前言

昨天介紹了 Embedding 模型的選型考量，今天要來看向量資料庫（Vector Database）——負責儲存這些向量，並提供快速的相似度搜尋能力的角色。

向量資料庫在做什麼？

傳統資料庫擅長的是精確匹配（WHERE id = 123）或範圍查詢（WHERE price > 100），但向量資料庫要解決的是完全不同的問題：在成千上萬筆向量裡，快速找出跟目標向量「距離最近」的幾筆。

如果資料量小，暴力比對（把查詢向量跟資料庫裡每一筆向量都算一次距離）也能work，但當資料量來到百萬筆以上，就需要專門的索引結構（如 HNSW、IVF）來加速搜尋，這也是向量資料庫存在的意義。

常見選項比較

為什麼選 Postgres + pgvector？

延續 Day 3 的選型決定，這系列會用 Postgres + pgvector。除了前面提過的「與既有資料整合方便」之外，還有：

• 可以把 Metadata（Day 8 提到的來源、時間等欄位）直接用一般 SQL 欄位儲存，過濾檢索時可以善用 Postgres 既有的索引機制
• 支援標準 SQL，方便除錯與資料檢查（不需要額外學一套新的查詢語法）
• 社群資源多，遇到問題容易找到解法

安裝與啟用 pgvector

-- 在 Postgres 中啟用 pgvector 擴充套件
CREATE EXTENSION IF NOT EXISTS vector;

-- 建立儲存 chunk 與向量的資料表
CREATE TABLE chunks (
    id SERIAL PRIMARY KEY,
    content TEXT NOT NULL,
    embedding VECTOR(1536),  -- 維度需與 Embedding 模型輸出一致
    metadata JSONB,
    created_at TIMESTAMP DEFAULT now()
);

索引結構的取捨

pgvector 提供兩種主要索引類型：

-- 建立 HNSW 索引
CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops);

小結

向量資料庫的選型要考量資料規模、是否需要跟既有系統整合、維運成本等因素。這系列選擇 Postgres + pgvector 作為示範，兼顧易用性與擴充彈性。明天我們要實際動手，把 Day 9 產出的 chunk 資料寫入向量資料庫、建立索引。