2023 年，大模型驚艷了世界。2024 年，RAG 技術(shù)如日中天。

RAG 使得大模型能夠在不更新模型參數(shù)的情況下，獲得必要的上下文信息，從而減少大模型的幻覺。隨著大型語言模型技術(shù)的不斷成熟和行業(yè)應(yīng)用的深入，人們對 RAG 系統(tǒng)的期望已經(jīng)超越了對其“酷炫”效果的追求。企業(yè)和組織開始尋找更可靠、可擴展的 RAG 解決方案，以滿足實際業(yè)務(wù)需求。

與此同時，支撐 RAG 的向量數(shù)據(jù)庫市場競爭愈加激烈。然而從當(dāng)前向量數(shù)據(jù)庫的實現(xiàn)來看，無論是插件形式，還是專門的向量數(shù)據(jù)庫，底層實現(xiàn)上很多都是采用諸如 HNSW 之類的公開算法，因此一些關(guān)鍵指標(biāo)例如召回率并不會有太大的區(qū)別。那么一個企業(yè)級解決方案想要脫穎而出，需要在哪些方面下功夫呢？

1、向量數(shù)據(jù)庫：RAG 的心臟

RAG 的出現(xiàn)是為了解決大模型幻覺問題，但它的出現(xiàn)也標(biāo)志著搜索范式的變化。

過去我們通過搜索框輸入關(guān)鍵詞，然后在上面自己去查找內(nèi)容。搜索可以使用特定關(guān)鍵字或者搜索技巧，很容易找到想要的信息。而問答則基于人類語言進行提問，不依賴關(guān)鍵字。這就導(dǎo)致了傳統(tǒng)關(guān)鍵字檢索的局限性，可能因為問法的不同而無法找到相關(guān)內(nèi)容。在這種問答環(huán)境中，對語義的要求自然而然地凸顯出來。所以這時候大家就基于向量數(shù)據(jù)庫，進行語義檢索，然后再將結(jié)果應(yīng)用于 RAG。如同 MySQL 在傳統(tǒng) Web 應(yīng)用的角色定位，向量數(shù)據(jù)庫是 RAG 應(yīng)用依賴的一項核心基礎(chǔ)功能。

在此背景下，火山引擎云搜索團隊提供的 RAG 解決方案可以視作一個兩層的解決方案。上層提供 RAG 框架服務(wù)，包括大模型集成、LangChain 集成、模型管理、混合檢索等。

下層則是向量檢索能力。作為一項基礎(chǔ)技術(shù)，單純的向量檢索能力可能并不會引起開發(fā)者的太多關(guān)注。但是在火山引擎云搜索服務(wù)的 tob 過程中，他們發(fā)現(xiàn) RAG 場景不乏向量數(shù)據(jù)規(guī)模龐大的客戶，從常見的千萬級別，到 10 億級別，甚至到 100 億級都有。在這種規(guī)模條件下，向量檢索解決方案選型就尤為重要，因為此時向量數(shù)據(jù)庫的成本和穩(wěn)定性都會面臨非常大的挑戰(zhàn)。

另外，RAG 技術(shù)的真正價值在于能夠提供更準(zhǔn)確的回答和更快速的搜索，其本質(zhì)上又與搜索引擎類似。如果希望將搜索產(chǎn)品擴展為 RAG 產(chǎn)品，那么 ES 和 OpenSearch 是最佳選擇之一。

在這方面，火山引擎云搜索服務(wù)提供了兼容 Elasticsearch/OpenSearch 的托管在線分布式搜索解決方案。早在 2022 年 4 月上線時，這項服務(wù)就內(nèi)置了向量檢索的能力。實際上，火山引擎云搜索團隊在 2020 年就開始應(yīng)用向量檢索技術(shù)，當(dāng)時在 ES 7.1 版本上集成了這一技術(shù)，以滿足集團業(yè)務(wù)對多模態(tài)檢索的需求。

在技術(shù)實現(xiàn)路線上，云搜索團隊選擇以開源開放的思路來建設(shè)向量檢索能力，其團隊成員還成為了 OpenSearch 開源項目向量檢索功能模塊的維護者，也是該模塊中唯一來自非 AWS 的維護者。隨著大模型技術(shù)的興起，云搜索團隊也從市場需求出發(fā)，從底層向量檢索到上層應(yīng)用服務(wù)，針對每一個環(huán)節(jié)提供了增強能力，形成一套完整易用的 RAG 應(yīng)用解決方案。

 從專有到集成的技術(shù)趨勢

火山引擎云搜索團隊涉足向量技術(shù)有著悠久的歷史。然而，向量數(shù)據(jù)庫真正走進大眾視野卻是近年來，這主要得益于 OpenAI 的興起和商業(yè)數(shù)據(jù)庫巨頭們的加入。

2022 年，向量數(shù)據(jù)庫領(lǐng)域融資熱潮涌現(xiàn)，多家專有向量數(shù)據(jù)庫廠商獲得了巨額投資。然而，技術(shù)潮流瞬息萬變。今年 6 月，OpenAI 收購實時分析數(shù)據(jù)庫 Rockset，標(biāo)志著向量數(shù)據(jù)庫發(fā)展進入新階段：向量數(shù)據(jù)庫不再是獨立的特性，而是集成在更大平臺中的組件。

與 Chroma、Milvus、Pinecone 等專有向量數(shù)據(jù)庫不同，Rockset 和 ES、Redis 等商業(yè)數(shù)據(jù)庫選擇通過插件形式加入向量檢索能力。Rockset 甚至在今年 4 月才正式引入向量搜索功能。OpenAI 選擇 Rockset 而非專有向量數(shù)據(jù)庫，業(yè)界普遍認(rèn)為這表明：客戶更看重數(shù)據(jù)庫的整體管理能力，以及與現(xiàn)有功能的無縫集成，以優(yōu)化數(shù)據(jù)處理工作流程并提高整體效率。

這一趨勢與火山引擎云搜索服務(wù)的發(fā)展路徑不謀而合。云搜索團隊選擇在開源版 ES 和 OpenSearch 基礎(chǔ)上增加向量功能，一方面能充分利用團隊在文本檢索和向量檢索領(lǐng)域的多年積累，另一方面也是站在巨人的肩膀上進一步增強整體競爭力。

在他們看來，向量數(shù)據(jù)庫更像是一種底層能力。客戶在使用向量數(shù)據(jù)庫時，不會單純地使用它來存儲或讀取向量數(shù)據(jù)。他們更多的是將向量數(shù)據(jù)庫與應(yīng)用場景結(jié)合起來，例如 RAG、以圖搜圖等語義檢索和解決方案。很多客戶實際就是從原本的搜索應(yīng)用升級到 RAG，這個遷移成本并不高。因此，如果一個數(shù)據(jù)庫能夠提供更多上層應(yīng)用的支持能力，對客戶來說會更有價值。

另一方面，在傳統(tǒng)數(shù)據(jù)庫實現(xiàn)向量，相當(dāng)于在原有的場景插上一個新的翅膀，處理能力就會更強。云搜索團隊在實踐中已經(jīng)認(rèn)識到這一點，所以隨著業(yè)務(wù)的發(fā)展，將向量檢索與文本檢索結(jié)合起來，實現(xiàn)了混合檢索的能力。這種融合擴展了產(chǎn)品的使用場景，實現(xiàn)了更大范圍內(nèi)的功能和性能提升，提高了產(chǎn)品競爭力。

在一些實際應(yīng)用中的復(fù)雜的場景里，單純使用簡單的 DSL 展開并不能滿足需求，特別是在需要優(yōu)化搜索準(zhǔn)確率的情況下。但其實搜索原生生態(tài)系統(tǒng)已經(jīng)提供了豐富的插件能力，這些插件可以有效優(yōu)化和增強搜索性能。而且引入向量檢索后，如在開源版 ES 或 OpenSearch 中，可以與原有的全文搜索引擎結(jié)合，實現(xiàn)復(fù)雜的結(jié)構(gòu)化查詢，從而顯著提高準(zhǔn)確率，達到一個非常好的效果。

以長文本為例，一篇包含 2 萬個字的文章，前半部分可能介紹某個事物的發(fā)展史，而后半部分的結(jié)論可能推翻了前面的結(jié)論，如果只檢索到前半部分內(nèi)容，結(jié)果會導(dǎo)致回答與實際意圖相反。這種情況下，就需要采用結(jié)構(gòu)化混合檢索，結(jié)合關(guān)鍵字和向量檢索，能更好地匹配專有名詞和復(fù)雜結(jié)構(gòu)，獲得更準(zhǔn)確的結(jié)果。

像云搜索服務(wù)這樣的產(chǎn)品，既支持向量檢索，也支持在向量檢索基礎(chǔ)上的復(fù)雜結(jié)構(gòu)化檢索。同時還在在結(jié)構(gòu)化檢索的基礎(chǔ)上通過插件擴展功能，提供干預(yù)、混排和重排等能力。從實際實踐來看，在處理專業(yè)型文檔時，借助這種增強的結(jié)構(gòu)化查詢檢索的能力，其準(zhǔn)確率遠(yuǎn)遠(yuǎn)優(yōu)于純向量檢索。

 開源才不怕綁定

在開源投入上，云搜索團隊很早就參與了開源 ES 社區(qū)的建設(shè)。字節(jié)跳動內(nèi)部很早就使用開源版 ES 用于支撐包括抖音、巨量引擎等核心業(yè)務(wù)，隨著集團業(yè)務(wù)的發(fā)展，業(yè)務(wù)部門對多模態(tài)檢索有使用需求，云搜索團隊發(fā)現(xiàn)這些向量檢索的需求與他們現(xiàn)有的 ES 使用場景可以結(jié)合。而當(dāng)時，Elasticsearch 還未提供向量檢索的能力。

亞馬遜則較早在開源 ES 發(fā)型版本 OpenDistro 上以插件的形式實現(xiàn)了向量檢索的能力，于 2019 年發(fā)布了并開源了該插件，也就是 OpenDistro k-NN 插件。鑒于當(dāng)時的實際情況，云搜索團隊在 2020 年將 k-NN 方案引入到內(nèi)部的實踐中，同時也積極參與社區(qū)的建設(shè) 。2021 年 4 月，亞馬遜基于開源 ES 7.10.2 版本分叉創(chuàng)建了新的項目 OpenSearch，并繼承了 OpenDistro 項目幾乎所有的擴展功能，自然也包括了向量檢索 k-NN 插件。

出于這些原因，在云搜索服務(wù)商用之后，團隊決定繼續(xù)通過 OpenSearch 來構(gòu)建自身向量能力：“為了更好地滿足開源需求，并遵循以開源為主導(dǎo)的思路，我們決定采用更加開源的方式來提供搜索服務(wù)。”

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

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

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

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

“將我們的技術(shù)貢獻給 OpenSearch 社區(qū)，是一件成就感比較大的事情，”火山引擎云搜索團隊魯蘊鋮分享道，“這不僅意味著我們的技術(shù)得到了認(rèn)可，更重要的是，我們能夠與社區(qū)一起共建一個更多人使用的服務(wù)、一個更加完善的搜索生態(tài)。”

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

“開源產(chǎn)品需要持續(xù)的維護和迭代，”魯蘊鋮強調(diào)，“而社區(qū)的貢獻正是推動產(chǎn)品發(fā)展的重要動力。我們積極參與 OpenSearch 社區(qū)的建設(shè)，不僅為產(chǎn)品帶來了新的功能和特性，也提升了產(chǎn)品的穩(wěn)定性和性能。”

而且，“遵守開源開放的標(biāo)準(zhǔn)，也讓我們沒有任何商業(yè)化和開源產(chǎn)品上的矛盾，也能幫助客戶解決被某一家云廠商綁定的顧慮。”

2、一套 RAG 系統(tǒng)，多種向量算法引擎

隨著業(yè)務(wù)的增長，為了滿足大規(guī)模內(nèi)部業(yè)務(wù)和外部客戶的需求，團隊對向量檢索能力進行了持續(xù)迭代。特別是在 To B 場景下，用戶的業(yè)務(wù)場景各不相同，數(shù)據(jù)規(guī)模也千差萬別，他們的關(guān)注點也不一樣。對于一個好的數(shù)據(jù)庫產(chǎn)品，它應(yīng)該能夠盡可能多地支持不同規(guī)模的業(yè)務(wù)場景。例如不同業(yè)務(wù)向量數(shù)據(jù)的數(shù)量可能是 10 萬級別、千萬級別、10 億，甚至 100 億以上。除了數(shù)量級之外，用戶采用的向量維度也呈逐步增加的趨勢，例如盡管現(xiàn)在不少用戶還在使用 128 或 512 維的向量，但是業(yè)界一些向量 embeddings 服務(wù)廠商例如微軟 Azure 和 OpenAI 已經(jīng)支持到 3072 維，云搜索產(chǎn)品也已經(jīng)支持存取多至 16000 維的向量數(shù)據(jù)。數(shù)據(jù)條數(shù)越大，維度越高，對檢索資源的需求也越高。

為了匹配不同規(guī)模的需求，火山引擎云搜索團隊調(diào)研了多種引擎，希望在原有的 開源 ES 和 OpenSearch 基礎(chǔ)上進行擴展，最終，他們率先引入了 Faiss 引擎。通過將 Faiss 與現(xiàn)有的全文檢索能力結(jié)合，為內(nèi)部集團業(yè)務(wù)提供向量檢索服務(wù)。

另外，HNSW 加上 PQ 向量壓縮是目前已有的向量數(shù)據(jù)庫里用得最多的算法，雖然能夠滿足可能百分之八九十的云搜索用戶需求，但是這兩種其實已經(jīng)發(fā)表很久了。而火山引擎云搜索的應(yīng)用場景也比較多樣化，處理的數(shù)據(jù)規(guī)模可能達到幾百億條，目前常見的基于內(nèi)存的向量引擎在這種規(guī)模下，會消耗非常多的資源，檢索時效上也不夠快。在這種情況下，云搜索團隊又引入了基于磁盤的 DiskANN 算法。

DiskANN 是一種基于圖的索引和搜索系統(tǒng)，源自 2019 年發(fā)表在 NeurIPS 上的論文《DiskANN: Fast Accurate Billion-point Nearest Neighbor Search on a Single Node》，它結(jié)合兩類算法：聚類壓縮算法和圖結(jié)構(gòu)算法，只需有限的內(nèi)存和 SSD 資源，就能支持?jǐn)?shù)十億的向量檢索。與常見的 ANN 算法相比，DiskANN 大幅提升向量召回的讀取效率，降低圖算法的內(nèi)存，提升召回率。

例如在當(dāng)前主流的內(nèi)存型 HNSW 算法下，業(yè)界常用的內(nèi)存估算方式是：向量個數(shù) *4* (向量維度 + 12)。那么在 DEEP 10M（96 維）的 1 千萬數(shù)據(jù)就需要內(nèi)存達到 4GB 以上，但是通過 DiskANN 優(yōu)化后，僅需要 70MB 的內(nèi)存就可以對海量數(shù)據(jù)高效的進行檢索；在 MS-MARCO（1024 維）的 1.38 億條記錄里，需要內(nèi)存更是高達 534GB，這樣檢索 1.38 億的數(shù)據(jù)需要 12 個 64GB 的節(jié)點。

按照上述估算公式，達到 10 億級別時需要大約 100 個節(jié)點，而達到 100 億級別時則需要約 1000 個節(jié)點。這種規(guī)模的服務(wù)在資源成本和穩(wěn)定性方面面臨著極大的挑戰(zhàn)。然而，引入了內(nèi)存和磁盤更好平衡的 DiskANN 算法后，云搜索團隊在 200 億單一向量庫中已成功驗證了其效果：DiskANN 論文提到可以節(jié)約 95% 的資源，從多個實際用戶案例來看，這一收益值非常接近。客戶僅需幾十臺機器即可穩(wěn)定高效地滿足百億級業(yè)務(wù)需求。

所以當(dāng)前火山引擎云搜索提供了總共四種檢索引擎，可以根據(jù)數(shù)據(jù)規(guī)模和成本預(yù)算來選擇不同的引擎。如果數(shù)據(jù)規(guī)模非常小，又對這種性能檢索性能有需求的話，可以使用基于內(nèi)存的向量檢索算法，比如 HNSW。對于大規(guī)模數(shù)據(jù)而言，如果仍使用一些高性能的基于內(nèi)存的算法，資源成本會非常高。因此，這時可能需要使用一些基于磁盤的向量檢索算法，比如 DiskANN，來達到資源和性能上的平衡。

目前云搜索服務(wù)通過 DiskANN 引擎提供的能力，完成了 200 億級別的 512 維向量構(gòu)建的客戶案例。在這個案例中，通過分布式的能力，構(gòu)建了一個超大規(guī)模的向量集群，實現(xiàn)了視頻、圖片、文本的混合檢索。并且在業(yè)界，微軟的 Azure ComosDB 目前也開始支持 DiskANN 算法。

“目前，我們支持了多種可商用的向量檢索算法，除了常見的基于內(nèi)存的 HNSW、IVF-Flat 之外，也包括基于硬盤的 DiskANN 算法。通過這種全方位、多層次的解決方案，用戶可以根據(jù)自己實際關(guān)注點，例如數(shù)據(jù)規(guī)模、性能延遲、成本預(yù)算等，能夠選擇不同的算法。”李杰輝表示。

不可能三角：穩(wěn)定、成本與性能

大模型火了之后，除了向量數(shù)據(jù)庫，一些中間件如 LangChain 和 Llama Index 也備受關(guān)注。這些中間件負(fù)責(zé)將向量數(shù)據(jù)庫與大語言模型（LLM）整合，形成 RAG 引擎。甚至有一些簡單將向量數(shù)據(jù)庫、中間件和 LLM 拼接起來的前端項目也吸引了大量關(guān)注。

然而，一套真正符合企業(yè)需求的 RAG 引擎并不僅僅是向量數(shù)據(jù)庫加上 LangChain 或 Llama Index 等中間件的簡單組合。從實踐來看，使用 LangChain 或者 Llama Index 原始方案，可能準(zhǔn)確率非常差，特別是在專業(yè)文獻的這種領(lǐng)域。也就是說簡單的拼裝方案可能對一些基礎(chǔ)的問答語料有效，但對于復(fù)雜的長文本或?qū)I(yè)領(lǐng)域（如財務(wù)報表或判決書）的檢索需求，僅靠簡單拼合難以達到預(yù)期效果。

對于一個能使準(zhǔn)確率得到很大的提升的 RAG 方案，需要從數(shù)據(jù)預(yù)處理到搜索增強整個流程不同階段增加干預(yù)跟定制化能力。

一個完整的 RAG 處理流程要分為幾個部分。首先一個是需要進行數(shù)據(jù)增強處理。無論是數(shù)據(jù)清理，還是對原始的半結(jié)構(gòu)化數(shù)據(jù)進行抽取，例如實體抽取或事件抽取，都需要進行詳細(xì)的處理。部分信息需要總結(jié)，并采用適當(dāng)?shù)姆椒ㄟM行分塊，而不是簡單地按照字?jǐn)?shù)進行劃分。比如，需要識別其中的表格和代碼，并將這些塊準(zhǔn)確地拆分出來。第二個部分就是存儲方案。最簡單的方法是將數(shù)據(jù)分割后，添加元數(shù)據(jù)、原文和向量，或者拼接字段也需要進行 schema 的設(shè)計，使得系統(tǒng)具有更強的結(jié)構(gòu)化檢索能力。第三個部分，就是進行混合搜索。例如基于向量后進行標(biāo)量過濾，或者關(guān)鍵詞召回和向量召回，然后進行混排和精排。

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

簡單來說，首先是對原始數(shù)據(jù)進行增強，然后進行合理的 schema 設(shè)計，而不僅僅是像 LangChain 那樣通用的方式，這樣檢索效果可能更好。最后，進行結(jié)構(gòu)化查詢設(shè)計和 rerank。特別是對于專業(yè)文獻，可能需要補充召回和 rerank 這些步驟，最終達到準(zhǔn)確的檢索效果。最后，對 prompt 進行調(diào)優(yōu)和處理，形成一個完整的端到端方案。這只是基礎(chǔ)單元，復(fù)雜場景下還需要進行 pipeline 設(shè)計，對意圖進行分類，并分成不同的任務(wù)來處理。

為了應(yīng)對復(fù)雜需求，火山引擎云搜索端到端的解決方案，提供的是一個完整的 RAG 生態(tài)，能夠?qū)⒒鹕揭嬉延械乃阉鞯慕?jīng)驗運用起來，比如 RAG 搜索的召回率提升，ES 的插件化能力，干預(yù)能力，以及基于 LangChain 或其他模型所不具備的抽象搜索和檢索重排功能。

“我的一個感受是 RAG 用戶關(guān)注的跟搜索用戶不一樣，就是他對準(zhǔn)確性的要求會高非常多。目前大部分用戶多多少少會遇到召回的準(zhǔn)確性不足，導(dǎo)致 RAG 回答效果不好的這種問題。這是 RAG 應(yīng)用的一個挑戰(zhàn)。”接觸過不少客戶的余煒強觀察到。

理論上開源文本搜索引擎提供了很強基礎(chǔ)能力，但是大部分用戶可能沒有足夠的檢索經(jīng)驗或能力去做優(yōu)化，從而將它們發(fā)揮到最好。字節(jié)跳動歷史上各類搜索經(jīng)驗，其中很大一部分可以并復(fù)用到了云搜索的 RAG 準(zhǔn)確率優(yōu)化上。另一方面云搜索團隊在 RAG 生態(tài)系統(tǒng)上開發(fā)了許多組件，以幫助用戶快速構(gòu)建端到端的 RAG 應(yīng)用，從而實現(xiàn)低接入成本和高效果的目標(biāo)。

對比 LangChain 和 Llama Index 和向量數(shù)據(jù)庫的簡單拼合方案，云搜索團隊的解決方案更為底層，雖然沒有可拖拽的 pipeline 單元，但通過交互式編程方式，結(jié)合 AI 生態(tài)和大模型管理能力，可以注入增強邏輯，構(gòu)建更復(fù)雜的應(yīng)用。理論上，這些干預(yù)能力可以直接嵌入到 LangChain 和 Llama Index 中。例如，如果將 OpenSearch 用作 Llama Index 的作為 vector store ，可以傳入一個 search pipeline。這個 pipeline 可以包含針對 RAG 的一些增強功能，包括干預(yù)增強，從而獲得更好的調(diào)優(yōu)體驗。

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

在實際應(yīng)用中，云搜索團隊發(fā)現(xiàn)客戶對底層檢索數(shù)據(jù)庫的需求通常可以歸納為三個維度：穩(wěn)定性、成本（越低越好）和延遲性能（越低越好）。

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

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

“我們發(fā)現(xiàn)在這個不可能三角里，用戶其實最看重的是穩(wěn)定和成本，這也與常規(guī)的行業(yè)認(rèn)知有一定偏差。”

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

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

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

構(gòu)建生產(chǎn)級 RAG 仍然是一個復(fù)雜而微妙的問題，如何高效地接入企業(yè)搜索生態(tài)、如何將性價比做得更好，所有這些問題都不是單純依靠開源的向量數(shù)據(jù)庫、開源的 RAG 就能輕松解決的，每個環(huán)節(jié)的增強、每一個構(gòu)建決策都能直接影響到產(chǎn)品的競爭力。

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