目录
前面RAG的内容算是更新完了，我们今天是对RAG做一个扩展。讲讲宣称能代替RAG的三个技术，分别是超长上下文 、Agentic Retrieval 与LLM Wiki 。我们先在开始给出一个结论，就是他们互相之间都没有任何的替代关系。都只是在不同的场景下的不同技术路线，仅此而已。
一、超长上下文和RAG
RAG的过程就像一个流水线，把用户的query转换成embedding向量， 在向量数据库中检索（Retrive）出一些相似度比较高的chunk，再经过ReRank重排序，得到TOK K个chunk，把这些chunk塞到提示词中，让大模型来根据问题和这些chunk来回答问题。
在构建这一套流程时，我们必须做的一个工作就是知识切片，然后将chunk向量化后存入向量数据库中。但是切片可能把知识拆散，割裂文档内部逻辑，关键片段若没被检索出来，就不会进入 prompt。模型不知道答案、又没拿到关键参考资料时（召回率不够高），被迫输出就容易幻觉。
现在推出模型的上下文越来越长，有的甚至宣称百万上下文。那么就有一种观点：利用大模型不断扩展的 "记忆容量"，直接将完整的文档库作为上下文输入，从根本上绕过传统 RAG 架构中的检索与拼接步骤。
但是我们前面给了结论了，这种方法不能替代RAG的，从直观的角度看，提示词太长会非常的耗费token，而且速度也会很慢。从技术上来讲，现在的百万上下问是一件很虚的事情，百万token的上下文窗口只是理论最大值，实际有效利用率仅约25%，如果提示词塞得太多会导致性能大幅下降。我们看一下上一阶段的几个模型：
我们看到95%的模型预训练窗口都是基于4K窗口完成的，也就是说95%的训练的训练数据的提示词 字数是不超过4000个token。5%的后训练是通过一些技术让模型像揠苗助长一样的，从4K窗口4000 token的这个提示词的限制，在极短的时间里，然后硬给它拉到百万级别的窗口上下文。这样的训练，导致这些模型其实没有那么强的能力去消化百万上下文。
现在的模型已经有所改善了，DeepSeek V4只有6%以下的模型训练是在小窗口完成的。大部分数据已经在64K/1M的窗口训练了。
这样的训练对模型的百万上下文的真正能力是有所提升的。那么不考虑成本和速度问题，百万上下文可能也做不到，因为没有太多百万token级别的训练数据，真正的能力还是要打个问号的。
总结一下：百万token级别的上下文
1）对算力消耗太大，成本太高
2）响应速度慢
3）有一定的技术瓶颈
所以到目前为止百万长上下文去替代RAG的可行性确实是偏弱一些。
二、超长上下文的应用场景
超长上下文与 RAG 并非完全对立，而是互补关系。在小体量、单文档场景下，它能提供更连贯的语境；但面对海量知识，RAG 仍是企业级应用的基石。
像单文档强相关的内容如合同，财报；代码，日志，表格等等不适合切片的内容都可以用超长上下问，把文件全部塞到提示词中。