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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 開(kāi)源才不怕綁定

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

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

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

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

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

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

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

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

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

“開(kāi)源產(chǎn)品需要持續(xù)的維護(hù)和迭代，”魯蘊(yùn)鋮強(qiáng)調(diào)，“而社區(qū)的貢獻(xiàn)正是推動(dòng)產(chǎn)品發(fā)展的重要?jiǎng)恿ΑＮ覀兎e極參與 OpenSearch 社區(qū)的建設(shè)，不僅為產(chǎn)品帶來(lái)了新的功能和特性，也提升了產(chǎn)品的穩(wěn)定性和性能?！?/p>

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

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

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

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

另外，HNSW 加上 PQ 向量壓縮是目前已有的向量數(shù)據(jù)庫(kù)里用得最多的算法，雖然能夠滿足可能百分之八九十的云搜索用戶需求，但是這兩種其實(shí)已經(jīng)發(fā)表很久了。而火山引擎云搜索的應(yīng)用場(chǎng)景也比較多樣化，處理的數(shù)據(jù)規(guī)?？赡苓_(dá)到幾百億條，目前常見(jiàn)的基于內(nèi)存的向量引擎在這種規(guī)模下，會(huì)消耗非常多的資源，檢索時(shí)效上也不夠快。在這種情況下，云搜索團(tuán)隊(duì)又引入了基于磁盤(pán)的 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ù)十億的向量檢索。與常見(jiàn)的 ANN 算法相比，DiskANN 大幅提升向量召回的讀取效率，降低圖算法的內(nèi)存，提升召回率。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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