把几万份 PDF 合同、制度文件、技术手册丢进知识库，再接一个大模型，很多团队第一次上线 RAG 时都是这么干的。
结果往往不太好看。用户问一个条款，大模型答得很流畅，但出处对不上；问一个技术参数，它找到了相似段落，却漏掉关键限定条件；问跨文档问题，它开始把几份材料里的信息揉在一起，像懂了，其实没懂。
这类问题不能简单归结为“模型幻觉”。RAG 本来就是为了解决大模型只依赖预训练知识的局限。NVIDIA 对 RAG 的解释很直接：它把外部数据源接入 LLM，让模型可以基于企业自己的结构化和非结构化资料生成回答，通常会用向量数据库做语义检索。
但到了企业场景，单靠“切分—向量化—检索”这条流水线，很快会碰到边界。IBM 在讨论 RAG 问题时提到，传统 RAG 在上下文窗口、聚合运算、复杂关系理解、分块策略和安全风险上都有现实限制。IBM 软件事业部高级副总裁 Dinesh Nirmal 的说法更直白：“RAG 在很大程度上存在缺陷。纯 RAG 并不能真正达到预期的最佳结果。”
所以，企业 RAG 的改造重点，不是把向量库换得更贵，也不是把 prompt 写得更长，而是先把检索链路做扎实。
先处理文档，再谈向量化
很多知识库效果差，问题出在第一步：文档还没被正确读懂，就被切成了 chunk。
常见做法是直接用固定字符数切分，比如把 PDF 文本按长度拆开，再送去 embedding。处理普通说明文档时，这种办法还能勉强工作；碰到合同条款、财务表格、技术参数表，就容易把上下文切断。
比如一个限制条件在上一段，具体数值在下一段。检索时只召回其中一段，大模型拿到的就是半截信息。它不是故意编，而是上下文本来就缺。
更稳的做法是先解析结构，再决定怎么切：
- PDF 不要直接丢给切分器，先用 PyMuPDF、Unstructured 这类工具提取标题、段落、表格等结构；
- 表格要尽量保留行列关系，不要把单元格打散成孤立文本；
- 章节标题、来源文件、页码、创建时间等信息，要作为元数据挂到 chunk 上；
- 对制度、合同、技术文档，优先按语义边界切分，而不是只按字符数切。
这一步看起来不性感，却决定了后面检索的上限。RAG 系统召回的不是“文档”，而是一段段 chunk。chunk 质量差，向量数据库再强也只能更快地找回错误片段。
向量检索不适合单独扛所有问题
向量检索擅长找语义相近的内容。用户问“售后响应时限”，它可能找到“服务承诺”“工单处理周期”等表达不同但意思接近的段落。
但企业知识库里有大量精确匹配需求：产品型号、合同编号、部门名称、季度简称、版本号、专有缩写。用户问“Q3 的销售额是多少”，只靠向量相似度，可能召回包含“销售额”的材料，却没抓住“Q3”这个限定。
这也是为什么混合检索会成为企业 RAG 的常规配置。腾讯云在企业级 RAG 指南中把文档解析、分块策略、混合检索、检索优化和生成质量控制放在同一条建设链路里看，而不是把 RAG 简化成向量检索。
一个典型流程是：向量检索负责语义相似，BM25 这类关键词检索负责精确词命中，然后合并结果、去重，再交给 Reranker 重排序。
# 伪代码：混合检索的基本流程
from langchain_community.retrievers import BM25Retriever
# 向量检索器
vector_retriever = vector_db.as_retriever(search_kwargs={"k": 5})
# 关键词检索器
bm25_retriever = BM25Retriever.from_documents(documents)
# 并行召回
vector_docs = vector_retriever.get_relevant_documents(query)
bm25_docs = bm25_retriever.get_relevant_documents(query)
# 合并、去重
all_docs = merge_and_deduplicate(vector_docs, bm25_docs)
# 重排序：让模型判断 Query 与候选片段的精细相关性
reranked_docs = reranker.compress_documents(query, all_docs, top_k=3)
这里最容易被低估的是重排序。第一轮召回追求覆盖，宁可多捞一些候选片段；重排序负责把真正相关的内容往前排。没有这一步，模型很可能拿到一堆“看起来相关”的材料，然后在相似但不准确的上下文里生成答案。
选向量数据库，不只看 QPS
向量数据库当然重要。NVIDIA 在介绍 RAG 时也提到，主动检索通常由用于高效语义搜索的向量数据库提供支持。
但企业选型时，只盯着 QPS 很容易跑偏。知识库真正麻烦的地方，是权限、过滤、元数据和后续扩展。
Milvus / Zilliz Cloud、Qdrant、Weaviate 都是常见选择，取舍可以从几个问题开始：
- 文档量未来会不会明显增长？
- 是否需要按部门、年份、文档类型、权限范围过滤？
- 是否要同时管理结构化和非结构化资料？
- 是否需要自建部署，还是可以使用云服务？
- 团队是否有能力维护分布式集群？
在企业知识库里，元数据过滤不是附加功能。用户问“只看 2025 年以后的政策文件”，或者“只查研发部门可见资料”，检索系统必须先把范围收窄，再做语义匹配。否则，大模型拿到的上下文再丰富，也可能包含不该出现、或者不该被用于回答的内容。
Prompt 要把“不能回答”写清楚
检索到了相关文档，不代表回答一定可靠。大模型仍可能忽略上下文，或者在证据不足时补全一个看似合理的答案。
政企场景尤其不能接受这种模糊地带。新华三在《数字化领航》AI 应用专刊中提到，RAG 提供的准确、可追溯知识基础，是构建可靠智能体的先决条件；没有 RAG，智能体的决策可能建立在错误信息之上。
落到实现上，Prompt 里要把引用约束写死：
请只使用以下检索到的文档片段回答问题。
如果文档中没有相关信息，请回答“未找到相关依据”，不要补充未经文档支持的内容。
文档片段：
{context}
问题：{question}
回答要求：
1. 每个关键结论必须标注引用来源，如 [Doc-1]。
2. 如果多个文档说法冲突，请指出冲突点。
3. 如果依据不足，请说明缺少什么信息。
这个模板解决不了所有问题，但能把系统行为从“尽量回答”改成“有依据才回答”。企业知识库最怕的不是回答慢一点，而是用很确定的语气给出错误结论。
如果业务问题经常需要多轮追问，还可以加入自我检查机制：先判断检索片段是否足够回答，再决定生成答案、二次检索，或要求用户补充条件。IBM 提到的上下文窗口、复杂关系理解和低质量输出问题，本质上都需要在检索链路和生成链路之间增加判断，而不是把所有压力交给最后一次生成。
真正该盯的是可追溯性
RAG 做到后期，评价标准会变得很朴素：答案从哪里来，能不能回到原文，权限是否正确，证据够不够。
所谓 RAG 3.0，与其说是一个新名词，不如说是企业从 demo 走向生产后，被迫补上的工程课：文档解析要保留结构，分块要尊重语义，检索要同时覆盖语义和关键词，重排序要筛掉噪声，生成阶段要强制引用来源。
中小团队不需要一开始就堆满所有组件。更现实的路径是先做三件事：改掉固定字符切分，引入混合检索和重排序，把回答来源标注到文档片段级别。
只要答案还能追溯到原始文档，RAG 系统就有校验和迭代的空间。追溯链断了，知识库看起来再智能，也只是把错误包装得更像正确。
参考来源：
[1] Meta Intelligence，RAG 檢索增強生成完全指南：客製化知識架構實戰，https://www.meta-intelligence.tech/insight-rag
[2] IBM，RAG 问题依然存在——以下是五种修复方法，https://www.ibm.com/cn-zh/think/insights/rag-problems-five-ways-to-fix
[3] H3C，《数字化领航》AI应用专刊，https://www.h3c.com/cn/d_202604/2833241_233453_0.htm
[4] 腾讯云，企业级RAG深度指南：从检索到生产级知识系统，https://adp.tencentcloud.com/zh/blog/enterprise-rag-guide
[5] NVIDIA，什么是检索增强生成 RAG，https://www.nvidia.cn/glossary/retrieval-augmented-generation
