LangChain 課程 – Embedding：向量嵌入

主題：Embedding 模型選擇

---

簡介

在 LangChain 生態系統裡，向量嵌入（Embedding）是將文字、程式碼或文件轉換成固定長度數值向量的核心技術。這些向量能夠在向量資料庫（如 Pinecone、Chroma、FAISS）中進行相似度搜尋，從而驅動檢索增強生成（RAG）等高階應用。
選對 Embedding 模型，不僅影響搜尋的精準度，也直接關係到成本、延遲與可擴展性。本文將從模型類型、效能指標、成本考量等面向，說明如何在 LangChain 專案中挑選最適合的 Embedding 模型，並提供完整的程式碼範例與實務建議。

---

核心概念

1. 為什麼要比較不同的 Embedding 模型？

觀點	影響
語意表達能力	大型語言模型（如 OpenAI text-embedding-3-large）能捕捉更細緻的語意差異，適合多領域、長文本。
回應速度	輕量模型（如 sentence-transformers/all-MiniLM-L6-v2）推論速度快，適合即時互動或高併發服務。
成本	OpenAI、Azure 等雲端 API 按字數計費；本地模型則需要 GPU 或 CPU 資源，前期投資較高。
資料隱私	本地模型可完全掌控資料，符合 GDPR、醫療資訊等合規需求。

小結：在選擇模型前，先釐清「精準度」與「效能/成本」的權衡點，才能避免日後重構系統。

2. 常見 Embedding 模型類型

類型	代表模型	授權	特色
OpenAI API	text-embedding-3-large、text-embedding-3-small	商業授權	高品質、即時可用、支援多語言
Azure OpenAI	text-embedding-ada-002（已被 text-embedding-3 取代）	商業授權	與 Azure 生態整合，計費方式相同
HuggingFace 🤗	sentence-transformers/all-MiniLM-L6-v2、intfloat/multilingual-e5-large	開源（MIT/Apache）	可自行部署、支援多語言、可微調
Cohere	embed-english-v3.0、embed-multilingual-v3.0	商業授權	低延遲、支援自訂欄位
自建模型	例如 bge-large-en（BAAI）	開源	完全掌控、可離線運算

3. 評估指標

1. 向量維度：常見 384、768、1024。維度越高，表達力越強，但索引與搜尋成本也會上升。
2. 相似度測試：使用 Cosine Similarity 或 Inner Product，對同義句、相似問題做基準測試。
3. 吞吐量（TP/s）：每秒可處理多少條文字。可透過 timeit 或 benchmark 套件測試。
4. 成本：API 每 1,000 token 的價格 vs 本地 GPU 計算成本（電費 + 硬體折舊）。

---

程式碼範例

以下範例均使用 LangChain（Python） 搭配不同的 Embedding 提供者，示範如何在同一程式中快速切換模型。

3.1 基本設定：建立 Embedding 工廠

from langchain.embeddings import OpenAIEmbeddings, HuggingFaceEmbeddings, CohereEmbeddings
from langchain.vectorstores import FAISS

def get_embedding(model_name: str):
    """
    依照傳入的 model_name 回傳對應的 Embedding 物件。
    支援: openai, hf-mini, hf-multi, cohere
    """
    if model_name == "openai":
        return OpenAIEmbeddings(model="text-embedding-3-large")
    elif model_name == "hf-mini":
        return HuggingFaceEmbeddings(model_name="sentence-transformers/all-MiniLM-L6-v2")
    elif model_name == "hf-multi":
        return HuggingFaceEmbeddings(model_name="intfloat/multilingual-e5-large")
    elif model_name == "cohere":
        return CohereEmbeddings(model="embed-english-v3.0")
    else:
        raise ValueError(f"Unsupported model: {model_name}")

3.2 建立向量資料庫（FAISS）並加入文件

documents = [
    {"id": 1, "text": "LangChain 可以讓 LLM 與外部工具串接"},
    {"id": 2, "text": "向量嵌入是檢索增強生成的基礎"},
    {"id": 3, "text": "選擇合適的模型能降低成本與提升效能"},
]

def build_faiss(docs, embedding):
    texts = [doc["text"] for doc in docs]
    # 建立 FAISS 索引
    vectordb = FAISS.from_texts(texts, embedding)
    return vectordb

# 範例：使用 openai 模型
embed = get_embedding("openai")
faiss_db = build_faiss(documents, embed)

3.3 相似度搜尋範例

query = "什麼是向量檢索？"
# 直接使用 FAISS 的相似度搜尋
results = faiss_db.similarity_search(query, k=2)

print("=== 最相似的 2 筆文件 ===")
for r in results:
    print(f"- {r.page_content}")

輸出示例

=== 最相似的 2 筆文件 ===
- 向量嵌入是檢索增強生成的基礎
- LangChain 可以讓 LLM 與外部工具串接

3.4 比較不同模型的相似度分數

def compare_models(query, docs):
    models = ["openai", "hf-mini", "hf-multi", "cohere"]
    for m in models:
        embed = get_embedding(m)
        db = build_faiss(docs, embed)
        scores = [db.similarity_score_with(query, doc["text"]) for doc in docs]
        avg_score = sum(scores) / len(scores)
        print(f"{m:10} -> 平均相似度分數: {avg_score:.4f}")

compare_models("向量嵌入的應用", documents)

說明：similarity_score_with 為自訂輔助函式，會回傳 Cosine Similarity。透過此方式，我們可以快速觀察 模型精度 與 語意捕捉能力 的差異。

3.5 結合本地 GPU 加速（使用 HuggingFace + PyTorch）

from langchain.embeddings import HuggingFaceEmbeddings

# 設定使用 GPU（若環境支援）
embed_gpu = HuggingFaceEmbeddings(
    model_name="sentence-transformers/all-MiniLM-L6-v2",
    model_kwargs={"device": "cuda"}   # 只要有 CUDA 即可
)

faiss_gpu = build_faiss(documents, embed_gpu)

# 測試效能
import time
start = time.time()
_ = faiss_gpu.similarity_search("LangChain 的優勢", k=3)
elapsed = time.time() - start
print(f"GPU 推論耗時: {elapsed:.3f} 秒")

提示：若 GPU 記憶體不足，將 device 改為 "cpu"，或改用較小的模型（如 all-MiniLM-L12-v2）。

---

常見陷阱與最佳實踐

陷阱	說明	最佳實踐
向量維度不一致	不同模型產出的向量長度不同，直接混用會導致搜尋錯誤。	統一維度：在同一資料庫內只使用同一模型，或在插入前先 投影（projection） 到相同維度。
忘記正規化	有些模型輸出已正規化（unit‑vector），有些則未正規化，導致相似度計算偏差。	明確正規化：使用 np.linalg.norm 或 sklearn.preprocessing.normalize 統一處理。
過度依賴單一模型	某些領域（醫療、法律）需要專業語料，通用模型表現不佳。	領域微調：使用 HuggingFace 的 SentenceTransformer 進行微調，或結合 多模型（ensemble）策略。
忽視成本警示	大模型 API 可能在大量資料時產生高額費用。	成本上限：在程式中加入 token 計算 與 預算檢查，必要時切換至本地模型。
向量資料庫未調整參數	FAISS、Pinecone 等索引的參數（如 nlist、nprobe）若未優化，搜尋速度會受限。	參數調校：根據資料量與查詢頻率調整索引參數，並使用 測試集 評估延遲。

---

實際應用場景

1. 客服聊天機器人
   • 使用 OpenAI text-embedding-3-large 為客戶問題產生高品質向量，配合 Pinecone 做即時相似度搜尋，提供最相關的 FAQ 回答。
2. 企業內部知識庫
   • 由於資料敏感，部署 HuggingFace intfloat/multilingual-e5-large 在自家 GPU 伺服器，結合 Chroma 作離線索引，確保資料不離開公司網路。
3. 多語言內容推薦
   • 透過 Cohere embed-multilingual-v3.0 同時支援英文、中文、日文，將文章向量化後在 Weaviate 中做相似度搜尋，提供跨語言的內容推薦。
4. 長文件檢索（Legal、醫療）
   • 先使用 段落切分（Chunking），再以 BGE-large-en（高維度、精度）產生向量，最後使用 FAISS IVF‑PQ 進行大規模檢索，適合上千篇長文件的法條比對。

---

總結

• Embedding 模型的選擇 必須同時考量 語意表達力、效能、成本與資料隱私。
• 透過 LangChain 的統一介面，開發者能在程式碼層面快速切換 OpenAI、Cohere、HuggingFace 等提供者，並在同一個向量資料庫中測試不同模型的表現。
• 實務上，建議先在小樣本上跑 相似度基準測試，再根據 吞吐量、成本上限 逐步擴展至全量資料。
• 最後，別忘了 正規化、維度一致性與索引參數調校，這些細節往往是系統成功與失敗的分水嶺。

透過本文的概念與範例，你已掌握在 LangChain 中挑選與切換 Embedding 模型的完整流程，接下來就可以依照自己的產品需求，建立高效、具成本效益的向量檢索服務了。祝開發順利！