Python 工程師的秘密武器：LLM與向量資料函式庫

人工智慧浪潮下的Python應用開發新紀元

人工智慧正以前所未有的速度改變著我們的世界。從語音助理能理解我們提出的各種問題，到自駕車能夠安全地在道路上行駛，這些看似魔法般的技術背後，其實是有著堅實科學基礎的機器學習和人工智慧技術。

AI應用開發的爆炸性成長

根據2023年Stack Overflow的調查，44%的開發者已經在使用AI工具，而83%的開發者使用過ChatGPT，這項2022年11月才推出的技術在短六個月內就吸引了超過十億使用者，創下了史上最快被採用的技術記錄。這些資料清楚地展示了AI技術的滲透力和影響範圍。

AI的魅力不僅在於它的潛力，更在於它提供的使用者經驗。以ChatGPT為例，它擁有簡潔的介面，不需任何訓練即可使用，能提供即時結果，並且能以最少的輸入大幅提升生產力。過去需要花費數小時研究的任務，現在只需片刻就能完成。

AI技術的廣泛應用與影響

AI最初在開發者社群中獲得關注，但現在正迅速擴充套件到各個非技術性領域，包括商業、金融和行銷。AI被廣泛認為是商業營運的遊戲規則改變者，將徹底改變組織的運作方式，影響從人力資源和IT到法務、內容創作和行銷的各個部門。

隨著生態系統的快速發展，AI/ML應用領域正在經歷高速增長。幾乎每天都有新工具、新整合和新見解出現。由於需求量大，即使對初學者來說，進入這個開創性領域也變得驚人地容易。對於更有經驗的工程師來說，這仍然是一個令人振奮的時代—玄貓個人認為，自從手機開始能夠安裝應用程式以來，我們還沒有見過如此多的創新和熱情！

技術學習方式的轉變

過去15年來，Stack Overflow的開發者論壇和專業檔案一直是學習程式設計和使用現有技術的基礎資源。開發者會閱讀建議並嘗試複製，在學習過程中不斷嘗試，同時消化許多工作者的意見。我們的學習方式—透過閱讀和反覆實驗—從根本上塑造了我們成為什麼樣的開發者。

而現在，有了ChatGPT、Copilot和Gemini等工具，我們有了一種不同與更快的方式來找到並消化我們需要的資訊。我們不再需要解析數十條建議並將它們編織成可行的方案。長遠來看，這種趨勢可能會導致開發者不太依賴官方檔案、程式碼範例和故障排除，或者不再依賴全球其他開發者的知識。更有可能的是，他們會尋求AI生成的指導和資訊。

開發者體驗的人性化價值

在我的職業生涯中，玄貓有幸遇到許多教師。無論是在程式碼審查時坐在旁邊的同事，還是YouTube影片中的講師，我主要是從其他開發者那裡學習的，為此我永遠感激不盡。我不知道如果我的老師只是機器，未來會是什麼樣子。我希望，如果沒有別的，他們至少能帶著諷刺和迷因。

作為開發者的經歷本質上是一種人性化的體驗，雖然不完美與參差不齊，但這些過程中的坎坷是有價值的。在第一次（或第五次）嘗試失敗並不總是毫無意義的。一旦你建立了一個AI應用程式，它將改變使用者的體驗和行為。它可能幫助他們更快地使用你的產品，但也可能意味著他們對事物的理解不夠深入，因為他們不必經歷那條漫長、崎嶇的理解之路。

本章的目標與架構

在本章中，我們將學習生成式AI（GenAI），然後如何使用Python構建GenAI應用。我們不僅會介紹如何構建應用，還會討論如何改進、操作和監控它。雖然適合初學者，但本章也為那些已經在構建GenAI應用的人提供見解，特別是在操作和安全方面。我們將AI視為一種既出色又具有潛在風險的技術，既認可其益處，也面對其挑戰。

讓我們一起深入探索這個令人著迷的技術領域，記住：能力越大，責任越大。現在，讓我們開始吧！

AI應用開發：從概念到實踐

在開始構建AI密集型應用之前，我們需要理解一些基本概念和工具。這一章將為你奠定堅實的基礎，使你能夠有效地設計和實作人工智慧應用。

AI和機器學習的基礎

人工智慧（AI）是一個廣泛的領域，旨在建立能夠模擬人類智慧的系統。機器學習（ML）是AI的一個子集，專注於開發能夠從資料中學習和改進的演算法。

在過去幾年中，深度學習—一種使用多層神經網路的機器學習方法—已經在影像識別、自然語言處理和其他領域取得了突破性的進展。這些進步為像ChatGPT這樣的大語言模型（LLM）的發展鋪平了道路。

大語言模型的崛起

大語言模型（LLMs）是一種根據深度學習的模型，經過海量文字資料訓練，能夠理解和生成人類語言。這些模型能夠執行各種任務，從文字生成和摘要到問答和翻譯。

LLMs的核心是Transformer架構，這是一種能夠平行處理文字並捕捉長距離依賴關係的神經網路設計。這種架構使模型能夠理解語言的連貫的背景與環境和微妙之處，從而生成連貫與相關的回應。

向量資料函式庫I應用的關鍵基礎設施

向量資料函式庫種專門設計用來儲存和查詢向量資料的資料函式庫。在AI應用中，文字、影像和其他資料通常被轉換為向量（數字陣列），這些向量捕捉了資料的語義意義。

向量資料函式庫開發者執行相似性搜尋，找到與查詢向量最接近的向量。這種能力在許多AI應用中都是至關重要的，例如推薦系統、影像搜尋和自然語言處理。

MongoDB的Atlas Vector Search是一個強大的向量資料函式庫方案，它與MongoDB的檔案模型無縫整合，使開發者能夠輕鬆地構建和擴充套件AI應用。

Python：AI開發的首選語言

Python已經成為AI和ML開發的首選語言，這要歸功於其簡潔的語法、豐富的函式庫系統和強大的社群支援。許多流行的AI框架和工具，如TensorFlow、PyTorch和Hugging Face Transformers，都提供了Python介面。

在本章中，我們將使用Python來構建我們的AI應用，利用其廣泛的函式庫具來簡化開發過程。

實用AI應用的設計原則

設計有效的AI應用需要考慮幾個關鍵原則：

1. 明確的問題定義：確保你清楚地瞭解你的應用要解決的問題。

2. 適當的技術選擇：根據你的需求選擇合適的模型和工具。不是所有問題都需要最先進的LLM。

3. 使用者經驗優先：設計直觀與有用的使用者介面，使非技術使用者也能與你的AI應用互動。

4. 可擴充套件性考慮：從一開始就考慮你的應用如何隨著使用者和資料的增長而擴充套件。

5. 道德和負責任的AI：考慮你的應用的道德影響，包括偏見、隱私和安全問題。

準備開發環境

在開始構建AI應用之前，我們需要設定開發環境。這包括安裝Python、必要的函式庫具，以及設定資料函式庫他服務。

下面是一個基本的設定步驟：

1. 安裝Python（推薦使用3.8或更高版本）
2. 設定虛擬環境來管理依賴
3. 安裝必要的函式庫pandas、numpy、scikit-learn等
4. 設定MongoDB Atlas帳戶和叢集
5. 取得必要的API金鑰和存取憑證

在接下來的章節中，我們將詳細介紹這些步驟，並開始構建我們的第一個AI應用。

大語言模型：運作原理與應用策略

大語言模型（LLMs）已成為生成式AI革命的核心。為了有效地使用這些模型構建應用程式，我們需要了解它們的工作原理、能力和侷限性。

LLM的內部運作機制

LLM是根據Transformer架構的深度學習模型，透過大量文字資料訓練而成。這些模型通常包含數十億甚至數千億個引數，使它們能夠理解和生成人類語言。

Transformer架構的關鍵創新是注意力機制，它允許模型在處理文字時關注相關單詞，無論它們在句子中的距離如何。這使得模型能夠捕捉長距離依賴關係和連貫的背景與環境訊息。

LLM的訓練過程通常包括兩個階段：

1. 預訓練：模型在大量文字資料上訓練，學習語言的統計模式和結構。

2. 微調：預訓練模型在特定任務的資料集上進一步訓練，以改進其在該任務上的表現。

近年來，指令微調和人類反饋強化學習（RLHF）等技術進一步提高了LLM的能力，使它們能夠更好地遵循指令和產生更有幫助的回應。

選擇合適的LLM

市場上有各種各樣的LLM可供選擇，從開放原始碼模型如Llama 2和Mistral到商業API如OpenAI的GPT-4和Anthropic的Claude。選擇合適的模型取決於多種因素：

1. 效能需求：不同模型在各種任務上的表現各不相同。一些模型在創意生成方面表現出色，而其他模型可能更擅長事實問答。

2. 資源限制：較大的模型通常需要更多的計算資源，這可能會影響佈署選項和成本。

3. 隱私考慮：如果你處理敏感資料，你可能需要考慮本地佈署的模型或具有強大隱私保證的提供商。

4. 成本：商業LLM API根據使用量收費，這可能會影響你的選擇，特別是對於高容量應用。

5. 可定製性：如果你需要針對特定領域或任務定製模型，開放原始碼模型可能提供更大的靈活性。

提示工程技術

提示工程是設計輸入以取得LLM最佳輸出的藝術。有效的提示可以顯著提高LLM的效能，特別是在複雜任務上。

以下是一些關鍵的提示工程技術：

1. 明確指令：清晰地指定你希望模型做什麼，包括任務、格式和任何特定要求。

2. 提供連貫的背景與環境：給模型足夠的背景訊息，使其能夠生成相關回應。

3. 使用範例：提供輸入-輸出範例來說明你期望的行為（少樣本學習）。

4. 角色指定：指定模型應該扮演的角色，例如「作為一個數學家」或「作為一個法律工作者」。

5. 分解複雜任務：將複雜問題分解為更簡單的子任務，逐步引導模型。

下面是一個有效提示的例子：

大語言模型基礎

大語言模型（LLMs）已成為現代人工智慧應用的核心技術。當玄貓第一次接觸這項技術時，我就被它能處理和生成人類語言的能力所震撼。讓我們一起深入瞭解這項技術的基礎原理和發展歷程。

機率框架的語言模型

語言模型的核心任務是預測文字序列中下一個詞的可能性。這個任務根據機率框架，將語言視為一個統計現象。具體來說，語言模型嘗試計算特定詞彙序列出現的機率。

對於一個詞彙序列 W = (w₁, w₂, …, wₙ)，語言模型計算 P(W) 的機率。根據條件機率的鏈式法則，這可以表示為：

P(W) = P(w₁) × P(w₂|w₁) × P(w₃|w₁,w₂) × ... × P(wₙ|w₁,...,wₙ₋₁)

這個公式表示了一個詞彙序列的機率等於每個詞彙在給定前面所有詞彙的條件下出現的機率的乘積。

n-gram 語言模型

早期的語言模型採用 n-gram 方法，這是一種根據馬可夫假設的簡化方法。n-gram 模型假設一個詞的出現只依賴於前面 n-1 個詞，而不是整個序列。

例如，在三元語法（trigram）模型中，我們假設：

P(wₙ|w₁,...,wₙ₋₁) ≈ P(wₙ|wₙ₋₂,wₙ₋₁)

這種簡化使計算變得可行，但也限制了模型捕捉長距離依賴關係的能力。n-gram 模型透過計數語料函式庫n-gram 的出現頻率來估計這些機率：

P(wₙ|wₙ₋ₙ₊₁,...,wₙ₋₁) ≈ count(wₙ₋ₙ₊₁,...,wₙ) / count(wₙ₋ₙ₊₁,...,wₙ₋₁)

在實際應用中，n-gram 模型面臨資料稀疏性問題。隨著 n 的增加，許多可能的 n-gram 在訓練資料中可能很少或根本不出現，導致零機率問題。為解決這個問題，引入了平滑技術，如拉普拉斯平滑或古德-圖靈估計，為未見過的 n-gram 分配小的非零機率。

儘管 n-gram 模型簡單實用，但它們無法有效捕捉語言的長距離依賴性和語義關係，這促使研究者探索更複雜的語言模型方法。

機器學習在語言模型中的應用

隨著機器學習技術的發展，語言模型也從簡單的統計方法進化到更複雜的學習架構。人工神經網路（Artificial Neural Networks，ANNs）成為這一轉變的關鍵推動力。

人工神經網路

人工神經網路受到人腦神經元網路的啟發，由多層相互連線的神經元組成。每個神經元接收輸入，應用轉換函式，並產生輸出。

一個基本的神經元（或感知器）可以表示為：

y = f(∑ᵢ wᵢxᵢ + b)

其中 x 是輸入向量，w 是權重向量，b 是偏置項，f 是啟用函式（如 sigmoid、tanh 或 ReLU）。

深度學習模型由多層神經元組成，形成複雜的網路結構：

1. 輸入層：接收原始資料
2. 隱藏層：處理資料的內部表示
3. 輸出層：產生最終預測或分類別結果

訓練人工神經網路

神經網路透過反向傳播和梯度下降演算法進行訓練。訓練過程包括以下步驟：

1. 前向傳播：輸入資料透過網路產生預測
2. 計算損失：比較預測與實際目標值的差異
3. 反向傳播：計算損失函式相對於每個權重的梯度
4. 權重更新：使用梯度下降調整權重以減小損失

這個過程反覆進行，直到模型收斂到令人滿意的效能。

神經網路的強大之處在於它能夠自動學習複雜的特徵表示，而不需要人工特徵工程。這種能力使它們在處理複雜的自然語言任務時特別有效。

神經網路在自然語言處理中的應用

將神經網路應用於自然語言處理涉及幾個關鍵步驟：

標記化（Tokenization）

標記化是將文字分解為更小單位（標記或token）的過程。標記可以是單詞、子詞或字元。對於LLMs，子詞標記化是常見的方法，如Byte-Pair Encoding (BPE)或WordPiece，它們能有效處理生詞和複合詞。

在我的實踐中，標記化是處理任何文字資料的第一步，它極大地影響了模型的效能和泛化能力。

嵌入（Embedding）

嵌入是將離散標記轉換為密集向量表示的過程。這些向量捕捉標記的語義和句法特性，使相似的詞在向量空間中彼此接近。

早期的嵌入技術如Word2Vec和GloVe透過分析大量文字中的詞共現關係來學習詞向量。現代LLMs使用更複雜的連貫的背景與環境嵌入，它們考慮標記在句子中的位置和周圍的連貫的背景與環境。

嵌入層將輸入標記對映到連續向量空間：

# 簡化的嵌入層範例
embedding_dim = 300
vocab_size = 10000
embedding_layer = torch.nn.Embedding(vocab_size, embedding_dim)

# 將標記ID轉換為嵌入向量
token_ids = torch.tensor([1, 2, 3, 4])
embeddings = embedding_layer(token_ids)  # 形狀: [4, 300]

預測機率分佈

語言模型的核心任務是預測下一個標記的機率分佈。在神經網路架構中，這通常透過softmax層實作：

# 簡化的語言模型預測層
hidden_size = 768
vocab_size = 10000
prediction_layer = torch.nn.Linear(hidden_size, vocab_size)

# 從隱藏狀態預測下一個標記
hidden_state = torch.randn(1, hidden_size)
logits = prediction_layer(hidden_state)
probabilities = torch.nn.functional.softmax(logits, dim=-1)

這個機率分佈可用於生成文字（選擇高機率的標記）或計算損失（與實際下一個標記比較）。

處理序列資料

自然語言是本質上的序列資料，處理這種資料需要特殊的神經網路架構。

迴圈神經網路（Recurrent Neural Networks）

迴圈神經網路（RNNs）透過維持內部狀態來處理序列資料。在每個時間步，RNN接收當前輸入和前一個時間步的隱藏狀態，然後更新隱藏狀態並產生輸出。

基本RNN的公式如下：

hₜ = f(Wₓₕxₜ + Wₕₕhₜ₋₁ + bₕ)
yₜ = g(Wₕᵧhₜ + bᵧ)

其中 h 是隱藏狀態，x 是輸入，y 是輸出，W 和 b 是可學習的引數。

RNN能夠處理變長序列，但在處理長序列時面臨梯度消失或爆炸問題。長短期記憶網路（LSTM）和門控迴圈單元（GRU）等變體透過引入門控機制來緩解這些問題，使模型能更好地捕捉長距離依賴關係。

Transformer架構

Transformer架構，首次在"Attention Is All You Need"論文中提出，徹底改變了自然語言處理領域。它完全依靠注意力機制而非迴圈結構，可以平行處理整個序列，大幅提高訓練效率。

Transformer的核心元件是自注意力機制，它允許模型關注輸入序列的不同部分：

Attention(Q, K, V) = softmax(QK^T/√d_k)V

其中Q（查詢）、K（鍵）和V（值）是由輸入序列線性轉換得到的矩陣。

Transformer架構包括多頭注意力、前饋神經網路、殘差連線和層歸一化等元件。它的編碼器-解碼器結構使其適用於各種序列轉換任務，如機器翻譯。

大語言模型如GPT系列主要使用Transformer的解碼器部分，透過預測下一個標記來生成文字。

LLMs的實際應用

大語言模型領域發展迅速，從早期的BERT和GPT模型到最新的GPT-4、LLaMA和PaLM等。這些模型在引數規模、訓練資料和能力上不斷突破。

在實際應用中，有三種主要使用LLMs的方法：

1. 提示工程（Prompting）：透過精心設計的提示引導模型生成所需輸出。這是最簡單的使用方式，但需要技巧來獲得一致的結果。

2. 微調（Fine-tuning）：在特定任務的資料上進一步訓練預訓練模型。這可以顯著提高模型在特定領域的效能，但需要計算資源和專業知識。

3. 檢索增強生成（RAG）：結合檢索系統和生成模型，先檢索相關資訊，再根據檢索結果生成回應。這種方法能提高模型回答的準確性和時效性，特別適合需要最新或專業知識的應用。

在玄貓的實踐中，結合這三種方法往往能達到最佳效果，特別是在構建特定領域的人工智慧應用時。

嵌入模型的深入解析

在構建人工智慧應用時，除了大語言模型，嵌入模型也是不可或缺的組成部分。玄貓在多個專案中發現，正確選擇和使用嵌入模型對應用的效能有決定性影響。

嵌入模型的本質

嵌入模型是將文字、影像或其他類別的資料轉換為高維向量表示的工具。這些向量捕捉了原始資料的語義訊息，使我們能夠以數學方式計算資料項之間的相似度。

簡單來說，嵌入模型將不同形式的資料對映到一個共同的向量空間，在這個空間中，相似的概念彼此接近，不相關的概念則相距較遠。

嵌入模型與LLMs的區別

雖然嵌入模型和大語言模型都處理文字資料，但它們的目標和應用場景有明顯差異：

1. 主要功能：

   • 嵌入模型：建立資料的數值表示，主要用於相似度比較和檢索
   • LLMs：理解和生成人類語言，執行各種複雜的語言任務

2. 輸出格式：

   • 嵌入模型：輸出固定維度的向量
   • LLMs：輸出自然語言文字

3. 計算資源：

   • 嵌入模型：通常較輕量，計算效率高
   • LLMs：通常需要更多計算資源

4. 應用場景：

   • 嵌入模型：語義搜尋、檔案分類別、聚類別、推薦系統
   • LLMs：對話系統、文字生成、翻譯、摘要

何時使用嵌入模型與LLMs

在實際應用中，應根據具體需求選擇使用嵌入模型還是LLMs：

• 當需要比較文字相似度或檢索相關檔案時，嵌入模型是首選
• 當需要生成新內容或理解複雜查詢時，LLMs更合適
• 在許多現代應用中，兩者結合使用效果最佳，例如檢索增強生成（RAG）系統

嵌入模型的類別

嵌入模型根據其設計目標和應用場景可分為多種類別：

1. 文字嵌入模型

文字嵌入模型將文字轉換為向量表示。根據處理的文字單位，可進一步分類別：

• 詞嵌入：如Word2Vec、GloVe，專注於單個詞的向量表示
• 句子嵌入：如BERT、USE (Universal Sentence Encoder

有用的框架、函式庫PI

在當今的AI應用開發中，選擇合適的框架、函式庫PI至關重要。這些工具能大幅提升開發效率，避免重複造輪子，同時確保應用程式的穩定性與擴充套件性。玄貓在多年的開發經驗中發現，掌握這些工具不僅能加快開發進度，更能讓我們專注於解決業務問題而非技術難題。

技術需求

在開始探索這些工具前，請確保你的環境已準備就緒：

• Python 3.10或更新版本
• 良好的網路連線以安裝相關套件
• MongoDB雲端帳戶（用於向量搜尋範例）
• OpenAI API金鑰（用於與LLM互動）
• Jupyter Notebook（用於實驗與教學）

Python在AI/ML領域的應用

Python已成為AI/ML開發的首選語言，這並非偶然。Python的簡潔語法、豐富套件生態系統以及強大的社群支援，使其成為實作複雜AI模型的理想工具。

當我第一次接觸機器學習時，曾嘗試使用Java實作一些基本演算法。然而，轉向Python後，開發效率提升了數倍。Python的簡潔語法讓我能專注於演算法邏輯，而非繁瑣的程式碼結構。

Python在AI/ML領域的優勢主要體現在：

• 豐富的專門函式庫NumPy、pandas、TensorFlow、PyTorch等）
• 快速原型開發能力
• 與大多數雲端服務和API的良好整合
• 活躍的開發社群和詳盡的檔案

AI/ML框架

在AI/ML領域，框架提供了實作複雜模型和演算法的高階抽象。以下是幾個關鍵框架：

LangChain

LangChain是近年來最受歡迎的LLM應用開發框架之一。它提供了一套工具和抽象，使開發者能更輕鬆地構建根據語言模型的應用程式。

LangChain的核心理念是將LLM的能力與外部資料源和計算環境連線起來，實作更複雜、更實用的應用。這種方法使LLM能夠突破其訓練資料的限制，存取最新訊息，並執行特定領域的任務。

以下是LangChain的主要元件：

1. 模型（Models）：與各種LLM（如OpenAI、Hugging Face等）的整合
2. 提示詞（Prompts）：管理和最佳化提示詞範本
3. 鏈（Chains）：將多個元件連線成流程
4. 記憶（Memory）：管理對話歷史和連貫的背景與環境
5. 索引（Indexes）：處理和檢索外部資料
6. 代理（Agents）：使LLM能夠根據任務選擇使用工具

讓我們看一個基本的LangChain範例，展示如何使用它與OpenAI的模型互動：

# 安裝必要的套件
# pip install langchain openai pymongo

from langchain.llms import OpenAI
from langchain.prompts import PromptTemplate
from langchain.chains import LLMChain
import os

# 設定OpenAI API金鑰
os.environ["OPENAI_API_KEY"] = "your-api-key-here"

# 初始化LLM
llm = OpenAI(temperature=0.7)

# 建立提示詞範本
prompt_template = PromptTemplate(
    input_variables=["product"],
    template="為{product}寫一個簡短的廣告文案，強調其環保特性。"
)

# 建立鏈
chain = LLMChain(llm=llm, prompt=prompt_template)

# 執行鏈
result = chain.run("竹製餐具套裝")
print(result)

• 首先，我們匯入必要的LangChain元件和OpenAI
• 設定OpenAI API金鑰（在實際應用中，應從環境變數或安全儲存取得）
• 初始化OpenAI LLM，設定temperature引數控制輸出的創造性
• 建立提示詞範本，定義輸入變數和範本文字
• 建立LLMChain，連線LLM和提示詞範本
• 執行鏈並傳入特定產品，取得生成的廣告文案

LangChain的強大之處在於它的模組化設計。你可以輕鬆地替換不同的LLM，修改提示詞範本，或者擴充套件鏈以包含更多步驟。

LangChain語義搜尋與評分

LangChain提供了強大的語義搜尋功能，可以根據語義相似度而非關鍵字比對來檢索檔案。這在構建知識函式庫答系統時特別有用。

以下是一個使用LangChain進行語義搜尋的範例：

from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import MongoDBAtlasVectorSearch
from pymongo import MongoClient
import os

# 設定OpenAI API金鑰
os.environ["OPENAI_API_KEY"] = "your-api-key-here"

# 連線MongoDB
client = MongoClient("your-mongodb-connection-string")
db = client.langchain_db
collection = db.test

# 準備檔案
documents = [
    "人工智慧正在改變各行各業的運作方式",
    "大語言模型如GPT-4展示了令人印象深刻的能力",
    "向量搜尋是實作高效語義檢索的關鍵技術",
    "Python是AI開發中最受歡迎的程式設計語言"
]

# 初始化嵌入模型
embeddings = OpenAIEmbeddings()

# 建立向量儲存
vector_search = MongoDBAtlasVectorSearch.from_documents(
    documents,
    embeddings,
    collection=collection,
    index_name="default"
)

# 執行語義搜尋
query = "哪種程式設計語言最適合AI開發？"
results = vector_search.similarity_search_with_score(query, k=2)

# 顯示結果
for doc, score in results:
    print(f"檔案: {doc.page_content}")
    print(f"相似度分數: {score}")
    print("---")

• 我們使用OpenAIEmbeddings生成檔案和查詢的向量表示
• 將檔案儲存在MongoDBAtlasVectorSearch中，這是LangChain支援的向量儲存之一
• 使用similarity_search_with_score方法執行搜尋，回傳最相似的檔案及其相似度分數
• k=2引數指定回傳前2個最相似的結果
• 結果包含檔案內容和相似度分數，分數越高表示越相似

帶預過濾的語義搜尋

在處理大型檔案集合時，預過濾可以顯著提高搜尋效率。LangChain允許你在執行向量相似度搜尋前應用過濾條件：

from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import MongoDBAtlasVectorSearch
from pymongo import MongoClient
import os

# 設定相關環境變數和連線
os.environ["OPENAI_API_KEY"] = "your-api-key-here"
client = MongoClient("your-mongodb-connection-string")
db = client.langchain_db
collection = db.documents_with_metadata

# 準備帶元資料的檔案
documents_with_metadata = [
    {"content": "Python是一種易於學習的程式設計語言", "metadata": {"category": "programming", "level": "beginner"}},
    {"content": "TensorFlow是Google開發的機器學習框架", "metadata": {"category": "machine_learning", "level": "intermediate"}},
    {"content": "向量資料函式庫化了相似性搜尋操作", "metadata": {"category": "databases", "level": "advanced"}},
    {"content": "Django是Python的Web框架", "metadata": {"category": "programming", "level": "intermediate"}}
]

# 插入檔案
for doc in documents_with_metadata:
    collection.insert_one({
        "content": doc["content"],
        "metadata": doc["metadata"],
        "embedding": OpenAIEmbeddings().embed_query(doc["content"])
    })

# 初始化向量搜尋
embeddings = OpenAIEmbeddings()
vector_search = MongoDBAtlasVectorSearch(
    collection,
    embeddings,
    text_key="content",
    embedding_key="embedding",
    index_name="default"
)

# 帶預過濾的語義搜尋
query = "什麼是好的Web開發工具？"
filter_condition = {"metadata.category": "programming"}

results = vector_search.similarity_search_with_score(
    query,
    k=2,
    pre_filter=filter_condition
)

# 顯示結果
for doc, score in results:
    print(f"檔案: {doc.page_content}")
    print(f"元資料: {doc.metadata}")
    print(f"相似度分數: {score}")
    print("---")

• 我們為每個檔案增加了元資料（category和level）
• 在執行向量搜尋時，使用pre_filter引數應用過濾條件
• 過濾條件限制只搜尋category為"programming"的檔案
• 這種方法結合了傳統的結構化查詢和向量相似度搜尋的優點
• 對於大型檔案集合，預過濾可以顯著提高搜尋效率和準確性

使用LangChain實作基本RAG解決方案

檢索增強生成（RAG）是一種結合檢索系統和生成模型的方法，可以大幅提升LLM生成內容的準確性和相關性。以下是使用LangChain實作簡單RAG系統的範例：

from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import MongoDBAtlasVectorSearch
from langchain.llms import OpenAI
from langchain.chains import RetrievalQA
from pymongo import MongoClient
import os

# 設定環境和連線
os.environ["OPENAI_API_KEY"] = "your-api-key-here"
client = MongoClient("your-mongodb-connection-string")
db = client.langchain_db
collection = db.knowledge_base

# 準備知識函式庫
documents = [
    "Python是一種高階程式設計語言，以其簡潔的語法和豐富的生態系統而聞名。它支援多種程式設計正規化，包括導向物件、命令式和函式程式設計。",
    "向量資料函式庫最佳化用於儲存和檢索向量嵌入。它們使用特殊的索引結構來高效執行K-最近鄰(KNN)搜尋，這在實作語義搜尋中至關重要。",
    "大語言模型(LLM)是根據Transformer架構的神經網路，經過大規模文字資料訓練。它們能夠生成人類級別的文字，理解連貫的背景與環境，並執行各種語言任務。",
    "檢索增強生成(RAG)結合了檢索系統和生成模型的優點。它首先檢索相關訊息，然後將這些訊息與使用者查詢一起提供給LLM，從而生成更準確、更相關的回應。"
]

# 初始化嵌入和向量儲存
embeddings = OpenAIEmbeddings()
vector_search = MongoDBAtlasVectorSearch.from_documents(
    documents,
    embeddings,
    collection=collection,
    index_name="default"
)

# 初始化LLM
llm = OpenAI(temperature=0)

# 建立RAG鏈
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=vector_search.as_retriever(search_kwargs={"k": 2})
)

# 執行查詢
query = "RAG和LLM有什麼關係？"
response = qa_chain.run(query)
print(response)

• 我們首先建立一個包含知識條目的向量資料函式庫 使用OpenAI嵌入模型為檔案生成向量表示
• 初始化OpenAI LLM，設定temperature=0以獲得更確定性的回答
• 建立RetrievalQA鏈，這是LangChain提供的一種RAG實作
• chain_type=“stuff"表示將檢索到的所有檔案直接"塞入"提示詞
• vector_search.as_retriever轉換向量儲存為檢索器，設定k=2檢索最相關的兩個檔案
• 最終，我們執行查詢並獲得根據檢索檔案生成的回答

這種RAG方法的優勢在於它結合了檢索系統的準確性和LLM的生成能力。LLM可以根據檢索到的相關訊息生成連貫、準確的回答，而不僅依賴其預訓練知識。

LangChain提示詞範本和鏈

LangChain的提示詞範本和鏈系統提供了強大的工具，用於構建複雜的LLM應用流程：

from langchain.llms import OpenAI
from langchain.prompts import PromptTemplate
from langchain.chains import SequentialChain, LLMChain
import os

# 設定API金鑰
os.environ["OPENAI_API_KEY"] = "your-api-key-here"

生成式人工智慧的技術世界：開發者

在我多年的技術開發生涯中，很少看到像生成式AI這樣迅速改變技術格局的革命性技術。作為一名經常在前沿技術領域工作的開發者，我深刻體會到掌握生成式AI基礎知識的重要性。這篇文章將帶你深入瞭解生成式AI的核心概念、關鍵技術堆積積疊以及實際應用場景，特別適合想要在這個領域起步的開發者。

當前的生成式AI領域發展迅猛，技術工具更迭頻繁，讓人眼花繚亂。有些AI公司可能在這篇文章發布後幾週內就不復存在。因此，我將聚焦於長期存在的高階概念和核心技術，這些是構建生成式AI應用的根本。

核心技術語解析

在深入技術細節前，先來釐清幾個經常混淆的關鍵概念：

人工智慧 (AI)

人工智慧指的是機器執行通常需要人類人工智慧的任務的能力。這包括感知、推理、學習和決策等任務。AI的發展歷程相當漫長，從早期的理論構想到今日的複雜技術體系，經歷了數十年的演進。

AI發展時間軸上的關鍵節點包括：

• 1950年：神經網路計算模型架構的提出
• 1950年代：人工智慧術語的正式確立及圖靈測試的提出
• 1960年代：第一個從試錯中學習的電腦感知器的發展
• 1970年代：工作者系統開始模擬人腦決策能力
• 1980年代：AI在醫療、模擬器和任務管理領域的廣泛應用
• 1990年代：IBM開發能擊敗人類工作者棋手的Deep Blue
• 2000年代：語音識別技術在個人助理中的應用
• 2010年代至今：大資料分析促進更複雜系統的發展，生成式AI和LLM（如ChatGPT）的崛起

機器學習 (ML)

機器學習是AI的一個子集，涉及使用演算法自動從資料中學習並隨時間改進。本質上，它是機器在沒有明確程式設計的情況下學習和適應的方式。ML最常用於需要分析上千資料點的領域，如醫療診斷、市場分析和軍事情報。ML能夠識別人類無法看見的隱藏或複雜的資料模式，然後提出下一步行動的建議。

生成式人工智慧 (GenAI)

生成式AI是能夠根據使用者提示建立文字、影像、音訊、影片和其他內容的能力。它為聊天機器人、虛擬助手、語言翻譯器等服務提供動力。這些系統使用在大量資料（如來自網際網路的文字和影像）上訓練的演算法，學習模式和關係，從而能夠生成類別似但不完全相同於底層訓練資料的新內容。

例如，大語言模型(LLM)使用訓練資料學習書面語言的模式，然後生成式AI可以使用這些模型來模擬人類的寫作風格。在我參與的一個金融科技專案中，我們利用生成式AI自動產生客戶服務回應，這不僅提高了效率，還使回應更加個人化與符合公司的語調。

生成式AI技術堆積積疊的選擇

構建功能完整的生成式AI應用需要整合多種技術元件。在玄貓看來，一個基礎的生成式AI堆積積疊至少需要包含以下元素：

1. 作業系統：通常根據Unix/Linux系統
2. 儲存層：SQL或NoSQL資料函式庫文將使用MongoDB）
3. **能夠儲存嵌入向量的資料函式庫：本文使用MongoDB，它可以將嵌入向量直接儲存在資料內容中
4. 網頁伺服器：如Apache或Nginx
5. 開發環境：如Node.js/JavaScript、.NET、Java或Python（本文主要使用Python）

這些元件的整合形成了一個完整的技術生態系統，使開發者能夠構建、佈署和擴充套件生成式AI應用。在實際開發中，我發現根據專案需求靈活調整堆積積疊元件非常重要，但上述基礎設定適用於大多數生成式AI應用場景。

Python與生成式AI的完美結合

Python語言由Guido van Rossum在1980年代末期構思，並於1991年正式發布。經過數十年的發展，Python已演變成一種多功能語言，因其簡潔的語法和強大的功能而備受開發者喜愛。

在我的職業生涯中，我見證了Python如何在AI和ML領域迅速崛起。雖然原因不完全清楚，但早期Python生態系統就開始引入更多針對ML和資料科學的函式庫架。TensorFlow、Keras、PyTorch和scikit-learn等函式庫些領域的開發者提供了強大的工具，而技術知識較少的分析師也能相對容易地上手Python。

生成式AI需要高計算能力和複雜演算法，而Python在這方面表現卓越：

• 資料處理：Pandas和NumPy等函式庫高效處理和分析大型資料集
• 神經網路開發：TensorFlow和PyTorch提供預建元件來設計和訓練複雜的神經網路
• 資料視覺化：Matplotlib和Seaborn實作資料和模型輸出的詳細視覺化
• Web服務佈署：Flask和FastAPI讓將生成式AI模型佈署為可擴充套件的Web服務變得簡單直觀

Python豐富的生態系統易於使用與允許快速入門，使其成為生成式AI專案的理想程式設計語言。在我帶領的一個自然語言處理專案中，我們能夠在短幾週內從概念驗證到功能原型，很大程度上得益於Python生態系統的成熟度和易用性。

OpenAI API：生成式AI的核心引擎

OpenAI API是本文中最關鍵的工具之一。該API於2020年中期推出，為開發者提供了存取OpenAI強大模型的途徑，允許將高階自然語言處理(NLP)能力整合到應用程式中。

透過此API，開發者可以存取一些現存最先進的AI模型，如GPT-4。這些模型在龐大的資料集上進行訓練，具有無與倫比的自然語言理解和回應生成能力。

OpenAI的基礎設施也設計為可擴充套件的。隨著專案的增長和對計算能力的需求增加，OpenAI確保你可以輕鬆擴充套件，而無需擔心底層硬體或系統架構。OpenAI的模型在NLP任務方面表現出色，包括文字生成、摘要、翻譯和情感分析，這對於建立內容、聊天機器人、虛擬助手等非常有價值。

在我最近的一個專案中，我們使用OpenAI API構建了一個能夠理解並回應客戶查詢的人工智慧客服系統。令人印象深刻的是，該系統不僅能夠處理標準問題，還能處理複雜的、多步驟的客戶需求，這在傳統規則基礎系統中是難以實作的。

MongoDB與向量搜尋：生成式AI的資料基礎

MongoDB在處理非結構化資料方面表現出色，這正是現實世界的特點。曾經有一位領先太空探索公司的研究人員在會議上發表了這樣一段令人難忘的評論：

“我們主要從網站和PDF檔案中抓取文字內容，並意識到嘗試將這些資料塞入表格中實際上沒有意義。”

MongoDB能夠處理現實世界中雜亂、非結構化的內容，如.txt檔案、Markdown、PDF、HTML等。MongoDB的靈活性足以擁有工程師認為最適合目的結構，正因為這種靈活性，它非常適合生成式AI使用案例。

另一個使用MongoDB的原因是其向量搜尋能力。向量搜尋確保當你在MongoDB中儲存一個短語時，它會將該資料轉換成一個陣列，這被稱為向量。向量是資料及其連貫的背景與環境的數值表示。這些維度的數量被稱為嵌入，擁有的維度越多越好。

以下是向量的簡單範例：

"quick brown fox" = [0.743, 0.720, -0.325, 0.195, 0.835, -0.945, ...]

在為一段資料建立嵌入後，一個數學過程將識別哪些向量彼此最接近或最近，然後你可以推斷資料是相關的。這允許你回傳相關字詞而不僅是精確比對。例如，如果你在搜尋"寵物”，你可以找到貓、狗、鸚鵡和倉鼠，即使這些詞並不是確切的"寵物"一詞。向量使你能夠接收在意義、連貫的背景與環境或相似性上相關的結果，而不僅是精確比對。

MongoDB將嵌入向量與資料本身一起儲存，這使得後續查詢更快。在我的一個電子商務推薦系統專案中，我們使用MongoDB的向量搜尋功能來識別相似產品，這大提高了推薦的相關性和使用者點選率。

生成式AI的關鍵特性與應用場景

生成式AI具有許多獨特性，使其在各種應用中非常有價值：

1. 自然語言理解與生成

生成式AI能夠理解人類語言的細微差別，並生成流暢、連貫的回應。這使其成為聊天機器人、內容創作和自動客戶服務的理想選擇。

2. 連貫的背景與環境感知

現代生成式AI模型能夠記住對話歷史並理解連貫的背景與環境，使互動更加自然和有意義。在一個我參與的醫療諮詢專案中，這種連貫的背景與環境理解能力讓AI能夠在複雜的診斷討論中保持連貫性。

3. 多模態能力

最先進的生成式AI系統可以處理文字、影像、音訊甚至影片，實作跨模態理解和生成。

4. 適應性學習

生成式AI可以透過持續學習和微調來適應特定領域或使用案例，隨著時間的推移提高其準確性和相關性。

為什麼選擇生成式AI？

在當前技術格局中，生成式AI提供了多方面的優勢：

效率提升

自動化內容生成、客戶服務和資料分析等任務，顯著提高工作效率。在一個內容管理專案中，我們使用生成式AI自動生成產品描述，將內容創作時間減少了70%。

創新可能性

開啟前所未有的創新可能性，從個人化學習體驗到創意內容生成，再到人工智慧決策支援。

擴充套件能力

生成式AI系統可以輕鬆擴充套件以處理大量請求，使其適合高需求環境。

成本效益

透過自動化重複性任務和提高效率，生成式AI可以顯著降低營運成本。

生成式AI的倫理考量與風險

在實作生成式AI的所有優勢的同時，我們必須認真考慮相關的倫理問題和潛在風險：

偏見與公平性

生成式AI模型可能會反映和放大其訓練資料中存在的偏見，導致不公平或歧視性的輸出。在我的實踐中，我始終強調資料集的多樣性和代表性，以減少潛在偏見。

隱私考量

處理和生成個人資料時的隱私問題，特別是在敏感領域如醫療或金融服務。

誤導性內容

生成式AI可能會生成虛假或誤導性訊息，這在新聞和公共訊息領域尤其成問題。

透明度與解釋性

瞭解生成式AI如何做出決策和生成內容可能具有挑

生成式AI的核心特性與革命性價值

生成式AI（GenAI）已經迅速改變了我們與技術互動的方式。作為一名長期研究AI系統的技術工作者，我發現生成式AI的價值遠超過其表面能力。當被問及生成式AI應用最重要的能力時，大多數人會認同它的內容創作功能：能夠以閃電般的速度生成文字、影像、音樂甚至影片。

生成式AI的核心特性

在我多年開發AI系統的經驗中，我認識到生成式AI的價值遠不止於此，它還具備以下關鍵特性：

內容創作與生成

生成式AI最顯著的特性是能夠快速建立各種形式的內容。無論是撰寫文章、根據文字描述生成逼真影像、創作音樂，還是製作影片內容，它為創意產業開啟了無限可能。以我曾參與的一個行銷專案為例，我們使用生成式AI在幾小時內建立了數十個內容變體，這在傳統工作流程中可能需要數週時間。

語言翻譯與跨文化溝通

生成式AI能夠實時翻譯語言，保留連貫的背景與環境和細微差別，促進跨語言障礙的無縫溝通。這不僅是機械式翻譯，而是能理解文化背景的深度轉換。

個人化體驗開發

在行銷和客戶服務領域，生成式AI能夠根據個別使用者量身定製體驗和內容。當提供適當背景時，它能分析偏好和行為，提供個人化推薦、電子郵件和客戶互動。

模擬與建模能力

在科研和工程領域，生成式AI可以模擬複雜系統和現象。它透過根據大量資料集生成的實際模型，幫助預測分子行為、氣候模式，甚至經濟趨勢。

資料增強與合成

對於機器學習，生成式AI可以產生合成資料來增強訓練集。在真實資料稀缺或有偏見的情境下，這尤為寶貴，允許建立多樣化和平衡的資料集來提升模型效能。這對軟體測試特別有用。

為何使用生成式AI？

生成式AI的每一項能力都令人信服與重要，當正確使用並結合時，具有革命性。簡而言之，沒有一個行業不能應用生成式AI。它透過快速聚合和總結各種內容並簡化搜尋，改善了使用者尋找想法和建立知識的體驗。它可以幫助收集新訊息、總結並重新編製成內容，加速甚至自動化行政任務，並成倍增加產出。

更重要的是，使用生成式AI的體驗比現有技術好上一個數量級。以客戶服務機器人為例，許多人熟悉的流程是這樣的：

1. 客戶首先遇到一長串選項：如果要與銷售或支援交談，請按1；對於帳單，請按2…當客戶的問題不能整齊地歸類別時，他們可能會隨便按4。
2. 按下4後，他們被引導到一個不包含他們所尋答案的支援頁面。他們點選一個按鈕說"不，這沒有回答我的問題"。
3. 他們自行搜尋知識函式庫能永遠找不到答案，最終透過電話聯絡。

想像能夠輸入你想要的內容，機器人以自然方式回應 - 不是引導你到一個頁面，而是直接給你答案。更進一步，使用者可以與機器人聊天，說他們想修改訂單的地址，機器人能夠在聊天視窗內完成這項操作，與使用者進行多步驟對話以確認並記錄他們的新訊息。這對客戶來說是一種全新、更令人愉悅的體驗！

生成式AI的倫理與風險

儘管有這些好處，但使用AI也存在風險和顧慮。在某些領域，對AI的抗議是重大的與有道理的。例如，由AI生成的藝術淹沒了網際網路的市場，取代了靠手藝謀生的藝術家和插畫家。有人質疑使用AI寫書是否給了一個人自稱作者的權利。這裡沒有明確的答案；根據自身經驗，我認為生成式AI加速而非取代了今天現有的工作正規化。但這可能不會一直如此。隨著AI的改進，它可能更有可能取代使用它的人類。

生成式AI的風險相當可觀，其中一些尚未被充分理解。即使是已經被充分理解的風險，如幻覺，使用者也難以識別，更難以對抗。關於生成式AI的挑戰以及如何減輕這些挑戰的建議，需要更深入的專業討論。

人工智慧應用的建構元素

在快速發展的軟體開發領域，一類別新型應用正在崛起：人工智慧應用。人工智慧應用是傳統全堆積積疊應用的超集，它們使用人工智慧來提供高度個人化、連貫的背景與環境感知的體驗，超越了傳統軟體的能力。

人工智慧應用的定義

傳統應用通常由客戶端使用者介面、伺服器端後端和用於資料儲存和檢索的資料函式庫。它們按照嚴格的指令集執行任務。人工智慧應用同樣需要客戶端、伺服器和資料函式庫它們用AI元件增強了傳統堆積積疊。

人工智慧應用的突出特點是理解複雜的非結構化資料，以實作自然、適應性的互動和決策。人工智慧應用可以參與開放式互動，生成新穎內容，並做出自主決策。

人工智慧應用的例子包括：

• 使用檢索增強生成(RAG)根據外部資料提供自然語言回應的聊天機器人。例如，Perplexity.ai是一個AI驅動的搜尋引擎和聊天機器人，根據從網路檢索的來源為使用者提供AI生成的答案。

• 讓你使用自然語言提示建立影像、影片和音訊等媒體的內容生成器。有各種專注於不同媒體類別的人工智慧內容生成器，如Suno for text-to-song，Midjourney for text-to-image，和Runway for text-to-video。

• 使用客戶資料根據其偏好和歷史提供個人化建議的推薦系統。這些建議可以用自然語言進一步個人化客戶體驗。Spotify的AI DJ就是一個例子，它根據你的聽歌歷史建立個人化電台，包括LLM生成的DJ插曲。

這些例子是開發者剛開始構建的新類別人工智慧應用的早期瞥見。接下來，我將探討人工智慧應用的核心元件。

人工智慧應用的關鍵建構元素

人工智慧應用的核心有兩個關鍵建構元素：

推理引擎

推理引擎是人工智慧應用的大腦，負責理解使用者輸入、生成適當回應，並根據可用訊息做出決策。推理引擎通常由大語言模型(LLMs)驅動 - 執行文字完成的AI模型。LLMs可以理解使用者意圖，生成類別人回應，並執行複雜的認知任務。

在我設計的一個企業知識管理系統中，我們使用LLM作為推理引擎來理解使用者的複雜查詢，並根據公司內部知識函式庫精確回答。這大減少了員工在檔案中搜尋答案的時間。

語義記憶

語義記憶指的是應用以儲存其含義和關係的方式儲存和檢索訊息的能力，使推理引擎能夠根據需要存取相關連貫的背景與環境。

語義記憶由兩個核心元件組成：

1. AI向量嵌入模型：AI向量嵌入模型以大型數字陣列表示非結構化資料（如文字或影像）的語義含義。

2. **向量資料函式庫：向量資料函式庫地儲存和檢索向量，以支援語義搜尋和連貫的背景與環境檢索。

推理引擎可以從語義記憶中檢索和儲存相關訊息，使用非結構化資料來告知其輸出。

在我參與的一個法律檔案分析系統中，我們使用向量嵌入將數千份合約轉換為向量表示，並儲存在向量資料函式庫這使得律師能夠使用自然語言查詢快速找到相關條款，而不必閱讀整個檔案集合。

模型託管基礎設施

為人工智慧應用提供動力的LLMs和嵌入模型與傳統應用相比有不同的硬體要求，特別是在規模上。人工智慧應用需要專門的模型託管基礎設施，能夠處理AI工作負載的獨特硬體和可擴充套件性要求。

在佈署大型人工智慧應用時，我發現建立專用的GPU叢集對於保持推理延遲在可接受範圍內至關重要。在一個專案中，我們透過實施動態批處理和模型量化技術，將推理成本降低了約40%。

人工智慧應用還納入了持續學習、安全監控和人類反饋，以確保品質和完整性。這些監控系統對於防止模型漂移和確保輸出符合預期標準至關重要。

LLMs：人工智慧應用的推理引擎

大語言模型(LLMs)是人工智慧應用的重要器官，開啟了全新類別的AI驅動系統。這些模型在大量文字資料上訓練，以理解語言、生成類別人文字、回答問題和進行對話。

LLMs透過發布新模型進行持續改進，特點是具有數十億或數萬億引數，增強的推理、記憶和多模態能力。

在我的職業生涯中，我見證了LLM的快速進化。從早期的GPT-2到今天的先進模型，進步是驚人的。在一個內容摘要專案中，我們將最新的LLM與三年前的模型進行了比較，發現新模型不僅產生的摘要更準確，而與能夠處理微妙的連貫的背景與環境線索，這在早期模型中是不可能的。

LLMs作為推理引擎使人工智慧應用能夠:

1. 理解複雜的使用者請求和查詢
2. 在各種情境下生成連貫、連貫的背景與環境相關的回應
3. 執行複雜的推理任務，如分析、總結和創造性寫作
4. 將非結構化資料轉化為可操作的洞見

然而，LLMs也有其侷限性。它們可能產生幻覺（生成看似合理但實際上不正確的訊息），並且對其訓練資料有內在偏見。這就是為什麼在實際應用中將LLMs與外部知識來源整合，如向量資料函式庫於建立既人工智慧又可靠的應用至關重要。

當我在金融科技公司工作時，我們發現純粹依賴LLM回答客戶查詢會導致約15%的回應包含不準確訊息。透過實施檢索增強生成(RAG)系統，我們將這一比率降低到不到2%，同時保持了回應的自然流暢性。

人工智慧應用的建構元素不僅是技術元件，而是一個協同工作的完整系統，使應用能夠理解、推理和適應。隨著這些技術的不斷發展，我們將看到人工智慧應用在各行各業開啟新可能性。

生成式AI和人工智慧應用的結合正在重塑我們與技術互動的方式。作為開發人員，理解這些建構元素如何協同工作以建立動態、連貫的背景與環境感知的體驗，將使我們能夠構建下一代人工智慧系統。

在建立人工智慧應用時，關鍵是平衡技術能力與使用者需求，確保這些系統不僅聰明，而與有用、可靠和可信。透過掌握本文討論的建構元素，開發者可以開始探索

大語言模型：人工智慧應用的推理引擎

大語言模型(LLM)已經成為人工智慧系統中強大的通用技術，它在AI系統中的角色類別似於傳統計算中的中央處理器(CPU)。就如同CPU是可以為多種任務程式設計的通用計算引擎，LLM也在根據語言的推理和生成中扮演著類別似的角色。LLM的通用性使開發者能夠將其應用於廣泛的推理任務。

LLM推理引擎的應用技術

隨著LLM的發展，多種利用其多樣能力的技術也隨之出現：

提示工程的藝術

提示工程（Prompt Engineering）是透過精心設計的提示來引導LLM執行各種語言任務。這種技術最大的優勢在於其迭代性質—由於提示本質上只是文字，開發者可以快速嘗試不同提示並觀察結果。

在我開發客戶服務AI助手時，發現進階提示技術能夠顯著提升模型回應的品質：

• 思維鏈提示：鼓勵模型將推理過程分解為一系列步驟，使其「思考」過程更加透明
• 多樣例子提示：向模型提供多個輸入/輸出對作為範例，增強模型理解任務的能力

微調：針對性強化

微調涉及從預訓練的通用模型開始，在與目標任務相關的較小資料集上進一步訓練。這通常比單純的提示工程產生更好的結果，但也有一定的成本和時間投入。

玄貓建議只有在充分利用提示工程後仍無法達到目標時才考慮微調。我曾協助一家法律科技公司微調LLM處理合約檔案，雖然花費了更多資源，但在專業領域的表現確實比一般提示工程更為出色。

檢索增強生成

檢索增強生成（Retrieval Augmentation）將LLM與外部知識連線，使其能夠利用最新的、領域特定的訊息。在這種方法中，從知識函式庫索相關訊息並注入到提示中，使LLM能夠生成與連貫的背景與環境相關的輸出。

檢索增強緩解了LLM靜態預訓練的侷限性，保持知識的更新，並降低模型產生錯誤訊息的可能性。這在構建需要處理特定領域最新資訊的應用時尤為重要。

LLM的多元能力

雖然本質上只是語言模型，但LLM展現出了令人驚訝的湧現能力。截至2024年春季，最先進的語言模型能夠執行以下類別的任務：

文字生成與完成

LLM能夠生成連貫的文字續寫，這使它們在內容建立、文字摘要和程式碼補全等任務中非常有用。我在開發技術檔案自動化工具時，發現代LLM能夠根據簡短的技術規範生成詳細與準確的API檔案。

開放式對話與聊天

LLM能夠進行來回對話，保持連貫的背景與環境並處理開放式使用者查詢和後續問題。這一能力是聊天機器人、虛擬助手、輔導系統等應用的基礎。

問答能力

LLM能夠直接回答使用者問題，執行研究，並綜合訊息以解決查詢。這種能力使其成為客戶支援和知識管理系統的理想選擇。

分類別與情感分析

LLM能夠將文字分類別為預定義的類別，並評估情緒、情感和意見。這使得內容審核和客戶反饋分析等應用成為可能。

資料轉換與提取

LLM能夠將非結構化文字對映為結構化格式，並提取關鍵訊息，如命名實體、關係和事件。這使LLM在資料挖掘、知識圖譜構建和機器人流程自動化(RPA)等任務中非常有價值。

隨著LLM規模和複雜度的不斷增長，新的能力不斷湧現，常以令人驚訝的方式出現，這些能力並非由原始訓練目標直接預期的。

例如，GPT-3生成功能性程式碼的能力就是一個意外的發現。隨著LLM領域的進步，我們可以期待看到更令人印象深刻和多功能的能力出現，進一步擴大人工智慧應用的潛力。

多模態語言模型的拓展

多模態語言模型在擴充套件語言模型能力方面具有特殊的前景。這類別模型除了處理文字外，還能處理和生成影像、語音和影片，已成為人工智慧應用的重要組成部分。

多模態模型使以下新應用類別成為可能：

• 根據多種輸入類別建立內容：例如，使用者可以同時提供影像和文字作為輸入的聊天機器人
• 高階資料分析：如分析X光片和醫療記錄的醫療診斷工具
• 實時翻譯：將一種語言的音訊或影像翻譯成另一種語言

這些例子突顯了多模態語言模型如何擴充套件語言模型的可能使用案例。

AI開發的正規化轉變

LLM的崛起代表了AI應用開發的正規化轉變。以前，許多推理任務需要專門訓練的模型，這些模型的建立往往耗時與計算成本高昂，通常需要專業的機器學習工程團隊。

相比之下，LLM的通用性使大多數軟體工程師可以透過簡單的API呼叫和提示工程來利用它們的能力。雖然最佳化根據LLM的工作流程以便於生產佈署仍然需要一定的技巧，但與傳統的機器學習方法相比，這個過程明顯更快速、更易於使用。

這種轉變大降低了AI應用的總體擁有成本和開發時間。以前可能需要一個複雜的機器學習工程團隊數月工作的NLP任務，現在可以由一個有LLM API存取許可權和一些提示工程技能的軟體工程師實作。

此外，LLM還開啟了以前不可能或不實際開發的全新應用類別。LLM理解和生成類別人文字、進行開放式對話和執行複雜推理任務的能力，為各行業的人工智慧應用開創了廣泛的可能性。

嵌入模型與向量資料函式庫義長期記憶

除了LLM提供的推理能力外，人工智慧應用還需要語義長期記憶來儲存和檢索訊息。

語義記憶通常由兩個核心元件組成——AI向量嵌入模型和向量資料函式庫量嵌入模型將非結構化資料（如文字或影像）的語義含義表示為大型數字陣列。向量資料函式庫地儲存和檢索這些向量，支援語義搜尋和連貫的背景與環境檢索。這些元件協同工作，使推理引擎能夠根據需要存取相關連貫的背景與環境和訊息。

嵌入模型的關鍵作用

嵌入模型是將文字和其他資料類別（如影像和音訊）對映到高維向量表示的AI模型。這些向量表示捕捉了輸入資料的語義含義，允許進行高效的相似性比較和語義搜尋，通常使用餘弦相似度作為距離度量。

嵌入模型將語義含義編碼為機器可解釋的格式。透過將相似概念表示為向量空間中的相鄰點，嵌入模型使我們能夠測量非結構化資料之間的語義相似性，並在大型語料函式庫行語義搜尋。

預訓練的嵌入模型廣泛可用，並可以針對特定領域或使用案例進行微調。與LLM相比，嵌入模型通常更經濟實惠，可以在有限的硬體上執行，使其對更廣泛的應用更加可行。

嵌入模型的一些常見應用包括：

• 語義搜尋與檢索：嵌入模型可以作為較大AI系統的元件，為LLM檢索相關連貫的背景與環境，尤其是在RAG架構中。RAG是本章討論的人工智慧應用的一個特別重要的使用案例。

• 推薦系統：透過將專案和使用者偏好表示為嵌入，推薦系統可以識別相似專案並生成個人化推薦。我曾為一家電商平台構建的推薦系統中，使用嵌入模型將使用者行為與產品特性對映到同一向量空間，顯著提升了推薦的相關性。

• 聚類別和主題建模：嵌入模型可以幫助發現大型資料集中的潛在主題和主旨，這對於分析使用者與人工智慧應用的互動非常有用，例如識別聊天機器人中的常見問題。

• 異常檢測：透過識別與常態在語義上距離較遠的異常向量，嵌入模型可以用於各種領域的異常檢測。

• 分析實體間關係：嵌入模型可以根據語義相似性揭示實體之間的隱藏關係和連線。

向量資料函式庫率的語義檢索

向量資料函式庫門為儲存和搜尋高維向量而最佳化的資料儲存。它們提供快速、近似最近鄰(ANN)搜尋能力，使人工智慧應用能夠根據空間鄰近性快速儲存和檢索相關訊息。

ANN搜尋之所以必要，是因為隨著資料函式庫的增長，對資料函式庫個向量執行精確的相似性計算變得計算成本高昂。向量資料函式庫如分層導航小世界(HNSW)等演算法來高效找到近似最近鄰，使向量搜尋在大規模下變得可行。

除了ANN搜尋外，向量資料函式庫還支援對與向量相關的元資料進行過濾和精確搜尋。這些功能的確切功能和效能在不同的向量資料函式庫中各不相同。

向量資料函式庫工智慧應用提供了給定查詢相關訊息的低延遲檢索。使用內容的語義含義進行搜尋，向量資料函式庫LM推理訊息的方式保持一致，使應用能夠為長期記憶應用與推理相同的非結構化資料格式。

在使用RAG的應用中，向量資料函式庫著關鍵角色。應用生成查詢嵌入，用於從向量資料函式庫索相關連貫的背景與環境。然後將多個相關區塊作為連貫的背景與環境提供給LLM，LLM使用這些訊息生成有深度與相關的回應。

在我開發企業知識管理系統時，向量資料函式庫能直接影響了整個系統的回應時間。選擇合適的向量索引演算法和最佳化查詢策略，能夠在保持檢索品質的同時將回應時間從秒級縮短到毫秒級。

模型託管：從理論到實踐的橋樑

要在人工智慧應用中實作AI模型，必須將它們託管在電腦上，可以是資料中心或雲端。這個過程稱為模型託管。與託管傳統軟體相比，為應用託管AI模型提出了一系列不同的要求。大規模執行AI模型需要強大的圖形處理單元(GPU)和設定軟體環境以高效載入和執行模型。

模型託管的關鍵挑戰包括高計算需求和硬體成本、GPU資源的有限可用性、管理和擴充套件託管基礎設施的複雜性，以及使用專有解決方案時可能的供應商鎖定或有限的靈活性。因此，硬體和成本限制必須比以往往更多地納入應用設計過程。

自託管模型的考量

自託管模型是指在組織自己的基礎設施和硬體資源上部

模型託管服務的關鍵優勢與選擇

在構建AI應用系統時，模型託管服務扮演著至關重要的角色。我在多個企業AI專案中發現，選擇合適的託管方式可能決定專案的成敗。模型託管服務不僅是執行模型的基礎設施，更是整個AI應用生態系統中的關鍵環節。

模型託管服務的核心價值

模型託管服務提供了多方面的優勢，使開發團隊能夠專注於核心應用開發：

基礎設施管理最佳化

使用模型託管服務可將硬體和基礎設施管理外包，這點在資源有限的團隊中尤為重要。託管提供商負責處理：

• 資源設定與擴充套件：根據需求自動調整計算資源
• 系統可用性保證：提供高用性和冗餘機制
• 安全防護：實施企業級安全標準和合規措施

我曾為一家金融科技公司實作AI決策系統時，若沒有使用託管服務，僅硬體管理就會耗費團隊近三分之一的資源。

經濟效益與彈性定價

託管服務採用彈性的定價模式，帶來明顯的成本優勢：

• 隨用隨付機制：只為實際使用的資源付費
• 資源彈性調整：可根據業務需求快速擴充套件或縮減
• 降低前期投資：無需大量資本支出購買專用硬體

在一個季節性業務的AI專案中，玄貓採用彈性託管方案，使客戶在低峰期節省了約65%的運算成本。

豐富的模型生態系統

託管提供商通常提供多種先進模型的存取許可權：

• 精選的最新模型：持續整合最新研究成果
• 最佳化與增強：針對原始模型進行效能和功能最佳化
• 多樣化選擇：提供不同規模和專業領域的模型

專業支援與技術指導

優質託管提供商不僅提供基礎設施，還提供全方位的技術支援：

• 模型選擇諮詢：協助選擇最適合特定應用的模型
• 提示工程指導：最佳化模型互動方式
• 架構設計建議：提供應用架構最佳實踐
• 模型微調協助：支援自訂模型訓練和最佳化

快速原型與實驗能力

託管服務大幅加速開發和創新週期：

• 快速測試不同模型：輕鬆比較各種模型的效能
• 靈活適應新發展：在快速發展的AI領域保持競爭力
• 降低實驗門檻：無需深厚的ML專業知識即可進行測試

可擴充套件性與可靠性保障

企業級託管服務提供穩健的基礎設施：

• 高用性架構：確保關鍵AI功能的穩定執行
• 自動擴充套件機制：應對流量波動和使用高峰
• 負載平衡：最佳化資源分配和請求處理

主要模型託管服務提供商

市場上有多種託管服務可供選擇，主要分為兩類別：

1. 模型開發商提供的託管服務：

   • OpenAI
   • Anthropic
   • Cohere

2. 雲端供應商的AI服務：

   • AWS Bedrock
   • Google Vertex AI
   • Azure AI Studio

在選擇託管服務時，我建議根據應用需求、預算、安全要求和團隊技術能力進行全面評估。不同提供商在延遲、成本結構和支援模型種類別上差異顯著，這些因素會直接影回應用的使用者經驗和營運成本。

智慧應用的核心架構元件

有了LLM、向量嵌入模型、向量資料函式庫型託管服務，你已經掌握了構建智慧應用的關鍵元素。實際架構會因應用場景而異，但一個常見的模式已經浮現：

典型智慧應用的組成要素

智慧應用通常由以下核心元件構成：

• 大語言模型：負責推理和內容生成
• 向量嵌入與向量搜尋：提供檢索和記憶功能
• 模型託管服務：支援大規模型執行

這些AI核心元件與傳統應用元素（如後端服務、API、前端介面、資料函式庫料管道）整合，形成完整的應用架構。此外，智慧應用還經常包含特定於AI的功能模組：

• 提示管理與最佳化：管理和改進與模型的互動
• 資料準備與嵌入生成：處理輸入資料並生成適當的表示
• AI安全、測試與監控：確保模型輸出的安全性和品質

在設計智慧應用架構時，玄貓建議從核心功能需求出發，然後逐步整合AI能力，而非試圖將AI強行加入現有系統。

RAG聊天機器人：智慧應用架構案例解析

為了具體說明智慧應用的架構，讓我們以一個根據檢索增強生成（RAG）的檔案聊天機器人為例。這個應用允許使用者與檔案內容進行對話互動。

核心元件與架構

這個聊天機器人應用包含七個關鍵元件：

1. 聊天機器人UI：提供使用者介面的網站
2. Web伺服器：管理使用者與LLM之間對話的Python Flask伺服器
3. 資料擷取轉換載入（ETL）管道：處理和準備資料的Python指令碼
4. 向量嵌入模型：由OpenAI託管的text-embedding-3-small模型
5. 大語言模型：由OpenAI託管的gpt-4-turbo模型
6. 向量儲存：MongoDB Atlas向量搜尋
7. 資料函式庫：用於儲存對話的MongoDB Atlas

關鍵資料流

在這個架構中，有兩個主要的資料流動路徑：

聊天互動流程

聊天互動流程描述了使用者如何與RAG聊天機器人進行溝通：

1. 使用者從網頁UI傳送訊息給聊天機器人
2. Web UI建立包含使用者訊息的請求並傳送給伺服器
3. Web伺服器向嵌入模型API傳送請求，為使用者查詢生成向量嵌入
4. Web伺服器使用查詢向量在向量資料函式庫行向量搜尋
5. 伺服器構建傳送給LLM的訊息，包含系統提示和結合使用者原始訊息與向量搜尋結果的新訊息
6. 伺服器將對話狀態儲存到資料函式庫. 伺服器將LLM生成的回應回傳給Web UI，最終呈現給使用者

這個流程確保了聊天機器人能夠理解使用者的問題，檢索相關資訊，並生成根據檢索內容的回應。

資料擷取管道

資料擷取管道負責準備和豐富資料，它以批次作業形式每24小時執行一次：

1. ETL管道從各種資料來源提取資料
2. 管道清理資料並將其轉換為一致的格式，同時將資料分割成適當大小的片段
3. 管道呼叫嵌入模型API為每個資料片段生成向量嵌入
4. 管道將資料片段及其向量嵌入儲存在向量資料函式庫5. 向量資料函式庫入進行索引以用於向量搜尋

從原型到生產的挑戰

雖然這種簡單架構可用於構建引人入勝的原型，但要將其轉變為生產級應用並持續迭代，還需要解決多項額外考量：

資料擷取策略最佳化

需要制定全面的資料擷取策略，包括：

• 資料取得、清理和準備的自動化流程
• 資料更新機制和增量處理能力
• 資料品質監控和異常檢測

進階檢索模式

為提高檢索準確性和效率，可考慮整合：

• 語義搜尋與傳統過濾的結合
• 根據AI的重排序機制
• 查詢變異和擴充套件技術

在一個法律檔案分析系統中，玄貓透過實施混合檢索策略，將相關檔案的檢索準確率提高了32%。

評估與測試機制

完善的評估框架應包括：

• 模型輸出評估模組
• 端對端應用流程測試
• 潛在偏見或錯誤的監控系統

可擴充套件性與效能最佳化

為確保應用在負載增加時保持回應性，需實施：

• 快取機制和結果重用
• 負載平衡和資源管理
• 批處理和非同步處理策略

安全與隱私保障

必須確保：

• 使用者只能與其有許可權的資料互動
• 使用者資料按照相關政策、標準和法律處理
• 實施適當的加密和資料保護措施

使用者經驗與互動設計

生成式AI介面需考慮新的互動模式：

• 串流式回應機制
• 答案信心度指示
• 來源參照和透明度

持續改進與模型更新

建立流程和系統以：

• 安全可靠地更新AI模型
• 最佳化應用中的超引數
• 收集使用者反饋並持續改進

智慧應用對軟體工程的影響

智慧應用的興起對軟體開發方式產生了深遠影響。開發這類別應用需要擴充套件傳統開發技能，AI工程師必須具備：

新技能與知識領域

• 提示工程：設計有效的模型互動方式
• 向量搜尋：理解和最佳化語義檢索
• 評估方法：衡量AI輸出的品質和適用性
• AI架構：熟悉最新AI技術和架構模式

雖然不需要完全理解底層神經網路，但基本的自然語言處理知識會非常有幫助。

新挑戰與考量

智慧應用開發還引入了新的挑戰：

• 資料管理與AI整合：處理大量非結構化資料並整合AI元件
• AI功能測試與除錯：測試和除錯AI驅動功能的複雜性
• 倫理、安全與安全性：解決AI輸出的倫理、安全和安全性問題
• 計算密集型工作負載：關注可擴充套件性和成本最佳化

傳統軟體開發者通常不需要面對這些挑戰。

軟體開發流程的調整

為應對這些挑戰，軟體開發團隊必須調整流程並採用新方法：

• 實施AI治理：建立AI開發和佈署的治理框架
• 橋接軟體和ML/AI團隊：促進跨團隊協作和知識分享
• 調整開發生命週期：適應智慧應用的特殊需求

玄貓在與多家企業合作時發現，成功的AI團隊往往採用混合敏捷方法，結合了傳統軟體開發的迭代性與AI開發的實驗性。

智慧應用的基礎架構

智慧應用代表軟體開發的新正規化，將AI與傳統應用元件結合，提供高度個人化、情境感知的體驗。智慧應用的核心元件包括：

推理引擎：大語言模型

LLM作為推理引擎，是智慧應用的中樞。由於其通用設計，LLM能夠執行多種任務，包括聊天、摘要和分類別。這種多功能性使其成為智慧應用的理想計算工具。

語義記憶：嵌入模型與向量資料函式庫嵌入模型和向量資料函式庫智慧應用的語義記憶，使推理引擎能夠在需

大語言模型的機率基礎與運作機制

在我多年開發AI系統的經驗中，理解大語言模型(LLM)的底層原理是構建高效AI應用的關鍵。無論是開發聊天機器人、內容生成系統或智慧助理，掌握LLM的機率框架都能讓你更有效地調整引數並最佳化應用表現。本文將帶你深入探索LLM的數學基礎和技術架構。

技術需求與準備

若想跟著本文實作，你需要:

• Python 3.8或更新版本
• 熟悉Python和pip套件管理器
• 基本的機率、微積分知識
• 軟體開發概念如API的基礎理解

雖然本章主要理論導向，但我會提供簡短的Python程式碼來說明tiktoken分詞工具的使用。

語言模型的機率框架

在開發與LLM互動的應用時，你很可能會遇到與token機率相關的API引數。理解LLM如何運用機率是掌握其運作機制的關鍵。

為何語言模型採用機率視角

語言模型通常採取機率視角而非絕對確定性的方式運作。這種設計讓演算法能夠處理自然語言中常見的不確定性和歧義性。

讓我舉個例子來建立對機率語言建模的直觀理解。假設有一個句子的開頭，你想預測下一個詞：

The

這顯然是個有多種可能答案的模糊任務。英文中冠詞"the"是非常見與通用的詞，後續可能性幾乎無限。任何名詞如house、dog、spoon等都可能是有效的句子延續。甚至形容詞如big、green、lazy也是可能的候選詞。相反地，某些詞很少出現在冠詞之後，包括動詞如eat、see和learn。

處理這類別不確定性時，我們可以改問一個略有不同的問題：「每個詞作為下一個詞出現的機率是多少？」

這個問題的答案不再是單一詞彙，而是一個龐大的查詢表，為詞彙表中的每個詞分配一個數值，代表該詞緊跟在"the"之後的機率。如果這個查詢表能代表英語的使用情況，我們會預期名詞和形容詞的機率高於動詞。下表展示了這樣一個查詢表可能的樣子（使用虛構的機率值）：

在這個簡單例子中，決定下一個詞的方法之一（但不是唯一方法）是瀏覽此查詢表並找出機率最高的詞。這種方法稱為貪婪選擇(greedy selection)，會建議"dog"是最可能的句子延續。

不過，重要的是註意到有許多可能性，每個都有不同機率。例如，“house"在機率上也是接近的第二名，表示它也可能是句子的合理延續。

為了捕捉自然語言的靈活性和表達性，語言模型以機率方式運作，而訓練語言模型的過程就是為每個可能延續當前句子的詞分配機率。

連貫的背景與環境如何改變預測

假設你已經過多次選詞過程，現在句子進展到：

The quick brown fox jumps over the

這個句子如何繼續？現在的機率分佈是什麼樣子？

如果你熟悉這個句子（這是個包含所有英文字母的全字母句，常用於打字練習和測試文字顯示），你會同意此時"lazy"的機率會遠高於其他詞。你的內部語言模型會自動完成整個句子，“lazy dog"這幾個詞會自然浮現在腦海。

為什麼會這樣？難道你不是和之前一樣，詢問"the"之後接什麼詞嗎？關鍵區別在於你現在有更多連貫的背景與環境；你看到了更多的句子部分，這表明僅考慮前一個詞不足以良好預測下一個詞。

然而，這個基本概念標誌著語言模型的最初起點，可以視為現代大語言模型（如ChatGPT等）的遙遠祖先。

n-gram語言模型

語言模型最早的形式化之一是n-gram模型，一種簡單的統計語言模型，首次發表於1948年Claude Shannon的著名論文《通訊的數學理論》。

n-gram語言模型可以描述為一個巨大的查詢表，模型考慮最後n-1個詞來預測下一個詞。對於n=2，你得到所謂的二元語法(bigram)模型，只回顧一個詞，如前面的表格所示。

正如前面的例子所示，這種簡單的二元語法模型有限，無法捕捉自然語言的細微差別。不過，在探討當n擴大到更大值時會發生什麼之前，讓我們簡要討論如何訓練二元語法模型，也就是如何計算表格中每對詞的機率：

1. 取一個大型文字語料函式庫如所有英文維基百科頁面的集合。
2. 掃描這些文字，計算單個詞的出現次數以及觀察到的詞對。
3. 在查詢表中記錄所有計數。
4. 計算詞A跟隨詞B的機率：將詞對計數除以單詞B的計數。

例如，要計算"dog"跟隨"the"的機率，按以下方式將詞對計數除以單詞計數：

P(dog|the) = Count(the dog) / Count(the)

這裡，P(dog|the)讀作「在給定the的情況下dog的機率」。換句話說，在剛看到"the"的情況下看到"dog"的機率是看到這兩個片語合的計數（分子）除以看到單獨"the"的所有計數（分母）。

因此，n-gram語言模型的訓練過程只需對文字進行一次掃描，計算所有出現的n-gram和(n-1)-gram，並將數字儲存在表格中。

在實踐中，有幾種技巧可以提高n-gram模型的品質，例如在每個句子的開始和結束處包含特殊的和標記，將詞分割成更小的子詞，如將"playing"分為"play"和”-ing"等。我將在後面的「分詞」部分回顧其中一些技術，它們也適用於現代LLM。

n-gram模型的侷限性

讓我們重新審視n的選擇。如你所見，較低的值，如n=2，不會產生一個非常好的語言模型。那麼，是否只是將n擴大到達到所需品質水平的問題呢？

較大的n值可以捕捉更多連貫的背景與環境並產生更具預測性的模型。對於n=8，模型可以回顧最後七個詞。查詢表會包含捕捉範例句子的行：

然而，將n增加到較大值面臨幾個挑戰，使這種方法在實踐中不可行。

查詢表的大小隨著較大的n呈指數增長。牛津英語詞典包含約273,000個英語單詞，這允許747.5億種兩個詞的可能組合（儘管許多組合在文字中永遠不會出現）。將n-gram模型增加到n=8，八個詞的可能組合增長到天文數字273,000^8。為每個組合在表格中儲存一個條目是不可能的，因為這個數字遠超過世界上所有可用的硬碟儲存空間，特別是考慮到世界的集體資料估計到2025年將達到175澤位元組（10^21位元組）。當然，大多數片語合永遠不會被遇到，你可以選擇在表格中省略未見的n-gram。

這個挑戰，被稱為稀疏性問題(sparsity problem)，突顯了n-gram模型的真正問題。隨著n的增長，遇到任何一個n-gram的機率呈指數下降。對於任何現實大小的訓練資料集，大多數n個詞的組合永遠不會被遇到。處理不屬於訓練語料函式庫字時，模型會為未見的n-gram分配零機率。在這種情況下，模型將無法做出有意義的預測，而與問題會隨著n變大而加劇。

總之，雖然n-gram對某些狹窄應用和教育目的有用，但今天的語言模型已經超越了純統計方法。LLM使用機器學習技術來處理上述一些問題，我將在下一節中介紹。

機器學習在語言模型中的應用

在探討使用ML的語言建模方法之前，我先介紹一些一般ML概念，並對不同神經網路架構進行高層次概述。

機器學習的基本概念

本質上，ML是一個關注開發和研究從資料中學習的演算法的領域。系統不是執行硬編碼規則，而是預期透過範例學習，檢視提供的輸入和期望的結果（在ML文獻中通常稱為目標），並在訓練過程中調整其行為，以使其輸出與使用者提供的目標相似。

ML演算法粗略分為三組：

• 監督學習
• 無監督學習
• 強化學習

每組有不同的學習目標和問題表述。對於語言建模，你主要考慮監督（和相關的自監督）演算法。

人工神經網路

監督學習演算法的一類別是人工神經網路(ANNs)。所有現代LLM都是基本ANN架構的變體。當你向GPT-4等模型發出API呼叫時，你的問題透過ANN流動以產生答案。這些模型在幾十年間在大小和複雜性上有所演變，但核心原則和構建塊仍然相同。

雖然人腦中的神經架構可能啟發了ANN的原始設計，但ANN與其生物對應物有顯著不同。

ANN由許多稱為神經元的較小單元組成，根據網路架構，它們以各種模式相互連線。每個神經元是一個小處理單元，接收來自其他神經元的數值訊號並將（修改的）訊號傳遞給其後繼神經元，類別似於生物神經元。ANN有可調引數，稱為權重，位於兩個神經元之間的連線上，可以影響它們之間傳遞的訊號。

前饋神經網路架構

最基本的ANN架構之一是所謂的前饋網路(FFN)。在這種架構中，神經元按層排列，從輸入層開始，然後是一個或多個隱藏層，最後是輸出層。層大小（指每層的神經元數量）可以變化。輸入和輸出層的大小由特定問題領域決定。例如，你可能想要學習從二維輸入（比如一個人的體重指數和年齡）到一維輸出（比如每日休息時燃燒的卡路里）的對映。隱藏層的大小通常是透過實驗在稱為超引數調整的過程中任意選擇的。

在FFN中，一層中的每個神經元連線到下一層中的所有神經元，導致兩個連續層之間的多對多關係。前饋網路通常有一個輸入層、多個隱藏層和一個輸出層。

這種神經網路架構為現代語言模型奠定了基礎，但要

神經網路的核心架構與運作機制

在深入研究語言模型之前，我們必須先理解支撐這些模型的基礎—神經網路。前饋神經網路（Feed-forward Neural Network）是最基本的神經網路架構，由輸入層、隱藏層和輸出層組成。

在我多年開發智慧系統的經驗中，神經網路的魅力在於它能透過簡單元件的複雜連線來解決困難問題。每個神經元雖然只執行簡單的數學運算，但當成千上萬個神經元協同工作時，就能展現驚人的模式識別能力。

神經元：智慧系統的基本單位

讓我們放大檢視單一神經元的運作方式。想像一個接收兩個輸入（z₁和z₂）的神經元，每個連線都有對應的權重（w₁和w₂）。神經元的處理流程如下：

1. 將每個輸入與其對應的權重相乘
2. 將所有乘積加總
3. 將總和傳遞給非線性啟用函式
4. 產生輸出（z₃）

用數學表示為：

z₃ = 啟用函式(w₁ × z₁ + w₂ × z₂)

非線性啟用函式在這裡扮演關鍵角色。在我設計早期語音識別系統時，發現若沒有這種非線性轉換，無論網路有多深，都只能表達線性關係，這大限制了模型的學習能力。

從單一神經元到複雜網路

當數百萬個神經元組成網路時，它們能執行複雜的運算。舉例來說，在預測一個人根據BMI和年齡的卡路里消耗時，輸入層接收這兩個數值，經過多個隱藏層的處理後，輸出層產生預測結果。

你可能會好奇，為何這些簡單的神經元能產生如此強大的模式識別能力？這歸功於通用近似定理（Universal Approximation Theorem）。這個定理證明，只要有足夠的隱藏層和神經元，神經網路可以任意精確度近似任何連續函式。

神經網路訓練的三大階段

當我們構建一個神經網路模型時，初始權重是隨機設定的，因此未經訓練的模型輸出基本上是無意義的。訓練過程旨在調整這些權重，使模型能夠產生符合預期的輸出。

在我為金融科技公司開發風險評估模型時，發現神經網路訓練過程可分為三個關鍵階段：

1. 前向傳播：從輸入計算輸出

前向傳播是將輸入資料傳遞給網路，計算每層的啟用值，最終產生輸出的過程。例如，當模型接收一個人的BMI和年齡作為輸入時，它會依序計算每一層的啟用值，直到輸出層產生預測的卡路里消耗量。

2. 損失計算：測量預測與實際的差距

模型的輸出與正確目標之間的差距被量化為損失值。這個單一數值反映了模型預測的準確程度。損失值越低，表示模型預測越接近實際值。

3. 反向傳播與權重調整：最佳化模型引數

反向傳播是訓練的核心。這個階段會計算每個權重對損失的影響（即梯度），然後根據這些梯度調整權重，使模型在下次預測時能產生更接近目標的輸出。

透過微積分中的鏈式法則，誤差訊號從輸出層反向傳播到所有先前的層，讓每個權重都能朝著減少損失的方向調整。

批次處理的優勢

在實務上，我們通常不會一次處理一筆資料，而是將訓練資料分成小批次（batch）。批次大小是另一個需要透過超引數調整實驗確定的值。批次處理有兩大優勢：

1. 效率提升：批次可以在特殊硬體（如GPU）上平行處理，大幅提高訓練速度
2. 穩定性增強：反向傳播的誤差梯度會在每個批次中取平均，使單一異常值對權重變更的影響較小

訓練會持續進行，直到模型在未見過的驗證資料上不再有改善為止。訓練完成後，模型就可以應用於新的輸入資料，這個過程稱為推論（inference）。

將自然語言轉換為神經網路可處理的形式

上述訓練程式是每個神經網路（包括大語言模型）的核心。由於神經網路只能處理數值資料，我們需要一種方法將語言表示為數值形式。

在開發玄貓的第一個文字分析系統時，我遇到了三個主要挑戰：

1. 輸入是離散的單詞：神經網路需要數值輸入，因此需要一種將單詞對映為數字的方法
2. 輸入是序列性的：與二元語法模型不同，語言模型需要考慮多個單詞來預測下一個單詞
3. 輸出需要是機率分佈：語言模型的輸出需要是所有可能的下一個單詞的機率分佈

標記化：文字到數字的轉換

將文字轉換為數值輸入的第一步是標記化（tokenization）。在這個階段，文字會被分割成常見的子詞、字元和標點符號，形成標記詞彙表。每個標記都會被賦予一個唯一的整數ID。

當使用大語言模型時，特別是自行託管的開放原始碼模型，選擇正確的標記器非常重要，它必須與模型訓練時使用的標記器完全比對。幸運的是，有許多常見的開放原始碼標記器可供使用。即使是商業LLM提供商，如OpenAI，也開放原始碼了他們的標記器函式庫與他們的模型互動變得更容易。

OpenAI的tiktoken函式庫多流行程式語言的繫結，包括Python、C#、Java、Go和Rust。以下是使用Python的tiktoken函式庫例：

import tiktoken

# 建立編碼器
encoder = tiktoken.get_encoding("cl100k_base")  # 這是GPT-4使用的編碼器

# 對文字進行標記化
text = "tiktoken是一個流行的標記器！"
tokens = encoder.encode(text)

print(f"標記ID：{tokens}")

# 解碼每個標記
for token in tokens:
    print(f"標記ID {token}: {encoder.decode([token])}")

在這個範例中，我們先建立一個編碼器，然後用它來將文字轉換成標記ID列表。最後，我們解碼每個標記ID，檢視它們代表的實際文字片段。

標記化技術的選擇對模型效能有顯著影響。在我開發多語言處理系統時，發現子詞標記化（如BPE、WordPiece）比單詞級或字元級標記化更有效，因為它能更好地平衡詞彙表大小和處理罕見詞的能力。

神經網路與自然語言處理的結合

神經網路為自然語言處理帶來了革命性的變革。透過將語言轉換為神經網路可處理的數值形式，我們能夠開發出越來越強大的語言模型。

這種方法的關鍵在於找到合適的表示方式，使神經網路能夠捕捉語言的複雜模式。從最初的詞袋模型到現代的連貫的背景與環境嵌入，語言表示技術的演進與神經網路架構的發展相輔相成。

語言模型的進步不僅改變了我們與電腦互動的方式，也深刻影響了我們理解人類語言的方法。當我們繼續探索神經網路與語言處理的交叉領域時，可以期待更多令人興奮的突破。

在語言模型的發展歷程中，我們看到了從簡單的統計模型到複雜的神經網路架構的演進。這個過程不僅展示了技術的進步，也反映了我們對語言本質理解的深化。透過不斷探索和創新，語言模型將繼續拓展人工智慧的邊界，為更多領域帶來變革性的影響。

深入理解大語言模型的技術原理與核心機制

語言模型的核心：標記化處理

在建構現代語言模型時，文字資料必須經過數值化處理才能被神經網路理解。這個過程的第一步是標記化（Tokenization），它將文字分解成更小的單位稱為標記（tokens）。

標記化是將文字轉換為語言模型能理解的數值形式的關鍵步驟。以GPT-4使用的cl100k_base分詞器為例，我們可以看到這個處理過程：

# 使用GPT-4的cl100k_base分詞器
encoder = tiktoken.get_encoding("cl100k_base")
token_ids = encoder.encode("tiktoken is a popular tokenizer!")
print("Token IDs", token_ids)
tokens = [encoder.decode_single_token_bytes(t) for t in token_ids]
print("Tokens", tokens)

執行後的輸出結果：

Token IDs [83, 1609, 5963, 374, 264, 5526, 47058, 0]
Tokens [b't', b'ik', b'token', b' is', b' a', b' popular', b' tokenizer', b'!']

這個例子顯示了幾個關鍵特點：

• “tiktoken"這個詞被分解為三個標記：’t’、‘ik’和’token’，因為這個詞在詞彙表中不夠常見
• 空格常被編碼為標記的一部分，通常位於開頭，例如” is”
• 每個標記都被轉換為唯一的數字ID，便於神經網路處理

在使用API與專有模型互動時，標記化通常在伺服器端自動進行，因此開發者可以直接提交文字形式的提示而無需自行標記化。然而，tiktoken等工具在構建AI應用時仍然非常有用，例如：

• 計算請求的標記數量，因為API通常按提交和回傳的標記數量收費
• 確保不超過語言模型的輸入上限（連貫的背景與環境視窗大小）

嵌入：從標記到向量空間

雖然標記ID是數值，但這些數字的分配是任意的，神經網路無法直接從中理解語義。因此，下一步是嵌入（Embedding）過程，將這些整數轉換為高維浮點數向量。

嵌入是將資料對映到高維向量空間的過程，不僅對語言模型的訓練至關重要，也是向量資料函式庫檢索語義相似專案的基礎。嵌入可以為任意資料實體建立：單詞、句子、整個檔案、影像，甚至是使用者或產品等更抽象的概念。

嵌入具有雙重目的：

1. 提供固定長度的浮點數表示，非常適合神經網路處理
2. 在向量空間中表示坐標，透過適當的訓練，可以透過幾何接近度表示資料實體之間的語義相似性

在實際操作中，嵌入矩陣包含n行d列，初始化為隨機浮點數。其中n是詞彙表大小，d是嵌入維度。要取得標記的坐標，使用標記ID作為嵌入矩陣的行索引，回傳d維向量。例如，標記"fox"可能被分配以下坐標：[-0.241, 1.356, -0.7882]。

這些嵌入矩陣的值與神經網路的權重類別似，最初是隨機分配的，但在訓練過程中會被視為可學習引數。透過允許梯度流回嵌入層，模型可以更新標記坐標的位置，以幫助預測任務。研究表明，在完全訓練的嵌入層中，模型會將語義相似的標記聚集在一起。

大語言模型使用維度更高的向量空間，通常是數百甚至數千維。在這種高維空間中，標記可以多種方式相互關聯。雖然某些維度可能具有可解釋的含義（如詞的情感），但大多數維度可能只對模型內部有意義。

預測機率分佈

語言模型需要輸出下一個標記的機率分佈，即為詞彙表中的每個標記提供一個數值。透過選擇與詞彙表大小比對的輸出層大小，神經網路將提供正確的輸出形狀，但這些數字理論上可以是任何實數，包括負數或非常大的正數。

要形成適當的機率分佈，輸出必須滿足兩個條件：

• 輸出必須是非負的
• 輸出總和必須等於1.0

為此，模型使用一個稱為softmax的特殊啟用函式，專為輸出層設計，當期望輸出機率時使用：

softmax函式的直觀理解是，分子中的指數函式將範圍從負無窮到正無窮對映到非負數範圍。透過除以所有指數的總和，將值標準化，確保輸出的總和正好等於1。

訓練模型的目標也需要包含相同長度的向量（每個標記一個值）。由於每步標記序列中的下一個詞是已知的，可以使用獨熱編碼（one-hot encoding）編碼正確的標記。為正確標記的位置分配值1.0，為所有其他位置分配0.0。這確保在反向傳播過程中，看到正確下一個標記的機率增加，而所有其他機率減少。

處理序列資料：從RNN到Transformer

為了生成良好的下一個標記預測，語言模型需要能夠考慮相當大的連貫的背景與環境，回溯許多單詞甚至句子。這在處理代詞和指代時尤為重要，因為代詞可能指的是前面句子中出現的實體。

考慮以下文字： “A solitary tiger stealthily stalks its prey in the dense jungle. The underbrush whispers as it attacks, concealing its advance toward an unsuspecting fawn.”

在這個例子中，第二句包含兩個代詞"it"和"its"，都指的是前一句中的老虎。但如果沒有看到第一句，你可能會認為"it"指的是灌木叢，這將導致完全不同的句子結尾。

這表明長距離連貫的背景與環境對語言建模和下一個標記預測很重要。然而，前饋神經網路（FFN）架構是無狀態的，不具備先前輸入的記憶。它不適合處理序列任務，其中未來的標記依賴並參照先前的標記。

迴圈神經網路（RNNs）

迴圈神經網路（RNNs）是一類別處理序列資料的神經網路。與FFN不同，RNN包括從神經元到自身和同層相鄰神經元的連線。這些迴圈連線使模型具有內部狀態，先前的啟用可以迴圈流動並在處理下一個輸入時保留在網路中。

然而，RNN的一個限制是梯度在每次透過迴圈連線的迭代中迅速減小。網路傾向於忘記超過幾個時間步的啟用，這個問題被稱為梯度消失問題。

為瞭解決這個問題，提出了進一步的架構變化，包括長短期記憶（LSTM）和門控迴圈單元（GRU）網路。在這些模型中，引入了由多個神經元組成的單元，可以在數千個時間步內捕捉梯度訊號，從而緩解梯度消失問題。

但RNN仍有其侷限性。迴圈網路的訓練沿時間維度順序進行，這意味著每個時間步都需要透過網路進行單獨的前向和後向傳播，這顯著減慢了長序列的訓練速度。

Transformer架構

2017年，Google發表了一篇名為《Attention Is All You Need》的論文，介紹了Transformer架構，它摒棄了迴圈連線的概念，而是依靠注意力機制來考慮先前的標記。這一發現開創了機器學習和自然語言處理領域的重大轉變，為幾乎所有現代LLM奠定了基礎。

Transformer相較於迴圈網路的優勢包括：能夠平行處理序列、長序列的計算複雜度降低，以及對長距離依賴關係的卓越處理能力。

原始的Transformer模型由兩個元件組成：編碼器和解碼器。這種架構最初是為語言翻譯而提出的，輸入序列由編碼器處理，輸出序列由解碼器處理。

現代的生成式模型，包括OpenAI的GPT系列、Meta的Llama、Anthropic的Claude和Google的PaLM模型，都將語言建模框架為下一個標記預測，學習任務是序列到單個標記的對映。這允許使用更簡單的架構，僅使用Transformer的解碼器部分。

透過這種革命性的架構，大語言模型能夠更好地理解語言的長距離依賴關係，為後續的模型發展奠定了堅實的基礎。

深入理解語言模型的內部機制

大語言模型的核心是標記化處理、嵌入向量轉換、機率分佈預測以及序列處理能力。在玄貓多年的AI系統開發經驗中，理解這些基本原理對於有效利用和最佳化語言模型至關重要。

標記化過程看似簡單，但它對模型理解和生成文字的能力有著深遠影響。嵌入向量則是連線離散標記與連續語義空間的橋樑，使模型能夠捕捉詞彙之間的複雜關係。而Transformer架構的出現徹底改變了處理序列資料的方式，為現代大語言模型的發展奠定了基礎。

作為開發者，我們需要理解這些技術細節，才能更好地設計提示、最佳化模型輸出，並在實際應用中充分發揮語言模型的潛力。隨著技術的不斷發展，我們可以期待看到更多創新的架構和方法，進一步推動自然語言處理領域的進步。

轉換器與大語言模型實務

處理序列資料的轉換器機制

轉換器（Transformer）模型的核心功能在於其處理序列資料的獨特方式。不同於傳統前饋神經網路（FFN）僅由全連線層組成，轉換器的編碼器和解碼器都包含多層「轉換器區塊」，每個區塊中都有注意力層先於全連線層。

注意力機制的關鍵作用

注意力層的主要目的是學習在處理當前詞元時，序列中哪些已見詞元最為相關。這種機制會對連貫的背景與環境中高度相關的詞分配高注意力權重，而對通用或不相關詞分配低注意力權重。

以下面兩個句子為例，它們只有最後一個詞不同：

• 「The cat eats food because it is hungry」(貓吃食物是因為牠餓了)
• 「The cat eats food because it is tasty」(貓吃食物是因為食物很美味)

在第一個句子中，模型會對與「hungry」相關的詞（如「cat」）給予更多注意力；而在第二個句子中，模型則會對與「tasty」相關的詞（如「food」）給予更多注意力。

這種注意力機制是轉換器的核心。具有里程碑意義的轉換器架構論文證明，單憑這種機制就能解決序列資料問題，無需在架構中引入遞迴連線。

大語言模型的實務應用

LLM 領域的快速演變

生成式 AI 和 LLM 是一個快速變化的領域，新模型、框架和研究論文頻繁發布。雖然訓練 LLM 的大部分知識已經公開，但撰寫本文時，從零開始訓練一個最先進的 LLM 的成本仍在數千萬到數億美元之間，這主要是因為需要大量 GPU 計算資源。

這種高昂成本使個人和大多數小型公司無法自行訓練模型，他們必須依賴預訓練的 LLM。目前最強大的模型如 OpenAI 的 GPT-4o 和 Anthropic 的 Claude 3.5 Sonnet 仍然是閉源的，但可以透過 API 以每個詞元計費的方式存取。開放原始碼模型如 Meta 的 Llama 3 在常見基準測試上仍然落後，但差距正在迅速縮小。

開放原始碼與閉源模型的選擇考量

在選擇 LLM 時，需要考慮多種因素：

1. 成本效益：根據使用場景和吞吐量需求，自託管開放原始碼模型或選擇託管服務可能更具成本效益
2. 安全性與合規性：商業 LLM 通常提供內容審核端點，過濾非法請求和有害內容
3. 技術支援：商業模型通常附帶技術支援和詳細檔案
4. 供應商鎖定：開放原始碼模型提供更多靈活性和定製性，避免潛在的供應商鎖定
5. 透明度：開放原始碼模型提供更高的透明度和與其他模型的互操作性

提示工程、微調和檢索增強生成

LLM 接受文字提示作為輸入，但簡單的提示可能無法達到應用程式所需的結果。有幾種策略可以應對這種情況：

1. 提示工程策略： 提示 LLM 更像是一門藝術而非嚴格的科學，這導致「提示工程師」成為軟體開發中的新角色。常見技術包括零樣本和少樣本提示，以及思維鏈提示。

2. 模型微調： 預訓練的 LLM 可以透過微調在特定資料上進一步訓練，使模型適應特定領域知識和回應風格。然而，這個過程可能很昂貴，與微調後的模型需要仔細評估，以避免過度擬合影響模型在其他任務上的表現。

3. 檢索增強生成（RAG）： RAG 是另一種將外部知識注入 LLM 的策略。每個請求首先查詢外部知識函式庫向量資料函式庫然後將相關訊息包含在 LLM 提示中。雖然這減輕了微調的一些缺點，但一個限制因素是 LLM 在單個請求中可以處理的提示長度（連貫的背景與環境大小）。因此，過濾掉不相關訊息以保持提示大小可管理是很重要的。

嵌入模型概述

嵌入模型是一種強大的機器學習技術，能將高維資料簡化為低維空間，同時保留關鍵特徵。這在自然語言處理中尤為重要，將稀疏的詞表示轉換為密集向量，捕捉詞之間的語義相似性。

嵌入模型的實際應用

考慮這樣一個例子：假設資料函式庫電影情節已經使用 OpenAI 的嵌入模型進行了嵌入。你想找所有與「銀河守護者」相關的電影，但不是透過傳統的語音或詞彙比對，而是透過語義搜尋，比如使用「Awkward team of space defenders」（笨拙的太空防衛隊）這個短語。

你會使用同一嵌入模型將這個短語嵌入，然後查詢嵌入的電影情節。結果嵌入是一個多維向量，包含了該短語的語義表示。

嵌入模型的技術需求

要實作這類別應用，你需要：

• MongoDB Atlas 叢集（免費的 M0 叢集通常足夠）
• OpenAI 帳戶和 API 金鑰
• Python 3 工作環境
• 必要的 Python 函式庫ymongo、langchain、langchain-openai 等）

嵌入模型的本質

嵌入模型是一種將大型複雜資料簡化為更易管理形式的工具。這個過程涉及降低資料的維度，就像將詳細的世界地圖簡化為只有國界和首都的版本。

玄貓喜歡用圖書館的比喻來解釋嵌入模型：想像一個巨大的圖書館，每本章代表高維空間中的一個點。嵌入模型可以幫助重新組織圖書館，使相關主題的書籍更接近，同時減少圖書館的整體「大小」，使導航更加便捷。

嵌入模型與 LLM 的區別

雖然嵌入模型和 LLM 都根據神經網路，但它們採用不同的方法：

• LLM 設計用於生成連貫與連貫的背景與環境相關的文字，利用大量資料理解和預測語言模式。
• 嵌入模型 專注於將單詞、短語或句子對映到密集向量空間，保留語義關係。

嵌入模型常用的技術包括對比損失和正負樣本取樣。正樣本是相似項（如同義詞或相關句子），而負樣本是不相似項（如不相關的詞或句子）。這種取樣透過最小化正對之間的距離和最大化負對之間的距離，幫助模型學習有意義的表示。

總之，LLM 在語言生成任務中表現出色，而嵌入模型則最佳化用於捕捉和利用語義相似性。兩者都透過使機器更有效地理解和產生人類語言來增強自然語言處理能力。

嵌入模型的應用與選擇

嵌入模型在各種應用場景中都有重要作用，從文字相似性搜尋、推薦系統到異常檢測。選擇適合的嵌入模型需要考慮多種因素：

1. 維度與表示能力：高維嵌入可以捕捉更多語義細節，但也需要更多儲存空間和計算資源
2. 領域適應性：不同領域（如醫療、法律、技術）可能需要專門的嵌入模型
3. 多語言支援：如果應用需要處理多種語言，選擇具有多語言能力的模型至關重要
4. 計算效率：在資源受限環境中，可能需要權衡精確度和效率

在實際應用中，嵌入模型與向量資料函式庫使用，能夠實作高效的語義搜尋和內容推薦，為使用者提供更相關、更個人化的體驗。

在現代 AI 系統中，嵌入模型常作為 LLM 的補充技術，處理特定任務如相似性計算、聚類別和降維，而 LLM 則負責理解和生成自然語言。這種組合充分發揮了兩種技術的優勢，創造更強大、更全面的 AI 解決方案。

在處理序列資料和建構人工智慧系統時，理解這些核心技術的工作原理和適用場景，對於開發者來說至關重要。無論是選擇合適的預訓練模型，還是設計自定義的 AI 解決方案，深入瞭解轉換器架構、大語言模型和嵌入模型的特性，都能幫助我們更有效地應對各種自然語言處理挑戰。

嵌入模型的本質與重要性

嵌入模型（Embedding Model）在現代人工智慧領域扮演著不可或缺的基礎角色。這類別模型能將各種資料形式轉換成密集向量表示，使機器能夠理解並處理複雜的語義關係。在我帶領團隊開發智慧搜尋引擎時，嵌入模型的選擇直接決定了系統對查詢語意的理解深度。

嵌入模型與大語言模型（LLM）雖然都屬於人工智慧技術，但其功能與應用場景有明顯區別：

• 嵌入模型：專注於將資料轉換為向量表示，捕捉語義關係，適用於相似度計算、聚類別分析等任務
• 大語言模型：專注於理解與生成文字，適合內容創作、對話系統等複雜語言任務

Word2vec：嵌入技術的開拓者

Google開發的Word2vec是嵌入模型的先驅，它能將單詞轉換成向量表示，並且捕捉單詞間的語義關係。Word2vec最令人驚嘆的特性是它能夠進行向量算術運算，例如：

向量("國王") - 向量("男人") + 向量("女人") ≈ 向量("女王")

這種能力使Word2vec在情感分析、機器翻譯和內容推薦等領域極為實用，為機器提供了理解語言語義的基礎能力。

GPT-4：超越嵌入的語言理解

相比之下，OpenAI開發的GPT-4作為大語言模型，其功能遠超純粹的嵌入。GPT-4能夠生成類別人文字，在對話、內容創作、摘要和翻譯等任務中表現卓越。其架構讓它能理解語言的細微差別，包括連貫的背景與環境、幽默、諷刺和文化參考等複雜概念。

嵌入模型與LLM的使用時機

嵌入模型適用場景

嵌入模型在需要捕捉和利用資料關係的情境中特別有價值：

1. 語義相似度計算：尋找或推薦與給定專案（如檔案或產品）相似的專案
2. 聚類別分析：根據語義特性將實體分組
3. 資訊檢索：透過理解查詢的語義內容增強搜尋功能

LLM適用場景

大語言模型則適合需要文字理解、生成或兩者兼具的任務：

1. 內容創作：生成連貫、連貫的背景與環境相關與風格適當的文字，例如從電影完整情節生成摘要
2. 對話式AI：構建能理解並進行類別人對話的聊天機器人和虛擬助手
3. 語言翻譯：處理習慣用語、文化細微差別和專業術語

嵌入模型的多元類別

文字嵌入模型

詞嵌入（Word Embeddings）

詞嵌入模型透過分析大規模文字語料函式庫連貫的背景與環境來捕捉語義意義。常見的方法包括：

1. 神經網路預測法：透過神經網路學習詞彙關聯，要麼從連貫的背景與環境預測單詞，要麼反之
2. 矩陣分解法：結合矩陣分解與連貫的背景與環境視窗技術，透過總結大型矩陣中的單詞共現頻率生成嵌入
3. 字元n-gram法：將每個單詞視為字元n-gram（特定順序的n個相鄰符號序列）的集合，更好地處理字首、字尾和罕見詞

以下是幾個重要的詞嵌入模型：

• Word2vec：由Google團隊開發，使用兩種架構：連續詞袋（CBOW）和跳躍式（Skip-gram）。Word2vec能夠捕捉詞彙語法關係，證據是它能夠從詞向量的算術運算中推匯出含義。

• GloVe：由斯坦福大學開發，融合了兩種主要詞表示方法的優勢：根據共現統計的全域矩陣分解和連貫的背景與環境視窗方法。GloVe透過從語料函式庫共現矩陣並應用降維技術，同時捕捉全域統計和區域性連貫的背景與環境，這對需要深入理解詞彙關係的任務非常有價值。

句子和檔案嵌入

句子和檔案嵌入模型透過考慮詞彙的連貫的背景與環境和排列來捕捉文字塊的整體語義意義。常見方法是將詞向量聚合為整個文字單元的連貼向量。這些模型在檔案相似度、資訊檢索和文字摘要方面很有用。

• Doc2vec（也稱為段落向量）：建立在Word2vec基礎上，將整個句子或檔案編碼為向量。引入檔案ID標記，使模型能夠在學習詞嵌入的同時學習檔案級嵌入，這在檔案分類別和相似度比較等任務中非常有幫助。

• BERT：Google的BERT採用連貫的背景與環境感知嵌入，同時讀取整個詞序列，而其前身則是線性處理文字。這種方法使BERT能夠從所有周圍的詞理解詞的連貫的背景與環境，產生更動態和細微的嵌入，在各種NLP任務中設定了新標準。

連貫的背景與環境嵌入

連貫的背景與環境嵌入模型設計用於生成根據句子中使用連貫的背景與環境而變化的詞向量。這些模型使用深度學習架構，透過檢查整個句子或有時周圍的句子來生成動態嵌入，捕捉根據詞特定連貫的背景與環境和語言環境的細微差別。

• ELMo（Embeddings from Language Models）：引入了動態、連貫的背景與環境相關的嵌入，根據詞的語言連貫的背景與環境產生可變嵌入。這種方法透過提供更豐富的語言理解，大提高了下游NLP任務的效能。

• GPT系列：OpenAI的GPT系列利用Transformer技術提供在大量文字語料函式庫訓練並針對特定任務微調的嵌入。GPT的成功凸顯了在NLP中結合大規模語言模型和Transformer架構的有效性。

專業化嵌入

專業化嵌入模型在向量空間中捕捉特定的語言特性，如地點、人物、語調和情緒。有些是特定語言或方言的，而其他則分析情感和情緒維度。應用包括法律檔案分析、支援票據分類別、行銷中的情感分析和多語言內容管理。

• fastText：由Facebook的AI研究實驗室開發，fastText透過將詞視為字元n-gram的集合來增強Word2vec，這對處理詞彙表外（OOV）詞特別有幫助。OOV詞是訓練期間未見過的詞，因此缺乏預先學習的向量表示，為傳統模型帶來挑戰。fastText透過其子詞嵌入的總和為OOV詞啟用嵌入，使其特別適合處理罕見詞和形態複雜的語言，如芬蘭語、土耳其語和阿拉伯語。

非文字嵌入模型

嵌入模型不僅限於將文字轉換為向量表示。影像、音訊、影片甚至JSON資料本身都可以用向量形式表示：

影像嵌入

• VGG（Visual Geometry Group）和ResNet（Residual Network）為原始影像轉換為密集向量設定了基準。這些模型捕捉重要的視覺特徵，如邊緣、紋理和顏色漸變，這對許多電腦視覺任務至關重要，包括影像分類別和物體識別。VGG擅長識別視覺模式，而ResNet在複雜的影像處理任務中提高準確性，如影像分割或照片標記。

音訊嵌入

• OpenL3和VGGish是音訊模型。OpenL3是改編自L3-Net架構的模型，用於音訊事件檢測和環境聲音分類別，將音訊嵌入到時間和頻譜連貫的背景與環境豐富的空間。VGGish源於影像的VGG架構，因此遵循相同的原則，將聲波轉換為小型、緊湊向量的模式，簡化了語音和音樂類別識別等任務。

影片嵌入

• 3D卷積神經網路（3D CNNs或3D ConvNets）和Inflated 3D（I3D）擴充套件了影像嵌入在感知時間動態方面的能力，這對動作識別和影片內容分析至關重要。3D ConvNets在三個維度（高度、寬度、時間）應用卷積濾波器，捕捉體積資料中的空間和時間依賴性，使其特別適合於時空資料，如影片分析、醫學成像和3D物體識別。I3D使用結合兩個3D ConvNets輸出的時空架構：一個處理RGB幀，另一個處理連續幀之間的光流預測。I3D模型對體育分析和監控系統很有用。

圖形資料嵌入

• Node2vec和DeepWalk捕捉圖中節點的連線模式，應用於社交網路分析、欺詐檢測和推薦系統領域。Node2vec透過在圖上執行有偏隨機遊走來學習節點的連續向量表示，捕捉多樣的節點關係和社群結構，提高節點分類別和連結預測等任務的效能。DeepWalk將隨機遊走視為節點序列，類別似於NLP中的句子，透過捕捉節點之間的結構關係並將它們編碼為連續向量表示，可用於節點分類別和聚類別。

JSON資料嵌入

• Tree-LSTM是傳統長短期記憶（LSTM）網路的變體，專門用於處理具有階層樹結構的資料，如JSON。與順序處理資料的標準LSTM單元不同，Tree-LSTM透過將多個子節點的狀態合併到父節點中來處理樹結構資料，有效捕捉巢狀結構中的依賴關係。這使它特別適合於語義解析和情感分析等任務，理解資料中的階層關係可以顯著提高效能。json2vec是這種嵌入模型的一種實作。

多模態嵌入模型

多模態嵌入模型處理並整合來自多種資料源的資訊到統一的嵌入空間。當不同模態相互補充或強化時，這種方法非常有用，共同可以帶來更好的AI應用。多模態模型非常適合深入理解多感官輸入內容，如多媒體搜尋引擎、自動化內容審核和可以透過視覺和口頭互動與使用者互動的互動式AI系統。

• CLIP：OpenAI的知名多模態模型。它學習如何將視覺影像與文字描述相關聯，使其能夠根據自然語言查詢識別訓練期間從未見過的影像。

• LXMERT：專注於處理視覺和文字輸入的模型。它可以提高帶有視覺方面的問題回答任務的效能，包括物體檢測。

• ViLBERT：Vision-and-Language BERT（ViLBERT）擴充套件了BERT架構，同時處理視覺和文字輸入，使用雙流模型，一個流處理使用預訓練卷積神經網路（CNN或ConvNet）從影像中提取的視覺特徵，另一個處理文字資料，交叉注意力層促進兩種模態之間的互動。ViLBERT用於視覺問答和視覺常識推理等任務，理解影像-文字關係至關重要。

• VisualBERT：透過將影像特徵與BERT類別架構的連貫的背景與環境化詞嵌入結合，整合視覺和文字資訊。它常用於影像-文字檢索和影像標題等任務，其中對齊和

嵌入模型選擇與應用：從理論到實踐

在人工智慧領域中，選擇合適的嵌入模型(Embedding Models)至關重要，它直接影響到模型處理語言任務的效能與準確性。作為一名長期參與AI專案開發的技術工作者，玄貓發現許多開發者在選擇嵌入模型時常感到困惑。本文將探討嵌入模型的選擇標準、應用場景以及實際實作方式。

根據任務需求選擇嵌入模型

不同類別的任務需要不同的嵌入模型，這取決於它們如何處理和表示文字資料。在我參與的多個專案中，發現選擇合適的模型是成功的第一步。

文字分類別與情感分析

文字分類別和情感分析等任務通常需要深入理解詞彙層面的語意關係。針對這類別任務，Word2vec或GloVe模型特別有效，因為：

• 它們提供強大的詞彙層級嵌入
• 能夠捕捉詞彙間的語意關係
• 適合處理需要詞彙層面理解的任務

進階語言理解任務

對於命名實體識別(NER)和詞性標記(POS)等更複雜的語言任務，理解詞彙在句子中的連貫的背景與環境變得尤為重要。在這些情況下，BERT或ELMo模型展現出顯著優勢：

• 它們能根據周圍文字動態生成嵌入
• 提供更豐富、更精確的理解
• 能夠區分同一個詞在不同連貫的背景與環境中的不同含義

檔案層級任務

對於問答系統、機器翻譯、檔案相似度比較和文字聚類別等需要細緻語言理解的任務，進階模型如BERT、GPT和Doc2vec是理想選擇：

• 這些模型能處理文字中的複雜依賴關係
• 適合分析整個檔案
• Doc2vec特別擅長比較檔案間的主題相似性，例如尋找相似的新聞或體育文章

資料集特性對模型選擇的影響

在選擇嵌入模型時，資料集的大小和特性是關鍵考量因素。當我為一家多語言內容平台設計NLP系統時，發現不同語言的特性對模型選擇有顯著影響。

語言形態學特性

對於形態學豐富的語言或包含大量生詞(OOV)的資料集：

• fastText等能捕捉子詞資訊的模型具有優勢
• 這些模型能有效處理新詞或罕見詞
• 適合處理如芬蘭語、土耳其語等形態學複雜的語言

多義詞處理

對於含有多義詞(一詞多義)的文字：

• ELMo或BERT等連貫的背景與環境嵌入模型至關重要
• 它們提供動態的、依連貫的背景與環境而變的表示
• 能根據具體使用情境區分詞義

資料集規模考量

資料集大小也會影響嵌入模型的選擇：

• 較大的資料集能從BERT、GPT和OpenAI的text-embedding-3-large等複雜模型中受益
• 這些模型能捕捉深層語言細微差別，但需要大量計算資源
• 較小的資料集可能更適合使用text-embedding-3-small等簡單模型，提供穩健效能但計算需求較低

計算資源限制

在選擇嵌入模型時，計算成本是一個不容忽視的因素。在我為一家初創公司最佳化NLP管道時，資源限制成為主要考量點。

計算需求差異

不同模型的資源需求差異顯著：

• GPT-4等較大模型需要龐大的計算能力，對小型組織或預算有限的專案可能不太適用
• 輕量級模型或針對特定任務微調的模型可以減少計算需求
• 這種選擇可以加速開發並改善回應時間

即時應用考量

對於需要即時回應的任務，高效模型至關重要：

• 翻譯、語音識別等任務需要快速處理
• 遊戲、媒體串流和電子商務中的即時推薦系統也需要高效模型
• 在這些場景中，模型效率直接影響使用者經驗

向量表示的重要性

在嵌入模型中，向量的大小直接影響其捕捉資料複雜性的能力。這是我在設計語意搜尋系統時特別關注的方面。

向量維度的影響

向量維度大小的選擇涉及多方面權衡：

• 大型向量能編碼更多資訊，允許更精細的區分
• 但它們需要更多計算資源和儲存空間
• 小型向量更高效但可能忽略細微差別
• 選擇向量大小需要平衡詳細表示與實際限制(如記憶體和速度)

神經網路與向量表示

瞭解向量、其大小與神經網路倒數第二層之間的關係對理解模型輸出的品質至關重要：

• 倒數第二層通常作為特徵提取器
• 輸出向量的維度代表輸入資料的學習特徵
• 這個向量的大小直接影響表示的精細程度

常見向量維度

不同模型的向量維度各異：

• SBERT的all-MiniLM-L6-v2使用384維
• SBERT的all-mpnet-base-v2使用768維
• OpenAI的text-embedding-ada-002使用1,536維
• Microsoft Research的ResNet-50使用2,048維
• OpenAI的text-embedding-3-large提供3,072維

向量嵌入的實際應用

向量嵌入是嵌入模型的輸出，表示為浮點數陣列，通常範圍從-1.0到+1.0。每個位置代表一個維度。

連貫的背景與環境檢索應用

向量嵌入在連貫的背景與環境檢索場景中扮演關鍵角色：

• 聊天機器人中的語意搜尋就是一個典型例子
• 資料事先嵌入並儲存在向量資料函式庫- 查詢必須使用相同的嵌入模型才能獲得準確結果

模型特異性

每個嵌入模型根據其訓練資料產生獨特的嵌入：

• 這些嵌入特定於模型的領域，不可互換
• 例如，在法律文字上訓練的模型與在醫療資料上訓練的模型產生的嵌入有顯著差異
• 這種特異性使得在整個應用程式中保持一致的嵌入模型至關重要

嵌入模型排行榜

隨著新模型不斷發展，如何保持更新？嵌入模型排行榜提供了寶貴的參考。

排行榜價值

模型排行榜幫助評估各種模型在眾多工中的表現：

• 它們提供根據準確性和效率等標準的透明競爭排名
• 透過針對標準化資料集和基準任務衡量模型
• 這些排行榜能突出最先進的模型及其權衡

關鍵資源

Massive Text Embedding Benchmark (MTEB)排行榜是一個重要資源：

• 提供文字嵌入模型效能基準的全面概述
• 可以存取Hugging Face MTEB排行榜檢視哪些模型設定了標準
• Hugging Face還提供Open LLM排行榜和特定語言的排行榜

嵌入模型綜述

不同嵌入模型各有優缺點，以下是一些主要模型的概述：

Word2vec

• 高品質、連貫的背景與環境豐富的嵌入
• 在TensorFlow等平台上可用，但線上可用性有限

GloVe

• 強大的嵌入，特別適合低頻詞
• 在TensorFlow等平台上可用，但線上可用性有限

BERT

• 連貫的背景與環境化嵌入，豐富與適應性強
• 線上可用

GPT

• 高品質嵌入，在生成和語言理解任務中表現出色
• 線上可用

Doc2vec

• 適合檔案級任務
• 嵌入反映比詞級模型更廣泛的連貫的背景與環境

fastText

• 有效捕捉OOV詞
• 開放原始碼與極輕量級
• 可在標準硬體上執行，甚至可生成適用於行動裝置的小型模型

text-embedding-3-large

• 高品質嵌入，適用於複雜NLP任務
• 捕捉細微連貫的背景與環境
• 取代了OpenAI的text-embedding-ada-002
• 可在保持高嵌入品質的同時生成較小向量

text-embedding-3-small

• 適用於標準NLP任務的良好品質嵌入
• 平衡效能和計算需求

是否總是需要嵌入模型？

答案是否定的。並非所有情況都需要嵌入模型來表示向量形式的資料。在某些應用中，更直接的向量化方法完全足夠。

簡單向量表示的適用場景

在以下情況下，複雜的公共嵌入模型或定製模型可能不必要：

• 焦點狹窄、規則明確或資料結構化的任務
• 簡單聚類別、精確相似度測量的場景
• 計算能力有限的環境

替代技術

一些簡單但有效的替代技術包括：

• One-hot編碼：將分類別資料轉換為二進位制向量，適合類別是名義上而無內在順序的情況
• TF-IDF向量：透過突出顯示檔案中相對於整個語料函式庫項相關性，巧妙地傳達文字重要性

權衡考量

這些替代方案雖然缺乏嵌入模型的語意深度，但提供了其他優勢：

• 計算效率和簡單性
• 增強透明度
• 減少計算需求
• 適合快速效能或資源有限的環境，如嵌入式系統或行動裝置

使用Python、LangChain和OpenAI實作嵌入功能

瞭解嵌入模型之後，讓我們看如何在實際程式碼中使用它們。以下Python指令碼使用langchain-openai函式庫用OpenAI的text-embedding-3-large模型嵌入文字資料，自定義生成1,024維向量（而非預設的3,072維）：

import os, pprint, time
from langchain_mongodb import MongoDBAtlasVectorSearch
from langchain_openai import OpenAIEmbeddings
from pymongo import MongoClient

# 設定OpenAI API金鑰
os.environ["OPENAI_API_KEY"] = "YOUR-OPENAI-API-KEY"

# 設定MongoDB連線字串
MONGODB_ATLAS_CONNECTION_STRING = "YOUR-MONGODB_ATLAS-CONNSTRING"

# 連線MongoDB
client = MongoClient(MONGODB_ATLAS_CONNECTION_STRING, tls=True,
                    tlsAllowInvalidCertificates=True)
db_name = "embeddings"
collection_name = "text"
coll = client[db_name][collection_name]
vector_search_index = "text_vector_index"

# 清空集合中的所有檔案
coll.delete_many({})

# 準備要嵌入的文字
texts = []
texts.append("A martial artist agrees to spy on a reclusive crime lord using his invitation to a tournament there as cover.")
texts.append("A group of intergalactic criminals are forced to work together to stop a fanatical warrior from taking control of the universe.")
texts.append("When a boy wishes to be big at a magic wish machine, he wakes up the next morning and finds himself in an adult body.")

# 初始化嵌入模型
embedding_model = OpenAIEmbeddings(
    model="text-embedding-3-large",
    dimensions=1024,
    disallowed_special=()
)

# 嵌入文字
embeddings = embedding_model.embed_documents(texts)

在這段程式碼中，我們首先設定必要的環境變數和連線資訊，然後準備了三個電影簡介的文字。使用OpenAIEmbeddings類別初始化嵌入模型，並指定使用text-embedding-3-large模型，維度設為1024，最後對文字進行嵌入處理。

這種方法的優點在於：

1. 靈活性：可以根據需求調整向量維度
2. 整合性：與MongoDB Atlas向量搜尋無縫整合
3. 可擴充套件性：可以輕鬆處理更多文字和更複雜的查詢

選擇嵌入模型的實用

根據我多年的實踐經驗，以下是選擇嵌入模型時的一些實用建議：

1. 明確任務需求：首先明確你的任務類別（分類別、命名實體識別、檔案相似度等），這將大幅縮小適用模型範圍

2. **評估資

向量資料函式庫代AI應用的搜尋引擎

在資料豐富與結構明確的情境下，傳統資料函式庫能夠有效處理我們明確知道要搜尋什麼的情況。然而，現實世界中，我們常無法精確描述所需資訊。例如，當你想找尋「那部有數字從天而降的電影裡的主角最新作品」時，傳統關鍵字搜尋可能無法理解這種模糊請求。

近年來，AI研究催生了一種新型技術——向量資料函式庫夠編碼並理解資料的語義含義，而非僅處理原始資料。這使得系統能夠理解上述查詢實際上是在尋找《駭客任務》主角基努李維主演的《捍衛任務》系列電影。

向量嵌入的本質與價值

向量嵌入本質上是一個數字列表，加上決定這些數字如何定義和比較的隱含結構。向量中的元素數量稱為向量的維度，每個維度代表它所描述事物的不同方面。

舉個簡單例子，描述一輛車的屬性可以結構化為 [年份, 品牌, 型號, 顏色, 里程]。這些屬性形成了一個向量空間，可以描述任何適用這些屬性的車輛。例如，特定車輛可以表示為 [2000, Honda, Accord, Gold, 122000]。

然而，AI應用中使用的向量更加抽象，維度也顯著增加。這些向量將具體概念分散到多個維度中，並標準化為每個維度的單一可能值集。例如，OpenAI的text-embedding-ada-002模型始終產生1,536個元素的向量，每個元素都是介於-1和1之間的浮點數。

這些向量是嵌入模型的輸出結果。嵌入模型是預先訓練好的機器學習模型，能將輸入（通常是文字標記字串）轉換為編碼輸入語義含義的向量。對人類來說，這些向量的多維度幾乎不可能解讀，但嵌入模型在訓練過程中學習每個維度的隱含義，並能可靠地為其輸入編碼。

向量相似度：理解資料間的語義關聯

向量資料函式庫儲存高維向量資料外，還支援各種操作，讓我們可以查詢和搜尋向量。其中最常見的操作是最近鄰搜尋，它會回傳與輸入查詢向量最相似的儲存向量列表。

相似度的數學定義

但什麼才代表兩個向量相似呢？簡而言之，相似向量彼此距離接近，我們可以用距離來衡量。雖然無法直觀地視覺化高維向量間的距離計算方式，但我們可以透過低維向量理解基本原理，再擴充套件到高維情況。

回想幾何學課程，我們可以使用距離公式計算兩個坐標向量間的距離。例如，2D坐標(x, y)使用距離公式：distance(a, b) = sqrt((a_x - b_x)^2 + (a_y - b_y)^2)。這同樣適用於3D坐標，公式中會增加一個額外維度的元件。這種模式可推廣到任意維數，被稱為歐幾裡得距離。

理論上，我們也可以使用歐幾裡得距離來測量AI應用中使用的高維向量間的距離。但實際上，隨著維度的增加，歐幾裡得距離的實用性會下降。這種在低維度有效但在高維度失效的工具和直覺現象被稱為「維度詛咒」。

餘弦相似度：高維空間的最佳距離度量

為克服高維空間的挑戰，大多數應用使用一種稱為餘弦相似度的距離度量。與歐幾裡得距離不同，餘弦相似度不是測量兩個向量尖端之間的空間，而是測量分享共同基底的兩個向量之間的角度大小。它能夠以數學上精確的方式確定兩個向量是否相同、完全無關或（最可能的情況）介於兩者之間。相似向量指向幾乎相同的方向，無關向量是正交的，而相反向量指向相反方向。

MongoDB實作語義搜尋的實際案例

讓我們透過一個實際例子，看如何使用MongoDB Atlas和OpenAI的嵌入模型實作語義搜尋。以下是一個完整的程式碼示範：

docs = []
for i in range(len(texts)):
    docs.append(
        {
            "text": texts[i],
            "embedding": embeddings[i]
        }
    )
coll.insert_many(docs)
print("Documents embedded and inserted successfully.")
time.sleep(3) # 允許向量儲存(Atlas)進行索引處理

semantic_queries = []
semantic_queries.append("Secret agent captures underworld boss.")
semantic_queries.append("Awkward team of space defenders.")
semantic_queries.append("A magical tale of growing up.")

vector_search = MongoDBAtlasVectorSearch(
    collection=coll,
    embedding=OpenAIEmbeddings(
        model="text-embedding-3-large",
        dimensions=1024,
        disallowed_special=()),
    index_name=vector_search_index
)

for q in semantic_queries:
    results = vector_search.similarity_search_with_score(
        query=q,
        k=3
    )
    print("SEMANTIC QUERY: " + q)
    print("RANKED RESULTS: ")
    pprint.pprint(results)
    print("")

程式碼解析

這段程式碼示範瞭如何將文字嵌入並存入MongoDB Atlas，然後執行語義搜尋：

1. 首先，程式將文字及其對應的嵌入向量組織成檔案集合，並插入MongoDB集合中
2. 插入後暫停3秒，允許Atlas完成向量索引處理
3. 接著定義三個語義查詢，分別描述不同類別的電影情節
4. 初始化向量搜尋引擎，使用OpenAI的text-embedding-3-large模型（1024維度）
5. 對每個查詢執行相似度搜尋，回傳最相似的3個結果及其相似度分數
6. 最後輸出查詢和排序結果

搜尋結果分析

執行程式後，我們可以看到每個語義查詢的搜尋結果：

對於「Secret agent captures underworld boss」（特工捕捉黑幫老大）查詢：

• 最相似的結果描述一位武術家同意潛入犯罪頭目的比賽進行間諜活動（相似度0.77）
• 其次是一群星際罪犯被迫合作阻止狂熱戰士控制宇宙（相似度0.66）
• 最後是一個男孩在魔法許願機器上希望長大的故事（相似度0.58）

對於「Awkward team of space defenders」（尷尬的太空防衛隊）查詢：

• 最相似結果是星際罪犯合作的故事（相似度0.79），這符合語義預期
• 其他結果相似度逐漸降低，表明與查詢的相關性減弱

對於「A magical tale of growing up」（成長的魔幻故事）查詢：

• 最相似結果是男孩透過魔法機器變成人的故事（相似度0.75）
• 其他結果相似度明顯較低

這些結果展示了向量搜尋的強大之處——即使查詢用詞與原始文字完全不同，系統仍能根據語義相關性回傳合適的結果。

嵌入模型選擇的最佳實踐

選擇合適的嵌入模型和向量大小不僅是技術決策，更是需要符合專案獨特性、技術和組織限制以及目標的策略決策。在我為多家企業設計語義搜尋系統時，發現以下幾點尤為重要：

計算效率與成本平衡

維持計算效率和成本是有效使用嵌入模型的另一個根本。由於某些模型可能資源密集與回應時間和成本較高，在不犧牲輸出品質的情況下最佳化計算方面至關重要。

我曾在一個電商產品推薦系統中，透過設計系統根據任務不同使用不同的嵌入模型，成功將查詢回應時間降低40%，同時維持了推薦品質。這種彈性架構設計能顯著提升系統韌性。

定期評估與調整

定期評估嵌入模型以確保AI/ML應用程式繼續按預期執行至關重要。這涉及定期檢查效能指標並進行必要的調整模型使用可能意味著更改向量大小以避免過度擬合——模型過於精細地調整到訓練資料，在未見過的資料上表現不佳。

在向量搜尋中，向量大小的選擇是一個微妙的平衡：

• 較小的向量（32-256維）：計算效率高，但可能缺乏足夠的語義表達能力
• 中等大小向量（512-1024維）：大多數應用的良好平衡點
• 較大的向量（1536-4096維）：提供更豐富的語義表達，但計算成本和儲存需求較高

監控與規劃

監控向量搜尋回應時間與所使用的嵌入模型和向量大小至關重要，因為這些會影響AI驅動應用程式的使用者經驗。也要考慮維護和更新嵌入模型的成本，包括重新嵌入資料的金錢、時間和資源支出。規劃這些有助於在需要更新時做出明智決定，並平衡效能、成本效益和技術進步。

向量資料函式庫際應用案例

向量資料函式庫用範圍廣泛，以下是我在實際專案中見證的幾個成功案例：

人工智慧客服系統

一家電信公司使用向量資料函式庫了其客戶支援系統。透過將常見問題和解決方案向量化，並結合RAG（檢索增強生成）技術，系統能夠理解客戶查詢的語義，並從知識函式庫索最相關的解決方案。這不僅提高了首次解決率，還減少了30%的平均處理時間。

多媒體內容推薦

一個串流媒體台使用向量資料函式庫強其內容推薦系統。透過分析使用者觀看歷史，系統生成使用者偏好的向量表示，然後使用最近鄰搜尋找到語義上相似的內容。這種方法超越了傳統的協同過濾，能夠發現表面上不同但主題或情感上相似的內容，使推薦更加多樣化與個人化。

學術研究文獻搜尋

在學術領域，向量資料函式庫革新文獻搜尋方式。研究人員不再僅限於關鍵字搜尋，而是可以描述研究問題或概念，系統會回傳語義相關的論文。這大加速了文獻綜述過程，並幫助研究人員發現跨學科的相關研究。

向量搜尋系統的建構最佳實踐

多年來我在設計和實作向量搜尋系統時，總結了以下幾點關鍵最佳實踐：

資料預處理的重要性

向量搜尋的品質很大程度上取決於輸入資料的品質。在將文字轉換為向量前，應當進行適當的預處理：

• 移除無關內容（如HTML標籤、特殊字元）
• 適當的分段：過長的文字應分割成更小、語義完整的單元
• 標準化處理：確保一致的格式和術語使用

混合搜尋策略

純語義搜尋並非總是最佳選擇。在實踐中，結合傳統的關鍵字搜尋和向量搜尋常能獲得更好的結果：

• 關鍵字搜尋擅長精確比對和結構化查詢
• 向量搜尋擅長理解語義相關性和處理模

向量相似度搜尋：核心概念與應用

當我們談論向量資料函式庫餘弦相似度（Cosine similarity）是一個關鍵概念。它不只是測量兩個向量之間距離的工具，更因為向量嵌入（embeddings）攜帶語義訊息的特性，成為衡量兩個向量相關性或關聯性的重要指標。將這個概念擴充套件到更多向量，我們就能判斷一個特定向量與其他所有向量的相關性，甚至按相關性對它們進行排序。這正是向量搜尋演算法的核心思想。

在實作大型向量搜尋系統時，我曾發現比較大量向量會帶來特有的複雜性和挑戰。為了應對這些挑戰，搜尋提供者開發了各種鄰近搜尋（nearest neighbor search）方法，在不同權衡之間取得平衡，並針對不同使用場景進行最佳化。接下來我將探討兩種處理實際搜尋場景的方法。

精確搜尋與近似搜尋的抉擇

精確鄰近搜尋的應用場景

某些應用場景要求搜尋結果必須只回傳真正的最近鄰。以生物識別驗證應用為例，當應用將使用者的生物識別訊息儲存為向量嵌入以便日後驗證身份時，精確性就變得至關重要。當使用者掃描指紋或臉部時，應用會為掃描資料建立向量嵌入，並將其作為鄰近搜尋的查詢向量。

這類別應用絕不能將使用者誤認為另一個具有相似指紋或面容的人。這種情況非常適合使用精確最近鄰搜尋（Exact Nearest Neighbor，ENN），它保證搜尋結果是最佳比對。ENN必須始終回傳最接近的比對向量，並確保它出現在其他相似但距離更遠的比對之前。

最直接的方法是使用暴力法（brute-force）：計算查詢向量與每個儲存向量之間的距離，然後回傳從最近到最遠排序的結果列表。透過檢查每個向量，可以保證搜尋結果精確包含最相關的向量並按順序排列。雖然這種方法對小型資料集有效，但隨著儲存向量數量增加，計算成本和時間消耗迅速增長。

某些巧妙的方法可以幫助精確搜尋擴充套件到較大的資料集，例如使用根據樹的索引來避免計算每個向量的相似度。這使精確搜尋在某些額外類別的應用中有用，但最終，這個問題難以擴充套件，在大型資料集上可能需要很長時間。在需要精確性的情況下，我們必須接受其限制並尋找解決方法。

近似鄰近搜尋的實用性

然而，對於許多常見的應用場景，只需知道你的搜尋結果足夠接近最佳比對即可。這類別使用場景稱為近似最近鄰搜尋（Approximate Nearest Neighbor，ANN），足以滿足許多日常應用的需求。

例如，當你在推薦應用中搜尋類別似《全面啟動》（Inception）的電影時，你不需要結果包含特定電影。相反，你可能只想要一份具有腦洞大開情節的科幻驚悚片列表。像[“關鍵報告”、“記憶拼圖”、“隔離島”]這樣的結果列表是有用的，即使事實證明《星際效應》（Interstellar）在技術上比任何回傳的結果都更接近語義比對。

精確搜尋與近似搜尋的選擇取決於你應用的需求。你可能有嚴格的要求，需要精確搜尋。但你也可能有一個使用場景，其中精確搜尋雖然有用，但對提供價值並非必要。或者進行精確搜尋可能根本沒有意義。下一節中，我將介紹如何評估搜尋演算法，幫助你確定需求。

搜尋評估指標

可以從精確度、召回率和延遲三個方面描述搜尋演算法：

• **精確度（Precision）**衡量搜尋結果的準確性。精確的搜尋嘗試只回傳與查詢相關的比對項，而很少或沒有不相關的結果。
• **召回率（Recall）**衡量搜尋結果的完整性。如果搜尋回傳所有相關結果的很大一部分，則召回率高。
• **延遲（Latency）**衡量搜尋查詢從開始到結束所需的時間。每次搜尋都需要一定時間回傳結果。確切的延遲因搜尋而異，但平均而言，它是搜尋空間中向量數量以及精確度和召回率要求的函式。

這些因素緊密相連，需要進行權衡，這定義了最近鄰搜尋的本質。例如，ENN搜尋具有完美的精確度，將包含最相關的結果。然而，為了保持合理的延遲，如果結果太多，它可能會省略一些相關結果。因為它錯過了有效結果，這種搜尋會有相對較低的召回率。如果ENN搜尋還需要高召回率，那麼搜尋必須執行更長時間，以確保包含足夠的相關結果。

在ANN搜尋中，可以放寬精確度要求，從而可以最佳化其他因素。可以透過允許搜尋花費更多時間或回傳更多可能包含假陽性的結果，來獲得更完整的結果。如果可以容忍假陽性（例如，透過在搜尋後在應用中過濾它們），那麼可以使用ANN進行快速搜尋，回傳高度相關的結果集。

應該評估你的應用並確定其關於這些因素的首要優先事項。然後，可以選擇適當的搜尋操作並調整演算法，直到其他因素適當平衡。

調整搜尋演算法涉及修改決定其如何構建和遍歷索引資料結構的設定引數。為了更好地瞭解這意味著什麼，接下來幾節將介紹用於啟用向量搜尋操作的概念和資料結構，從連通性的概念開始。

圖連通性與向量搜尋

如果你曾經使用過城市的公共交通網路出行，你可能想過城市選擇在特定地點設定火車或公車站的原因。雖然有許多因素在起作用，但如果你看一個理想情況，可以將選擇歸結為兩個相關因素：連通性和延遲。

想象一個乘火車的乘客，我們稱她為Alice，正在穿越城市去看她的朋友Bob。如果Bob家附近有一個站點，那就太好了，因為這樣Alice一下火車就能看到他。當然，你不可能在每個房子前都放一個火車站，而與超過某個點後，增加更多站點會增加平均行程時間。

每次改變站點數量或連線，都可能影響系統中任意兩個目的地之間的行程時間。通常，規劃公共交通站點位置的工作是由知識豐富的土木工程師、城市規劃者和其他利益相關者經過深思熟慮完成的。交通網路的主要目標是在合理的時間內將乘客帶到離其真正最終目的地相對較近的站點。透過瞭解他們的目標並應用特定策略，城市規劃者嘗試以對交通乘客有用與高效的方式連線城市的遠距離部分。

同樣，ANN搜尋的目標是在合理的時間內找到接近給定查詢向量的向量。如果從交通規劃者那裡獲得靈感，可以利用這種相似性並設計有效的ANN索引。

可導航小世界

本質上，交通規劃和最近鄰搜尋都歸結為構建和遍歷圖的問題，該圖在連通性和延遲之間進行權衡。可以使用稱為可導航小世界（Navigable Small Worlds，NSW）的演算法來構建這樣的圖。它一次接收一個向量，並為每個向量在圖中增加一個節點。每個節點也可以與其他節點連線，這些連線稱為鄰居，在圖構建過程中分配。

NSW演算法旨在平衡節點的直接鄰居的相關性與節點與圖其餘部分的連執行緒度。它主要會分配與節點密切相關的鄰居。然而，它有時也可能連線圖上相對遠離的兩個不太相似的節點。如果想象交通範例，這就像有一條公車路線在同一個社群有幾個站點，但也通往往市中心。居民可以輕鬆到達當地目的地。如果他們需要去社群外，他們仍能夠存取城市的其餘部分。

對於NSW圖的範例，請參考下圖。注意每個節點最多連線三個鄰居，與通常，附近節點緊密連線。每個節點代表一個向量，用線連線的節點是鄰居。高亮的連線顯示貪婪最近鄰搜尋的路徑。

一旦構建了向量的NSW圖，就可以將其用作ANN搜尋的索引。可以從隨機節點開始，使用搜尋演算法沿著鄰居連線，直到達最近鄰。這使你只需比較總搜尋空間的子集。例如，注意上圖中的搜尋路徑如何到達最近鄰，而無需存取圖中的每個節點。

如何搜尋可導航小世界

用於遍歷NSW圖的確切搜尋演算法可能會有所不同，並影響搜尋的整體行為。最常見的演算法是簡單的貪婪搜尋，每一步，你找到並採取最佳的即時選項，不考慮以前或未來的步驟。例如，NSW圖的貪婪搜尋首先隨機選擇一個節點作為起點，然後測量該節點與查詢向量的接近程度。然後，它測量到該節點的每個鄰居的距離。如果其中一個鄰居比當前節點更接近，那麼搜尋會移至該節點，並繼續相同的測量和比較過程。否則，搜尋完成，當前節點是近似最近鄰。

在NSW與貪婪搜尋的這個基本例子中，近似的定義非常廣泛，搜尋可能回傳次優結果。這歸結為圖搜尋的本質，在這種情況下，它被設計為找到圖的區域性最小值。這個區域性最小值不保證是全域最小值，這使得搜尋是近似而非精確的。如果貪婪搜尋演算法停留在離全域最小值太遠的區域性最小值上，它可能回傳假陽性。

可以透過調整圖的構建引數部分防範這一點。然而，由於搜尋查詢和被搜尋的底層資料的動態特性，無法完全防止假陽性區域性最小值的存在。相反，需要找到一種方法來最小化它們的影響。

一種方法是從不同的隨機入口節點開始多次執行搜尋。這種方法稱為隨機重試（randomized retries），從圖中收集多個樣本，並在所有樣本中回傳最佳結果。還可以向演算法增加額外的機制使其更加健壯。一個常見的架構將貪婪搜尋演算法與可設定的優先佇列配對，該佇列保持搜尋已經看到的最近鄰的排序列表。如果搜尋遇到假陽性區域性最小值，佇列讓它回溯並探索可能導致更近鄰居的圖的其他分支。

你使用的確切搜尋方法取決於資料集和你的目標。例如，隨機重試易於實作並可以平行執行。

層次化搜尋：從機場到目的地的旅程

想像一下愛麗絲的旅行經驗。她的旅程發生在兩個不同的層次上。首先，在機場層次，她可以從家鄉機場前往任何與之相連的目的地機場。在這個層級，她能夠直接抵達許多不同城市，但每個城市的存取僅限於一個位置：機場。她利用機場網路快速接近目的地，無需花費過多時間規劃路線和長途跋涉。當她抵達離Bob最近的機場後，她便進入第二個層次——當地交通網路，這讓她能夠更精確地接近Bob的位置。

這正是層次化可導航小世界（Hierarchical Navigable Small World, HNSW）演算法的核心思想。當我們構建複雜的向量搜尋系統時，可以建立一個層級化的結構，其中每一層都是一個NSW（可導航小世界）圖。

HNSW的層級結構與搜尋機制

HNSW圖結構的特點在於其層級化設計。如同愛麗絲的旅程，頂層包含相對較少的節點，這些節點彼此距離較遠與連線稀疏。每個較低的層級都包含其上層的所有節點，再加上額外的節點和連線，使圖變得更加密集和互聯。

在我設計大規模向量搜尋系統時，常以這種方式劃分層級：頂層節點代表「大範圍」跳躍點，而較低層級則提供「細粒度」導航。這種設計能顯著提升搜尋效率，特別是在處理數十億向量的情境下。

![HNSW圖結構示意圖]

HNSW演算法在實際實作中，會以機率方式決定每個向量所處的最高層級，較低層級的節點比那些同時存在於較高層級的節點更為常見。搜尋過程始於最高層級，透過找到與查詢向量最接近的節點開始。然後，移至下一層的相同節點並從那裡繼續搜尋。這個過程持續進行，直到在最終層級找到最近的鄰居，此時搜尋完成。

HNSW的實用價值

HNSW是許多現代向量搜尋應用的基礎。經過實戰檢驗，它能在合理的時間內提供有用的結果。該演算法高度適合近似最近鄰（ANN）場景，與具有可設定的引數，讓開發者能夠控制搜尋效能。

在我參與的一個大型電商推薦系統專案中，透過HNSW演算法最佳化，我們將搜尋延遲從原本的200毫秒降低到不到20毫秒，同時保持了96%以上的精確度。這種效能與精確度的平衡，正是HNSW在實際應用中的核心價值。

向量資料函式庫要性

向量攜帶深層語義訊息，未來幾年將在越來越多的場景中被應用。處理向量需要特定與複雜的操作，這些操作只處理向量資料。此外，搜尋需求往往與更結構化的資料函式庫有很大區別。

向量資料函式庫式與優勢

這些因素共同決定了向量操作和傳統資料函式庫負載在很大程度上是獨立的。這促成了向量資料函式庫念——專門設計用於處理向量資料、索引和工作負載的系統。從開發者的角度來看，向量資料函式庫採取多種形式：

1. 獨立產品：完全獨立於其他操作型資料函式庫類別向量資料函式庫由專注於實作和最佳化向量操作，而不需考慮其他資料函式庫。然而，向量搜尋應用通常需要額外的過濾或元資料，並可能根據搜尋結果執行更傳統的資料函式庫。這些使用案例要麼在執行時需要對不同資料函式庫多次查詢，要麼需要額外的同步層將資料從操作型資料函式庫到向量儲存中。

2. 整合式解決方案：向量資料函式庫整合到現有的資料函式庫料服務中。例如，如果定義了適當的向量搜尋索引，通用資料函式庫系統可能在其查詢語言中支援向量搜尋操作。這允許應用程式利用現有系統的功能，並在同一系統內進行搜尋。向量資料函式庫在系統內獨立擴充套件和執行，但作為統一API的一部分與傳統操作一起向使用者展示。這將向量儲存與現有資料函式庫，但能帶來更簡單與易於維護的架構。

無論形式如何，向量資料函式庫AI應用中的關鍵工具。它們專為儲存和查詢向量資料而設計，可以設定以提供最佳搜尋結果並支援AI應用。

向量搜尋如何增強AI模型

AI模型涵蓋了廣泛的資料結構和技術。機器學習構成了現代大多數根據向量的AI模型的核心，旨在透過訓練過程「教導」電腦完成特定任務。一般來說，機器學習過程透過將精選的資料集輸入到能夠從資料中檢測和推斷模式的基礎模型中來工作。一旦模型學習了這些模式，它就能夠重建或插值這些模式以處理新的輸入。

資訊檢索與資訊合成

機器學習訓練和AI應用通常可分為兩個方面：

1. 資訊檢索：涉及尋找對AI過程有用的相關資訊。向量搜尋非常適合這項任務。嵌入模型可以將各種輸入的語義編碼成標準向量形式。然後，可以使用搜尋為同樣廣泛的輸入找到比對項，包括結構化和非結構化資料。

2. 資訊合成：將多個訊息片段（可能來自不同來源）組合成一個連貫與有用的結果。這是生成式AI模型的領域。這些模型無法可靠地找到或生成真實事實，但它們可以有效地處理和重新格式化輸入訊息。

向量搜尋在AI模型生命週期中的應用

向量搜尋透過在每個階段（從訓練到微調再到執行時）提供最相關的資料來增強機器學習和AI模型：

1. 訓練階段：可以使用向量資料函式庫儲和搜尋訓練資料。設計一個過程，從語料函式庫到用於每個訓練任務的最相關資料。例如，當為特定領域（如醫學）訓練語言模型時，可以使用向量搜尋從醫學教科書中檢索最相關的章節用於每個訓練批次。這確保了模型學習最相關的訊息，而不會被雜訊幹擾。

2. 微調階段：可以在更通用的基礎模型之上應用相同的理念進行微調，這本質上是第二階段的訓練。例如，可以微調醫學語言模型，使其生成的報告採用醫院系統偏好的風格和結構。向量搜尋可以幫助找到與每個訓練主題相關的人工撰寫的報告。

3. 執行時階段：無論模型是專用還是通用，都可以透過修改給予模型的輸入來定製其執行時行為。向量搜尋可以分析原始輸入並查詢相關訊息。然後，可以增強或細化原始輸入以包含檢索到的連貫的背景與環境。例如，可以維護一個罕見疾病的向量資料函式庫搜尋與使用者描述比對的任何內容，以獲得更加個人化的診斷。

AI應用有多種形式，但現代應用程式越來越多地使用執行時定製方法，為生成式轉換器模型提供相關連貫的背景與環境。這種架構是一種稱為檢索增強生成（RAG）技術的基礎，玄貓將在後續部分探討。

案例研究與實際應用

向量搜尋是一種強大的工具，能讓開發者建立複雜的系統，根據訊息的含義而非僅是精確的字詞來查詢訊息。透過理解資料點之間的連貫的背景與環境和關係，向量搜尋幫助檢索高度相關的結果。

Okta - 自然語言存取請求（語義搜尋）

Okta作為全球領先的身份安全提供商之一，使用自然語言RAG介面，允許使用者輕鬆請求組織中新技術的角色。他們使用Atlas向量搜尋和自定義嵌入模型構建了一個名為Okta Inbox的系統，使用者能夠將自然語言查詢對映到正確的角色。

這是利用語義搜尋解決問題的典型例子，Okta資料科學團隊訓練的嵌入模型能夠將自然語言請求對映到要分配的正確使用者角色。

這些請求會透過現有工作流程經由Slack路由到管理員。最終結果是一個簡單的使用者經驗，使請求者和存取管理者之間的身份管理變得更加簡單，從而使Okta作為身份和存取管理解決方案的價值主張更加突出。

Okta選擇使用Atlas向量搜尋來查詢這些向量，因為他們已經在使用Atlas作為操作資料儲存，這提供了更簡化的開發者體驗。

One AI - 根據語言的AI（根據業務資料的RAG）

One AI提供針對不同行業的垂直化AI代理和聊天機器人。這些服務允許在檔案上執行詳細的AI輔助分析，應用於金融服務、房地產、製造業和零售業等不同行業。

One AI提供的聊天機器人都是使用MongoDB Atlas平台構建的，索引了來自20多個不同內部服務的超過1.5億個檔案。One AI將AI融入日常生活的目標，透過簡單地向他們儲存在Atlas中的資料增加向量搜尋索引，並透過嵌入式自然語言輸入使其可查詢，變得可行。

正如One AI的CEO和創始人Amit Ben所說：“語言AI中一個非常見的使用案例是建立表示語言的向量。在同一個資料函式庫有向量化語言表示以及其他表示的能力，然後可以透過單一查詢介面存取，解決了我們作為API公司的核心問題。”

這是多租戶RAG應用的典型例子，One AI提供的一種AI服務索引和提供的資料可能與另一服務不相關。這是一種在Atlas平台內易於構建的常見資料建模式。

諾和諾德 - 自動臨床研究生成（進階RAG/RPA）

諾和諾德是全球領先的醫療保健公司之一，其使命是戰勝世界上一些最嚴重的慢性疾病，如糖尿病。作為獲得新藥批准和交付給患者過程的一部分，他們必須生成臨床研究報告(CSR)。這是臨床試驗的方法論、執行、結果和分析的詳細記錄，旨在作為監管機構和藥物審批過程中其他利益相關者的關鍵真相來源。

向量搜尋

隨著AI技術的快速發展，向量搜尋在未來幾年將變得更加重要。當我在不同企業諮詢時，已經看到越來越多的組織開始將向量資料函式庫其核心基礎架構。

技術趨勢與發展方向

1. 多模態向量搜尋：未來的向量搜尋將不僅限於文字，還將包括影像、音訊甚至影片等多模態資料。這將使系統能夠跨不同媒體類別進行「意義」層面的搜尋。

2. **實時向

向量搜尋的實戰應用與效益

向量搜尋技術正在徹底改變企業處理資訊的方式。以諾和諾德製藥（Novo Nordisk）為例，他們成功將原本需要12週才能完成的臨床研究報告（CSR）流程縮短至僅10分鐘。這項突破性的成就歸功於他們開發的NovoScribe工具，它結合了多種先進技術：

• 使用Claude 3和ChatGPT作為聊天完成模型
• 採用Amazon Bedrock服務上的Titan進行文字嵌入
• 透過MongoDB Atlas向量搜尋作為知識函式庫相關資料

NovoScribe的核心功能在於生成符合定義內容規則的驗證文字。系統會計算每個文字片段與相關統計資料的相似度，然後將這些資訊輸入結構化提示，讓大語言模型（LLM）生成準備好供工作者審核的報告，包含所有呈現資料的來源追蹤。

諾和諾德公司的Tobias Kröpelin博士解釋：「MongoDB Atlas的優勢在於我們可以將報告的原生向量嵌入與所有相關文字片段和元資料一起儲存。這意味著我們能夠快速執行強大與複雜的查詢。對於每個向量嵌入，我們可以根據來源檔案、作者和時間進行篩選。」

透過在MongoDB中智慧地組織資料並定義向量搜尋索引，諾和諾德建立了一個先進的臨床報告生成系統。他們利用創新的嵌入模型和LLM，大幅改進了CSR編寫流程。

向量搜尋最佳實踐核心原則

在實作向量搜尋時，關注幾個核心領域能顯著提升結果品質和系統效能：智慧資料建模、適當的佈署模型選擇，以及針對原型與生產環境的特定考量。遵循這些最佳實踐，不僅能提高搜尋結果的準確性，還能確保系統以可擴充套件、生產就緒的方式運作。

資料建模：向量搜尋的根本

在MongoDB環境中，資料建模指的是設計資料庫存資料結構的過程。與傳統關聯式資料函式庫，MongoDB是一種NoSQL資料函式庫用靈活、無模式的模型，允許更動態和層次化的資料儲存。

向量搜尋的資料建模核心理念是：嵌入模型的能力並非無限，開發者可以透過將向量與其他相關資料結合，來掌控搜尋相關性問題。這種控制可以透過簡單的方式實作，例如整合使用者基礎欄位進行元資料過濾；也可以採用更複雜的方式，如使用LLM定義區塊間的圖形關係，並在$vectorSearch查詢後進行查詢。

利用元資料的廣義思考方式是：使用檔案而非向量來向使用者傳遞資料。使用檔案作為聚合階段的結果意味著不同的聚合階段可以組合在一起，產生比單獨一個階段更強大的功能，並能受益於查詢最佳化。這一直是MongoDB檔案模型的核心優勢，在生成式AI應用時代仍然適用。

過濾策略：提升搜尋效率與準確性

元資料使用的最基本與最有效形式是透過預先過濾限制向量搜尋的範圍。這會限制要考慮的有效檔案範圍，對於選擇性過濾器（最常見的過濾器類別）來說，這能提高準確性並降低查詢延遲。

在查詢時，這些預先過濾可以使用$match MQL語法作為$vectorSearch查詢的一部分。這意味著除了點過濾器（如$eq）外，使用者還可以定義範圍過濾器（如$gt或$lt），只對符合某值範圍的檔案進行搜尋，而非比對特定值。這可以大幅減少需要搜尋的有效檔案數量，降低需要完成的工作量，並通常提高搜尋準確性。$match過濾器還可以利用邏輯運算元（如$and和$or）允許使用者組合過濾器，並在搜尋應用中建立更複雜的邏輯。

讓我們看兩種常見的過濾器類別，以及何時如何使用它們。

動態過濾器

動態過濾器是根據搜尋查詢內容而變化的元資料片段。這些可以是資料的屬性，例如書籍的出版時間或價格。它們通常由使用者在執行搜尋時與自然語言查詢一起選擇。以下是一個例子：

[
  {
    "_id": ObjectID("662043cfb084403cdcf5210a"),
    "paragraph_embedding": [0.43, 0.57, ...],
    "page_number": 12,
    "book_title": "A Philosophy of Software Design",
    "publication_year": 2018
  },
  {
    "_id": ObjectID("662043cfb084403cdcf5210b"),
    "paragraph_embedding": [0.72, 0.63, ...],
    "page_number": 6,
    "book_title": "Design Patterns: Elements of Reusable Object-Oriented Software",
    "publication_year": 1994
  },
  {
    "_id": ObjectID("662043cfb084403cdcf5210c"),
    "paragraph_embedding": [0.12, 0.48, ...],
    "page_number": 3,
    "book_title": "Guide to Fortran",
    "publication_year": 2008
  }, ...
]

動態過濾器在建立語義搜尋應用時最為常見，因為它們通常由使用者在搜尋欄中執行查詢前輸入。這與RAG介面形成對比，後者完全使用自然語言。

靜態過濾器與多租戶

有些情況下，過濾器與查詢主體無關，而是與使用者的個人資料相關聯。使用者可能在查詢只有其公司可以存取的資料，但這些資料與許多其他租戶的資料一起以多租戶方式儲存。在這種情況下，使用者ID或使用者所屬的公司ID可用於過濾搜尋結果。對於租戶數量多但向量數量少的情況，過濾器是推薦的資料建模方法，而非將許多資料分散在多個集合和索引中。

當租戶間向量數量差異大與在同一集合或索引中建模的租戶數量多時，建議在$vectorSearch中將exact標誌設定為true。這將導致對應於向量索引的所有段執行平行的詳盡搜尋。在許多情況下，考慮到過濾器的高度選擇性和執行過濾HNSW搜尋時需要搜尋和丟棄的大量潛在向量，這將加速搜尋。

智慧分塊策略：提升向量搜尋效果

在檢索增強生成（RAG）的環境中，出現了一個有趣的類別比。就像聊天模型需要智慧的提示工程一樣，嵌入模型需要智慧的分塊處理。智慧分塊需要找到可以有效對映到搜尋或自然語言查詢的適當連貫的背景與環境級別。這也可能是提供給LLM的適當連貫的背景與環境級別，但如果你智慧地建模資料，這並非嚴格要求。

固定令牌數與重疊分塊法

固定令牌數與重疊是許多RAG整合框架（如LangChain）中的常見預設設定，它根據每個區塊的指定最大令牌數和區塊間的期望重疊來分割非結構化資料。這種方法比整頁攝取方法更精細，允許在特定資料集上進行更多實驗。它不涉及利用非結構化資料中的任何結構，這在開發簡單性方面是積極的，但當句子、段落或其他邊界以你想要建模的方式標示語義重要性時，可能是消極的。

如果你對源資料控制有限，或使用不適合利用檔案結構（如HTML標籤）的邊界分塊方法的非結構化資料，這種技術可能是一個好選擇，因為它與任何文字格式相容。

下面是一個範例，不同顏色表示不同的區塊和重疊部分：

Hierarchical NSW incrementally builds a multi-layer structure consisting of a hierarchical
set of proximity graphs (layers) for nested subsets of the stored elements.

實驗與最佳化

評估哪種分塊策略或嵌入模型最適合你的使用案例，需要製作檔案判斷列表以及你期望對映到這些檔案的查詢。你還需要嘗試在嵌入資料前可以應用的不同嵌入模型和分塊策略，看哪種最適合你的使用案例。

特定嵌入模型可能在固定分塊策略下表現更好或更差。你可以更容易評估哪種分塊和嵌入模型組合最適合你的使用案例。你可以有同一資料的多個版本，每個版本以不同方式分割和處理。透過比較這些版本，你可以確定最適合特定搜尋需求的最佳分割方法和嵌入模型。

確定嵌入模型是否有效地將檔案對映到範例查詢的最佳方法是檢查詢檔案集合回傳的相似度分數，並檢視它與實際問題的良好回應的比對程度，如下表所示：

對於固定令牌數與重疊策略，你需要確定想要開始的令牌數。在訊息檢索社群中，300-500令牌範圍對實驗來說似乎足夠。

混合搜尋策略：結合多種相關性來源

混合搜尋涉及在單一檔案中建模多個相關性來源，並在查詢時與單一向量搜尋一起考慮它們。這種技術體現了MongoDB支援的聚合管道的靈活性，允許大量實驗和調整搜尋系統，利用向量搜尋、詞彙搜尋、傳統資料函式庫、地理空間查詢等。

讓我們探索一些更流行的混合搜尋方法，以及你可能發現與你的使用案例相關的一些有前景的探索方向。

向量與詞彙搜尋結合

向量搜尋是一種利用查詢與索引檔案之間語義相似性的可靠方法，這種相似性由嵌入模型的能力定義。像BM25這樣的詞彙搜尋系統（Lucene以及相應的Atlas Search使用）以完全不同的方式提供幫助，它們直接索引標記並使用詞袋式方法，根據查詢詞在每個檔案中的出現情況對一組檔案進行排名，而不考慮它們在檔案中的接近程度。

儘管根據20世紀80年代開發的原始機率檢索框架，這種方法在將查詢中的關鍵字對映到檔案中的關鍵字方面仍然相當好，特別是當該詞在嵌入模型訓練連貫的背景與環境之外使用時。小型資料集可能包含訓練資料集中未見過或具有替代含義的標記。

在我多年的向量搜尋實踐中，發現混合搜尋策略對於處理冷啟動問題特別有效。當使用者查詢包含特殊術語或領域專有名詞時，純向量搜尋可能會因為這些詞彙在預訓練模型中表示不足而失效。透過結合詞彙搜尋，我

向量搜尋的多元應用策略

混合搜尋：結合向量與傳統檢索技術

在實際應用中，純粹的向量搜尋雖然強大，但往往無法滿足所有搜尋需求。我在設計多個企業級搜尋系統時發現，結合向量搜尋和詞彙搜尋（lexical search）的混合方法能帶來更全面的搜尋體驗。

向量搜尋擅長處理語意相似性，而傳統的詞彙搜尋則在處理關鍵字、專有名詞和術語方面表現出色。這兩種方法各有優勢，如下圖所示：

有些向量搜尋提供者也嘗試提供稀疏向量搜尋作為詞彙搜尋的替代方案，但這種方法通常缺乏詞彙搜尋的許多內建功能，如同義詞列表、分頁和分面搜尋等。

MongoDB 允許開發者充分實驗這些策略，同時支援根據外部鍵（而非僅限於檔案 _id）的聯合查詢模式。這使得開發者可以為同一檔案建立不同層級的表示，並由不同的搜尋方法處理。以下是一個例項，展示如何同時使用向量搜尋和文字搜尋：

[
  {
    "_id": ObjectID("662043cfb084403cdcf5210d"),
    "page_number": 81,
    "paragraph_embedding": [0.43, 0.91, ...],
  },
  {
    "_id": ObjectID("662043cfb084403cdcf5210e"),
    "full_page_content": "Pulling complexity down makes the most sense if (a) the complexity being pulled down is closely related to the class's existing functionality, (b) pulling the complexity down will result in many simplifications elsewhere in the application, and (c) pulling the complexity down simplifies the class's interface. ...",
    "page_number": 36,
  }, ...
]

這種聯合考慮兩種查詢結果集的方法就是所謂的混合搜尋，可以使用倒數排名融合（reciprocal rank fusion）方法實作。MongoDB

智慧型應用程式設計的關鍵考量

在智慧型應用程式快速發展的今日，良好的架構設計已成為效能、擴充套件性和安全性的決定性因素。多年來，玄貓在設計大型AI系統時發現，許多開發者往往專注於模型建構，卻忽略了支撐這些模型的資料基礎設施設計。本文將帶領各位探索AI/ML應用程式設計的核心要素，從資料建模到安全機制，提供全面與實用的。

實際案例：MongoDB Developer News

為了讓概念更具體易懂，我們將以一個虛構的新聞應用程式 MongoDB Developer News (MDN) 為例，這是一個類別似Medium.com的內容平台。透過這個例項，我將展示如何從零開始設計一個智慧型應用程式的資料架構。

資料建模：三種資料消費者的平衡設計

設計AI/ML系統的資料模型時，必須考慮三種不同的資料消費者：人類、應用程式和AI模型。每一種消費者對資料有不同的需求和存取模式，這顯著影響我們的資料組織方式。

理解不同類別的資料

在實作MDN之前，我們需要了解三種基本的資料類別：

1. 結構化資料：遵循預定義結構，通常儲存在關聯式資料函式庫主要用於交易性資訊。這類別資料支援互動型系統和智慧型系統。

2. 非結構化資料：包括PDF、圖片、影片等二進位資產。這類別資料通常儲存在如Amazon S3的物件儲存服務中，採用靈活的目錄結構，並具有較低的儲存成本。

3. 半結構化資料：如JSON檔案，允許每個檔案定義自己的結構，能夠容納共同和獨特的資料點，甚至可以缺少某些資料。

MDN的資料模型設計

對於MDN應用，我們需要儲存新聞文章、訂閱者資料、帳單資訊等。為了簡化，本文將專注於新聞文章及其相關二進位內容（主要是圖片）的資料模型。

文章集合的基本結構

文章集合代表一篇新聞文章及其元資料，包括建立詳情、標籤和貢獻者。所有檔案都包含標題、摘要、HTML和純文字格式的內文，以及相關的媒體元素，如圖片。

{
  "_id": ObjectId("..."),
  "title": "MongoDB Atlas Vector Search功能深度解析",
  "summary": "本文探討MongoDB最新的向量搜尋功能及其在AI應用中的實際應用案例",
  "body_html": "<p>MongoDB最近推出了...</p>",
  "body_text": "MongoDB最近推出了...",
  "created_at": ISODate("2023-09-15"),
  "updated_at": ISODate("2023-09-16"),
  "author_id": ObjectId("..."),
  "brand": "tech",
  "subscription_type": "premium",
  "tags": ["database", "vector-search", "ai"],
  "contributors": [
    { "user_id": ObjectId("..."), "role": "editor" }
  ],
  "contents": [
    {
      "_id": ObjectId("..."),
      "type": "image",
      "url": "https://storage.example.com/images/abc123.jpg",
      "alt_text": "MongoDB Vector Search架構圖"
    }
  ]
}

使用向量嵌入增強資料

為了支援語義搜尋和相似圖片查詢，我們需要為文章的標題、摘要和圖片建立向量嵌入。下表描述了需要的嵌入欄位、使用的嵌入模型和向量大小：

為了簡化，我們將標題和摘要連線起來，建立一個文字嵌入。理想情況下，對於圖片，我們會將嵌入儲存在contents陣列的每個物件中。然而，目前MongoDB Atlas不支援在物件陣列中的欄位上建立向量索引，這會導致檔案膨脹的反模式。

最佳做法是將圖片嵌入儲存在單獨的集合中，並使用擴充套件參照模式。這種方法解決了檔案大小限制問題，並提供了更好的查詢效能。

更新後的資料模型

考慮到搜尋需求，我們對MDN的資料模型進行了更新：

1. 文章集合：包含文章基本資訊和語義嵌入
2. 文章內容嵌入集合：儲存圖片嵌入和相關元資料

修改後的文章內容嵌入集合結構如下：

{
  "_id": {
    "article_id": ObjectId("..."),
    "content_id": ObjectId("...")
  },
  "content_embedding": [0.1, 0.2, ...],  // 768維向量
  "brand": "tech",
  "subscription_type": "premium"
}

為搜尋使用案例定義索引

為支援不同的搜尋需求，我們需要建立以下索引：

1. 語義嵌入向量索引：用於文章集合中的語義搜尋

{
  "fields": [
    {
      "numDimensions": 1024,
      "path": "semantic_embedding",
      "similarity": "cosine",
      "type": "vector"
    },
    {
      "path": "brand",
      "type": "filter"
    },
    {
      "path": "subscription_type",
      "type": "filter"
    }
  ]
}

2. 內容嵌入向量索引：用於文章內容嵌入集合中的相似圖片搜尋

{
  "fields": [
    {
      "numDimensions": 768,
      "path": "content_embedding",
      "similarity": "cosine",
      "type": "vector"
    },
    {
      "path": "brand",
      "type": "filter"
    },
    {
      "path": "subscription_type",
      "type": "filter"
    },
    {
      "path": "_id.article_id",
      "type": "filter"
    }
  ]
}

3. 詞彙搜尋索引：用於文章集合中的文字搜尋

{
  "mappings": {
    "dynamic": false,
    "fields": {
      "brand": {
        "normalizer": "lowercase",
        "type": "token"
      },
      "subscription_type": {
        "normalizer": "lowercase",
        "type": "token"
      },
      "summary": {
        "type": "string"
      },
      "tags": {
        "normalizer": "lowercase",
        "type": "token"
      },
      "title": {
        "type": "string"
      }
    }
  }
}

在建立這些索引後，我們可以實作三種主要的搜尋功能：

1. 透過標題和摘要進行詞彙或語義比對，並根據品牌和訂閱類別進行過濾
2. 擴充套件第一種搜尋功能，包括標籤
3. 尋找使用相似圖片的其他文章，並根據品牌和訂閱類別進行過濾

這種混合搜尋方式結合了語義和詞彙搜尋，使用倒數排名融合技術，為使用者提供更準確的搜尋結果。

資料儲存：容量規劃與叢集設定

完成資料模型設計後，我們需要考慮MDN的儲存需求，包括容量大小、速度和其他資料函式庫設定。這些因素對於支援應用程式的資料存取模式至關重要。

儲存需求估算

根據MDN的規劃，每天將發布100篇文章，保留最近5年的文章，總計182,500篇。假設有4,800萬訂閱者和2,400萬日活躍使用者，高峰存取時間分佈在三個主要時區的30分鐘內。

首先，我們估算總資料大小：

• 每篇文章有一個1,024維的語義搜尋嵌入和五個768維的圖片搜尋嵌入，未壓縮總計約40KB
• 加上標題、摘要、正文（有和無標記）和其他欄位，平均每篇文章大小約為300KB（未壓縮）

5年的文章將需要約100GB未壓縮空間。使用MongoDB的WiredTiger壓縮（可選Snappy、zlib或zstd），這將減少到磁碟上約50GB。定義的向量索引額外增加約3.6GB。圖片和二進位資產將儲存在Amazon S3中。

簡化起見，我們不估計搜尋和傳統索引的大小。整體而言，MDN在MongoDB Atlas上需要80-100GB的磁碟空間，這在當今的雲端運算標準下是非常可管理的。

確定資料函式庫類別

MongoDB Atlas提供兩種主要的叢集類別：

1. 複製集：有一個主節點處理寫入，和次要節點提供高用性，次要節點也可用於讀取。這些集合可以垂直擴充套件，也可以透過在相同或不同雲區域增加更多節點來水平擴充套件讀取。

2. 分片叢集：由多個分片組成，每個分片是整體資料集的一部分，每個分片都是一個複製集。它們可以垂直和水平擴充套件讀取和寫入。分片可以放置在不同的雲區域，以增強資料位置和合規性。

如何確定是否需要分片叢集？關鍵因素包括資料集大小或應用程式的吞吐量是否超出單一伺服器的容量。例如，高查詢率可能耗盡伺服器的CPU容量，而大於系統RAM的工作集大小可能對硬碟的I/O容量造成壓力。

對於MDN，每天發布100篇文章，分片並非必要。其他分片原因如資料治理、合規性和災難還原策略（RPO和RTO）也不適用於MDN。

考慮到每秒寫入次數少與資料大小可管理，使用複製集是合理的選擇。

確定IOPS需求

MDN是一個低寫入、高讀取的應用案例。每天只新增100篇文章，對儲存系統的寫入壓力很小。MongoDB Atlas提供不同的儲存和IOPS選項，包括：

• 標準IOPS：從3,000 IOPS/10GB到16,000 IOPS/14TB
• 佈建IOPS：從100 IOPS/10GB到64,000 IOPS/4TB
• NVMe：從100,125隨機讀取IOPS/380GB到3,300,000隨機讀取IOPS/4,000GB

根據使用者分佈，預計每天有2,400萬活躍使用者，高峰期為30分鐘。假設每篇文章需要3個IOPS用於磁碟讀取（150KB壓縮÷64KB I/O大小），我們需要佈建6,000 IOPS。

RAM需求與工作集大小

RAM需求取決於工作集大小，即活躍資料集的大小。對於MDN，這包括：

1. 熱門文章：假設10%的文章產生90%的流量，這些文章需要常駐在記憶體中
2. 索引：向量索引和傳統索引需要儲存在RAM中以獲得最佳效能
3. 連線和查詢開銷：處理使用者連線和查詢的額外記憶體需求

考慮到這些因素，我們估計MDN需要約16GB的RAM。

選擇最適合的MongoDB Atlas叢集

根據上述分析，我們為MDN選擇了以下MongoDB Atlas設定：

• 叢集類別：複製集（而非分片叢集）
• 儲存：標準IOPS，100GB儲存空間
• RAM：16GB
• IOPS：6,000 IOPS（足以處理高峰期讀取需求）
• 佈署模式：多區域佈署，以提供全球覆寫和低延遲

這種設定提供了良好的價效比，同時確保應用程式在高峰期能夠流暢執行。

資料流：

MongoDB Atlas全球架構設計：支援AI應用的最佳實踐

在設計支援AI和機器學習功能的全球性應用時，資料架構扮演著至關重要的角色。隨著使用者遍佈全球各地，應用程式必須能夠提供低延遲、高用性的體驗，同時有效管理資源成本。本文將探討一個名為MDN（Media Distribution Network）的全球內容平台案例，分析其MongoDB Atlas叢集設定策略、資源需求評估及資料流設計。

全球區域資源分配策略

MDN平台的使用者分佈在全球不同區域，這決定了我們需要採取分散式架構設計。根據使用者分佈資料，我們可以看到：

從上表可以看出，在全球尖峰使用時段（考慮時區重疊），系統需要支援至少6,000 IOPS的讀取能力。這個資料是我們設計MongoDB Atlas叢集時的關鍵參考點。

IOPS需求分析與叢集規劃

在AWS上的標準MongoDB Atlas叢集最低提供3,000 IOPS。要達到6,000 IOPS，我們需要使用Atlas M50層級並設定2TB磁碟空間。然而，如果僅佈署在單一雲端區域，這種設定不僅資源過度設定，還無法為全球使用者提供低延遲體驗。

更有效的方案是在主要地理區域佈署應用程式堆積積疊，實作區域性資源設定、工作負載分散和本地讀取，從而提供最佳的客戶體驗。使用MongoDB Atlas，我們可以跨區域放置向量搜尋節點：

1. 向量搜尋節點設定：S40層級提供26,875讀取IOPS，足以滿足需求，每個區域至少兩個節點以確保高用性。
2. 資料節點設定：為支援完全本地讀取，我們需要在相同區域設定唯讀節點，並滿足IOPS要求，可以使用Atlas M40層級。

RAM需求評估

對於資料節點，Atlas M40層級提供16GB RAM。MongoDB的WiredTiger儲存引擎會保留(RAM - 1GB)的50%用於其快取。以平均300KB的檔案大小計算：

可用快取空間 = (16GB - 1GB) × 50% = 7.5GB
可快取檔案數量 ≈ 7.5GB ÷ 300KB ≈ 28,000檔案

考慮到每天新增100篇文章，M40層級的快取可容納約280天（大約9個月）的資料，這對我們的案例已經綽有餘。

對於向量搜尋，S40層級提供16GB RAM、2個vCPU和100GB儲存空間。向量索引（HNSW圖）必須適合記憶體：

單篇文章向量大小 = 1 × 1,024向量 + 5 × 768向量 = 19.5KB
總向量索引大小 = 19.5KB × 182,500篇文章 ≈ 3.5GB

16GB RAM遠超過向量搜尋的需求，還為詞彙搜尋索引留下充足空間。

最終叢集設定方案

經過詳細分析，我們確定了MDN的全球叢集設定：

這種設定策略有以下考量：

1. 成本效益平衡：在美洲區域未額外設定唯讀節點，而是使用兩個次要節點作為唯讀節點，這在MDN低寫入模式下節省成本，儘管可能存在資源競爭。
2. 可用性與延遲權衡：在其他區域僅設定一個M40唯讀節點可進一步節省成本，但在維護視窗期間會增加延遲，因為讀取將被重新路由。
3. 災難還原考量：為防止美洲區域完全中斷，同時遵循最佳實踐，可考慮在三個區域設定五個節點，並在有兩個可選節點的兩個區域佈署應用程式堆積積疊。

在我多年設計分散式系統的經驗中，這種權衡是常見的。關鍵在於根據應用特性找到效能、可用性與成本之間的最佳平衡點。

資料流設計：確保AI應用中的資料高效流動

資料流涉及資料在系統中的移動，直接影響提供給使用者的結果的準確性、相關性和速度，進而影響使用者參與度。我們需要考慮如何處理資料來源、處理資料、提示大語言模型(LLM)和嵌入模型來豐富資料。

處理靜態資料來源

最簡單的靜態資料匯入方法是使用mongoimport，它支援JSON、CSV和TSV格式，適用於初始載入或批次更新，可處理大型資料集。透過增加插入工作者數量以比對主機的vCPU數，可以提高匯入速度。

mongoimport也可以動態更新外部來源的資料。開發者可以在執行時構建呼叫命令，並將其作為程式外任務執行。例如，一些遊戲公司使用此方法從移動應用商店更新玩家的購買資料。

以MDN為例，使用者可以在訂閱時提供GitHub ID。透過GitHub API，我們可以建立使用者擁有或貢獻的儲存函式庫用的程式語言列表。定期排程作業可以取得這些資料，然後匯入並合併到使用者資料中，用於後續文章推薦。

// 檔案: github-20240719.json
{ "github_id" : "user1", "languages" : ["python", "csharp"], ...}
{ "github_id" : "user2", "languages" : ["python", "cpp"], ...}

// 集合: mdn.subscribers
{ "_id" : ObjectId("669...ab8"), "github_id" : "user1", ... }
{ "_id" : ObjectId("669...ab9"), "github_id" : "user2", ... }

使用mongoimport根據github_id欄位合併資料的命令：

mongoimport --uri=<連線到Atlas叢集的連線字串>
--db=mdn --collection=subscribers --mode=merge
--file=github-20240719.json --upsertFields=github_id
--numInsertionWorkers=4

合併後的結果：

// 集合: mdn.subscribers 合併後
{ "_id" : ObjectId("669...ab8"), "github_id" : "user1", "languages" : ["python", "csharp"], ... }
{ "_id" : ObjectId("669...ab9"), "github_id" : "user2", "languages" : ["python", "cpp"], ... }

雖然mongoimport是一個多功能工具，但它不支援持續同步、邏輯執行或資料轉換。接下來我們將探討一些支援這些功能的方法。

儲存豐富向量嵌入的操作資料

當原始表示被儲存或更新時，相應的向量嵌入必須重新整理以準確反映內容。這可以透過以下方式完成：

同步處理方式

在資料函式庫前取得更新的向量嵌入，同時寫入資料和嵌入。這種方法適用於快速、簡單的嵌入模型或當模型本地託管時。然而，如果嵌入模型的回應時間變化大，這種方法可能會失敗。

非同步處理方式

確保主要資料的即時一致性，並允許之後提示嵌入模型。雖然這提供了可擴充套件性並處理了不可預測的模型，但會引入延遲，在此期間嵌入暫時過時。

在MongoDB中，我們可以使用以下四種方法非同步地保持嵌入的最新狀態：

1. Kafka聯結器：透過Kafka聯結器促進Apache Kafka與MongoDB集合之間的資料流。這是Confluent驗證的聯結器，允許資料從Apache Kafka主題流入MongoDB集合作為資料接收器，並將MongoDB的變更發布到Kafka主題作為資料源。

2. Atlas流處理：此方法使用與MongoDB Atlas資料函式庫的查詢API處理複雜的資料流。它啟用持續聚合，包括訊息完整性的架構驗證和及時問題檢測。處理後的資料可以寫入Atlas集合。

3. Atlas觸發器：Atlas觸發器透過回應事件或遵循預定義的排程來執行應用程式和資料函式庫。每個觸發器監聽特定事件類別，並連結到Atlas函式。當發生比對事件時，觸發器啟動並將事件物件傳遞給連結的函式。

4. 變更流：此方法提供對資料變更的實時存取。應用程式可以訂閱集合、資料函式庫個佈署中的變更並立即反應，事件按順序處理並可還原。使用聚合框架，變更流允許過濾和轉換通知。

作為Python開發者，我發現變更流特別實用。以下是一個使用LangChain和OpenAI嵌入MDN文章標題和摘要的Python 3變更流範例：

import os
from langchain_openai import OpenAIEmbeddings
from pymongo import MongoClient
from pymongo.errors import PyMongoError

# 設定OpenAI API金鑰
os.environ["OPENAI_API_KEY"] = "your_openai_api_key"

# 初始化OpenAI嵌入模型
embeddings = OpenAIEmbeddings(
    model="text-embedding-3-large", # 使用最新的OpenAI嵌入模型
    dimensions=1024                 # 設定向量維度為1024
)

# 連線到MongoDB Atlas
client = MongoClient("your_mongodb_atlas_connection_string")
db = client.mdn
collection = db.articles

# 定義一個函式來處理變更事件
def process_change(change_event):
    # 只處理插入和更新操作
    if change_event['operationType'] in ['insert', 'update']:
        document = change_event['fullDocument']
        
        # 檢查檔案是否包含所需欄位
        if 'title' in document and 'summary' in document:
            try:
                # 組合標題和摘要為一個文字
                text_to_embed = f"{document['title']} {document['summary']}"
                
                # 生成向量嵌入
                title_summary_embedding = embeddings.embed_query(text_to_embed)
                
                # 更新檔案，增加嵌入
                collection.update_one(
                    {"_id": document["_id"]},
                    {"$set": {"title_summary_embedding": title_summary_embedding}}
                )
                print(f"Updated embedding for article: {document['title']}")
                
            except Exception as e:
                print(f"Error generating embedding: {e}")

# 設定變更流管道，只監視插入和更新操作
pipeline = [
    {"$match": {"operationType": {"$in": ["insert", "update"]}}},
    {"$match": {"updateDescription.updatedFields.title": {"$