Vector database trả lời đúng một câu hỏi, rất nhanh
Đưa cho nó một dãy số và nó trả về những dãy được lưu trữ gần với dãy đó nhất. Đó là toàn bộ giao diện.
Các dãy số đó là embedding. Một mô hình embedding biến một đoạn văn, một mô tả sản phẩm hay một hình ảnh thành vài trăm đến vài nghìn con số, được sắp xếp sao cho những ý nghĩa tương tự nằm gần nhau, và embedding trong AI là gì trình bày cách làm điều đó. Vector database là nơi những dãy số đó cư trú khi bạn có rất nhiều dãy như vậy. Nó lưu mỗi dãy cùng một ID và một số metadata, xây dựng một chỉ mục trên chúng, và trả lời truy vấn hàng xóm gần nhất: "đây là một vector truy vấn, cho tôi mười dãy gần nhất."
Phần khó nằm ở chữ nhanh. So sánh một truy vấn với một triệu vector được lưu, mỗi vector có 1.536 con số, là 1,5 tỷ phép nhân, và làm điều đó ở mỗi lần gõ phím thì không thể mở rộng được. Vì vậy vector database dùng chỉ mục hàng xóm gần đúng gần nhất, phổ biến nhất là HNSW, một cấu trúc đồ thị từ một bài báo năm 2016 của Malkov và Yashunin, chỉ xét vài trăm ứng viên thay vì cả triệu và gần như luôn trả về câu trả lời đúng. Chữ "gần như" đó chính là sự đánh đổi: một chút độ chính xác đổi lấy tốc độ nhanh hơn cả nghìn lần.
Cơ sở dữ liệu hiện có của bạn khớp từ ngữ; vector database khớp ý nghĩa
Một cơ sở dữ liệu quan hệ tìm các hàng có giá trị khớp: WHERE customer_id = 4127. Một chỉ mục tìm kiếm toàn văn tìm các tài liệu chứa từ ngữ: refund AND policy. Vector database tìm các mục có ý nghĩa gần: truy vấn "làm sao để lấy lại tiền" trả về đoạn văn có tiêu đề "Đổi trả và hoàn tiền" dù hai câu không chung từ nào.
| Cơ sở dữ liệu quan hệ | Tìm kiếm toàn văn | Vector database | |
|---|---|---|---|
| Đặt câu hỏi | Hàng nào khớp giá trị này? | Tài liệu nào chứa những từ này? | Mục nào mang ý nghĩa gần với cái này? |
| Chỉ mục | B-tree trên các cột | Chỉ mục đảo trên các từ | Đồ thị hoặc phân cụm trên vector (HNSW, IVF) |
| Chính xác? | Có | Có | Thường là gần đúng |
| Mạnh về | ID, ngày tháng, số tiền, phép nối | Tên, mã, cụm từ chính xác | Từ đồng nghĩa, diễn đạt lại, đa ngôn ngữ, hình ảnh |
| Yếu về | Ý nghĩa | Ý nghĩa | Chuỗi chính xác, đếm, lọc theo giá trị |
| Ví dụ | Postgres, MySQL, SQLite | Elasticsearch, Lucene | Pinecone, Weaviate, Qdrant, Milvus, Chroma, pgvector |
Hàng cuối cho thấy ranh giới của danh mục này mờ nhạt đến mức nào. pgvector thêm các cột vector và chỉ mục HNSW vào Postgres thông thường, còn Elasticsearch đã mang trường vector từ phiên bản 7.0 năm 2019 và tìm kiếm HNSW từ 8.0 năm 2022. Một "vector database" thường là một khả năng bên trong cơ sở dữ liệu bạn đang chạy sẵn hơn là một sản phẩm mới, và các sản phẩm độc lập cạnh tranh nhau về quy mô cùng sự hoàn thiện vận hành, chứ không phải làm được điều mà Postgres không làm được.
Chat với tài liệu của bạn là một lượt tìm kiếm vector cộng với mô hình ở cuối
Retrieval-augmented generation, được RAG là gì trình bày chi tiết, có một bước tìm kiếm và một bước viết. Vector database chính là bước tìm kiếm.
- Chia mỗi tài liệu thành các đoạn dài vài trăm đến một nghìn token.
- Tạo embedding cho từng đoạn và lưu các vector, cùng văn bản của đoạn và nguồn của nó, vào vector database.
- Khi một câu hỏi xuất hiện, tạo embedding cho câu hỏi đó và yêu cầu cơ sở dữ liệu tìm các đoạn gần nhất.
- Đưa những đoạn đó cho mô hình ngôn ngữ cùng câu hỏi, và để mô hình viết câu trả lời.
Bước 1 và 2 chỉ diễn ra một lần, khi tài liệu được thêm vào. Bước 3 và 4 diễn ra ở mỗi câu hỏi. Mô hình ngôn ngữ không bao giờ thấy toàn bộ bộ dữ liệu; nó chỉ thấy năm hoặc mười đoạn mà cơ sở dữ liệu chọn ra. Đó là lý do câu trả lời chỉ tốt bằng khả năng tìm kiếm: nếu vector gần nhất là đoạn sai, mô hình sẽ tự tin trả lời sai câu hỏi, điều mà ảo giác AI là gì xếp vào lỗi tìm kiếm chứ không phải sự bịa đặt.
Khi nào bạn cần đến nó, và khi nào gửi cả file là lựa chọn tốt hơn
Quyết định này xoay quanh kích thước. Một mô hình chỉ có thể xem xét cửa sổ ngữ cảnh của nó tại một thời điểm, và mỗi token bên trong đó đều được tính phí ở mỗi lượt. Vector database tồn tại để chỉ đưa phần liên quan ra trước mô hình. Với một tài liệu vừa vặn, việc tìm kiếm là bước bạn có thể bỏ qua; với một bộ dữ liệu không vừa, đó là lựa chọn duy nhất.
Hãy định giá hai cách thiết kế trên một báo cáo 300.000 token, vài trăm trang, được hỏi mười câu, mỗi câu truy xuất năm đoạn 1.000 token. Gửi cả file mỗi lần là 3 triệu token đầu vào. Truy xuất năm đoạn 1.000 token mỗi câu hỏi là 50.000 token. Theo mức giá đầu vào niêm yết trong bảng chỉ số chi phí mô hình AI, lấy từ OpenRouter ngày 2026-08-20, khoảng cách là 60 lần trên mọi mô hình. Prompt caching, ở nơi nhà cung cấp có hỗ trợ, tính phí đọc lại cùng một file bằng một phần mười đến một nửa giá niêm yết, thu hẹp khoảng cách còn khoảng 6 đến 30 lần. Truy xuất vẫn thắng, chỉ là ít hơn.
Thiết kế gửi cả file mua được điều gì đó với số tiền ấy khi file vừa với ngân sách: một hợp đồng 60 trang, khoảng 40.000 token, cho phép mô hình trả lời những câu hỏi cần toàn bộ tài liệu cùng lúc, chẳng hạn "có điều gì ở đây mâu thuẫn với điều khoản 14 không", điều mà truy xuất không thể hỏi vì nó không bao giờ thấy điều khoản 14 và phần mâu thuẫn trong cùng một lô. Quy tắc rút ra: một tài liệu, hoặc một nhóm nhỏ, đưa vào nguyên vẹn; một thư viện thì đi qua vector database. Ở giữa hai trường hợp, hãy chia bản tải lên theo chủ đề để mô hình nhận được đúng phần nó cần.
Whizi gửi thẳng văn bản, tối đa một lượt 40.000 token
Whizi không chạy vector database cho cuộc trò chuyện của bạn. Khi bạn đính kèm một file, đường dẫn tải tài liệu lên trích xuất văn bản và gửi nó cho mô hình dưới dạng văn bản prompt, tối đa ngân sách cố định 40.000 token mỗi lượt; một bản tải lên dài hơn sẽ bị cắt bớt, kèm một thông báo toast và một dấu hiệu trong tin nhắn báo điều đó. File dự án hoạt động theo cách tương tự: tính năng dự án ghim tối đa 10 file và dựng lại văn bản của chúng vào prompt ở mỗi tin nhắn, giới hạn ở 32.000 ký tự mỗi file và 120.000 ký tự cho toàn bộ khối dự án.
Các giới hạn này chính là ranh giới của thiết kế. Một file được ghim vượt quá 32.000 ký tự sẽ bị cắt bớt, một bản đính kèm vượt quá ngân sách 40.000 token mỗi lượt sẽ bị cắt, và một dự án là một thư mục, không phải một thư viện có thể tìm kiếm. Sự đánh đổi này là có chủ đích: với một hợp đồng hay một bài báo vừa với ngân sách của lượt trò chuyện, việc có sẵn toàn bộ văn bản tốt hơn việc phải tìm kiếm nó, và phép kiểm tra quan trọng, yêu cầu mô hình trích dẫn đoạn nó đã dùng, hoạt động được vì đoạn đó luôn có mặt. Với hàng nghìn tài liệu, vector database mới là công cụ đúng và một ứng dụng chat là công cụ sai.
Hai thói quen được kế thừa từ cơ chế này. Hãy nêu tên file trong câu hỏi của bạn khi có nhiều file được đính kèm, vì nếu không mô hình sẽ tự chọn mà không nói gì. Và với bất kỳ câu trả lời nào bạn sẽ hành động theo, hãy yêu cầu trích dẫn. Một hệ thống truy xuất có thể trả về sai đoạn; một hệ thống dùng cả file có thể trả lời từ trí nhớ thay vì từ file. Yêu cầu trích dẫn bắt được cả hai lỗi này.
- Gửi một tài liệu nguyên vẹn; đặt một bộ sưu tập sau vector database
- Chia một bản tải lên dài theo chủ đề để mô hình nhận được đúng phần câu hỏi cần
- Yêu cầu mô hình trích dẫn đoạn nó đã dùng trước khi dựa vào câu trả lời
- Dùng tìm kiếm văn bản thuần cho ID, mã và cụm từ chính xác; tìm kiếm vector khớp ý nghĩa, không khớp ký tự
- Coi một lần truy xuất sai là vấn đề tìm kiếm: tạo embedding lại bằng mô hình tốt hơn hoặc đoạn nhỏ hơn trước khi đổ lỗi cho mô hình viết
Câu hỏi thường gặp
Vector database là gì, nói theo cách đơn giản?
Một kho lưu trữ các dãy số mà mô hình AI dùng để đại diện cho ý nghĩa, được xây dựng để tìm những kết quả gần nhất thật nhanh. Bạn đưa cho nó embedding của một câu hỏi và nó trả về các embedding, cùng văn bản đứng sau chúng, mang ý nghĩa tương tự. Đây là nửa tìm kiếm của việc chat với tài liệu của bạn bất cứ khi nào bộ dữ liệu quá lớn để gửi nguyên vẹn.
Tôi có cần vector database để dùng AI với tài liệu của mình không?
Chỉ khi tài liệu không vừa với cửa sổ ngữ cảnh của mô hình. Một báo cáo hay hợp đồng đơn lẻ có thể được gửi nguyên vẹn cho mô hình, đó là cách Whizi xử lý với file đính kèm và file dự án được ghim. Một thư viện gồm hàng nghìn tài liệu cần đến truy xuất, và truy xuất cần một chỉ mục vector, dù là trong một sản phẩm chuyên biệt hay một tiện ích mở rộng Postgres như pgvector.
Sự khác biệt giữa vector database và cơ sở dữ liệu thông thường là gì?
Một cơ sở dữ liệu thông thường khớp giá trị: ID này, ngày này, từ chính xác này. Vector database khớp ý nghĩa, trả về các mục được lưu có embedding nằm gần với truy vấn nhất. Nó thường là gần đúng, dùng một chỉ mục như HNSW kiểm tra vài trăm ứng viên thay vì mọi mục, và nó kém ở phép khớp chính xác mà một cơ sở dữ liệu thông thường làm tốt.
Vector database nào được dùng nhiều nhất?
Pinecone, Weaviate, Qdrant, Milvus và Chroma là những sản phẩm độc lập phổ biến, và pgvector thêm cùng khả năng đó vào Postgres. Elasticsearch và OpenSearch cũng hỗ trợ tìm kiếm vector. Lựa chọn thường mang tính vận hành, xoay quanh quy mô và hạ tầng lưu trữ, vì tất cả đều triển khai cùng ý tưởng hàng xóm gần đúng gần nhất.
Truy xuất tiết kiệm được bao nhiêu so với gửi cả file?
Mười câu hỏi trên một báo cáo 300.000 token tốn $6.00 với Claude Sonnet 5 nếu file được gửi ở mỗi lượt và $0.10 nếu năm đoạn 1.000 token được truy xuất thay vào đó, theo mức giá niêm yết của OpenRouter lấy ngày 2026-08-20. Với GPT-5.6 Luna, cặp số tương ứng là $0.60 so với $0.01. Tỷ lệ là 60 lần trên mọi mô hình vì cả hai cách thiết kế đều trả cùng mức giá trên mỗi token.
