某金融客户把产品说明书按固定512 token切片，结果一句“本理财产品不保本”被拦腰截断，前一半落在A片段，后一半落在B片段。大模型检索时只拿到A片段，给出的回答变成了半截语义，风险警示直接消失。另一家制造企业走另一个极端，把整份200页的技术手册当作一个切片，检索时只要命中就整本塞进Prompt，上下文窗口瞬间爆炸，成本飙升不说，核心参数被淹没在噪声里。
合理的做法是根据文档语义结构切分：按章节、段落、表格行做边界识别，保持128-1024 token的弹性区间。关键数据项尽量保证原子性，不要跨切片断裂。
我们曾帮一家零售企业做诊断，其RAG系统的top-5检索命中率只有38%。原因是他们单纯依赖向量相似度，而“Apple”在语义空间里既可能是水果也可能是公司。用户问“Apple最新的供应链政策”，结果召回的是水果种植指南。加上BM25做稀疏向量混合检索，并把分类标签（如“供应链”“农产品”）作为过滤条件，命中率才提升到82%。
很多企业的知识库是“大杂烩”：正式SOP、内部论坛讨论、过期公告、甚至员工随手记的Confluence草稿混在一起。RAG不会自动判断哪份文件更权威。我们曾经看到一次严重失误：大模型引用了一份三年前的测试版接口文档，导致生产环境API调用失败。必须在入库阶段就给文档打上权威等级标签，比如“正式发布>部门审核>草稿讨论”，并在检索时优先召回高权重来源。
没有引用标记的RAG就像没有参考文献的论文。某医疗AI项目初期没有强制引用来源，医生发现模型给出的用药建议虽然正确，但无法追溯到具体临床指南章节，最终不敢采纳。加上片段级引用后，可信度显著提升。
比无引用更隐蔽的是无更新机制。一份促销政策在官网上已经下架三个月，但向量库里依然存活。建议至少建立两套机制：一是基于来源文档的主动全量更新（每月一次），二是基于用户反馈的被动召回（当用户点击“答案不准确”时，触发该片段的人工复核）。
与其在上线后救火，不如在上线前建立基线。以下是我们内部使用的检查清单，可直接复用：
1. 切片质量：随机抽取100个切片，检查是否存在语义断裂或过度冗余，目标断裂率低于5%。
2. 检索评测：准备50-100个真实业务问题，计算MRR（平均倒数排名）和top-5命中率，目标MRR>0.7，命中率>80%。
3. 来源校验：确保每条被召回的片段都携带文档ID、版本号、最后更新时间。
4. 引用覆盖率：要求大模型输出中，事实性陈述必须有[来源ID]标注，目标覆盖率100%。
5. 更新时效：核心政策类文档的更新延迟不超过T+7天，技术文档不超过T+30天。
6. 人工抽检：每周由业务专家抽检20组问答，记录“幻觉率”和“无法回答率”，两者之和应控制在10%以内。
RAG系统的天花板不在大模型的参数规模，而在检索环节能送来什么样的上下文。再强的GPT-4，面对一堆截断的、过期的、不相关的片段，也只能编造答案。把钱和精力花在切片策略、混合检索、权威分级和更新治理上，比盲目换更大尺寸的模型更有性价比。检索质量决定回答质量，这句话不是口号，是工程底线。
