作者：Vipra Singh

編譯：ronghuaiyang

導讀

在系列博客中，我們通過檢索增強生成（RAG）應用的視角來學習大規模語言模型（LLM）。

1. 引言

在之前的博文中，我們已經討論到將原始數據嵌入爲向量的內容。爲了重複利用嵌入的信息，我們需要存儲這些嵌入，以便按需訪問。爲此，我們使用一種特殊的數據庫，即向量數據庫。

對於使用檢索增強生成（RAG）的大規模應用來說，高效存儲和檢索向量的能力，包括增刪改查操作、元數據過濾以及水平擴展，都是至關重要的。像 ChromaDB、Pinecone 和 Weaviate 這樣的向量數據庫專門針對這些需求，提供了快速檢索和相似性搜索功能。

集成合適的向量數據庫對於最大化 RAG 性能至關重要。根據應用場景的具體需求深思熟慮地選擇，可以確保存儲和檢索的無縫銜接，從而優化檢索增強生成模型的效能。

在本篇博文中，我們將深入探討向量數據庫與索引方法。

2. 向量數據庫 Vs. 其他數據庫

數據庫的對比

3. 向量數據庫 Vs. 向量索引 =================

在科技行業中，一個普遍存在的誤解認爲向量數據庫僅僅是近似最近鄰（Approximate Nearest Neighbor, ANN）搜索算法的簡單包裝。

實際上，向量數據庫是一種針對非結構化數據的綜合性解決方案。與這種誤解相反，它包含了現代結構化 / 半結構化數據庫管理系統中常見的用戶友好特性，包括雲原生支持、多租戶能力和可擴展性。它解決了獨立向量索引的侷限性，應對了可擴展性挑戰、集成複雜性，以及缺乏實時更新和內置安全措施的問題。隨着本教程的深入，這一點將變得越來越明顯。

另一方面，像 FAISS 和 ScaNN 這樣的輕量級 ANN 庫充當構建向量索引的工具。這些庫旨在加速多維向量的最近鄰搜索。雖然它們適用於生產系統中的小型數據集，但隨着數據集的增長，可擴展性就成了一個挑戰。

4. 流行的向量數據庫 ===========

4.1. 向量數據庫是如何工作的？

衆所周知，傳統數據庫以行和列的形式存儲字符串、數字和其他類型的標量數據。相比之下，向量數據庫則處理向量，因此它的優化和查詢方式大相徑庭。

在傳統數據庫中，我們通常查詢的是數據庫中與查詢值完全匹配的行。而在向量數據庫中，我們應用相似度度量來尋找與查詢向量最相似的向量。

向量數據庫使用了多種參與近似最近鄰 (ANN) 搜索的不同算法組合。這些算法通過各種索引技術優化搜索過程。

這些算法被組裝成一個管道，以提供對查詢向量鄰居的快速且準確的檢索。由於向量數據庫提供的結果是近似的，我們主要考慮的權衡是在準確性和速度之間。結果越準確，查詢速度就越慢。然而，一個良好的系統可以在近乎完美的準確性下提供超快速的搜索。

以下是向量數據庫的一個常見處理流程：

1. 索引建立：向量數據庫使用 PQ（Product Quantization）、LSH（Locality Sensitive Hashing）或 HNSW（Hierarchical Navigable Small World graphs）等算法對向量進行索引。此步驟將向量映射到一個數據結構中，以便加快後續的搜索速度。

2. 查詢：向量數據庫將索引後的查詢向量與數據集中的索引向量進行比較，以找出最近鄰（應用索引所使用的相似度度量）。

3. 後處理：在某些情況下，向量數據庫從數據集中檢索出最鄰近的向量，並進行後處理以返回最終結果。這一步驟可能包括使用不同的相似度度量對最近鄰向量進行重新排序。

在接下來的部分中，我們將更詳細地討論這些算法，並解釋它們是如何共同作用於提升向量數據庫的整體性能的。

5. 索引技術 =======

基於樹的方法 在低維數據中效率高，能夠提供精確的最近鄰搜索。然而，由於 “維度災難” 的影響，它們在高維空間中的性能通常會下降。此外，這類方法需要大量內存，並且在處理大型數據集時效率較低，導致較長的構建時間和更高的延遲。

量化方法 內存效率高，通過將向量壓縮爲緊湊的編碼來提供快速的搜索時間。但是，這種壓縮可能會導致信息損失，潛在地降低了搜索準確性。此外，這些方法在訓練階段可能會計算密集，增加了構建時間。

哈希方法 速度快且相對內存效率高，將相似向量映射到相同的哈希桶中。它們在處理高維數據和大規模數據集時表現良好，提供了高吞吐量；然而，由於哈希碰撞導致的誤報和漏報，搜索結果的質量可能較低。選擇合適的哈希函數數量和哈希表數量至關重要，因爲它們顯著影響性能。

聚類方法 可以通過縮小搜索空間到特定聚類來加速搜索操作，但搜索結果的準確性會受到聚類質量的影響。聚類通常是批量處理過程，這意味着它不適合動態數據，其中不斷有新向量加入，導致頻繁的重新索引。

圖方法 在準確性和速度之間提供了良好的平衡。它們在處理高維數據時效率高，可以提供高質量的搜索結果。然而，它們可能對內存要求較高，因爲需要存儲圖結構，並且圖的構建也可能計算成本高昂。

向量數據庫中算法的選擇取決於任務的具體需求，包括數據集的大小和維度、可用的計算資源，以及在準確性和效率之間的可接受權衡。同時，值得注意的是，許多現代向量數據庫採用混合方法，結合不同方法的優點以實現高速度和高準確性。理解和權衡這些算法對於任何希望從向量數據庫中獲得最佳性能的人來說至關重要。接下來，我們將逐一探討這些類別中所有流行的算法。

6. 精確匹配 ===========

6.1. 扁平索引（暴力搜索，Flat Indexing）

扁平索引以犧牲搜索速度爲代價，實現了完美的搜索質量。扁平索引的內存利用率是合理的。

我們首先應考察的索引是最簡單的——扁平索引。

扁平索引之所以稱爲 “扁平”，是因爲我們不對輸入的向量做任何修改。

由於不對向量進行近似或聚類處理——這些索引能夠產生最準確的結果。我們獲得了完美的搜索質量，但這是以顯著增加的搜索時間爲代價的。

在使用扁平索引時，我們引入查詢向量 xq，並將它與索引中每一個全尺寸向量進行比較，計算到每個向量的距離。

使用扁平索引，我們將請求 xq 和每一個索引中的向量進行對比

計算完所有這些距離之後，我們返回距離最近的 k 個作爲最近鄰匹配，這就是 k 近鄰（kNN）搜索。

6.2. 平衡搜索時間

扁平索引在準確性方面表現出色，但搜索速度極慢。在相似性搜索中，搜索速度和搜索質量（準確性）之間總是存在權衡。

我們必須做的是確定我們的用例最佳平衡點位於何處。使用扁平索引時，我們處於這樣的狀態：

扁平索引是 100% 的搜索質量 0% 的搜索速度

這裏我們的搜索速度未經過優化，這可能適用於許多較小索引的使用場景，或者在搜索時間無關緊要的情況下。但其他應用場景需要在速度和質量之間取得更好的平衡。

那麼，我們如何加快搜索速度呢？主要有兩種方法：

1. 減少向量大小：通過降維或將表示向量值的比特數減少。

2. 縮減搜索範圍：我們可以通過聚類或將向量根據某些屬性、相似性或距離組織成樹狀結構來實現這一點，然後將搜索限制在最近的簇內或只遍歷最相似的分支。

採用上述任一方法意味着我們不再執行全面的最近鄰搜索，而是執行近似最近鄰 (ANN) 搜索，因爲我們不再遍歷整個高分辨率數據集。

因此，我們得到的是一個更均衡的組合，既重視搜索速度也考慮到了搜索時間：

一般來說，我們想要一個速度和質量更加均衡的搜索

7. 近似匹配 =======

7.1. 近似最近鄰（Annoy）

在向量數據庫中使用的基於樹的算法中，Annoy（或稱 “Approximate Nearest Neighbors Oh Yeah”）以其高效性和簡潔性脫穎而出。Annoy 是一個 C++ 庫，帶有 Python 綁定，由 Spotify 設計，用於在空間中查找與給定查詢點接近的點（近似匹配）。它創建大型只讀、基於文件的數據結構，這些結構通過內存映射進入內存，使得多個進程可以共享相同的數據。

Annoy 通過使用隨機投影樹的森林來進行高效的 ANN 搜索。算法將點投射到隨機超平面上，並根據點落在超平面的哪一側來劃分空間。這一過程遞歸進行，形成了空間分區的二叉樹。創建了一個森林，每棵樹都有不同的隨機種子。當收到查詢點時，算法遍歷森林中的每棵樹，找到該點所屬的葉節點。然後通過收集所有樹中找到的葉節點中的點列表，並從這個列表中返回與查詢點最近的前 k 個點，來近似最近鄰。

Annoy 特別適合高維數據，因爲在高維數據中，精確的最近鄰搜索可能成本過高。它在 Spotify 的音樂推薦中投入生產使用，根據音頻特徵幫助找到相似歌曲。因此，準確性會受到森林中樹的數量以及搜索過程中檢查的點數的影響，這兩者都可以根據任務的具體需求進行調整和優化。

Annoy 的高效性和內存效率使其成爲處理高維數據和大型數據庫的強大選擇。但也有一些權衡需要考慮。構建索引可能需要大量時間，特別是對於大型數據集而言。由於 Annoy 使用隨機森林分區算法，索引不能隨着新數據的加入而更新，必須從頭重建。根據你的數據集大小或數據變化的頻率，重新訓練索引可能成本高昂。

7.2. 逆文檔（IVF）索引

IVF - 優秀的搜索質量，良好的搜索速度，以及合理的內存使用。條形圖中 “半填充” 的部分表明在調整索引參數時性能變化的範圍。

IVF（Inverted File Index）索引通過聚類來減少搜索範圍。它非常受歡迎，因爲易於使用，同時提供高搜索質量和合理的搜索速度。

它基於 Voronoi 圖的概念運作——也被稱爲 Dirichlet 鑲嵌（一個聽起來更酷的名字）。

爲了理解 Voronoi 圖，我們可以想象將高維向量投射到二維空間中。隨後在我們的二維空間中放置幾個額外的點，這些點將成爲我們的 “聚類中心”（在此情況下爲 Voronoi 單元）。

接着，從每個中心點向外延伸相同半徑的圓。在某個點上，每個圓的周長會與其他圓相交——這樣就形成了我們的單元邊界：

現在，每個數據點都將被包含在一個單元內，並被分配給相應的中心點。

和使用其他索引一樣，我們引入查詢向量 xq —— 這個查詢向量必定會落入我們某個單元內，這時我們將搜索範圍限制在那個單一的單元裏。

但如果查詢向量落在單元邊緣附近，就存在一個問題——離它最近的另一個數據點很可能位於相鄰的單元中。我們稱這種情況爲_邊緣問題_：

爲緩解這個問題並提高搜索質量，我們可以增加一個稱爲 nprobe 的索引參數值。通過 nprobe，我們可以設定要搜索的單元數量。

7.3. 隨機投影 (RP)

隨機投影的基本思想是利用隨機投影矩陣將高維向量投影到低維空間。我們生成一個隨機數構成的矩陣，該矩陣的大小是我們期望的目標低維值。接着，我們計算輸入向量與該矩陣的點積，得到的投影矩陣比原始向量的維度低，但仍能保留它們之間的相似性。

查詢時，我們使用相同的投影矩陣將查詢向量投影到低維空間中。然後，我們將投影后的查詢向量與數據庫中投影后的向量進行比較，以找到最近的鄰居。由於數據的維度降低，搜索過程比在整個高維空間中搜索要快得多。

只需記住，隨機投影是一種近似方法，投影質量取決於投影矩陣的性質。一般來說，投影矩陣的隨機性越高，投影質量越好。然而，生成真正的隨機投影矩陣可能在計算上相當昂貴，特別是對於大型數據集。

7.4. 乘積量化（PQ）

構建索引的另一種方法是乘積量化（PQ），這是一種針對高維向量（如向量嵌入）的_有損_壓縮技術。它將原始向量分解成更小的部分，通過爲每個部分創建一個代表性 “碼” 來簡化每個部分的表示，然後將所有部分重新組合起來，同時不會丟失對於相似性操作至關重要的信息。PQ 的過程可以分爲四個步驟：分割、訓練、編碼和查詢。

1. 分割 - 向量被分解成多個片段。

2. 訓練 - 我們爲每個片段構建一個 “碼本”。簡而言之，算法生成一系列潛在的“碼”，這些碼可以分配給向量。實際上，這個“碼本” 是由對向量每個片段執行 k-means 聚類所產生的聚類中心點組成的。碼本中的值的數量與我們在 k-means 聚類中使用的 k 值相同。

3. 編碼 - 算法爲每個片段分配一個特定的碼。實踐中，訓練完成後，我們會爲向量的每個片段找到碼本中最接近的值。該片段的 PQ 碼就是碼本中相應值的標識符。我們可以根據需要使用任意數量的 PQ 碼，這意味着每個片段可以從碼本中選擇多個值來表示。

4. 查詢 - 查詢時，算法將向量分解爲子向量，並使用相同的碼本來量化它們。然後，它利用索引的碼來找到與查詢向量最接近的向量。

碼本中代表向量的數量在表示的準確性與搜索碼本的計算成本之間存在權衡。碼本中代表向量越多，子空間中向量的表示就越準確，但搜索碼本的計算成本就越高。相反，碼本中代表向量越少，表示的準確性就越低，但計算成本也就越低。

7.5. 局部敏感哈希 (LSH)

LSH（局部敏感哈希）— 其性能範圍廣，極大依賴於設置的參數。高質量的搜索結果會導致較慢的搜索速度，而快速的搜索則會降低搜索質量。對於高維數據表現不佳。條形圖中 “半填充” 的部分表示在調整索引參數時遇到的性能波動範圍。

局部敏感哈希（Locality Sensitive Hashing, LSH）的工作原理是通過哈希函數處理每個向量，將向量分組到 “桶” 中，該哈希函數旨在最大化哈希衝突，而非通常哈希函數所追求的最小化衝突。

這是什麼意思呢？想象我們有一個 Python 字典。當在字典中創建新的鍵值對時，我們使用哈希函數對鍵進行哈希。鍵的哈希值決定了存儲其相應值的 “桶” 位置。

典型的字典類對象所用的哈希函數會盡量減少哈希衝突，力求每個桶只分配一個值。

Python 字典就是使用了典型哈希函數的哈希表的例子，這種函數最小化了哈希衝突，即兩個不同對象（鍵）產生相同哈希值的情況。

在字典中，我們希望避免這些衝突，因爲這意味着多個對象會被映射到同一個鍵下——但在 LSH 中，我們卻想最大化哈希衝突。

爲何要最大化衝突呢？這是因爲對於搜索而言，我們利用 LSH 來將相似的對象聚集在一起。當我們引入一個新的查詢對象（或向量）時，我們的 LSH 算法就能用來找到最匹配的組羣：

7.6. 分級導航小世界 (HNSW)

HNSW — 搜索質量高，搜索速度快，但索引體積較大。條形圖中 “半填充” 的部分展示了在調整索引參數時遇到的性能變化範圍。

HNSW 構建了一種層次化的、樹狀結構，其中樹的每個節點代表一組向量。節點間的邊表示向量之間的相似度。算法開始時，創建一組節點，每個節點包含少量向量。這可以通過隨機方式完成，也可以使用如 k-means 聚類算法，將每個聚類變成一個節點。

然後，算法檢查每個節點的向量，並在該節點與其擁有最相似向量的節點之間繪製邊。

在使用 HNSW 索引進行查詢時，它利用這張圖來遍歷樹結構，訪問那些最有可能包含與查詢向量最接近向量的節點。

7.7. 基於密度的噪聲空間應用聚類 (DBSCAN)

DBSCAN 算法基於密度可達性和密度連通性的概念進行操作。它從數據集中的一個任意點開始，如果在這個點的給定半徑eps內至少有minPts個點，則創建一個新的聚類。這裏的eps（epsilon）是一個用戶定義的輸入值，表示在聚類中考慮兩點間最大允許的距離，而minPts是指形成一個聚類所需的最少數據點數目。然後，算法迭代地將eps半徑內所有直接可達的點加入到聚類中。這一過程持續進行，直到無法再向聚類中添加更多點爲止。之後，算法繼續處理數據集中下一個未訪問的點，並重復這一過程，直到所有點都被訪問過。在 DBSCAN 中，關鍵參數是eps和minPts，分別定義了點的聚類範圍以及形成聚類所需的最小點密度。

8. 相似度度量：距離度量

相似度度量是數學方法，用於確定向量空間中兩個向量的相似程度。在向量數據庫中，這些度量被用來比較數據庫中存儲的向量，並找出與給定查詢向量最相似的那些。

可以採用幾種不同的相似度度量方法，包括：

• 餘弦相似度：計算兩個向量在向量空間中夾角的餘弦值。其範圍從 - 1 到 1，其中 1 表示完全相同的向量，0 表示正交向量，而 - 1 表示方向完全相反的向量。

• 歐幾里得距離：衡量向量空間中兩點間的直線距離。其範圍從 0 到無窮大，0 表示完全相同的向量，而數值越大代表向量之間的差異越大。

• 點積（內積）：計算兩個向量的大小乘以它們之間夾角的餘弦值。其結果範圍從負無窮到正無窮，正值表示向量大致指向相同方向，0 表示正交向量，負值則表示向量大致指向相反方向。

8.1. 如何選擇相似度度量

確實，通常最佳實踐是使用與訓練嵌入時相同的相似度度量來進行搜索；然而，相似度度量的選擇也應依據數據的具體特性和所解決問題的上下文來決定。以下是針對討論過的每種相似度度量的一些主要應用領域：

歐氏距離

• 聚類分析：例如 k-means 算法，根據向量空間中的鄰近性對數據點進行分組。

• 異常檢測與欺詐識別：在這種情況下，通過與正常交易集中心點異常大的距離可識別出異常數據點。

點積

• 圖像檢索與匹配：視覺內容相似的圖像其向量將高度一致，導致較高的點積值，因此在尋找與查詢圖像相似的圖像時，點積是一個很好的選擇。

• 神經網絡與深度學習：在神經網絡中，全連接層利用點積來結合輸入特徵與可學習權重，捕捉特徵間的關係，對於分類和迴歸等任務非常有幫助。

• 音樂推薦：點積相似度有助於識別具有相似音頻特徵的曲目，對音樂推薦系統而言極爲寶貴。

餘弦相似度

• 主題建模：在文檔嵌入中，每個維度可以代表詞頻或 TF-IDF 權重。不同長度的文檔可能具有截然不同的詞頻，但擁有相似的詞分佈。由於這使得它們在向量空間中的方向相似但距離不同，因此餘弦相似度是理想選擇。

• 文檔相似性：這是主題建模的另一應用。相似的文檔嵌入具有相似的方向，但距離可能不同。

• 協同過濾：這種推薦系統方法利用用戶的集體偏好和行爲來做出個性化推薦。用戶（或項目）根據他們的交互被表示爲向量。儘管總體評分和受歡迎程度可能導致不同的距離，但相似向量的方向仍然接近，因此常採用餘弦相似度。

9. 過濾 =====

每個儲存在數據庫中的向量都附帶有元數據。除了查詢相似向量的能力之外，向量數據庫還能夠根據元數據查詢來過濾搜索結果。爲此，向量數據庫通常維護兩個索引：一個向量索引和一個元數據索引。它會在向量搜索之前或之後執行元數據過濾，但這兩種情況都可能存在一些導致查詢過程變慢的難題

過濾過程可以在向量搜索之前或之後進行，但每種方法都有可能影響查詢性能的挑戰：

• 預過濾：此方法中，在向量搜索之前進行元數據過濾。雖然這有助於減小搜索範圍，但也可能導致系統忽略不滿足元數據過濾標準的相關結果。此外，複雜的元數據過濾可能會因額外的計算負擔而拖慢查詢進程。

• 後過濾：在這種方法中，元數據過濾在向量搜索之後執行。這樣可以確保考慮所有相關結果，但也會因完成搜索後需要剔除不相關結果而引入額外開銷，從而可能減慢查詢進程。

爲了優化過濾過程，向量數據庫採用多種技術，比如利用高級索引方法處理元數據，或採用並行處理加速過濾任務。在搜索性能與過濾準確性之間取得平衡，對於向量數據庫提供高效且相關的查詢結果至關重要。

10. 選擇一個向量數據庫 =============

爲您的決策提供一份簡明概要：

1. 開源與雲託管服務：傾向開源方案時，Weaviate、Milvus 和 Chroma 成爲首選競爭者。儘管 Pinecone 非開源，其卓越的開發者體驗和全面託管解決方案尤爲突出。

2. 性能：就每秒查詢量的原始性能而言，Milvus 領跑，Weaviate 和 Qdrant 緊隨其後。而在延遲方面，Pinecone 和 Milvus 均展現出了低於 2 毫秒的出色成績。增加 Pinecone 的多節點部署後，可實現更高的查詢速率。

3. 社區活躍度：Milvus 擁有最龐大的社區基礎，其次爲 Weaviate 和 Elasticsearch。強健的社區通常意味着更佳的支持、功能升級和漏洞修復。

4. 可擴展性、高級功能與安全性：對於衆多企業應用至關重要的基於角色的訪問控制，在 Pinecone、Milvus 和 Elasticsearch 中均有提供。在擴展性方面，Milvus 和 Chroma 支持動態片段分配，適配不斷變化的數據集。若需多樣化的索引類型，Milvus 支持 11 種不同索引，無人能及。儘管各平臺廣泛支持混合搜索，但在磁盤索引支持上，Elasticsearch 相對不足。

5. 價格：對預算有限的初創企業或項目來說，Qdrant 提供的 5 萬向量約 9 美元定價極具吸引力。而對於追求高性能的大規模項目，Pinecone 和 Milvus 提供了有競爭力的定價體系。

總之，向量數據庫的選擇沒有統一標準，最合適的選項取決於特定項目需求、預算限制和個人喜好。

10.1. 參數對比

• 開源：表明軟件的源代碼是否對公衆免費開放，允許開發者審查、修改和分發該軟件。

• 自託管：指出數據庫是否能夠在用戶自己的基礎設施上運行，而不是依賴第三方雲服務。

• 雲管理界面：是否提供數據庫雲管理的界面。

• 專爲向量設計：這意味着數據庫專門針對向量存儲和檢索進行了設計，而非一般數據庫附加向量功能。

• 開發者體驗：評估開發者使用數據庫的友好性和直觀性，包括文檔、SDKs、API 設計等因素。

• 社區：評估圍繞數據庫的開發者社區的規模和活躍度。強大的社區通常意味着良好的支持、貢獻及持續開發潛力。

• 每秒查詢量：使用特定數據集（此處爲 nytimes-256-angular 數據集）進行基準測試時，數據庫每秒能處理的查詢次數。

• 延遲：從發起請求到接收響應的時間差（以毫秒爲單位）。針對 nytimes-256-angular 數據集，95% 的查詢延遲低於指定時間。

• 支持的索引類型：指數據庫支持的各種索引技術，這些技術能影響搜索速度和準確性，包括 HNSW、IVF 等。

• 混合搜索：判斷數據庫是否支持將傳統（標量）查詢與向量查詢相結合，這對於需基於非向量標準篩選結果的應用至關重要。

• 磁盤索引支持：表示數據庫是否支持在磁盤上存儲索引，這對於處理無法全部載入內存的大型數據集非常重要。

• 基於角色的訪問控制：檢查數據庫是否有允許向特定角色或用戶授予權限的安全機制，以增強數據安全性。

• 動態段落放置與靜態數據分片：涉及數據庫如何管理數據分佈和擴展。動態段落放置可根據實時需求靈活分配數據，而靜態數據分片則是將數據預先分割成確定的段。

• 免費託管層級：指出數據庫提供商是否提供免費的雲託管版本，使用戶無需初始投資即可測試或使用數據庫。

• 價格（5 萬向量 @1536 維）與價格（2000 萬向量，2000 萬次請求 @768 維）：提供存儲和查詢特定數據量的費用信息，爲小型和大規模應用場景的成本效益提供參考。

總結

這篇博客爲我們提供了一個關於向量數據庫的精簡探索，特別強調了它們在檢索增強生成（RAG）應用中的關鍵作用。作者突出了諸如 ChromaDB、Pinecone 和 Weaviate 等流行數據庫的重要性，強調了爲達到最優 RAG 性能，高效存儲與檢索的必要性。

博客深入介紹了多種索引技術和算法，洞悉了 Annoy、倒排文件（IVF）索引、隨機投影、乘積量化、局部敏感哈希（LSH）、HNSW 和 DBSCAN 等方法。同時，它進一步解釋了餘弦相似度、歐氏距離和點積等相似度量，並給出了在文檔相似性、圖像檢索和協同過濾中的實際應用案例。

文章中還有一大部分內容致力於幫助讀者選擇合適的向量數據庫。考慮的關鍵因素包括開源可用性、性能、社區強度、可擴展性、高級功能、安全性和價格。比較參數提供了快速概覽，使讀者能夠根據自身特定需求和偏好做出明智的決策。

總之，這篇博客作爲向量數據庫導航的快速指南，爲無縫集成和優化 RAG 模型提供了必需的知識基礎。

—END—

英文原文：https://medium.com/@vipra_singh/building-llm-applications-vector-database-part-4-2bb29e7c798d

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/gf9G8gI1zV8Nmlo1eB6lAw