RAG（检索增强生成）这两年火得不行，各种教程都说”搭一个 RAG 系统只要三步”。
但真正动手做过产品的人都知道，实际跑起来完全是另一回事：用户问的问题和文档里的说法对不上、数据分布在五六个系统里、给 LLM 喂太多内容直接超 token 限制、用户等了三秒没响应就骂人……
微软 Azure 团队最近发了一篇文档，系统梳理了 RAG 落地时会碰到的核心挑战，并且给出了两套解法。今天就把这五个”坎”说清楚，顺便看看现在行业里的解决思路。
坎一：用户问的，和文档里写的，根本不是一回事
这是 RAG 系统里最常见的坑，叫查询理解（Query Understanding）。
举个真实的例子：
用户问：“公司对 2023 年之后入职的远程办公员工，有什么调休政策？”
但公司文档里写的是：“关于后疫情时期新入职全职员工的弹性工作与假期安排”。
你看，人能秒懂两边说的是同一件事，但传统关键词检索就不行了——“调休”对”假期”，“远程办公”对”弹性工作”，“2023 年后入职”对”新入职全职员工”，完全对不上。
传统 RAG 的解法是混合检索（Hybrid Search），把关键词搜索和向量相似度搜索合起来用，再加上语义排序（Semantic Ranking），让结果按”意思接近程度”重新打分，而不是按”字面匹配程度”排序。
更进一步的 Agentic RAG 解法是让 LLM 先”审题”——它看到用户的复杂问题，会主动拆成多个子查询分别去搜。比如把上面的问题拆成”远程员工假期政策”+“2023年后入职”+“调休规定”，然后并行去搜，最后把结果合并起来。相当于有一个聪明的助手先把你的问题翻译成搜索引擎能理解的版本。
坎二：数据分布在七八个系统里，根本不是”一个数据库”能搞定的事
企业真实的数据环境是什么样的？
- HR 政策存在 SharePoint
- 薪酬福利在数据库里
- 公司公告放在内部网页上
- 合同文件在云存储里
- 还有一堆历史遗留系统……
传统 RAG 的做法是建一个统一索引层，让爬虫从各个数据源把数据拉出来，做分块（chunking）、向量化（vectorization），存进一个索引里。这就像把所有书都复印一遍，堆到一个大仓库里。
问题是：数据源一更新，你得重新爬、重新索引，否则答案就是过时的。而且复制数据本身就有治理风险。
Agentic RAG 的思路不一样——它不强制把所有数据集中起来，而是”query-time unified”（查询时统一）。系统收到一个问题，智能地把子查询分发到对应的真实数据源（SharePoint、Bing、本地索引……），直接去源头发查询，拿回结果再合并。
这就好比以前是”把书都搬到图书馆再借”，现在是”让一个馆员帮你同时去好几个图书馆查，然后把结果汇总给你”。
坎三：LLM 能吃的 token 有上限，你却有上万页文档
GPT-4 能接受约 128K tokens，看起来挺多？
但如果你做的是企业知识库，文档动不动就上千页，根本不可能一股脑塞给模型。
传统 RAG 的解法是在检索阶段就做”精筛”——语义排序只返回最相关的前 50 条结果，通过 top-k、top-n 参数和最低分阈值来控制。同时用 scoring profiles 给重要内容加权，让真正有用的片段排在前面。
Agentic RAG 的解法更进一步——它的返回是结构化的，不只是文本块，还包括：
- 引用来源（Citation）：明确标出这个答案参考了哪段原文
- 查询活动日志：告诉你系统实际搜了哪些关键词、搜了什么数据源
- 可选的答案合成（Answer Synthesis）：用一个专门的 LLM 把检索结果压缩成精炼答案再返回，进一步省 token
打个比方：传统 RAG 像图书馆给你抱来 50 本可能相关的大部头；Agentic RAG 像一个研究助手，直接把答案整理好，每条结论都注明了出处。
坎四：用户等不了 30 秒，RAG 系统却要跑半天
用户体验研究普遍认为，AI 回答超过 5 秒就会让人开始焦虑。
RAG 系统慢在哪里？主要在两个环节：
- 检索阶段：多数据源串行查询，一个查完才查下一个
- 生成阶段：LLM 拿到所有内容后还要”消化”一遍
传统 RAG 的优化思路是把检索层做快——Azure AI Search 能做到毫秒级查询响应，单次查询直接返回结果，尽量减少等待。
Agentic RAG 的关键优化是并行化：把拆出来的子查询同时发出去，而不是一个一个串行执行。子查询都返回了，最后再汇总。这就像你同时给三个同事发消息问不同的问题，而不是先等第一个回复再问第二个。
同时 Agentic RAG 支持可调节的推理努力级别（Minimal / Low / Medium），简单问题用轻量推理，复杂问题再动用强推理，在效果和速度之间做权衡。
坎五：财务数据能不能只让财务部的人看到？
这是企业级 RAG 最容易在评审阶段被毙掉的问题。
老板的灵魂拷问是：“我把内部文档接进 AI，如果任何员工都能问 AI 任何问题，那财务机密不就泄露了？”
传统 RAG 的安全机制主要是文档级别安全修剪（Document-level Security Trimming）——在索引层面就给数据打上权限标签，查询时根据用户身份过滤，不该看的文档直接不返回。同时配合 Microsoft Entra ID 权限元数据、网络隔离（Private Endpoints）等手段。
Agentic RAG 的安全方案更细粒度——做到了知识源级别的访问控制。同样是问”公司战略规划”，不同部门的人从同一个 AI 助手得到的信息范围是不同的，因为它会根据每个人的权限，去对应数据源分别查、能查什么返回什么。
两条路：Classic RAG 还是 Agentic RAG？
说了这么多，企业实际落地的时候怎么选？微软的文档给了一个很清晰的决策参考：
选 Agentic RAG（智能体检索）如果：
- 你的客户端是 AI Agent 或复杂对话系统
- 需要最高的准确率和相关性
- 用户问题复杂、多轮、上下文依赖强
- 需要带引用的结构化回答
- 从零开始搭建新的 RAG 系统
选 Classic RAG（经典检索）如果：
- 只需要用 GA（正式发布）级别的功能
- 优先考虑简单性和响应速度
- 已有现成的编排代码不想大改
- 需要对查询管道做细粒度人工控制
总结
RAG 不是一个搭好就完事的系统，它需要在查询理解、多数据源整合、token 效率、响应速度和安全合规这五个维度上持续打磨。
传统的”一股脑索引+关键词检索”方案在简单场景够用，但面对复杂企业需求，越来越需要”智能体思维”——让系统主动理解用户意图、动态规划查询策略、按需访问真实数据源。
好消息是，这些能力正在变成各大云平台的标配。比如微软把 Agentic Retrieval 做成了 Azure AI Search 里的预览功能，NVIDIA 也开源了相关蓝图（Blueprint）。选对工具，至少这五个坎不会每个都自己重新踩一遍。