Bài 8. Lưu vector bằng FAISS

1. Đặt vấn đề

Sau khi tạo embedding cho các chunk tài liệu, cần một nơi lưu vector và tìm kiếm vector nhanh. FAISS là một thư viện phổ biến để tìm kiếm vector hiệu quả, phù hợp cho triển khai local. Trong hệ thống AI local bệnh viện, FAISS có thể đóng vai trò “bộ nhớ tìm kiếm ngữ nghĩa” cho kho tài liệu nội bộ.

Tuy nhiên, FAISS chỉ là nơi lưu và tìm vector. Nó không thay thế quản lý tài liệu, metadata, phân quyền, hiệu lực, log hoặc giao diện người dùng. Muốn dùng FAISS tốt trong bệnh viện, cần thiết kế cách lưu vector và metadata đi kèm.

2. FAISS là gì?

FAISS là thư viện tìm kiếm vector. Nó cho phép lưu nhiều vector embedding và tìm các vector gần nhất với vector truy vấn. Trong RAG, FAISS nhận vector của câu hỏi và trả về các chunk có vector gần nhất.

Có thể hiểu FAISS như một công cụ tìm kiếm theo “độ gần ý nghĩa”.

3. Vì sao dùng FAISS cho AI local?

FAISS phù hợp vì:

• Chạy local.
• Nhanh.
• Không cần dịch vụ cloud.
• Phù hợp kho vector vừa và lớn.
• Có nhiều loại index.
• Dễ tích hợp với Python.
• Có thể backup file index.

Đối với bệnh viện muốn giữ dữ liệu nội bộ, FAISS là lựa chọn thực tế.

4. FAISS lưu gì?

FAISS lưu vector, thường là mảng số float. Mỗi vector có một ID nội bộ hoặc vị trí trong index. Nhưng FAISS không tự hiểu tài liệu y tế, không biết quyền truy cập, không biết tên quy trình.

Vì vậy, cần lưu thêm metadata bên ngoài:

• Vector ID.
• Chunk ID.
• Nội dung chunk.
• Tên tài liệu.
• Phiên bản.
• Quyền.
• Nguồn.

5. Thiết kế mapping giữa FAISS và metadata

Một thiết kế phổ biến:

• FAISS index lưu vector.
• File/database metadata lưu danh sách chunk theo cùng thứ tự.
• Khi FAISS trả về index 123, hệ thống lấy metadata[123].

Với hệ thống lớn, nên dùng database như SQLite/PostgreSQL để lưu metadata. Với thử nghiệm nhỏ, có thể dùng JSON hoặc pickle, nhưng cần cẩn thận backup và đồng bộ.

6. Loại FAISS index

FAISS có nhiều loại index. Giai đoạn đầu có thể dùng loại đơn giản như IndexFlat để dễ kiểm tra, nhất là khi số chunk chưa quá lớn. Khi kho tài liệu lớn hơn, có thể dùng index tối ưu hơn.

Không nên tối ưu quá sớm. Bệnh viện nên bắt đầu bằng cấu hình dễ hiểu, đo chất lượng, sau đó tối ưu tốc độ nếu cần.

7. Lưu FAISS index ra file

Sau khi xây index, cần lưu ra file để dùng lại. Nếu không lưu, mỗi lần khởi động phải tạo lại từ đầu.

Cần backup:

• File FAISS index.
• Metadata store.
• Cấu hình embedding model.
• Danh sách tài liệu nguồn.
• Version của pipeline.

FAISS index và metadata phải cùng phiên bản. Nếu lệch, kết quả truy xuất sẽ sai.

8. Phân quyền không nằm trong FAISS

FAISS trả về vector gần nhất. Nhưng kết quả đó có thể thuộc tài liệu người dùng không có quyền xem. Do đó, sau khi FAISS trả kết quả, API trung gian phải lọc metadata theo quyền người dùng.

Tốt hơn nữa, có thể lọc trước bằng kho index riêng theo nhóm quyền, nhưng cách này phức tạp hơn. Giai đoạn đầu có thể dùng FAISS chung và lọc kết quả sau, miễn là không đưa chunk vượt quyền vào prompt.

9. Tình trạng hiệu lực không nằm trong FAISS

Tương tự, FAISS không biết tài liệu còn hiệu lực. Cần metadata status, effective_date, version. Khi truy xuất, hệ thống phải ưu tiên hoặc chỉ chọn tài liệu còn hiệu lực.

Nếu không lọc hiệu lực, hệ thống có thể trả lời theo quy trình cũ.

10. Kiểm tra FAISS index

Sau khi lưu vector, cần test:

• Số vector có bằng số chunk không?
• Metadata có khớp không?
• Truy vấn thử có trả đúng chunk không?
• Source hiển thị đúng không?
• Lọc quyền có hoạt động không?
• Lọc hiệu lực có hoạt động không?

Không nên chỉ kiểm tra hệ thống “không lỗi”; phải kiểm tra chất lượng truy xuất.

11. Kết luận

FAISS là công cụ mạnh để lưu và tìm kiếm vector trong hệ thống RAG local. Trong bệnh viện, FAISS nên được dùng cùng metadata store, phân quyền, lọc hiệu lực và cơ chế backup. FAISS giúp tìm tài liệu theo ý nghĩa, nhưng không tự bảo đảm câu trả lời đúng. Chất lượng RAG phụ thuộc vào việc FAISS được kết nối đúng với dữ liệu, metadata và API trung gian.