引言

《Rag Agent，迭代史》系列已完成4次迭代，概要如下：

V1版本

内容：通过Dify平台，搭建入门智能体，包含：知识库（配置一律默认），智能体简易配置。
结果：能跑通。
问题：回答质量低，根源在于召回内容语义不完整。

V2版本（切换至COZE平台）

内容：将上传文章进行Q&A Pairs转换，保证每对Q&A语义完整。
结果：较V1版本，内容具备语义完整性。
问题：回答缺乏广度与深度。因“Q&A Pairs转换”在保证语义完整的同时，造成了严重的信息丢失。

V3版本

内容：舍弃V2版本"Q&A Pairs转换"路线，知识库尝试父子层级切分（索引和上下文分离）。
结果：较V2版本，内容广度和深度有所提升。
问题：提示词中的固定模板导致答案结构僵化，逻辑流畅性不足。

V4版本

内容：先对召回内容（这里指父级内容）进行预处理，提取自由主题，让LLM参考自由主题和召回内容先形成结构性大纲，再输出内容。
结果：较V3版本，内容的结构性/逻辑流畅性在感官上明显提升。
问题：出现答非所问。根因是检索阶段存在内容召回不全或不准确的问题。

前4个版本的迭代主要依赖主观直觉与定性观察。然而，在规划V5时，过多的可能性使得 “选择迭代方向” 本身成为了瓶颈。这引出了一个根本性原则：

No measure, no management!

因此，建立量化的评估体系，定义明确的迭代目标与关键指标，是突破瓶颈的首要路径。本文即围绕该体系展开，主要内容包括：

整体评估框架
黄金评估集介绍及构建
各类评估器的Prompt

一、整体评估框架

本文将 RAG Agent链路解耦为：

user_query -> Retrieval（检索召回） -> LLM_Generation（大模型生成）-> answer

在这个链路中：

user_query： 用户问题
Retrieval： 检索召回，通过用户问题检索召回上下文（contexts）,给LLM提供内容参考。
LLM_Generation： 大模型内容生成，根据参考内容和Prompt，生成内容。
answser： Agent最终输出答案。

基于该链路，建立评估框架：
ragAgent_评估链路图

链路阶段	评估目标	涉及指标
整体评估(user_query->answer)	衡量 Agent 回答用户问题时的正确程度。	Correctness：答案正确性
Retrieval阶段	衡量检索召回的contexts质量表现。	Recall：召回率 Precision：准确率 MRR：平均倒数排名
LLM_Generation阶段	评估生成内容的表现情况。	Groundedness：答案有据性 Relevance：答案相关性 Organization：信息组织力

1.1 答案正确性-整体评估(User_Query->Answer)

我们首先需回答：究竟在迭代什么？我们在乎Rag Agent的什么能力？

当然是衡量 Agent 回答用户问题时是否正确。

答案正确性

定义：Agent 的最终回答是否在事实层面与专家撰写的标准答案 (Ground Truth Answer) 一致。注：Ground Truth后文简称为GT
计算方式：LLM-as-a-Judge。利用更强模型（如DeepSeek-V3）对比 Agent Answer 与 GT Answer。
评分标准：
- 最高分：事实完全一致，关键信息无遗漏。
- ……
- 最低分：事实矛盾（一本正经胡说八道）或关键信息缺失。
实践意义：这是迭代的最终评判标准，无论采取何种迭代方向，如果正确性得分低，说明在做“无用功”。

1.2 Retrieval阶段

在此阶段，衡量的是召回内容质量，需要对比实际召回的上下文与专家标记的充分且必要 的上下文。

[!NOTE]
充分且必要
指生成标准答案所需的最小上下文集合。

字典解释

ID：指召回的每条上下文都具备唯一识别ID，IDs则指上下文的ID集合。
Retrieved_Contexts_IDs ：指用户询问后，Retrieval阶段实际召回的上下文ID集合。
GT_Contexts_IDs：指专家根据问题标记的最小上下文ID集合，该集合能构成标准答案。

1.2.1 召回率 ( Context Recall )

该指标决定了系统的能力天花板。

定义：专家认为回答问题必需的那些上下文集合，检索系统找全了吗？
计算公式： $Recall = \frac{| RetrievedContextsIDs \cap GTContextsIDs |}{| GTContextsIDs |}$
公式详解：
- 针对每一个问题，都需要专家标注充分且必要的上下文ID集合（GT_Contexts_IDs）。
- 将问题送入Agent中，Retieval阶段得到实际召回的Contexts集合（Retrieved_Contexts_IDs ）。
- 取GT_Contexts_IDs 和 Retrieved_Contexts_IDs 的交集，获取其数量，再除以GT_Contexts_IDs的数量，则得到召回率。
实践意义：
- 召回内容诊断： 如果 Recall 很低，说明 LLM 根本没有获得足够的原材料，这是导致“答非所问”的根本原因。
- 迭代方向： 想办法提高Recall，如：优化 Embedding 模型、优化切分粒度、优化检索召回策略、增大 Top-K、降低召回阈值、引入NER、优化Rerank等等。

1.2.2 准确率（ Context Precision ）

变相表示LLM生成时所参考内容的信噪比。

定义：Retrieval阶段检索回来的 Top-K 上下文集合中，有多少是真正有用的？
计算公式： $Precision = \frac{| RetrievedContextsIDs \cap GTContextsIDs |}{| RetrievedContextsIDs |}$
公式详解：
- 取GT_Contexts_IDs 和 Retrieved_Contexts_IDs 的交集，获取其数量，再除以Retrieved_Contexts_IDs 的数量，则得到准确率。
实践意义：
- 召回内容诊断： Precision 低意味着检索结果中充斥着大量噪音。这不仅浪费 Token 成本，更会诱导 LLM 产生幻觉（因为 LLM 很难忽略看似相关实则错误的干扰信息）。
- 迭代方向：想办法提高Precision，过滤掉不必要的召回上下文，包括：元数据过滤、增高召回阈值、混合检索、优化Rerank等.

1.2.3 平均倒数排名 (Mean-RR)

衡量Retrieval阶段对召回上下列表的排序能力与对 LLM 的“注意力引导”效果。

定义：在召回上下文的列表中，第一个正确（属于 GT_Contexts_IDs ）的上下文是不是排在最前面？
计算公式： $RR = \frac{1}{Rank of First Relevant Context In RetrievedContextsIDs}$
公式详解：
- 针对每一个问题，检查 Retrieved_Contexts_IDs 列表（有序）。
- 找到列表中第一个出现在 GT_Contexts_IDs 中的文档，记录其排名位置（Rank）。
- 计算该问题的得分 $\frac{1}{Rank}$ （例如：排第1得1分，排第2得0.5分，没找到得0分）。
- 将所有问题的得分加总后取平均值，即为 MRR。
实践意义：
- 召回内容诊断： MRR 低说明正确答案虽然被召回了，但被埋没在列表的中间或尾部。由于 LLM 存在 “迷失中间 (Lost in the Middle)” 效应和 “首因效应”，排在靠后的正确信息很容易被 LLM 忽略或权重降低，导致回答质量下降。
- 迭代方向： 核心是优化排序逻辑，确保最相关的文档“置顶”。包括：引入重排序模型 (Re-ranker)（这是提升 MRR 最有效的手段）、微调 Embedding 模型、调整混合检索中关键词与向量的权重配比等。

1.3 LLM_Generation阶段

在此阶段，假设检索召回已经完成，我们将目光聚焦于 LLM 的“大脑”处理能力。评估的重点不再是“找没找到”，而是“读懂了没”以及“写得好不好”。

字典解释

Retrieved_Contexts: 指Retrieval阶段实际召回的上下文内容，特指内容本身，不是ID。

1.3.1 答案有据性（Groundedness）

该指标是 RAG Agent的“防幻觉”底线。

定义：Agent 的回答是否严格基于召回上下文？生成的每一个原子事实（Atomic Fact）能否在召回上下文中找到证据支撑？
计算逻辑（LLM-as-a-Judge）：
- 输入：Agent Answer vs Retrieved_Contexts
- 逻辑：裁判 LLM 将回答拆解为独立的事实陈述，逐一在 Context 中寻找证据。
评分标准：
- 最高分：所有信息均有出处，允许合理的总结与改写。
- ……
- 最低分：包含未知的外部信息，或与 Context 严重冲突。
实践意义：
- 生成内容诊断：确保 Agent “知之为知之，不知为不知”。对于教程类 Agent，必须防止它在检索失败时，利用训练数据中的过时知识编造参数。
- 迭代方向：若分数低，需修改 System Prompt，加强“仅基于上下文回答”、“严禁使用外部知识”的约束；或降低 LLM 的 Temperature 参数；或更换LLM等。

1.3.2 答案相关性（Relevance）

该指标衡量 Agent 是否“听懂了人话”以及“服务态度”。

定义：Agent 是否直接、有效地回应了用户的核心问题？
计算逻辑（LLM-as-a-Judge）：
- 输入：Agent Answer vs User Query。注：此处特意不输入上下文，以保持变量隔离。
- 逻辑：裁判 LLM 判断回答是否直击痛点，是否存在废话、复读机行为或答非所问。
评分标准：
- 最高分：完美切题。
- ……
- 最低分： 答非所问，如V4版本遇到的问题。
实践意义：
- 生成内容诊断：
  1. 若相关性低：说明 LLM 指令遵循能力差，或者被 Prompt 中的无关信息带偏。
  2. 若相关性低但有据性高：这是典型的”老实人办坏事”。说明检索到了错误信息，Agent 被迫“老实地”回答了错误的内容。此时锅在 Retrieval 阶段。
- 迭代方向：优化 Prompt 中的任务指令（Instruction），明确回答风格；若属上述情况2，则需回溯优化召回率。

1.3.3 可选指标-信息组织力（Organization）

该指标是 V4 版本的特色指标，用于衡量“结构化生成”策略的成效。

定义：Agent 是否成功利用“主题约束”，将碎片化的召回上下文有机融合，并果断舍弃了无关噪音？
计算逻辑（LLM-as-a-Judge）：
- 输入：Agent Answer vs Retrieved_Contexts。
- 逻辑：判断 Agent 是否构建了清晰的逻辑主线？是否舍弃了 Context 中的琐碎噪音？是否消除了“根据资料1显示…”这种机械拼接痕迹？
评分标准：
- 最高分：深度融合/完美降噪/专家口吻。
- ……
- 中间分：机械拼接/流水账。
- ……
- 最低分：逻辑混乱。
实践意义：
- 生成内容诊断：这是区分“复读机”与“真正的专家助手”的关键。验证 V4 引入的 “自由主题提取 -> 结构化生成” 策略是否生效。
- 迭代方向：若分数低，说明 LLM 仍倾向于机械摘录。需优化生成阶段的 Prompt，引入思维链（CoT），要求 LLM 先在内部构建大纲，再进行“专家口吻”的转述。

二、黄金评估集

2.1 介绍

在整体评估框架中，会发现无论什么指标，都要求有 正确参考内容 作为对比，这些正确参考内容是黄金集条目的核心要素，主要包含3部分：

要素	变量名	定义	作用
问题	`user_query`	覆盖新手、进阶、排错等多维度的用户提问。	模拟真实场景输入。
标准上下文ID集合	`GT_Context_IDs`	回答该问题充分且必要的召回内容ID集合。	检索评估的基准，计算召回率和准确率。
(可选)标准上下文内容	`GT_Contexts`	回答该问题充分且必要的召回内容本身。	当标准答案撰写成本较高时，作为生成标准答案的素材。
标准答案	`GT_Answer`	基于标准上下文生成的、逻辑严密且事实准确的理想回答。	生成评估的基准，用于判定 Agent 回答的正确性。

2.2 黄金集的构造原则

黄金集为评估服务，评估框架为迭代服务。

在此前提下，首先避免踩坑大坑，需指出黄金集条目不是越多越好，原因如下：

黄金集不是为了在大数据上抛出统计学显著性，而是快速诊断系统病灶。
黄金集更多是“困难样本的浓缩”，当样本过多时，分母变大，指标被稀释。
黄金集的更新维护成本较高，小规模的样本可确保人工校验的可行性。
迭代成本，小样本意味着评测成本低、速度快。

构建黄金评估集需要遵循以下原则：

覆盖度 > 质量 > 数量

2.2.1 覆盖度

覆盖度并非指题目要穷尽所有的业务知识点，而是指黄金集中的 GT_Contexts（标准上下文）必须覆盖不同的检索场景。

在对检索场景分类前，先介绍检索动作依赖性，大致分为单跳类型和多跳类型。

单跳类型：指检索召回模块通过用户输入，仅需进行一次并行检索动作，即可在结果集中找齐所需信息，上下文之间是并列关系（B上下文不需要通过A上下文中的线索得到），图示如下：
多跳类型：指检索召回模块无法通过初始输入一次性找齐答案。它需要多次检索，且后续的检索动作依赖于前一次检索到的内容（线索）。上下文之间存在链式或因果关系（A $\to$ B），图示如下：

结合检索动作依赖性 & GT_Contexts在文档的位置分布情况，就可以得到4类检索场景。

覆盖度类型	类型描述	主要挑战指标
A_单跳_单文档_单点	`GT_Contexts`只需标记1条，单跳获得	挑战：Precision。考察系统能否精准定位，不带噪音。
B_单跳_单文档_多点	`GT_Contexts`需在同一文档中标记多条，单跳获得	挑战：Recall。考察切分粒度是否太细导致语义破碎？窗口是否够大？
C_单跳_多文档_多点	`GT_Contexts`需在多文档中标记多条，单跳获得	挑战：Organization。考察 V4 能否将并列的、来源不同的知识点有机融合。
D_多跳_多文档_多点	`GT_Contexts`需在多文档中标记多条，多次	挑战：Recall。考察检索链路的完整性。若 A 没召回，B 也就丢了。
就此，我们便能通过黄金评估集能覆盖检索场景，至于分布比例可酌情考虑。

2.2.2 质量

质量是黄金集的生命线。高质量的标注必须遵循 “最小完备集” 原则。即：专家标注的 GT_Contexts 对于回答该问题而言，必须是充分且必要的。

充分性—— “缺一不可”
– 定义：集合必须包含回答问题所需的所有信息片段。
– 违规后果：若漏标关键Contexts，检索没找回来也不扣分，但生成阶段 LLM 却因缺信息而瞎编（导致 Recall 虚高，幻觉增加）。

必要性 —— “多一不可”
– 定义：集合中不应包含任何对回答问题无实质帮助的冗余片段。
– 违规后果：若多标了无关Contexts，Agent 没找回来（这是对的）却被扣了召回分（导致 Recall 虚低，误杀好模型）。

验收标准：专家在审核时需自问：“如果我不给 LLM 看这个 Context，它还能答对吗？”如果不影响作答，则该 Context不应被标记为 GT。

2.2.3 数量

在 RAG 的迭代开发期，遵循 “精简原则”。

推荐规模：50 条以内 （tips：作者首次实践时，只构建了10条）
动态维护策略：
- 拒绝题海战术：保持小规模数据集，确保专家可在短时间内完成一轮人工校验，保证评估的可持续性。
- 末位淘汰制：黄金集应是“动态错题本”。当某个 Type A 类问题在连续N个版本中得分均为满分，说明系统已完全掌握，应将其移出黄金集（转入回归测试库），并补充新的 Type C/D 类“难题”进来。
- 保持敏感度：始终维持黄金集的高难度与高敏感度，确保每一次代码微调（如修改 Prompt 或重排序权重）都能在分数上得到直观反馈。

2.3 黄金集构建实操SOP

面对海量文档，纯人工构建耗时耗力。为了在质量与效率之间取得平衡，推荐采用 AI 辅助 + 专家裁决的流水线模式。

Step 1：定向提问

利用 LLM 遍历知识库，针对性地生成覆盖 A/B/C/D 四类场景的问题。

操作技巧：不要让 LLM 泛泛而谈。需在 Prompt 中明确要求：“请根据文档生成一个需要跨段落总结的问题（B类）”或“请生成一个多跳推理问题（D类）”。
输入：知识库文档片段。
Prompt：见文末附录。
产出：候选问题列表。

Step 2：专家标记上下文

这是构建过程中唯一不可省略的人工环节，也是确立“真理”的过程。

操作：开发者审视候选问题，利用搜索工具在知识库中检索，人工筛选出 GT_Context_IDs。
执行标准：严格执行“最小完备集”原则。
- 自问 1：“为了答对这道题，必须看这段话吗？” -> 若否，剔除。
- 自问 2：“只看这两段话，逻辑链条断了吗？” -> 若断，补录。
产出：User_Query + GT_Context_IDs。

Step 3：有机融合生成答案

有了精准的上下文，我们不需要人工手写几百字的标准答案，而是让 LLM 代劳。

策略：使用 “有机融合 Prompt”。要求 LLM 扮演专家，基于 GT_Context_IDs 进行逻辑重组，生成一篇结构严密、丝滑的“满分作文”。
Prompt：见文末附录。
产出：GT_Answer。

Step 4：快速验收

专家只需快速人工扫视生成的 GT_Answer,同时也可以让LLM代劳。

检查点：逻辑是否通顺？是否存在明显幻觉（使用了素材外的信息）？
耗时：熟练后，每条数据的验收时间可控制在 1-2 分钟。
Prompt：当然，也能利用LLM进行答案审核，Promp放在文末附录。

三、结语

回顾《Rag Agent，迭代史》，V1 到 V4 是“功能”的累积，而评估框架的诞生，则是“工程”的觉醒。

评估不是终点，而是新迭代的起点。带着这套量化体系，让我们在后续版本中，用数据驱动每一次优化，通过实操去挑战 RAG 的能力上限。

附录

Agent_Answer有据性评估Prompt

# Role
你是一位专门检测 AI 幻觉的审计员。你的任务是判断“模型回答”中的每一条信息是否都有“参考资料”作为支撑。

# Input Data
## **参考资料 (Retrieved Context)**:
{{context}}

## **模型回答 (Model Answer)**:
{{actual_output}}

# Evaluation Steps (评估步骤)
1. 将“模型回答”拆解为独立的陈述句。
2. 逐一检查每一条陈述句：
   - 它是否能在“参考资料”中找到明确证据？
   - 或者它是否是基于“参考资料”的合理推断（不矛盾）？
3. 检查是否存在“参考资料”中未提及的外部知识（除非是普适常识）。

# Scoring Rubric (评分标准 1-5)
- **5分 (完全忠实)**：回答中的所有事实、数据、逻辑都严格源自参考资料。回答是对资料的有机重组，没有添加任何未授权的信息。
- **4分 (基本忠实)**：回答基于参考资料，但包含了极少量的、无害的连接词或背景修饰，不影响事实准确性。
- **3分 (部分幻觉)**：回答的主要内容基于资料，但夹杂了资料中未提及的具体细节（如编造了具体的参数值或步骤）。
- **2分 (严重幻觉)**：回答中包含大量资料中不存在的信息，或者通过外部知识回答了资料中没提到的问题。
- **1分 (完全矛盾)**：回答的内容与参考资料直接冲突，或者是完全的瞎编。

# Output Format
请严格输出 JSON 格式：
{
  "score": <1-5的整数>,
  "reason": "<简短指出哪一句话或者是哪个参数在参考资料中找不到依据>"
}

Agent_Answer相关性评估Prompt

# Role
你是一位严格的考官。你的任务是评估考生的回答是否**直接、完整**地回应了考题，而不关心回答的事实是否正确。

# Input Data
## **用户问题 (User Question)**:
{{input}}

## **模型回答 (Model Answer)**:
{{actual_output}}

# Evaluation Criteria (评估标准)
请关注回答的**针对性**。
- 回答是否正面解决了用户的疑问？
- 回答是否提供了有用的信息，还是在说废话？
- **注意**：即使回答包含事实错误（幻觉），只要它是在尝试回答这个问题，相关性分数也可以很高。

# Scoring Rubric (评分标准 1-5)
- **5分 (完美相关)**：回答直击痛点，完整覆盖了问题的所有意图。无冗余废话。
- **4分 (高度相关)**：回答了核心问题，但可能包含少量不必要的啰嗦，或者遗漏了次要的追问。
- **3分 (一般)**：回答沾边，但不够直接。例如：用户问“怎么做”，回答却在解释“是什么”。或者回答过于宽泛。
- **2分 (低相关)**：回答了相关的话题，但没有解决具体问题。例如：复述了一遍问题中的关键词，但没给出结论。
- **1分 (不相关)**：完全答非所问，或者像复读机一样重复问题，或者回答了完全不同的问题。

# Output Format
请严格输出 JSON 格式：
{
  "score": <1-5的整数>,
  "reason": "<简短评价回答是否直接解决了问题>"
}

Agent_Answer信息组织力评估Prompt

# Role
你是一位资深的信息架构师和编辑。你的任务是评估 AI 是否成功地将**碎片化的【上下文】**重构成**结构化的成品**。

# Input Data
## **用户问题**: 
{{这里填写用户问题}}


## **上下文 (Context)**: 
*(注意：这里面可能包含很多零碎、重复、甚至与核心主题无关的噪音信息，其中topics代表了内容主题)*

{{这里填写召回的上下文}}


# **模型回答 (Model Answer)**: 
{{actual_output}}

# Evaluation Goal
请判断：模型是否成功应用了“主题约束”策略？即：它是否从碎片中提取了逻辑主线，并**果断舍弃**了那些无法串联的零碎信息？

# Evaluation Criteria (评分标准 1-5)

- **5分 (卓越的重构)**：
    - **极强的逻辑主线**：回答围绕核心主题展开，结构严密（如：总分总、对比结构）。
    - **完美的降噪**：上下文中那些琐碎的、无法融入主题的孤立句子被完全过滤掉了。
    - **有机串联**：引用的上下文片段被“消化”后重新组织，看不到拼接痕迹。

- **4分 (良好的重构)**：
    - 有明显的主题结构。
    - 舍弃了大部分噪音，但可能保留了个别突兀的细节。
    - 语句通顺。

- **3分 (机械拼接 - 你的痛点)**：
    - **流水账**：虽然回答了问题，但感觉是把上下文里的信息按顺序翻译了一遍。
    - **未过滤噪音**：上下文里提到的一些无关琐事（比如无关的参数定义）也被强行塞进了回答里。
    - **缺乏主线**：没有清晰的“自由主题”感。

- **2分 (逻辑混乱)**：
    - 试图结构化但失败了，导致逻辑断层。
    - 或者强行把不相关的信息硬凑在一起。

- **1分 (失败)**：
    - 直接复制粘贴上下文原文。
    - 或者完全脱离上下文自己瞎编。

# Output Format
请严格输出 JSON 格式：
{
  "score": <1-5的整数>,
  "reason": "<简短评价回答是否直接解决了问题>"
}

黄金集构建_提问Prompt

# Role
你是一位 RAG 系统测试专家，专门负责构建高难度的“黄金评估集”。你需要深入理解提供的技术文档，并站在小白用户、进阶用户和故障排查者的角度，设计出能全面考察检索系统能力的测试题。

# Taxonomy: 检索场景分类矩阵
请严格按照以下四种难度类型生成问题，确保问题集具备充分的覆盖度：

1.  **Type A (单跳-单点)**:
    * **定义**: 答案仅位于文档中的某一个具体段落，只需精准匹配。
    * **特征**: 询问具体的参数值、定义、报错含义。
    * **例题**: "Flux.1 Dev 版本的显存推荐值是多少？"

2.  **Type B (单跳-离散)**:
    * **定义**: 答案分散在同一文档的开头、中间或结尾，需要进行长文总结。
    * **特征**: 询问“所有...”、“流程步骤”、“包含哪些...”。
    * **例题**: "总结一下文中提到的所有 ControlNet 预处理器名称。"

3.  **Type C (跨文档-对比/融合)**:
    * **定义**: 答案需要结合文档中两个不同主题的部分（甚至跨文档）进行对比或综合。
    * **特征**: 询问“区别是什么”、“优缺点对比”、“共同点”。
    * **例题**: "对比一下文中提到的 IPAdapter 和 ControlNet 在控图原理上的主要区别。"

4.  **Type D (多跳-推理)**:
    * **定义**: 答案无法直接找到，需要先找到线索 A，再根据线索 A 找到答案 B。
    * **特征**: 问题中包含间接引用的实体，或询问“如何配置 X 对应的 Y”。
    * **例题**: "我要加载文中提到的那个 T5 文本编码器，在 ComfyUI 加载节点里应该填哪个文件名？" (需先查 T5 对应的文件名，再回答)。

# Task
阅读提供的参考文档，生成 **5-8 个** 测试问题。

# Requirements
1.  **覆盖度强制**: 输出必须尽可能覆盖 A、B、C、D 四种类型。如果文档内容不足以生成 C 或 D 类，请尝试基于文档逻辑挖掘最接近的问题。
2.  **拟人化**: 问题必须模拟真实用户的提问口吻，不要过于书面化。
3.  **自证**: 对每个生成的问题，必须标注其所属类型，并简述“解题路径”。

# Input Data (参考文档)
{{document_content}}

# Output Format
请严格按以下 JSON 格式输出：
[
  {
    "question": "生成的问题文本",
    "type": "Type A / B / C / D",
    "reasoning": "简述为什么属于这个类型（例如：需要结合第1段和第5段的内容）",
    "source_clue": "答案对应的关键词或原文片段"
  },
  ...
]

黄金集构建_生成标准答案Prompt

 # Role
你是一位 ComfyUI 领域的资深技术专家，擅长将碎片化的技术文档融合成逻辑严密、通俗易懂的教程答案。

# Input Data
## 1. 用户问题 (User Question):
{用户问题}

## 2. 预提取的核心主题 (Pre-extracted Themes):
{你预处理好的主题列表}
*(注：这些主题仅作为你的“导航线索”，帮助你组织逻辑。)*

## 3. 参考资料 (Raw Contexts):
{粘贴 gt_contexts 对应的原始文本}
*(注：这是你生成答案的唯一事实来源。)*

# Task Instructions
请执行以下 **“有机融合” (Organic Fusion)** 的生成过程：

## Step 1: 语义映射与结构规划 (Internal Thought)
* **审查主题**：查看预提取的“核心主题”，在“参考资料”中寻找对应的事实细节。
* **过滤空洞**：如果某个主题在参考资料中没有实质性内容支撑，请果断**舍弃**该主题，或将其**合并**到其他点中。**不要为了凑骨架而强行描写。**
* **构建逻辑流**：根据资料的丰富程度，动态调整回答的结构（是先讲原理，还是先讲操作？是对比叙述，还是分步叙述？）。

## Step 2: 融合生成 (Synthesis Generation)
基于 Step 1 的规划，撰写最终的标准答案。
* **有机串联**：不要机械地按“主题1、主题2”罗列。请使用过渡句，将各个知识点串联成一篇连贯的短文。
* **事实查核**：确保所有引用的参数、名称、逻辑都严格源自“参考资料”。
* **风格要求**：保持“专家教学”的口吻，清晰、丝滑、有见地。

# Output
请直接输出 **最终的标准答案** (Markdown格式)。
*(不需要输出 Step 1 的思考过程，直接给我结果)*

黄金集构建_标准答案审核Prompt

# Role
你是一位严格的内容审计员。你的任务是检查一份由 AI 生成的“标准答案”是否合格。

# Input Data
## 1. 用户问题:**
{粘贴你的问题}

## 2. 原始参考资料 (Ground Truth Contexts):**
{粘贴你标记的contexts原文}

## 3. 待审核的答案 (Generated Answer):**
{粘贴标准答案}

# Audit Criteria (审核标准)
请检查“待审核的答案”是否满足以下条件：
1. **忠实性 (关键)**：答案中的所有事实是否都能在“参考资料”中找到依据？是否存在幻觉（编造资料中没有的信息）？
2. **完整性**：是否回答了“用户问题”的核心痛点？
3. **准确性**：是否存在逻辑错误或误导性描述？

# Output
请简要输出：
- **结果**：【通过】 或 【需修改】
- **理由**：(如果需修改，请指出具体哪一句话有问题)

Rag Agent，迭代史（五）：量化评估体系——从“感觉还行”到“数据说话”

引言

一、整体评估框架

1.1 答案正确性-整体评估(User_Query->Answer)

1.2 Retrieval阶段

1.2.1 召回率 ( Context Recall )

1.2.2 准确率（ Context Precision ）

1.2.3 平均倒数排名 (Mean-RR)

1.3 LLM_Generation阶段

1.3.1 答案有据性（Groundedness）

1.3.2 答案相关性（Relevance）

1.3.3 可选指标-信息组织力（Organization）

二、黄金评估集

2.1 介绍

2.2 黄金集的构造原则

2.2.1 覆盖度

2.2.2 质量

2.2.3 数量

2.3 黄金集构建实操SOP

Step 1：定向提问

Step 2：专家标记上下文

Step 3：有机融合生成答案

Step 4：快速验收

三、结语

附录

Agent_Answer有据性评估Prompt

Agent_Answer相关性评估Prompt

Agent_Answer信息组织力评估Prompt

黄金集构建_提问Prompt

黄金集构建_生成标准答案Prompt

黄金集构建_标准答案审核Prompt

You may also like...

发表回复取消回复

Rag Agent，迭代史（五）：量化评估体系——从“感觉还行”到“数据说话”

引言

一、整体评估框架

1.1 答案正确性-整体评估(User_Query->Answer)

1.2 Retrieval阶段

1.2.1 召回率 ( Context Recall )

1.2.2 准确率（ Context Precision ）

1.2.3 平均倒数排名 (Mean-RR)

1.3 LLM_Generation阶段

1.3.1 答案有据性（Groundedness）

1.3.2 答案相关性（Relevance）

1.3.3 可选指标-信息组织力（Organization）

二、 黄金评估集

2.1 介绍

2.2 黄金集的构造原则

2.2.1 覆盖度

2.2.2 质量

2.2.3 数量

2.3 黄金集构建实操SOP

Step 1：定向提问

Step 2：专家标记上下文

Step 3：有机融合生成答案

Step 4：快速验收

三、结语

附录

Agent_Answer有据性评估Prompt

Agent_Answer相关性评估Prompt

Agent_Answer信息组织力评估Prompt

黄金集构建_提问Prompt

黄金集构建_生成标准答案Prompt

黄金集构建_标准答案审核Prompt

You may also like...

Blog，启动

数据驱动：数据分析全流程框架

ComfyUI，SD控图入门篇，IPAdapter

发表回复 取消回复

二、黄金评估集

发表回复取消回复