Wavi Books · AI, LLM & AI Agent

Vector Database là gì? Vai trò của vector DB trong RAG và AI

Nguyễn Minh Trí · Biên tập chuyên môn Wavi Books

Vector Database là gì, cách lưu embedding, tìm kiếm tương đồng và tiêu chí chọn vector DB cho hệ thống RAG, chatbot và AI Agent.

## Vector Database là gì

## Hiểu nhanh trước khi chọn mô hình hoặc framework

Vector Database là gì, cách lưu embedding, tìm kiếm tương đồng và tiêu chí chọn vector DB cho hệ thống RAG, chatbot và AI Agent. Một hệ thống AI đáng tin phải kiểm soát được dữ liệu nguồn, cách đánh giá và hành vi khi mô hình không chắc chắn.

Một mô hình có thể trả lời rất trôi chảy trong bản demo, rồi bịa đúng phần quan trọng nhất khi gặp dữ liệu thật. Khoảnh khắc ấy nhắc chúng ta rằng sản phẩm AI không chỉ là prompt: phía sau còn có dữ liệu, đánh giá, quyền truy cập, công cụ và cách hệ thống xử lý khi không chắc chắn.

Vector database nghe có vẻ xa lạ, nhưng ý tưởng cốt lõi lại rất gần gũi: tìm những nội dung giống nhau về ý nghĩa, ngay cả khi chúng không dùng cùng một từ.

Vector database là hệ thống lưu trữ và truy vấn các vector nhiều chiều, thường được tạo từ văn bản, hình ảnh hoặc âm thanh bằng mô hình embedding. Nó giúp tìm đối tượng gần nghĩa thay vì chỉ khớp chính xác từ khóa.

Trong RAG, vector DB thường lưu các đoạn tài liệu và metadata. Khi có câu hỏi, hệ thống biến câu hỏi thành vector, tìm các đoạn gần nhất rồi cung cấp chúng cho LLM.

## Những khái niệm cốt lõi cần nắm

## Từ tìm đúng chữ đến tìm đúng ý

Tìm kiếm từ khóa giống như dò chính xác một cụm từ trong sách. Tìm kiếm vector giống như nhờ người thủ thư tìm các trang cùng nói về một vấn đề. Embedding biến nội dung thành các điểm số để máy tính ước lượng mức độ gần nhau về ngữ nghĩa.

## Chuyện gì xảy ra khi đem vào dự án thật?

Một kho vector có thể trả về đoạn văn rất giống câu hỏi nhưng vẫn không chứa câu trả lời. Đây là lý do metadata, bộ lọc, chiến lược chia đoạn và reranking quan trọng không kém việc chọn công nghệ lưu trữ.

## Nếu bắt đầu hôm nay, tôi sẽ làm thế này

Bạn nên thử với vài trăm tài liệu và tự đọc các kết quả top đầu. Khi mắt người còn thấy kết quả vô lý, chưa cần vội tối ưu tốc độ hay mở rộng hạ tầng.

- Embedding model quyết định không gian ngữ nghĩa.

- Khoảng cách cosine hoặc dot product dùng để xếp hạng.

- Metadata filter thu hẹp phạm vi tìm kiếm.

- Hybrid search kết hợp vector với từ khóa.

## Lộ trình thực hành từng bước

- Bước 1: Đo chất lượng embedding trên dữ liệu tiếng Việt.

- Bước 2: Thiết kế metadata theo quyền và loại tài liệu.

- Bước 3: Benchmark độ chính xác, độ trễ, khả năng sao lưu và chi phí vận hành.

## Những sai lầm thường gặp

- Chọn công cụ trước khi có dữ liệu kiểm thử.

- Không quản lý phiên bản embedding.

- Bỏ qua phân quyền ở tầng truy xuất.

## Góc nhìn dành cho người học và developer Việt Nam

Dữ liệu tiếng Việt có tên riêng, viết tắt và thuật ngữ pha tiếng Bạn. Vì vậy cần kiểm thử truy vấn thật thay vì dựa hoàn toàn vào benchmark tiếng Bạn.

## Nên học tiếp như thế nào?

## Bài tập quan sát chất lượng truy xuất vector

Lấy 20 đoạn tài liệu ngắn, tạo năm câu hỏi dùng từ khác với tài liệu rồi xem các kết quả được truy xuất. Ghi lại trường hợp đúng ý, gần ý nhưng thiếu câu trả lời và hoàn toàn sai. Sau đó thử đổi kích thước đoạn hoặc thêm bộ lọc metadata. Bạn sẽ thấy vector database chỉ là một phần; cách tổ chức dữ liệu quyết định rất nhiều đến trải nghiệm cuối.

## Ví dụ xuyên suốt để nối kiến thức

Một nhân viên hỏi “nghỉ chăm con ốm được mấy ngày?”, trong khi tài liệu chỉ ghi “chế độ nghỉ khi con mắc bệnh”. Tìm từ khóa có thể bỏ lỡ, còn embedding có thể đưa hai cách diễn đạt lại gần nhau. Tuy nhiên, nếu kết quả lấy nhầm chính sách của năm cũ, câu trả lời vẫn sai dù độ tương đồng rất cao.

## Khung triển khai từ thử nghiệm đến thực tế

Thiết kế vector search cần trả lời bốn câu hỏi: đơn vị nào được embedding, metadata nào dùng để lọc, bao nhiêu kết quả được lấy và có cần reranker hay không. Đây là bài toán truy xuất thông tin trước khi là bài toán chọn database.

### Bốn bước nên đi theo thứ tự

- Làm sạch tài liệu, giữ phiên bản và nguồn sở hữu rõ ràng.

- Chia đoạn theo cấu trúc ý nghĩa thay vì cắt cứng mọi đoạn bằng nhau.

- Tạo embedding, lưu metadata và kiểm tra thủ công top kết quả.

- Thêm hybrid search hoặc reranking khi bộ kiểm thử chứng minh cần thiết.

## Trade-off cần nhìn thẳng

Đoạn quá ngắn thiếu ngữ cảnh; đoạn quá dài làm loãng ý và tốn token. Lấy quá ít kết quả dễ bỏ sót, lấy quá nhiều lại đẩy nhiễu vào prompt. Chất lượng tốt thường đến từ việc cân bằng các yếu tố này.

## Đánh giá bằng kết quả thay vì cảm giác

Đánh giá recall của đoạn chứa câu trả lời, precision của top kết quả và tỷ lệ câu trả lời có nguồn phù hợp. Đừng chỉ nhìn độ tương đồng vector vì con số cao không đồng nghĩa với hữu ích.

## Giá trị đối với năng lực nghề nghiệp

Khi hiểu retrieval, bạn có thể debug RAG bằng bằng chứng thay vì liên tục đổi model. Đây là kỹ năng có giá trị cho AI Engineer, Data Engineer và Backend Engineer làm sản phẩm tìm kiếm.

## Câu hỏi tự kiểm tra trước khi chuyển chủ đề

Bạn có thể giải thích Vector Database là gì bằng ngôn ngữ của mình, nêu một trường hợp nên dùng, một trường hợp không nên dùng và chỉ ra cách đo kết quả hay chưa? Nếu chưa, hãy quay lại ví dụ nhỏ trong bài, thay đổi một ràng buộc rồi quan sát điều gì buộc giải pháp phải thay đổi. Đây là cách biến kiến thức đọc được thành khả năng ra quyết định.

## Góc nhìn dành cho developer Việt Nam

Với developer và AI engineer tại Việt Nam, nên học chủ đề này bằng một bài toán nhỏ có dữ liệu thật và tiêu chí đánh giá rõ. Cách làm đó giúp bạn phân biệt một demo gây ấn tượng với một ứng dụng AI có thể kiểm tra, vận hành và giải thích cho người dùng.

## Đọc tiếp trên Wavi Books

Nếu bạn muốn học chủ đề này theo một lộ trình có cấu trúc, có thể xem Building LLM Powered Applications bản tiếng Việt tại [Wavi Books](/sach/building-llm-powered-applications-valentina-alto-2026). Sách liên quan được đặt sau phần kiến thức để bạn có thể đánh giá nội dung trước khi chọn mua.