RAG 问答如何证明答案来自文档关键不是完成一次调用而是让输入口径、处理状态和结果证据可以复核。本文围绕“如何上传文档、确认解析入库状态并让每个 RAG 回答携带可核对的引用来源”给出一套面向真实业务流程的实现方式。问题与结果只有完成解析和索引的文档进入检索回答同时保存知识库、线程、消息和引用片段。适用场景开发者文档问答产品帮助中心企业内部知识检索实现前先确定边界上传成功不等于索引完成必须检查 parse_status 和 index_statustenant_id、knowledge_base_id 和 thread_id 分别承担隔离职责回答没有引用或引用不支持结论时进入人工复核入库与问答必须分成两个状态机网页资料可以先通过 文章正文抽取形成稳定正文再与本地文档一起进入知识库。文档上传返回document_id后继续检查解析和索引状态只有parse_status与index_status满足可用条件文档才进入问答范围。原文件哈希、文件名、知识库和租户标识应一起保存。最小问答示例curl -X POST https://api.gugudata.com/ai/knowledge-bases/default/chat/completions?appkeyYOUR_APPKEY \ -H Content-Type: application/json \ -d { model: gugudata-knowledge-chat, messages: [{role: user, content: 这个接口的错误处理规则是什么}], tenant_id: docs-portal, stream: false, top_k: 6 }知识库问答知识库问答知识库问答响应中的回答正文和sources必须一起保存。界面应让用户展开引用片段而不是只显示自然语言答案。多轮追问继续使用服务端返回的thread_id但文档版本变化时应明确开始新线程或记录索引版本。引用验收关键事实至少有一个引用片段引用属于当前知识库和租户引用文档版本与回答生成时一致引用缺失、冲突或不足时回答状态标记为“需要复核”。任务状态与失败处理生产接入至少区分INPUT_INVALID、PENDING、RUNNING、SUCCEEDED、PARTIALLY_FAILED和FAILED。状态名称可以按业务调整但不能把“任务已创建”“请求 HTTP 成功”和“结果可用”合并成一个成功状态。参数错误应直接返回给调用方频率或额度限制停止当前批次并保留下一次可执行条件依赖服务失败可以进入有上限的退避重试业务结果缺失、覆盖不足或引用不足则进入人工复核。每次尝试记录请求标识、开始和结束时间、业务状态、失败原因以及是否产生可用结果。还应为重试设置幂等键和最大次数。相同输入、相同规则版本和相同业务目标不能因为网络超时重复写入多个正式结果超过重试上限后保留最后错误和人工处理入口。运行记录与回归检查上线前保存一组脱敏固定样本用于比较接口或规则升级前后的字段结构、状态流转和关键结果。回归测试不追求结果文本逐字一致而是检查必填字段、来源证据、错误分类和能力边界是否稳定。对于本文场景重点回归以下约束上传成功不等于索引完成必须检查 parse_status 和 index_statustenant_id、knowledge_base_id 和 thread_id 分别承担隔离职责回答没有引用或引用不支持结论时进入人工复核监控指标至少包括成功结果数、失败数、处理中任务数、人工复核数和数据新鲜度。任何未采样指标都应显示“未采样”不能默认为零。数据契约与留痕字段作用knowledge_base_id稳定业务标识用于关联记录和请求追踪tenant_id稳定业务标识用于关联记录和请求追踪document_id稳定业务标识用于关联记录和请求追踪document_hash内容哈希用于完整性、版本和重复识别index_status显式状态或原因禁止以空值代替失败thread_id稳定业务标识用于关联记录和请求追踪message_id稳定业务标识用于关联记录和请求追踪answer业务数据字段保存来源、口径和缺失状态sources原始来源或响应供后续复核usage业务数据字段保存来源、口径和缺失状态重试应新增尝试记录不覆盖最后一次失败。派生结果必须关联输入版本、生成时间和业务状态。验收清单文档更新后不会静默沿用旧索引回答中的关键结论可定位到引用片段不同租户和知识库不能互相检索能力边界RAG 引用能提高可追溯性但不能证明原文真实、最新或足以支持专业结论。示例中的YOUR_APPKEY仅为占位符。真实密钥只能放在服务端环境变量或密钥管理系统中。