盡管人工智能正在獲得所有的關注，一些引人注目的問題再次提醒我們 “garbage in, garbage out”。如果我們忽略底層的數據管理原則，那么輸出就不可信。一旦我們能夠保證基礎訓練數據的準確性，人工智能的采用率將會大大提高。

然而，未來必須與現實相抗衡！如今，大多數業務數據都位于企業數據源內部，而不在公共領域的互聯網上。如果我們在這個企業級的數據系統上利用大語言模型 ，就會出現新的不確定性。

但是，如何利用LLM對企業私有數據的實現強大功能呢？

這里試圖探討技術人員應該如何發展他們的數據策略，并選擇一個數據基礎設施來利用LLM和企業數據。

1. 重啟數據策略

組織必須做出一個基本決定ーー是否創建自己的 LLM、用私有數據調優LLM 或利用通用 LLM 的 API。

1.1 訓練自定義的 LLM

為特定的任務啟用特定的模型構建，例如分類 Slack 消息以識別 PII。這種方法需要在組織中具備深厚的 AI 技能，并且更適合具有大型且復雜IT 團隊的組織，另外訓練像 gpt-4 這樣的 LLM 還需要大量的基礎設施。

目前，生成式人工智能領域對于支持這個選項來說還為時過早。然而，隨著許多服務提供商將來開發特定于領域的 llm，這個領域可能是最令人興奮的領域。

1.2 調優通用 LLM的權重

此選項使用模型權重對特定訓練集上的現有模型進行微調。它還需要對人工智能有深入的了解，并且需要對基礎設施資源進行投資，這取決于數據的大小。此外，它還創建了一個新的職責崗位，稱為 LLMOps。

和前一個選項一樣，這個方式在在成熟度曲線上也較早。LoRA可以幫助微調，期望看到在這個領域的快速發展。

1.3 通用LLM的提示工程

此選項使用模型輸入，將上下文插入到通過 api 發送給 LLM 的輸入消息中。對于具有一般 IT 技能和資源的組織來說，這個選項通常是利用生成性 AI 空間的初步嘗試。

這種方式稱為提示工程，已經出現為人工智能模型開發準確和相關的文本提示詞工具。利用外部內容來增強 LLM 的過程稱為檢索增強生成 (RAG)。

下表顯示了權衡情況：

因為大多數組織不具備訓練或調優 LLM 所需的技能。這種方法涉及向量化數據和創建嵌入，需要編程能力。雖然提示工程也消耗資源，但是比前兩個選項消耗的資源少得多。它最大的好處是允許將上下文數據實時提供給 LLM。

2. LLM 的數據持久化策略

在構建大語言模型應用時，數據策略的第二步是確定如何高效支撐AI工作負載的技術架構。這一階段的核心挑戰在于權衡技術選型：是否需要引入全新的技術體系，還是能夠基于現有基礎設施進行適配性改造？這不僅關系到系統開發成本，更直接影響到模型性能的可持續性。

在實際部署中，數據持久化與管理能力構成了LLM應用的基石。這包括對模型輸入數據的全生命周期管理、向量嵌入的高效存儲與檢索機制，以及對查詢模式的深度優化。特別是在提示工程（Prompt Engineering）領域，開發者面臨兩種關鍵策略選擇：

第一種策略是將API服務作為LLM的"短期記憶"模塊，通過臨時緩存和即時調用的方式處理模型輸入數據。這種方案的優勢在于實現成本低、響應速度快，特別適合對實時性要求較高但數據量相對有限的場景。

第二種策略則是構建"長期記憶"體系，通過持久化存儲技術對模型輸入數據進行結構化保存。這種方案能夠建立完整的數據資產庫，支持復雜的數據檢索、歷史回溯和知識演化，尤其適用于需要深度語義理解和跨會話上下文關聯的場景。在具體實施時，開發者需要根據業務需求在存儲效率、查詢性能和數據一致性之間找到最佳平衡點。

這兩種策略并非完全對立，而是可以結合使用。例如，在實時交互場景中采用API緩存處理即時請求，同時將關鍵數據同步至持久化存儲系統，從而構建兼具時效性與完整性的數據管理體系。這種混合架構能夠最大化發揮LLM的能力，同時確保系統的可擴展性和穩定性。

下圖顯示了兩個備選方案的例子：

短期記憶是短暫的，而長期記憶是持久化的。

2.1 短期記憶：集成內置嵌入和向量化的庫

提到的諸如FAISS等庫均為開源項目，并已被眾多產品廣泛應用。這些工具為開發者提供了強大的功能，但同時也要求開發團隊自行負責構建數據處理流水線以實現最終的交付目標。這意味著從數據預處理、向量化到相似性搜索的每一個環節都需要精心設計與實現。

相比之下，Google的Matching Engine（匹配引擎）提供了一個完全托管的解決方案，專為優化模型輸入而設計，并且支持數據的持久化存儲。使用Matching Engine，開發者可以無需關注底層基礎設施的搭建和維護，直接通過API調用即可快速部署高效率的向量搜索服務。這種全托管的方式不僅簡化了開發流程，還確保了系統的可擴展性和穩定性，特別適合希望減少運維負擔并加速產品上市的企業或團隊。 

因此，在選擇技術方案時，如果需要靈活性和對技術棧的深度控制，可以選擇如FAISS這樣的開源庫；若追求高效部署、易于管理及自動擴展能力，則Google Matching Engine將是更為理想的選擇。兩者各有優勢，具體選用哪一種取決于項目的具體需求、團隊的技術能力和資源情況。

2.2 長期記憶

隨著人工智能和機器學習應用的不斷深入，向量數據的高效處理變得日益重要。為此，原生向量數據庫應運而生——這些是專門為高效存儲、索引和檢索高維向量而設計的專用系統，例如 FAISS、Pinecone 和 Milvus 等。

與此同時，傳統的關系型與非關系型數據庫管理系統（DBMS）也在迅速跟進，逐步集成對向量數據的支持。像 Elasticsearch 這類以搜索為核心的數據平臺，原本就具備強大的倒排索引能力，用于關鍵詞搜索和日志分析，如今也開始引入高效的向量相似性搜索功能，標志著其在語義搜索領域的進一步拓展。

此外，一些現代數據庫如 SingleStoreDB 及其他主流系統，也已經具備了內建的向量嵌入支持，能夠實現本地化的語義搜索功能。盡管在過去，這類功能并未被廣泛宣傳或重點使用，但隨著大模型和AI驅動的應用興起，它們正重新受到關注并被深度整合到新一代智能系統中。

當然，向量數據并非必須依賴數據庫來存儲。事實上，文件系統也是一種可行的選項，特別是那些支持列式存儲格式的文件格式，如 Apache Parquet 或 Apache Arrow。這些格式非常適合批量處理和大規模數據分析，同時也能夠有效地存儲向量數據。

然而，一個不可忽視的問題是：如果缺乏合適的索引機制，在文件中進行向量查詢可能會非常緩慢。因為順序掃描無法高效地處理高維空間中的相似性匹配，這使得構建高效的索引結構成為向量數據管理中不可或缺的一環。

下面的圖顯示了長期記憶的例子，雖然這個列表只是代表性的，因為大多數數據庫供應商正在增加對向量的支持：

現代數據堆棧已經爆滿 要求簡化的呼聲已經高漲。因此，重新啟動數據策略必須支持降低復雜性。這意味著探討目前部署的數據和分析技術是否以及如何能夠用于對私有數據進行向量搜索。

3.在私有數據上使用LLM 的價值鏈

通過部署聊天機器人來實現企業數據的自然語言搜索，可以大幅擴展數據訪問的用戶群體和應用場景。除了基礎的搜索功能外，大型語言模型（LLMs）利用深度神經網絡算法還能執行復雜的任務，如文檔摘要、內容排名及個性化推薦等。

舉例來說，當您在某零售商網站上查找特定商品卻無果時，借助LLM的附加API調用，即便初次查詢未返回結果，系統也能基于相似性或語義搜索技術提供一系列相關產品推薦。這種向量搜索方法能夠識別出與您的查詢意圖最接近的商品集合，從而提升用戶體驗。

目前，諸如ChatGPT這樣的應用依賴于GPT-3乃至更新的GPT-4模型，它們基于2021年9月前的公開數據進行訓練。這意味著對于像2022年底結束的世界杯足球賽這類較新的事件，LLM可能無法提供準確信息。此外，訓練這些先進的LLM需要龐大的計算資源，例如ChatGPT就需要大約10,000個GPU的工作量，這使得訓練過程既昂貴又耗時。

為了克服這一限制并利用最新數據，可以在對GPT-3或GPT-4的API請求中加入額外的信息，比如關于世界杯足球賽的維基百科頁面作為“提示”或“模型輸入”。然而，需注意的是，GPT-3的最大輸入長度為4000個token（約等于5頁文本），而GPT-4則支持高達32000個token（大約40頁）。這里的token可以是單詞、短語、代碼片段或是任何其他形式的模型輸入。

轉向商業需求，特別是那些涉及探索企業數據以發現新洞察的情況，我們可以通過市場營銷實例來說明如何提高客戶轉化率。理想的應用程序應能實時分析所有流入的數據，運用模型生成個性化的優惠，并在用戶使用應用程序的同時即時實施這些優惠。這通常涉及到從交易數據庫提取數據，通過批處理操作完成數據抽取、加載與轉換，接著在OLAP引擎中運行分析，最后創建細分市場并制定報價策略。

而在新一代AI驅動的模型中，您可以直接實時攝取數據，經由一個或多個GPT服務應用模型，并立即根據用戶在線行為做出響應。這些GPT模型特別適用于實時數據處理場景，如推薦系統、分類和個人化定制服務。近年來的技術進步，包括LangChain和AutoGPT的發展，正在革新現代應用程序的開發與交付方式。

要達成上述目標，以下是三個關鍵步驟。

3.1 為向量搜索準備數據

在深入探討向量搜索的機制之前，我們先來理解“向量”究竟是什么。傳統數據庫中的關鍵詞搜索依賴于精確匹配，但在自然語言查詢場景中，這種匹配方式往往無法捕捉語義層面的相似性。當用戶輸入一個自然語言問題時，系統需要將該句子轉換為一種結構化表示形式，以便與其他文本進行比較——這一過程的核心就是“嵌入（Embedding）”。

什么是嵌入？

嵌入是一種將文本、圖像或其他非結構化數據映射為數值向量的技術。這些向量以高維空間中的坐標點形式存在，就像數組一樣，每個維度代表某種語義特征。例如，“king” 和 “man” 在語義上比 “woman” 更接近，因此它們在向量空間中的距離也會更近。

如果沒有這些嵌入向量，大型語言模型（LLM）就無法準確提取提示（prompt）的上下文信息，也就無法生成語義連貫的響應。

語義距離與相似性計算

當對新文本執行搜索時，模型會計算詞匯之間的“語義距離”。這個距離是通過一些數學函數來衡量的，常見的包括：

• 余弦相似度（Cosine Similarity）
• 點積（Dot Product）
• 歐幾里得距離（Euclidean Distance）

這些方法幫助模型識別出與輸入最相關的候選結果，即所謂的“最近鄰（Nearest Neighbor）”。

然而，在面對數百萬甚至數十億個向量時，逐個計算距離顯然效率極低。為此，我們需要使用近似最近鄰（Approximate Nearest Neighbor, ANN）算法來大幅縮小搜索空間并提升性能。

高效向量搜索的關鍵：ANN 與 HNSW

目前最流行的向量索引技術之一是 HNSW（Hierarchical Navigable Small World）圖算法。它通過構建多層導航結構，使得在大規模向量集合中可以快速定位最近鄰。許多主流的向量數據庫（如 FAISS、Milvus）都集成了 HNSW 來加速搜索過程。

為了支持生成式 AI 工作負載，現代數據庫必須具備以下能力：

1. 將原始數據轉換為嵌入向量；
2. 持久化存儲這些向量；
3. 構建高效的索引結構以實現快速檢索。

以下是準備和處理用于向量搜索的數據的標準步驟：

1. 數據攝入（Ingestion）

• 使用標準的數據導入工具將數據加載到數據庫中。
• 對于關系型數據庫（RDBMS），通常意味著將數據寫入表中。
• 支持批量導入或實時流式處理，確保能夠處理最新數據。
• 目標字段可以是數組、JSON 或其他適合存儲向量的格式。

2. 數據協調（Curation）

• 執行輕量級的數據清洗和標準化操作。
• 統一文本格式、處理缺失值或異常內容。
• 可在此階段對數據進行豐富（Enrichment），例如添加標簽或分類信息。
• 輸出通常是一個結構化的列表或文檔。

3. 數據編碼（Encoding）

• 將結構化數據轉化為嵌入向量。
• 可使用外部服務 API，如 OpenAI 的 text-embedding-ada-002 模型，或開源的 Sentence Transformers 等預訓練模型。
• 圖像、音頻等非結構化數據也可通過相應模型轉換為向量。

4. 加載嵌入向量（Vector Ingestion）

• 將生成的向量存儲到數據庫中。
• 通常做法是在原表基礎上擴展一個新的列，類型為 vector、JSON 或 BLOB，用于保存向量數據。
• 這些向量應與原始記錄保持一一對應。

5. 性能調優（Performance Optimization）

為了加快搜索速度，可以采用多種優化策略：

• 壓縮向量數據：例如使用 PQ（Product Quantization）減少內存占用。
• 利用 SIMD 指令：實現并行化向量掃描，提升計算效率。
• 構建 HNSW 索引：加速大規模向量的近似最近鄰搜索。
• 使用專用函數：如 SingleStoreDB 提供的 JSON_ARRAY_PACK 函數可將 JSON 數組高效轉為向量。

完成上述流程后，您的系統就具備了支持語義搜索的能力。從自然語言查詢到語義嵌入，再到高效檢索，整個過程依賴于向量的生成、存儲與索引機制。借助現代向量數據庫和嵌入模型的強大功能，企業可以以前所未有的方式探索其內部數據的價值，推動智能應用的快速發展。

3.2 執行向量搜索

當系統完成數據的嵌入與索引構建后，操作便轉移到前端——即用戶通過如 ChatGPT 這樣的聊天機器人進行交互的環節。此時，用戶以自然語言形式提出問題或輸入提示（prompt），而第一步就是將這些文本內容轉換為向量表示。

這一轉換通常通過調用大型語言模型（LLM）來實現，例如 OpenAI 的 GPT-3 或其他預訓練嵌入模型。該過程將用戶的自然語言查詢映射到高維語義空間中的一個向量點，從而可以與其他已索引的向量進行相似性比較。

接下來，系統會首先在企業內部的數據中執行向量搜索，尋找最相關的匹配結果。隨后，系統可以將這些匹配項作為附加上下文信息，再次輸入到 LLM 中，以生成更準確、更具上下文相關性的回答。

正如前文所述，LLM 的輸入長度是有限制的。例如，GPT-4 雖然支持最多約 32,000 個 token（相當于 40 頁左右的文本），但其訪問權限尚未完全開放。因此，如何高效利用這有限的“上下文窗口”，成為提升模型輸出質量的關鍵因素之一。

在這種情況下，使用企業數據庫進行向量搜索就顯得尤為重要：它能夠在將請求發送給 LLM 之前，快速篩選出最相關的信息，從而大幅減少需要傳遞給模型的數據量，同時確保上下文的質量和相關性。

此外，如果使用的數據庫既支持傳統關鍵字搜索，又具備向量搜索能力，還可以實現兩者的融合查詢。也就是說，在執行 SQL 查詢時，既可以基于結構化字段進行 JOIN 和過濾，也可以結合向量相似性搜索來增強語義理解能力。這種混合搜索方式不僅提升了查詢的靈活性，也為構建智能化應用提供了更強的數據支撐。

簡而言之，向量搜索不僅是連接用戶自然語言輸入與企業數據之間的橋梁，更是優化 LLM 使用效率、降低成本并提升響應質量的關鍵一環。借助現代數據庫的多模態查詢能力，開發者可以在傳統結構化查詢的基礎上，無縫集成語義搜索功能，從而打造更加智能、高效的 AI 應用體驗。

3.3 利用 LLM 生成智能響應

在完成數據庫、數據倉庫或湖倉（Lakehouse）中的向量搜索并獲取相關匹配結果后，下一步是將這些信息輸入到大型語言模型（LLM）中，以執行更高級的語義任務，例如個性化推薦、內容摘要或上下文增強。

具體來說，系統會將從數據庫中檢索出的相關數據（即“匹配結果”）連同用戶查詢一起，發送至 LLM 的 API 接口。LLM 將基于這些信息進行理解和推理，最終生成自然語言形式的響應，提供更具洞察力和個性化的輸出。

然而，在早期階段，隨著 ChatGPT 等工具的興起，許多企業和機構出于對數據隱私的擔憂，限制了其使用。這是因為 OpenAI 在最初的數據政策中明確表示，可能會利用用戶的輸入內容來訓練和優化其模型。

值得指出的是，OpenAI 在 2023 年 3 月更新了其數據使用政策。根據最新規定，用戶輸入不再被用于模型訓練。盡管系統仍會在服務器上保留提示信息最多 30 天，但這主要是為了滿足合規與法律審查需求。30 天后，相關數據將被自動刪除，從而顯著提升了用戶數據的隱私保護水平。

因此，如今越來越多的企業開始放心地將 LLM 集成到其業務流程中，借助其強大的語義理解與生成能力提升應用智能化水平。

一旦處理完成，LLM 將返回結構化或自然語言形式的響應，供前端應用展示給用戶或觸發后續的自動化流程。這一過程不僅實現了從原始數據到智能輸出的閉環，也為構建下一代 AI 驅動型應用提供了堅實基礎。

4.小結

生成式人工智能仍處于快速發展階段，展現出巨大潛力。本文聚焦于實現語義搜索，特別是支撐這一生態系統、尤其是組織在利用大型語言模型處理專有數據時所需的數據庫能力。盡管技術不斷演進，企業在推進AI成熟過程中不應忽視數據管理的最佳實踐。

在企業AI應用集成的過程中， MCP 的作用顯著，如果希望快速入門MCP，可以閱讀筆者的《MCP極簡入門》。