最近Claude 4+发布了。上下文窗口扩展到了惊人的程度号称能一次性处理几十万甚至上百万字的文档。这让很多人开始讨论有了这么大的上下文还需要向量检索吗。

这个问题在我们团队也引起了热烈的讨论。有人说大模型的上下文越来越大向量检索迟早会被淘汰。也有人说向量检索有它不可替代的优势不会被完全取代。

这篇文章我想深入分析一下向量检索和Claude 4+长上下文这两种方案各自的优缺点以及在不同场景下到底该选哪个。

两种方案是什么

先简单介绍一下这两种方案。

向量检索也就是我们常说的RAG检索增强生成。它的原理是把文档切成小块转换成向量存在向量数据库里。用户提问的时候先把问题转换成向量在向量数据库里检索最相关的几块内容然后把这些内容和问题一起传给大模型让大模型基于检索到的内容来回答。

Claude 4+长上下文就是直接把整个文档都放进大模型的上下文窗口里让大模型直接阅读整个文档然后回答问题。不需要检索不需要切块直接把所有内容都给大模型。

这两种方案都能解决大模型知识不足的问题让大模型能基于特定的文档来回答问题。但它们的实现方式完全不同。

向量检索的优缺点

先说说向量检索的优点。第一个优点是成本低。向量检索只需要把检索到的几块内容传给大模型。一般也就几千字token用量很少。而长上下文方案要把整个文档都传进去可能是几十万字token用量是向量检索的几十倍甚至上百倍。对于大规模应用来说成本是一个很重要的因素。如果每天有大量的查询向量检索的成本要比长上下文低得多。第二个优点是速度快。向量检索先做检索这个过程很快一般几十毫秒就能完成。然后把检索到的少量内容传给大模型大模型生成回答也很快。而长上下文方案要把几十万字的内容都传给大模型。光是传输和处理就要花不少时间。大模型要读完这么长的内容再生成回答速度也会慢很多。第三个优点是准确率高。向量检索会把最相关的内容检索出来放在上下文里。大模型只需要关注这几块相关的内容不容易被无关的信息干扰。而长上下文方案大模型要在几十万字的内容里找到相关的信息。这对大模型的注意力是一个很大的考验。很多研究表明大模型在处理长上下文的时候会出现中间遗忘的问题就是对上下文中间部分的内容关注度不够容易漏掉关键信息。第四个优点是支持超大规模的知识库。向量检索理论上可以支持无限大的知识库。不管是几百万篇文档还是几亿条数据都能存到向量数据库里。检索的时候只取最相关的几块。而长上下文方案受限于上下文窗口的大小。就算Claude 4+能支持上百万字那也是有限的。如果你的知识库有几千万字那就不可能全部放进上下文里。

再说说向量检索的缺点。第一个缺点是实现复杂。向量检索需要做文档切块向量化存储检索等一系列步骤。每个步骤都有很多细节需要处理。比如切块的大小怎么定重叠多少用什么embedding模型检索的时候取多少块等等。这些细节都会影响最终的效果。要做好向量检索需要不少的技术积累。第二个缺点是检索可能不准确。向量检索的效果取决于检索的质量。如果检索到的内容和问题不相关那大模型就没法给出正确的回答。特别是对于一些复杂的问题可能需要综合多个部分的内容才能回答。这时候简单的向量检索可能就不够用了。第三个缺点是切块会丢失上下文。向量检索需要把文档切成小块。切块的时候可能会把一些连贯的内容切到不同的块里。这样检索到一块内容的时候可能缺少了上下文导致大模型理解不准确。再说说Claude 4+长上下文的优点。第一个优点是实现简单。长上下文方案不需要做切块向量化检索这些复杂的步骤。直接把文档内容和问题一起传给大模型就行。实现起来非常简单。只要调用大模型的API把内容传进去就能得到回答。不需要维护向量数据库不需要处理检索的逻辑。第二个优点是不会遗漏信息。长上下文方案把整个文档都给了大模型。理论上大模型能看到所有的内容不会因为检索不到而遗漏信息。对于一些需要综合全文来回答的问题长上下文方案可能会有优势。第三个优点是适合复杂的推理。有些问题需要大模型深入理解文档的内容进行复杂的推理。这时候把整个文档都给大模型让它自己去分析和推理可能效果更好。而向量检索只给了几块相关的内容大模型可能缺少足够的上下文做不了复杂的推理。再说说长上下文的缺点。第一个缺点是成本高。这是最明显的缺点。把几十万字的内容传给大模型token用量非常大。一次查询的成本可能是向量检索的几十倍甚至上百倍。如果你的应用每天有大量的查询那成本会非常高。第二个缺点是速度慢。长上下文方案传输和处理大量的token需要时间。大模型读完几十万字再生成回答也需要时间。用户可能需要等几十秒甚至几分钟才能得到回答。这对于很多应用来说是不可接受的。第三个缺点是准确率不一定高。虽然长上下文给了大模型所有的内容但大模型不一定能准确地找到相关的信息。研究表明大模型在处理长上下文的时候会出现中间遗忘和注意力稀释的问题。也就是说上下文越长大模型的注意力越分散越容易漏掉关键信息。有时候反而不如向量检索把最相关的内容直接给大模型。第四个缺点是受限于上下文窗口。虽然Claude 4+的上下文窗口很大但也是有限的。如果你的文档超过了上下文窗口的大小那就没法用长上下文方案了。而且上下文窗口越大成本越高速度越慢。所以实际上能用的上下文大小是有限制的。

不同场景的选择

分析了优缺点之后我们来看看不同场景下到底该选哪个。

第一个场景知识库问答文档量大查询频繁。

这种场景首选向量检索。因为文档量大长上下文放不下。查询频繁长上下文的成本太高。向量检索成本低速度快准确率也有保证。

比如企业内部的知识库问答客服系统的问答这些都适合用向量检索。

第二个场景单篇长文档的深度分析。

这种场景适合用长上下文。因为只有一篇文档虽然长但能放进上下文窗口。而且深度分析需要大模型理解全文进行复杂推理。

比如让大模型分析一份几十页的合同找出风险点。或者让大模型总结一篇长篇论文的核心观点。这些都适合用长上下文。

第三个场景对响应速度要求高的应用。

这种场景首选向量检索。长上下文的速度太慢用户等不起。向量检索能在几百毫秒内返回结果用户体验好。

比如智能客服实时问答这些应用对响应速度要求高适合用向量检索。

第四个场景对成本敏感的应用。

这种场景也是首选向量检索。长上下文的成本太高大规模应用不划算。向量检索每次查询的成本很低适合大规模使用。

第五个场景需要最高准确率的关键应用。

这种场景可以考虑两种方案结合。先用向量检索找到最相关的内容。然后把检索到的内容加上一些上下文传给大模型。或者对于一些复杂的问题再用长上下文做深度分析。

两种方案结合取长补短可能效果最好。

我们的实践

在我们的项目中我们用的是向量检索为主长上下文为辅的方案。

大部分的查询用向量检索来处理。这样成本低速度快能满足大部分用户的需求。

对于一些复杂的查询向量检索的效果不好的时候我们会自动切换到长上下文模式。把更多的内容甚至整个文档传给大模型做深度分析。

这样既保证了大部分查询的效率和成本又能在需要的时候提供更深度的分析。

我们还做了一些优化。比如在向量检索的时候不只取最相关的几块还会取这些块的前后文保证上下文的完整性。还会做重排序把最相关的内容排在最前面。

通过这些优化向量检索的准确率已经能满足大部分场景的需求了。

未来的趋势

最后聊聊未来的趋势。

我认为向量检索和长上下文不会是互相取代的关系而是互相补充的关系。

大模型的上下文窗口会越来越大。这是肯定的。但不管上下文多大都是有限的。而且上下文越大成本越高速度越慢。所以向量检索依然有它的价值。

未来可能会出现更多混合的方案。比如用向量检索做粗筛然后用长上下文做精排和深度分析。或者根据问题的复杂度自动选择合适的方案。

而且向量检索本身也在不断发展。比如多模态向量检索知识图谱增强的检索自适应切块等这些技术都会让向量检索的效果越来越好。

所以不用纠结哪个会取代哪个。根据自己的场景选择合适的方案或者把两种方案结合起来才是最好的选择。

写在最后

向量检索和Claude 4+长上下文各有优缺点。没有哪个是绝对的好也没有哪个是绝对的坏。

选择哪个取决于你的场景。如果文档量大查询频繁对成本和速度敏感那就选向量检索。如果是单篇长文档的深度分析对成本和速度不敏感那就选长上下文。

当然最好的方式可能是把两种方案结合起来取长补短。

最后用一句话来结束这篇文章：没有最好的技术只有最合适的技术。根据场景选择方案才是王道。

愿每一个做AI应用的人都能选择合适的技术做出好的产品。