别被 Demo 骗了，聊聊企业级 RAG 落地时最容易踩的检索坑

很多公司在部署 RAG（检索增强生成）时，最容易陷入的误区就是把这当成一个简单的“接口调用”工程。在 Demo 阶段，用几个精心挑选的 PDF 样本跑通流程确实很快，但一旦进入企业级实战，你会发现检索精度低到离谱，LLM 依然在胡说八道。经过实际部署踩坑，我发现绝大多数的“幻觉”问题，根本不是大模型的能力问题，而是前端检索链路的质量太差。

最核心的痛点在于，很多人习惯于直接走 Query -> Vector DB -> LLM 这种极简链路。在这种模式下，如果你的知识库切片（Chunking）策略没做好，或者仅仅依赖向量检索，结果必然是灾难性的。比如在处理包含特定产品型号、专业术语或内部编码的文档时，向量检索（Vector Search）经常会因为语义空间的微小偏差而召回错误片段，导致模型基于错误信息生成答案。

想要真正落地，必须在检索链路中引入“混合检索（Hybrid Search）”和“重排（Rerank）”机制。

首先是数据清洗的死磕。千万不要直接把原始 PDF 扔进向量数据库。PDF 里的页眉页脚、表格断行、乱码字符会产生巨大的检索噪声。建议在入库前通过清洗脚本剔除冗余信息，并采用更智能的切片策略，而不是死板的固定字符长度切分。

其次，在检索阶段，必须将向量检索与传统的 BM25 关键词匹配结合起来。向量检索擅长处理语义相关性，而 BM25 擅长处理精确匹配。只有两者结合，才能在处理专业术语时保证足够的召回率。

最关键的环节是 Rerank（精排）。在初步召回 50-100 个片段后，必须通过一个专门的 Rerank 模型（如 BGE-Reranker）对这些片段进行二次打分，过滤掉那些虽然语义相关但缺乏核心重点的噪声，只将最相关的 Top 3-5 个片段喂给 LLM。我之前测试过，不加 Rerank 时，召回片段的干扰项极多，模型很容易被误导；加上 Rerank 后，回答的准确率才勉强达到及格线。

如果你正在搭建工作流，我建议参考以下这个逻辑结构，这比简单的单路检索稳得多：

workflow:
  input: user_query
  step_1: query_expansion (通过 LLM 扩展查询词，提升召回覆盖面)
  step_2: hybrid_retrieval (执行向量检索 + BM25 关键词检索)
  step_3: rerank (利用精排模型对召回结果进行相关性过滤)
  step_4: generation (将精选上下文注入 Prompt，引导 LLM 生成)

最后，在预算核算时，请务必关注除了 Token 之外的隐形成本。很多团队在立项时只算了 API 费用，却忽略了向量数据库的内存开销。随着数据量增加，为了维持检索速度，索引对内存的占用非常惊人，且数据同步的延迟在实时性要求高的场景下会成为巨大的技术瓶颈。

总结来说，RAG 的上限不在于你用了哪个 LLM，而在于你对数据的清洗程度以及检索链路的精细化管理。不要迷信简单的架构，死磕召回率和精排才是落地的唯一出路。