先問「為什麼 keyword 不夠」，再談向量資料庫——語意相近，但用字不同時怎麼找？

假設知識庫裡有一段話：「如何在分散式系統裡保證資料不遺失？」使用者卻搜尋「多機備份會不會掉資料」。若只做關鍵字比對（倒排索引 + BM25：依詞頻／稀有度打分的關鍵字排序），兩邊幾乎沒有共同詞，結果可能是空的——但對人來說，這兩句意思很接近。

向量搜尋的做法是：先把文字（或圖片）轉成一串數字——Embedding（嵌入向量）——讓「意思接近」的內容在數字空間裡距離也接近；查詢時同樣轉成向量，找出距離最近的 Top-K 筆。承擔這件事、並在大規模下仍能毫秒級回應的系統，就是常說的向量資料庫（Vector Database）。

先建立畫面：向量就是座標；相近的意思會聚在一起。先别管 768 維，用 2D 想即可。

把每段文字想成平面上的一個點。Embedding 模型的工作，是讓「語意相近」的點靠得近、「不相干」的點離得遠。查詢時：把問題也變成一個點（下圖的 ★），再找離它最近的幾個點——這就是 Nearest Neighbor / Top-K。

真實系統是幾百～上千維，人眼看不見，但「距離近 = 較相似」的直覺相同。§06 Demo 會用 2D 畫布讓你親手點 query。

常見距離／相似度

• L2（歐氏距離）：就是平面上兩點的直線距離——上表用的直覺。圖像 embedding 常見。
• Cosine Similarity：比「方向」像不像，不太在乎向量長短；文字最常用。實務常先做 L2 normalize（把長度收成 1），再比角度。
• Inner Product（內積）：向量已 normalize 時與 Cosine 等價；若沒 normalize，長度會干擾分數，別跟 Cosine 混用。

§06 Demo 用 L2 在 2D 示意「近／遠」；文字系統多半是 normalize 後的 Cosine／IP，但「愈近愈像」的決策邏輯相同。

第 2 節的「點」在實務上通常代表一段文字，不是整本書——所以要先切段再 embed。

真實文件往往太長：若整本手冊只變成一個向量，查詢時只能說「這本書有點相關」，無法指出哪一段。因此要先 Chunk（切段），讓空間裡的每個點對應可引用的片段。

這是兩條各自獨立觸發的路徑：上面一條每份文件只跑一次，下面一條每次提問跑一次，兩者在索引處交會——而且必須用同一個 embedding 模型、同一維度，否則距離根本不可比。這也就是下方「換模型 = 重建世界」的具體意思：兩條路徑都得整條重跑。

1. Chunking：長文切成片段。模型內部用 token（子詞單位，可粗想成「比字元大、比句子小的計長單位」）限制長度；實務常切成約數百 token——大約半頁～一頁說明文字的量級。一頁 PDF 常見會變成數個 chunk。切太細語意破碎；切太粗一次撈回太多雜訊。邊界常留 overlap（重疊）：實務常見約 10%～20% 的長度，讓跨段關鍵句兩邊都留得到。
2. Embedding：呼叫模型把 chunk 轉成 d 維向量（常見 768～1536）。建索引與查詢必須同一模型、同一維度。
3. Metadata：一併存 doc_id、tenant_id、source 等，供過濾（權限、租戶、時間）。注意：若先 ANN 取 Top-10 再過濾，可能只剩 1～2 筆——看起來像「搜尋很空」。能 pre-filter（先縮小候選再搜）就先縮小；細節見 §07。
4. Query path：使用者問題同樣 embed → ANN 取 Top-K →（可選）rerank（用更重的模型把候選再排一次）→ 把原文 chunk 當上下文交給 LLM。

Chunk 切壞的後果（反例）

精確全掃太慢時，用「少看一些點」換速度；漏看就可能漏檢——這就是 recall vs latency。

精確 kNN：對每個向量算一次距離，複雜度約 O(N·d)。ANN 透過資料結構剪枝，讓查詢只檢查一部分候選，目標是：recall@K 仍夠高，P99 延遲可接受。

兩種常見思路（先建立機制，再記產品名）

多數後端團隊的務實路徑：先在 PostgreSQL 驗證，量級與 SLA 撞牆再上分散式向量庫。

pgvector：你已經會的資料庫加一欄向量

pgvector 是 PostgreSQL extension：表上加 vector(d)，可建 HNSW / IVFFlat，並用 SQL 做 metadata filter + 排序。優點是零新基礎設施、ACID、JOIN；限制是單機記憶體／寫入天花板，到億級向量通常不夠。

CREATE EXTENSION vector;
CREATE TABLE doc_chunks (
  id BIGSERIAL PRIMARY KEY,
  content TEXT,
  embedding vector(1536),
  tenant_id INT
);
CREATE INDEX ON doc_chunks
  USING hnsw (embedding vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);
-- ef_construction：建圖時的搜尋寬度（愈大圖通常愈好，建置愈慢）
-- 查詢時另有 ef：控制「這次走路走多勤」，影響 recall / 延遲

SELECT id, content
FROM doc_chunks
WHERE tenant_id = 42
ORDER BY embedding <=> $1   -- <=> = cosine 距離，愈小愈像
LIMIT 10;

專用向量庫：為規模而生

Milvus、FAISS（常作函式庫嵌入服務，而非獨立 DB）這類系統把「向量集合、分片、多種 ANN、水平擴展」當一等公民。適合億級向量、高 QPS，或需要把索引／向量壓進更少記憶體時。代價是多一套運維，metadata 也不如 SQL 靈活。內部還有 collection／segment 等名詞——決策階段可先略過，當成「可水平切的索引分片」即可。

左側看命中／漏檢；右側看這次查詢「探了哪些桶／走了哪些候選」以及實際距離比較次數。

畫布上有一組 2D 點（模擬向量）。點一下可移動 Query ★。左側列表的 GROUND TRUTH＝用 Flat 全掃算出的「正確 Top-5」，用來對照 ANN 有沒有漏。預設已選 Flat，請依序試：

1. Flat——全掃，recall@5 應為 100%，比較次數 = 全部點。
2. IVF + 小 nprobe——畫布出現 cluster 圓；實線粗圓 = 有 probe。只探少數桶時，看漏檢（橘）與比較次數下降。
3. IVF + 大 nprobe——recall 回升、比較次數上升。
4. HNSW——切換後預設 ef=16（教學起點，通常已接近滿分）；再把 ef 往下調到 2～4，觀察漏檢與比較次數下降。淡線是鄰近邊，亮一點的是走過的邊；右側 TRACE 顯示擴張步數與訪問點數。

這是 2D 教學模型：IVF 真的只掃被 probe 的 cluster；HNSW 真的只沿預建鄰近邊（含少量跨區跳接）擴張。真實高維 HNSW 有多層、曲線更陡，仍需離線 benchmark 定參。

把前面串成可答的架構故事：檢索差先查 recall，再決定調 ANN、chunk 或 hybrid。

• Ingestion：文件 → chunk → embed → upsert（+ metadata）。寫入後索引是否立刻可搜，見 §05。
• Retrieval：query embed → ANN Top-K →（可選）rerank → 當 LLM 上下文（RAG 的檢索段）。
• Hybrid：BM25 與向量各取一截，再把兩路排名合併（常見手法叫 RRF：兩邊名次互相加權，不必調分數量綱）——專有名詞靠 keyword，語意靠向量。
• Filter：假設 ANN 取 Top-10，再按 tenant_id 過濾只剩 2 筆——使用者會覺得「搜尋很空」。能 pre-filter（先縮小再 ANN）就先縮小；只能 post-filter 時，要把 K 加大或換支援過濾的索引路徑。

RRF 合併：一個最小例子

假設向量路與 BM25 路各回傳排名（名次愈小愈好）。RRF 常用分數：1 / (60 + rank)，兩路加總後再排序——重點是用名次、不用原始分數，所以不必把 Cosine 與 BM25 硬齊到同一量綱。

上表只示範「名次相加」的直覺；常數 60 可調，但面試講清楚「為何不用原始分數相加」比背數字重要。