RAG 的未来——2025 下半年我的技术判断
RAG 的未来——2025 下半年我的技术判断
适读人群：AI 应用开发者、后端工程师 | 阅读时长：约12分钟 | 核心价值：对 RAG 技术走向给出有明确立场的判断，欢迎一年后来对账
上个月我帮一个创业团队做技术评审，他们在纠结一件事：要不要把现有的向量检索 RAG 系统迁移到 Graph RAG。理由是看到一篇文章说 Graph RAG 效果好很多，团队 CTO 看完很兴奋，准备排期重构。
我看了他们的系统——客服问答场景，知识库是产品手册和 FAQ，总计大概 8 万字。
我直接说：别动，现在改是在浪费钱。
这不是随口说的。两年做 RAG 相关的项目，踩过向量检索的坑，评估过 Graph RAG 的方案，也真实用过长上下文模型来绕过 RAG 的路子。今天就把我对 2025 下半年 RAG 技术走向的判断写出来，有理有据，欢迎来打脸。
Graph RAG：技术上优秀，工程上还没到时候
先说结论：Graph RAG 在特定场景下效果显著优于传统向量 RAG，但 2025 下半年不会大范围普及，工程复杂度是主要障碍。
Graph RAG 的核心思路是把知识库里的实体关系抽取出来，构建知识图谱，检索时不是找相似段落，而是沿着关系路径遍历相关知识。微软研究院 2024 年发的那篇论文给的数据很好看，在需要多跳推理的问题上，Graph RAG 比向量 RAG 答案质量高 20-40%。
这个数字是真的，我不否认。但有几个工程现实我要点出来：
知识图谱的构建成本被严重低估。 实体抽取、关系抽取、图谱更新——这一套流程要做好，至少需要专门的数据工程投入。我见过一个团队搞了三个月，图谱质量还是很差，原因是他们的领域文档本身写得很不规范，实体边界模糊，LLM 抽取出来的关系乱七八糟。向量检索的容错性更强，文档质量差一点也能凑合跑。
更新维护是真正的难题。 向量库更新很简单，改了文档，重新 embedding，覆盖掉旧的向量。图谱不一样，一个节点的变更可能影响一堆边的有效性，怎么做增量更新而不破坏图结构，这个问题目前工程界还没有特别成熟的答案。
适用场景比宣传的更窄。 Graph RAG 真正发挥优势的场景是：知识库中存在大量显式的实体关系、问题需要多跳推理、实体之间的关联是核心答案。典型的例子：医药知识库（药物-疾病-副作用的关系网络）、法律条款引用关系、金融监管规定之间的相互依赖。
普通的企业知识库——产品文档、内部规范、客服 FAQ——用 Graph RAG 是杀鸡用牛刀，而且这把牛刀目前还需要专人磨。
我的判断：Graph RAG 2025 年下半年会继续在垂直领域（医药、法律、金融合规）有专项落地，但不会替代向量 RAG 成为主流架构。主流工程师不需要现在押注，可以保持关注。
长上下文模型会替代 RAG 吗？我的答案是：部分替代，有边界
这个问题过去一年被问烂了。Claude 3 支持 200K token，Gemini 1.5 Pro 支持 1M token，很多人开始问：直接把整个知识库塞进去不就行了，还要 RAG 干什么？
我当时也测试过这个路子。结论是：能用，但没法完全替代，而且成本账要算清楚。
先说能用的场景：知识库总量在 100 万字以内（约 130 万 token 以内），查询频率不高，对延迟不敏感，能承担相应的 token 成本。这种场景下，把全量知识直接喂给模型，效果往往比 RAG 更好，因为省去了检索可能遗漏关键信息的问题，模型可以在全局上下文中推理。
但有几个问题长上下文解决不了：
成本。 每次对话都带着完整知识库，token 费用是固定成本，不是边际成本。一个有 500 万字知识库的企业，每次查询就得烧掉相当数量的 token。RAG 检索后只放入相关片段，成本差一到两个数量级。
"迷失在中间"问题（Lost in the Middle）。 学术界已经有很多论文验证这个现象：LLM 对超长上下文的注意力分布不均匀，对头部和尾部内容的记忆更好，中间部分容易被忽略。这个问题没有被完全解决，只是在某些模型上有所改善。
知识更新成本。 知识库更新后，要么重新构建新的上下文，要么每次都带上最新的全量知识。RAG 系统只需要更新对应文档的向量，其余不变。
实时性问题。 RAG 可以接入实时数据源（数据库、API 调用），长上下文模型的知识是静态的。
我的判断：2025 年下半年，长上下文会在"小知识库、低频查询、高质量要求"的场景抢走一部分 RAG 的份额，但不会颠覆 RAG 的主体地位。RAG 会进化，不会消亡。
具体来说，我预计会看到更多 RAG + 长上下文的混合架构：先用 RAG 检索出候选文档集（几十个文档），再把这批文档放入长上下文窗口让模型做精细推理，取两者的优点。
多模态 RAG：技术成熟度判断
这个方向我最近花时间看了不少，说实话，目前的成熟度比我预期的要低。
多模态 RAG 解决的问题是：知识库里不只有文本，还有图表、流程图、产品截图、表格。怎么让 RAG 系统也能理解和检索这些非文本内容。
目前主流有两条路：
路线一：图文转文本。 用多模态 LLM（GPT-4V、Claude 3 Vision）把图片转成文字描述，再对描述做向量检索。简单粗暴，工程上好落地。缺点是信息损失大，图表中的精确数字、坐标关系、空间布局往往在转成文字后失真。
路线二：多模态向量。 用 CLIP 类的模型直接对图片和文字生成对齐的向量表示，在同一个向量空间里做检索。理论上更优雅，但实际工程中有个大问题：图文向量的对齐质量在专业领域（工业图纸、医学影像、财务报表）很差，通用 CLIP 模型根本理解不了这些专业图像。
我自己做过一个测试，用 CLIP 检索工程 PDF 里的流程图，准确率很让人沮丧。
目前相对跑得通的多模态 RAG 场景：产品图片描述（电商场景）、PPT/报告中的图表（配合 LLM 生成描述后再检索）。
我的判断：多模态 RAG 2025 年下半年仍处于"能 Demo、难生产"的阶段。电商图片检索是相对成熟的方向，其他场景建议谨慎排期，先做 PoC 验证效果再决定投入。
向量检索本身的演进：几个真实有用的方向
说完三个大方向，再说说向量 RAG 自身的优化——这些是我在项目里真实用到过、效果有保障的。
混合检索（Hybrid Search）已经是标配了。 纯向量检索有个经典问题：对精确词汇匹配很弱。比如用户问"报错 NullPointerException 怎么解决"，向量检索可能给你返回一堆语义上"差不多"的内容，但就是没有包含"NullPointerException"这个精确词的文档。BM25 稀疏检索在精确词匹配上更强。把两种检索结果用 RRF（Reciprocal Rank Fusion）融合，稳定性会明显好于单一方案。这个现在基本是中等以上复杂度项目的标配了。
Reranker 不是可选项，是必选项。 向量检索 Top-K 结果的质量不稳定，Reranker（cross-encoder 结构的精排模型）对候选结果做二次排序，能把最相关的结果拉到前面。BGE-Reranker、Cohere Rerank 都是工程上能用的。代价是延迟增加，通常在 200-500ms 范围，多数业务场景可以接受。
文档分块策略严重被低估。 我见过太多项目把分块当成一个参数设置，定个 chunk_size=500 就完事了。实际上分块策略对 RAG 质量的影响能有 30% 以上。语义分块（按段落和主题边界切，而不是按固定字数切）在大多数场景下比固定大小分块好。如果文档有清晰的结构（标题层级），按结构分块往往最好。
Query 改写和扩展是性价比很高的优化点。 用户输入的问题往往很短、很模糊。在检索前用 LLM 把查询扩展成更完整的表述，或者从不同角度生成多个查询变体（HyDE，Hypothetical Document Embeddings），检索召回率能有明显提升。这个实现成本低，效果稳定，强烈推荐。
我的总体判断：RAG 2025 下半年的走向
把上面的分析收一下，我的具体判断如下：
向量 RAG 不会被替代，会持续演进。混合检索 + Reranker + 语义分块的组合，是 2025 年下半年的工程主流。
Graph RAG 继续在垂直领域深耕，进不了大众视野。我预计 2026 年会有一两个成熟的 Graph RAG 平台出现，降低构建门槛，届时才值得普通团队认真评估。
长上下文和 RAG 的关系是互补而非竞争。混合架构（RAG 粗召回 + 长上下文精推理）会成为高质量 AI 应用的标配架构。
多模态 RAG 最快也要 2026 年才有相对成熟的工程方案，现在入场踩坑的成本很高，除非你的场景非常明确，否则不建议大力押注。
回到开头那个创业团队——我的建议是，先把现有向量 RAG 的混合检索和 Reranker 做好，查询质量提升 20% 轻松达到，比搞 Graph RAG 重构实际得多。他们最后采纳了这个建议，三周上线了改进版，效果确实不错。
技术判断这件事，不怕说错，怕的是没有立场。一年后来对账，我会把结果写出来。