Vector Database
Kho lưu và tìm kiếm các vector embedding theo độ gần nghĩa, trả về những đoạn giống nhất trong mili giây. Nhiều dự án nội bộ chỉ cần extension pgvector trên Postgres sẵn có là đủ.
Định nghĩa
Có embedding rồi thì phải cất ở đâu đó, và phải tìm được nhanh. Vector database sinh ra cho đúng việc này: lưu hàng triệu dãy số, và khi nhận một dãy số mới thì trả về những dãy gần nó nhất trong vài chục mili giây. Nếu duyệt tuần tự từng bản ghi thì việc đó bất khả thi, nên bên trong nó dùng các cấu trúc chỉ mục xấp xỉ — đánh đổi một chút độ chính xác lấy tốc độ.
Đây là hạ tầng, không phải tính năng. Người dùng cuối chẳng bao giờ biết nó tồn tại, nhưng BA thì phải biết vì nó kéo theo cả chuỗi câu hỏi về dữ liệu cá nhân và phân quyền.
Khác database quan hệ ở đâu
| Database quan hệ | Vector database | |
|---|---|---|
| Câu hỏi trả lời được | "Đơn nào của khách X trong tháng 7" | "Đoạn nào nói về ý gần giống câu này nhất" |
| Kết quả | Đúng hoặc không có | Danh sách xếp hạng theo độ gần, luôn có kết quả |
| Chỉ mục | B-tree, chính xác | Xấp xỉ, đánh đổi tốc độ lấy độ chính xác |
| Ràng buộc dữ liệu | Khoá ngoại, kiểu dữ liệu, transaction | Gần như không |
| Phân quyền theo dòng | Có sẵn ở nhiều hệ | Thường phải tự làm bằng bộ lọc metadata |
Phân quyền theo dòng — cái nằm ở đáy bảng — là chỗ tốn thời gian nhất khi làm cho doanh nghiệp. Bên dưới nói kỹ.
Khi nào dự án thật sự cần một cái riêng
Phần lớn hệ thống nội bộ mình gặp ở Việt Nam không cần dựng một vector database chuyên dụng. Nếu dự án đã chạy Postgres, extension pgvector xử lý được vài trăm nghìn đoạn văn bản một cách thoải mái, và bạn được thêm một thứ quý: dữ liệu vector nằm cùng chỗ với dữ liệu nghiệp vụ, nên phân quyền, sao lưu, kiểm toán dùng chung cơ chế sẵn có.
Cần hệ chuyên dụng khi: số đoạn lên tới hàng chục triệu, cần truy vấn dưới 50 mili giây ở tải cao, cần cập nhật chỉ mục liên tục theo thời gian thực, hoặc team đã có sẵn kinh nghiệm vận hành nó.
Nếu ai đó đề xuất một dịch vụ vector trả phí ngay từ sprint đầu cho một kho tài liệu 740 trang, cứ hỏi con số dự kiến về số đoạn và số truy vấn mỗi giây. Thường thì câu hỏi đó tự kết thúc cuộc tranh luận.
Ví dụ thực tế
Dược sĩ đứng ở quầy, khách chờ trước mặt, câu hỏi là thuốc này bảo quản dưới 25 độ hay dưới 30 độ. Một chuỗi nhà thuốc 137 cửa hàng dựng trợ lý tra cứu nội bộ cho đúng loại tình huống đó: hướng dẫn bảo quản, chính sách đổi trả, quy định bán thuốc kê đơn, và bảng tương tác thuốc do phòng chuyên môn soạn.
Toàn bộ tài liệu sau khi cắt ra được 26.400 đoạn. Chạy trên pgvector cùng cụm Postgres của hệ thống bán hàng, truy vấn trung bình dưới 80 mili giây với 45 người dùng đồng thời. Không có dịch vụ ngoài, không thêm hợp đồng, không thêm một hệ thống nữa để trực đêm.
Phần khó không nằm ở hạ tầng. Nó nằm ở chỗ: tài liệu chính sách nhân sự và bảng lương thưởng theo cửa hàng cũng được đề xuất đưa vào cùng kho, và lúc đó câu hỏi "dược sĩ ở cửa hàng A có được đọc đoạn nói về thưởng của cửa hàng B không" trở thành một yêu cầu thiết kế thật sự.
Câu hỏi BA nên hỏi team
- Phân quyền ở bước nào? Lọc trước khi tìm hay lọc sau khi tìm. Lọc sau thì có nguy cơ trả về ít kết quả hơn dự kiến; lọc trước thì cần metadata đầy đủ trên từng đoạn. Chốt sớm, đừng để tới lúc rà bảo mật.
- Xoá thì xoá được không? Khách yêu cầu xoá dữ liệu cá nhân, hoặc một tài liệu bị thu hồi. Phải xoá được cả đoạn trong kho vector, chứ không riêng file gốc. Hỏi luôn: xoá xong có phải chạy lại chỉ mục không, mất bao lâu.
- Đổi mô hình embedding thì sao? Toàn bộ 26.400 đoạn phải tạo lại vector. Ai làm, mất bao lâu, trong lúc đó hệ thống chạy bằng gì.
- Dữ liệu cá nhân có bị nhét vào đoạn không? Nhiều kho tài liệu nội bộ có kèm ví dụ minh hoạ chứa tên và số điện thoại thật. Cần một bước rà và che trước khi nạp.
- Sao lưu và khôi phục. Nghe hiển nhiên, nhưng kho vector hay bị coi là "dữ liệu dẫn xuất, tạo lại được" — cho tới lúc tạo lại mất 9 tiếng vào đúng ngày cao điểm.
