Website được thiết kế tối ưu cho thành viên chính thức. Hãy Đăng nhập hoặc Đăng ký để truy cập đầy đủ nội dung và chức năng. Nội dung bạn cần không thấy trên website, có thể do bạn chưa đăng nhập. Nếu là thành viên của website, bạn cũng có thể yêu cầu trong nhóm Zalo "HI.AI Members" các nội dung bạn quan tâm.

Bài 5. API tạo embedding

1. Đặt vấn đề

Nếu bệnh viện chỉ dùng AI để sinh văn bản, API generate hoặc chat có thể đủ. Nhưng nếu muốn xây dựng hệ thống RAG, hỏi đáp tài liệu nội bộ, tìm kiếm ngữ nghĩa hoặc FAISS, cần tạo embedding. Embedding là vector biểu diễn ý nghĩa của văn bản. Ollama có thể hỗ trợ gọi model embedding qua API để chuyển văn bản thành vector.

API tạo embedding là nền tảng cho các ứng dụng như: hỏi đáp quy trình, tra cứu biểu mẫu, tìm văn bản pháp luật, tìm tiêu chí chất lượng, phân nhóm phản ánh người bệnh, phát hiện tài liệu trùng lặp và xây dựng kho tri thức nội bộ.

2. Embedding API là gì?

Embedding API nhận văn bản đầu vào và trả về vector số. Vector này có thể lưu vào FAISS hoặc vector database. Khi người dùng hỏi, câu hỏi cũng được chuyển thành vector. Hệ thống so sánh vector câu hỏi với vector tài liệu để tìm nội dung liên quan.

Ví dụ khái niệm request:

 
{
"model": "embedding-model",
"input": "Quy trình báo cáo sự cố té ngã người bệnh"
}
 

Response sẽ chứa vector embedding.

3. Khi nào dùng embedding API?

Dùng khi cần:

  • Xây dựng RAG.
  • Tìm kiếm ngữ nghĩa.
  • Lập chỉ mục tài liệu.
  • Tìm tài liệu tương tự.
  • Phân nhóm phản ánh.
  • Tìm biểu mẫu theo nội dung hỏi.
  • Tìm tiêu chí liên quan.
  • So sánh văn bản.
  • Phát hiện nội dung gần trùng.

Embedding API thường không hiển thị trực tiếp cho người dùng. Nó chạy ở backend.

4. Quy trình tạo embedding cho tài liệu bệnh viện

Một quy trình cơ bản:

  1. Thu thập tài liệu.
  2. Chuyển tài liệu thành text.
  3. Làm sạch text.
  4. Chia tài liệu thành chunk.
  5. Gửi từng chunk đến embedding API.
  6. Nhận vector.
  7. Lưu vector vào FAISS.
  8. Lưu metadata của chunk.
  9. Khi người dùng hỏi, tạo embedding cho câu hỏi.
  10. Tìm chunk liên quan trong FAISS.
  11. Đưa chunk vào prompt cho LLM.

5. Chọn model embedding

Không nên dùng LLM sinh văn bản làm embedding nếu nó không được thiết kế cho embedding. Cần chọn model embedding phù hợp:

  • Hỗ trợ tiếng Việt tốt.
  • Tốc độ ổn.
  • Vector chất lượng.
  • Dễ tích hợp.
  • Phù hợp kích thước kho tài liệu.
  • Giấy phép phù hợp.

Cần đánh giá bằng bộ câu hỏi truy xuất tài liệu bệnh viện.

6. Chunking trước khi embedding

Tài liệu bệnh viện thường dài. Không nên tạo embedding cho toàn bộ file dài trong một vector duy nhất. Cần chia chunk theo cấu trúc:

  • Mục.
  • Điều.
  • Khoản.
  • Bước quy trình.
  • Phần biểu mẫu.
  • Tiêu chí.
  • Đoạn có ý nghĩa hoàn chỉnh.

Chunk nên có tiêu đề đi kèm để giữ ngữ cảnh. Ví dụ, chunk về “Bước 3: Báo cáo sự cố” nên lưu cả tên quy trình.

7. Metadata đi kèm embedding

Mỗi vector cần metadata:

  • ID chunk.
  • Tên tài liệu.
  • Loại tài liệu.
  • Mã tài liệu.
  • Phiên bản.
  • Ngày ban hành.
  • Tình trạng hiệu lực.
  • Phòng ban sở hữu.
  • Quyền truy cập.
  • Đường dẫn file gốc.
  • Nội dung chunk.

FAISS lưu vector; metadata cần lưu ở database hoặc file đi kèm.

8. Embedding câu hỏi người dùng

Khi người dùng hỏi, API trung gian tạo embedding cho câu hỏi. Cần lưu ý:

  • Câu hỏi nên được làm sạch.
  • Có thể thêm ngữ cảnh tác vụ.
  • Không nên đưa dữ liệu định danh nếu không cần.
  • Cần dùng cùng embedding model với tài liệu đã lập chỉ mục.

Nếu đổi embedding model, thường phải tạo lại toàn bộ chỉ mục.

9. Bảo mật embedding

Vector embedding không phải lúc nào cũng vô hại. Vector đi kèm metadata và chunk text có thể phản ánh nội dung nhạy cảm. Cần bảo vệ:

  • File chunk.
  • Vector index.
  • Metadata.
  • Log truy xuất.
  • Backup FAISS.

Không nên cho người dùng truy cập trực tiếp kho vector.

10. Kết luận

API tạo embedding là nền tảng của RAG và tìm kiếm ngữ nghĩa trong hệ thống AI local bệnh viện. Nó giúp biến tài liệu thành vector để FAISS tìm kiếm theo ý nghĩa. Muốn embedding hiệu quả, bệnh viện cần chọn model phù hợp tiếng Việt, chunking đúng, metadata đầy đủ, phân quyền chặt chẽ và đánh giá bằng câu hỏi thực tế. Embedding không phải chức năng phụ, mà là thành phần quyết định chất lượng hỏi đáp tài liệu nội bộ.