FDE岗位实务指南 · 第13篇引用了一段话为何答案仍错上一篇《企微、Agent平台与业务系统各管什么读懂系统图》说到系统图能把一条业务请求的责任边界画清楚。这一篇收窄到一个具体故障知识问答。这是企业里最常见的第一批AI应用——制度、手册、FAQ全部入库人人都来问。也是投诉最快的一批应用问题问出去答案引用了一段原文却是错的。最容易发生的一幕是这样的。车间计划员问AI助手申请6000元的备件要谁审批助手引用了一段制度原文作答有出处、有页码、看起来很可靠。可答案用的是已经作废的旧规则。计划员拿着它去找班组长签字被退回来第二次又被退回来然后他得出结论这个AI不能信。这类投诉到达FDE手里的形态往往比现场更糟糕一句AI答错了没有问题原文没有发生时间没有提问人的账号甚至说不清是哪次回答。所以倒查的第零步是复现——拿到问题原文、时间点和提问账号用同样的条件重跑一次。复现不了的问题先登记在案能复现的才进入检查。这一步省下的不是时间是后面全部判断的可信度。团队的第一反应往往是模型不行。这句话把四类完全不同的问题压成了一类资料问题该入库的没入库或旧版本混在库里检索问题正确的片段在库里但没被找到或被排在后面上下文问题片段找到了但没有进入最终交给模型的上下文生成问题资料都对模型没用好答非所问或添油加醋。统称幻觉会掩盖这四类问题的差别也让人把力气花在错误的地方——最常见的错位是资料和过程的问题却一直在换模型、改提示词。FDE在这里的工作不是成为检索算法工程师而是沿资料进入、检索、上下文与回答四个环节逐步检查用保存下来的证据判断错误发生在哪一段再决定改哪里。这篇文章就讲这条倒查路径以及怎样把答案错变成可区分、可修复的具体问题。把答案沿检索过程倒查一次知识问答在系统里走过的路比多数人印象里长。拆开看是七步文件解析把PDF、文档转成可处理的文本→切分按段落或长度切成片段→索引为片段建立向量与元数据→检索按问题相似度召回候选并应用过滤条件→重排可选把候选重新排序→上下文挑选片段拼进提示词受长度限制→回答模型依据上下文生成答案和引用。每一步都可能出错而且出错的形态不一样解析可能丢页眉表格切分可能把条款拦腰截断索引可能停留在旧版本文件检索可能漏掉正确片段重排可能把旧的排到前面上下文可能把召回的片段挤出去回答可能忽略明明在场的依据。切分问题在候选列表里有典型签名片段开头是半句话、结尾也是半句话——看到这种片段先查切分配置再谈其他。倒查的意思是从答案往回走而不是从文件往前走。顺序固定。第一步看答案引用了什么。引用的片段是新版本还是旧版本有没有引用引用的内容能不能支持那句话第二步看最终上下文里有什么。把这一次请求实际拼进提示词的片段完整取出来。正确答案需要的片段在不在里面如果不在问题不在模型——它根本没看到。第三步看检索候选里有什么。检索返回的前若干条候选正确片段排在第几位被过滤条件排除了还是召回了但名次靠后第四步看索引里有什么。正确片段到底入库了没有入的是哪个版本元数据里生效时间、状态、权限标记写的是什么这四步之所以要倒着走是因为顺着走每一步都可能看起来正常文件在库里检索也返回了十条结果模型也给出了带引用的回答。只有从答案回头才知道该在哪一步停住。实操里可以先用一个两问法快速分诊。第一问正确片段在不在最终上下文里不在问题在检索或拼装往第二、三步走。第二问在模型为什么不用这才轮到生成环节。两个问题把链路问题和模型问题先分开团队讨论就不会一上来就围绕换模型打转。倒查需要的证据从哪里来多数问答平台的管理后台都能导出调用日志包含检索候选与最终上下文没有日志能力的用调试接口或重跑脚本补同一问题、同一账号、同一过滤条件重放逐项抓取候选列表、片段原文、上下文全文和回答。教学设定里我们把它整理成一个固定动作问题发生当天就把五件套存档——问题原文、可读范围、候选及排序、最终上下文、回答与引用。日志通常有保留期事后补抓常常已经来不及。支撑倒查的是证据留存。问题出现的那一刻下面这些东西必须还能取到用户的问题原文、用户当时的可读范围、检索返回的候选及排序、每条候选的来源文件与版本、最终进入上下文的片段、模型的完整回答与引用。设计稿里把这个清单叫RAG检查表文件、索引版、查询、过滤、片段、上下文、回答和引用。没有这份表倒查就退化成猜。有两条经验值得先记下。一条是检索不到不一定是模型不聪明——原资料根本没入库你去调重排参数没有用另一条是召回正确却没传给模型你去补资料也没有用。先定位断点再动手改这句话在RAG上比在多数系统上都值钱。分别处理版本、召回与上下文问题用一个贯穿的教学设定来走全过程。某制造企业的制度知识库中备件申请审批规则有两个版本。R1是旧规则2026年3月之前有效单笔金额5000元含以下的备件申请由班组长审批。R2是现行规则2026年6月发布单笔金额8000元含以下的备件申请由车间主任审批申请单须注明用途。两条都是合成教学内容不代表任何真实企业制度。旧文件没有从库里删除——很多企业都保留旧版制度供审计追溯问题出在没有给它打失效标记。问题Q7车间申请6000元的备件需要谁审批按R2答案是车间主任审批且申请单须注明用途。情况一答案引用了R1。助手回答由班组长审批引用了旧文件。倒查第四步索引里R2在入库时间正确第三步重放Q7抓取检索候选前十名里R1和R2都在R1因为措辞与问题更相似金额、审批、备件三个词都命中排第二R2排第五第二步上下文取前四条只有R1进了上下文。断点定位检索排序加上下文配额把旧规则顶到了前面。这里有一个前置检查不能省先确认R2确实是现行版本、提问用户确实获准读取——版本有效期与权限是链路外的两个门跳过它们后面的定位会建立在错误前提上。修复方向不是改模型而是给文件补上生效与失效时间的元数据检索时默认过滤已失效版本审计需要旧版的走单独的查历史版本入口并把每次历史查询记入审计。版本治理的要害正在于此对象、规则和配置都会变不登记版本今天的结果就无法解释昨天的回答——三个月前R1还是对的同一条回答从正确变成错误中间系统一行代码都没改。情况二答案没有引用任何版本。助手回答一般由班组长或车间主任审批建议咨询行政确认。倒查第三步检索候选前三名里R2排第一第二步最终上下文里没有R2——同一次请求里另一份长文档占了大部分长度预算R2片段在拼装时被挤掉了。断点定位上下文截断与拼装策略。修复方向是调整各来源的片段配额与长度预算让规则类短片段有保底名额或者对超长文档先压缩再拼装。截断的机制值得多说一句因为它违反直觉。拼装通常按来源依次取片段直到长度预算用尽排在前面的来源吃掉预算后面的来源即使候选排名第一也进不去。所以检索第一却没进上下文不是玄学是预算分配问题。验证方法很直接把那一次请求的上下文全文导出来数一数——R2的片段确实不在长文档的片段占了大头证据就齐了。两种情况在用户端的表现几乎一样——答案错了但断点、修法和回归重点完全不同。这就是为什么诊断记录要逐项写清。这张记录长这样诊断项记录内容问题Q7车间申请6000元的备件需要谁审批版本与权限R2现行有效提问用户获准读取已核检索候选R2在候选中排名第一位最终上下文R2缺失被长文档挤出截断/拼装问题先检查上下文长度预算与拼装顺序而非模型与提示词修复后行为答案引用R2说明适用范围为8000元含以下并提示须注明用途无依据查询知识库未收录的情形回答依据未收录不补造规则最后两行值得展开。修复后的验收不是答对了Q7就完事而是答案要引用正确版本、说明适用范围——8000元这条线以内由车间主任批那超过8000元怎么办如果库里有更高金额的条款就引用它如果没有正确行为是回答该情形的审批依据未收录而不是替企业编一条规则出来。无依据时不补造这是知识问答应用的底线行为也应该是验收用例的一部分。验收还有一层容易被忽略修复动作本身要回归。给文件加失效过滤会不会把审计需要的历史查询也挡掉调整长度预算会不会让另一个来源的综合题丢片段改一处、验全局这个习惯在第12篇的系统图里讲过在RAG场景同样成立。建立能区分问题的测试样本单次修复之后怎样知道没有改坏别的地方靠一套能区分失败类型的测试样本。样本设计的标准不是覆盖多少问题而是每类常见失败至少有一个样本能把它单独暴露出来。第一类版本敏感性样本。同一个问题在新旧规则下答案不同。Q7就是6000元在R1下超限须上报、在R2下由车间主任审批一个样本同时压住检索到旧版和用错版本作答两种失败。构造这类样本的前提是库里确实同时存在新旧版本——这恰恰是真实知识库的常态。第二类无依据样本。问一个库里明确没有的问题期望回答是依据未收录并说明查过哪里。这类样本防的是补造规则模型在没找到依据时倾向用通识把话圆上而通识在具体企业制度上经常是错的。第三类无权限样本。提问用户无权读取某份文件时期望行为是拒答或降级回答而不是把内容吐出来。这里有个容易被误解的点元数据筛选能帮助范围检索但不等于权限控制——过滤器挡住了片段进上下文未必挡得住索引阶段的暴露更替代不了来源系统本身的权限校验。权限要在检索层和来源系统两边核验不能只让模型承诺不说。第四类跨片段综合样本可选进阶。答案需要拼两段才能完整比如金额线和用途填写要求分在两处。这类样本压的是切分与拼装——条款被拦腰截断的问题只有综合题能暴露出来。样本数量不必求多。教学建议是每类三到五个起步跟着失败台账滚动扩充线上每出现一类没见过的失败就补一个样本进对应类别。一个二十条的样本集只要分类清楚比一百条不分类型的问答题库更能说明问题。每个样本的记录格式与RAG检查表对齐查询、期望依据哪份文件哪个版本哪一段、期望回答要点、期望行为引用还是拒答。期望依据写得越具体失败时越容易分类依据拿错了是版本问题依据没进上下文是拼装问题依据在场但答案偏离是生成问题。两个操作问题决定样本集的成色。一是期望答案由谁写期望依据应由业务规则负责人确认——哪条规则现行、适用范围到哪里这是业务知识FDE不能替他答期望行为引用、拒答、降级由FDE按应用定位写。二是样本怎么保持新鲜规则一改版版本敏感性样本必须跟着更新否则样本在检验一个已经不存在的世界样本集自己也该有版本号和变更记录就像对待一份受管理的配置。回归的结果也不要只看对错题数。把每次失败按四类归档计数——版本错误、召回缺失、上下文缺失、生成偏离——改进是否有效看的是各类计数的变化而不是单题命运。这个分类台账还有个副产品几轮之后你会发现失败集中在哪一类那就是下一个该投入的地方。还有一条纪律调试用的样本和验收用的评测集要分开。修复过程中反复跑的那批题会不知不觉地朝着过拟合调试题的方向改声称改进必须换一批没参与调试的题来验。这与做原型验证的思路一致——下一篇会专门讲。什么时候应该改检索之外的地方倒查走到头如果四步证据都干净资料正确入库、版本正确、权限正确、正确片段进了上下文、排在显眼位置答案仍然错——这时才轮到生成环节。改提示词是第一选择明确要求只依据提供的片段回答找不到就说明对多数生成偏离有效。换更强或更合适的模型是第二选择。微调是最后的选择前提是这个任务足够稳定、有足量的合格样本而且前面几类问题已经排除——在断点没定位清楚之前上微调等于用更贵的方法重演同一个错误。比较这三条路线时用同一批任务样本、按错误分类看效果并且每条路线都要写清楚它不解决什么提示词管不住检索排序微调同步不了每周更新的制度。还有两条边界要守住。其一召回到相似文字不等于规则适用。检索按相似度工作金额审批这些词都命中的片段未必是管辖当前情形的条款把全部文档塞进提示词也不能解决这个问题只会让新旧冲突的段落同时在场模型挑哪段更像运气。适用范围的判断要么靠检索前的元数据过滤要么靠规则结构化——这正是第10篇讲本体时说把规则变成可检查的对象的原因。其二RAG解决的是资料使用不能替代动作授权或业务状态检查。知道8000元以下由车间主任批不等于知道眼前这张申请单当前是什么状态、这位主任今天是否在岗、这笔金额是否触发额外审批。资料、状态、授权是三件事检索做得再顺也只覆盖第一件。本篇只深入知识检索这一类故障。跨系统的一般定位方法——当问题可能出在飞书、Agent平台、连接器或业务系统的任何一段时怎样圈定范围——留到后面讨论。下一篇先讲另一件事想法太多、证据太少的时候FDE怎样用最小原型把一个判断验证掉