为什么 RAG "不怎么被提了"
两个原因，一个是场景被吃掉了，一个是概念被吸收了。
长上下文模型确实替代了一部分 RAG 的工作。现在主流模型动不动支持几十万 token 的上下文窗口，如果你的知识库只是几百页讲义或一个中等规模的文档集，直接全塞进 prompt 可能就是最省事的方案，根本不需要检索。有研究专门对比了不同模型在长文档处理上的能力差异，结论是：对于这类场景，硬塞确实比检索更简单可靠。当然，这类研究本身也面临一个尴尬——论文写完时用的模型还是旗舰，等正式发表时已经被更新了一轮。
更关键的原因是：RAG 没有消失，而是融入了更大的体系。行业里现在更常说的是 "context engineering"（上下文工程）。RAG 只是其中一个环节，和重排序、查询改写、记忆系统、工具调用协同工作。你不会单独讨论一辆车的轮子好不好用，但每辆车都有轮子。
从产品层面看得更清楚。OpenAI 的 API 至今内置 file search 功能，本质就是语义搜索加关键词的混合检索。Anthropic 推出了 Contextual Retrieval，在 RAG 基础上叠加了上下文信息和重排序，官方数据显示混合检索把检索失败率降低了将近一半，再叠上重排序后降了三分之二。这些大厂不是在告别 RAG，而是在把它从一个向量库 demo 做成工业级的检索工程。
判断很明确：RAG 还值得做，但今天值得做的版本，是混合检索、智能重排、能自己判断什么时候该去查资料的进化版。
知识图谱：别把它当起点
GraphRAG 是微软推出的项目，思路是在普通 RAG 之上加一层知识图谱，用图结构来表达文档之间的实体和关系。项目目前还在活跃更新，GitHub 上持续有新版本。
值不值得做？值得，但要看你的需求到了哪一步。
GraphRAG 解决的是一类特定问题——当你问的不是靠关键词就能命中的事实性问题，而是"过去两周笔记里有哪些主题反复出现""某个概念在不同论文之间怎么演变""帮我梳理一条跨文档的关系链"这类全局性、需要跨文档关联推理的问题时，普通向量检索确实够呛，图结构能发挥独特作用。
但 GraphRAG 不是"必然比普通 RAG 更强"的升级版。有评测专门做过对比，结论是两者各有优势。在很多日常问答任务上，GraphRAG 反而不如标准 RAG 准确，延迟也更高。把图谱理解成一个"第二层索引"更准确——它帮你做关系推理，但它不是地基。
实操建议：先把基础的混合检索做好。语义搜索加关键词检索，再加一个重排序模型，这套组合在绝大多数场景够用了。"这篇论文里某个定义在哪""这份讲义里某个概念怎么解释""帮我找出处并给引文"——混合检索就能覆盖。等你发现需求升级了，开始关心文档间的关系、想要跨材料的时间线和概念网络，再加图谱不迟。
本地部署的保密边界怎么画
用 Codex CLI 或 Claude Code 在本地搭建知识系统完全可行，但有一个区分必须想清楚："本地执行"和"本地推理"不是一回事。
Codex CLI 可以在本地目录里读文件、改代码、跑脚本，这些操作确实在你自己的机器上完成，它也支持接入 Ollama 之类的本地模型。拿它做知识系统的工程助手和编排工具没问题。
但如果底层推理用的还是云端模型，你实际得到的是"本地索引加本地工具，推理在远端"。检索结果和拼好的 prompt 还是要发到云端，这不等于全链路本地化。
关键策略是把敏感数据挡在检索层：
- 原始文档、切块、embedding、全文索引——全部留在本地
- 云端模型只看到经过检索筛选后的最小化结果
- 即使模型在云端，它接触到的也只是与当前问题相关的几个片段，而非完整知识库
如果要做到更彻底——从索引到推理全部私有化——就把模型 provider 也换成本地的。Codex 和 Claude Code 都支持接入本地模型。代价是本地模型能力通常不如云端大模型，但对知识库问答这类任务，小模型往往够用。
对独立开发者的实际意义
这条技术路线的结构其实很清晰：混合检索是地基，重排序是标配，图谱是可选的第二层，本地化部署是保密性的兜底方案。对一人公司来说，不需要一步到位搭完整套系统。先用现成的混合检索方案把自己的知识库跑起来，遇到瓶颈再逐层叠加，这比一开始就追求最复杂的架构务实得多。已经在动手搭建的人，比停留在讨论阶段的人领先了不止一步。