OpenAI o3-pro发布，也许当前的RAG过时了...

前两天，OpenAI 发布 o3-pro，号称最强推理 AI 模型上线，推理能力再创新高。对于推理最强这个信息，很多人都是无所谓的状态，但随后的信息就很嗨了：

伴随o3-pro的推出，OpenAI还做出了一个令人意外的决定，o3的价格下调80%，降至与GPT-4o相当的水平。具体来说：

1. 调整前：输入token每百万10美元，输出token每百万40美元；
2. 调整后：输入token每百万约2美元，输出token每百万约8美元；

虽然对比DeepSeek的费用来说还是偏贵，但已经是很有诚意的降价了，一些同学对此可能没什么概念：

10000字的提示词之前要花0.72元，现在只需要0.144元了。

除此之外，o3-pro上下文窗口大小为 200k，最大输出 token 数为 100k，这意味着至少可以输入约15万字的提示词！

大家知道15万字是什么概念吗，一篇短篇小说，各位得看一晚上了！

而无论是更便宜的资费还是更强的上下文，他都利好于Agent架构的记忆问题，大白话来说就是RAG由于更长的提示词上下文，可以玩得更花了！

作为AI应用80%会涉及的技术，今天我们就来简单介绍下RAG的几种玩法。

AI应用很简单，简单到一周就可以出demo；AI应用也很复杂，复杂到一年后效果依旧跟demo差不多，下图就是AI产品调用流程的具象化：

他是一段提示词输入 + LLM处理后的一段输出，但就是这里的输入和输出就学问大了。

一、基础RAG

最简单的检索增强模式，通过简单的文档检索提升模型的应答质量。

最初使用这个模式的时候，多半是为了加入特殊数据（知识），比如大模型关于糖尿病的治疗输出是基于临床指南的，而我们实现了一个医生的数字分身后，就要用该医生的回答，这里的流程是：

基础RAG优势在于快、易落地；短板则是检索策略死板、推理链条单薄。

RAG在工程层面只包含三个关键步骤：向量检索 → 上下文拼接 → 一次性生成。

这套流程足以在短时间内构建可用 Demo，但当场景复杂度提升，缺陷也会迅速暴露。下面按“现象—成因—应对”顺序展开：

就是因为基础RAG这样那样的技术，所以很快就衍生出了高级RAG框架：

二、高级RAG

所谓高级RAG其实也没那么高级，其实就是基于RAG增加了很多工程控制策略。

他就是把“只会在一个抽屉翻文件”的基础 RAG，升级成“先问清需求、跑遍图书馆、再把最有价值的段落按优先级贴到桌面”的智能助手，显著提升召回率 + 精准度 + 可观测性。

这里举个例子：

所以，高级 RAG = 多通道找资料 + 智能排序 + 过程可追踪的检索增强方案，让 AI 回答既更全又更准，还能快速定位哪里出错。

传统 RAG 只用向量 Top-k 检索，常漏掉专业术语或编号；高级 RAG 同时跑向量、关键词、结构化数据等多路召回，再用轻量模型二次排序，把真正相关的段落放到最前。

系统自动记录召回率、覆盖率等指标，如果出问题也可以很快查到是检索缺料还是 Prompt 失误。

总而言之，就是策略层面多了一些，调试方面更友好了。

三、GraphRAG

GraphRAG我们前面已经介绍过了。

如果说基础 RAG 像“在抽屉里翻资料”、高级 RAG 像“跑遍图书馆并打上标签”，那 GraphRAG 就是把所有书的知识点串成一张关系网，查询时直接沿着网状路径跳跃推理。

它把“检索增强”升级到了“关系增强”，让模型真正理解“谁跟谁有关系、为什么”：

对比之前的RAG技术，GraphRAG的门槛会高一些，其构建过程就很复杂，比如之前的真实案例，他会有个知识预处理阶段：

# 知识图谱构建示意
kg = {
    "nodes": [
        {"id": "案例-XX医疗项目", "type": "case"},
        {"id": "部门墙", "type": "problem"},
        {"id": "Figma-Axure冲突", "type": "root_cause"},
        {"id": "埋雷预警", "type": "solution", "proprietary": True}
    ],
    "edges": [
        {"source": "案例-XX医疗项目", "target": "部门墙", "rel": "典型案例"},
        {"source": "部门墙", "target": "Figma-Axure冲突", "rel": "深层原因"},
        {"source": "埋雷预警", "target": "案例-XX医疗项目", "rel": "验证方案"}
    ]
}

• 输入：

根据以下知识图谱路径回答问题：
用户问题 -> 部门墙 -> 典型案例 -> XX医疗项目
        ↓
根本原因 -> Figma-Axure冲突
        ↓
解决方案 -> 埋雷预警（专有方案）

• 输出：

这个问题在《XX医疗项目》中有典型体现：  
1️⃣ **冲突起源**：设计组使用Figma交付原型，开发组坚持Axure格式（识别到工具冲突实体）  
2️⃣ **恶性循环**：沟通不畅导致开发擅自删除「消息已读」功能（关联到结果实体）  
3️⃣ **破局关键**：  
   - 立即实施「需求对齐看板」（关联解决方案）  
   - 启用课程独创的「埋雷预警」机制（优先调用私有方案）  
4️⃣ **效果验证**：二期项目交付周期缩短37%（绑定结果数据）  

四、推理型RAG

如果说 GraphRAG 把资料“织成网”，那推理型 RAG 就是在网里塞进一位能「拆题-找料-论证-拍板」的小型决策官。它将思维链推理与检索动态调度融合，直接面向“复杂思考 + 自主决策”场景。

事实上，我并不认为推理型RAG比知识图谱的策略更高明，但如果基于知识图谱做推理，效果显然会更好，只不过不通过图谱也能CoT

以下是一些对比：

为方便各位理解，我这里举个案例：

• 30 岁男性，三天前起发热 38.6 ℃，伴咳嗽、皮疹（躯干散在红斑），近 24 h 出现乏力、关节酸痛。血常规：WBC 12 × 10⁹/L，CRP 48 mg/L。
• 给出最可能的 5 个诊断并指出下一步检查/用药建议。

这里处理起来就要上推理型RAG了：

步骤1：症状网络构建

先把患者口述的所有信息拆成「症状、体征、检查、指标」等标准标签，再自动计算“两两 / 三元”组合的重要度。

系统只对权重最高的组合打上深度检索标记，并在界面里用节点-边图可视化，医生一眼就能看出真正值得追问与排查的线索，避免让零散信息淹没核心问题。

步骤2：动态取数

策略引擎实时监听高权重组合，比如：

1. 出现“黄痰+胸痛”时，立即调用感染性疾病索引；
2. 检测到“呼吸短促”则切换到胸膜并发症知识图谱；

这样做的好处是先问清再查料，按需拉取指南段落、病例摘要和实验室阈值，而不是一次性拉满 Top-k，既省 token 又缩短响应延迟。

检索结果会带上“触发原因 + 来源库”标签，便于后续审计。

步骤3：回溯闭环

系统先基于当前证据自动生成首版诊断列表并打置信度分，再为每条诊断设置关键否定条件（如“若无发热，则需重新评估肺栓塞”）。

一旦反事实验证不通过，回溯控制器就会重开检索-推理流程并写入修正日志，形成可追踪的自纠错闭环。

最终输出不仅是一行诊断结论，更包含推理路径、证据引用和下一步检查/用药建议，既合规也方便质量迭代。

五、Agentic RAG

这个东西就没撒好介绍的了，基本也是Manus那套模型即所有的套路，主打模型会自己聪明得查找到所有需要的资料，暂时我没用过，也就不评论了...

结语

过去两年，模型发生了很大的变化，主要体现在两个方面：

1. 第一，模型的基础能力更强了；
2. 第二，模型的上下文更长了；

但这在前两年可不是这么回事，主流大模型的上下文窗口只有 4k–8k-16k-32k-64k-... 的不断发展。

最初谁想让模型吸收操作手册或聊天库，唯一的可行办法就是先把文档切成能塞进窗口的小片段，再做向量检索和拼接。

于是各种花式chunk策略应运而生：递归滑窗、层级重叠、语义边界分段,它们不是“炫技”，而是时代的权宜之计。

如今通用模型上下文模型把窗口拉到 128k、200k 甚至更大。结果很直接：能整篇塞进去的文档，就没必要硬切。

这并不是否定旧方法，而是承认边际收益正在递减：你再雕琢分块粒度，带来的增益也抵不过“一次性放进去”带来的信息完整度。

但是，当前模型对长文的理解还不行，插入过长的提示词依旧有个窗口期

所以，新一代的RAG使用，近期可能会发现不小的演进：

1. 窗口够大就整篇输入，不够再按结构化单元分；把“切不切”当成成本决策，而非技术信仰；
2. 检索层负责把文本、图像、视频统一变成向量或结构，业务代码不再东拼西凑；
3. 检索-推理-验证全程留痕；

过去分块是时代产物；未来的看点，是让检索和推理在更丰富、更实时的多模态数据上无缝衔接，把工程精力投到真正能提高业务价值的环节，而不是继续在切割细节上反复雕花。

参考：RAG技术的演进中对RAG的分类方式