2026-05-08#

Question#

企业知识库 RAG 的检索质量优化

你在做一个企业内部知识库问答系统，用户经常反馈两类问题：

1. 明明文档里有答案，但系统没检索到；
2. 检索到了相关文档，但模型回答仍然不准确，甚至混入了不相关内容。

如果让你负责优化这个 RAG 系统，你会怎么分析和改进？

可以从这几个角度回答：

• chunking strategy 怎么设计和调整？
• embedding / vector search / hybrid search / reranking 分别解决什么问题？
• 如何判断问题出在 retrieval 还是 generation？
• 生产环境里如何持续评测和监控 RAG 质量？

Your Answer#

我不知道

Review#

本次未作答，完整示范回答如下。

Improved Answer#

结论先行：优化企业知识库 RAG，不能只调 prompt，而要把问题拆成两段看：retrieval 是否找到了正确证据，generation 是否忠实基于证据回答。前者决定“有没有把答案拿进上下文”，后者决定“模型有没有正确使用证据”。

1. 先定位问题：retrieval 还是 generation#

我会先建立一批带标准答案的 golden dataset，每条包含：

• 用户问题
• 应命中的文档或段落
• 标准答案
• 可接受引用范围

然后分别评测：

• Retrieval Recall@K：正确证据是否出现在 top-k 结果中；
• MRR / nDCG：正确证据排序是否靠前；
• Answer Faithfulness：回答是否被检索证据支持；
• Answer Relevance：回答是否真正回答了用户问题。

如果正确文档没进 top-k，说明主要是 retrieval 问题；如果正确文档进来了但回答错，说明主要是 generation / context organization 问题。

2. 优化 chunking strategy#

chunking 的目标不是“平均切文本”，而是让每个 chunk 保持完整语义，同时适合检索。

我会关注：

• 按结构切分：优先按标题、段落、表格、FAQ、章节切，而不是固定长度硬切；
• 控制 chunk size：太小会丢上下文，太大 embedding 会被噪声稀释；
• 保留上下文信息：chunk 中带上文档标题、章节路径、更新时间、权限标签；
• 适当 overlap：避免答案跨 chunk 时被切断；
• 特殊文档特殊处理：表格、流程文档、代码文档、PDF 扫描件需要不同解析策略。

例如企业制度类文档，可以按“制度标题 → 章节 → 条款”切分；API 文档可以按“接口 → 参数 → 示例”切分。

3. 组合 embedding、vector search、hybrid search、reranking#

不同检索组件解决的问题不同：

• embedding / vector search：解决语义相似问题，比如“请假规则”和“年假申请政策”不是字面相同但语义相关；
• keyword search / BM25：解决精确匹配问题，比如产品名、错误码、合同编号、人名、缩写；
• hybrid search：同时利用语义召回和关键词召回，适合企业知识库这种专业词多、表达方式又不统一的场景；
• reranking：对初召回结果重新排序，让真正能回答问题的 chunk 排在前面，而不是只看向量距离。

一个常见链路是：

query rewrite → hybrid search 召回 top 50 → reranker 排序 → 选 top 5~10 → 组织 context → LLM 生成答案并引用来源

4. 优化 generation 和 context organization#

如果检索结果是对的，但回答仍然不准，我会优化生成阶段：

• 要求模型只基于给定 context 回答；
• 没有证据时明确回答“不知道”；
• 每个关键结论附带 citation；
• 将多个 chunk 按相关性、章节顺序、文档权威性组织；
• 避免把大量弱相关 chunk 塞进 prompt，减少干扰；
• 对冲突文档按更新时间、来源优先级处理。

这里的重点是：RAG 不是把检索结果简单拼进 prompt，而是要控制证据质量、顺序和使用规则。

5. 生产环境持续评测和监控#

上线后我会持续监控四类指标：

• 检索指标：Recall@K、top-k 命中文档、reranker 分数分布；
• 生成指标：faithfulness、answer relevance、citation accuracy；
• 用户反馈：点赞/点踩、追问率、人工纠错记录；
• 系统指标：延迟、token 成本、检索耗时、不同文档类型的失败率。

同时建立 prompt regression test：每次调整 chunking、embedding model、reranker、prompt 或模型版本，都跑固定测试集，避免局部优化导致整体退化。

总结#

所以我的优化思路是：

先用评测数据判断问题发生在 retrieval 还是 generation；
retrieval 侧优化 document parsing、chunking、hybrid search 和 reranking；
generation 侧优化 context organization、citation 和拒答策略；
最后用 golden dataset、线上反馈和 observability 持续迭代。

这样才能把 RAG 从 demo 变成稳定可用的企业知识库问答系统。