- 向量資料庫儲存和索引嵌入，從而實現對非結構化資料進行快速語義相似性搜尋。
- 它們透過充當外部記憶層來為 NLP 和 RAG 提供支持，將向量距離與元資料過濾器結合。
- 專用引擎、支援向量的 SQL 資料庫和像 VDB 這樣的輕量級程式庫可以滿足不同的規模和控制需求。
- 人工神經網路演算法和距離度量（如 HNSW、L2 和餘弦）對精確度、延遲和資源使用有顯著影響。
本文將詳細介紹向量資料庫領域，重點在於輕量級、本地部署的方案。：向量資料庫究竟是什麼，它與普通向量索引有何不同，它如何為自然語言處理和隨機數生成提供支持，哪些引擎和擴展值得考慮（從 Milvus 和 Qdrant 到 PostgreSQL pgvector 和 VDB 等嵌入式庫），以及距離度量和人工神經網路演算法如何影響品質和效能。
什麼是向量資料庫？它為什麼重要？
傳統關係型資料庫在處理行和列形式的結構化資料方面表現出色。但是，當需要處理大量非結構化內容時，它們就顯得力不從心了。將 PDF、聊天記錄、圖像或感測器資料載入到傳統的 SQL 模式中，然後再將其準備好供人工智慧使用，不僅繁瑣，而且在需要語義相似性而非精確匹配時，計算效率也很低下。
向量資料庫透過直接處理稠密向量（而非僅僅處理詞元或關鍵字）來解決這個問題。與其問“這個字段是否包含單字‘smartphone’？”，不如問“哪些儲存的向量最接近查詢嵌入？”，系統會返回語義相關的項目，即使它們不共享完全相同的措辭。
這種從關鍵字匹配到向量空間相似性的轉變正是其優勢。 語義搜索強大的推薦功能和強大的檢索增強生成（RAG）現在，企業可以將傳統的業務資料與「語意記憶」結合到單一架構中，既可以透過專用的向量引擎，也可以透過在現有資料庫中啟用向量類型來實現。
向量、嵌入及其實際解決的問題
任何向量資料庫的核心都是向量：有序的數字列表，用於在多維空間中定位項目。每個向量對應一個物件——句子、段落、圖像、產品、使用者個人資料——這些物件透過機器學習模型學習，並沿著數十、數百甚至數千個維度進行編碼。
不同的嵌入模型定義了不同的向量空間和維度。有些方法可能輸出 384 維向量，有些則輸出 768 維甚至更高；隨著維度的增加，表示形式可以捕捉更豐富的細微差別，但高效索引也變得更具挑戰性。向量資料庫正是專門處理這類問題：大規模的長浮點向量。
它們真正解決的痛點是傳統關鍵字搜尋在非結構化資料上的僵化性。傳統的「智慧型手機」搜尋會遺漏只提到「手機」或「行動裝置」的文件；允許拼字錯誤的關鍵字搜尋會有一些幫助，但它仍然無法真正理解「擁有自然採光的中世紀現代住宅」是一種風格，而不是你在每個房源清單中都能找到的字面短語。
透過儲存嵌入向量，向量資料庫可以實現相似性搜尋：查詢和文件都是向量，向量空間中的接近程度代表語義相關性。這就是為什麼搜尋「手機」可以檢索到只提到「智慧型手機」的文件；即使表面形式不同，它們的嵌入也落在空間的同一區域。
向量索引與完整向量資料庫
將「向量索引」的概念與完整的向量資料庫的概念區分開來是有益的。兩者都處理向量，但它們解決問題的層次不同，並且具有不同的特徵集。
向量索引是一種針對最近鄰搜尋進行最佳化的資料結構你給它一組向量和一個查詢向量，它就能告訴你哪些儲存項目與查詢項目最接近。像 FAISS 這樣的函式庫在這方面表現出色；它們實現了高效的近似最近鄰 (ANN) 搜尋和聚類演算法，但它們並非完整的資料庫系統。
相較之下，向量資料庫則利用資料庫功能封裝了這些索引。 例如元資料儲存、模式管理、安全性、資源管理、並發控制、故障復原以及與更廣泛的資料生態系統的整合。組織機構在這裡保存嵌入物件和原始物件（或對它們的引用），而不僅僅是索引結構。
企業級向量資料庫還提供查詢語言和 API，這些語言和 API 將向量相似性與結構化屬性的過濾器結合。您可以查詢“與此段落相似的文檔，其中 project = X 且 created_at 在過去 30 天內”，僅使用索引庫很難乾淨利落地完成此操作。
一些現代關係系統透過加入原生向量類型，已經成為「支援向量的資料庫」。例如，Oracle 資料庫和 MySQL 現在除了傳統的數值和文字欄位外，還支援向量。這使您可以將業務記錄和嵌入內容保存在同一個引擎中，從而避免在單獨的向量儲存和主資料庫之間出現一致性問題。
向量資料庫如何為自然語言處理和生成式人工智慧提供支持
語義搜尋是最顯而易見的應用案例之一。該系統摒棄了傳統的關鍵字匹配方式，而是將使用者查詢和所有已索引文件嵌入其中，然後檢索向量最接近的文檔。它能夠處理同義詞、釋義，甚至略微偏離主題但上下文相關的短語，從而顯著提升了搜尋相關性，遠勝於純文字搜尋。
這一語意層還能降低拼字錯誤和吵雜語言的影響。使用者不必完美地表達查詢；只要整體意義相似，嵌入模型就會將查詢放置在正確的文件附近，向量資料庫會將這些文件呈現出來。
高效率的嵌入管理是另一個關鍵作用向量資料庫經過優化，能夠存儲、索引和檢索大型模型生成的大量文本嵌入；它們使應用程式能夠將其視為一個快速、可查詢的“內存庫”，可以在毫秒級內訪問，而不是像某些應用程序進程中的文件集合或臨時數組那樣進行訪問。 大型模型產生的嵌入 通常依靠運行時和加速器來實現規模化應用。
實際上，這在多個自然語言處理應用中都有體現。聊天機器人和人工智慧助理使用向量資料庫來尋找先前對話或文件的相關部分；問答系統將文件轉換為嵌入，並透過檢索和合成正確的段落來回答複雜的問題；情感和意圖分析受益於向量中編碼的更豐富的語義關係；推薦引擎根據項目和用戶在嵌入空間中的接近程度來推斷它們之間的相似性。
檢索增強生成（RAG）中的向量搜索
檢索增強生成（RAG）結合了向量搜尋和大型語言模型，以解決諸如幻覺和過時知識等問題。LLM 具有固定的訓練截止點，除非您在推理時明確提供，否則無法查看您的專有文件。
典型的 RAG 流程首先是將知識庫分割成較小的部分。 例如，文字區塊大小為 200-500 個單詞，然後使用選定的模型將每個文字區塊編碼成一個嵌入向量。這些向量以及標題、標籤或來源 URL 等元資料一起儲存在向量資料庫中。
當使用者提出問題時，系統會將查詢嵌入相同的模型中。 並對儲存的詞嵌入執行相似性搜尋。前 k 個最接近的詞塊被認為與問題“相關”，並且由於資料庫的 ANN 索引，可以在幾毫秒內檢索到這些詞塊。
然後將檢索到的資料塊新增至 LLM 提示字元的前面或以其他方式註入其中。這就是「增強」部分：該模型接收原始用戶請求和幾個相關的外部上下文，這有助於它基於事實而不是猜測來給出答案。
最後，LLM根據檢索到的上下文產生一個回應。由於資料庫內容可以不斷更新，RAG 允許 LLM 使用最新的、特定領域的資訊進行回答，而無需重新訓練模型本身，並且透過將輸出錨定在實際文件中來減少幻覺。
相似性搜尋的實際工作原理
從本質上講，向量搜尋是將查詢向量與多個已儲存的向量進行比較，並根據距離或相似度分數對它們進行排序。真正的挑戰在於，當有數百萬甚至數十億個高維向量時，如何快速且準確地完成這項工作。
各引擎的基本步驟是一致的。首先，你需要將資料向量化：文字、圖像、音訊或其他內容透過嵌入模型產生向量。接下來，將這些向量儲存在資料庫中，通常還會儲存ID和元數據，並在此基礎上建立一個或多個人工神經網路（ANN）索引。
在查詢時，使用者輸入也被嵌入到一個向量中。然後，資料庫使用該索引，根據選定的度量（餘弦相似度、歐氏距離、內積或其他）找到近似最近鄰居，並返回最佳匹配及其相似度得分。
結果通常會以相似度分數排序，因此最接近的向量會排在最前面。許多引擎還支援混合查詢，您可以在按元資料（例如價格範圍、位置、類別）篩選的同時，優化向量相似性，從而獲得更具商業感知的結果。
為了實現大規模的快速處理，現代向量資料庫依賴近似最近鄰演算法。它們犧牲了一小部分記憶力，換取了速度和記憶體使用方面的巨大提升，這對於大多數現實世界的 AI 應用來說是可以接受的。
關鍵的人工神經網路演算法：HNSW、LSH 和乘積量化
分層可導航小世界（HNSW）是向量資料庫中應用最廣泛的人工神經網路演算法之一。它將向量組織成多個圖層：上層節點較少，連接範圍較遠，而下層節點較密集，最底層所有節點都相互連接。
在搜尋過程中，HNSW 從頂層的一個入口點開始，貪婪地向附近的鄰居移動。隨著搜尋的不斷優化，它會逐層向下移動。這種分層圖結構能夠有效平衡召回率和延遲，這也是 HNSW 為 Milvus、Qdrant 等引擎提供支援的原因。
局部敏感雜湊 (LSH) 採用不同的方法，使用雜湊函數將相似的向量以高機率映射到同一個桶中。與試圖避免衝突的傳統雜湊演算法不同，LSH 演算法允許相似項發生衝突。它建立了多個哈希表，使得每次查詢只需檢查匹配桶中的候選項，而無需檢查整個資料集。
這種方法能夠以機率方式有效地降低維度，同時保留鄰域結構。對於高維度數據，當需要極快的候選生成速度並且能夠容忍近似結果時，LSH 可能非常有吸引力。
乘積量化（PQ）著重於壓縮向量，以節省記憶體並加速距離計算。它將每個高維向量分成幾個子向量，然後分別量化每個子空間，並只儲存最近的質心的 ID，從而形成一個短碼。
這種壓縮方法可以在保持距離估計功能的同時，將記憶體使用量減少 90% 以上。雖然 PQ 是有損的，可能會稍微降低搜尋精度，但對於記憶體是主要瓶頸的大型集合來說，它非常強大，並且是 FAISS 等工具和一些向量資料庫後端的主要組成部分。
距離測量：歐氏距離、餘弦距離及其他
向量搜尋的品質也很大程度取決於您選擇的距離或相似度度量。最常見的兩種選擇是歐氏距離（L2）和餘弦相似度（或其補集，餘弦距離）。
歐氏距離衡量的是n維空間中兩點之間的直線距離。對於向量 P 和 Q，相似度是座標差平方和的平方根。距離越短，相似度越高，其值範圍從 0（向量完全相同）到無限大。
此指標對數值大小較為敏感。如果一個向量比另一個向量長得多——例如，代表更長的文檔或更大的特徵值——歐氏距離會反映出這一點，即使兩個向量大致指向同一方向。當絕對尺度具有語義意義時，例如物理座標或連續數值特徵（其中大小至關重要），這種方法效果很好。
相較之下，餘弦相似度關注的是兩個向量之間的角度，而不是它們的長度。它是向量點積除以向量範數的乘積。許多實際系統使用餘弦距離 = 1 − 餘弦相似度，其中 0 表示方向相同，數值越大表示差異越大。
由於餘弦相似度忽略了大小，因此當方向編碼語義時，它是理想的選擇。在文本應用中，關於同一主題的兩篇文檔——一篇短，一篇長——仍然應該被視為非常相似；餘弦距離可以實現這一點，而歐氏距離可能會僅僅因為較長的文檔計數較大就對其進行懲罰。
在自然語言處理中常見的高維度稀疏空間中，餘弦相似度往往比歐氏距離表現得更穩健。「維度災難」使得在高維度空間中所有歐氏距離看起來都趨於相似，這會降低區分能力。餘弦轉換作用於歸一化向量，通常能為文字嵌入提供更有意義的相似性排序。
選擇指標最終取決於你希望在你的領域中「相似性」代表什麼。如果尺度很重要——例如，基於偏差幅度的異常檢測——歐氏距離可能更合適。如果主體接近程度或方向一致性比長度更重要，餘弦距離通常是更好的選擇。一些資料庫也提供內積作為測量，當向量歸一化時，內積與餘弦距離密切相關。
流行的向量資料庫和向量系統
向量儲存方案的生態系統已經爆炸性成長，涵蓋了從完全託管的雲端服務到自架開源引擎和庫式解決方案等各種選擇。正確的選擇取決於您的規模、預算、營運限制以及您希望與現有資料基礎設施的整合程度。
專用的向量資料庫從一開始就是為高通量相似性搜尋而建構的。它們通常支援多個 ANN 索引、複雜的壓縮方案、豐富的元資料過濾以及生產級聚類和故障轉移。
Milvus 是一個強大的開源向量資料庫的典型例子，專為大規模工作負載而設計。它面向機器學習、深度學習、相似性搜尋和推薦系統，並支援 GPU 加速、分散式查詢以及各種索引方法，如 IVF、HNSW 和 PQ。
這種可配置性使您可以根據自身需求平衡呼叫、延遲和儲存空間佔用。Milvus 非常適合擁有數十億向量、多語言內容和嚴格效能要求的企業，並且可以無縫整合到複雜的資料平台中。
其他專用引擎則滿足略有不同的市場需求。Pinecone專注於提供具有嚴格服務等級協定 (SLA) 和強大元資料功能的全託管雲端部署；Weaviate提供具有GraphQL API、內建向量化器和混合關鍵字+向量搜尋功能的開源引擎；Qdrant提供具有高級人工神經網路 (ANN)方法和靈活過濾功能的快速開源向量搜尋服務；Chroma面向更簡單的用例和實驗，並提供便捷的開發者體驗；Vespa擅長混合搜尋和排名，可處理結構化欄位、文字和向量；Deep Lake專注於圖像和影片等多模態資料集，其中與機器學習框架的緊密整合至關重要。
同時，通用資料庫也開始採用向量特徵，而不是完全放棄這一領域。對於已經投資 SQL 或文件儲存的組織來說，這是一種無需建立單獨系統即可添加語義搜尋的務實方法。
使用 pgvector 擴充的 PostgreSQL 是這裡最受歡迎的方案之一。Pgvector 引入了 VECTOR 類型，可以直接在 Postgres 表中儲存固定維度的向量，並公開了歐氏距離、內積和餘弦距離的相似性運算符。
這表示您可以建立一個類似 embeddings(id SERIAL PRIMARY KEY, vector VECTOR(768)) 的表建立索引後，即可執行「給我按 L2 距離排序的 5 個最接近的向量」之類的查詢，所有操作均使用標準 SQL。該擴展支援高維索引，並且可以很好地整合到 LangChain 等框架中。
pgvector 的最大優勢在於其簡潔性和整合性。您的事務資料、分析表和嵌入資料都儲存在同一個引擎中，並採用統一的備份和安全方案。但缺點是，Postgres 並非專為處理數十億向量工作負載而設計，因此在超大規模或極低延遲要求下，專用向量資料庫通常會優於它。
Elasticsearch 和 OpenSearch 也可以轉換為向量感知系統。 透過 k-NN 插件。如果您的團隊已經運行了一個用於日誌或全文的搜尋集群，那麼啟用向量欄位可能足以在無需重新架構的情況下實現語義搜尋原型。 MongoDB 也加入了這一趨勢，將向量搜尋整合到其以文件為導向的生態系統中，以支援更輕量級的使用情境。
嵌入式和輕量級選項：VDB 和本機部署場景
並非每個項目都需要（或能夠負擔得起）分散式企業級向量資料庫。對於許多正在建立 MVP、研究工具或裝置端應用程式的創辦人和團隊來說，輕量級的嵌入式函式庫更具吸引力。
VDB 就是一個輕量級解決方案的例子：一個僅包含頭檔的 C 函式庫，實作了核心向量搜尋功能。它以 Apache 2.0 許可證發布，可以直接放入 C 或 C++ 應用程式中，除了用於多線程的可選 pthreads 之外，沒有其他特殊依賴項。
核心功能集涵蓋了大多數早期產品所需的功能。VDB 支援多種相似性度量（餘弦相似度、歐氏相似度、內積），多執行緒搜尋以利用多核心 CPU，基本上持久化功能，以便您可以從磁碟保存和重新載入索引，以及官方 Python 綁定，以便您可以將其整合到典型的 AI 堆疊中。
由於它僅包含頭部訊息，因此整合非常簡單。將頭檔包含在您的專案中，編譯，使用您喜歡的模型（OpenAI、Cohere、Sentence Transformers 等）產生嵌入，將它們連同關聯的 ID 或元資料一起推送到 VDB 中，並在處理請求時查詢前 k 個最近鄰居。
這種設計非常適合本地部署或邊緣部署。如果您正在建立一個類似 LangChain + ChatGPT 的應用，但希望將所有內容保留在自己的防火牆之後，那麼嵌入式程式庫可以避免外部相依性和廠商鎖定。對於雲端延遲不可接受的物聯網或邊緣設備而言，將向量儲存編譯到二進位檔案是一大優勢。
當然，凡事有利有弊：VDB 並非旨在取代完整的企業級資料庫。它依賴精確（窮舉）搜索，而非複雜的神經網路圖或量化技術，因此查詢時間與資料集大小呈線性關係。對於數萬甚至數十萬個向量，這通常是可以接受的，尤其是在多執行緒的情況下；但對於數千萬個向量，除非進行分片或引入自訂索引層，否則很可能會遇到效能瓶頸。
現實世界的混合搜尋：連結向量和元數據
在實踐中，幾乎所有生產用例都將向量相似度與結構化屬性的嚴格過濾結合起來。使用者很少想要「整個語料庫中最相似的事物」；他們想要的是「相似的，但也要遵守這些限制條件」。
設想一個房地產搜尋應用程序，用戶可以在其中描述房屋的感覺。 ——「採光充足的中世紀現代風格」——同時也附加了「三間臥室」、「售價低於 80 萬美元」和「位於 A 區」等硬性限制條件。簡單的向量搜尋很容易返回一棟位於錯誤學區、價值 200 萬美元的華麗中世紀別墅；而普通的 SQL 過濾器則根本無法理解這種風格查詢。
像 AlloyDB for PostgreSQL 這樣的引擎展示瞭如何透過內聯過濾來解決這個問題。AlloyDB 將 Postgres 相容性與 Google 的可擴展基礎架構相結合，整合了 pgvector 作為一流的擴展，並利用基於 ScaNN 的向量索引對其進行增強，以實現快速相似性搜尋。
其內聯過濾功能意味著向量索引和 SQL 元資料過濾器只需一次操作即可套用。AlloyDB 不是先進行向量搜索，然後再過濾掉不匹配的行，而是在遍歷向量索引時檢查數值和類別約束，從而避免浪費工作和延遲懲罰。
最終結果是，一種混合搜尋方式能夠在幾毫秒內返回符合美學偏好和嚴格篩選條件的房屋。這種模式可以推廣到電子商務（款式+價格+庫存）、內容發現（主題+語言+地區），以及任何「氛圍」必須與嚴格的商業規則共存的領域。
從嵌入式系統到生產應用
一旦選定了儲存方法，建構基於向量的特徵的高階流程就相當一致。無論您使用的是 Milvus、Qdrant、PostgreSQL + pgvector、Elasticsearch k-NN 還是像 VDB 這樣的輕量級函式庫。
首先，你需要為語料庫產生詞嵌入。對於文本，可以是文件、知識庫、工單、電子郵件或聊天記錄；對於圖像和多模態數據，則需要使用合適的視覺或多模態模型。每個資料項都會變成一個向量，外加您關心的任何元資料。
接下來，將嵌入向量與標識符和元資料一起儲存在選定的向量儲存庫中。在向量資料庫中，這通常意味著建立一個包含向量和元資料欄位的集合或表；在 VDB 中，它可能是磁碟快照支援的記憶體索引。
在查詢時，將使用者輸入嵌入到相同的模型中，並發出相似性搜尋。資料庫傳回前 k 個最相似的向量，您可以使用它們的 ID 或儲存的有效負載來尋找底層項目（文件、產品、影像）。
對於 RAG，您需要將檢索到的內容作為附加上下文傳遞給 LLM。對於推薦系統，您可以直接使用鄰居作為候選對象進行排名。對於分析或異常檢測，您可以聚合距離和鄰居信息，以了解模式和異常值。
向量資料庫也使得以穩健的方式實現嵌入模型變得更加容易。無需手動處理文件或臨時數組，即可獲得完善的資源管理、擴展調節、安全控制和查詢語言，讓您能夠清晰地表達複雜的相似性+篩選查詢。這些維運的考量包括對生產環境中的LLM和向量進行監控、追蹤和治理，詳情請參見[此處]。 人工智慧可觀測性的層次.
當與生成式人工智慧結合時，該技術堆疊能夠提供個人化的體驗，這些體驗基於您自己的數據，並能隨著您的數據量增長而不斷發展。無論您選擇重量級的分散式資料庫還是輕量級的本地庫，概念部分——嵌入、相似性度量、人工神經網路或精確搜尋以及元資料過濾器——都保持不變，並構成了現代人工智慧應用程式的支柱。
隨著人工智慧系統變得越來越具有對話性、多模態性和對上下文的依賴性，向量資料庫作為語義記憶層的作用只會更加凸顯。理解向量的儲存、索引和比較方式正迅速成為任何使用語言和視覺模型建立嚴肅應用程式的人的核心技能。
