原型为什么总是看起来很好
在干净的演示数据上，切分文档、生成向量、检索 Top K，通常半天就能得到一个看似可用的问答系统。但进入真实业务后，同义表达、过期信息、复杂表格和权限隔离会迅速暴露问题。
原型往往只验证了“某个问题能否找到某段文字”，生产系统却要保证不同用户、不同版本和不同数据源下都能稳定工作。真正的链路是：数据进入、解析、切分、索引、召回、重排、生成、引用和反馈，任何一个环节的错误都会在最终答案中被放大。
生产链路的五个检查点
1. 文档治理
在生成向量前先处理重复、过期、冲突和低质量内容。为每份文档保存来源、版本、更新时间、所属租户和访问级别，并让删除动作能够同步传播到全文索引、向量索引和缓存。
如果两个制度文件互相冲突，模型无法替你判断哪个有效。应在入库阶段指定权威来源和生效时间，把“最新版本优先”变成确定规则。
2. 语义切分
固定字符数切块实现简单，但容易把标题与正文、条件与结论、表头与数据拆开。更稳妥的方式是先保留 Markdown/HTML 的标题层级，再根据段落、列表、代码块和表格边界切分，最后才用长度上限兜底。
每个块都应携带足够的父级信息：文档标题、章节路径、页码和原始地址。召回一个小段落时，可以向前后扩展相邻块，但不要把整份文档无差别塞进上下文。
3. 混合召回与重排
向量检索擅长语义相似，关键词检索擅长型号、错误码和专有名词。生产系统通常同时运行 BM25 与向量召回，合并候选后再用重排模型排序。
query
├─ keyword search ─┐
└─ vector search ─┼─> merge / deduplicate ─> rerank ─> top evidence
┘Top K 不是越大越好。候选过多会增加成本，也会让冲突证据干扰生成。应通过评估集选择召回数量，并为“没有足够证据”保留拒答路径。
4. 离线评估
测试集要来自真实问题，而不是只由开发者编写。每条样本至少包含问题、可接受答案、必需证据和权限上下文。检索层可以观察 Recall@K、MRR 与 nDCG；生成层关注事实一致性、引用正确率、拒答能力和任务完成率。
一次端到端分数不足以定位问题。把评估拆成“证据是否被召回”“证据排序是否靠前”“模型是否忠实使用证据”三个阶段，才能判断应该改索引、重排还是提示词。
5. 答案溯源
界面应展示引用片段、文档标题、版本和更新时间。引用必须与模型实际看到的证据绑定，不能在生成结束后再用相似度搜索“补一个看起来相关的链接”。
对于政策、财务、医疗等高风险场景，还需要保留当次检索快照。否则源文档更新后，用户看到的引用可能已经无法解释历史答案。
权限必须进入检索链路
不要先召回所有内容，再要求模型“不要泄露”。权限过滤必须发生在检索前或检索过程中，并使用服务端可信的用户身份。缓存键也应包含租户和权限版本，避免高权限用户的结果被低权限用户命中。
线上观测
建议为每个请求记录查询改写、候选文档 ID、各阶段得分、最终引用、模型版本、延迟和 Token 消耗。用户的点赞或点踩只是弱信号，更有价值的是“没有找到答案”“引用错误”“答案已过期”等结构化反馈。
发布新切分策略或嵌入模型时，不要直接覆盖索引。建立新版本索引，离线回放同一测试集，再通过小流量对比后切换别名，才能安全回滚。
一条简单但有效的原则
先确保检索结果中存在答案，再讨论模型如何组织语言。若证据不在上下文里，提示词无法凭空提高事实准确率。
同样，证据存在也不等于系统可靠：它还必须是当前用户有权读取的正确版本，并且最终回答能够准确引用。把 RAG 看成一条可测试的数据产品链路，比不断更换向量数据库更接近问题本质。