企业官网建设流程全解析

最近看了一篇业界流传度很高的技术分享，核心命题就一句话：怎么从非结构化文本里，自动抽出一套供 Agent 使用的“问答逻辑链”数据。这个词值得拆开说——先说“问答”，它不是简单的 Q→A 快照，而是要包含“问题—推理步骤—可回溯的答案”这一整条链；再说“逻辑链”，它强调每一步中间结论都能从原文找到依据，并且步骤与步骤之间是递进的。这个东西解决什么问题呢？我发现很多团队做 Agent 微调，用的是现成的指令问答对，模型确实能回答，但你怎么问它都不说过程，出了问题也没法查它依据的是什么。而逻辑链数据把推理过程显式化，适合做 few-shot 示例、指令微调、过程奖励模型，甚至是指标化评测。正在做 Agent、RAG、模型微调或者自己搭训练语料的人，应该都会觉得这个思路有用。

1. Agent 的推理能力卡在“数据形态”上

1.1 简单问答对为什么不够用

先聊聊一个很多团队都踩过的坑。早期大家做“领域问答”的时候，训练数据就是几十万条（问题，答案），拿给模型一看，模型学的是“问题→答案”的输入输出映射。这个映射短平快，但 Agent 不是这么干活的。Agent 要完成一次复杂任务，通常要经过“理解目标→拆解子目标→检索/调工具→得到中间结果→汇总成最终答案”。如果训练数据不包含中间过程，模型只能自己脑补，脑补出来的路径经常跳步、重复、自洽性很差。

举个例子，你问一个客服 Agent“退货流程是什么”，它给一段官方话术，答得好像完整，但如果你追问“如果商品已经使用过了还能退吗”，它就慌了。为什么？因为训练语料里没有“把主问题拆成校验条件→查看规则列表→匹配当前情况→生成分支答案”这种链条。简单问答对解决不了分支推理，逻辑链数据可以把这些分步思考过程固化下来，让模型照着学。这是我从多个项目里反复验证过的一个结论：想让模型学会拆解问题，首先得给它看拆解过程，而不是只看一头一尾。

1.2 什么才算一条合格的“问答逻辑链”

我自己的定义是五要素：输入文本片段、一个需要多步回答的高价值问题、一组推理步骤、每一步都有原文依据、最终答案由链尾推出。更重要的是步骤间的递进关系，而不是平行罗列。

用一个例子说明。假设原文是：

系统通过引入序列特征和用户实时行为信号，将召回候选集从10000压缩到500，点击率提升3个百分点；由于点击率提升，排序阶段获得了更多正向样本，最终整体成交转化率提升1.2%。

一个问题可以是：“为什么该系统能提升成交转化？”

一条合格的链：

1. 第1步：依据原文“引入序列特征和用户实时行为信号”，推出结论“候选集更精准”；
2. 第2步：依据“候选集压缩到500，点击率提升3%”，结合第1步结论，推出“点击率提升”；
3. 第3步：依据“点击率提升后排序阶段获得更多正向样本”，结合第2步结论，推出“排序模型能力增强”；
4. 第4步：依据“最终整体成交转化率提升1.2%”，结合第3步结论，得到最终答案“因为候选集精准→点击率提升→排序模型获得更多正向样本→成交转化率提升1.2%”。

不合格的版本是什么？它把原文的四个信息点平行列举，第1步说“引入了序列特征”，第2步说“候选集压缩到500”，第3步说“点击率提升3%”，第4步说“转化率提升1.2%”。每步之间没有推理关系，去掉任何一步都不影响结论。这种就不是逻辑链，而是要点列表。抽数据时最常犯的错就是这种，后面会专门讲怎么筛。

1.3 为什么优先用“文本抽取”，而不是让模型直接生成

有人会问，直接用大模型“自问自答”不也能生成一堆推理样本吗？我问过几个同行，他们都说早期这么干过，但效果不稳。原因有三：

第一，可追溯性。文本抽取的答案必须落在原文区间内，幻觉空间被压缩；模型自由生成则没有这个约束。

第二，可验证性。抽取数据的复核方式很简单，打开原文，看答案位置对不对即可；自生成数据的复核还要额外判断“这说法本身对不对”，门槛完全不同。

第三，领域质量。正规来源文本（产品文档、教材、操作手册、内部知识库）本身经过审核，抽取出来的知识可靠性高。模型自由生成的样本则往往是训练语料里高频知识的拼贴，专业领域一测就露馅。

我自己就栽过跟头：用模型蒸馏了一批链式推理数据，评测集上准确率好看，换成真实产品文档问答，模型开始一本正经地引用“常识”回答问题，其实产品根本没那个设计。改成从文档里抽取之后，起码答案都有原文出处可查，调试起来也容易得多。所以“抽取”这个动作本身，就是一种天然的质量约束。

1.4 这篇工作真正改变的是什么

它把“数据生产”这件事从对齐任务变成了抽取任务。以前我们造推理数据，靠人写或靠模型写，写完之后总得担心它是不是“对的”。抽取出数据则是先给定“输出空间”，模型只需要在这个空间里做选择和组织，错误率会低一个量级。另外，它可以大规模并行，全流程自动化程度高，也方便定期重新跑一遍来扩充语料。我觉得这是它值得被拿来讲的根本原因。做训练数据的人都知道，能自动化的部分越靠前，后面留给人工判断的边际成本就越低。

2. 从原始文本到逻辑链的完整流水线

2.1 第一步：文本清洗与知识块切分

实操的第一步不是喂模型，而是把长文切成适合抽取的知识块。我现在的做法是：先按标题层级切，再按段落切。切完之后，单块控制在 300 到 800 字之间。这个区间是有讲究的：块太小，比如只有一两句话，问题问不出来，链条没空间展开；块太大，模型在生成步骤时容易“跨段引用”，你好不容易约束的幻觉又会回来。

如果碰到正文没有标题，或者一个章节特别长，我会用滑窗做 50% 重叠。但有一个细节必须保留：标题路径，比如“用户手册>通知设置>提醒频率”。这个东西看似不起眼，实际上很有用。生成问题时，模型可以带着“当前在哪一章”的意识去提问，抽出来的问答也天然带着知识坐标。Agent 将来引用答案时，能直接指出“来自哪个章节”，用户信任感完全不同。这个标题路径是我在做第一版数据管线时忽略的，后来加上之后，下游 Agent 回答的定位能力明显提升。

2.2 第二步：问题生成，要覆盖多种推理深度

问题不能只出“这段讲了什么”，要让 Agent 学会不同深度的问题拆解。我一般把问题分成四类，并且按比例配比：

• 事实提取型，如“默认超时时间是几秒”，占比约 30%，答案往往在一句话内；
• 归纳总结型，如“集成这个模块需要哪三个前置条件”，占比约 30%，需要跨多句合并；
• 因果推导型，如“为什么候选集压缩后转化率反而提升”，占比约 25%，是逻辑链训练的核心；
• 对比决策型，如“A 方案和 B 方案在什么场景下更合适”，占比约 15%，需要有对比条件和结论。

之所以要配比，是因为只喂单一类型，Agent 就会在某种问题上特别强，其它问题则回归“话痨式回答”。Prompt 里可以让模型参考真实用户语气，比如“请从文中找出……”“如果……会怎样”“相比……有什么区别”，别生成公式化的“根据文档内容，……”。后一种句子在微调时会污染输出风格，让 Agent 说话一股文档味，这是很多微调项目后期要花大力气清洗的东西，不如在生成阶段就卡住。

2.3 第三步：答案定位与链式推理构建

这是核心中的核心。我自己实践过的两种构建方式，各有适用场景。

一种是“答案回推法”。先让模型从知识块里找到最可能包含答案的候选句，再压缩成不改变语义的短句。然后，从答案反推：如果要得出这个结论，需要先知道什么？每一步反推都必须有原文依据，找不到依据就删掉或换组合方式。这样生成的链牢牢锚定在原文上，幻觉概率很低。我之所以推荐这种方法，是因为它的每一步都在“验证”，而不是“生成”。模型从最终答案往回找前提，比从问题往前推更容易控制质量。

另一种是“正推状态法”。让模型一句一句读文本，用一个状态变量记录“目前已经推出的结论”。每读完一句话，评估能否和当前状态产生关联，如果能，就生成一个新结论并更新状态。这种方法适合长文档和长程推理，但实现成本高，容易因为状态变量错乱导致链断掉。一般来说，普通知识库场景用回推法就够了；只有做复杂推理评测，才需要上状态法。

Prompt 里可以要求模型输出 JSON，结构大致是这样：

{ "question": "为什么该系统能提升成交转化？", "chain": [ { "step": 1, "evidence": "系统通过引入序列特征和用户实时行为信号", "conclusion": "候选集更精准" }, { "step": 2, "evidence": "候选集压缩到500，点击率提升3个百分点", "conclusion": "点击率提升，模型能更聚焦高潜内容" } ], "answer": "因为候选集精准→点击率提升→排序阶段获得更多正向样本→最终成交转化率提升1.2%" }

注意，chain 里每步的 conclusion 尽量是“新的信息”，不是重复原句，而是经过了一次语义压缩或推理。如果某一步 conclusion 只是把 evidence 又抄了一遍，那这条链的实际信息量就很低。

2.4 抽样校验闭环，别把烂数据混进语料

不论初抽模型多强，必须抽样。我建议每批生成完，按 10%~20% 做人工复核，重点看三件事：

• 问题是不是和文本强相关；
• chain 里的每一步能不能用给出的 evidence 解释；
• 最终答案能不能由 chain 推出来。

抽样通过率低于 70%，就说明 Prompt 或过滤阈值有问题，先不急着加量，回头调参。这个“生成—筛查—调整”的小闭环，是这套管线能不能长期使用的关键。很多人只关心生成速度和数量，忽略了抽样反馈，结果垃圾数据越积越多，后面清洗成本比重新生成还高。

3. 把抽取做扎实：模型选型、Prompt 写法与三重校验

3.1 模型选型：分层比单模型更重要

抽链条这个任务，不一定要上最强的模型。我建议分三层：

第一层初抽，用理解能力强、JSON 输出稳定的通用大模型，负责把问题、链条、答案生成出来；

第二层粗过滤，用小模型加规则，做格式检查、证据字符串匹配、余弦相似度检查，把明显不合格的样本直接丢掉；

第三层细校验，用一个专门做“逻辑连贯性”判定的模型，给链条打 0/1 标签。

分层的价值是省钱。要是每一条都让最强模型把所有环节做了，成本翻好几倍，而粗过滤环节其实能筛掉 30% 左右的垃圾样本，这些样本根本不需要强模型来看。资源紧的时候，可以先把初抽和粗过滤合并，但细校验不建议省。因为逻辑链数据最大的价值在“链”上，链坏了，答案再对也不能用。我见过不少团队用同一个大模型既生成又校验，结果模型自己对自己生成的内容天然好感度高，很多问题根本发现不了。换个更小的模型做校验，反而能挑出毛病。

3.2 Prompt 框架的细节写法

分享一个我自己改过很多遍的 Prompt 骨架。核心有四个区：

指令区：明确说“你是一个数据抽取器。下面是一段文档片段。请先理解所有事实，再生成问题、推理链和答案。禁止引用原文之外的背景知识。”

输出区：强制 JSON，字段名固定为 question、chain、answer。

示例区：给一个正例，再给一个反例。反例专门展示某模型把常识混进中间结论，并标注“该链条因第 2 步没有 evidence 被判定不合格”。

约束区：chain 中每一步必须包含 evidence 字段，且 evidence 必须能在原文片段中直接找到或高度对应；step 数量最多不超过 5 个；question 必须是该片段能回答的，禁止泛泛而谈。

为什么要给反例？我试过只给正例，模型很容易“照葫芦画瓢”，正例长什么样它就长什么样，完全不懂边界。给一个反例之后，它理解“不能干什么”的速度明显加快，生成质量提升很明显。

JSON 格式不要妥协。非 JSON 输出全算失败，重新抽样生成。看起来浪费，但后处理统一性好，批量重试也方便。如果在生产环境里跑，还可以加一层 JSON Schema 校验，把字段类型错误、缺字段的样本自动标记为失败。

3.3 三重校验法的具体做法

第一重是证据一致性。最简单的方式是字符匹配，看 evidence 是否在原文中出现；如果模型做了改写，至少要求证据中的关键实体、数字、术语和原句完全一致，否则判定不合格。数字是最容易暴露问题的：原文写“提升 3%”，模型只要写成“提升 5%”，哪怕语义再顺，也直接废掉。

第二重是逻辑闭环。把 chain 里的中间结论提取出来，让校验模型判断“前一步结论 + 新证据 → 后一步结论”是否成立。这个不要靠人肉看，做一个 0/1 分类器就行。实际做的时候，可以把“前一步结论”“新证据”“后一步结论”拼成一段文本，让分类模型判断语义上是否构成因果关系。

第三重是答案可推导。只基于 chain 的最后一条和整条链的汇聚信息，判断它能否自然地推出最终答案。这一步专门防“结论很对，但链条根本没有证明它”的现象。老实说，三重校验法最初是我为另一个项目改造出来的，用在逻辑链数据上意外地贴切。它最大的好处是把“数据质量”这种形容词变成了三个可执行步骤，出了问题能直接定位到是哪一重没过。

3.4 成本和速度怎么平衡

分享一个很实用的经验：不是所有文本都值得抽。

先做一个轻量级段落分类器，只保留包含“原因、影响、条件、步骤、对比”等触发词的段落进入抽取管线；纯描述、情绪表达、流程管理类文本直接跳过。这样能把成本降到三分之一以下。数据管线不是要把所有语料都榨干，而是要优先榨出最“有链”的语料。

另一个省钱技巧是缓存。同一个知识块在不同版本里经常只改了几个词，可以用内容哈希判断“改没改”，没变就直接复用上一版抽取结果，只对变更过的知识块重新抽，增量成本非常低。

4. 抽出来的逻辑链，在 Agent 侧怎么落地

4.1 做 few-shot 示例：让 Agent 模仿拆解节奏

最轻的使用方式，是把抽好的逻辑链直接塞进 Agent 的 System Prompt 里。不需要微调，花几十秒改一下提示词，效果就会变化。比如文档问答 Agent，如果 System Prompt 里放了两条高质量链条的参考，它在回答新问题时往往会先写“我会分三步来解决：先确认用户在问哪个模块，再匹配对应规则，最后给出分情况结论”。这个效果比直接告诉它“要一步步思考”好得多，因为模型是模仿出来的，不是被命令出来的。

需要注意：few-shot 里链条要覆盖不同题型，至少一条因果推导、一条对比决策，不要全是归纳总结，不然 Agent 会被带偏。我见过有人放了三条例题全是“列出三个步骤”的类型，结果 Agent 遇到因果问题也在那傻列步骤，根本不碰因果关系。

4.2 做 SFT 微调数据：思维模板化

如果要做指令微调（SFT），可以把逻辑链转成对话格式。用户提问作为 user 输入，Assistant 先输出一个“思考”字段，包含中间结论，再输出最终答案。我建议在训练时把“思考”和“答案”分开两个字段，或者至少用清晰的标记切分，这样后续想单独用答案或单独评测推理过程都方便，结构清晰、可扩展。

这里有个需要注意的点：训练样本里不要全部都是长链。如果 Agent 每次回答问题都输出五步推理，用户会疯。我一般按比例混入一部分“直接回答”样本，让模型学会判断什么时候该展开、什么时候该收敛。这个比例我习惯控制在长链样本占 30%~40%，其余是普通问答和短链，效果比较稳。

4.3 做过程奖励和评测集：把质量变成指标

如果团队在跑强化学习（RL），逻辑链数据是天然的过程奖励标注来源。把抽好的链条当作正样本，再通过交换步骤顺序、删除某一步等方式造一批负样本，拿去训练一个过程奖励模型（PRM），让模型对 Agent 每一步的中间质量打分。这样 RL 阶段不是只奖励最终结果，每一步都有信号，训练会稳定很多。

即使不做 RL，逻辑链数据也可以做成评测集。评测 Agent 时，不仅看最终答案对不对，还看生成的推理步骤能不能匹配参考链。这种评测方式更有诊断价值，因为它能告诉你模型是“答对了但思路偏”还是“思路正但表达不好”。我实际用下来，步骤匹配分数的波动比端到端准确率更能提前暴露问题，比如一次文档改版后，最终答案准确率没怎么掉，步骤匹配分掉了 15%，一查原来是隐形数据漂移。

4.4 数据规模和配比的经验

单领域内，先做 3000 到 5000 条逻辑链就足够看到明显变化。再多当然可以，但边际效应递减，而且如果没有做好问题类型配比，数据越多模型越“啰嗦”。

另一个建议是定期用新文档重新跑一遍抽取管线，让逻辑链语料跟产品迭代保持同步。Agent 吃到的推理知识如果长期不更新，回答质量会慢慢落后于文档版本，这一点容易被人忽视。做数据管线的人都知道，语料的新鲜度和语料的质量同样重要，甚至更新鲜的普通数据经常比老的高质量数据更管用。

5. 常见问题与排查技巧实录

5.1 模型把常识塞进推理链

这是遇到过最多的问题。表现是链条里的某一步听起来很合理，但原文里根本找不到对应证据。比如文档只写了“点击率提升”，模型却在中间结论里补了一句“因为用户更喜欢该产品”，这就是常识污染。

排查和对策：

• 生成时，在 Prompt 里强调“每一步结论必须能在当前段落或前文证据中直接对应；无法对应则删掉该步”；
• 粗过滤阶段，用文本匹配检查 evidence 与原文的相似度，低于阈值的直接丢弃；
• 细校验时，把这条链单独拎出来看，如果去掉常识那一步，链条仍然成立，就说明该步多余。

5.2 链条退化成为并列要点

表现是看起来有“第 1 步、第 2 步”的字样，但每步之间是并排关系，删掉任何一步都不影响最终推理结果。这种数据喂给模型，模型只会学会“列点”，学不会“递推”。

我的排查方法简单粗暴：做“消融测试”。删掉链条的任意一步，再重新看“从前一步能不能推出后一步”，如果不受影响，说明这条链不成立，直接废掉。用这种方法筛出来的链，递进关系基本是货真价实的。这个方法成本不高，但每批数据都能揪出一批“假链”，我建议把它加进自动化过滤的流程里。

5.3 问题分布严重偏斜

生成出来的问题大多是“这段讲了什么”，偶尔来一条“A 和 B 的区别”，完全没有“为什么”“如果……会怎样”。这会让 Agent 在因果推理类任务上几乎没进步。

对策是建立疑问词统计表，记录“为什么、如何、如果、区别、步骤、是否”等词的占比，低于预期时，就专门写一批 Prompt 去补抽对应类型。数据管线其实是个动态平衡的过程，一段时间不盯，分布就会飘。我一般会在生成任务里加入一个“类型”字段，让模型自己标注问题类型，后续按类型统计配额就方便了。

5.4 常用排查速查表

5.5 两个容易被忽略的工程细节

一个是标题路径要保留。抽取时带上文档标题路径，后续 Agent 回答问题时可以直接引用“来自哪个章节”。另一个是版本管理。逻辑链数据最好跟着文档版本走，记录生成时间、模型版本、Prompt 版本。这几个信息在排查“模型为什么忽然变傻”时非常有用。数据管线一旦跑起来，版本就是你的第一道排查线索，没有版本记录就只能从头猜。

我自己做这套流程时最大的感受是，真正拉开差距的不是“生成”环节，而是“判定”环节。把模型换成更强的版本，无非是多产出几条像样的链；但要是没有一套稳定判断“这条链到底行不行”的机制，数据量越大，垃圾越难收拾。三重校验、消融测试、问题类型配额，这些方法看着简单，用久了就会发现它们才是管线的地基。后续我打算把这套抽取逻辑做成一个自动质检服务，挂在文档更新流程后面，文档一变就重新抽一遍，让 Agent 的知识永远跟得上库。思路大致如此，具体的实现细节欢迎一起聊。