🔒 You must be logged in as an Administrator or Editor to listen to this audio.
这份文稿是上一部分内容的延续，主要从代码实战应用、综合评分标准以及系统优化策略三个维度，深入讲解了如何将 RAG 评估落地并在发现问题后进行调优。
以下是核心内容的详细总结：
一、 评估框架 (Ragas) 的实战应用
在实际代码中，使用 Ragas 框架进行评估通常遵循一套固定的“套路”：
- 准备数据：针对实际项目（如金融助手），通常只需要准备**“用户问题”和对应的“参考答案”。将问题输入给你的 RAG 系统，系统会自动生成“检索的上下文”和“最终回答”**。
- 构建数据集：将上述四个要素（问题、参考答案、上下文、最终回答）组合成 Ragas 框架要求的数据集格式 (Dataset)。
- 配置与执行：导入所需的大模型 (LLM) 和嵌入模型 (Embedding)，配置需要评估的指标，执行评估操作。
- 结果输出：将评估结果转换为 Pandas 数据表，并导出为 CSV 文件，方便直观地对比各项指标的得分。
二、 综合评估：F1 分数与行业参考标准
在实际应用中，很难同时达到完美的“高召回率”和“高精度”，通常的妥协状态是**“高召回率 + 中等精度”**（宁可多找点废话，也不能漏掉关键信息）。
为了综合比较不同模型或不同时期的检索效果，引入了 F1 分数：
- 作用：它是精度 (Precision) 和召回率 (Recall) 的调和平均值，用于在精度和召回率出现一高一低时，给出一个综合评判标准，直观判断哪种方案总体更优。
行业常规的指标参考线（经验值）： | 评估指标 | 优秀标准 | 及格/中等标准 | 较差标准 | | :--- | :--- | :--- | :--- | | 上下文召回率 (Recall) | ≥ 0.9 (医疗/法律等严谨领域需极高) | - | - | | 上下文精度 (Precision) | ≥ 0.8 | 0.5 - 0.8 | < 0.5 | | 忠实度 (Faithfulness) | ≥ 0.9 (不能有幻觉) | - | - | | 答案相关性 (Relevance) | ≥ 0.9 (不能答非所问) | - | - |
三、 指标偏低的原因及“对症下药”优化策略
如果评估跑出来的分数不理想，需要根据具体指标去反推问题所在：
1. 检索阶段问题（针对上下文）
- 召回率低（找不全）：
- 原因：知识库本身缺失该信息、嵌入(Embedding)模型能力不足、检索策略设置返回的文档数量过少。
- 优化：扩充/更新知识库、更换更高维度的嵌入模型、采用多路召回策略。
- 精度低（找得不准、噪声大）：
- 原因：相似度阈值设置太低（召回了太多无关文档）、文档分块(Chunking)过大或过小、索引构建不合理。
- 优化：优化分块策略、使用重排序 (Rerank) 技术、调整检索相似度阈值。
2. 生成阶段问题（针对最终答案）
- 忠实度低（胡编乱造）：
- 原因：检索到的上下文太长导致关键信息被稀释（大模型抓不住重点）、提示词(Prompt)约束力不够。
- 优化：在 Prompt 中加强约束（“严格基于以下上下文回答”）、精简和提炼送给大模型的上下文。
- 答案相关性低（答非所问）：
- 原因：大模型没有理解用户的真实意图，特别是面对复杂多步的问题。
- 优化：增加问题意图识别环节、对复杂问题进行改写 (Query Rewriting) 或拆解后再进行检索和回答。
四、 核心答疑 (Q&A) 精华总结
- 上下文与文档块的关系：它们本质是同一个东西。上下文就是由检索器找出来的、与问题相关的多个“文档块”组合而成的。
- 评估的时机：通常在应用构建完成后进行系统性评估；但在开发阶段也可以对单个小模块（如单纯测检索）进行边做边测。
- 数据更新与重新评估：知识库动态更新后，不需要全部推翻重来，只需对新增的数据进行定期抽样评估即可；如果发现某个环节（如分块策略）有严重问题，才需要推翻该环节重新构建索引。