面对爆炸式增长的模型上下文窗口，传统的向量检索RAG是否还值得投入？本文基于实际投研项目经验，对比分析了RAG与长上下文的优劣，并提供了实用的技术选型决策树。
智能速览
向量检索在精确查询中经常失效，返回相似但不准确的信息
文档分块会破坏表格、代码等结构化信息的完整性
长上下文模型在100K tokens以内场景下可直接替代RAG
代码检索场景中，精确搜索比语义检索更可靠
混合检索策略结合了关键词、向量搜索与长上下文优势
精华内容
当模型能轻松处理50页财报时，复杂工程化的RAG系统是否还有必要？让我们从实际效果出发，理性评估各种技术路线。
检索失效
向量检索基于语义相似度假设，但在精确查询中经常失效。例如查询茅台2024年净利润，系统可能返回2023年数据、五粮液数据或泛泛的盈利描述，而真正答案因表述简洁得分反而不高。这说明向量空间中，答案与看似答案的内容距离往往很近，导致检索精度下降。
分块代价
为向量化而切割文档会破坏信息完整性。财报中的财务数据表被切成碎片，代码函数被拦腰截断，跨段落的逻辑链条被打断。即使采用1000字符分块+200字符重叠的策略，仍经常遇到检索结果缺少关键上下文的情况。这种信息损失是向量检索的固有缺陷。
维护难题
完整RAG系统需要向量数据库、分块策略优化、embedding模型选择、同步机制和质量监控等组件，带来显著工程负担。更严重的是，向量空间缺乏时效性感知，新旧信息冲突时无法自动判断，元数据仅作为外部过滤条件，不参与相似度计算，导致过时信息可能被优先检索。
长文优势
2024年大模型上下文窗口突破200K tokens，使大部分场景不再需要RAG。直接输入50页财报或5万行代码库，模型能自主保持注意力，不遗漏细节，理解跨段落逻辑和表格结构。虽然单次调用成本约6美元，但省去了向量数据库等基础设施成本，整体可能更经济。
代码实践
顶尖代码AI工具的选择值得借鉴。Claude Code完全依赖ripgrep做精确字符串匹配，工程师公开承认不用RAG，因为代码场景中精确性至关重要，grep结果可预测且毫秒级响应。Sourcegraph的Cody也从架构中移除了embeddings，证明向量化在大规模代码场景确实存在局限。
混合策略
基于实践，推荐混合检索方案：先提取关键词实体进行精确搜索，无结果时再用向量做模糊回退，最后合并结果扩展上下文。用户标记的重点内容可设置权重提权。决策树建议：文档小于100K tokens直接用长上下文；100K-1M tokens根据精确或模糊需求选择；超过1M tokens则采用关键词筛选加向量排序的混合策略。
