RAG 知识库落地：让业务文档可检索、可引用

近期方向里，RAG / 知识库是把 LLM 嵌进业务的常规路径：制度、产品说明、运维手册先切片入库，再检索增强生成。我们给内部工单系统做的试点表明，业务方最关心的不是模型多聪明，而是「这句结论出自哪份文档第几页、能不能点开核对」。没有溯源，客服不敢把答案写进工单；有溯源，才谈得上降本增效。

切片与元数据

按 Markdown 或 PDF 标题层级切片，单块 512–1024 token，重叠 64 token 避免断句。元数据附带来源文件、章节路径、版本号、更新时间、产品线、权限标签。入库前 OCR 清洗页眉页脚、页码。检索命中后，回答必须带引用片段，UI 可点击跳转原文 PDF 锚点，减少一本正经胡说。表格类内容尽量整表进一块或转结构化行，避免半表半文检索不到。

检索质量

向量检索用 bge-m3 类 embedding，Top-K 20 后用 reranker 精排到 Top5 再喂给 LLM。关键字段过滤：客服索引不含研发内部文档。坏答案排查顺序：切片是否切碎语义、版本是否过时、权限是否串库、prompt 是否要求必须引用。我们曾把 2023 与 2025 退费政策混索引，引用正确率跌到 60%，拆索引并加 effective_date 过滤后恢复到 88%。

评估

准备 50–100 条黄金问题集，涵盖高频客诉与边界 case，每周自动跑命中率、引用正确率、拒答率。没有评估的 RAG 只是演示。上线门槛：引用正确率大于 85%，否则仅内部灰度。企业场景要的不是更会聊天，而是更敢把答案写进工单、更敢对外承诺 SLA。

权限与合规

文档入库前打标签：公开、内部、机密。检索链路在向量库 filter 阶段就拦掉越权 chunk，而不是生成后再删——后者已有泄露风险。离职员工上传的临时说明要有 owner 与 expiry，定时任务清理过期切片。回答模板要求模型「仅依据引用片段」，无引用则拒答并建议转人工，降低幻觉进工单的概率。

运维与迭代

embedding 模型升级需全量 re-index，蓝绿索引切换，避免检索空窗。用户点「有帮助 / 无帮助」反馈回写标注集，每月增补黄金问题。成本上，rerank 比盲目增大 context 更划算：Top5 精排往往比 Top20 全文塞 prompt 更准也更省 token。RAG 是 living system，不是一次性接 API 的项目。

与 Agent 工具链衔接

当工单系统需要「查库存再回答」时，RAG 检索与 function call 分工：结构化查询走 API，非结构化制度走向量库，避免把所有事塞进 embedding。Agent 规划步骤时，每步仍要求引用片段编号，便于审计。Prompt 版本与索引版本一起打 tag，回滚时可精确到「周二那版 prompt 加周三索引」的组合，而不是一锅粥重试。

上线初期限制单次提问最大引用条数与总 token，防止恶意刷库。对高频相同问题可做缓存答案，但缓存键要含文档版本号，制度更新后自动失效。RAG 的价值在可审计的正确率曲线，而不是 demo 里的一次惊艳回答。

法务与合规参与定义「可入库文档范围」与「必须拒答话题清单」，比事后删库便宜。内部试点先接只读工单注释，不自动发送客户，人工确认两周后再开半自动。每一步都有引用截图存档，纠纷时可回放，这是企业 RAG 与玩具聊天最大的差别。

小结

RAG 是否可用，最终看引用是否正确、权限是否隔离、过期文档是否被及时淘汰。把评估集和引用展示做成产品能力，而不是上线后的补丁，知识库才能从演示走向日常工单。持续用真实提问回灌切片策略，比盲目换更大模型更有效。

实践中把上述清单变成可勾选的发布门禁，比事后补救更省时间。