Một anh Hà Nội vào chơi Nghệ An, hỏi đường: "Chị ơi, đường ra ga tàu đi ngả nào?". Chị người Nghệ nhiệt tình chỉ tay: "Đi thẳng đến cái nhà tê, xong rẽ qua cái đường mô có cây bàng là tới". Anh trai Hà Nội đứng hình vì không biết nhà "tê" và đường "mô" nằm ở đâu.
Ở bài trước, chúng ta đã gặp RAG.Bạn hỏi AI:
"Tôi quên mật khẩu, phải làm sao?"
Hệ thống RAG sẽ cố gắng tìm tài liệu liên quan rồi đưa cho AI.
Nghe đơn giản.
Nhưng có một câu hỏi bắt đầu xuất hiện:
"À thì là như vậy, nhưng túm lại thì máy tìm kiểu gì?"
Ví dụ trong kho tài liệu có hai câu:
"Tôi quên mật khẩu."
và:
"Làm thế nào để reset password?"
Con người nhìn vào là hiểu:
Hai câu này gần như đang hỏi cùng một chuyện.
Nhưng máy không thể chỉ nhìn kiểu:
có chữ "mật khẩu"?
vì câu thứ hai có thể chẳng có chữ "mật khẩu" nào.
Nó lại có:
- reset
- password
Vậy làm sao để máy hiểu rằng:
"quên mật khẩu"
và:
"reset password"
có ý nghĩa gần nhau?
Đây là lúc chúng ta bắt đầu gặp:
Vector.
Và khi có rất nhiều vector cần lưu trữ, tìm kiếm:
Vector Database.
Trước tiên: Vector là gì?
Nghe chữ "Vector" có vẻ như sắp phải mở sách toán., nghe hơi...căng thẳng!
Khoan.
Ở mức người mới học AI, bạn có thể hiểu đơn giản:
Vector là một cách biểu diễn thông tin dưới dạng một dãy số để máy tính có thể xử lý và so sánh.
Ví dụ tưởng tượng:
"Tôi thích lập trình Python"
sau khi được xử lý có thể được biểu diễn đại loại như:
[0.12, -0.45, 0.78, 0.31, ...]
Một câu khác:
"Tôi đang học Python"
cũng có thể được biểu diễn thành một dãy số:
[0.15, -0.42, 0.74, 0.35, ...]
Bạn nhìn hai dãy số này:
[0.12, -0.45, 0.78, 0.31, ...]
[0.15, -0.42, 0.74, 0.35, ...]
chắc sẽ nghĩ:
"Ủa... nhìn có hiểu gì đâu?"
Không sao.
Máy tính lại rất thích kiểu này.
Nó có thể dùng các phương pháp toán học để đo xem những vector này gần nhau đến mức nào.
Và đó chính là điều chúng ta cần.
Tại sao phải biến chữ thành số?
Máy tính không "hiểu" câu:
"Tôi quên mật khẩu."
theo cách con người hiểu.
Nó cần một cách biểu diễn để thực hiện các phép tính.
Vì vậy, hệ thống có thể biến nội dung thành một vector.
Ví dụ tưởng tượng:
"Tôi quên mật khẩu."
↓
Embedding
↓
[0.21, -0.14, 0.82, 0.37, ...]
Một câu khác:
"Làm sao reset password?"
↓
Embedding
↓
[0.19, -0.11, 0.79, 0.40, ...]
Sau đó máy có thể nói:
"Hai vector này khá gần nhau."
Từ đó suy ra:
"Hai đoạn văn này có khả năng liên quan đến cùng một chủ đề."
Đây là ý tưởng cơ bản phía sau semantic search.
Embedding là gì?
Ở bài trước chúng ta đã "nhắc sơ" đến từ này.
Bây giờ hiểu kỹ hơn một chút:
Embedding là quá trình biến dữ liệu như văn bản thành một vector số nhằm biểu diễn những đặc điểm/ngữ nghĩa mà hệ thống có thể dùng để so sánh.
Ví dụ:
"Quên mật khẩu"
được đưa qua một embedding model.
Kết quả:
[0.12, -0.31, 0.77, 0.09, ...]
Một câu khác:
"Reset password"
được đưa qua embedding model.
Kết quả:
[0.15, -0.29, 0.73, 0.11, ...]
Hai vector có thể khá gần nhau.
Trong khi:
"Cách nấu mì Quảng"
có thể cho ra một vector nằm rất xa, rất có thể có "quan hệ họ hàng" với "Nấu món mì gốc Quảng Nam"
Nói kiểu đời thường:
Embedding giống như biến câu chữ thành một "tọa độ ý nghĩa" để máy dễ tìm những thứ có nội dung gần nhau.
Nghe "tọa độ" có vẻ "khoa học kỹ thuật" quá, nhung không phải tọa độ GPS đâu nhé.
Keyword Search và Semantic Search
Đây là chỗ Vector Database bắt đầu có lý do để tồn tại.
Giả sử bạn có:
Tài liệu A:
"Cách reset mật khẩu tài khoản."
Tài liệu B:
"Nhân viên quên password có thể sử dụng chức năng đặt lại mật khẩu."
Tài liệu C:
"Cách thanh toán đơn hàng."
Tài liệu D:
"Hướng dẫn đổi địa chỉ giao hàng."
Bạn hỏi:
"Tôi quên password thì phải làm sao? Tìm tài liệu nào?"
Cách 1: Keyword Search
Máy tìm những từ giống nhau:
password
Có thể tìm được tài liệu B.
Khá ổn.
Nhưng nếu tài liệu viết:
"Người dùng quên thông tin đăng nhập..."
thì sao?
Có thể chẳng có chữ:
password
hoặc:
mật khẩu
Nhưng nội dung lại hoàn toàn liên quan.
Cách 2: Semantic Search
Semantic Search quan tâm nhiều hơn đến:
"Ý nghĩa của câu này gần với đoạn nào?"
Ví dụ:
Người dùng:
"Tôi quên password."
Hệ thống có thể tìm được:
"Nhân viên quên thông tin đăng nhập..."
dù hai câu không giống nhau từng chữ.
Đây là một trong những lý do embedding rất hữu ích.
Vector Database xuất hiện ở đâu?
Bây giờ hãy tưởng tượng bạn có:
10 tài liệu
Bạn có thể xử lý khá dễ.
Nhưng nếu có:
100.000 tài liệu
thì sao?
Bạn có thể có hàng triệu đoạn văn.
Mỗi đoạn được biến thành một vector.
Ví dụ:
Chunk 1 → Vector 1
Chunk 2 → Vector 2
Chunk 3 → Vector 3
...
Chunk 1.000.000 → Vector 1.000.000
Bạn cần một nơi để:
lưu vector
lưu thông tin liên quan
tìm vector gần nhất
trả về những đoạn dữ liệu tương ứng
Đó là lúc:
Vector Database
phát huy tác dụng.
Vector Database là gì?
Hiểu đơn giản:
Vector Database là hệ thống lưu trữ và tìm kiếm dữ liệu vector, đặc biệt hữu ích cho những bài toán cần tìm các dữ liệu có mức độ tương đồng cao.
Nếu Database truyền thống thường làm những việc kiểu:
SELECT * FROM users
WHERE email = 'abc@example.com'thì Vector Database lại rất phù hợp với câu hỏi kiểu:
"Trong kho dữ liệu này, đoạn nào có ý nghĩa gần với câu hỏi của tôi nhất?"
Đây là hai kiểu tìm kiếm khác nhau.
Hãy tưởng tượng một cái tủ hồ sơ
Database truyền thống
Bạn có một tủ hồ sơ:
- Ngăn 1: Khách hàng
- Ngăn 2: Đơn hàng
- Ngăn 3: Sản phẩm
- Ngăn 4: Nhân viên
Bạn biết mình cần:
"Khách hàng có ID = 123."
Bạn tìm đúng:
ID = 123
Rất rõ ràng.
Vector Database
Bây giờ bạn bước vào một thư viện khổng lồ.
Bạn nói:
"Tôi muốn tìm tài liệu nói về cách xử lý khi người dùng quên mật khẩu."
Bạn không biết chính xác tài liệu tên gì.
Bạn cũng không biết nó nằm ở trang nào.
Bạn chỉ biết:
Tôi cần thông tin có ý nghĩa gần với vấn đề này.
Hệ thống tìm kiếm những tài liệu gần nhất.
Đó chính là kiểu bài toán mà vector search hỗ trợ.
Nói "đơn giản dị":
Database thường: "Cho tôi đúng người số 123."
Vector search: "Cho tôi mấy người có vẻ đang nói cùng chuyện với ông này."
Vector Database hoạt động cùng RAG như thế nào?
Ở bài trước, chúng ta có:
User hỏi
↓
Retrieval
↓
Lấy tài liệu
↓
AI trả lời
Bây giờ chúng ta mở rộng:
User hỏi
↓
Embedding câu hỏi
↓
Vector Search
↓
Tìm các vector gần nhất
↓
Lấy các đoạn tài liệu tương ứng
↓
Đưa context cho AI
↓
AI trả lời
Đây chính là một luồng RAG phổ biến.
Ví dụ cụ thể
Giả sử DatVietLapTrinh có 1.000 bài viết.
Mỗi bài được chia thành nhiều chunk.
Ví dụ:
Bài A
-Chunk 1
-Chunk 2
-Chunk 3
Bài B
-Chunk 1
-Chunk 2
-Chunk 3
...
Sau đó mỗi chunk được tạo embedding:
Chunk A1 → Vector A1
Chunk A2 → Vector A2
Chunk A3 → Vector A3
Chunk B1 → Vector B1
Chunk B2 → Vector B2
...
Các vector này được lưu trong hệ thống tìm kiếm.
Người đọc hỏi:
"Tại sao pip install lại không chạy?"
Câu hỏi cũng được tạo embedding:
Question
↓
Embedding
↓
Query Vector
Sau đó hệ thống tìm những vector gần với Query Vector.
Có thể tìm được:
Chunk 1:
python -m pip
Chunk 2:
PATH
Chunk 3:
multiple Python installations
Những chunk này được đưa cho AI.
AI mới tạo câu trả lời.
Có phải Vector gần nhau là "giống nhau"?
Không nên hiểu đơn giản như vậy.
Gần nhau thường có nghĩa là hệ thống đánh giá chúng có mức độ tương đồng theo không gian vector.
Không nhất thiết:
Vector A = Vector B
mới là liên quan.
Ngược lại, hai câu có thể dùng những từ khác nhau nhưng vẫn có vector gần nhau.
Ví dụ:
"Tôi quên mật khẩu."
và:
"Làm sao đặt lại password?"
không giống từng chữ.
Nhưng về ý nghĩa:
rất gần.
Đó chính là thứ semantic search muốn tận dụng.
"Khoảng cách" giữa các vector là gì?
Đây là lúc một chút toán học bắt đầu lấp ló ngoài cửa.
Trong vector search, hệ thống cần một cách để đo:
"Vector A và Vector B gần nhau đến mức nào?"
Có nhiều cách đo.
Một cách rất phổ biến là:
Cosine similarity.
Bạn chưa cần học công thức ngay.
Chỉ cần hình dung:
Vector A
↘
↘
↘
Vector B
Nếu hướng của chúng khá giống nhau:
similarity cao.
Nếu hướng khác nhiều:
similarity thấp.
Ngoài cosine similarity, còn có những cách đo khoảng cách/tương đồng khác tùy hệ thống.
Điểm quan trọng là:
Vector Database không chỉ "lưu số". Nó còn hỗ trợ tìm kiếm dựa trên những vector đó.
Tại sao không dùng MySQL là đủ?
Câu hỏi rất hay.
Bạn hoàn toàn có thể dùng MySQL cho rất nhiều dữ liệu của ứng dụng.
Ví dụ:
- users
- products
- orders
- posts
- comments
Đó là những dữ liệu có cấu trúc rõ ràng.
Bạn có thể tìm:
SELECT * FROM products
WHERE id = 123;Hoặc:
SELECT * FROM users
WHERE email = 'abc@example.com'Nhưng nếu bạn hỏi:
"Tìm cho tôi những đoạn tài liệu có ý nghĩa gần với câu hỏi này."
thì đây là một bài toán khác.
Bạn cần khả năng tìm kiếm vector.
Đó là lý do các hệ thống AI/RAG thường sử dụng các công cụ hoặc hệ thống hỗ trợ vector search.
Vector Database có thay thế Database truyền thống không?
Không.
Đây là hiểu nhầm khác khá phổ biến.
Không phải:
- MySQL --> Vứt sọt rác
- Vector Database ---> Giữ lại
Mà có thể là:
MySQL
+
Vector Database
Mỗi thứ phục vụ những nhu cầu khác nhau.
Ví dụ:
MySQL
Lưu:
- User ID
- Tên
- Đơn hàng
- Giá
- Ngày mua
Vector Database
Lưu:
- Embedding
- Metadata
- Thông tin phục vụ semantic search
Một hệ thống thực tế thậm chí có thể kết hợp cả hai.
Ví dụ:
MySQL
↓
Thông tin sản phẩm
Vector Database
↓
Embedding của mô tả sản phẩm
Người dùng tìm:
"Điện thoại chụp ảnh tốt trong điều kiện thiếu sáng"
Vector search có thể tìm những sản phẩm có nội dung mô tả phù hợp về mặt ngữ nghĩa.
Metadata là gì?
Đây là một khái niệm rất đáng nhớ.
Giả sử vector database có:
Vector
+
Metadata
Metadata có thể chứa:
title = "Pip không hoạt động"
category = "Python"
url = "..."
author = "..."
date = "..."
Tại sao cần?
Vì khi tìm thấy vector phù hợp, bạn cần biết:
"Nó thuộc tài liệu nào?"
Ví dụ:
Vector gần nhất
↓
Chunk
↓
Metadata
↓
Bài viết: "Pip không hoạt động"
Sau đó hệ thống có thể đưa đúng nội dung và nguồn cho AI.
Đây là lúc Filter xuất hiện
Giả sử bạn có rất nhiều tài liệu:
- PHP
- Python
- C++
- AI
- Arduino
- Robotics
Người dùng hỏi:
"Làm sao tạo Virtual Environment?"
Bạn không nhất thiết muốn hệ thống tìm trong mọi thứ.
Có thể lọc:
category = Python
rồi mới thực hiện vector search.
Hoặc:
language = Python
Hoặc:
year >= 2025
Tùy hệ thống.
Vì vậy trong thực tế, retrieval thường không chỉ đơn giản là:
"Vector nào gần nhất?"
mà có thể là:
Filter
↓
Vector Search
↓
Ranking
↓
Top results
Top-K là gì?
Bạn không muốn lấy:
10.000 đoạn tài liệu
rồi ném hết vào AI.
Thường hệ thống sẽ lấy một số lượng nhỏ kết quả tốt nhất.
Ví dụ:
Top 3
Top 5
Top 10
Đây thường được gọi là:
Top-K retrieval.
Ví dụ:
Query
↓
Vector Search
↓
Top 5 chunks
↓
AI
K = 5.
Không phải lúc nào K = 5 cũng là tốt nhất.
Nếu lấy quá ít:
Có thể thiếu context.
Nếu lấy quá nhiều:
Context dài, nhiều thông tin thừa, có thể tăng chi phí và làm câu trả lời kém tập trung.
Đây cũng là thứ phải thử nghiệm và debug.
Vector Database không phải "cục nam châm thần kỳ"
Đây là phần hy vọng bạn sẽ nhớ dù chỉ...90%.
Có Vector Database không có nghĩa:
"AI tìm cái gì cũng đúng."
Không.
Bạn vẫn có thể gặp:
Tài liệu sai
↓
Embedding sai/không phù hợp
↓
Chunking không tốt
↓
Retrieval sai
↓
Context sai
↓
AI trả lời sai
Hoặc:
Tài liệu đúng
↓
Search được tài liệu gần nhưng không phải đoạn cần thiết
↓
AI nhận context không đủ
↓
AI trả lời thiếu
Vì vậy:
Vector Database chỉ là một thành phần trong cả hệ thống.
Đừng quá tin tưởn tuyệt đối, và cũng đừng thấy AI trả lời sai rồi hét:
"Trí Tuệ....điên hả trời!"
Có thể nó chẳng làm gì sai cả.
Chunking quan trọng đến mức nào?
Rất quan trọng.
Giả sử bạn có đoạn:
Sản phẩm được bảo hành 12 tháng.
Điều kiện bảo hành:
- Còn nguyên tem.
- Không bị ngấm nước.
- Có hóa đơn mua hàng.
Nếu chia chunk quá nhỏ:
"Sản phẩm được bảo hành 12 tháng."
và:
"Không bị ngấm nước."
Bạn có thể mất một phần ngữ cảnh.
Nếu chunk quá lớn:
cả 30 trang tài liệu
thì retrieval lại khó tập trung.
Vì vậy chunking là một bài toán thiết kế.
Không có câu:
"Chia đúng 500 ký tự là luôn tốt."
Tùy loại dữ liệu.
Vector Database và RAG: ai làm việc gì?
Hãy nhớ bằng bảng này:
Thành phần Việc chính
Tài liệu Nguồn kiến thức
Chunk Chia tài liệu thành phần nhỏ
Embedding Model Biến nội dung thành vector
Vector Database Lưu và tìm vector
Retrieval Tìm nội dung liên quan
Context Đưa thông tin tìm được cho AI
AI Model Tạo câu trả lời
Nhìn cả hệ thống:
Tài liệu
↓
Chunk
↓
Embedding
↓
Vector Database
↓
User hỏi
↓
Embedding câu hỏi
↓
Vector Search
↓
Relevant Chunks
↓
Context
↓
AI Model
↓
Answer
Đây là một trong những sơ đồ đáng nhớ nhất của phần "AI thật là rắc rối" này.
Một ví dụ đời thường
Hãy tưởng tượng bạn vào một thư viện.
Bạn nói với thủ thư:
"Tôi muốn tìm tài liệu về cách sửa xe máy khi đề không nổ."
Thủ thư không mang cho bạn:
Toàn bộ thư viện.
Họ sẽ tìm:
Sửa xe
+
Đề máy
+
Không nổ
rồi đưa vài cuốn liên quan, ví dụ: Giáo Trình Kỹ Thuật Sửa Chữa Ô Tô, Máy Nổ, Giáo Trình Chẩn Đoán Kỹ Thuật Ô Tô, Kỹ Thuật Chẩn Đoán Ôtô...
Trong RAG:
Bạn
↓
Câu hỏi
Thủ thư
↓
Retrieval
Mục lục/thông tin tìm kiếm
↓
Vector Search
Những trang phù hợp
↓
Chunks
Người giải thích
↓
AI
Vector Database giống như một phần của hệ thống thư viện giúp việc tìm kiếm theo mức độ liên quan trở nên hiệu quả.
Có những Vector Database nào?
Hiện nay có nhiều lựa chọn và công nghệ khác nhau.
Bạn có thể gặp những cái tên như:
- Pinecone
- Weaviate
- Milvus
- Qdrant
- Chroma
- pgvector
Ngoài ra, một số hệ quản trị cơ sở dữ liệu truyền thống cũng hỗ trợ vector search, chẳng hạn PostgreSQL với pgvector.
Điều quan trọng ở bài này không phải là:
"Học thuộc 6 cái tên."
Mà là hiểu:
Tại sao chúng tồn tại và chúng giải quyết vấn đề gì?
Khi đã hiểu vấn đề, học công cụ nào sau này sẽ dễ hơn nhiều.
Vector Database có phải chỉ dành cho AI không?
Không nhất thiết.
Nhưng nó đặc biệt hữu ích trong các bài toán cần:
Semantic Search
Similarity Search
Recommendation
Retrieval
RAG
Tìm nội dung tương tự
Tìm hình ảnh/văn bản có đặc điểm gần nhau
Ví dụ bạn có:
100.000 sản phẩm
Người dùng không muốn tìm bằng tên chính xác.
Họ nói:
"Tôi cần một chiếc áo mặc đi du lịch, nhẹ và thoáng."
Hệ thống có thể tìm những sản phẩm có mô tả phù hợp về mặt ngữ nghĩa.
Đó là một bài toán khác với:
WHERE product_name LIKE '%áo%'Chua thêm một chút
Có một sự thật khá buồn cười:
Bạn dọc thấy cần vô số thứ:
Vector
Embedding
Similarity
Cosine
Database
RAG
rồi bắt đầu nghĩ:
"Chắc mình phải học toán dữ lắm."
Không hẳn.
Nếu mục tiêu của bạn là xây ứng dụng AI, bạn cần hiểu:
khái niệm
dữ liệu đi đâu
tại sao tìm được
tại sao tìm sai
cách kiểm tra
cách chọn công cụ
Còn nếu sau này bạn muốn nghiên cứu sâu về machine learning, information retrieval hoặc thuật toán vector search...
thì lúc đó toán sẽ bước vào gõ cửa.
Nhưng:
Chưa cần mở cửa hôm nay. Lúc này đơn giản chỉ cần hiểu "chung chung"
Debug một hệ thống Vector Search
Đây mới là phần mong bạn mang theo từ những bài này.
Giả sử người dùng hỏi:
"Làm sao reset mật khẩu?"
Nhưng hệ thống trả về tài liệu về:
"Cách thanh toán."
Đừng chỉ nhìn AI.
Hãy kiểm tra:
1. Query có đúng không?
"Làm sao reset mật khẩu?"
2. Embedding model có hoạt động không?
Có tạo được vector không?
3. Vector search có chạy không?
Có kết quả không?
4. Similarity có hợp lý không?
Kết quả đầu tiên có thực sự liên quan?
5. Metadata có đúng không?
Vector đó thực sự thuộc tài liệu nào?
6. Filter có làm mất dữ liệu cần thiết không?
Ví dụ bạn vô tình lọc:
category = PHP
trong khi tài liệu cần tìm nằm ở:
category = Python
7. Chunk có đủ context không?
Đoạn tìm được có đầy đủ câu trả lời không?
8. AI có nhận đúng context không?
Retrieval đúng nhưng truyền context sai thì vẫn "toang".
Checklist Vector Database
- Nếu bạn chỉ muốn nhớ phần cốt lõi:
- Vector là dạng biểu diễn dữ liệu bằng số
- Embedding biến dữ liệu thành vector
- Vector có thể dùng để so sánh mức độ tương đồng
- Semantic Search tìm theo ý nghĩa thay vì chỉ giống từ khóa
- Vector Database lưu và tìm kiếm vector
- Vector Database thường xuất hiện trong các hệ thống RAG
- RAG có thể dùng Vector Search để tìm context
- Metadata giúp biết vector/chunk thuộc tài liệu nào
- Filter có thể giới hạn phạm vi tìm kiếm
- Top-K là số lượng kết quả được lấy ra
- Chunking ảnh hưởng mạnh đến chất lượng retrieval
- Vector Database không đảm bảo AI luôn trả lời đúng
- Vector Database không thay thế hoàn toàn database truyền thống
- Retrieval sai có thể dẫn đến câu trả lời sai
FAQ nhanh
Vector có phải là một file không?
Không.
Vector là một dạng biểu diễn dữ liệu bằng các giá trị số.
Embedding có phải là Vector Database không?
Không.
Embedding là quá trình/mô hình tạo ra vector biểu diễn.
Vector Database là hệ thống dùng để lưu trữ và tìm kiếm các vector cùng dữ liệu liên quan.
Vector Database có phải là database bình thường không?
Nó vẫn là một hệ thống lưu trữ dữ liệu, nhưng được thiết kế để hỗ trợ các bài toán vector search/similarity search.
Vector Database có thay MySQL không?
Không nhất thiết.
Một ứng dụng có thể sử dụng cả database truyền thống và vector search cho những nhu cầu khác nhau.
Có phải cứ vector gần nhau là hai câu giống nhau hoàn toàn?
Không.
Vector gần nhau thường thể hiện mức độ tương đồng theo cách embedding model biểu diễn dữ liệu. Nó không có nghĩa hai câu giống từng chữ hoặc hoàn toàn đồng nghĩa.
RAG có bắt buộc phải dùng Vector Database không?
Không.
RAG có thể dùng nhiều phương pháp retrieval khác nhau. Vector Database là một lựa chọn phổ biến cho semantic/vector search.
Có cần học toán để sử dụng Vector Database không?
Để bắt đầu xây ứng dụng, bạn không cần đào sâu toán ngay.
Bạn nên hiểu trước:
Embedding
↓
Vector
↓
Similarity
↓
Search
↓
Retrieval
Sau đó mới học sâu hơn nếu công việc hoặc dự án yêu cầu.