已经接了大模型 API，但答得不准、还会乱编，问题通常出在哪？

先不要急着换模型：把错误拆成知识源、检索、上下文、生成规则和业务接口五层，用同一批问题逐层定位，才能知道“乱编”发生在哪里。

“答案不准”至少包含四种不同故障：资料本身没有答案；系统没找到正确资料；正确资料进入上下文但模型没有忠实使用；答案正确却调用了错误订单或用户数据。它们的修复方法完全不同。只调整提示词或换更大的模型，可能让演示看起来改善，却掩盖版本、权限和检索问题。

在确定模型、数据与上线边界时，还可以对照 AI 应用上线后准确率不达标怎么办？谁来持续调优？ 和 专业长文档密集型业务如何用 AI 提升处理效率？；这些内容补充了需要放在同一项决策中考虑的上下文。

从错误表现反查故障层

表现	首先检查	可复跑测试	常见修复
回答使用旧价格或旧政策	知识源与版本	手工核对标准答案和生效范围	下线旧版、增加负责人和失效时间
明明有文档却说不知道	解析、切分、索引与检索	正确片段是否进入 top-k	修复 OCR、标题元数据、混合检索或重排
找到片段仍编造额外事实	上下文与生成指令	逐句核对答案是否被片段支持	缩短上下文、要求引用、证据不足则拒答
多轮后张冠李戴	会话状态与身份	重放同一轮次和用户切换	分离会话、减少无关历史、重新确认对象
查错订单或重复执行	工具参数、权限与幂等	沙箱检查参数和回执	服务端鉴权、确认页、幂等键与回滚

第一步先建立可复跑的错误病例集

从生产记录挑出能覆盖主要错误表现、业务类别和高风险后果的失败对话，保存当时的用户问题、知识版本、检索结果、完整上下文、模型与提示词版本、工具参数和最终答案。病例数量要随着新故障持续增加，起始规模以能够形成稳定故障分类并复现主要问题为准。先由业务负责人写明可接受答案、必须包含的事实和严重错误；没有标准答案的问题单独标为“资料缺口”，不要算成模型错误。

对每条病例依次做三次测试：只看知识库能否人工找到答案；固定正确证据后看模型能否生成受支持答案；最后接回真实检索和业务接口跑端到端。这样可以区分检索召回、生成忠实度和集成错误。RAG 原始论文说明了把外部检索与生成结合的思路，见 NeurIPS 2020 论文，但 RAG 降低不了知识本身错误，也不能保证模型使用了证据。

上下文越长不一定越准确

把整本手册塞进上下文看似省去检索，实际可能引入多个版本和大量无关文字。“Lost in the Middle”研究发现，相关信息在长上下文中的位置变化会显著影响模型使用效果，参见论文原文。因此要测试切分边界、标题与表格保留、关键词加语义的混合召回、元数据过滤和重排，而不是只增加 top-k。涉及权限时，过滤必须在检索前由服务端执行，不能让模型看到敏感片段后再要求它别说。

评测至少分开记录检索 recall@k、上下文精确度、有证据回答正确率、引用一致率、正确拒答率和严重错答率。RAGAS 论文也把检索上下文、忠实度与答案质量视为不同维度，见 EACL 论文；自动评委可以帮助批量筛查，但高风险错误仍应由业务人员复核，不能让另一个模型单独宣布合格。

修复后必须回归而不是凭感觉聊天

每次修改知识、切分、检索、提示词或模型，都在同一套冻结集上重跑，同时增加这次发现的病例。上线门槛要同时写明抽样范围、风险类别和任务指标，例如“测试集按真实问题分布抽样并覆盖全部严重错误类别，严重错答为 0，有证据正确率达到双方约定值”，而不是笼统的“准确率 95%”。另外监控无答案率、转人工率、延迟和单次成本，避免准确度提升建立在不可接受的等待或费用上。

滚水科技处理这类问题时应先交付错误分类、可复跑病例、逐层指标和修复前后对照，而不是默认追加向量库或更贵模型。若客户无法提供权威资料和答案负责人，应明确把问题判为知识治理缺口并暂停扩大上线。