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 應用解決方案。

 從專有到集成的技術趨勢

火山引擎云搜索團隊涉足向量技術有著悠久的歷史。然而，向量數據庫真正走進大眾視野卻是近年來，這主要得益于 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 月，亞馬遜基于開源 ES 7.10.2 版本分叉創建了新的項目 OpenSearch，并繼承了 OpenDistro 項目幾乎所有的擴展功能，自然也包括了向量檢索 k-NN 插件。

出于這些原因，在云搜索服務商用之后，團隊決定繼續通過 OpenSearch 來構建自身向量能力：“為了更好地滿足開源需求，并遵循以開源為主導的思路，我們決定采用更加開源的方式來提供搜索服務?！?/p>

火山引擎云搜索團隊選擇 OpenSearch 來構建自身向量能力，不僅看中了其開源優勢，也看重了其與 開源 ES 的技術傳承。OpenSearch 的檢索體系從 開源 ES 演變而來，是一個持續演進的技術體系，也是大家所熟悉的技術棧。云搜索團隊選擇基于 OpenSearch 去構建向量檢索，也能更好的利用之前積累的內部經驗。

隨著 RAG 技術和大模型的發展，衍生出來對向量檢索的要求不斷提高。首先是向量維度的變化，其次是向量和文本結合功能性的需求，此外還有對搜索準確性的更高要求。核心數據庫尤其是在向量場景下，需要不斷迭代升級，來滿足這種大模型場景下的搜索需求。

從 2020 年開始，云搜索團隊進行向量檢索的開發，并將向量檢索與全文檢索結合。在這個過程中提出了非常多的功能，這些功能一開始服務字節跳動集團的業務，到云搜索服務產品上線之后也面向外部客戶。同時本著“開源開放”的基本策略，自從引入向量檢索能力，團隊開始將支持內部業務所需的一些新功能引入并貢獻至 OpenSearch（當時的 OpenDistro）社區中去。

RAG 和向量檢索在今年受到了極大的關注，火山引擎云搜索團隊在過去幾年也持續參與 OpenSeach 社區向量檢索功能的建設，今年云搜索團隊成員被邀請成為該項目維護者（maintainer），這也是一個重要的里程碑。

“將我們的技術貢獻給 OpenSearch 社區，是一件成就感比較大的事情，”火山引擎云搜索團隊魯蘊鋮分享道，“這不僅意味著我們的技術得到了認可，更重要的是，我們能夠與社區一起共建一個更多人使用的服務、一個更加完善的搜索生態?！?/p>

魯蘊鋮認為，開源不僅是一種開發模式，更是一種理念。秉承開源理念，火山引擎云搜索團隊能夠與社區攜手合作，共同推動搜索技術的進步。這不僅促進整個社區的繁榮發展，也對火山引擎自身的產品發展是有利的。

“開源產品需要持續的維護和迭代，”魯蘊鋮強調，“而社區的貢獻正是推動產品發展的重要動力。我們積極參與 OpenSearch 社區的建設，不僅為產品帶來了新的功能和特性，也提升了產品的穩定性和性能?！?/p>

而且，“遵守開源開放的標準，也讓我們沒有任何商業化和開源產品上的矛盾，也能幫助客戶解決被某一家云廠商綁定的顧慮?！?/p>

2、一套 RAG 系統，多種向量算法引擎

隨著業務的增長，為了滿足大規模內部業務和外部客戶的需求，團隊對向量檢索能力進行了持續迭代。特別是在 To B 場景下，用戶的業務場景各不相同，數據規模也千差萬別，他們的關注點也不一樣。對于一個好的數據庫產品，它應該能夠盡可能多地支持不同規模的業務場景。例如不同業務向量數據的數量可能是 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% 的資源，從多個實際用戶案例來看，這一收益值非常接近?？蛻魞H需幾十臺機器即可穩定高效地滿足百億級業務需求。

所以當前火山引擎云搜索提供了總共四種檢索引擎，可以根據數據規模和成本預算來選擇不同的引擎。如果數據規模非常小，又對這種性能檢索性能有需求的話，可以使用基于內存的向量檢索算法，比如 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 的設計，使得系統具有更強的結構化檢索能力。第三個部分，就是進行混合搜索。例如基于向量后進行標量過濾，或者關鍵詞召回和向量召回，然后進行混排和精排。

火山引擎云搜索提供了非常強的混合檢索能力，可以在向量召回的文檔上結合更多的 operator 進行匹配和評分干預，從而確保更準確的檢索效果。從檢索方面看，結構化查詢和查詢后的 rerank 需要進行定制。通過這些步驟的干預，最終可以達到高準確率的檢索效果。

簡單來說，首先是對原始數據進行增強，然后進行合理的 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 的一些增強功能，包括干預增強，從而獲得更好的調優體驗。

對于向量數據庫來說，“性能”是其中一個關鍵的產品競爭力評價指標。云搜索團隊一開始也針對這些能力，尤其是性能和延遲方面，進行了全面的能力建設。其實在向量檢索火起來之前，一直到現在，很多廠商在做性能報告的時候，都會把重點放在查詢延遲上，這是一個比較通用的衡量標準。然而，隨著向量檢索技術的發展和應用場景的豐富，單純的關注查詢延遲已經無法滿足所有需求。

在實際應用中，云搜索團隊發現客戶對底層檢索數據庫的需求通常可以歸納為三個維度：穩定性、成本（越低越好）和延遲性能（越低越好）。

“這三個維度形成了一個‘不可能三角’，其實在向量檢索中，我們不可能找到一種方案能夠同時滿足這三個條件——既穩定，成本又低，且延遲時間非常短?！?/p>

通過與客戶的深入交流，他們發現用戶其實更多關注的是穩定性，這是所有的用戶的一個共性，其次是成本。穩定性不僅意味著檢索速度快或慢，而是指在數據量增加時，系統仍能可靠地返回結果。盡管很多人認為數據庫性能應該保持在毫秒級別，但實際上在大規模檢索場景中，許多客戶可以接受秒級的延遲，當然這是在數據量非常大的前提下。例如，當數據規模達到 10 億條時，如果客戶要求毫秒級別的性能，則需要全內存方案支持。在這種情況下，支持 10 億條向量可能需要四五百臺機器，對于許多 To B 用戶來說，這樣的成本是非常難以接受的。對于他們來說，其實是能夠接受成本低和較慢的查詢速度，但是關鍵要穩定，不能數據稍微多一點就崩了。

“我們發現在這個不可能三角里，用戶其實最看重的是穩定和成本，這也與常規的行業認知有一定偏差?！?/p>

所以后面火山引擎云搜索服務主要是沿著“既能有效控制成本，又能提供可靠的穩定性”的指導思維去迭代系統能力。

其中成本控制主要體現在使用成本和實際資源消耗成本上。在資源消耗成本上，火山引擎云搜索通過引入更優的算法 (DiskANN) 和采用無服務器 (Serverless) 方案。例如在當前主流的內存型 HNSW 算法下，業界常用的內存估算方式是：向量個數 *4* (向量維度 + 12)。那么 在 DEEP 10M（96 維）的 1 千萬數據就需要內存達到 4GB 以上，但是通過 DiskANN 優化后，僅需要 70MB 的內存就可以對海量數據高效的進行檢索。在使用成本方面，云搜索提供了完整的生態解決方案，加上 token 價格很低的方舟和豆包平臺，這樣用戶的接入成本和使用成本也得到了顯著降低。

向量檢索算法引擎的選型上，對于小規模數據的用戶推薦使用全內存方案，而對于大規模數據的用戶，如果預算充足，則可以選擇全內存方案，以確保性能和穩定性。對于同時關注穩定性和成本的用戶，則推薦使用基于硬盤的檢索方案，如 DiskANN。這種方案既能有效控制成本，又能提供可靠的穩定性。

構建生產級 RAG 仍然是一個復雜而微妙的問題，如何高效地接入企業搜索生態、如何將性價比做得更好，所有這些問題都不是單純依靠開源的向量數據庫、開源的 RAG 就能輕松解決的，每個環節的增強、每一個構建決策都能直接影響到產品的競爭力。

火山引擎云搜索團隊的下一步計劃是結合行業趨勢，提供更多的 AI Native 能力。云搜索不僅已經支持圖像搜索、文本搜索圖像、文本搜索視頻以及標簽與向量語義聯合查詢等復雜查詢，還希望在生成式 AI 領域進一步融合各種檢索功能。一方面，通過降低使用門檻，用戶可以更輕松地上手；另一方面，通過整合以往的技術積累，能夠提供更優質的用戶體驗。