用 Codex 检查知识库回答靠谱吗？

企业知识库接入 AI 后，第一次演示通常都很顺利：上传资料，输入问题，模型给出一段像样回答。真正上线前要检查的是引用是否存在、边界是否拒答、旧资料是否误导、回答能否被人工复核。Codex 可以辅助做批量检查，但验收标准必须先写清楚。

适用场景：已经准备资料，准备检查回答

如果还处在整理资料阶段，先看 AI API 接入前企业知识库要先整理什么。本文假设你已经有文档、切片、权限和初版问答流程，接下来要判断回答是否能给客服、销售、运营或内部支持使用。

知识库回答最怕“看起来对”。模型可能引用了不存在的政策，混合了旧版本价格，把内部说明写给外部用户，或者在资料缺失时硬编结论。Codex 的价值不是替代业务负责人审批，而是把测试问题、回答、引用来源和差异记录批量整理出来，让复核更有条理。

操作步骤：建立一组可复查样本

1. 先分问题类型

不要只准备 20 个标准问法。样本至少分成五类：资料明确能回答、资料部分能回答、资料不存在、权限不允许回答、用户问题含糊。每类都写期望行为：直接回答、列出不确定项、拒答、提醒找人工，或要求用户补充信息。这样才能检查模型是否真的理解边界。

2. 要求回答带来源

让 AI 模型接口返回答案、引用片段、文档标题、更新时间和置信说明。若没有来源，就不要把回答当作可上线结果。开发者 AI 调用可以按 JSON 输出契约 约定字段，例如 answer、sources、missing_info、review_required。Codex 可以读取测试结果表，帮你找出来源为空、更新时间过旧或回答过度肯定的记录。

3. 做误答复盘，而不是只算通过率

每条失败样本都要标原因：检索没召回、切片太短、资料过旧、提示词诱导、模型猜测、权限规则缺失。然后再决定修资料、修检索、修提示词还是修权限。上线前的灰度思路可以参考 AI API 接入上线前灰度验证，先让少量内部用户试用并记录问题。

常见问题和避坑

第一，不要把“回答流畅”当准确。检查时要看来源是否支持结论，尤其是价格、权限、退款、合同、接口限制这类敏感内容。第二，不要让模型在资料缺失时自由发挥。提示词里应写明：没有依据时必须说明缺少资料。第三，不要忽略旧资料，知识库最常见的误答不是没有资料，而是旧资料和新资料同时存在。

如果知识库服务还要分配给客服或工单系统，可以结合 客服工单自动分类和分流 的复核方式，把“可直接回复”“需人工确认”“需更新资料”“权限不足”设为固定状态。这样模型调用管理不只看接口是否可用，也看回答是否能进入真实流程。

检查清单：一条回答上线前看什么

• 答案是否引用了真实文档、标题、片段或更新时间。
• 引用内容是否足以支持结论，没有把相邻段落误当依据。
• 资料缺失、权限不足或问题含糊时，是否拒答或要求补充。
• 回答是否区分内部说明和外部用户可见说明。
• 误答样本是否有原因归类和修复动作，而不是只改一句提示词。

最终验收可以用一句话判断：当回答错了时，团队能不能追到是哪份资料、哪次检索、哪个提示词版本、哪个模型输出造成的。如果可以追踪，知识库 AI 才有持续改进的基础；如果只能说“模型又乱答了”，还不适合扩大使用范围。

复核记录可以怎么写

建议把测试结果做成一张表，而不是只在聊天窗口里看答案。表格字段可以包括：问题、期望行为、模型回答、引用文档、引用片段、是否需要人工复核、错误类型、修复建议、复测日期。Codex 可以帮助把多轮测试输出整理成这张表，也可以按错误类型分组，例如“无来源回答”“旧资料误导”“权限边界错误”“回答过度承诺”。

复核时不要只看正确率，还要看错误是否可修。检索没召回，可能需要调整切片和关键词；资料过旧，应该处理文档生命周期；权限边界错误，应该先修权限规则；模型猜测，则要调整提示词和拒答要求。把原因拆开，团队才知道下一步该改数据、改流程还是改模型调用参数。

上线后的抽检频率

知识库上线后也需要抽检，尤其是价格、政策、活动规则、接口限制和售后说明发生变化时。可以每周抽取热门问题、无结果问题和人工转接问题各一批，让业务负责人看来源是否仍然有效。若连续几次出现同类误答，就不要只在提示词里补一句限制，而要回到资料治理和模型调用管理层面处理。