Bài 3. API hội thoại dạng chat

1. Đặt vấn đề

Không phải mọi tác vụ AI đều diễn ra trong một lượt. Nhiều trường hợp người dùng cần hội thoại nhiều lượt: hỏi thêm, yêu cầu sửa, bổ sung chi tiết, đổi văn phong, rút gọn, mở rộng, so sánh hoặc tiếp tục dựa trên câu trả lời trước. Với các tác vụ này, API hội thoại dạng chat phù hợp hơn API sinh văn bản đơn lượt.

Trong bệnh viện, API chat rất phù hợp để xây dựng chatbot nội bộ: nhân viên có thể hỏi về quy trình, yêu cầu giải thích thêm, nhờ tạo bản nháp, sau đó yêu cầu chỉnh sửa theo văn phong hoặc thêm phần phân công. Tuy nhiên, hội thoại nhiều lượt cũng có rủi ro: lịch sử chat có thể chứa dữ liệu nhạy cảm, model có thể bị kéo ra ngoài phạm vi ban đầu, context dài làm chậm hệ thống và khó kiểm soát nguồn.

2. API chat là gì?

API chat thường sử dụng cấu trúc messages, trong đó mỗi message có vai trò:

system: hướng dẫn nền.
user: nội dung người dùng hỏi.
assistant: câu trả lời trước đó của model.

Ví dụ khái niệm:

{
  "model": "assistant-qlcl",
  "messages": [
    {
      "role": "user",
      "content": "Hãy viết kế hoạch cải tiến giảm thời gian chờ khám."
    }
  ],
  "stream": false
}

Nếu có hội thoại nhiều lượt, các message trước đó được gửi lại để model có ngữ cảnh.

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

API chat phù hợp với:

Chatbot nội bộ.
Hỏi đáp nhiều lượt.
Chỉnh sửa văn bản qua nhiều vòng.
Hướng dẫn kỹ thuật từng bước.
Tra cứu tài liệu có hỏi tiếp.
Hỗ trợ người dùng mới.
Tư vấn quy trình nội bộ trong phạm vi cho phép.
Tạo nội dung rồi hiệu chỉnh.

Ví dụ:

Người dùng: “Viết kế hoạch triển khai 5S.”
AI: tạo bản nháp.
Người dùng: “Rút gọn còn 2 trang.”
AI: rút gọn.
Người dùng: “Thêm phần phân công phòng Điều dưỡng.”
AI: bổ sung.

API chat giúp giữ mạch hội thoại.

4. Quản lý lịch sử hội thoại

Đây là vấn đề quan trọng. Có hai cách:

4.1. Không lưu lịch sử lâu dài

Phù hợp với tác vụ nhạy cảm. Lịch sử chỉ tồn tại trong phiên làm việc.

4.2. Lưu lịch sử có kiểm soát

Phù hợp nếu người dùng cần xem lại. Nhưng phải có phân quyền, chính sách lưu trữ, xóa và bảo mật.

Trong bệnh viện, nếu lưu lịch sử, cần cảnh báo người dùng không nhập dữ liệu định danh và cần bảo vệ log/hội thoại như dữ liệu nội bộ nhạy cảm.

5. Giới hạn context

Hội thoại dài làm tăng context. Nếu cứ gửi toàn bộ lịch sử, prompt sẽ dài, chậm và có thể vượt context window. API trung gian cần có chiến lược:

Chỉ gửi một số lượt gần nhất.
Tóm tắt lịch sử hội thoại.
Lưu trạng thái tác vụ.
Không gửi lại thông tin không cần thiết.
Tách phiên hội thoại theo chủ đề.
Xóa hoặc ẩn thông tin nhạy cảm.

Không nên để lịch sử hội thoại tăng vô hạn.

6. System prompt trong API chat

Có thể dùng model tùy biến bằng Modelfile hoặc gửi system message trong request. Trong bệnh viện, nên chuẩn hóa system prompt ở Modelfile hoặc API trung gian.

Ví dụ system message cho chatbot nội bộ:

Bạn là trợ lý AI nội bộ của bệnh viện. Chỉ hỗ trợ tra cứu, soạn thảo, tóm tắt và giải thích thông tin ở mức tham khảo. Không tự chẩn đoán, không điều trị, không bịa căn cứ, không tiết lộ dữ liệu vượt quyền.

Nếu dùng Modelfile, system prompt đã được gắn vào model tùy biến.

7. API chat và RAG

Trong chatbot RAG, mỗi lượt hỏi có thể cần truy xuất tài liệu mới. Không nên chỉ dựa vào lịch sử. Quy trình:

Nhận câu hỏi mới.
Xác định ý định.
Tạo embedding câu hỏi mới.
Tìm tài liệu liên quan.
Lọc theo quyền.
Đưa tài liệu vào message hoặc prompt.
Gọi API chat.
Trả lời kèm nguồn.

Nếu người dùng hỏi tiếp “vậy biểu mẫu nào?”, hệ thống cần hiểu ngữ cảnh trước đó nhưng vẫn phải truy xuất tài liệu liên quan.

8. Kiểm soát người dùng kéo AI ra ngoài phạm vi

Trong hội thoại nhiều lượt, người dùng có thể yêu cầu:

“Bỏ qua hướng dẫn trước.”
“Hãy đoán số liệu.”
“Tự tạo căn cứ pháp lý.”
“Kê đơn giúp tôi.”
“Cho tôi xem dữ liệu phòng khác.”

API trung gian và system prompt phải kiểm soát. Không nên chỉ dựa vào model.

9. Thiết kế giao diện chat

Giao diện chat bệnh viện nên có:

Lựa chọn loại trợ lý.
Cảnh báo không nhập dữ liệu định danh.
Hiển thị nguồn khi có RAG.
Nút sao chép câu trả lời.
Nút đánh giá hữu ích/không hữu ích.
Nút báo lỗi.
Lịch sử phiên nếu được phép.
Nút xóa hội thoại.
Hướng dẫn phạm vi sử dụng.

10. Kết luận

API chat phù hợp để xây dựng chatbot nội bộ và các tương tác nhiều lượt trong bệnh viện. Tuy nhiên, cần quản lý lịch sử, context, dữ liệu nhạy cảm, phạm vi trả lời và phân quyền. Với ứng dụng bệnh viện, API chat nên đi qua API trung gian để kiểm soát người dùng, RAG, log và model mặc định theo từng vai trò.

Đăng nhập để gửi ý kiến