2 长上下文和 RAG 分别适合什么场景
1️⃣ 考察意图
面试官想考察的不是“背概念”，而是场景化系统设计能力——能否根据业务约束（数据规模、延迟、成本、更新频率）做出工程取舍。刁钻点在于：很多人会答“长上下文适合长文档，RAG适合知识问答”，但面试官真正想看的是边界条件：比如上下文窗口到128K后RAG是否被淘汰？延迟敏感场景下长上下文的推理成本如何量化？答好了能展示出对LLM推理效率、检索系统瓶颈和混合架构设计的硬实力。
2️⃣ 标准答
核心原则：没有银弹，只有trade-off。 决策基于三个维度：数据特性（静态vs动态）、延迟预算（实时vs离线）、成本约束（token vs 检索开销）。
长上下文场景（适合）
- 全局推理任务：如长文档摘要（论文/合同）、故事连贯性生成、代码库重构分析。需要模型“看到”所有上下文才能做因果推理，RAG的片段化检索会丢失跨段依赖。
- 低延迟容忍：离线批处理或非实时场景。例如，用GPT-4-128K处理整本小说摘要，单次推理成本约$0.3（按$15/1M tokens计），但若用RAG分10次检索+5次推理，总成本可能更高且延迟不可控。
- 数据静态且小规模：知识库<1000页且半年不更新。例如，公司内部政策文档，直接塞入上下文避免维护检索索引。
- 实际坑：长上下文模型存在“中间迷失”问题（Lost in the Middle）。解法：将关键信息放在开头或结尾，或使用RoPE扩展（如YaRN）调整位置编码，但需注意微调后可能降低短上下文性能。
RAG场景（适合）
- 知识密集型问答：如客服系统（产品手册实时更新）、法律条文检索（需精确引用条款）。RAG通过BM25+稠密检索（如DPR/ColBERT）保证召回率，且可解释性强（直接返回原文片段）。
- 高实时性要求：新闻摘要、股票分析。RAG的索引可分钟级更新（如用Elasticsearch增量索引），而长上下文模型需重新处理整个输入。
- 多文档交叉推理：如对比10份财报中的营收数据。RAG先检索相关段落，再用LLM聚合，避免长上下文模型因注意力分散而遗漏细节。
- 成本敏感：RAG的token消耗仅为长上下文的10%-30%。例如，处理100页文档（约50K tokens），RAG检索+推理成本约$0.05，而长上下文单次推理需$0.75（按GPT-4价格）。
- 实际坑：检索质量是瓶颈。解法：使用混合检索（BM25+向量）加重排序（如Cohere Rerank 3），并设置chunk重叠（如256 tokens chunk，64 tokens overlap）避免切碎语义。
混合架构（最佳实践）
- 先RAG后长上下文：例如，客服系统：用户问题先检索产品手册（RAG），若涉及多轮对话历史，再将检索结果+最近10轮对话（<8K tokens）拼入上下文。这兼顾了知识实时性和对话连贯性。
- 决策公式：若数据更新频率>1次/天 或 延迟要求<500ms → 选RAG；若任务需全局因果推理 且 数据量<500页 → 选长上下文；否则用混合。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从数据特性、延迟预算、成本约束三个层面回答。数据层面：静态小规模用长上下文，动态大规模用RAG；延迟层面：实时场景（<500ms）必须RAG，离线批处理可考虑长上下文；成本层面：长上下文推理token成本是RAG的3-10倍。总结一句：没有绝对优劣，核心是根据业务约束做trade-off，实际落地常用混合架构——先RAG检索关键片段，再放入长上下文模型做综合推理。”
4️⃣ 高频追问 & 应对
追问 1：你说长上下文有“中间迷失”，具体怎么量化？比如128K窗口下，信息放在第50K位置和最后1K位置，召回率差多少？
根据【通用知识】Anthropic的论文《Lost in the Middle》，当关键信息位于上下文中间（25%-75%位置）时，模型准确率下降约15-20个百分点（从80%降至60%）。解法：一是位置重排，将关键信息放在开头或结尾；二是使用注意力掩码（如LongLoRA的shifted sparse attention）强制模型关注中间区域。实际工程中，我会在prompt模板中固定“重要信息在开头”的格式。
追问 2：如果数据量是100万页，但更新频率很低（一年一次），你选哪个？为什么？
选RAG。虽然数据静态，但100万页（约500M tokens）远超当前任何长上下文模型的经济上限（GPT-4-128K单次推理成本约$7500）。RAG通过分片索引（如用FAISS建向量库，每片1000页）和级联检索（先粗筛再精排），总成本可控制在$100以内。关键trade-off：RAG牺牲了全局推理能力，但可通过多轮检索（如ReAct模式）弥补。
追问 3：混合架构中，RAG检索结果和长上下文拼接时，如何避免信息冗余或冲突？
核心是去重与优先级排序。我会用MMR（最大边际相关性） 算法对检索结果去重，确保多样性；然后按时间戳（最新优先）和相关性分数（BM25+向量得分加权）排序。冲突处理：若检索结果与上下文矛盾，用LLM的自一致性机制（如多次采样投票）或显式提示“以最新信息为准”。实际落地中，我在客服系统里加了一个冲突检测模块，用余弦相似度>0.9的段落标记为重复，只保留一个。
5️⃣ 避坑 · 常见错误答法
- ❌ “长上下文会取代RAG，因为模型窗口越来越大。” → ✅ “窗口增大不解决检索效率问题。128K窗口下，RAG的检索成本（$0.01/次）仍远低于长上下文推理（$0.75/次），且RAG支持实时更新，这是长上下文无法替代的。”
- ❌ “RAG就是检索+生成，很简单。” → ✅ “RAG的难点在检索质量：chunk大小、重叠率、检索器选择（BM25 vs 向量）直接影响效果。例如，chunk太大（>512 tokens）会稀释语义，太小（<64 tokens）会丢失上下文。实际需A/B测试确定最优参数。”
- ❌ “所有场景都用混合架构最保险。” → ✅ “混合架构增加系统复杂度（维护两个管道、处理冲突）。对于简单场景（如单文档问答），直接用长上下文更简单可靠。决策应基于ROI：若混合架构提升<5%但成本翻倍，就不值得。”
6️⃣ 简历呼应
- 如果你有RAG项目：从“实际落地中如何平衡检索延迟与召回率”切入，举例你如何用HNSW索引（efConstruction=200, efSearch=50）将检索延迟从200ms降到50ms，同时保持召回率>95%。
- 如果你只做过传统NLP：用“信息检索系统”类比——长上下文像全文扫描（适合小数据），RAG像倒排索引（适合大数据）。强调你对BM25、TF-IDF的理解，以及如何迁移到LLM场景。
- 如果你是校招无项目：聚焦论文复现——比如复现《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中的DPR训练，并对比长上下文模型（如Longformer）在相同数据集上的效果，展示你对trade-off的量化分析能力。
- 《Lost in the Middle: How Language Models Use Long Contexts》 (Anthropic, 2023)
- 《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》 (Lewis et al., 2020)
- 《LongLoRA: Efficient Fine-tuning of Long-Context Transformers》 (Chen et al., 2023)
- 《HyDE: Precise Zero-Shot Dense Retrieval without Relevance Labels》 (Gao et al., 2022)
- FAISS官方文档：HNSW索引参数调优指南 (efConstruction, efSearch, M)