目前RAG的替代方案主要有哪些

回复 群友 4814： RAG 现在已经不是“要不要用”的问题，而是“该用哪种检索”的问题。按当前主流做法分四类，从轻到重： 一、长上下文直接塞。上下文窗口够大、语料在几万到几十万 token 量级时，很多团队干脆不做检索，整份文档直接进 prompt，靠 cache 降成本。适合“一份文档反复问”的场景；不适合知识库持续增长、每次只问一小块的情况——成本随语料线性涨，且中间信息容易被忽略（lost in the middle）。 二、把检索做成 Agent 的工具（agentic search）。这是现在替代 naive RAG 最主流的一条：不给模型预检索好的 chunks，而是给它 grep、读文件、sql 查询、网页搜索这些工具，让它自己多轮去找。优点是省掉“切块+向量召回”这一步的精度损失，模型能自己改写 query、顺着线索追；代价是延迟和 token 都高得多。Claude Code 那种仓库检索、Devin 读代码库，本质都是这条路线。判断标准：问题需要多跳、需要拼多个来源时用，一问一答的事实查询用不上。 三、不靠相似度靠结构。把知识组织成知识图谱、文档树、SQL 表、或者 wiki 式的互链文档，检索变成遍历和查询而不是向量近似。GraphRAG 是典型代表，适合实体关系密集的领域（医疗、金融、企业内部组织关系）。成本在构建与维护，不适合天天变的语料。 四、缓存与记忆。把高频问答对、用户偏好、会话摘要沉淀成 cache（prompt cache 或语义 cache），命中就直接返回或注入，绕开检索。厂商侧有隐式 prompt cache，应用侧常见的是 semantic cache。这是省钱层，不是能力层。 几句实务判断： 大多数项目“RAG 效果不好”的原因其实不在检索范式，而在切块策略和评测缺失。换向量库、换 embedding 模型多数时候是白折腾，先量一下召回率（正确段落有没有被召回）再决定换不换。 另外现在这些不是互斥选项。一个现实组合是：小规模稳定语料走长上下文 + cache，大规模走 agentic search 当工具，领域实体关系多的补一层图，全部外面套一层语义缓存。你的语料规模和查询形态大概什么样？说清楚我能给更具体的选型。