上一篇《企微、Agent平台与业务系统各管什么：读懂系统图》说到，系统图能把一条业务请求的责任边界画清楚。这一篇收窄到一个具体故障：知识问答。这是企业里最常见的第一批AI应用——制度、手册、FAQ全部入库，人人都来问。也是投诉最快的一批应用：问题问出去，答案引用了一段原文，却是错的。

最容易发生的一幕是这样的。车间计划员问AI助手："申请6000元的备件，要谁审批？"助手引用了一段制度原文作答，有出处、有页码、看起来很可靠。可答案用的是已经作废的旧规则。计划员拿着它去找班组长签字，被退回来，第二次又被退回来，然后他得出结论：这个AI不能信。

这类投诉到达FDE手里的形态，往往比现场更糟糕：一句"AI答错了"，没有问题原文，没有发生时间，没有提问人的账号，甚至说不清是哪次回答。所以倒查的第零步是复现——拿到问题原文、时间点和提问账号，用同样的条件重跑一次。复现不了的问题先登记在案，能复现的才进入检查。这一步省下的不是时间，是后面全部判断的可信度。

团队的第一反应往往是"模型不行"。这句话把四类完全不同的问题压成了一类：资料问题（该入库的没入库，或旧版本混在库里）；检索问题（正确的片段在库里，但没被找到，或被排在后面）；上下文问题（片段找到了，但没有进入最终交给模型的上下文）；生成问题（资料都对，模型没用好，答非所问或添油加醋）。统称"幻觉"会掩盖这四类问题的差别，也让人把力气花在错误的地方——最常见的错位，是资料和过程的问题，却一直在换模型、改提示词。

FDE在这里的工作不是成为检索算法工程师，而是沿资料进入、检索、上下文与回答四个环节逐步检查，用保存下来的证据判断错误发生在哪一段，再决定改哪里。这篇文章就讲这条倒查路径，以及怎样把"答案错"变成可区分、可修复的具体问题。

一次知识问答在系统里走过的路，比多数人印象里长。拆开看是七步：文件解析（把PDF、文档转成可处理的文本）→切分（按段落或长度切成片段）→索引（为片段建立向量与元数据）→检索（按问题相似度召回候选，并应用过滤条件）→重排（可选，把候选重新排序）→上下文（挑选片段拼进提示词，受长度限制）→回答（模型依据上下文生成答案和引用）。

每一步都可能出错，而且出错的形态不一样：解析可能丢页眉表格，切分可能把条款拦腰截断，索引可能停留在旧版本文件，检索可能漏掉正确片段，重排可能把旧的排到前面，上下文可能把召回的片段挤出去，回答可能忽略明明在场的依据。切分问题在候选列表里有典型签名：片段开头是半句话、结尾也是半句话——看到这种片段，先查切分配置，再谈其他。

倒查的意思是：从答案往回走，而不是从文件往前走。顺序固定。

第一步，看答案引用了什么。引用的片段是新版本还是旧版本？有没有引用？引用的内容能不能支持那句话？

第二步，看最终上下文里有什么。把这一次请求实际拼进提示词的片段完整取出来。正确答案需要的片段在不在里面？如果不在，问题不在模型——它根本没看到。

第三步，看检索候选里有什么。检索返回的前若干条候选，正确片段排在第几位？被过滤条件排除了，还是召回了但名次靠后？

第四步，看索引里有什么。正确片段到底入库了没有？入的是哪个版本？元数据里生效时间、状态、权限标记写的是什么？

这四步之所以要倒着走，是因为顺着走每一步都可能"看起来正常"：文件在库里，检索也返回了十条结果，模型也给出了带引用的回答。只有从答案回头，才知道该在哪一步停住。

实操里可以先用一个两问法快速分诊。

第一问：正确片段在不在最终上下文里？不在，问题在检索或拼装，往第二、三步走。

第二问：在，模型为什么不用？这才轮到生成环节。两个问题把"链路问题"和"模型问题"先分开，团队讨论就不会一上来就围绕换模型打转。

倒查需要的证据从哪里来？多数问答平台的管理后台都能导出调用日志，包含检索候选与最终上下文；没有日志能力的，用调试接口或"重跑脚本"补：同一问题、同一账号、同一过滤条件重放，逐项抓取候选列表、片段原文、上下文全文和回答。教学设定里我们把它整理成一个固定动作：问题发生当天就把五件套存档——问题原文、可读范围、候选及排序、最终上下文、回答与引用。日志通常有保留期，事后补抓常常已经来不及。

支撑倒查的是证据留存。问题出现的那一刻，下面这些东西必须还能取到：用户的问题原文、用户当时的可读范围、检索返回的候选及排序、每条候选的来源文件与版本、最终进入上下文的片段、模型的完整回答与引用。设计稿里把这个清单叫RAG检查表：文件、索引版、查询、过滤、片段、上下文、回答和引用。没有这份表，倒查就退化成猜。

一条是：检索不到，不一定是模型不聪明——原资料根本没入库，你去调重排参数没有用；另一条是：召回正确却没传给模型，你去补资料也没有用。

先定位断点，再动手改，这句话在RAG上比在多数系统上都值钱。

分别处理版本、召回与上下文问题

用一个贯穿的教学设定来走全过程。某制造企业的制度知识库中，备件申请审批规则有两个版本。R1是旧规则，2026年3月之前有效："单笔金额5000元（含）以下的备件申请，由班组长审批。"R2是现行规则，2026年6月发布："单笔金额8000元（含）以下的备件申请，由车间主任审批，申请单须注明用途。"两条都是合成教学内容，不代表任何真实企业制度。旧文件没有从库里删除——很多企业都保留旧版制度供审计追溯，问题出在没有给它打失效标记。

问题Q7："车间申请6000元的备件，需要谁审批？"按R2，答案是车间主任审批，且申请单须注明用途。

助手回答"由班组长审批"，引用了旧文件。倒查：第四步，索引里R2在，入库时间正确；第三步，重放Q7抓取检索候选，前十名里R1和R2都在，R1因为措辞与问题更相似（金额、审批、备件三个词都命中）排第二，R2排第五；第二步，上下文取前四条，只有R1进了上下文。断点定位：检索排序加上下文配额，把旧规则顶到了前面。

这里有一个前置检查不能省：先确认R2确实是现行版本、提问用户确实获准读取——版本有效期与权限是链路外的两个门，跳过它们，后面的定位会建立在错误前提上。修复方向不是改模型，而是给文件补上生效与失效时间的元数据，检索时默认过滤已失效版本；审计需要旧版的，走单独的"查历史版本"入口，并把每次历史查询记入审计。版本治理的要害正在于此：对象、规则和配置都会变，不登记版本，今天的结果就无法解释昨天的回答——三个月前R1还是对的，同一条回答从"正确"变成"错误"，中间系统一行代码都没改。

情况二：答案没有引用任何版本。

助手回答"一般由班组长或车间主任审批，建议咨询行政确认"。倒查：第三步，检索候选前三名里R2排第一；第二步，最终上下文里没有R2——同一次请求里另一份长文档占了大部分长度预算，R2片段在拼装时被挤掉了。断点定位：上下文截断与拼装策略。修复方向是调整各来源的片段配额与长度预算，让规则类短片段有保底名额，或者对超长文档先压缩再拼装。

截断的机制值得多说一句，因为它违反直觉。拼装通常按来源依次取片段，直到长度预算用尽；排在前面的来源吃掉预算，后面的来源即使候选排名第一也进不去。所以"检索第一却没进上下文"不是玄学，是预算分配问题。验证方法很直接：把那一次请求的上下文全文导出来数一数——R2的片段确实不在，长文档的片段占了大头，证据就齐了。

两种情况在用户端的表现几乎一样——"答案错了"，但断点、修法和回归重点完全不同。这就是为什么诊断记录要逐项写清。这张记录长这样：

最后两行值得展开。修复后的验收不是"答对了Q7"就完事，而是答案要引用正确版本、说明适用范围——8000元这条线以内由车间主任批，那超过8000元怎么办？如果库里有更高金额的条款就引用它；如果没有，正确行为是回答"该情形的审批依据未收录"，而不是替企业编一条规则出来。无依据时不补造，这是知识问答应用的底线行为，也应该是验收用例的一部分。

验收还有一层容易被忽略：修复动作本身要回归。给文件加失效过滤，会不会把审计需要的历史查询也挡掉？调整长度预算，会不会让另一个来源的综合题丢片段？改一处、验全局，这个习惯在第12篇的系统图里讲过，在RAG场景同样成立。

单次修复之后，怎样知道没有改坏别的地方？靠一套能区分失败类型的测试样本。样本设计的标准不是覆盖多少问题，而是：每类常见失败至少有一个样本能把它单独暴露出来。

同一个问题，在新旧规则下答案不同。Q7就是：6000元在R1下超限（须上报）、在R2下由车间主任审批，一个样本同时压住"检索到旧版"和"用错版本作答"两种失败。构造这类样本的前提是库里确实同时存在新旧版本——这恰恰是真实知识库的常态。

问一个库里明确没有的问题，期望回答是"依据未收录"并说明查过哪里。这类样本防的是补造规则：模型在没找到依据时，倾向用通识把话圆上，而通识在具体企业制度上经常是错的。

提问用户无权读取某份文件时，期望行为是拒答或降级回答，而不是把内容吐出来。这里有个容易被误解的点：元数据筛选能帮助范围检索，但不等于权限控制——过滤器挡住了片段进上下文，未必挡得住索引阶段的暴露，更替代不了来源系统本身的权限校验。权限要在检索层和来源系统两边核验，不能只让模型"承诺不说"。

第四类，跨片段综合样本（可选进阶）。

答案需要拼两段才能完整，比如"金额线"和"用途填写要求"分在两处。这类样本压的是切分与拼装——条款被拦腰截断的问题，只有综合题能暴露出来。

样本数量不必求多。教学建议是每类三到五个起步，跟着失败台账滚动扩充：线上每出现一类没见过的失败，就补一个样本进对应类别。一个二十条的样本集，只要分类清楚，比一百条不分类型的"问答题库"更能说明问题。

每个样本的记录格式与RAG检查表对齐：查询、期望依据（哪份文件哪个版本哪一段）、期望回答要点、期望行为（引用还是拒答）。期望依据写得越具体，失败时越容易分类：依据拿错了是版本问题，依据没进上下文是拼装问题，依据在场但答案偏离是生成问题。

两个操作问题决定样本集的成色。一是期望答案由谁写：期望依据应由业务规则负责人确认——哪条规则现行、适用范围到哪里，这是业务知识，FDE不能替他答；期望行为（引用、拒答、降级）由FDE按应用定位写。二是样本怎么保持新鲜：规则一改版，版本敏感性样本必须跟着更新，否则样本在检验一个已经不存在的世界；样本集自己也该有版本号和变更记录，就像对待一份受管理的配置。

回归的结果也不要只看对错题数。把每次失败按四类归档计数——版本错误、召回缺失、上下文缺失、生成偏离——改进是否有效，看的是各类计数的变化，而不是单题命运。这个分类台账还有个副产品：几轮之后你会发现失败集中在哪一类，那就是下一个该投入的地方。

还有一条纪律：调试用的样本和验收用的评测集要分开。修复过程中反复跑的那批题，会不知不觉地朝着"过拟合调试题"的方向改；声称改进，必须换一批没参与调试的题来验。这与做原型验证的思路一致——下一篇会专门讲。

什么时候应该改检索之外的地方

倒查走到头，如果四步证据都干净：资料正确入库、版本正确、权限正确、正确片段进了上下文、排在显眼位置，答案仍然错——这时才轮到生成环节。

改提示词是第一选择：明确要求"只依据提供的片段回答，找不到就说明"，对多数生成偏离有效。

换更强或更合适的模型是第二选择。微调是最后的选择，前提是这个任务足够稳定、有足量的合格样本，而且前面几类问题已经排除——在断点没定位清楚之前上微调，等于用更贵的方法重演同一个错误。比较这三条路线时，用同一批任务样本、按错误分类看效果，并且每条路线都要写清楚它不解决什么：提示词管不住检索排序，微调同步不了每周更新的制度。

其一，召回到相似文字不等于规则适用。

检索按相似度工作，"金额""审批"这些词都命中的片段，未必是管辖当前情形的条款；把全部文档塞进提示词也不能解决这个问题，只会让新旧冲突的段落同时在场，模型挑哪段更像运气。适用范围的判断，要么靠检索前的元数据过滤，要么靠规则结构化——这正是第10篇讲本体时说"把规则变成可检查的对象"的原因。

其二，RAG解决的是资料使用，不能替代动作授权或业务状态检查。

知道"8000元以下由车间主任批"，不等于知道眼前这张申请单当前是什么状态、这位主任今天是否在岗、这笔金额是否触发额外审批。资料、状态、授权是三件事，检索做得再顺也只覆盖第一件。

本篇只深入知识检索这一类故障。跨系统的一般定位方法——当问题可能出在飞书、Agent平台、连接器或业务系统的任何一段时怎样圈定范围——留到后面讨论。下一篇先讲另一件事：想法太多、证据太少的时候，FDE怎样用最小原型把一个判断验证掉。

知识库已建好，答案仍然错：FDE怎样检查RAG

副总裁

架构设计

知识问答AI应用常因引用失效规则而答错，核心症结不在模型而在RAG链路。本文详解倒查法：从答案回溯检查引用、上下文、检索候选与索引，区分版本、召回、上下文及生成四类问题。提供诊断记录模板与分类测试样本设计，强调版本元数据、权限校验及无依据拒答底线，以证据驱动修复而非盲目调参。

Agent

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

知识库已建好，答案仍然错：FDE怎样检查RAG

知识库已建好，答案仍然错：FDE怎样检查RAG

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐