大模型为什么会答错：从生成机制到 RAG 的可信回答证据链

大模型的回答看起来像一个结果，实际上是问题表达、证据检索、上下文工程、生成约束与结果验证共同作用的产物。本文用一个教学模拟案例拆解这条链路，并给出可直接用于排查问题的方法。

一、语言流畅，为什么仍然可能答错

先看一个明确标注的教学模拟案例。

一名员工问企业问答机器人：“出差住宿可以报销多少钱？”机器人迅速回答：“每晚 600 元”，措辞完整，还附上了一条制度引用。员工据此预订酒店，报销时却被告知标准不符。进一步排查发现，机器人引用的是已经失效的旧制度；新制度按照城市、职级和出差时间设置不同标准，而这些条件既没有在提问时说明，也没有在回答前追问。

这个案例没有使用真实企业名称、制度或项目数据，只用于说明问题。它揭示了一种常见错觉：只要答案通顺、语气确定、页面上还有引用，回答就值得相信。但“能回答”与“可信”之间至少隔着三个问题：答案有没有依据，依据是否仍然有效，以及依据是否适用于当前用户。

很多团队遇到错误回答时，第一反应是换更大的模型、写更长的 Prompt，或者把更多资料塞进上下文。这些方法有时有效，却也可能完全偏离病因。模型只是链路中的一环。资料版本错误时，更强的模型仍会读到旧制度；问题缺少城市与职级时，更长的 Prompt 也无法凭空补齐事实；权限过滤出错时，提高检索召回反而可能让不该出现的资料进入答案。

因此，可信回答不是由模型单独产生的，而是由问题定义、证据获取、上下文工程、受约束生成和结果验证共同构成的一条证据链。 只看最终文字，就像只看事故现场而不检查上游流程；要提高可信度，必须知道证据从哪里来、经过了什么处理、最终结论由哪段原文支持。

二、幻觉并不是偶然故障

要理解模型为什么会一本正经地答错，不必先掌握整部人工智能发展史，只需要看懂它如何生成下一段文字。

输入文本首先被拆成 Token，也就是模型能够处理的文本单元，再转换成编号(Token ID)。Embedding 将这些编号映射为语义向量，并加入位置信息，让模型既能处理内容，也能区分词语顺序。向量序列进入 Transformer，多层注意力计算让不同位置的信息彼此关联，最终形成用于预测下一个 Token 的隐藏状态。这个状态再被映射为覆盖整个词表的 Logits，也就是各候选 Token 的分数。

解码策略会根据这些分数选择一个 Token，把它追加到已有序列，再继续预测下一个。循环不断进行，直到生成终止符或满足其他停止条件。用户看到的完整回答，就是这一连串概率选择逐步累积的结果。

这里最关键的区别是：模型得到的是“下一个 Token 如何接续更可能”的分布，而不是从事实数据库中取出的唯一答案。训练让模型学会大量语言模式、概念关系和表达方式，因此它可以把一句话说得非常像正确答案；但生成过程本身并没有自动执行“这条制度是否最新”“这个数字是否适用于该员工”“引用是否真正支撑结论”等核验。

换句话说，模型的原生目标是生成最可能接续的内容，不是自动验证这句话是否有可靠证据。 流畅性主要来自语言模式，事实性则需要应用系统额外保证。模型不确定时仍可能继续生成，是因为“继续接话”符合生成任务，而“暂停、追问或拒答”通常需要系统明确提供触发条件。

这并不意味着所有错误都应笼统称为“模型幻觉”。如果正确制度根本没有进入知识库，问题首先是知识覆盖；如果制度存在但没被检索到，问题在召回；如果检索到了正确片段，模型却脱离片段扩写，才更接近生成忠实度问题。把所有错误都归咎于模型，会让团队在错误的层级上反复调参。

三、可信回答的五段证据链

一条可信回答链路，可以拆成五个连续但职责不同的环节。

问题定义：先确认用户真正想问什么

用户输入往往不是一条完整需求。“能报多少”缺少城市、职级、日期和费用类型；多轮对话里的“那北京呢”还依赖上一轮语境。系统需要识别指代、时间和适用范围，决定当前信息是否足以回答。如果缺失条件会改变结论，应先追问，而不是让模型选择一个看似合理的默认值。

问题定义不是把原句机械扩写，而是形成可独立理解、可用于检索的查询。好的查询既保留用户意图，也明确必要边界。例如，把“那北京呢”改写为“2026 年某职级员工前往北京出差时，住宿报销标准是多少”，检索系统才知道它究竟要找什么。年份与职级仍未知时，系统应保留未知并追问，不能擅自补造。

证据获取：找到完整、有效且可用的资料

证据不只是“语义相似的文本”。企业场景至少还要检查来源权威性、制度版本、有效时间与用户权限。旧制度可能与问题高度相似，却已经失效；新制度可能存在于扫描表格中，却因解析失败没有进入索引；某份管理层规则可能内容正确，却不允许普通员工检索。

因此，检索系统不仅要召回，还要过滤、重排和做权限校验。高召回率意味着相关资料更不容易漏掉，高精度意味着返回内容更少被噪声污染。两者都重要，但不能以绕过权限或忽略版本为代价。

上下文组织：只给模型当前真正需要的信息

检索到资料不等于模型已经得到良好证据。系统还要决定放入哪些片段、如何排序、是否补充标题和来源，以及适用条件是否与数字一起出现。上下文过少会缺证据，过多则会引入冲突和干扰；同一制度的新旧版本同时出现，模型可能把不同段落拼成一个不存在的规则。

上下文工程追求的不是“多”，而是“相关、完整、可理解”。关键条件应靠近结论，来源与版本信息应随片段一起传入，彼此冲突的材料应显式标记，而不是把判断压力全部留给模型。

受约束生成：让模型依据证据回答

生成阶段要明确回答边界：只根据提供的证据作答；关键结论附来源；证据不足或冲突时说明无法确认；缺少必要条件时先追问。这里的目标不是让语言变得保守，而是让确定程度与证据强度匹配。

Prompt 可以规定角色、目标、格式和拒答规则，却不能把不存在的事实写出来。证据缺失时，即使重复强调“准确回答”，模型也只能在已有模式中猜测。真正有效的约束必须与证据状态联动，例如检索无结果时进入澄清或拒答分支，而不是仍然要求生成完整答案。

结果验证：确认答案、证据和业务结果都成立

验证不能只问“最终答案对不对”。还要分别检查正确资料是否被召回、回答是否忠于证据、关键结论是否正确、引用是否真正支持结论，以及呈现形式是否符合业务要求。高风险问题还需要人工复核和操作留痕。

这五段不是一个漂亮的流程图，而是一套责任边界：问题不清要回到问题定义，资料缺失要回到知识治理，证据杂乱要优化检索与上下文，证据充分但回答偏离才重点处理生成，线上效果异常则要检查评测集与真实流量之间的差异。

四、上下文工程：决定模型此刻看见什么

上下文工程可以理解为系统设计“模型此刻需要看见什么”。它不是一种提示词技巧，而是 Prompt、RAG、Tool 与 Memory 的组合，每个模块解决不同问题。

• Prompt：定义任务目标、背景、角色、受众、样例、约束与输出格式。它告诉模型如何完成任务、哪些边界不能越过。
• RAG：检索并补充回答所需的外部知识。它适合提供企业制度、产品文档、知识手册等相对稳定但可能更新的事实依据。
• Tool：获取实时信息、执行计算或改变外部状态。库存、订单状态、当前汇率等动态信息，应通过工具查询，而不是期待模型参数记住。
• Memory：建立长短期记忆，使系统能够在连续对话中理解历史上下文。它保存有价值的会话状态和跨会话经验，但也要控制过期、错误与隐私信息。

四者既协同，也不能相互替代。Prompt 能约束回答，却不能补充缺失事实；RAG 能提供制度文本，却不适合承担实时订单查询；Tool 能返回当前状态，却不会自动理解长期偏好；Memory 能保留历史，但历史经验不是权威知识来源。

尤其需要注意，历史消息不等于长期记忆。短对话里，应用可以把此前消息重新放入当前请求，让模型理解“它”“那里”等指代；随着对话增长，全部历史会增加成本和干扰，系统需要截断、摘要或抽取关键事实。长期记忆则通常经过选择、存储与调用，不能把每一句聊天原样永久保存。

上下文也不是越长越可靠。把几十份制度全部放入请求，会增加版本冲突、注意力稀释与权限暴露风险。更合理的目标是：用最少但足够的内容支撑当前结论，并让模型清楚哪些内容是事实证据、哪些只是回答要求。

五、RAG 不是“接一个向量数据库”

RAG，即检索增强生成，核心是用户提问后先从外部知识中找到相关片段，再把问题和证据一起交给模型。它不需要为每次知识更新重新训练模型，而是在当前请求中补充依据。但一个可用的 RAG 系统远不止向量数据库，至少包含建立索引与检索生成两个阶段。

第一阶段：建立索引

建立索引决定“库里有什么”。系统先从 PDF、Markdown、网页或数据库中解析正文、标题和元数据，再把长文档切成适合检索的 Chunk。Embedding 模型把片段转换为语义向量，最后将向量、原文、来源、版本和权限标签一起保存。

文档解析常被低估。扫描件、复杂表格、页眉页脚和跨页段落，都可能让“文件已上传”与“知识已可用”成为两件事。索引还需要版本治理：新制度生效后，旧制度是删除、降权还是保留用于历史查询，应由业务规则决定，不能只依赖语义相似度。

切片也不是寻找一个通用的固定数字。片段过大，主题混杂、定位不准；片段过小，条件、结论与例外容易被拆开。合理策略应根据文档结构与问题类型设计：标题可作为层级信息随片段保留，表格可按语义行列重组，制度条款需要尽量保持“适用条件—规则—例外”的完整性。切片本质上是在完整性与定位精度之间取舍。

第二阶段：检索与生成

用户问题先被改写为适合独立检索的查询，再转成向量；系统根据语义相似度召回候选片段，随后通过标签过滤、Top-K、重排序和权限校验筛选证据。最后才把问题、证据与回答要求组装成上下文，交给大模型生成答案。

这里有三个容易忽略的判断。

第一，建立索引决定“库里有什么”，问题改写决定“系统在找什么”。多轮对话中的“那北京呢”如果直接向量化，检索系统不知道它在比较住宿标准、交通费用还是天气。系统需要结合上一轮把它改写为独立查询；必要条件仍缺失时，应先追问而非自行补齐。

第二，召回不是终点。语义相似只说明文字含义接近，不代表资料权威、最新、完整或有权限使用。过滤负责用部门、类型、时间等标签缩小范围，重排序负责让更符合当前问题的片段靠前，权限校验则必须在证据进入上下文之前完成。

第三，引用存在不代表答案可信。引用可能只是“相关”，却没有支持答案中的数字、因果或适用范围。验收时应把关键结论拆开，逐项确认能够定位到支持它的原文；如果原文只支持部分结论，回答就应降低确定性或说明尚无法确认。

六、错误答案应该如何定位

发现错误后，最有效的做法不是同时改模型、Prompt、切片和 Top-K，而是先根据现象定位最可能的层级，再做单变量验证。

Recall 关注相关证据有没有被找回，Precision 关注找回的内容中有多少真正有用。Faithfulness 关注回答是否忠于给定证据，Correctness 关注答案本身是否正确。不同评测框架可能使用不同名称、定义与计算方式，不能把所有指标都统一说成 Ragas 指标，也不能仅凭一个总分判断系统哪里出了问题。

评测集同样决定结论是否可靠。只有标准问法和常见问题，可能让离线结果很好看，却覆盖不了线上省略表达、多轮指代、错别字、冲突资料、无答案问题、越权请求与过期制度。评测集应同时包含真实问题、边界问题与对抗问题，并保存期望证据、允许的回答范围和应当拒答的条件。

优化时最好固定一组评测集做回归。调整切片后，先观察召回与证据完整性；调整重排序后，检查正确片段的位置与噪声；调整 Prompt 或模型后，检查忠实度、引用和拒答。一次改变多个变量，即使总分上升，也很难知道真正有效的改动是什么，更难在结果下降时回滚。

七、从“回答正确”走向“系统可信”

单次回答正确只是结果，系统可信还意味着过程可解释、风险可控制、错误可定位。上线前至少可以检查以下问题：

• 资料是否有明确负责人、版本、生效时间与失效时间？
• 文档上传后，正文、表格、标题和元数据是否真正解析成功？
• 用户是否只能检索自己有权限查看的内容？
• 关键条件缺失时，系统会追问，还是直接猜测？
• 找不到依据或证据冲突时，系统是否明确说“无法确认”？
• 每个关键结论是否都能定位到真正支持它的原文？
• 高风险问题是否进入人工复核，而不是自动执行？
• 修改切片、Prompt、检索配置或模型后，是否使用同一评测集回归？
• 技术指标是否与解决率、转人工率、响应时间和用户反馈连接？

这些检查项背后是一种产品观念的变化：目标不是让机器人显得无所不知，而是建立恰当的确定性。低风险且证据充分的问题，可以直接回答；条件缺失时应该追问；证据不足时应该说明无法确认；涉及高风险决策或外部动作时，则需要人工审批。拒绝猜测不是能力不足，而是可靠系统应具备的边界感。

证据链也让团队分工更清楚。业务负责人治理资料与规则，数据和算法团队负责解析、检索与评测，产品团队定义交互、追问、引用和人工兜底，安全团队控制权限与审计，模型负责在给定证据和约束下完成理解与表达。任何一方单独优化，都无法替代整条链路的协作。

小结

真正可靠的大模型应用，不是让模型任何时候都有答案，而是让系统知道证据从哪里来、何时应该追问、何时必须拒绝猜测，以及回答错误时应该回到哪一层修复。

本文由 @Grace 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于 CC0 协议。