Vector database
Also: 向量資料庫 · 向量庫 · vector db · 向量搜尋 · embedding database
A database that searches by how close the meaning is: you give it a query vector and it returns the nearest few records, instead of matching exact wording.
When you will meet it
This is RAG's retrieval engine. Once your knowledge base is too big for one prompt, it picks the few most relevant passages out of tens or hundreds of thousands. Without knowing how it works you cannot diagnose "the passage exists but was not retrieved".
An analogy
An ordinary database is like a dictionary index: look up "apple" and you flip to the exact "apple" page. A vector database is a librarian who knows topics: ask for "fruit" and it hands you apples, bananas and pears — things close in meaning — even if you never typed those words.
Minimal example
# 概念示意（不同向量庫的 API 名稱略有差異）
docs = ["報銷上限是三萬元", "出差要事先申請", "辦公室在十樓"]
db.add([embed(d) for d in docs]) # 建立索引：每段文字轉成向量存進去
hits = db.search(embed("差旅花費怎麼報"), top_k=2)
# → 最可能回：出差要事先申請 / 報銷上限是三萬元
# 注意查詢裡根本沒有「報銷」「三萬」這些字，靠的是意思接近Two things to grasp first. One: indexing and querying must use the same embedding model, or the coordinate systems differ and results are effectively random. Two: it returns the most similar, not the most correct — so in practice a rerank pass often reorders afterwards, or hybrid search adds keywords.
What people get wrong
- Assuming a vector database can replace all databases. It excels at fuzzy, meaning-based queries but is poor at exact matching: for a precise order number, error code or name, traditional keyword search is actually more accurate.
- Reaching for an expensive managed service from the start. Many cases are fine with a local, embedded vector store (SQLite vector extensions, LanceDB, Chroma); get it working locally before considering managed.