author: 吴师兄 source: 微信公众号 url: https://mp.weixin.qq.com/s?__biz=MzUyNjQxNjYyMg==&mid=2247519327&idx=1&sn=f2e1ffd006218b7f92b04da05415c1c2&chksm=fb18d75b24db077a9f1a689a12b516e21f79721944fe5fab7b7e42b3dd547c455046d7862a47&mpshare=1&scene=1&srcid=0508k8T7s2dkBOPAkP4u3rgg&sharer_shareinfo=d0c3240308ff86440fd41937d4985a9a&sharer_shareinfo_first=d0c3240308ff86440fd41937d4985a9a#rd saved: 2026-05-08 10:33:38 tags: - 笔记同步助手

id: 6bc0181d-8dc6-40c0-ba9b-b7d7b334a869

公众号名称：吴师兄学算法

作者名称：吴师兄

发布时间：2026-05-08 10:19

面试官：你的项目里做了RAG知识问答系统，能说说当时为什么选这个方案吗？

我：我们公司文档库比较大，需要支持实时检索，所以用了RAG架构，向量数据库召回加Rerank，整体效果还不错。

面试官：现在Gemini的上下文窗口已经到200万token了，你为什么还在做RAG？直接把文档全塞进去不行吗？

我：长上下文成本太高。

面试官（冷笑）：你算过吗？你们文档库一共多大？

我：大概有几千份文档，每份十几页左右……

面试官：那我告诉你，如果你的文档库只有100份、每份10页，直接塞反而比RAG便宜。你的系统用RAG，是真的需要，还是习惯性用——你连这个都没想清楚？

我：（彻底卡住）

很多做过RAG项目的人，面对这个问题都会卡住。不是技术不懂，是当初选型时根本没认真算过账。今天就把这个问题彻底讲清楚。

简要回答

RAG和长上下文不是非此即彼的问题，是成本、延迟、精度三者的工程权衡题。选型答案取决于三个核心变量：文档库总大小、日均查询量、问题类型。

对于金融保险公司这种场景——5000份文档，日均查询3000次——走完下面的分析第一步，答案就出来了：RAG是唯一可行方案，不是因为"习惯"，是被数字逼出来的。

面试官真正在考的，是你做技术选型时有没有量化思维。说得出"成本高"但说不出具体数字，在他看来等于没答。

RAG vs 长上下文整体选型路径图

一、先把账算清楚

很多人跳过了这一步，直接开始选向量数据库、调Embedding模型。但选型的第一步不是选工具，是算数字。

场景A：小文档库，高查询频次

文档库：100份 × 10页 = 约150万中文字符 ≈ 75万token（中文字符与token换算约1:0.5）

长上下文方案（Gemini 1.5 Pro）：

• 每次查询输入约75万token

• Gemini 1.5 Pro定价：超过12.8万token后，$3.5/百万输入token

• 每次查询输入成本：75万 × $3.5 / 100万 ≈ $2.6

• 日均1000次查询：约$2600/天

RAG方案：

• Embedding是一次性离线成本，75万token × $0.02/百万 ≈ $0.015（只算一次）

• 每次查询召回top-5片段，约2000token

• 每次查询LLM输入成本：2000token × $3.5 / 100万 ≈ $0.007

• 日均1000次查询：约$7/天

结论：同样的文档库，同样的查询量，成本差距约370倍。文档库小但查询频次高，RAG碾压。

场景B：文档库超过任何模型的上下文窗口

Gemini 2.0最大上下文200万token，约折合100万汉字，即约2000页文档。

5000份文档 × 20页 = 10万页，远超模型窗口上限。长上下文方案在数据规模这一步就已经不可行，RAG是唯一选择，没有讨论空间。

场景C：文档库小，查询频次极低（原型或测试阶段）

文档库：50份文档，日均查询不超过20次。

RAG的工程量：向量库选型和部署、Embedding模型选型、Chunk策略设计、Rerank模块接入、评估体系构建——保守估计2-3周工程时间。

长上下文的工程量：在prompt里插入文档，改5行代码，下午就能跑起来。

结论：原型阶段用长上下文，先验证产品方向，确认有价值再迁移RAG。用正确的工具做正确的阶段的事。

三种场景成本与复杂度对比图

二、长上下文的三个真实问题

账算完了，不代表长上下文没有别的坑。即使在成本可接受的场景里，还有三个问题值得认真对待。

问题一：Lost-in-the-Middle，中间内容被系统性忽视

Stanford 2023年论文《Lost in the Middle》做了一个直接测试：把答案放在文档的不同位置，看模型能不能找到。实测结果如下：

• 答案在开头（第1页）：准确率92%

• 答案在中间（第50页）：准确率61%

• 答案在结尾（第100页）：准确率88%

中间位置的信息，模型的注意力会系统性衰减，准确率比头尾低40%。这不是某个模型的bug，是Transformer结构的固有特性。对于保险知识库这类场景，很多关键的免责条款、特殊规则恰好分散在文档中间，用长上下文方案，这些内容可能被稳定地漏掉。

问题二：Prefill延迟在实时场景不可接受

75万token的prefill，在Gemini实测下需要8-12秒。用户能接受的首字响应时间通常不超过3秒。这个缺口靠调prompt填不平。

KV Cache可以缓解，但前提是文档内容稳定。对于法律法规、产品手册这类相对固定的文档，Cache命中率高；对于包含实时数据、频繁修订的知识库，文档一更新Cache就失效，下一次查询还是得付完整prefill的时间。

问题三：成本随查询量严格线性增长

RAG的成本结构：Embedding是一次性离线成本，每次查询只付召回片段的token。文档库加大，召回片段大小基本不变，查询成本几乎不变。

长上下文的成本结构：每次查询都付全量文档的token。文档加大，每次查询成本加大；查询量加大，成本严格线性增长，没有任何批量折扣。

日查询量超过1000次后，两者成本差距开始显著放大，到5000次时差距通常超过百倍。

类似的成本拆解分析，我们在训练营的金融研报RAG项目里做过完整实测，包括BM25、向量检索、Rerank各环节的成本精确到每次查询，这些量化数据在面试里比泛泛而谈有说服力得多。

长上下文三大真实问题图

三、RAG的三个真实问题

说完长上下文的坑，也要说清楚RAG的边界。选型不是给RAG洗白，而是要知道每种方案在什么情况下会失效。

问题一：召回精度存在天花板

向量检索的召回率有上限。工业界做得比较好的系统，Recall@5大概在85-90%左右。这意味着10-15%的查询，正确答案就是召不上来，不是模型不聪明，是答案的语义表示和查询的向量距离太远，或者Chunk切割时把关键内容切断了。

长上下文在这里有天然优势：全文都在上下文里，不存在召回失败的问题。但代价是前面说的成本、延迟、中间内容衰减三个问题同时承受。

问题二：工程复杂度远超想象

一个生产可用的RAG系统，绝不是接一个向量数据库就完了。从上游到下游，每个环节都有坑：

• 文档解析：PDF里的跨页表格、嵌套列表、图片文字怎么处理？

• Chunk策略：固定长度切还是语义切？重叠率设多少？

• Embedding模型：通用模型还是领域微调？

• 向量库选型：Milvus、Weaviate、pgvector，各有什么优劣？

• Rerank模型：Cross-Encoder打分，延迟能接受吗？

• 评估体系：Golden Dataset怎么建？Recall和MRR怎么算？

没有3个月以上的工程经验，很难把这条链路调到生产可用的效果。长上下文绕开了所有这些问题，代价是要承受它自己的三个限制。

问题三：多跳推理能力弱

"条款A规定免赔额1000元，条款B规定特定疾病赔付比例80%，我这个病最终赔多少？"

这类需要跨文档关联推理的问题，RAG召回的是孤立片段。片段之间的关联信息丢失了，模型可能分别召回了条款A和条款B，但无法感知两者之间存在推导关系。

长上下文在这类问题上有天然优势，所有文档都在上下文里，模型可以自由做跨文档关联推理。这是长上下文唯一在质量上胜过RAG的维度，而不只是便利性上的区别。

RAG三大真实局限badcase图

四、选型决策树

把前面的分析整理成一棵决策树，遇到选型问题直接套用：

问题1：文档库总量超过50万token吗（约25万汉字，约500页）？

是 → 长上下文根本装不下，只能RAG，往下不用问了

否 → 继续

问题2：日均查询量超过500次吗？

是 → RAG的成本优势开始显现，推荐RAG

否 → 继续

问题3：问题类型以多跳推理为主吗？

是 → 长上下文有天然优势，推荐长上下文

否 → 继续

问题4：当前是原型阶段还是生产阶段？

原型 → 长上下文，工程成本低，先验证方向

生产 → RAG，可维护性和成本可控

回到面试里的项目：5000份文档远超50万token，走完第一步就出来了，RAG是唯一可行选项。面试官要的正是这个回答方式，不是结论，是能把结论推导出来的过程。

五、混合方案：更务实的工程答案

实际生产系统里，很少有人严格只用一种。大多数成熟系统都在做分层处理。

模式一：用路由层按查询类型选路径

def route_query(query: str, doc_metadata: dict) -> str:
     """根据查询复杂度和文档类型选择检索路径"""
     total_tokens = doc_metadata["total_tokens"]

     # 文档量超出窗口，只能RAG
     if total_tokens > 1_800_000:
         return "rag"

     # 多跳推理问题，且文档量在范围内，走长上下文
     if is_multi_hop(query) and total_tokens < 200_000:
         return "long_context"

     # 高频简单问题，走RAG控成本
     return "rag"

 def is_multi_hop(query: str) -> bool:
     patterns = ["如果…那么", "根据…和…推断", "两者关系", "分别是"]
     return any(p in query for p in patterns)

模式二：KV Cache按文档稳定性分层

对相对固定的文档（产品手册、法律法规、监管条例），用长上下文 + KV Cache。文档不频繁更新，Cache命中率高，prefill延迟只在第一次查询时发生，后续查询直接复用。

对动态文档（用户数据、实时行情、频繁修订的内部规则），走RAG，每次检索都是最新内容，不存在Cache失效问题。

两层策略在同一个系统里可以并存，代价是运维复杂度增加，但成本和延迟都可以控制在合理范围内。

对比总结

RAG vs 长上下文 vs 混合方案横向对比表格图

面试总结

遇到"为什么不直接用长上下文"这个问题，千万不要用"成本高"三个字糊弄过去，面试官一定会追问"你算过吗"。

第一步（15秒）：先给结论，再说推导过程

我们的项目场景是5000份文档，日均查询3000次。先走决策树第一步：文档总量约1500万token，远超Gemini 200万token上限，长上下文方案在数据规模上就不可行。这是硬约束，和成本无关。

第二步（45秒）：用数字说明成本差距

退一步，假设文档量在范围内，日均3000次查询，长上下文方案每次付全量文档token，以75万token、$3.5/百万的定价计算，每天成本约$7800。RAG方案每次查询约2000token，每天成本约$21，差距约370倍。

第三步（30秒）：主动说长上下文的合理使用场景

长上下文不是错误选择，在原型阶段、文档量小、多跳推理为主的场景下，它反而比RAG更合适。我们项目里对固定的监管文件用了长上下文加KV Cache，对高频更新的内部数据走RAG，分层处理。

如果面试官继续追问：

"你们的RAG召回率是多少？怎么评估的？" ——说清楚Golden Dataset构建方式，Recall@5和MRR指标体系，以及离线评估和在线评估的结合方式。

"文档更新后怎么处理？" ——增量Embedding更新机制，只对有变化的文档重新Embedding，Milvus支持实体更新，不需要全量重建索引。

这道题考的不是你知不知道长上下文，而是你做技术选型时有没有量化思维，有没有把成本、延迟、精度三条线放在一起权衡过。背得出选型框架和真的在项目里算过账，面试官追两句就能听出来。

我们训练营里有一个生产级的金融研报RAG系统，RAG vs 长上下文的成本拆解、KV Cache分层策略、混合路由的工程实现，代码和架构都在，各环节成本精确到每次查询，吃透之后遇到这类选型题不会再被数字问住。感兴趣的可以点击了解了解一下，我们会根据你的背景帮你判断适不适合入营。

明显感觉大厂的面试已经变了。。

原创 吴师兄 吴师兄学算法

内容效果不满意？点此反馈