Bài 3. Kiến trúc RAG cho tài liệu bệnh viện

1. Đặt vấn đề

Xây dựng RAG cho bệnh viện không chỉ là viết vài dòng code tạo embedding và lưu vào FAISS. Một kiến trúc RAG đúng phải bao gồm dữ liệu, xử lý tài liệu, metadata, phân quyền, embedding, vector search, hybrid search, prompt, model, API trung gian, giao diện, log và cơ chế cập nhật. Nếu thiếu một trong các thành phần này, hệ thống có thể trả lời sai, lộ dữ liệu hoặc không cập nhật theo tài liệu mới.

Bệnh viện cần nhìn RAG như một hệ thống quản trị tri thức, không phải chỉ là một chức năng chatbot.

2. Kiến trúc tổng thể

Một kiến trúc RAG cơ bản cho bệnh viện có thể gồm:

1. Kho tài liệu nguồn.
2. Bộ xử lý tài liệu.
3. Bộ chia chunk.
4. Embedding model.
5. FAISS index.
6. Metadata store.
7. API trung gian.
8. Bộ truy xuất tài liệu.
9. Prompt builder.
10. Ollama chạy LLM.
11. Giao diện chatbot/website.
12. Log và feedback.
13. Cơ chế cập nhật chỉ mục.

Luồng trả lời:

Người dùng hỏi → API trung gian xác thực → tạo embedding câu hỏi → truy xuất FAISS → lọc metadata/quyền/hiệu lực → tạo prompt → gọi Ollama → trả câu trả lời kèm nguồn.

3. Kho tài liệu nguồn

Kho tài liệu nguồn có thể gồm:

• PDF.
• Word.
• Excel.
• HTML.
• Node Drupal.
• Webform.
• Văn bản pháp luật.
• SOP.
• Quy trình.
• Biểu mẫu.
• Hướng dẫn chuyên môn.
• Tài liệu đào tạo.

Kho nguồn cần được quản lý rõ. Không nên đưa mọi file lộn xộn vào RAG. Cần phân loại, kiểm tra phiên bản và xác định tài liệu nào được phép sử dụng.

4. Bộ xử lý tài liệu

Bộ xử lý tài liệu có nhiệm vụ:

• Đọc file.
• Trích xuất text.
• Loại bỏ phần thừa.
• Giữ tiêu đề.
• Nhận diện bảng nếu cần.
• Nhận diện metadata.
• Chuẩn hóa encoding.
• Lưu text sạch.

Nếu tài liệu là scan ảnh, cần OCR, nhưng OCR có thể lỗi. Tài liệu dùng cho RAG nên ưu tiên file text rõ ràng.

5. Chunking

Tài liệu dài cần chia thành các đoạn nhỏ gọi là chunk. Chunk phải đủ nhỏ để đưa vào prompt, nhưng đủ lớn để giữ ngữ cảnh.

Trong bệnh viện, chunk nên chia theo cấu trúc tài liệu:

• Mục.
• Điều.
• Khoản.
• Bước quy trình.
• Tiêu chí.
• Phần biểu mẫu.
• Nội dung hướng dẫn.

Không nên cắt tùy tiện theo số ký tự nếu làm mất ngữ cảnh.

6. Embedding model

Embedding model chuyển chunk thành vector. Cần chọn model hiểu tiếng Việt tốt, phù hợp tài liệu bệnh viện. Nếu embedding kém, FAISS tìm sai tài liệu, LLM sẽ trả lời sai.

Embedding model phải thống nhất giữa lúc lập chỉ mục và lúc truy vấn. Nếu đổi embedding model, cần tạo lại vector.

7. FAISS index

FAISS lưu vector và tìm vector gần nhất. Khi người dùng hỏi, câu hỏi được embedding thành vector, FAISS tìm các chunk có vector gần nhất.

FAISS rất mạnh và phù hợp triển khai local. Tuy nhiên, FAISS chỉ lưu vector. Metadata như tên tài liệu, phiên bản, quyền truy cập, nội dung chunk thường cần lưu riêng trong database hoặc file metadata.

8. Metadata store

Metadata là phần sống còn trong RAG bệnh viện. Mỗi chunk cần có:

• ID chunk.
• ID tài liệu.
• Tên tài liệu.
• Loại tài liệu.
• Phiên bản.
• Ngày ban hành.
• Tình trạng hiệu lực.
• Đơn vị ban hành.
• Phạm vi áp dụng.
• Quyền truy cập.
• Đường dẫn tài liệu.
• Nội dung chunk.
• Tiêu đề cha.

Nếu không có metadata, hệ thống khó hiển thị nguồn, lọc quyền và ưu tiên bản mới.

9. Bộ truy xuất

Bộ truy xuất nhận câu hỏi và trả về các chunk liên quan. Một bộ truy xuất tốt có thể kết hợp:

• Vector search bằng FAISS.
• Keyword search.
• Metadata filter.
• Reranker.
• Lọc quyền.
• Lọc hiệu lực.
• Ưu tiên tài liệu chính thức.

Trong bệnh viện, chỉ vector search thường chưa đủ.

10. Prompt builder

Prompt builder tạo prompt cuối cùng gửi cho Ollama. Prompt cần gồm:

• Vai trò AI.
• Câu hỏi người dùng.
• Các đoạn tài liệu liên quan.
• Yêu cầu chỉ trả lời dựa trên tài liệu.
• Yêu cầu nói chưa đủ căn cứ nếu nguồn không đủ.
• Yêu cầu hiển thị nguồn hoặc mã nguồn.

Prompt builder là nơi kiểm soát cách LLM sử dụng tài liệu.

11. Ollama và model sinh câu trả lời

Ollama chạy model LLM. Model đọc prompt và sinh câu trả lời. Model nên được tùy biến bằng Modelfile để phù hợp môi trường bệnh viện, ví dụ: không bịa, trả lời thận trọng, bám nguồn.

Chất lượng model vẫn quan trọng. RAG tốt nhưng model quá yếu cũng có thể tổng hợp kém.

12. API trung gian

API trung gian điều phối toàn bộ hệ thống:

• Xác thực người dùng.
• Phân quyền.
• Gọi embedding.
• Truy xuất FAISS.
• Tạo prompt.
• Gọi Ollama.
• Ghi log.
• Trả response.
• Nhận feedback.

Không nên để giao diện người dùng gọi trực tiếp FAISS hoặc Ollama.

13. Giao diện người dùng

Giao diện cần hiển thị:

• Câu trả lời.
• Nguồn.
• Cảnh báo nếu chưa đủ căn cứ.
• Nút mở tài liệu gốc.
• Nút feedback.
• Cảnh báo không nhập dữ liệu nhạy cảm.
• Lịch sử nếu được phép.

Giao diện tốt giúp người dùng hiểu AI trả lời dựa trên nguồn nào.

14. Cập nhật chỉ mục

Tài liệu bệnh viện thay đổi. Kiến trúc RAG phải có cơ chế:

• Thêm tài liệu mới.
• Cập nhật tài liệu sửa đổi.
• Loại bỏ tài liệu hết hiệu lực.
• Re-embedding chunk thay đổi.
• Cập nhật metadata.
• Kiểm tra lại chất lượng truy xuất.

Nếu chỉ mục không cập nhật, chatbot sẽ trả lời theo tài liệu cũ.

15. Kết luận

Kiến trúc RAG cho bệnh viện gồm nhiều lớp: tài liệu, xử lý, chunking, embedding, FAISS, metadata, truy xuất, prompt, Ollama, API trung gian, giao diện, log và cập nhật. Muốn RAG hoạt động tốt, bệnh viện cần thiết kế toàn bộ chuỗi này. RAG không chỉ là kỹ thuật AI, mà là kiến trúc quản lý tri thức có phân quyền, nguồn và vòng đời dữ liệu rõ ràng.