AI 工程圈有个共识：90% 的 RAG（检索增强生成：让大模型先查企业资料再回答的技术）项目效果差，瓶颈根本不在大模型，而是检索层没把正确的数据喂给它。

这是什么

我们注意到，大多数开发者遇到 AI 知识库答非所问时，第一反应是换更大的模型或改提示词。这完全没对症。在典型的 RAG 架构里，真正出问题的是检索环节。

首先是向量相似度（计算文本语义接近度的指标）不等于相关性。用户问“如何处理 API 超时”，系统召回了大量“什么是超时”的段落，语义相近但对解决问题毫无用处。其次，把大量松散相关的内容全塞给大模型，不叫提供上下文，叫让模型在噪声里猜答案，不仅成本高昂，还会增加延迟。最后，绝大多数项目用固定字数切分文档，完全无视段落逻辑，导致上下文断裂。

行业已经摸索出解法：用 Hybrid Search（混合检索：结合语义和 BM25 关键词匹配）解决精准名词查不到的问题；用 Parent-Child Chunking（父子分块：用小块文本去检索，命中后返回所属大块文本补充上下文）解决信息碎裂；用 HyDE（假设文档嵌入：让 AI 先生成假设性答案，再用它去搜真文档）来应对用户口语化提问。

行业怎么看

我们认为，行业正在从“大模型崇拜”转向“数据工程崇拜”。只盯着模型参数，不如花精力把检索链路做扎实，这才是真正能降本增效的着力点。

但这套做法也有明显的反对声音：检索层的复杂化会大幅推高工程成本。引入混合检索、重排和查询改写，意味着系统延迟增加、每一步都可能额外调用模型，维护难度远超预期。有架构师指出，对于结构清晰的内部文档，简单的关键词搜索加上一点微调，效果未必比花哨的检索策略差，过度工程化反而容易成为拖累项目进度的新陷阱。

对普通人的影响

对企业 IT：别再只盯着采购最贵的大模型了，AI 落地成不成功，八成取决于你的数据清洗和检索管道搭得好不好。

对个人职场：懂大模型提示词的红利期正在消退，能把企业散乱数据整理成“AI 友好”结构的人会更值钱。

对消费市场：企业级知识库产品将从“听起来聪明但总翻车”走向“死板但准确”，真正能帮用户解决具体问题的 B2B AI 软件会变多。