作者：好奇的小逸
原文：https://zhuanlan.zhihu.com/p/2036619681105228260
最近正好在搞 agentic factual ability的问题，就想着先总结一下目前的内容，这里首先想一下我们的目标是什么？直接给出结果的普通事实类问答吗？显然不是。我们这里想要的是一套可观察、可验证、可复盘的求证过程。例如： 看到问题 -> 判断要不要查 -> 知道该查什么 -> 找到合适证据 -> 判断证据够不够 -> 识别证据之间是否冲突 -> 最后只说证据支持的内容。
模型不能只是把脑子里记住的事实吐出来，而是要学会在面对事实性问题时，先判断这个问题是否依赖时效、来源、口径和上下文；如果需要查，就应该主动查；查到证据后，还要能分辨证据质量，不能把网页标题、营销稿、二手转述都当成同等可靠的事实来源。最后回答时，也不能为了显得确定而把不确定的东西说满。
在清楚目标之后，那么我们针对该类型数据的 query 应该怎么筛？轨迹数据应该怎么生成？Claude Code / Codex 这类工具应该怎么用？ 这篇就简单的来梳理一下。
1. 首先要想清楚：我们到底要训练什么？
普通事实问答训练的是：
问题 -> 答案
比如：
- 问题：阿里巴巴集团现任 CEO 是谁？ 回答：吴泳铭。
- 但 agentic factual 数据要训练的是：
- 问题 -> 检索动作 -> 观察证据 -> 判断 -> 最终回答
比如：
- 问题：现任阿里巴巴集团 CEO 是谁？
- Action: search(“阿里巴巴集团 现任 CEO 官方”) Observation: 阿里巴巴集团官网管理团队页面显示吴泳铭为 CEO。
- Final: 截至当前查询时间，阿里巴巴集团官网显示吴泳铭为集团 CEO。
这里真正有训练价值的，不只是“吴泳铭”这个答案，而是模型学到了：
- “现任”是时效信息，需要查；
- 要优先查官方来源；
- 回答时最好加时间边界；
- 不要凭记忆硬答。
2. Query 不是越多越好，要能产生“有价值轨迹”
做这类数据时，Query的筛选非常重要
比如：
- 中国的首都是哪里？
这种太简单的问题，无法训练出模型的agent 能力。
我们真正需要的是更有价值的Query，例如：
- 现任阿里巴巴集团 CEO 是谁？
- 某公司 2023 年是否盈利？
- 根据这份公告，公司第四季度营收是多少？
- 某药品是否已经获批用于某个适应症？
- 《西游记》的作者参与创办的公司，
- 是否在 2024 年发布过大模型？
因为这类问题真正考验的，不是模型能不能“答出一个结果”，而是它能不能处理更复杂的事实判断：哪些信息有时效性、证据范围该怎么限定、权威来源该怎么选、用户问题里有没有错误前提、不同口径下结论是否会变、证据冲突时怎么取舍，以及证据不足时能不能老老实实说“不确定”。
3. Query 分类和标签怎么打
为什么要先做分类和标签？
原因很简单：不同 query 需要的求证方式不一样。 例如：
问“现任 CEO”，要查最新来源。 问“根据这份公告”，只能查给定文档。 问“某公司是否盈利”，要先区分盈利口径。 问“未公开内部信息”，可能就应该拒答。
如果不提前标出来，后面生成轨迹时就很容易乱：该查的不查，不该联网的乱联网，该分口径的直接 yes/no。
所以这里先做两层标注。
第一层是“问题类型”，也就是先判断这条 query 大概属于哪一类 例如：
时效事实类：现任 CEO、最新版本、当前政策状态 给定文档问答类：根据公告、根据论文、只基于上文 错误前提识别类：问题里可能混了一个不成立的前提 口径歧义判断类：盈利、开源、上市、有效、效果更好 冲突证据处理类：不同来源可能说法不一致 证据不足拒答类：未公开信息、私人信息、无法验证的信息
第二层是“处理标签”，也就是告诉后面的生成流程该怎么处理这条query 例如：
任务类别：属于上面哪一类 证据范围：只能看给定文档，还是可以开放检索 是否需要检索：要不要调用 search / document search 是否需要权威来源：要不要优先查官网、年报、法规库 推荐证据源：大概该查哪些材料 轨迹生成策略：这条样本应该生成什么样的求证过程
这里举一个简单的例子，来帮助理解：
比如这条：
- 某公司 2023 年是否盈利？
就可以标成：
{
"任务类别": "口径歧义判断类",
"证据范围": "开放检索",
"是否需要检索": true,
"是否需要权威来源": true,
"推荐证据源": ["年报", "公司公告", "交易所公告"],
"轨迹生成策略": "分别查净利润和调整后 EBITDA，最后分口径回答"
}
这样后面生成轨迹时就很清楚：不能直接回答“盈利”或“不盈利”，而是要先查证据、分口径、再给结论。
4. 轨迹数据到底长什么样？
一个完整轨迹不用写得很复杂，先包含 4 个核心部分就够：
query：用户问题
类别：属于哪类事实任务
证据：从哪里查到什么
response：最终要训练模型学习的求证轨迹和回答
例如：
{
"query": "某公司 2023 年是否盈利？",
"类别": "口径歧义判断类",
"证据": [
"E1: 年报显示归属于股东的净亏损为 12 亿元",
"E2: 公告称调整后 EBITDA 盈利"
],
"response": "先查年报净利润，再查调整后 EBITDA，最后回答：按净利润口径亏损，按调整后 EBITDA 口径盈利，不能简单说已经盈利。",
}
5. Mid-train 和 SFT 数据不要做成一模一样
这里的答案是否定的，因为它们训练的目标不一样。
Mid-train 更偏“能力训练”，重点是让模型学会事实验证背后的底层动作，比如：怎么拆 claim、怎么匹配证据、怎么判断支持/反驳/信息不足、怎么处理冲突证据、怎么识别错误前提。
所以 Mid-train 数据可以更结构化，不一定要像真实对话。
例如： 问题 -> claim 拆解 -> 证据 -> stance 判断 -> 推理依据 -> 最终结论
而 SFT 更偏“行为对齐”，重点是让模型学会在真实用户场景里应该怎么行动、怎么表达。它要更像最终用户会看到的 assistant 行为，比如：什么时候查、怎么查、怎么引用证据、怎么给出克制且有边界的回答。
例如： User 问题 -> Assistant 检索/观察 -> Final answer
6. 一个可行的合成流水线
这里简单梳理一个可执行流程：
清洗去重-> 打分类和处理标签 -> 构造 evidence_pack -> 生成轨迹样本 -> verifier 打分 -> 写入 SFT / Mid-train 数据
这里最关键的是 evidence_pack，生成的轨迹样本中的 observation 最好都来自evidence_pack，不要让模型凭记忆去生成。
7. 最容易踩的坑
这类数据最容易出问题的地方，其实就几个：
- observation 凭空写： 轨迹里说“官网显示”，但其实没有真实证据。解决办法是 observation 必须来自 evidence_pack。
- 只看最终答案： 有些答案碰巧对，但过程完全不合格。agentic 数据要看它有没有查、查得对不对。
- 什么问题都联网： 用户说“根据这份公告”，就只能看公告。Agentic 能力不是永远用工具，而是该用才用。
- 证据不足还硬答： 查不到可靠来源时，要降级表达或拒答，不要编一个听起来像真的答案。