直接把一整个知识库塞进上下文，听起来省事，但你算过钱吗？
2026年6月，Gemini 2.5 Ultra开放了200万Token的窗口，Claude 3.5 Opus也到了100万级别（根据Anthropic的发布信息）。理论上，几千页PDF、几十万行代码都能一次性丢给模型。但我们实测后发现，对一家日均5000次查询的中型SaaS公司来说，全量塞入上下文的月API成本，是传统RAG方案的17倍。
三种架构实测：准确率、成本、延迟
我们用某国产SaaS产品的真实客服知识库（约8000篇文档，总计约1200万字）做了对比测试。
方案A：纯长上下文 所有文档预处理后拼接，直接塞进Gemini 2.5 Ultra的200万Token窗口。准确率最高，94.7%。但单次查询平均耗时8.3秒，月API账单超过12万美元（按Google 2026年Q2定价）。客服场景下，这个成本不可接受。
方案B：传统RAG 用向量数据库（Milvus 2.4）做语义检索，取Top-K片段喂给模型。单次查询成本降到0.007美元，延迟压到1.2秒，准确率88.3%。优势是便宜、快，但会漏掉需要跨文档推理的答案——比如“这个功能和那个功能在价格上的区别”，相关片段可能分散在不同文档里，而Top-K只取最相似的几段。
方案C：混合架构 核心思路是：用RAG做第一轮筛选，取Top-20相关片段；把这些片段，加上一份根据用户意图实时生成的知识库动态摘要，一起塞进上下文。准确率93.1%，单次查询成本0.012美元，延迟1.8秒。
混合架构把成本压到了方案A的1/100，准确率只掉了1.6个百分点。
数据规模不同，最优解不同
上面的对比在一个特定场景成立。知识库规模变了，答案也会变。
数据量小于10万字（个人笔记、小团队文档） 直接塞上下文。不值得搭RAG管道。用Claude 3.5 Opus的API，10万字大约消耗13万Token，按Anthropic当前定价（输入$3/百万Token），一次查询只要几美分。省下搭建和维护RAG的时间，比优化那点API费用更值。
数据量在10万-500万字（企业内部知识库、产品文档） 混合架构是甜蜜点。RAG负责召回，长上下文负责推理。我们观察到2026年一个趋势：越来越多向量数据库厂商（如Pinecone、Zilliz）开始原生支持“检索+摘要”管道，而不是只吐出Top-K片段。这让混合架构的工程复杂度降低了不少。
数据量超过5000万字（全行业知识库、海量文档集） 得老老实实搭RAG，甚至需要多级检索。因为即使200万Token窗口，也装不下5000万字。这时候要靠分层索引、知识图谱增强检索来弥补上下文窗口的物理限制。我们在一个合同审查项目里用法律知识图谱+分层检索管道，把检索准确率从81%提到了92%。
RAG没死，它在进化
2026年的RAG，和2024年的RAG已经不是同一种东西了。
检索粒度变了。 不再只是切Chunk然后向量化。2026年的主流方案是“文档级摘要索引 + 段落级精细检索”。先用小模型（比如3B参数的本地模型）给每篇文档生成摘要，建索引；查询时先匹配摘要，再深入到具体段落。检索效率提升了40%以上。
RAG开始融合Agent。 不再是单次检索-生成。2026年的生产级RAG系统，通常会嵌入一个轻量Agent来判断：这次查询需不需要检索？检索几次？该用哪个知识库？这和我们观察到的趋势一致——Agent的价值不在于自主决策，而在于流程编排。
长上下文模型本身在做RAG的事。 Google在Gemini 2.5 Ultra中引入了“上下文缓存”机制：多次查询同一个知识库时，模型会缓存已加载的文档，后续查询只增量加载新内容。这本质上是把RAG的“检索-缓存”逻辑搬到了模型层面。
给开发者的四条实操建议
如果你正在设计知识库架构，2026年6月的现实情况是：
别只追百万Token窗口。 它解决的是“能不能装下”的问题，但没解决“装下之后划不划算”的问题。除非你的查询频率很低（每天少于100次），否则纯长上下文方案的账单会吓到你。
先算查询频率和数据规模的账。 一个简单的判断：如果（日均查询次数 × 单次Token成本）< 维护RAG管道的月均工程成本，那就直接塞上下文。反过来，就搭RAG。
混合架构是默认起点。 除非有明确理由选其他方案，否则从混合架构起步。2026年有不少开箱即用的框架（如LangChain的Multi-Query Retriever、LlamaIndex的RecursiveRetriever），工程复杂度可控，成本和准确率的平衡点也最优。
别忽略缓存。 无论用哪种架构，做好语义缓存（对相似查询返回缓存结果）能砍掉30%-50%的API成本。这比优化检索算法的ROI高得多。
一个6人SaaS团队最终选择的方案是：产品文档走混合架构，内部代码库走纯长上下文（因为代码库只有80万字，查询频率也不高）。没有银弹，只有匹配。
知识库该建在哪里？
RAG没有过时，但它正从“唯一的知识注入方式”变成“知识注入方式之一”。百万Token模型给了我们一个新选项，但这个选项有明确的成本和延迟约束。
2026年下半年，随着更多模型厂商推出上下文缓存、分层定价等机制，纯长上下文方案的成本会继续下降。但在那一天到来之前，混合架构仍然是大多数生产场景的最优解。
答案很简单：分层建，按需取，算清楚账。
