Vector database là loại database đưa mọi thứ về một dãy số, rồi tìm kiếm bằng cách đo xem dãy số nào gần dãy số nào. Nó không tìm theo phép so sánh bằng, cũng không tìm theo chuỗi con. Nó tìm theo độ giống nhau.
Nghe thì hơi khó hình dung. Nhưng đây chính là thứ nằm dưới gần như mọi ứng dụng AI mà anh em đang dùng hằng ngày. Tìm ảnh giống ảnh. Gợi ý sản phẩm tương tự. Trợ lý đọc kho tài liệu nội bộ rồi trả lời có dẫn nguồn. Bỏ vector database ra thì cả ba cái đó tắt.
Video gốc tôi quay ngày 23/02/2024. Bài viết này giữ nguyên mạch giải thích trong video, thêm ảnh cắt từ chính video, thêm bảng tra giải thuật index, và thêm hẳn một mục nói rõ hai năm rưỡi vừa rồi thị trường đã đổi những gì.
Bài đi theo thứ tự này:
- Cái demo làm tôi phải ngồi xem lại ba lần
- Vector là cái gì, nói cho người không làm toán
- Máy đưa ảnh với chữ về cùng một dãy số bằng cách nào
- Hai chỗ vector database khác hẳn database quan hệ
- Bên trong nó có những tầng nào
- Thị trường năm 2024, và cái gì đã đổi tới hôm nay
- Bài toán nào thật sự cần tới nó
- Vì sao cuối cùng nó ăn nhau ở hiệu năng
- Bộ câu hỏi tự soi, copy về dùng luôn
- Giới hạn thật, và bảy ngày tới làm được gì
Vì sao một con AI đọc hết cuốn sách 402 trang rồi tìm ra đúng một bức vẽ tay?
Vì nó không đọc chữ và không nhìn ảnh. Nó quy cả hai về cùng một loại dữ liệu, rồi so hai thứ đó với nhau bằng phép đo khoảng cách.
Tôi mở đầu video bằng một demo của Google. Họ đưa vào Gemini 1.5 Pro toàn bộ bản ghi hội thoại của chuyến Apollo 11, dày 402 trang. Rồi họ đưa thêm một bức vẽ tay nguệch ngoạc, đúng kiểu vẽ trên giấy nháp, không kèm một dòng mô tả nào. Câu hỏi vỏn vẹn ba chữ: khoảnh khắc nào đây.
Nó trả lời đúng: đây là lúc Neil Armstrong đặt bước chân đầu tiên xuống mặt trăng. Anh em thấy khó chỗ nào chưa ạ? Con AI này phải xử lý ba loại thông tin cùng lúc. Nội dung nằm trong cuốn sách. Nội dung nằm trong bức vẽ. Và cái ý người dùng đang muốn.
Ba loại đó vốn không so được với nhau. Chữ là chữ, ảnh là ảnh. Muốn so thì phải đưa hết về cùng một hệ quy chiếu.
Cái sức chứa lớn cũng là chuyện đáng nói. Tháng 2 năm 2024 Google công bố Gemini 1.5 Pro với cửa sổ ngữ cảnh một triệu token, và họ đang thử nghiệm mức mười triệu. Một triệu token đó tương đương một giờ video, mười một giờ âm thanh, hơn ba mươi nghìn dòng code, hoặc hơn bảy trăm nghìn từ.
Nhưng sức chứa lớn không giải quyết được bài toán chính. Nhồi 402 trang vào mỗi lần hỏi thì tiền token đi bằng đâu. Và nếu kho tài liệu của công ty là bốn mươi nghìn trang chứ không phải bốn trăm trang thì nhồi kiểu gì. Chỗ đó mới là chỗ vector database bước vào.
Vector là cái gì, nói cho người không làm toán?
Bản chất vector chỉ là một dãy nhiều số. Không hơn.
Anh em quen với ma trận hai chiều hay ba chiều thì dễ hình dung. Một điểm trong không gian ba chiều có ba con số. Dữ liệu thật thì phức tạp hơn nhiều, nên nó cần hàng trăm hoặc hàng nghìn chiều. Cả cái dãy số dài đó gọi là vector.
Tôi ví dụ cho dễ. Lấy năm câu tiếng Anh, chấm mỗi câu theo ba tiêu chí: nói về thời gian tới mức nào, cảm xúc tích cực tới đâu, có dính tới ngoài trời không.
Câu "This park is awesome" ra bộ số 3, 9, 8. Câu "It is great to be out here" ra 3, 8, 8. Hai bộ số nằm sát nhau. Mà đọc hai câu đó lên thì đúng là cùng một ý thật. Trong khi câu "I hate Mondays" ra 2, 1, 1, nằm tít đằng kia.
Đấy. Vector database làm đúng cái việc này, chỉ khác là nó không dùng ba tiêu chí do người đặt tên, nó dùng hàng trăm tới hàng nghìn tiêu chí do mô hình tự học ra. Con người không đọc nổi từng chiều đó nghĩa là gì. Nhưng máy thì đo khoảng cách được, và đo rất nhanh.
Hai vector càng gần nhau thì hai thứ chúng đại diện càng giống nhau. Bài toán tìm kiếm ngữ nghĩa quy về đúng một câu: tìm cho tôi dãy số nào gần dãy số này nhất.
Máy chuyển ảnh với chữ về cùng một dãy số bằng cách nào?
Bằng một thứ gọi là embedding model. Nó đứng ở giữa, nhận vào dữ liệu thô, nhả ra vector.
Chỗ này có một luật anh em phải nhớ: mỗi loại dữ liệu đi qua một mô hình riêng. Chữ đi qua text embedding model. Ảnh đi qua image embedding model. Video đi qua video embedding model. Sai mô hình là ra vector vô nghĩa.
Nhìn sơ đồ này là hiểu hết cái demo Apollo 11. Cuốn sách đi qua mô hình chữ, đẻ ra rất nhiều vector. Bức vẽ đi qua mô hình ảnh, đẻ ra một vector. Câu hỏi của người dùng cũng đi qua mô hình chữ, đẻ ra một vector nữa. Xong rồi máy chỉ việc đo khoảng cách, lấy ông gần nhất, trả về.
Các hãng làm mô hình chuyển đổi khác nhau thì chất lượng khác nhau, và sức chứa mỗi lần nạp cũng khác nhau. Đây là chỗ tiền của anh em đi vào, nên đừng chọn qua loa.
Vector database khác database quan hệ ở hai chỗ nào?
Khác ở lúc đưa dữ liệu vào, và khác ở lúc lấy dữ liệu ra. Hai chỗ đó thôi, nhưng đủ để thành hai loài khác nhau.
Chỗ thứ nhất là lúc ghi. Với MySQL hay PostgreSQL, muốn lưu một bộ phim để sau này tìm được thì phải khai báo trước một loạt cột mô tả: tên phim, đạo diễn, năm sản xuất, thể loại. Không có cột thì sau này không tìm ra. Với vector database thì cứ đẩy thẳng file vào. Trong lúc đẩy, dữ liệu tự thành vector, mà bản thân vector đã mô tả nội dung bên trong rồi.
Chỗ thứ hai là lúc đọc. Database quan hệ tìm bằng so sánh bằng, hoặc tìm bằng toán tử LIKE với một chuỗi con. Tôi tìm bộ phim tên Mai thì gõ tên bằng Mai, hoặc tên chứa Mai. Còn câu hỏi "tìm cho tôi bộ phim giống phim Mai" thì database quan hệ chịu ngay. Nó không có khái niệm giống.
| Chỗ khác | Database quan hệ | Vector database |
|---|---|---|
| Cách đưa vào | Khai báo cột trước, rồi mới điền đạo diễn, tên phim, năm sản xuất | Đẩy thẳng file vào, mô hình embedding tự sinh ra dãy số mô tả nội dung |
| Cách lấy ra | So sánh bằng, hoặc LIKE với một chuỗi con | Đo khoảng cách giữa hai vector, lấy ông gần nhất |
| Câu trả lời được | Phim nào tên là Mai | Phim nào giống phim Mai |
| Index quen dùng | B-tree | Flat, IVF, HNSW, DiskANN, NGT |
| Kết quả trả về | Đúng, hoặc không có gì | Gần đúng, kèm điểm giống nhau |
| Chỗ dễ vỡ | Thiếu cột mô tả là mất đường tìm | Đổi mô hình embedding là phải nạp lại toàn bộ |
Nhìn dòng cuối cùng nhá. Đó là cái giá phải trả, và ít người nói tới lúc đi bán hàng.
Bên trong một vector database có những tầng nào?
Có bốn tầng, và tầng quan trọng nhất nằm dưới cùng.
Luồng ghi đi như sau. Dữ liệu thô nằm ở dưới cùng, gồm tài liệu, video, ảnh, âm thanh. Nó đi qua embedding model tương ứng để thành vector. Vector được rải vào các phân vùng bên trong database. Rồi trên đống vector đó, hệ thống dựng index.
Luồng đọc thì ngược lại. Người dùng gõ một câu bằng tiếng người. Con vector database nói ngay: tôi chỉ làm việc với vector thôi anh ạ. Thế là câu hỏi cũng phải đi qua embedding model để thành vector. Lúc này bài toán rút gọn còn đúng một việc: tìm trong kho vector cái nào gần nhất với vector vừa nhận. Query engine tra qua index rồi trả kết quả về.
Anh em để ý chữ index chưa ạ. Cứ chỗ nào dữ liệu lớn lên là chỗ đó phải có giải thuật tối ưu đường lấy ra. Chuyện này chẳng mới. Nó là chuyện kinh điển của mọi database, và vì sao có index mà SQL vẫn chậm là câu tôi đã có phân tích riêng cho thế giới database quan hệ. Sang vector database thì cái tên vẫn là index, nhưng ruột bên trong khác hẳn.
Thị trường vector database trông ra sao, và hai năm rưỡi vừa rồi đã đổi những gì?
Thị trường chia làm hai trường phái, và cả hai đều đông.
Trường phái thứ nhất là những ông sinh ra chỉ để làm vector, không làm gì khác. Milvus, Qdrant, Weaviate, Pinecone, chroma, LanceDB, Vald, vespa. Sứ mệnh của các ông này gọn một câu: tìm theo độ giống nhau cho thật nhanh.
Trường phái thứ hai là những ông kinh điển nhảy vào sân. PostgreSQL có extension pgvector. Oracle thông báo hỗ trợ từ dòng 23. MongoDB có Atlas Vector Search. Elasticsearch và Redis cũng gắn thêm phần tìm theo vector. Các ông này vốn đẻ ra để làm rất nhiều việc, vector chỉ là một việc thêm vào.
Video gốc quay tháng 2 năm 2024. Từ đó tới nay đã đổi kha khá, nên tôi để nguyên một bảng mốc thời gian để anh em tự đối chiếu.
| Mốc | Chuyện gì xảy ra | Chỗ kiểm lại |
|---|---|---|
| 28/08/2023 | pgvector bản 0.5.0 thêm index HNSW cho PostgreSQL | Changelog pgvector |
| 03/11/2023 | X công bố tính năng gợi ý bài tương tự, Qdrant lên tiếng đó là hệ của họ | Tài khoản Qdrant |
| 04/12/2023 | MongoDB Atlas Vector Search lên bản chính thức | Thông cáo MongoDB |
| 15/02/2024 | Gemini 1.5 Pro mở cửa sổ một triệu token, đang thử nghiệm mười triệu | Blog Google |
| 23/02/2024 | Video gốc của bài này lên sóng | Kênh Trần Quốc Huy |
| 29/04/2024 | pgvector bản 0.7.0 thêm halfvec, sparsevec và hàm binary_quantize | Changelog pgvector |
| 10/2025 | Oracle đổi tên 23ai thành Oracle AI Database 26ai tại Oracle AI World | Tài liệu Oracle |
| 08/2026 | pgvector đang ở bản 0.8.6, kiểu vector chứa tối đa 16.000 chiều | Kho mã pgvector |
Có một dòng trong bảng này đáng nói riêng. Trong video, tôi có nhận xét rằng giải thuật index của pgvector còn nghèo hơn mấy ông chuyên dụng, vì lúc đó nó mới có IVF. Hôm nay câu đó đã cũ. pgvector giờ có cả HNSW, có halfvec để cắt một nửa bộ nhớ, có sparsevec, có cả lượng tử hoá nhị phân. Với phần lớn bài toán trong doanh nghiệp Việt Nam, một con PostgreSQL cắm thêm pgvector là chạy được, không cần dựng hệ mới.
Nhận xét cũ sai vì thời gian trôi, chứ không phải sai vì đánh giá ẩu. Ngành này chạy nhanh hơn cả tài liệu của chính nó. Nên mọi bảng so sánh sản phẩm anh em đọc được, kể cả bảng của tôi, đều phải nhìn kèm ngày tháng.
Bài toán nào thật sự cần tới vector database?
Có ba nhóm hay gặp. Hai nhóm đầu quen mặt rồi, nhóm thứ ba mới là nhóm hút tiền đầu tư.
Gợi ý những thứ tương tự
Anh em vào một trang thương mại điện tử, tìm một sản phẩm, rồi kéo xuống dưới thấy dãy "sản phẩm tương tự". Đó chính là chỗ vector database đứng.
Cái này chạy được vì mỗi sản phẩm đã thành một vector, gồm cả ảnh lẫn mô tả. Tìm sản phẩm tương tự tức là tìm vector gần nhất. Ông nào đang định làm tính năng gợi ý, hoặc làm hệ hỗ trợ ra quyết định, thì nghĩ tới nó ngay từ đầu.
Nhắc bài cho mô hình ngôn ngữ, tức là RAG
Đây mới là chỗ tiền đổ vào.
Mô hình ngôn ngữ có một điểm dở: nó chỉ biết những gì có trong dữ liệu huấn luyện, mà dữ liệu đó dừng ở một mốc quá khứ. Tôi hỏi Ronaldo chơi cho câu lạc bộ nào mùa 2023 và 2024, mà mô hình chỉ học tới 2021, thì nó tắc.
Vector database xuất hiện đúng lúc đó, đóng vai người bạn ngồi cạnh nhắc bài.
Luồng chạy đúng bốn bước. Câu hỏi đi qua embedding model để thành vector. Vector đó đi tìm trong kho, qua index. Kho trả về đoạn văn bản gần nghĩa nhất. Mô hình ngôn ngữ nhận đoạn đó rồi mới viết câu trả lời.
Kết quả là mô hình biết những chuyện xảy ra sau ngày dữ liệu huấn luyện của nó dừng lại. Với doanh nghiệp thì thay chỗ báo chí bằng kho tài liệu nội bộ, quy trình, hợp đồng, biên bản. Trợ lý trả lời bằng đúng dữ liệu của công ty, và dẫn được nguồn.
Tìm kiếm trong kho tài liệu nội bộ
Nhóm này ít được nhắc mà lại dễ ăn nhất. Công ty nào cũng có một đống file nằm rải rác. Tìm bằng từ khoá thì trượt, vì người viết dùng chữ này còn người tìm dùng chữ khác. Tìm theo độ giống nhau thì hai cách nói khác nhau vẫn về chung một chỗ.
Vì sao tôi nói cuối cùng nó sẽ ăn nhau ở hiệu năng?
Vì khi ai cũng nhét được dữ liệu phi cấu trúc vào database, thì thứ còn lại để phân thắng bại chỉ còn tốc độ lấy ra.
Đây là quan điểm của tôi khi làm việc với các dự án thật. Dữ liệu bên ngoài doanh nghiệp phần lớn không có cấu trúc. Khi việc đưa vào đã dễ với mọi hệ, số vector sẽ không dừng ở vài trăm nghìn. Nó lên hàng tỷ. Lúc đó câu hỏi duy nhất còn lại là lấy ra nhanh được không.
Mà tốc độ lấy ra thì quyết định phần lớn ở index. Index trong vector database không đơn giản như trong database quan hệ. Bên kia anh em quen với B-tree là chính. Bên này có cả một rừng giải thuật.
Nhìn bảng trên là đọc ra ngay ai đang mạnh chỗ nào. Tôi gộp lại thành bảng dưới cho anh em dễ tra.
| Giải thuật | Nó làm gì | Được và mất | Ai đang dùng |
|---|---|---|---|
| Flat | Quét hết, so từng vector một | Chính xác tuyệt đối. Dữ liệu lớn là chậm ngay | elasticsearch, redis, milvus |
| IVF | Chia không gian thành cụm, chỉ quét vài cụm gần nhất | Dựng nhanh, tốn ít bộ nhớ. Chia cụm hỏng thì độ chính xác tụt | pgvector, LanceDB, milvus |
| HNSW | Dựng đồ thị nhiều tầng, nhảy dần từ tầng thô xuống tầng mịn | Truy vấn nhanh nhất nhóm này. Dựng lâu và ngốn bộ nhớ | Qdrant, chroma, Weaviate, vespa, redis |
| DiskANN | Giữ đồ thị trên ổ đĩa thay vì nhồi hết vào bộ nhớ | Chịu được tập rất lớn. Phụ thuộc tốc độ ổ đĩa | milvus, Weaviate, LanceDB |
| NGT | Kết hợp cây với đồ thị lân cận | Ít gặp trong dự án ở Việt Nam | Vald |
Cứ thấy chữ Flat là biết nó quét toàn bộ. Giả sử tôi có một tỷ vector trong kho, mỗi lần hỏi nó lấy lần lượt cả một tỷ ra so khoảng cách. Đây đúng là chuyện full scan trên dữ liệu lớn mà tôi đã có chia sẻ rất nhiều lần ở mảng SQL. Hệ quả giống hệt nhau: chạy được lúc dữ liệu nhỏ, rồi chết lúc dữ liệu lớn, mà cùng một câu lệnh lúc nhanh lúc chậm là dấu hiệu đầu tiên anh em nhìn thấy.
Trong mắt tôi ở thời điểm quay video, Qdrant và Milvus là hai ngôi sao đang lên. Cả hai đều công bố giải quyết được bài toán tìm kiếm nhanh tới mức vừa gõ vừa ra kết quả.
Cuối năm 2023, X công bố tính năng gợi ý bài viết tương tự. Qdrant lên tiếng ngay rằng phần tìm kiếm đó chạy trên hệ của họ. Một nền tảng cỡ đó chọn ai thì đó là một phiếu bầu đáng tin, vì họ không có chỗ nào để giấu chuyện chậm.
Bài toán của anh em có cần vector database không?
Phần lớn trường hợp tôi gặp là chưa cần. Nhưng đừng tin câu đó của tôi, cũng đừng tin ông bán hàng. Tự soi bằng bộ câu hỏi dưới đây.
Anh em copy nguyên khối này về, điền số thật vào, rồi mang ra họp. Nó chặn được kiểu quyết định mua hệ mới chỉ vì thấy người khác mua.
BỘ CÂU HỎI TỰ SOI: BÀI TOÁN CỦA TÔI CÓ CẦN VECTOR DATABASE KHÔNG
Điền số thật. Ô nào chưa có số thì ghi CHƯA ĐO, đừng ước lượng.
[1] Người dùng đang đi tìm cái gì?
A. Tìm đúng một bản ghi đã biết mã, biết tên, biết khoảng ngày
B. Tìm những thứ GIỐNG với một đoạn văn, một tấm ảnh, một câu hỏi
Trả lời A thì dừng lại ở đây. Database đang chạy là đủ.
[2] Dữ liệu nguồn có cấu trúc tới đâu?
A. Đã có bảng, có cột, có kiểu dữ liệu rõ ràng
B. Là PDF, ảnh chụp, ghi âm, email, ghi chú rời rạc
[3] Bao nhiêu bản ghi cần tìm theo độ giống nhau?
Con số thật: .............. bản ghi
Dưới 100.000 thì extension trên database sẵn có thường đã đủ
[4] Mỗi bản ghi thành vector bao nhiêu chiều?
Con số thật: .............. chiều
Nhân số chiều với số bản ghi rồi nhân 4 byte, ra mức bộ nhớ tối thiểu
[5] Người dùng chờ được bao lâu cho một lần tìm?
Con số thật: .............. mili giây, đo ở phân vị 95
[6] Kết quả gần đúng có chấp nhận được không?
A. Sai là hỏng nghiệp vụ, ví dụ đối chiếu công nợ, tính lương
B. Sai một chút vẫn dùng được, ví dụ gợi ý sản phẩm, tìm tài liệu
Trả lời A thì tìm theo độ giống nhau không phải công cụ đúng
[7] Dữ liệu đổi bao nhiêu lần một ngày?
Con số thật: .............. lượt thêm, sửa, xoá mỗi ngày
Index kiểu đồ thị dựng lâu. Đổi liên tục là chỗ đau nhất
[8] Ai trong đội vận hành được thêm một hệ thống nữa?
Tên người: ..............
Không điền được tên thì coi như chưa có người
[9] Đã đo cách rẻ nhất chưa?
Chạy thử tìm bằng từ khoá trên database sẵn có, trên đúng 100 câu hỏi thật
Số câu trả về đúng: .............. trên 100
Chưa có con số này thì chưa được phép kết luận cách cũ không đủ
CHỐT:
Câu 1 và câu 2 cùng chọn B, câu 3 vượt 100.000, câu 9 đã đo và cách cũ trượt.
Đủ cả bốn điều đó mới đi tiếp. Thiếu một điều thì chưa cần vector database.Câu số 9 là câu hay bị bỏ qua nhất. Không đo cách cũ thì mọi so sánh về sau đều là cảm tính, và tối ưu nên bắt đầu từ đâu vẫn là câu hỏi phải trả lời trước, dù anh em đang ở thế giới SQL hay thế giới vector.
Giới hạn thật của vector database
Phần này tôi viết từ chỗ đau, không viết từ tài liệu quảng cáo.
Kết quả là gần đúng, không phải đúng. Mọi giải thuật index nhanh đều đánh đổi độ chính xác lấy tốc độ. Nó trả về thứ gần nhất mà nó tìm thấy, chứ không cam kết đó là thứ gần nhất trong kho. Bài toán nào cần con số khớp tuyệt đối thì đừng đưa cho nó.
Đổi mô hình embedding là nạp lại toàn bộ. Vector do mô hình cũ sinh ra không so được với vector do mô hình mới sinh ra. Kho một tỷ bản ghi thì đây là một dự án, không phải một buổi chiều.
Index đồ thị ngốn bộ nhớ. HNSW nhanh vì nó giữ cả đồ thị trong bộ nhớ. Tính chi phí máy chủ trước khi chọn, đừng tính sau.
Dữ liệu đổi liên tục là chỗ đau nhất. Index dạng đồ thị dựng lâu. Chính vì vậy mà tới bản Oracle AI Database 26ai, việc cho phép thêm sửa xoá trên bảng đang có index HNSW mới được nêu ra như một cải tiến đáng kể.
Cắm pgvector vào con Postgres đang chạy nghiệp vụ là gánh thêm tải cho chính nó. Vector chiếm nhiều dung lượng, mà dung lượng bảng phình ra thì hiệu năng đi xuống. Đây đúng là câu chuyện VACUUM trong PostgreSQL ảnh hưởng tới hiệu năng thế nào, và ở bài này tôi không nhắc lại. Cũng cùng con Postgres đó, phần lọc kèm theo truy vấn vector vẫn cần index thường, mà thứ tự các cột trong index quyết định index đó có được dùng hay không.
Chọn hệ có sẵn thì thừa hưởng luôn cả tính nết của nó. Dùng Atlas Vector Search nghĩa là sống chung với kiến trúc MongoDB, và MongoDB lúc nhanh lúc chậm vì kiến trúc ít người để ý là bài tôi có phân tích riêng chuyện đó.
Không đo thì đừng kết luận. Trước khi nói hệ này nhanh hơn hệ kia, phải có số của cùng một tập dữ liệu, cùng một bộ câu hỏi. Thói quen đọc kế hoạch thực thi trong EXPLAIN và EXPLAIN ANALYZE áp thẳng sang đây được: đo cái máy thật sự làm, đừng đo cái mình tưởng nó làm.
Và giới hạn lớn nhất nằm ngoài công nghệ. Vector database không biết nghiệp vụ của công ty anh em. Nó tìm cái giống nhau. Còn giống theo tiêu chí nào mới đúng với việc kinh doanh thì đó là câu của người, không phải câu của máy.
Bảy ngày tới anh em làm được gì?
Không cần mua gì cả. Bảy việc dưới đây làm bằng thứ đang có.
- Viết ra một câu hỏi thật mà hệ thống hiện tại đang trả lời sai hoặc trả lời trượt. Một câu thôi, càng cụ thể càng tốt.
- Gom đúng 100 câu hỏi thật của người dùng hoặc của nhân viên. Lấy từ ticket, từ chat nội bộ, từ email.
- Chạy 100 câu đó qua cách tìm kiếm hiện tại. Đếm số câu ra đúng. Đây là mốc gốc, không có nó thì không so được gì.
- Chọn một kho tài liệu nhỏ, khoảng vài nghìn trang, làm sân tập. Đừng động vào kho quan trọng nhất ngay lần đầu.
- Dựng thử một con PostgreSQL riêng, cắm pgvector, nạp kho tài liệu đó vào. Chưa cần đụng tới hệ đang chạy sản xuất.
- Chạy lại đúng 100 câu hỏi đó. Đếm lại số câu ra đúng, và đo cả thời gian trả lời.
- Điền hai con số vào bộ câu hỏi tự soi ở trên rồi mang ra họp. Quyết định lúc đó mới có căn cứ.
Làm đi rồi sửa. Bản đầu bao giờ cũng còn nhiều chỗ chưa ổn, chạy được cái đã.
Câu hỏi hay gặp
Vector database có thay thế database quan hệ không?
Không. Hai loại giải hai bài toán khác nhau. Database quan hệ lo dữ liệu có cấu trúc, cần chính xác tuyệt đối, cần giao dịch. Vector database lo chuyện tìm theo độ giống nhau trên dữ liệu không có cấu trúc. Phần lớn hệ thống thật chạy song song cả hai, mỗi bên một việc.
Chưa có ngân sách mua hệ mới thì bắt đầu từ đâu?
Bắt đầu bằng pgvector trên PostgreSQL. Nó là extension, cài xong là có kiểu dữ liệu vector, có index IVFFlat và HNSW. Bản 0.8.6 hiện tại chứa được vector tới 16.000 chiều, thừa cho phần lớn mô hình embedding phổ biến. Chạy tốt rồi hãy tính chuyện tách ra hệ chuyên dụng.
Mô hình có cửa sổ một triệu token rồi thì còn cần vector database không?
Vẫn cần. Cửa sổ lớn giải bài toán đọc một tài liệu dài trong một lần hỏi. Nó không giải bài toán kho bốn mươi nghìn trang, cũng không giải bài toán tiền token. Nhồi cả kho vào mỗi câu hỏi thì vừa chậm vừa đắt. Tìm trước rồi mới đưa đúng phần cần đọc vào, đó vẫn là cách rẻ nhất.
RAG có bắt buộc phải dùng vector database không?
Không bắt buộc. RAG chỉ có nghĩa là tìm trước rồi mới trả lời. Kho nhỏ thì tìm bằng từ khoá cũng chạy. Vector database trở nên đáng tiền khi người hỏi và người viết dùng hai bộ từ khác nhau, hoặc khi kho lớn tới mức quét hết là chậm.
Nâng cấp phiên bản database có làm truy vấn nhanh hơn không?
Có, ở một số trường hợp, và cơ chế thì không phải phép màu. Bộ tối ưu của phiên bản mới chọn được đường thực thi tốt hơn. Tôi có phân tích chuyện này ở bài hiệu năng MySQL 8 và các nâng cấp trong query optimizer. Với vector cũng vậy, pgvector đổi bản là đổi luôn giải thuật index có sẵn.
Vector database dính vào AI Agent ở chỗ nào?
Nó là phần trí nhớ tra cứu được. Agent muốn làm việc thật thì phải đọc được tài liệu của công ty, và đọc có chọn lọc. Tôi có chia sẻ nguyên cách dựng đội ngũ AI Agent vận hành doanh nghiệp, còn một ví dụ chạy thật trên nghiệp vụ kế toán thì nằm ở bài AI Agent kiểm tra hoá đơn đầu vào.
Đúc kết
Vector database đưa mọi loại dữ liệu về cùng một dãy số, rồi tìm bằng cách đo khoảng cách. Đó là toàn bộ ý tưởng, phần còn lại là kỹ thuật.
Thứ quyết định thắng thua về lâu dài là hiệu năng, mà hiệu năng nằm phần lớn ở giải thuật index. Ai làm database lâu năm thì thấy quen ngay, vì đây đúng là câu chuyện cũ mặc áo mới.
Và trước khi mua bất cứ thứ gì, hãy đo cách rẻ nhất trước. Điền cho xong bộ câu hỏi tự soi ở trên. Nếu Postgres với pgvector đã chạy đủ nhanh cho 100 câu hỏi thật của anh em thì cứ dùng, chưa cần đi đâu cả. Tùy anh em, hướng nào cũng được, miễn là có số trong tay.
Nguồn tham khảo
- Google, thông báo Gemini 1.5 Pro ngày 15/02/2024: blog.google
- pgvector, kho mã và nhật ký thay đổi: github.com/pgvector/pgvector
- MongoDB, thông cáo Atlas Vector Search lên bản chính thức ngày 04/12/2023: mongodb.com
- Oracle, tài liệu AI Vector Search cho Oracle AI Database 26ai: docs.oracle.com
- Qdrant, thông báo về tính năng gợi ý bài tương tự trên X: x.com/qdrant_engine
