95% 向量资源节省，火山引擎云搜索 RAG 技术体系演进

2023年，大模型横空出世，惊艳全场。转眼到了2024年，RAG技术成了绝对的主角。

RAG的优势在于，它能让大模型在不更新参数的前提下，获取必要的上下文信息，从而有效缓解幻觉问题。而随着大模型技术不断成熟和行业落地加速，大家对RAG系统的期望早已不是“看着酷炫”就够用了。企业和组织开始追求更可靠、可扩展的RAG方案，真正服务于业务。

与此同时，支撑RAG的向量数据库市场也打得火热。但仔细看看现在的向量数据库实现，不管是插件形式还是专用系统，底层用的多是HNSW这类公开算法，关键指标比如召回率其实拉不开太大差距。那么，一个企业级方案要想真正脱颖而出，到底得在哪些方面下功夫？

1 向量数据库：RAG的心脏

RAG的出现初衷是为了解决大模型幻觉，但它其实也标志着搜索范式的转变。

过去我们通过搜索框输入关键词，自己翻找内容。搜索靠关键字和技巧，很容易定位目标。而问答基于自然语言提问，不依赖关键字，传统的关键词检索很容易因为问法不同而漏掉内容。在这种场景下，语义检索的重要性自然凸显。于是大家开始借助向量数据库做语义检索，再把结果接入RAG。就像MySQL在传统Web应用中的角色一样，向量数据库成了RAG应用的核心基础设施。

在这样的背景下，火山引擎云搜索团队提供的RAG方案可以看作一个两层架构：上层提供RAG框架服务，包括大模型集成、LangChain集成、模型管理、混合检索等；下层则是向量检索能力。作为一项基础技术，单纯的向量检索可能不会引起太多开发者注意。但在服务ToB客户的过程中，团队发现RAG场景里向量数据的规模非常惊人——从常见的千万级别，到10亿级别，甚至100亿级都有。在这种规模下，向量检索方案的选择就至关重要了，因为成本和稳定性都会面临严峻挑战。

另外，RAG的真正价值在于提供更准确的回答和更快速的搜索，本质上跟搜索引擎很像。如果想把搜索产品扩展为RAG产品，ES和OpenSearch是最佳选择之一。

火山引擎云搜索服务正是兼容Elasticsearch/OpenSearch的托管在线分布式搜索方案。早在2022年4月上线时，它就内置了向量检索能力。实际上，团队从2020年就开始应用向量检索技术——当时在ES 7.1版本上集成了该技术，用于满足集团内部的多模态检索需求。

技术路线上，云搜索团队选择以开源开放的思路建设向量检索能力，团队成员还成了OpenSearch开源项目向量检索功能模块的维护者，也是该模块中唯一来自非AWS的维护者。大模型技术兴起后，团队从市场需求出发，从底层向量检索到上层应用服务，针对每个环节都做了增强，形成了一套完整易用的RAG应用方案。

从专有到集成的技术趋势

2022年，向量数据库领域融资热潮涌动，多家专有向量数据库厂商获得巨额投资。但技术潮流说变就变。今年6月，OpenAI收购了实时分析数据库Rockset，这标志着向量数据库发展进入新阶段：向量数据库不再是独立的特性，而是集成在更大平台中的组件。

与Chroma、Milvus、Pinecone等专有向量数据库不同，Rockset、ES、Redis等商业数据库选择通过插件形式加入向量检索能力。Rockset甚至在今年4月才正式引入向量搜索功能。OpenAI选择Rockset而非专有向量数据库，外界普遍认为这释放了一个信号：

这个趋势与火山引擎云搜索服务的发展路径不谋而合。团队选择在开源版ES和OpenSearch基础上增加向量功能，一方面能充分利用多年积累的文本检索和向量检索经验，另一方面也是站在巨人肩膀上增强整体竞争力。

在他们看来，向量数据库更像是一种底层能力。客户使用时，不会单纯地存储或读取向量数据，而是把向量数据库与应用场景结合起来——比如RAG、以图搜图等语义检索方案。很多客户其实就是从原本的搜索应用升级到RAG，迁移成本并不高。所以，如果一个数据库能提供更多上层应用的支持能力，对客户来说会更有价值。

另一方面，在传统数据库里实现向量，相当于给原有场景插上了新的翅膀，处理能力更强。云搜索团队在实践中已经认识到这一点，所以随着业务发展，他们将向量检索与文本检索结合，实现了混合检索能力。这种融合扩展了产品使用场景，在更大范围内实现了功能和性能的提升，也提高了产品竞争力。

在一些实际应用中，复杂的场景下单纯用DSL展开并不能满足需求，尤其是需要优化搜索准确率的时候。但搜索原生生态系统已经提供了丰富的插件能力，可以有效优化和增强搜索性能。引入向量检索后，在开源版ES或OpenSearch中，可以与原有的全文搜索引擎结合，实现复杂的结构化查询，从而显著提高准确率，达到非常好的效果。

举个例子，一篇2万字的文章，前半部分讲某个事物的发展史，后半部分的结论却推翻了前面的结论。如果只检索到前半部分内容，结果就会跟实际意图相反。这种情况就需要结构化混合检索，结合关键字和向量检索，才能更好地匹配专有名词和复杂结构，获得更准确的结果。

像云搜索服务这样的产品，既支持向量检索，也支持在向量检索基础上的复杂结构化检索。同时在结构化检索基础上通过插件扩展功能，提供干预、混排和重排等能力。从实际实践来看，处理专业文档时，借助这种增强的结构化查询检索，准确率远远优于纯向量检索。

开源才不怕绑定

在开源投入上，云搜索团队很早就参与了开源ES社区的建设。字节跳动内部很早就使用开源版ES支撑抖音、巨量引擎等核心业务。随着集团业务发展，业务部门对多模态检索有了需求，团队发现这些向量检索需求跟他们现有的ES使用场景可以结合。而当时，Elasticsearch还没有提供向量检索能力。

亚马逊则较早地在开源ES发型版本OpenDistro上以插件形式实现了向量检索能力，2019年发布了并开源了该插件——也就是OpenDistro k-NN插件。鉴于当时的实际情况，云搜索团队在2020年将k-NN方案引入内部实践，同时积极参与社区建设。2021年4月，亚马逊基于开源ES 7.10.2版本分叉创建了OpenSearch项目，继承了OpenDistro几乎所有扩展功能，自然也包括了向量检索k-NN插件。

出于这些原因，在云搜索服务商用之后，团队决定继续通过OpenSearch来构建自身向量能力：“为了更好地满足开源需求，并遵循以开源为主导的思路，我们决定采用更加开源的方式来提供搜索服务。”

选择OpenSearch来构建向量能力，不仅看中了它的开源优势，也看重了它与开源ES的技术传承。OpenSearch的检索体系从ES演变而来，是持续演进的技术体系，也是大家熟悉的技术栈。基于OpenSearch构建向量检索，能更好地利用之前积累的内部经验。

随着RAG和大模型的发展，对向量检索的要求不断提高。首先是向量维度的变化，其次是向量和文本结合的功能性需求，另外还有对搜索准确性的更高要求。核心数据库，尤其是向量场景下，需要不断迭代升级来满足大模型场景下的搜索需求。

从2020年开始，云搜索团队进行向量检索开发，并将向量检索与全文检索结合。在这个过程中提出了很多功能，这些功能一开始服务字节跳动集团业务，云搜索服务产品上线后也面向外部客户。同时本着“开源开放”的基本策略，团队从引入向量检索能力开始，就将支持内部业务所需的新功能引入并贡献给OpenSearch（当时的OpenDistro）社区。

RAG和向量检索在今年受到了极大关注。火山引擎云搜索团队在过去几年持续参与OpenSearch社区向量检索功能的建设，今年团队成员被邀请成为该项目维护者（maintainer），这是一个重要的里程碑。

“将我们的技术贡献给OpenSearch社区，是一件成就感比较大的事情，”火山引擎云搜索团队鲁蕴铖分享道，“这不仅意味着我们的技术得到了认可，更重要的是，我们能够与社区一起共建一个更多人使用的服务、一个更加完善的搜索生态。”

鲁蕴铖认为，开源不仅是一种开发模式，更是一种理念。秉承开源理念，火山引擎云搜索团队能够与社区携手合作，共同推动搜索技术进步。这不仅促进整个社区的繁荣发展，对火山引擎自身的产品发展也是有利的。

“开源产品需要持续的维护和迭代，”鲁蕴铖强调，“而社区的贡献正是推动产品发展的重要动力。我们积极参与OpenSearch社区的建设，不仅为产品带来了新功能和特性，也提升了产品的稳定性和性能。”

而且，“

。”

2 一套RAG系统，多种向量算法引擎

随着业务增长，为了满足大规模内部业务和外部客户的需求，团队对向量检索能力进行了持续迭代。尤其在ToB场景下，用户的业务场景各不相同，数据规模千差万别，关注点也不一样。一个好的数据库产品，应该尽可能多地支持不同规模的业务场景。比如不同业务向量数据的数量可能是10万级别、千万级别、10亿，甚至100亿以上。除了数量级，用户采用的向量维度也在逐步增加——虽然不少用户还在用128或512维的向量，但业界一些向量embeddings服务厂商如微软Azure和OpenAI已经支持到3072维，云搜索产品也已经支持存取多至16000维的向量数据。数据条数越大，维度越高，对检索资源的需求也越高。

为了匹配不同规模的需求，火山引擎云搜索团队调研了多种引擎，希望在原有开源ES和OpenSearch基础上进行扩展。最终，他们率先引入了Faiss引擎。通过将Faiss与现有的全文检索能力结合，为内部集团业务提供向量检索服务。

另外，HNSW加上PQ向量压缩是目前已有向量数据库里用得最多的算法，虽然能满足可能百分之八九十的云搜索用户需求，但这两者其实已经发表很久了。火山引擎云搜索的应用场景也比较多样化，处理的数据规模可能达到几百亿条，常见的基于内存的向量引擎在这种规模下会消耗非常多的资源，检索时效也不够快。在这种情况下，团队又引入了基于磁盘的DiskANN算法。

DiskANN是一种基于图的索引和搜索系统，源自2019年发表在NeurIPS上的论文《DiskANN: Fast Accurate Billion-point Nearest Neighbor Search on a Single Node》。它结合了两类算法：聚类压缩算法和图结构算法，只需有限的内存和SSD资源，就能支持数十亿的向量检索。与常见的ANN算法相比，DiskANN大幅提升了向量召回的读取效率，降低了图算法的内存需求，提升了召回率。

举个例子：在当前主流的内存型HNSW算法下，业界常用的内存估算方式是：向量个数 × 4 × (向量维度 + 12)。那么在DEEP 10M（96维）的1千万数据就需要内存达到4GB以上，但通过DiskANN优化后，仅需要70MB的内存就可以对海量数据高效进行检索；在MS-MARCO（1024维）的1.38亿条记录里，所需内存更是高达534GB，检索1.38亿的数据需要12个64GB节点。

按照上述估算公式，达到10亿级别时需要大约100个节点，达到100亿级别则需要约1000个节点。这种规模在资源成本和稳定性方面面临极大的挑战。然而，引入内存和磁盘更好平衡的DiskANN算法后，云搜索团队在200亿单一向量库中已成功验证了效果：DiskANN论文提到可以节约95%的资源，从多个实际用户案例来看，这一收益值非常接近。客户仅需几十台机器即可稳定高效地满足百亿级业务需求。

目前云搜索服务通过DiskANN引擎提供的能力，完成了200亿级别的512维向量构建的客户案例。在这个案例中，通过分布式能力构建了超大规模的向量集群，实现了视频、图片、文本的混合检索。而且在业界，微软的Azure CosmosDB目前也开始支持DiskANN算法。

“目前，我们支持了多种可商用的向量检索算法，除了常见的基于内存的HNSW、IVF-Flat之外，也包括基于硬盘的DiskANN算法。通过这种全方位、多层次的解决方案，用户可以根据自己的实际关注点——比如数据规模、性能延迟、成本预算等——选择不同的算法。”李杰辉表示。

不可能三角：稳定、成本与性能

大模型火了之后，除了向量数据库，一些中间件如LangChain和Llama Index也备受关注。这些中间件负责将向量数据库与大语言模型（LLM）整合，形成RAG引擎。甚至有一些简单将向量数据库、中间件和LLM拼接起来的前端项目也吸引了大量关注。

然而，一套真正符合企业需求的RAG引擎并不仅仅是向量数据库加上LangChain或Llama Index等中间件的简单组合。从实践来看，使用LangChain或Llama Index原始方案，准确率可能非常差，尤其在专业文献领域。也就是说，简单的拼装方案可能对一些基础的问答语料有效，但对于复杂的长文本或专业领域（如财务报表或判决书）的检索需求，仅靠简单拼合很难达到预期效果。

一个能使准确率得到很大提升的RAG方案，需要从数据预处理到搜索增强整个流程的不同阶段增加干预和定制化能力。

一个完整的RAG处理流程要分为几个部分：首先是数据增强处理。无论是数据清理，还是对原始半结构化数据进行抽取（比如实体抽取或事件抽取），都需要详细处理。部分信息需要总结，并采用适当的方法进行分块，而不是简单地按字数划分。比如要识别其中的表格和代码，并将这些块准确拆分出来。第二个部分是存储方案。最简单的方法是将数据分割后，添加元数据、原文和向量，或者拼接字段也需要进行schema设计，使系统具有更强的结构化检索能力。第三个部分是混合搜索。比如基于向量后进行标量过滤，或者关键词召回和向量召回，然后进行混排和精排。

简单说：首先对原始数据进行增强，然后进行合理的schema设计（而不是像LangChain那样通用的方式），这样检索效果可能更好。最后，进行结构化查询设计和rerank。尤其对于专业文献，可能需要补充召回和rerank这些步骤，最终达到准确的检索效果。然后对prompt进行调优和处理，形成完整的端到端方案。这还只是基础单元，复杂场景下还需要进行pipeline设计，对意图进行分类，并分成不同的任务来处理。

为了应对复杂需求，火山引擎云搜索端到端的解决方案提供的是一个完整的RAG生态，能够将火山引擎已有的搜索经验运用起来——比如RAG搜索的召回率提升、ES的插件化能力、干预能力，以及基于LangChain或其他模型所不具备的抽象搜索和检索重排功能。

“我的一个感受是RAG用户关注的跟搜索用户不一样，他对准确性的要求会高非常多。目前大部分用户多多少少会遇到召回的准确性不足，导致RAG回答效果不好的问题。这是RAG应用的一个挑战。”接触过不少客户的余炜强观察到。

理论上开源文本搜索引擎提供了很强的基础能力，但大部分用户可能没有足够的检索经验或能力去做优化，从而将它们发挥到最好。字节跳动历史上各类搜索经验，其中很大一部分可以复用到了云搜索的RAG准确率优化上。另一方面，云搜索团队在RAG生态系统上开发了许多组件，以帮助用户快速构建端到端的RAG应用，从而实现低接入成本和高效果的目标。

对比LangChain和Llama Index与向量数据库的简单拼合方案，云搜索团队的解决方案更为底层。虽然没有可拖拽的pipeline单元，但通过交互式编程方式，结合AI生态和大模型管理能力，可以注入增强逻辑，构建更复杂的应用。理论上，这些干预能力可以直接嵌入到LangChain和Llama Index中。比如，如果将OpenSearch用作Llama Index的vector store，可以传入一个search pipeline。这个pipeline可以包含针对RAG的一些增强功能，包括干预增强，从而获得更好的调优体验。

对于向量数据库来说，“性能”是其中一个关键的产品竞争力评价指标。云搜索团队一开始也针对这些能力——尤其是性能和延迟方面——进行了全面的能力建设。其实在向量检索火起来之前，一直到现在，很多厂商在做性能报告时，都会把重点放在查询延迟上，这是一个比较通用的衡量标准。然而，随着向量检索技术发展和应用场景的丰富，单纯关注查询延迟已经无法满足所有需求。

在实际应用中，云搜索团队发现客户对底层检索数据库的需求通常可以归纳为三个维度：稳定性、成本（越低越好）和延迟性能（越低越好）。

“这三个维度形成了一个‘不可能三角’，其实在向量检索中，我们不可能找到一种方案能够同时满足这三个条件——既稳定，成本又低，且延迟时间非常短。”

通过与客户的深入交流，他们发现用户其实更关注的是稳定性——这是所有用户的共性，其次是成本。稳定性不仅意味着检索速度快或慢，而是指在数据量增加时，系统仍能可靠地返回结果。尽管很多人认为数据库性能应该保持在毫秒级别，但实际上在大规模检索场景中，许多客户可以接受秒级的延迟——当然这是在数据量非常大的前提下。比如，当数据规模达到10亿条时，如果客户要求毫秒级别的性能，则需要全内存方案支持，支持10亿条向量可能需要四五百台机器。对许多ToB用户来说，这样的成本非常难以接受。对他们而言，其实能接受较低的成本和较慢的查询速度，但关键要稳定——不能数据稍微多一点就崩了。

“我们发现在这个不可能三角里，

，这也与常规的行业认知有一定偏差。”

所以火山引擎云搜索服务主要是沿着“既能有效控制成本，又能提供可靠的稳定性”的指导思维去迭代系统能力。

其中成本控制主要体现在使用成本和实际资源消耗成本上。在资源消耗成本上，通过引入更优的算法（DiskANN）和采用无服务器（Serverless）方案。例如在当前主流的内存型HNSW算法下，

。那么。在使用成本方面，云搜索提供了完整的生态解决方案，加上token价格很低的方舟和豆包平台，用户的接入成本和使用成本也得到了显著降低。

向量检索算法引擎的选型上，对于小规模数据的用户推荐使用全内存方案；而对于大规模数据的用户，如果预算充足，则可以选择全内存方案以确保性能和稳定性。对于同时关注稳定性和成本的用户，则推荐使用基于硬盘的检索方案（如DiskANN）。这种方案既能有效控制成本，又能提供可靠的稳定性。

构建生产级RAG仍然是一个复杂而微妙的问题。如何高效地接入企业搜索生态、如何将性价比做得更好——所有这些问题都不是单纯依靠开源的向量数据库、开源的RAG就能轻松解决的。每个环节的增强、每一个构建决策都能直接影响到产品的竞争力。