Bài 12. Thiết kế API trung gian để kiểm soát truy cập và ghi log

1. Đặt vấn đề

Trong toàn bộ kiến trúc sử dụng Ollama qua API trong bệnh viện, API trung gian là thành phần quan trọng nhất để bảo đảm an toàn. Ollama API giúp gọi model, nhưng không đủ để quản lý người dùng bệnh viện, phân quyền tài liệu, kiểm soát dữ liệu nhạy cảm, ghi log nghiệp vụ, giới hạn tốc độ, chọn model theo vai trò hoặc tích hợp RAG. Nếu bỏ qua API trung gian, hệ thống AI local có thể chạy được nhưng khó kiểm soát.

API trung gian là lớp điều phối giữa người dùng, ứng dụng, dữ liệu bệnh viện, RAG và Ollama. Đây là nơi biến AI local từ một service kỹ thuật thành một dịch vụ có quản trị.

2. Vai trò của API trung gian

API trung gian thực hiện:

• Xác thực người dùng.
• Phân quyền.
• Chọn model.
• Kiểm tra request.
• Chặn dữ liệu nhạy cảm nếu cần.
• Gọi embedding.
• Truy xuất FAISS.
• Lọc tài liệu theo quyền.
• Tạo prompt.
• Gọi Ollama.
• Streaming response nếu cần.
• Ghi log.
• Thu feedback.
• Rate limit.
• Xử lý lỗi.
• Theo dõi hiệu năng.

3. Kiến trúc tổng quát

Người dùng
  ↓
Website / Drupal / QMS / Chatbot
  ↓
API trung gian
  ↓
RAG / FAISS / Metadata / Permission
  ↓
Ollama API
  ↓
Model AI local

API trung gian có thể viết bằng Python, PHP, Node.js hoặc ngôn ngữ phù hợp. Nếu làm RAG/FAISS nhiều, Python thường thuận lợi.

4. Xác thực người dùng

API trung gian cần biết ai đang gọi. Có thể dùng:

• Session từ website nội bộ.
• Token API.
• JWT.
• OAuth/OpenID nếu có.
• Tích hợp LDAP/SSO nếu bệnh viện có.
• API key cho service nội bộ.

Không nên cho endpoint AI chạy công khai không xác thực.

5. Phân quyền

Sau khi xác thực, cần xác định quyền:

• Người dùng thuộc phòng ban nào?
• Vai trò gì?
• Được dùng trợ lý nào?
• Được truy xuất kho tài liệu nào?
• Được dùng tác vụ nào?
• Có được upload file không?
• Có được xem lịch sử không?

Phân quyền phải áp dụng trước khi truy xuất tài liệu và trước khi gọi model.

6. Chọn model theo tác vụ

API trung gian không nên để người dùng tự chọn model tùy tiện. Nên ánh xạ:

Điều này giúp hệ thống ổn định và dễ kiểm soát.

7. Kiểm soát đầu vào

API trung gian nên kiểm tra:

• Prompt quá dài.
• File quá lớn.
• Dữ liệu định danh người bệnh.
• Yêu cầu chẩn đoán/điều trị.
• Yêu cầu bịa số liệu.
• Yêu cầu vượt quyền.
• Nội dung độc hại hoặc không phù hợp.
• Tác vụ không được phép.

Tùy mức độ, API có thể chặn, cảnh báo hoặc yêu cầu xác nhận.

8. RAG và lọc quyền

Nếu dùng RAG:

1. Tạo embedding cho câu hỏi.
2. Tìm chunk liên quan.
3. Lọc theo quyền người dùng.
4. Lọc theo tình trạng hiệu lực.
5. Chọn top-k.
6. Tạo prompt.
7. Gọi Ollama.

Không được đưa tài liệu vượt quyền vào prompt rồi yêu cầu model không tiết lộ. Phải lọc trước.

9. Ghi log

Log nên gồm:

• User ID.
• Phòng ban.
• Thời gian.
• Tác vụ.
• Model.
• Endpoint.
• Thời gian phản hồi.
• Trạng thái thành công/lỗi.
• Tài liệu được truy xuất.
• Feedback.
• Token hoặc độ dài prompt nếu có.

Có ghi toàn bộ prompt/response hay không cần chính sách riêng. Nếu ghi, phải bảo vệ log.

10. Rate limit và quota

Cần giới hạn:

• Số request/phút.
• Độ dài prompt.
• Độ dài response.
• Số file upload.
• Số tác vụ dài đồng thời.
• Quyền dùng model lớn.
• Quyền dùng RAG kho nhạy cảm.

Rate limit giúp tránh quá tải GPU và lạm dụng hệ thống.

11. Xử lý lỗi

API trung gian cần trả lỗi rõ:

• Model chưa sẵn sàng.
• Ollama không phản hồi.
• Hệ thống bận.
• Không có quyền.
• Không tìm thấy tài liệu.
• Prompt quá dài.
• File không hỗ trợ.
• Timeout.
• Dữ liệu đầu vào không phù hợp.

Không nên trả lỗi kỹ thuật thô cho người dùng cuối.

12. Monitoring

Cần theo dõi:

• Số request.
• Thời gian phản hồi.
• Tỷ lệ lỗi.
• Tải GPU/RAM/CPU.
• Model được dùng nhiều.
• Tác vụ phổ biến.
• Người dùng sử dụng nhiều.
• Câu hỏi không tìm thấy nguồn.
• Feedback xấu.
• Lỗi bảo mật.

Monitoring giúp cải tiến hệ thống.

13. Bảo vệ endpoint Ollama

Ollama nên chỉ listen localhost hoặc chỉ cho API trung gian truy cập. Firewall nên chặn truy cập trực tiếp từ client. Nếu nhiều máy chủ, chỉ IP của API trung gian được gọi Ollama.

Đây là nguyên tắc quan trọng.

14. Kết luận

API trung gian là lớp bắt buộc nếu bệnh viện muốn dùng Ollama qua API một cách an toàn và có khả năng mở rộng. Nó kiểm soát xác thực, phân quyền, model, dữ liệu, RAG, log, tốc độ, lỗi và monitoring. Ollama chỉ nên là model serving backend; mọi logic nghiệp vụ bệnh viện phải đi qua API trung gian. Khi thiết kế tốt lớp này, bệnh viện có thể tích hợp AI local vào Drupal, website nội bộ, QMS và các hệ thống khác mà vẫn giữ được kiểm soát cần thiết.