2024 年 RAG 技术如日中天，企业级解决方案如何脱颖而出？

云计算de小白

2023年，大模型惊艳世人。2024年，RAG技术达到巅峰。

RAG使得大模型无需更新模型参数就能获得必要的上下文信息，从而减轻了大模型的假象，随着大语言模型技术的不断成熟和行业应用的深入，人们对RAG系统的期望已经超出了企业和组织开始寻找更加可靠、可扩展的RAG解决方案来满足实际的业务需求。

与此同时，支持RAG的矢量数据库市场竞争也愈发激烈，但从目前的矢量数据库实现来看，无论是插件形式还是专用矢量数据库，很多底层实现都采用了HNSW等公开算法，因此在召回率等一些关键指标上不会有太大差别，那么企业级解决方案应该从哪些方面着手才能脱颖而出呢？

1. 矢量数据库：RAG 的核心

RAG 是为了解决大模型错觉问题而创建的，但它的出现也标志着搜索范式的改变。

以前我们都是把关键词输入到搜索框里，自己去搜索内容，搜索可以使用特定的关键词或者搜索技巧，很方便的找到想要的信息。而问答是基于人类语言的，不依赖关键词，这就导致了传统关键词搜索的局限性，可能因为问法不同而找不到相关内容。在这种问答环境下，语义化的需求自然而然的就出现了，所以这时候人们就利用向量数据库来进行语义检索，然后将结果应用到RAG上。就像MySQL在传统Web应用中的作用一样，向量数据库是RAG应用依赖的一个核心基础功能。

在此背景下，火山引擎云搜索团队提供的RAG解决方案可以看作是一个两层的解决方案，上层提供RAG框架服务，包括大模型集成、LangChain集成、模型管理、混合检索等。

再往下一层是向量搜索能力，作为一项基础技术，单纯的向量搜索能力可能并不会受到太多开发者的关注，但在火山引擎云搜索服务研发过程中，他们发现RAG场景并不缺少向量数据规模，客户数量庞大，从常见的千万级到数十亿级乃至百亿级，在这样的规模条件下，向量搜索方案的选型就显得尤为重要，因为向量数据库的成本和稳定性都会面临很大的挑战。

另外，RAG技术的真正价值在于能够提供更精准的答案和更快速的搜索，本质上和搜索引擎类似，如果你想将自己的搜索产品拓展成RAG产品，ES和OpenSearch是最佳选择之一。

对此，火山云搜索服务提供了兼容Elasticsearch/OpenSearch的托管式在线分布式搜索解决方案，早在2022年4月上线时，该服务就内置了向量检索能力。搜索团队在2020年开始应用向量检索技术，并将该技术集成到ES 7.1版本中，满足了集团对多模态检索的业务需求。

在技​​术实现上，云搜索团队选择以开源的方式构建向量检索能力，团队成员还成为 OpenSearch 开源项目向量检索功能模块的维护者，并且是该模块唯一非 AWS 员工的维护者。随着大模型技术的兴起，云搜索团队也从市场需求出发，从底层向量检索到上层应用服务，提供各个环节的增强能力，形成完整、易用的 RAG 应用解决方案。

技术趋势从专有到集成

火山云搜索团队在向量技术上的布局由来已久，但向量数据库真正进入大众视野却是近几年的事情，主要得益于OpenAI的崛起以及商业数据库巨头的加入。

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月，亚马逊fork了开源ES 7.10.2版本，创建了新项目OpenSearch，继承了OpenDistro项目的几乎所有扩展功能，自然也包括向量检索k-NN插件。

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

火山引擎云搜索团队选择开放搜索来构建自己的向量能力，不仅看重其开源优势，更看重其与开源ES的技术传承。开放搜索的检索体系是从开源ES演化而来的，是一个不断演进的技术体系，也是大家熟悉的技术栈。云搜索团队选择基于开放搜索来构建向量搜索，也能更好地利用此前积累的内部经验。

随着 RAG 技术和大模型的发展，向量检索的要求也在不断提高，首先向量维度的变化，其次需要向量与文本结合的功能，另外对搜索准确率的要求也更高，核心数据库特别是在向量场景下，需要不断迭代升级，才能满足这种大模型场景下的搜索需求。

2020 年以来，云搜索团队一直在研发向量搜索，并将向量搜索与全文搜索相结合。在这个过程中，提出了很多功能，这些功能最初服务于字节跳动集团内部业务，随后成为云搜索的核心，产品上线后也开放给外部客户使用。同时，本着“开源”的基本策略，自向量搜索能力推出后，团队开始陆续推出一些支撑内部业务所需的新功能，并贡献给开放搜索（当时的 OpenDistro）社区。

RAG和向量搜索在今年得到了极大的关注，Volcano Engine云搜索团队也在过去几年持续参与OpenSeach社区向量搜索功能的建设，今年云搜索团队成员受邀成为项目维护者，也是一个重要的里程碑。

“能把我们的技术贡献给开放搜索社区，感觉很有成就感”，火山引擎云搜索团队陆云成表示，“这不仅意味着我们的技术得到了认可，更重要的是，我们可以和社区一起，共同构建更多人能使用的服务，以及更加完善的搜索生态。”

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

“开源产品需要持续的维护和迭代”，陆云成强调，“而社区贡献是产品发展的重要驱动力。我们积极参与开放搜索社区的建设，不仅给产品带来了新的功能和特性，也提升了产品的稳定性和性能。”

而且，“坚持开源标准还能让我们避免商业化和开源产品之间产生冲突，也能帮助客户解决被绑定到某个云供应商的顾虑”。

2. RAG体系及多种矢量算法引擎

随着业务的增长，团队在向量检索能力上不断迭代，以满足大规模内部业务和外部客户的需求。尤其在 To B 场景下，用户的业务场景千差万别，数据规模也千差万别。一个好的数据库产品应该能够支持尽可能多的不同规模的业务场景。比如不同业务向量数据的数量可能是十万、千万、十亿，甚至千亿。除了数量级之外，用户使用的向量维度也在逐渐提升。比如虽然很多用户还在使用 128 维或 512 维的向量，但是业界一些 vector embeddings 服务商，比如 Microsoft Azure、OpenAI 等，已经支持 128 维或 512 维的向量。云搜索产品也支持高达 16000 维的向量数据的存储和访问。数据项数量越大、维度越高，对搜索资源的需求就越高。

为了满足不同规模的需求，火山引擎云搜索团队调研了多种引擎，希望在原有开源ES、OpenSearch的基础上进行扩展，最终率先引入了Faiss引擎，结合现有数据库，为集团内部业务提供向量搜索服务。

另外，HNSW+PQ向量压缩是现有向量数据库中最常用的算法，虽然可以满足80%~90%云搜索用户的需求，但这两个算法其实已经发布很久了。引擎云搜索的应用场景也比较多样，处理的数据规模可能达到几百亿，在这个规模下，目前常见的基于内存的向量引擎会消耗大量资源，检索时间不够快。针对这种情况，云搜索团队引入了基于磁盘的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维）中1000万数据需要4GB内存，而经过DiskANN优化后，只需要70MB内存，就能高效搜索海量数据；而MS-MARCO（1024维）中1.38亿记录的情况下，需要534GB内存，数据需要12个节点，每个节点64GB。

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

因此，火山云搜索目前一共提供了四种搜索引擎，你可以根据数据规模和成本预算来选择不同的引擎。如果数据规模非常小，又需要这种搜索性能，那么可以使用基于内存的向量检索算法，比如 HNSW。而对于大规模数据，如果还是使用一些高性能的基于内存的算法，资源成本会很高，因此你可能需要使用一些基于磁盘的向量检索算法，比如 DiskANN，来达到资源和性能之间的平衡。

目前，云搜索服务已经通过 DiskANN 引擎提供的能力，完成了构建 200 亿条 512 维向量的客户案例。该案例通过分布式能力构建了超大规模向量集群，实现了视频、图像、文本的混合检索。在业界，微软的 Azure ComosDB 现在也支持 DiskANN 算法。

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

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

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

但真正符合企业需求的 RAG 引擎并非只是简单的向量数据库与 LangChain 或者 Llama Index 等中间件的组合，在实际应用中，LangChain 或者 Llama Index 原有的解决方案可能准确率非常差，尤其是对于一些基础的问答语料，简单的拼接可能有效，但对于复杂的长文本或者专业领域的检索需求（比如财务报表或者判断），单靠简单的拼接很难达到预期的效果。

对于能够显著提高准确率的RAG解决方案来说，需要在从数据预处理到搜索增强的整个流程的不同阶段增加干预和定制能力。

一个完整的RAG处理流程可以分为几个部分，第一部分是数据增强，无论是数据清洗还是抽取原始的半结构化数据，比如实体抽取或者事件抽取，都需要进行详细的处理。有些信息需要用合适的方法进行归纳和分块，而不是简单的按照字数来划分，比如需要识别出表格和代码，精准的将这些块分开。第二部分是存储解决，最简单的方法就是对数据进行拆分，增加元数据，原文和向量，或者拼接字段，还需要进行Schema设计，让系统具备更强的结构化检索能力。第三部分是混合检索，比如基于向量的标量过滤，或者关键词召回和向量召回，之后是混合排序和精细化排序。

火山云搜提供了非常强的混合搜索能力，可以组合更多的算子对向量召回的文档进行匹配和打分干预，从而保证搜索结果更加精准。rerank需要定制化，通过这些步骤的干预，最终达到高精度的检索效果。

简单来说，首先我们需要对原始数据进行增强，然后设计合理的schema，而不是像LangChain那样只是通用的方法，这样检索效果可能会更好。最后需要设计结构化的query和rerank，对于专业文档，可能还需要加入recall和rerank的步骤，才能达到精准的检索结果。最后对prompt进行调优和处理，形成完整的端到端解决方案，这只是基本单元，在复杂的场景下，还需要pipeline的设计，将intent进行分类，分成不同的task去处理。

为了应对复杂的需求，火山云搜索提供了端到端的解决方案，提供了完整的RAG生态，可以应用Volcano现有的搜索经验，比如提升RAG搜索的召回率、ES的插件能力、干预能力，以及基于LangChain或其他模型所不具备的摘要搜索和检索重排序能力。

“我的感觉是RAG用户的关注点和搜索用户不一样，就是对准确率的要求高很多。目前大部分用户或多或少都会遇到召回准确率不够高，导致RAG答题效果不好，这对RAG应用来说是一个挑战。”接触过不少客户的余伟强表示。

理论上，开源文本搜索引擎提供了强大的基础能力，但大多数用户可能没有足够的搜索经验或能力将其发挥到极致，其中一部分可以在 Cloud Search 的 RAG 精度优化中得到复用；另一方面，Cloud Search 团队在 RAG 生态上开发了众多组件，帮助用户快速构建端到端的 RAG 应用，从而实现低接入成本、高使用效果的目标。

相比于 LangChain、Llama Index 和向量数据库的简单组合，云搜索团队的解决方案更加基础，虽然没有可拖拽的流水线单元，但可以通过交互式编程注入，结合 AI 生态和大模型管理能力，增强逻辑，构建更复杂的应用。理论上这些干预能力可以直接嵌入到 LangChain 和 Llama Index 中，比如如果使用 OpenSearch 作为 Llama Index 的向量存储，可以传入一个搜索流水线，这个流水线可以包含对 RAG 的几项增强，包括干预增强，以获得更好的调优体验。

对于向量数据库而言，“性能”是衡量产品竞争力的关键指标之一，云搜索团队也在这些方面进行了全面的能力建设，特别是在性能和​​延迟方面。此前，直到现在，很多厂商在做性能报告时，都会重点关注查询延迟，这是一个比较常见的指标，但随着向量搜索技术的发展和应用场景的丰富，单纯关注查询延迟已经远远不够。

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

“这三个维度形成了一个‘不可能三角’。事实上，在矢量搜索中，我们不可能找到一个能够同时满足所有三个条件的解决方案——稳定、低成本、非常短的延迟。”

通过和客户的深入沟通，他们发现用户其实更注重稳定性，这是所有用户的共同特点，其次才是成本。稳定性不仅仅意味着检索速度快或慢，还指在数据量增加时，数据的稳定性。虽然很多人认为数据库性能应该保持在毫秒级，但实际上在大规模检索场景下，很多客户可以接受秒级的延迟。当然，这只有在数据量非常大的情况下才如此，比如当数据规模达到10亿时，客户如果要求毫秒级的性能，就需要全内存的方案，这种情况下支持10亿条向量可能需要四五百台机器。对于B2B用户来说，这样的成本是非常难以接受的，对于他们来说，其实可以接受低成本、较慢的查询速度，但关键是保证稳定性，数据多一点的时候不能崩溃。

“我们发现，在这个不可能三角中，用户其实最看重的是稳定性和成本，这与传统的行业认知有些不同。”

因此火山引擎云搜索服务主要沿着“有效控制成本，提供可靠的稳定性”的指导原则进行系统能力的迭代。

成本控制主要体现在使用成本和实际资源消耗成本上。在资源消耗成本上，火山引擎云搜引入了更优算法（DiskANN），并采用了无服务器方案。在HNSW算法下，业界常用的内存估算方式为：向量个数*4*（向量维数+12）。那么DEEP 10M（96维）下1000万数据需要4GB以上的内存，但经过DiskANN优化后，只需要70MB内存，便可实现海量数据的高效搜索。在使用成本上，云搜提供了完整的生态解决方案，加上Token价格极低的方舟、豆包平台，使得用户的接入成本和使用成本也得到了显著降低。

在向量检索算法引擎的选择上，对于小规模数据的用户，建议使用全内存方案；对于大规模数据的用户，如果预算充足，可以选择全内存方案，保证性能和稳定性；对于注重稳定性和成本的用户，建议使用基于硬盘的检索方案，如DiskANN，可以有效控制成本，并提供可靠的稳定性。

构建生产级的RAG依然是一个复杂而微妙的问题，如何高效对接企业搜索生态、如何实现更好的性价比，都是无法简单依赖开源向量数据库和开源RAG轻松解决的问题，每一个环节的提升、每一个建设决策都能够直接影响产品的竞争力。

火山引擎云搜索团队的下一步是结合行业趋势，提供更多 AI Native 能力。目前云搜索已经支持图片搜索、图片文本搜索、视频文本搜索、标签与向量语义的联合查询等复杂查询。进一步整合生成式 AI 领域的各类搜索功能。一方面降低使用门槛，让用户更轻松上手；另一方面融合前期的技术积累，提供更好的用户体验。