Vector DB 1 — Tổng quan & tìm kiếm ngữ nghĩa

Vấn đề: tìm theo ý nghĩa, không phải theo chữ

Hình dung một cán bộ nghiệp vụ gõ vào công cụ tra cứu nội bộ: "quy trình mở tài khoản cho khách vãng lai". Kho tài liệu có một văn bản rất đúng ý, nhưng nó dùng cụm "hướng dẫn tiếp nhận khách hàng không thường xuyên". Với tìm kiếm từ khoá (keyword / full-text search) — công cụ so khớp chuỗi ký tự, thậm chí có stemming và từ điển đồng nghĩa thủ công — tài liệu này bị bỏ sót, vì không một từ nào trùng khớp trực tiếp.

Đây là giới hạn cốt lõi: full-text search so khớp chữ, không hiểu nghĩa. Nó mạnh khi người dùng biết chính xác thuật ngữ (số hợp đồng, mã sản phẩm, tên riêng), nhưng yếu khi:

• Đồng nghĩa / diễn đạt khác: "vãng lai" ≈ "không thường xuyên", "quá hạn" ≈ "chậm trả".
• Câu hỏi tự nhiên: người dùng hỏi "khách nợ xấu thì xử lý sao" thay vì gõ từ khoá.
• Đa ngôn ngữ / viết tắt: "KYC" vs "định danh khách hàng".

Tìm kiếm ngữ nghĩa (semantic search) đảo ngược cách tiếp cận: thay vì so khớp từ, ta biến mỗi đoạn văn bản thành một vector số sao cho gần nghĩa thì gần nhau trong không gian. Khi đó "khách vãng lai" và "khách không thường xuyên" nằm sát nhau, và ta tìm được nhau dù không chung một chữ.

Embedding vector là gì?

Embedding là phép biểu diễn một đối tượng (văn bản, ảnh, âm thanh, thậm chí hồ sơ khách hàng) thành một vector số thực nhiều chiều — ví dụ 768, 1024 hay 1536 chiều. Từng chiều riêng lẻ không có ý nghĩa "con người đọc được", nhưng toàn bộ vector mã hoá được ngữ nghĩa của đối tượng.

Tính chất then chốt do mô hình embedding học được: hai đối tượng gần nhau về ý nghĩa → hai vector gần nhau về khoảng cách hình học. Vector của "sao kê tài khoản" gần "bảng liệt kê giao dịch" hơn là gần "lãi suất tiết kiệm".

"tài khoản quá hạn"      → [ 0.12, -0.04,  0.88, ... , 0.31]   (1024 số)
"khoản vay chậm trả"     → [ 0.10, -0.02,  0.85, ... , 0.29]   ← rất gần
"khuyến mãi thẻ tín dụng"→ [-0.51,  0.77, -0.10, ... , 0.02]   ← xa

Bài này chỉ dừng ở trực giác và kiến trúc hệ thống. Chi tiết mô hình embedding tạo ra vector thế nào, chọn model ra sao, cách chunk văn bản — xem Vec 2 — Embeddings & độ tương đồng và bài nền tảng LLM 3 — Embeddings & tìm kiếm vector.

Đo độ tương đồng: cosine, dot product, Euclidean

Khi đã có vector, "gần nghĩa" quy về "gần nhau" theo một độ đo (distance/similarity metric). Ba độ đo phổ biến:

Điểm mấu chốt thực chiến: nếu vector đã được normalize về độ dài 1 thì cosine, dot product và Euclidean cho cùng thứ tự xếp hạng — chỉ khác hằng số. Đa số mô hình embedding hiện đại đã normalize sẵn, nên trong thực tế bạn hầu như luôn dùng cosine cho text và không cần đắn đo. Sai lầm thường gặp là dùng dot product trên vector chưa normalize, khiến các đoạn văn dài (vector "to" hơn) bị ưu tiên một cách sai lệch. Chi tiết toán và cạm bẫy: Vec 2.

Nearest neighbor search: vì sao brute-force không mở rộng được

Câu truy vấn cũng được embed thành một vector $q$. Tìm kết quả = tìm k vector gần $q$ nhất trong kho — bài toán k-Nearest Neighbor (kNN).

Cách ngây thơ (brute-force / exact search): tính khoảng cách từ $q$ tới từng vector rồi lấy top-k. Với $n$ vector, mỗi vector $d$ chiều, chi phí là O(n·d) cho mỗi truy vấn.

Con số cụ thể để thấy vấn đề: kho tài liệu nội bộ ngân hàng có 5 triệu đoạn (chunk), mỗi vector 1024 chiều → mỗi truy vấn phải làm ~5 tỷ phép nhân-cộng. Với vài chục truy vấn/giây từ chatbot hỗ trợ, brute-force sập ngay. Nó chỉ ổn khi $n$ nhỏ (vài chục nghìn).

Lời giải là ANN — Approximate Nearest Neighbor: chấp nhận gần đúng (đôi khi bỏ lỡ 1-2 hàng xóm thật) để đổi lấy tốc độ nhanh gấp hàng trăm, hàng nghìn lần. Ta đo chất lượng ANN bằng recall@k (tỷ lệ trong top-k trả về trùng với top-k thật). Thực tế cấu hình recall ~95-99% là quá đủ, vì "đúng nghĩa" vốn đã mờ. Các thuật toán ANN (HNSW, IVF, PQ...) và cách chỉnh tham số là chủ đề của Vec 3 — Chỉ mục ANN.

Vector database là gì — khác gì DB thường?

Một vector database là hệ quản trị được thiết kế để lưu trữ, đánh chỉ mục (index) và truy vấn vector theo độ tương đồng ở quy mô lớn. So với database quan hệ truyền thống:

Một năng lực bắt buộc trong thực tế là metadata filtering: cùng lúc "tìm gần nghĩa" và "chỉ trong tài liệu phòng Tín dụng, còn hiệu lực, ngôn ngữ tiếng Việt". Ví dụ minh hoạ (cú pháp mô phỏng, không phải SQL chuẩn):

search(
  vector = embed("điều kiện tất toán trước hạn"),
  top_k  = 8,
  filter = { phong_ban: "TinDung", trang_thai: "hieu_luc", ngon_ngu: "vi" }
)

Điểm tinh tế: lọc metadata trước hay sau ANN ảnh hưởng lớn tới recall (pre-filter vs post-filter) — sẽ bàn ở Vec 6 — Hybrid search.

Ứng dụng: không chỉ là "ô tìm kiếm"

Cùng một hạ tầng vector phục vụ rất nhiều bài toán:

• Semantic search: tra cứu ngữ nghĩa tài liệu, chính sách, FAQ nội bộ.
• RAG (Retrieval-Augmented Generation): cung cấp nền tri thức cho LLM để nó trả lời dựa trên kho riêng của ngân hàng thay vì "bịa". Đây là ứng dụng bùng nổ nhất — xem LLM 4 — RAG và bài chuyên sâu Vec 7 — RAG retrieval.
• Hệ gợi ý (recommendation): sản phẩm/nội dung "tương tự" = vector gần nhau.
• Khử trùng lặp & entity resolution: gộp hồ sơ khách hàng trùng dù tên gõ khác dấu, sai chính tả, viết tắt — vector gần nhau vượt qua khác biệt bề mặt.
• Phát hiện bất thường (anomaly detection): điểm nào xa mọi cụm quen thuộc → nghi ngờ gian lận / giao dịch lạ.
• Tìm ảnh / tài liệu quét: khớp chữ ký, con dấu, CMND/CCCD.

Định vị các lựa chọn: pgvector vs vector DB chuyên dụng

Không phải cứ nói "vector" là phải mua hệ chuyên dụng. Hai hướng chính:

• pgvector — extension biến PostgreSQL thành DB vector. Ưu điểm cực lớn: dữ liệu vector nằm ngay cạnh dữ liệu nghiệp vụ, join/lọc/transaction bằng SQL quen thuộc, một hệ để vận hành. Phù hợp đại đa số dự án doanh nghiệp tới hàng chục triệu vector. Xem Vec 4 — pgvector và nền tảng PostgreSQL extensions.
• Vector DB chuyên dụng (dạng Qdrant, Milvus, Weaviate...) — tối ưu riêng cho vector: quy mô hàng trăm triệu–tỷ vector, sharding, nhiều thuật toán ANN, độ trễ cực thấp. Đổi lại là thêm một hệ thống phải vận hành, đồng bộ. So sánh chi tiết: Vec 5 — Vector databases.

Quy tắc thực dụng cho môi trường ngân hàng: bắt đầu với pgvector (đã có Postgres, kiểm soát, dễ audit), chỉ chuyển sang chuyên dụng khi thực sự chạm trần về quy mô hoặc độ trễ.

Lưu ý: các câu truy vấn vector không chạy trên sandbox PostgreSQL read-only của trang này (cần extension và dữ liệu vector), nên bài dùng ví dụ minh hoạ, không đánh dấu "▶ Chạy được". Bài Vec 4 sẽ trình bày cú pháp pgvector thật.

Pipeline chung: chunk → embed → index → query → rerank

Mọi hệ tìm kiếm ngữ nghĩa đều đi theo 5 bước, chia làm 2 pha:

1. Chunk — chia tài liệu dài thành đoạn vừa phải (vài trăm token) để mỗi vector "cô đọng" một ý.
2. Embed — đưa từng chunk qua mô hình embedding → vector.
3. Index — nạp vector (kèm metadata) vào chỉ mục ANN. (1-3 là pha offline, làm lại khi tài liệu đổi.)
4. Query — embed câu hỏi, ANN search + lọc metadata → top-k ứng viên.
5. Rerank (tuỳ chọn) — dùng mô hình mạnh hơn chấm lại top-k để nâng độ chính xác trước khi trả về / đưa cho LLM.

Bước rerank thường tăng chất lượng đáng kể vì ANN chỉ cho "ứng viên thô". Kết hợp thêm keyword search (BM25) với vector search tạo thành hybrid search — Vec 6. So với hệ full-text như Elasticsearch (xem Elasticsearch tổng quan), vector bổ sung khả năng "hiểu ý" mà lexical thiếu; thực tế mạnh nhất là kết hợp cả hai.

Use case thực tế

Bối cảnh: Trung tâm hỗ trợ NCB muốn giảm tải cho tổng đài. Cán bộ tư vấn hiện mất trung bình 90 giây lục tìm đúng điều khoản trong ~12.000 trang quy trình, sản phẩm, thông báo nội bộ (khoảng 48.000 chunk sau khi chia). Full-text search cũ bỏ sót ~35% câu hỏi vì khách diễn đạt khác thuật ngữ nội bộ.

Giải pháp — semantic search trên pgvector:

1. Chunk & embed: chia 12.000 trang → 48.000 đoạn, mỗi đoạn 1024 chiều. Lưu kèm metadata: phong_ban, loai_tai_lieu, hieu_luc_den, mat_do_bao_mat.
2. Index: dựng chỉ mục HNSW trong pgvector; brute-force 48.000×1024 ≈ 49 triệu phép/truy vấn vẫn ổn, nhưng HNSW để sẵn cho lộ trình mở rộng lên hàng triệu chunk.
3. Query: cán bộ gõ câu hỏi tự nhiên; hệ embed câu hỏi, lọc metadata theo phòng ban + còn hiệu lực + đúng quyền bảo mật của người dùng, rồi ANN lấy top-8.
4. Rerank: chấm lại top-8, trả về top-3 đoạn kèm trích dẫn nguồn.

Kết quả (mục tiêu triển khai): thời gian tra cứu từ 90s xuống ~12s; tỷ lệ "tìm đúng ngay lần đầu" từ 65% lên ~92%. Cùng hạ tầng này về sau tái sử dụng cho chatbot RAG hỗ trợ khách và khớp hồ sơ (gộp khách trùng dù sai dấu/viết tắt). Các con số cải thiện là mục tiêu minh hoạ cho kịch bản.

Ghi nhớ

• Keyword search so khớp chữ; semantic search hiểu ý — vector giải quyết đồng nghĩa, diễn đạt khác, câu hỏi tự nhiên mà full-text bỏ sót.
• Embedding = biểu diễn số nhiều chiều, gần nghĩa → gần nhau. Không tự sinh vector — dùng mô hình embedding (xem Vec 2, LLM 3).
• Độ đo: cosine là mặc định cho text; dot product tương đương khi vector đã normalize; Euclidean cho dữ liệu có độ lớn ý nghĩa.
• Brute-force kNN là O(n·d) — không mở rộng được; dùng ANN đổi độ chính xác lấy tốc độ, đo bằng recall@k.
• Vector database = lưu + index (HNSW/IVF) + truy vấn theo độ tương đồng ở quy mô lớn, kèm metadata filtering — khác hẳn B-tree/inverted index.
• Ứng dụng rộng: semantic search, RAG (LLM 4), gợi ý, khử trùng/entity resolution, phát hiện bất thường, tìm ảnh.
• Bắt đầu bằng pgvector (Postgres sẵn có, dễ audit); chỉ chuyển DB chuyên dụng khi chạm trần quy mô/độ trễ.
• Pipeline chuẩn: chunk → embed → index → query → rerank; kết hợp lexical + vector = hybrid search cho kết quả tốt nhất.