檢索與重排序技術的綜合優勢
結合檢索與重排序技術能顯著提升大語言模型(LLM)的輸出品質。玄貓曾在為金融科技公司開發客服AI時，發現這兩項技術的結合帶來了質的飛躍。這種結合具有以下關鍵優勢：
- LLM可以存取並利用訓練資料以外的相關資訊，提供更準確與符合連貫的背景與環境的回答
- 透過重排序聚焦於最相關資訊，模型回應更加精準，減少錯誤和無關內容
- 檢索功能可從更新的資源中提取最新資訊，使模型回應更加即時
- 這些技術使模型能有效處理特定、詳細的查詢，無需頻繁重新訓練整個模型
舉個實際例子，假設你詢問LLM關於量子運算的最新研究。處理流程如下：
- 檢索：模型在大型科學論文和文章資料函式庫尋相關量子運算檔案
- 重排序：將初步檢索的檔案重新排序，將最新與最相關的研究置於頂部
- 回應生成：LLM利用排名最高的檔案生成關於量子運算最新研究趨勢的詳細準確回應
這種方法讓LLM能提供資訊充分、時效性強與連貫的背景與環境準確的答案，大幅改善使用者經驗。
後期互動策略的實作
當你準備將應用程式推向生產環境時，還有一些策略可以改善使用者經驗並建立反饋迴圈，以便更好地瞭解生成式AI應用的行為。這些策略被稱為後期互動策略，有時也稱為根據BERT的情境化後期互動(ColBERT)。
我們先定義「互動」這個概念。互動指的是評估查詢與檔案之間相關性的過程，透過比較它們的表示來實作。後期處理策略是指查詢與檔案表示之間的互動發生在流程後期，通常是在兩者已被獨立編碼之後。而早期互動模型則是指查詢與檔案嵌入在更早階段互動，通常是在模型編碼之前或期間。
當使用者與生成式AI應用互動時，他們輸入的查詢會被編碼成密集向量表示。潛在的回應（通常是檔案或段落）也被編碼成密集向量表示。系統執行查詢與檔案嵌入之間的相似度比對，回傳相似度得分最高的檔案作為最佳比對。
為了提高相關性，系統不會向使用者回傳所有比對結果，而是提供最相關的結果或結果集的摘要版本。像ColBERT這樣的後期互動模型透過專注於最有希望的查詢-檔案對而非考慮所有可能的配對來提高效率，產生更精確的結果和更好的使用者經驗。
在我為搜尋引擎最佳化專案工作時，發現實作ColBERT或類別似技術能顯著提升檢索效能，為使用者查詢提供更相關的結果。
查詢重寫技術
查詢重寫（或查詢重構）是一種用於提高LLM回答品質的技術。這個過程涉及修改原始查詢，使其更清晰、更具體或更詳細，從而幫助模型生成更好的回應。LLM本身不會在背景中顯式重寫查詢，所以這種工作是手動的，除非你實作了一個工作流程，在處理前評估並重寫使用者的查詢。
重寫查詢可以使其更清晰精確，減少歧義，確保模型準確理解問題。增加相關連貫的背景與環境或細節可以幫助模型提供更準確與符合情境的回答，並可以消除具有多重含義的術語歧義，確保回應符合預期含義。此外，重構查詢以包含額外相關細節可以產生更全面的回答。
查詢重寫如何運作？首先要了解你的生成式AI應用的使用者意圖——你的應用目的是什麼，它將嘗試回答哪些類別的問題？瞭解使用者期望的回應與你的應用可能提供的回應之間的差距至關重要。
例如，根據意圖，使用者查詢可以增加額外的連貫的背景與環境和細節。這大擴充套件了使用者查詢（並增加了每個查詢的令牌計數），但通常會產生更好的結果。
以一個簡單的例子，假設你的應用生成影像。使用者請求一張小貓的圖片，這是一個簡單的查詢，可能有無數結果。
為幫助使用者獲得更好的結果，你可以在UI中增加三個按鈕，讓使用者選擇風格——逼真的照片風格、文藝復興繪畫風格或動漫卡通風格。當使用者點選風格按鈕然後提交查詢時，系統不是直接傳遞「小貓圖片」的請求，而是將查詢修改為：
一張小貓的影像，動漫風格，大眼睛，千秋，Q版風格，畫素風格，動漫插圖，可愛，鳥山明風格。
這裡，對於每個按鈕風格，你可以增加擴充使用者查詢的術語，並在提交前應用它們。
再舉個例子，考慮這個使用者查詢： “平均收入是多少？”
一個有意義的重寫可能是： “[2024年5月] [銷售SKU 123] 的平均收入是多少？”
這個重寫的查詢增加了額外連貫的背景與環境，幫助系統瞭解使用者是在詢問特定產品和時間段，從而產生更準確與有用的回應。
在進行查詢重寫時，簡化語言也很重要。複雜的查詢可以簡化或分解為更簡單的部分，使模型更容易處理並準確回應。這種方法涉及將一個大型查詢分解為組成部分（通常透過一系列輸入欄位/表單實作），然後將每個資料輸入統一為單一提交查詢。這引導使用者構建格式良好的查詢，無需專業知識。
例如，假設使用者只有一個輸入欄位來輸入查詢。在這種情況下，他們可能會遺漏相關訊息或提供無關訊息，這可能影響準確性或增加幻覺的可能性。相反，如果提供一系列欄位，每個都有明確指示，然後將輸入的訊息組裝成提供給生成式AI應用的查詢，會比自由形式的文字輸入獲得更好的結果。
在實際實作中，你可以考慮一個工作流程，系統本身分析查詢的意圖和連貫的背景與環境，審查詢的複雜性，然後重寫查詢使其更清晰、更具體或更詳細。重構的查詢可用於生成回應。
測試與紅隊評估
測試AI系統對確保其準確性、可靠性和整體效能至關重要。在軟體工程中，自動化測試通常是軟體開發過程的一部分。生成式AI應用也不例外。你需要定期測試輸出，確保輸出品質沒有劇烈變化。
測試策略
就像典型的軟體工程功能一樣，你需要在測試計劃中包含單元測試、整合測試、效能測試和使用者接受性測試階段。然而，具體實施方式因使用案例而異。
在生成式AI應用的背景下，單元測試仍然具有相同的基本原則，涉及測試應用程式的各個元件或模組，確保它們正常運作。然而，對於生成式AI應用，單元測試還需要包括以下步驟：
- 輸入驗證：確保應用程式正確處理和驗證各種輸入類別、格式和範圍。測試邊緣情況，如空輸入、過大輸入或格式錯誤的資料
- 預處理：驗證任何預處理步驟，如標記化、正規化或特徵提取，是否正確執行
- 模型載入：測試模型是否從儲存位置正確載入，並驗證是否使用了正確的版本
- 模型推論：確保模型在給定有效輸入時生成無錯誤的輸出。使用控制輸入測試推論功能，驗證預期行為，如某些提示或情境的確定性回應
- 輸出格式：驗證生成的輸出是否符合預期的格式和結構。這包括檢查輸出是否完整、格式正確，並符合任何長度或內容限制
- 後處理：測試任何修改或增強模型輸出的後處理步驟，如清理文字、轉換格式或應用額外業務邏輯
- 功能性：輸出應該能正常運作。如果你的生成式AI應用輸出程式碼，你需要測試該程式碼本身是否能編譯並按預期運作
整合測試專注於驗證生成式AI系統的元件能否按需協同工作。這意味著你將測試元件之間的互動，檢查以下內容：
- 資料擷取管道是否提取正確的資料
- 建議如何呈現給使用者（例如格式化，如果這是由另一個函式庫具完成的）
- API負載測試，如果你使用其他LLM如OpenAI或Anthropic
透過效能測試評估處理時間、效率和可擴充套件性。這可能包括以下活動：
- 測試應用程式如何處理大量同時查詢的負載情況
- 評估自託管模型在各種硬體設定上的推論時間
- 測量應設定的輸入和輸出令牌限制，以控制成本和處理時間
- 測量模型生成輸出所需的時間，確保符合效能要求。這對具有實時限制的應用程式尤為重要
除了常規測試外，建議生成式AI應用還應進行以下額外測試：
- 偏見與公平性：如果你的模型做出影響生活和生計的建議，你需要仔細考慮對不同人口群體的訓練資料偏見
- 強健性：為確保生成式AI應用對變化和噪聲具有彈性，你需要使用對抗性例子和邊緣情況進行測試，評估其處理意外輸入的能力
紅隊評估
如果你的生成式AI應用將接受來自人類的自然語言提示和輸入，那麼紅隊評估實踐是非常推薦的。紅隊評估涉及模擬真實世界、具挑戰性或對抗性的情境，以識別生成式AI應用中的漏洞和弱點。這種方法借鑑自網路安全實踐，對確保生成式AI應用滿足使用者期望特別重要。
這涉及擁有一大群使用者，他們會提出真實世界的問題，但不受指令碼限制，可以問任何問題。紅隊評估的原因是生成式AI應用可能與經常會產生不同的輸出，即使輸入類別似或相同，這些輸出也可能差異很大。不僅如此，生成輸出的品質通常是主觀的，取決於人類判斷。因此，傳統軟體應用產生可預測與一致的結果，但生成式AI並非如此。
以聊天機器人應用為例，常規自動化測試可能會讓生成式AI應用回答200個最常見的使用者問題，然後評估正確性。而使用紅隊，你會讓50名使用者提出他們想問的任何問題，然後記錄所提問的問題和回應。這可能會產生以下洞見：
- 如果使用者以類別似但非完全相同的措辭提問，他們會收到不正確或較不正確的回答
- 一些使用者會提出惡意問題，生成式AI應用的回應不佳
- 其他使用者提出不屬於訓練資料的問題，生成式AI應用會產生幻覺答案（或根本不回答），從而識別擴充套件訓練資料的需求
- 當使用者連續提出許多問題時，應用會停滯
- 當使用者提出特定類別的問題時，他們對輸出不滿意，因為應用缺乏高品質的訓練資料或回覆格式不理想
- 在適當提示下，生成式AI應用會分享其他使用者工作階段的細節，從而識別安全問題
在玄貓參與的一個對話機器人專案中，紅隊測試幫助我們發現了系統在處理多輪
生成式AI應用的全方位最佳化
在AI領域工作多年，我深知生成式AI（GenAI）應用雖然強大，但若缺乏適當的最佳化和校正機制，就像是一把雙面刃，可能帶來意想不到的後果。當我為一家金融科技公司實作AI客服系統時，曾親眼見證一個未經充分測試的模型，如何在真實環境中產生誤導性回應，最終導致客戶投訴增加而非減少。
這個經驗讓我明白，開發可靠的生成式AI應用不僅需要優秀的基礎模型，更需要全方位的最佳化策略。本文將分享我在多年實踐中總結的關鍵最佳化方法，幫助你建立更準確、更可靠的GenAI系統。
紅隊測試：在實戰前的關鍵防線
紅隊測試（Red Teaming）是一項在AI系統正式上線前至關重要的安全措施。這種測試方法源自資安領域，目的是模擬可能的攻擊者，找出系統的弱點和漏洞。
要進行有效的紅隊測試，我建議記錄每位使用者提出的所有問題及系統的回應，然後請測試人員評分並提供意見。雖然這種詳細的使用者測試在軟體開發中並不常見與相當費力，但它能讓你在正式環境佈署前，瞭解應用在真實情境中與真實人類互動時的表現，這種價值無可替代。
在我主導的一個醫療AI專案中，我們組織了一支由醫療專業人員、資安工作者和一般使用者組成的紅隊。透過他們的測試，我們發現了多個可能導致錯誤醫療建議的場景，這些問題在開發環境中完全沒有被察覺。這次經驗讓我深刻認識到多角度測試的重要性。
由於AI系統的規模和範圍，完整測試每個元件往往是不可能的。有效的測試和紅隊工作依賴於判斷系統中哪些部分風險最高。雖然偶爾提供不太準確的建議可能影響不大，但單一幻覺（hallucination）可能造成的潛在傷害卻相當高。你需要考慮傷害的嚴重程度、不準確的可能性，以及撤回或糾正不準確資訊的能力作為風險評估標準。
建議參考 AI Incident Database 瞭解已報告的AI事件案例。例如，該資料函式庫了一個涉及人力設定推薦的應用程式事件，其演算法建議導致設施人力不足，進而引發疏忽、傷害甚至死亡的嚴重事件，最終促使對使用AI的醫療提供者提起訴訟，甚至立法規範。
資訊後處理：提升輸出品質的關鍵環節
GenAI與以往往的AI或分析工具的主要區別在於它能高效生成新內容，而這些內容通常以非結構化形式呈現，如文字或影像。當你看到格式精美的輸出，如專案符號、多種字型等，這實際上是一種資訊後處理的結果。
資訊後處理指的是AI模型生成初始回應後，但在將回應傳送給使用者前所採取的一系列步驟。這個關鍵環節能增強GenAI模型的輸出，精煉原始回應，使其更有用、更準確，並更符合情境。
以下是幾種最實用的後處理方式：
事實檢查
驗證提供資訊的準確性，可能涉及對照可靠來源或資料函式庫事實。在實作一個法律AI助手時，我發現未經事實檢查的輸出偶爾會參照不存在的法規或誤解現有法律。我們建立了一個專門的事實檢查模組，將生成的內容與最新法規資料函式庫比對，大幅提升了系統可靠性。
格式化處理
將資訊結構化為清晰可讀的格式，如專案符號、段落或表格。這也可能包括樣式變更，如粗體、文字顏色或字型，以提高可讀性和強調重點。
語法、風格和語氣檢查
有時，GenAI應用程式提供的文字品質不符合預期，或與人類書寫的精確訊息、語氣和風格不一致。後處理工具和供應商可以處理生成的文字輸出，顯著提高其可讀性，使其符合讀者期望。
資訊後處理是GenAI輸出生命週期中的重要組成部分。它彌補了原始模型輸出與精緻、使用者就緒回應之間的差距，提高準確性、可讀性、相關性和整體使用者滿意度。透過實施有效的後處理策略，AI系統能夠提供更高品質、更可靠的結果。
隨著GenAI的普及，已經有許多專門提供這類別服務的公司出現，開發者不必從頭構建這些功能。在一個企業內容生成專案中，我們使用了專業的後處理服務，將原始AI輸出轉化為符合企業風格的內容，效果遠超我們自行開發的解決方案。
其他技術最佳化策略
除了上述方法外，還有一些更容易實施的技術最佳化方案。這些方法可能會提高GenAI應用的準確性和效能，雖然所需的工作量各不相同。
例如，在MongoDB對GPT進行測試時發現，相同問題集的準確率從GPT-3.5到GPT-4提升了7%。透過提示工程（prompting）、檢索增強（retrieval augmentation）或後期互動策略獲得如此程度的準確性提升當然是可能的，但會相當困難。
因此，值得探索每一個潛在的改進途徑，包括硬體升級、程式碼最佳化、並發管理、資料函式庫最佳化，甚至只是升級軟體。所有這些都能改善GenAI應用的結果，應該獨立研究：
硬體和軟體升級
升級計算資源，例如使用更強大的GPU、水平擴充套件更多伺服器，或更新至最新版本的軟體，對準確性和效能都有顯著影響。
在處理一個大規模影像生成AI系統時，我發現僅將GPU升級到最新一代，就使推論速度提高了近40%，同時還略微提升了輸出品質。這種投資回報率在AI領域是難得的高效改進。
程式碼最佳化
重構和最佳化程式碼以提高效率、減少計算負載並更有效地處理資料。我經常看到的一個常見問題是，開發者未能有效批處理AI請求，導致資源浪費和不必要的API呼叫延遲。
網路最佳化
透過最佳化資料傳輸、快取回應和最小化API呼叫開銷來減少網路延遲。在分散式AI系統中，網路延遲往往成為最大瓶頸，特別是當系統需要多次往往返呼叫時。
並發管理
實作並發和平行處理技術以高效處理多個請求。特別是對於需要服務大量使用者的應用，合理的並發策略可以在不增加硬體成本的情況下顯著提高系統吞吐量。
資料函式庫化資料函式庫和互動以減少I/O開銷。在我參與的一個RAG（檢索增強生成）專案中，簡單的資料函式庫最佳化將查詢時間從平均700毫秒降低到不到50毫秒，大幅提升了整體使用者經驗。
生成式AI應用的全面最佳化方法
最佳化生成式AI的方法多種多樣，可以在生成答案之前、期間和之後實施。為了獲得最佳效能，你需要用高品質資料訓練GenAI模型，用特定使用案例資料補充現有模型，並有徹底的評估資料集，記錄模型的效能以建立準確性基準。
一旦你有了這個基準，就可以立即開始使用本文討論的技術進行改進。以下是一些我在實踐中發現特別有效的方法：
少樣本提示（Few-shot Prompting）
少樣本提示涉及向GenAI模型提供一個或幾個範例或提示，引導其回應，使模型能夠生成相關與符合情境的輸出，而只需最少的訓練資料。
在一個客戶支援AI專案中，我發現將3-5個高品質的問答對作為提示範例，可以將模型的回答準確率提高達25%。關鍵在於選擇真正代表性的範例，並確保這些範例涵蓋不同的情境和語言風格。
檢索與重排序
根據使用者查詢檢索並重新排序相關檔案或資料點，然後重新排序這些結果，優先考慮最相關和最有用的資訊，再生成最終回應。
我在建構企業知識函式庫時發現，檢索階段的品質直接決定了最終回應的準確性。投資於更好的向量相似度演算法和更精確的嵌入模型，往往比調整生成模型本身更有效。
查詢重寫
改進查詢的清晰度、具體性或情境，幫助AI模型更準確地理解和回應使用者的請求。
當面對模糊或多義的查詢時，查詢重寫可以顯著提高結果相關性。我們曾經為一個技術支援系統開發了一個專門的查詢理解模組，它能夠識別使用者真正的意圖，即使表達不清，也能將其轉化為明確的技術查詢。
格式化GenAI回應
透過清晰、有組織與可讀的方式結構化和呈現AI生成的內容，可以提升整體使用者經驗並確保資訊易於理解。
不要低估格式的力量。在一個財務報告AI系統中，僅透過改進數字的呈現格式和增加適當的視覺分隔，使用者滿意度就提高了30%，即使底層資訊完全相同。
實施後期互動策略
實施如ColBERT等後期互動策略可以提高所檢索資訊的相關性和準確性。這些技術在檢索過程的較後階段引入更複雜的相關性判斷，能夠捕捉更細微的語義關係。
持續測試與記錄
透過測試、紅隊測試和記錄結果，你可以追蹤隨時間改進效能、安全性和回應品質的進展。建立一個持續評估框架，定期檢查系統表現，是確保長期穩定性的關鍵。
GenAI技術正在（並將繼續）改變軟體產業的面貌。有了這些最佳化策略，你的GenAI應用將能夠在不斷發展的環境中適應並脫穎而出。
進階學習資源
以下是一些值得探索的資源，可以幫助你進一步深入瞭解生成式AI的各個方面：
生成式AI基礎
- Gryka, Maciej的《Invest in RAG》，探討如何從不可靠的代理構建可靠系統
- Vox Creative製作的《The Black Box: Even AI’s creators don’t understand it》播客，探討AI的黑盒特性
智慧應用的構建模組
- Naveed等人的《A Comprehensive Overview of Large Language Models》，全面概述大語言模型
大語言模型
- 《Speech and Language Processing》，自然語言處理的經典教材
- Hochreiter和Schmidhuber的《Long Short-Term Memory》，介紹LSTM的開創性論文
- Vaswani等人的《Attention Is All You Need》，介紹Transformer架構的重要論文
- 《Prompt Engineering Guide》，提示工程的實用
嵌入模型
- 多種嵌入模型的研究論文，包括詞嵌入、影像嵌入、音訊嵌入和圖嵌入等
向量資料函式庫 Malkov和Yash
118, 134, 136, 140, 151, 153, 155-156, 167 search: 3-4, 7-8, 12-14, 17, 27, 29-30, 32, 36, 38-41, 44-45, 47-51, 57-60, 65, 67-75, 77-89, 92, 94-113, 118-119, 121-128, 132-134, 140-148, 151-152, 155-159, 162-165, 167, 171-173, 175-176, 178-180, 182, 187-188, 191-193, 199-201, 203-205, 210, 219, 221, 223-224, 229, 240, 247-248, 250, 252-254, 257-258, 262 semantic: 2-4, 7-8, 12-14, 17, 27-28, 36, 38-39, 42, 44-45, 47-48, 50-51, 56-58, 65, 68, 70-72, 74, 77-81, 83-85, 87-89, 95-98, 101-102, 110, 112, 119-120, 122-128, 132-133, 140-143, 145-148, 151-152, 156, 158-159, 162-165, 167, 171-172, 179-180, 182, 187-188, 191, 199-205, 208-210, 213, 219-230, 247-248, 250, 253-254, 257, 262 sentence: 7, 38, 41, 44, 49-51, 55-57, 68, 71-73, 77, 82, 121, 142, 145-146, 148, 151, 155, 173, 203, 205, 207-208, 210, 219-220, 222, 224-225, 230, 258 sharded: 76, 88-89, 91, 99-100, 102-103, 108-110, 112-113 similarity: 27, 36, 47, 50, 56-59, 68, 70, 72, 74, 77-78, 80, 83-85, 95, 101-102, 110, 112, 122-123, 125, 142, 147-148, 157, 159, 162-163, 165, 167, 182-183, 187-188, 204, 207, 209, 213, 222-223, 225, 229, 250 simplify: 18, 23, 76, 119, 140, 146, 148, 164, 257-258 sklearn: 58, 133 sparse: 57, 79-81, 83-85, 87, 95, 101-102, 110, 112, 127, 147-148, 162-163, 165, 204, 207, 209, 258 SQL: 3, 105 standardize: 80 storage: 6, 18, 27, 47, 65, 74, 76, 88-89, 91-92, 98-102, 110, 112-113, 117, 133, 135, 175, 246-247 structured: 15, 22, 53-54, 79, 84, 101, 121, 153, 176, 189-192, 220-221, 224-227, 241-243, 254, 258 synchronize: 108 syntactic: 47, 79 T templates: 53, 128, 150, 154, 176, 253 tensor: 27, 35-36, 39, 41-42, 45, 52, 148, 159 TensorFlow: 5, 118-119, 133 tokenize: 28, 37, 39, 56, 82, 145, 148, 220, 226 torch: 5, 118, 144, 210 transform: 13, 16-17, 19, 22, 27-28, 32, 36-39, 41-42, 44-45, 50, 52-57, 60, 68, 70-73, 75, 77, 82, 105, 110, 119, 121, 125, 133, 142, 145-146, 148, 151, 154-155, 173, 179, 182-183, 203, 205-210, 219, 222, 224-226, 230, 236, 239, 258 transformer: 27-28, 32, 36-39, 41-42, 44-45, 50, 52-58, 60, 68, 70-73, 75, 77, 82, 110, 119, 121, 125, 142, 145-146, 148, 151, 154-155, 173, 179, 182-183, 203, 205-210, 219, 222, 224-226, 230, 258 transparent: 203, 259 trend: 5, 11-13, 15, 29, 46, 67, 70, 77, 80, 87, 90, 94, 102, 118, 140, 148, 153, 165, 171, 175, 179, 187, 232, 235, 239, 244, 246, 252, 254, 258 trigger: 108, 243, 255, 259 troubleshoot: 22, 244, 258
U understanding: 2, 7, 21, 27-28, 30, 42, 47-48, 52, 56, 68, 78, 80, 82, 105, 112, 117, 119, 123, 143, 152, 171-172, 175-176, 179, 188, 200-201, 232, 235-236, 245, 248, 250, 253, 255, 257 unicode: 55, 133, 136 V validate: 15, 17, 20, 22-23, 57, 106, 137, 143, 157, 167, 182, 185, 187, 189, 191-193, 199-200, 213, 219, 221, 233, 237, 241, 244, 246-247, 249-250, 252, 256, 260-261 vector: 1-8, 11-23, 27-30, 32, 35-45, 47-75, 77-89, 91-113, 117-128, 131-134, 136-137, 140-148, 150-155, 157-159, 161-167, 171-173, 175-176, 178-180, 182-183, 187-193, 199-205, 207-230, 239-240, 243-244, 247-250, 253-254, 256-258, 261-262 visualization: 15, 22, 57-58, 85, 101, 245, 248, 253 vocabulary: 29, 37, 50, 52-55, 57, 59
Index 274 W webhook: 105, 108, 113, 243, 248 workflow: 5, 12, 15, 21, 23, 55, 58-59, 121, 128, 156, 167, 193, 241, 243, 245-246, 248-249, 251, 256-258, 260, 262
向量資料函式庫深入解析
向量資料函式庫引技術在近年來隨著AI應用的爆發性成長變得極為重要。當我們在處理大規模向量資料時，索引的選擇與設計可能成為系統效能的關鍵因素。透過適當的索引策略，我們能夠顯著提升搜尋效率，並為各種應用場景提供最佳解決方案。
向量索引的基礎概念
向量索引是一種專為高維向量資料設計的特殊資料結構，其目的是加速相似性搜尋操作。與傳統資料函式庫不同，向量索引處理的是多維空間中的相似度計算，而非精確比對。
在建立向量索引時，我們需要考慮幾個關鍵因素：
向量維度與表示方式
向量維度直接影響索引效能與記憶體使用量。當我處理大語言模型產生的嵌入向量時，常見的維度範圍在768至1536之間。高維度向量雖能提供更精確的表示，但也帶來更高的計算成本。
相似度計算方法
不同的應用場景可能需要不同的相似度計算方式：
- 餘弦相似度：適用於方向相似性比較，不考慮向量長度
- 歐氏距離：考慮向量間的絕對距離
- 曼哈頓距離：在某些特定領域應用中更為適合
每種距離計算方法都有其特定的應用場景，選擇合適的方法對於搜尋結果的準確性至關重要。
主流向量索引技術比較
在實際應用中，我經常使用以下幾種索引技術：
1. 分層導航圖 (HNSW)
HNSW (Hierarchical Navigable Small World) 是目前最廣泛採用的向量索引之一，它透過建立多層圖結構實作高效搜尋。
# 使用HNSW索引範例
from pymongo import MongoClient
from bson import json_util
client = MongoClient('mongodb://localhost:27017')
db = client.vector_db
# 建立HNSW索引
db.documents.create_index([
("embedding", "vector")
],
vector_options={
"type": "hnsw",
"dimensions": 768,
"similarity": "cosine"
})
# 向量搜尋查詢
results = db.documents.aggregate([
{
"$vectorSearch": {
"index": "embedding_index",
"path": "embedding",
"queryVector": query_vector,
"numCandidates": 100,
"limit": 10
}
}
])
HNSW索引的主要優勢在於其出色的搜尋效能。在我的實際專案中，對於百萬級別的向量集合，HNSW通常能在幾毫秒內回傳結果。然而，HNSW的索引建立過程較為耗時，與記憶體用量較高。
2. 倒排檔案 (IVF)
IVF (Inverted File Index) 透過將向量空間分割為多個簇，並在搜尋時只檢查最相關的簇，從而加速搜尋過程。
# MongoDB中使用IVF索引設定
db.documents.create_index([
("embedding", "vector")
],
vector_options={
"type": "ivfflat",
"dimensions": 768,
"similarity": "cosine",
"lists": 100 # 簇的數量
})
IVF索引在建立時較快，記憶體用量也較低，但搜尋精確度可能略低於HNSW。在處理較大規模資料集時，IVF通常是一個不錯的選擇，特別是在資源有限的環境中。
3. 產品量化 (PQ)
產品量化是一種降低向量儲存空間的技術，它將高維向量分解為多個低維子向量，並對每個子向量進行獨立編碼。
# 設定包含PQ的索引
db.documents.create_index([
("embedding", "vector")
],
vector_options={
"type": "ivfflat",
"dimensions": 768,
"similarity": "cosine",
"lists": 100,
"compression": {
"type": "pq",
"bits": 8,
"subvectors": 96
}
})
PQ技術能大幅降低記憶體使用量，對於超大規模向量集合尤其有用。在我處理包含上億向量的專案中，PQ壓縮可以將記憶體用量減少高達90%，但代價是搜尋精確度的輕微下降。
索引最佳化策略
在實際應用中，索引最佳化是一個持續的過程。以下是我在實踐中總結的一些最佳化策略：
引數調校
每種索引類別都有其特定引數需要調整：
- HNSW:
M(每層的連線數)和efConstruction(建立時的搜尋深度)是關鍵引數 - IVF:
lists(簇的數量)通常設定為資料量的平方根附近 - PQ:
subvectors(子向量數)和bits(每個子向量的位數)需要平衡壓縮率和精確度
混合索引策略
在某些情況下，組合多種索引技術可以獲得更好的效果：
# 使用IVF+PQ混合索引
db.documents.create_index([
("embedding", "vector"),
("category", 1) # 傳統B-tree索引
],
vector_options={
"type": "ivfflat",
"dimensions": 768,
"similarity": "cosine",
"lists": 100,
"compression": {
"type": "pq",
"bits": 8,
"subvectors": 96
}
})
在我開發的一個產品推薦系統中，透過結合向量索引和傳統索引，我們能夠同時考慮產品特徵相似度和類別過濾，顯著提升了推薦的相關性。
分片與擴充套件
對於大規模向量集合，分片是提高效能的重要策略：
// 為向量集合建立分片
db.adminCommand({
shardCollection: "vector_db.documents",
key: { "_id": "hashed" }
})
在分散式環境中，選擇合適的分片鍵至關重要。我通常偏好使用雜湊分片以確保資料均勻分佈。
實際應用案例
語意搜尋系統
在開發一個檔案語意搜尋系統時，我採用了以下索引策略：
# 為檔案嵌入向量建立HNSW索引
db.documents.create_index([
("embedding", "vector")
],
vector_options={
"type": "hnsw",
"dimensions": 1536, # OpenAI ada-002模型嵌入維度
"similarity": "cosine",
"m": 16,
"efConstruction": 128
})
這個索引能夠支援每秒數百次的向量查詢，即使在數百萬檔案的集合中也能保持毫秒級回應時間。
多模態搜尋
對於包含文字、影像等多種模態的搜尋系統，我使用了多個專門索引：
# 文字嵌入索引
db.multimodal.create_index([
("text_embedding", "vector")
],
vector_options={
"type": "hnsw",
"dimensions": 768,
"similarity": "cosine"
})
# 影像嵌入索引
db.multimodal.create_index([
("image_embedding", "vector")
],
vector_options={
"type": "hnsw",
"dimensions": 512,
"similarity": "cosine"
})
在查詢時，我們可以根據搜尋類別選擇合適的索引，或者結合兩種索引的結果以實作跨模態搜尋。
效能監控與最佳化
持續監控索引效能對於維持系統穩定執行至關重要。我通常關注以下幾個指標：
- 查詢延遲：平均和95%百分位數回應時間
- 索引大小：記憶體用量和硬碟空間
- 召回率：搜尋結果的準確性
// 監控索引統計資訊
db.documents.stats().indexSizes
當發現效能下降時，可以考慮重建索引或調整引數：
// 重建向量索引
db.runCommand({
dropIndexes: "documents",
index: "embedding_1"
})
// 重新建立最佳化後的索引
// ...
在向量資料函式庫用過程中，索引選擇和最佳化是一個持續演進的過程。隨著資料量的增長和查詢模式的變化，我們需要不斷調整索引策略以維持最佳效能。透過深入理解不同索引技術的特性和適用場景，我們能夠為各種向量搜尋應用構建高效、可擴充套件的解決方案。
在實際應用中，向量索引技術的選擇不僅關乎技術效能，還需要考慮業務需求、資源限制以及未來擴充套件性。透過精心設計的索引策略，我們能夠在保持高效能的同時，為使用者提供精確、相關的搜尋結果。
