谷歌的Gemini 2.5 Ultra开放API，单次能吃下超过百万Token。理论上，你可以把整个知识库直接丢给它。但“能做”和“划算地做”是两回事。
我们拿一个内部文档问答项目实测了三种方案：
- 纯长上下文直投：每次把约80万Token的全部文档和问题一起扔给Gemini 2.5 Ultra。
- 传统RAG：用Embedding模型检索出最相关的几个片段（约5000 Token），再送给一个较小的模型（如Llama 4 Scout）回答。
- 混合架构：先用RAG筛选出一批候选片段（约2万Token），然后把这些片段和问题一起送给长上下文模型做最终推理。
结果很清楚。纯直投的准确率最高，在复杂推理问题上比传统RAG高出约15个百分点。但代价是，一次查询API成本超过5元，响应延迟超过20秒。
传统RAG成本最低（不到0.1元），延迟也短（3秒内）。但它的软肋在检索精度。如果问题模糊，或者答案散落在文档各处，它就容易漏掉关键信息。
混合架构成了我们的选择。它先用RAG快速筛选出约2万Token的相关内容，再交给长上下文模型。这样，准确率接近纯直投（88%对92%），成本却只有它的十分之一（约0.5元），延迟控制在8秒内。对企业内部知识库查询来说，这个平衡点可以接受。
一张表看三种方案
以10万份技术文档的知识库为例，测试三类查询：事实查找、流程解析、综合推理。
| 方案 | 综合推理准确率 | 单次API成本 | 响应延迟 | 适合场景 |
|---|---|---|---|---|
| 纯长上下文直投 | 92% | 约5元 | 超过20秒 | 查询少、要求极致准确、预算充足的分析场景，比如深度解析长访谈记录。 |
| 传统RAG | 78% | 低于0.1元 | 3秒内 | 高频、成本敏感的客服或内部查询，对答案绝对精准度可适度放宽。 |
| 混合架构 | 88% | 约0.5元 | 约8秒 | 当前最均衡的生产选择。适合企业知识库、技术文档支持、合同审阅等。 |
你的知识库该怎么选？
别只看百万Token的噱头，选型关键在于知识库大小和查询频率。
知识库小于10万Token（约100页文档）？ 直接投喂长上下文模型可能是最优解，省去维护RAG的麻烦。但要注意成本：按Gemini 2.5 Ultra定价，每天查1000次，月成本可能数万元。
知识库在10万到1000万Token之间（百页到上万页文档）？
这是混合架构的主场。你需要一个可靠的Embedding模型（如bge-m3）和向量数据库做第一轮筛选。核心是调好检索的召回条数和Token上限。
知识库超过千万Token（数十万页文档）？ 传统RAG仍是基础，但需要精细的分块和重排序策略。也可以考虑多级混合：先用RAG粗筛，再用长上下文模型精读。
RAG没死，它在进化
长上下文模型正在改变RAG的设计思路。过去RAG要精准捞出“针”给模型；现在，我们可以给模型更多上下文，让它自己在“草堆”里找针，甚至综合多根针。
这带来几个变化：
- 检索粒度变粗：从句子级检索转向段落或章节级检索，更利于模型理解上下文。
- RAG角色转变：从“答案生成者”变为“高效预处理器”，主要任务是过滤掉90%的无关信息，降低后续处理负担。
- 对Embedding要求更高：要为长上下文模型提供更优质的“草堆”，需要能更好理解复杂语义的Embedding模型。
所以，回到最初的问题：还要不要搭RAG？**要，但得用新方法。**混合架构是目前性价比最高的解法。如果只是快速试验或知识库不大，直接投喂文档也是简单的开始。
就像我们实测车芯跑模型，纸面算力和实际体验隔着工程鸿沟一样，选择知识库架构，最好的方法是：用你的真实文档和问题，花时间分别测试三种方案。数据会告诉你答案。
