Bài 8. So sánh kết quả giữa nhiều model

1. Đặt vấn đề

Trong AI local, không nên chọn model chỉ bằng cảm tính. Cùng một máy chủ có thể chạy nhiều model khác nhau, mỗi model có điểm mạnh và điểm yếu riêng. Một model có thể viết văn bản hành chính tốt nhưng RAG kém. Một model có thể trả lời nhanh nhưng nội dung nông. Một model có thể phân tích tốt nhưng dùng nhiều VRAM. Một model có thể tiếng Anh mạnh nhưng tiếng Việt hành chính chưa phù hợp.

Vì vậy, bệnh viện cần có phương pháp so sánh kết quả giữa nhiều model. Đây là bước quan trọng trước khi chọn model chính thức cho chatbot, RAG, quản lý chất lượng hoặc soạn thảo văn bản.

2. Không so sánh bằng vài câu hỏi ngẫu nhiên

Sai lầm thường gặp là hỏi mỗi model vài câu khác nhau rồi kết luận. Cách này không công bằng và không đủ tin cậy. Cần dùng cùng một bộ câu hỏi, cùng điều kiện, cùng tiêu chí đánh giá.

Ví dụ, nếu model A được hỏi câu dễ, model B được hỏi câu khó, kết quả không có giá trị so sánh. Nếu model A được prompt kỹ hơn model B, kết quả cũng không công bằng.

3. Xây bộ prompt chuẩn

Bệnh viện nên xây bộ prompt chuẩn gồm nhiều nhóm:

3.1. Hỏi đáp nội bộ

• Quy trình báo cáo sự cố gồm những bước nào?
• Biểu mẫu nào dùng khi người bệnh té ngã?
• Khi nhân viên cần cấp tài khoản phần mềm, quy trình thế nào?

3.2. Soạn thảo văn bản

• Viết kế hoạch cải tiến giảm thời gian chờ khám.
• Viết thông báo triển khai khảo sát hài lòng.
• Viết báo cáo sơ kết công tác quản lý chất lượng.

3.3. Tóm tắt

• Tóm tắt một quy trình.
• Tóm tắt biên bản họp.
• Tóm tắt văn bản pháp luật.

3.4. Bảng kiểm

• Tạo bảng kiểm 5S.
• Tạo bảng kiểm an toàn người bệnh.
• Tạo bảng kiểm giám sát quy trình kỹ thuật.

3.5. Phân tích

• Phân tích nguyên nhân thời gian chờ dài.
• Gợi ý giải pháp cải tiến.
• Phân loại phản ánh người bệnh.

3.6. Câu hỏi an toàn

• Câu hỏi yêu cầu chẩn đoán.
• Câu hỏi thiếu dữ liệu.
• Câu hỏi yêu cầu bịa căn cứ pháp lý.

4. Tiêu chí đánh giá

Có thể chấm theo các tiêu chí:

• Đúng nội dung.
• Đầy đủ.
• Không bịa.
• Văn phong phù hợp.
• Cấu trúc rõ.
• Cụ thể, không chung chung.
• Bám nguồn nếu có RAG.
• Biết nói không đủ căn cứ.
• Tốc độ.
• Mức sử dụng VRAM/RAM.
• Phù hợp với tác vụ bệnh viện.

Không nên chỉ chấm “hay” hoặc “dở”.

5. So sánh định tính và định lượng

So sánh định lượng bằng điểm giúp tổng hợp. So sánh định tính giúp hiểu vì sao model tốt hoặc kém.

Ví dụ:

Nhưng cần ghi nhận: Model B tốt hơn nhưng chậm hơn. Nếu dùng cho văn bản dài, chấp nhận; nếu dùng cho chatbot nhanh, Model A có thể phù hợp hơn.

6. So sánh cùng temperature và tham số

Khi so sánh, nên dùng cùng cấu hình:

• Temperature.
• Top_p.
• Context length.
• Prompt.
• Dữ liệu RAG.
• Độ dài yêu cầu.
• Điều kiện máy chủ.

Nếu tham số khác nhau, kết quả có thể lệch.

7. So sánh trên RAG

Nếu model dùng cho RAG, cần so sánh trong pipeline RAG thật. Model có thể chat tốt nhưng khi nhận nhiều chunk tài liệu lại không bám nguồn tốt. Cần test:

• Có dùng đúng tài liệu không?
• Có trích nguồn không?
• Có bịa ngoài nguồn không?
• Có biết nói thiếu căn cứ không?
• Có tổng hợp đúng nhiều đoạn không?

8. So sánh tốc độ

Chất lượng và tốc độ phải đi cùng. Ghi nhận:

• Thời gian phản hồi.
• Token/giây nếu đo được.
• VRAM.
• RAM.
• GPU temperature.
• Tốc độ cold start và warm run.

Một model tốt hơn 10% nhưng chậm gấp 3 lần có thể không phù hợp cho chatbot thường xuyên.

9. Mời người dùng chuyên môn đánh giá

Phòng CNTT không nên tự đánh giá toàn bộ nội dung. Cần mời:

• Phòng Quản lý chất lượng đánh giá nội dung QLCL.
• Phòng Điều dưỡng đánh giá bảng kiểm điều dưỡng.
• Phòng Kế hoạch tổng hợp đánh giá văn bản quản trị.
• Bác sĩ chuyên môn đánh giá tài liệu y tế.
• Phòng CNTT đánh giá tác vụ kỹ thuật.

Model dùng cho ai thì người dùng đó phải tham gia đánh giá.

10. Lưu kết quả so sánh

Cần lưu:

• Prompt.
• Câu trả lời từng model.
• Điểm chấm.
• Nhận xét.
• Thời gian phản hồi.
• Tài nguyên.
• Ngày test.
• Phiên bản model.

Sau này khi cập nhật model, có cơ sở so sánh.

11. Kết luận

So sánh kết quả giữa nhiều model là bước quan trọng để chọn model phù hợp cho bệnh viện. Cần dùng bộ prompt chuẩn, tiêu chí rõ, điều kiện giống nhau, đánh giá cả chất lượng lẫn tốc độ, kiểm tra RAG và mời người dùng chuyên môn tham gia. Model tốt nhất không phải lúc nào cũng là model điểm cao nhất tổng thể, mà là model phù hợp nhất với từng nhóm tác vụ và phần cứng hiện có.