Embedding 與向量檢索
前言
電腦怎麼理解「貓和狗很像，但和汽車不像」這件事？ 對人類來說這是常識，但對電腦來說，「貓」、「狗」、「汽車」不過是三個毫無關聯的字串。Embedding（嵌入）技術就是解決這個問題的關鍵——它把文字變成數字向量，讓電腦也能理解語意上的「遠近親疏」。
這篇文章會帶你學什麼？
學完這章後，你將獲得：
- 直覺理解：明白 Embedding 是什麼，為什麼「貓」和「狗」的向量會靠近
- 相似度計算：掌握餘弦相似度、歐氏距離等核心度量方法
- 索引原理：理解向量資料庫如何在百萬級資料中毫秒級檢索
- 技術選型：了解主流向量資料庫的特點和適用場景
- 端到端流程：掌握從文字到向量到檢索的完整 Pipeline
| 章節 | 內容 | 核心概念 |
|---|---|---|
| 第 1 章 | Embedding 概念 | 語意空間、向量表示 |
| 第 2 章 | 相似度計算 | 餘弦相似度、歐氏距離 |
| 第 3 章 | 向量索引 | 暴力搜尋 vs ANN |
| 第 4 章 | 向量資料庫 | Pinecone、Milvus、Chroma |
| 第 5 章 | 端到端 Pipeline | 文字→向量→儲存→查詢 |
0. 全景圖：從文字到數字的橋樑
在自然語言處理的世界裡，有一個根本性的挑戰：電腦只認識數字，不認識文字。
早期的做法是給每個詞分配一個編號（One-Hot 編碼），比如「貓」=001，「狗」=010，「汽車」=100。但這樣做有個致命問題：所有詞之間的距離都一樣遠。「貓」到「狗」的距離和「貓」到「汽車」的距離完全相同——這顯然不符合我們的直覺。
Embedding 的革命性在於：它把每個詞映射到一個稠密的低維向量空間，讓語意相近的詞自然聚集在一起。在這個空間裡，「貓」和「狗」靠得很近，而「汽車」則在遠處——電腦終於能「理解」語意了。
從 One-Hot 到 Embedding 的飛躍
- One-Hot：維度 = 詞表大小（可能幾萬維），每個向量只有一個 1，其餘全是 0，稀疏且無語意
- Embedding：維度通常 768~1536，每個數字都有意義，稠密且富含語意資訊
- 關鍵突破：Word2Vec（2013）證明了「詞的含義可以用它的上下文來定義」，開啟了 Embedding 時代
1. Embedding 概念：把文字變成座標
Embedding 的核心思想可以用一句話概括：用一組數字（向量）來表示一個詞或句子的含義。
想像一個二維座標系。我們把「貓」放在座標 (0.2, 0.7)，「狗」放在 (0.3, 0.6)，「汽車」放在 (0.9, 0.1)。你會發現「貓」和「狗」的座標很接近，而「汽車」離它們很遠。這就是 Embedding 的直覺——語意相似度變成了空間距離。
Word Embedding Space Visualization
Semantically similar words stay closer in vector space and form natural clusters
💡 Embedding models map text into high-dimensional vector spaces, often 768 to 1536 dimensions. This demo simplifies that into 2D to show the core idea: semantically similar words have shorter vector distances。
Embedding 的三個關鍵特性
- 語意聚類：相似含義的詞會自動聚集在一起（動物一簇、食物一簇、科技一簇）
- 類比關係：向量運算可以表達語意關係，經典例子：king - man + woman ≈ queen
- 維度含義：每個維度隱式編碼了某種語意特徵（如「是否是動物」、「大小」、「情感傾向」等）
| 編碼方式 | 維度 | 語意資訊 | 典型應用 |
|---|---|---|---|
| One-Hot | 詞表大小（~50000） | 無 | 傳統 NLP |
| Word2Vec | 100~300 | 詞級語意 | 詞相似度、類比推理 |
| BERT Embedding | 768 | 上下文語意 | 句子理解、問答 |
| OpenAI text-embedding-3 | 1536~3072 | 深層語意 | RAG、語意搜尋 |
2. 相似度計算：向量之間有多「近」？
有了向量表示，下一個問題自然是：怎麼衡量兩個向量有多相似？ 這就像在地圖上衡量兩個城市有多近——你可以量直線距離，也可以看方向是否一致。
Vector Similarity Calculator
Drag vector endpoints to observe similarity metrics in real time
💡Cosine similarityfocuses only on direction and is useful for semantic text comparison; Euclidean distanceconsiders both direction and magnitude and fits absolute-distance scenarios.
兩種核心度量
- 餘弦相似度（Cosine Similarity）：衡量兩個向量的方向是否一致，值域 [-1, 1]。1 表示方向完全相同，0 表示正交（無關），-1 表示完全相反。文字語意比較的首選，因為它不受向量長度影響。
- 歐氏距離（Euclidean Distance）：衡量兩個向量端點之間的直線距離，值域 [0, ∞)。0 表示完全重合，值越大越不相似。適合需要考慮「絕對大小」的場景。
| 度量方式 | 公式直覺 | 值域 | 適用場景 |
|---|---|---|---|
| 餘弦相似度 | 看方向，忽略長度 | [-1, 1] | 文字語意搜尋、推薦系統 |
| 歐氏距離 | 看端點直線距離 | [0, ∞) | 圖片特徵、聚類分析 |
| 點積 | 方向 × 長度 | (-∞, +∞) | 正規化向量的快速計算 |
| 曼哈頓距離 | 沿座標軸走的距離 | [0, ∞) | 高維稀疏向量 |
3. 向量索引：如何在百萬向量中毫秒檢索？
假設你有 100 萬條文件，每條都轉成了 1536 維的向量。使用者提了一個問題，你需要找到最相似的 10 條。最直接的方法是逐一計算相似度——但這意味著要做 100 萬次 1536 維的向量運算，太慢了。
這就是向量索引要解決的問題：用空間換時間，透過預處理建立索引結構，讓檢索速度從 O(n) 降到近似 O(log n)。
Vector Index Strategy Comparison
Compare brute-force search with approximate nearest neighbor search
| Strategy | Time complexity | Accuracy | Use case |
|---|---|---|---|
| Brute force | O(n) | 100% | Small datasets (<10K) |
| ANN (IVF) | O(n/k) | ~95% | Large datasets (>100K) |
| HNSW | O(log n) | ~98% | High-performance retrieval |
暴力搜尋 vs 近似最近鄰（ANN）
- 暴力搜尋（Flat）：逐一比較，100% 準確但速度慢。適合資料量小（< 10 萬）的場景。
- IVF（倒排檔案索引）：先把向量空間劃分成若干區域（聚類），查詢時只搜尋最近的幾個區域。像是把圖書館按主題分區，找書時只去相關區域。
- HNSW（分層可導航小世界圖）：構建多層圖結構，從粗粒度到細粒度逐層導航。像是先看世界地圖定位到國家，再看省級地圖，最後看街道地圖。
- PQ（乘積量化）：把高維向量壓縮成短編碼，犧牲少量精度換取大幅記憶體節省。適合超大規模資料集。
| 索引類型 | 構建速度 | 查詢速度 | 召回率 | 記憶體占用 | 適用規模 |
|---|---|---|---|---|---|
| Flat（暴力） | 無需構建 | 慢 | 100% | 高 | < 10 萬 |
| IVF | 中等 | 快 | 95%+ | 中 | 10 萬~1000 萬 |
| HNSW | 慢 | 很快 | 99%+ | 高 | 10 萬~1000 萬 |
| PQ | 中等 | 快 | 90%+ | 很低 | > 1000 萬 |
| IVF-PQ | 中等 | 快 | 92%+ | 低 | > 1 億 |
4. 向量資料庫：專為向量而生的儲存引擎
有了向量和索引演算法，你需要一個地方來儲存和管理它們。傳統資料庫（MySQL、PostgreSQL）擅長處理結構化資料，但對高維向量的相似度搜尋力不從心。向量資料庫就是為這個場景專門設計的。
Mainstream Vector Database Comparison
Click a card to see details and compare use cases across vector databases
Scenario recommendations
向量資料庫的核心能力
- 高效儲存：針對高維浮點向量最佳化的儲存格式
- ANN 檢索：內建多種近似最近鄰索引演算法（HNSW、IVF 等）
- 元資料過濾：支援在向量搜尋的同時按標籤、時間等條件過濾
- 即時更新：支援動態增刪改向量，無需重建整個索引
- 水平擴展：分散式架構支援億級向量規模
| 資料庫 | 類型 | 特點 | 適用場景 |
|---|---|---|---|
| Pinecone | 全託管雲端服務 | 零維運、開箱即用 | 快速原型、中小規模生產 |
| Milvus | 開源分散式 | 高效能、可擴展 | 大規模生產環境 |
| Chroma | 開源輕量 | 嵌入式、API 簡潔 | 本地開發、小型專案 |
| Weaviate | 開源雲原生 | 內建向量化、GraphQL | 需要自動向量化的場景 |
| Qdrant | 開源高效能 | Rust 實作、過濾強 | 需要複雜過濾的場景 |
| pgvector | PG 擴充 | 複用現有 PG 基礎設施 | 已有 PostgreSQL 的團隊 |
5. 端到端 Pipeline：從文字到檢索的完整流程
理解了各個元件後，讓我們把它們串起來，看看一個完整的向量檢索系統是怎麼工作的。
整個流程分為兩條線：離線寫入（把文件變成向量存起來）和線上查詢（把問題變成向量去搜尋）。
Embedding Generation Pipeline
Step through the full conversion from text to vector
離線寫入流程
- 文件載入：從各種來源（PDF、網頁、資料庫）讀取原始文字
- 文字預處理：清洗、去雜訊、標準化（去掉 HTML 標籤、特殊字元等）
- 文字分塊：按策略將長文字切分為合適大小的片段（200~500 tokens）
- 向量化：呼叫嵌入模型（如 OpenAI text-embedding-3-small）將每個片段轉為向量
- 存入向量資料庫：將向量和原始文字、元資料一起寫入資料庫
線上查詢流程
- 接收查詢：使用者輸入自然語言問題
- 查詢向量化：用同一個嵌入模型將問題轉為向量
- 相似度檢索：在向量資料庫中搜尋 Top-K 最相似的文件片段
- 後處理：重新排序、去重複、元資料過濾
- 返回結果：將最相關的文件片段返回給呼叫方（或交給 LLM 生成回答）
| 環節 | 關鍵選擇 | 推薦方案 |
|---|---|---|
| 嵌入模型 | 精度 vs 成本 vs 速度 | OpenAI text-embedding-3-small（性價比高） |
| 分塊策略 | 粒度 vs 語意完整性 | 遞迴分塊，200~500 tokens |
| 向量資料庫 | 規模 vs 維運成本 | 小專案用 Chroma，生產用 Pinecone/Milvus |
| 相似度度量 | 語意 vs 精確 | 餘弦相似度（文字場景首選） |
| Top-K 值 | 召回率 vs 雜訊 | 先檢索 20 條，重新排序後取 Top 5 |
總結
Embedding 與向量檢索是連接「人類語言」和「機器理解」的橋樑，也是 RAG、語意搜尋、推薦系統等 AI 應用的基礎設施。
回顧本章的關鍵要點：
- Embedding 的本質：把文字映射到高維向量空間，讓語意相似度變成空間距離
- 相似度度量：餘弦相似度關注方向（適合文字），歐氏距離關注絕對距離
- 索引是效能關鍵：HNSW 和 IVF 讓百萬級向量的檢索降到毫秒級
- 向量資料庫選型：小專案用 Chroma/pgvector，生產環境用 Pinecone/Milvus
- 端到端思維：從文件載入到最終檢索，每個環節的選擇都會影響最終效果
延伸閱讀
- OpenAI Embeddings 文件 - 官方嵌入模型使用指南
- Pinecone Learning Center - 向量資料庫和檢索的系統教學
- FAISS Wiki - Facebook 開源的向量檢索庫文件
- Word2Vec 原始論文 - Embedding 時代的開山之作
- MTEB 排行榜 - 嵌入模型效能對比排行榜