核心判断
RAG（检索增强生成）是结构性需求——即使基模知识再完整，也永远无法处理私有数据和实时数据。但现有的 naive RAG 设计有四个根本性问题，这些问题推动着 RAG 向主动信息系统演进。
为什么 RAG 永不消亡：私有数据（你的公司内部文档）、实时数据（今天的股价）、特定领域专有知识（内部合规手册）——这三类信息模型不可能从训练数据中获得，必须通过检索传入。基模越强，这个结构性需求不会消失，只会演进形态。
现有 RAG 的四大问题
问题1：向量空间距离 ≠ 业务相关性
基于 Embedding 的检索只考虑语义相似性，不考虑业务 relevance。用户问"我上个月的投资回报率"，系统检索所有包含"回报率"的文档，但可能遗漏了关键的"你上个月买了什么"——这个查询在向量空间里离"回报率"较远，但在业务上是必须的。
问题2：Query 理解不足
"Compare 我和 Tom 的项目进度"——系统需要理解谁是 Tom、我的项目是什么，但直接向量化用户 query 处理不了这种上下文依赖。现有的 RAG 假设 query 是自包含的，但真实用户的 query 往往依赖上下文。
问题3：不支持多跳推理
"我们在哪些城市有办公室，这些城市的平均房价是多少？"——需要先 retrieve 办公室位置，再基于结果 retrieve 房价数据。现有 RAG 通常只支持 single-hop，多跳需要 Agent 介入，但 RAG 和 Agent 之间的边界目前还不清晰。
问题4：知识库维护是噩梦
旧信息什么时候废弃？新信息什么时候加入？同一份文档有多个版本怎么办？多个源说不同的东西怎么解决？这些知识库维护问题在规模化后会变成系统性瓶颈，但现有 RAG 框架几乎没有好的解法。
演进方向：五个维度
方向1：Query 理解增强
检索前先用 LLM 理解 query 的真实意图：解析隐式依赖、解析上下文引用、路由到合适的检索策略。从"被动嵌入"变成"主动意图理解"。
方向2：Agentic 多跳检索
Agent 驱动的迭代检索：Agent 理解需要什么信息 → 第一次检索 → 分析结果 → 决定需要更多信息 → 第二次检索 → 合成答案。Agent 在编排检索过程，不是被动等结果。
方向3：混合多维度检索
结合多个信号加权：语义相似度 + 关键词精确匹配 + 结构化 SQL 查询 + 时效性权重 + 用户历史访问权重 + 来源可信度。不同信号的加权组合，而非单一维度。
方向4：实时知识集成
静态知识库演进为动态知识系统：实时数据（API 调用）+ 用户个人数据（日历、邮件）+ 外部新闻源。系统需要智能决定：什么时候用检索（静态知识）、什么时候用工具调用（实时 API）、什么时候用 Few-shot（用户提供的信息）。
方向5：知识维护智能化
自动弃用检测、冲突解决、版本追踪、质量评分、更新传播——把人工的知识库维护工作自动化。这是企业级 RAG 系统真正落地的关键瓶颈。
RAG 产品评估框架：评估一个 RAG 产品时，不要只看"能不能检索到相关文档"，要看它是否解决了这四个根本问题。一个能处理多跳查询、有知识库维护机制、能理解 query 意图的 RAG 系统，和一个 naive 向量检索系统，竞争力差距是数量级的。