Chọn mô hình AI cho AI Agent dựa trên tiêu chí nào?

Khi bắt đầu một dự án AI Agent, câu hỏi “dùng mô hình nào” thường được đặt ra rất sớm, đôi khi trước cả khi biết agent sẽ làm việc gì. Kết quả là doanh nghiệp chọn theo danh tiếng hoặc bảng xếp hạng chung, rồi mới phát hiện mô hình đó chậm với kênh chat, tốn kém khi lượng tin nhắn lớn, hoặc lúng túng với cách khách viết tiếng Việt không dấu.

Mô hình ngôn ngữ chỉ là một phần của agent, nhưng chọn sai thì các phần còn lại khó bù. Bài viết đưa ra tám tiêu chí để so các mô hình trên chính bài toán của doanh nghiệp, cách dựng một bộ đánh giá nhỏ để quyết định bằng số liệu, và cách thiết kế để sau này đổi mô hình không phải làm lại.

1. Bản chất của việc chọn mô hình AI

Trong một AI Agent, mô hình làm ba việc: hiểu câu người dùng viết, quyết định cần tra cứu hay gọi công cụ nào, và soạn câu trả lời từ dữ liệu nhận về. Mỗi việc đòi hỏi năng lực khác nhau. Phân loại tin nhắn vào vài nhóm cố định là việc mô hình nhỏ làm tốt; suy luận qua nhiều bước với nhiều công cụ thì cần mô hình mạnh hơn. Vì vậy không nhất thiết cả agent chỉ dùng một mô hình.

Áp vào ba mức việc: phần hỏi đáp cần mô hình bám sát tài liệu và biết từ chối khi thiếu thông tin. Phần tra cứu cần mô hình gọi công cụ đúng tham số, vì một mã đơn sai là cả câu trả lời sai. Phần ghi cần mô hình ổn định nhất về định dạng đầu ra, nhưng quan trọng hơn là lớp kiểm tra phía sau, vì không mô hình nào đúng tuyệt đối.

2. Tám tiêu chí so sánh mô hình

1. Độ chính xác

Độ chính xác phải đo trên việc của doanh nghiệp, không dựa vào điểm benchmark công khai. Dựng một bộ câu hỏi thật có đáp án do người nghiệp vụ duyệt, chia theo loại việc: trả lời theo tài liệu, trích xuất trường dữ liệu, chọn công cụ. Một mô hình đứng cao trên bảng xếp hạng chung vẫn có thể kém ở đúng loại việc doanh nghiệp cần.

2. Độ trễ

Độ trễ là thời gian từ lúc người dùng gửi đến lúc nhận trả lời, gồm cả thời gian tra cứu và gọi công cụ. Kênh chat với khách cần phản hồi nhanh; việc chạy nền như tóm tắt email cuối ngày chấp nhận chậm hơn. Nên đo ở giờ cao điểm và với câu hỏi dài, không chỉ với vài câu mẫu ngắn.

3. Chi phí

Chi phí mô hình thường tính theo lượng chữ đưa vào và sinh ra, nên phụ thuộc nhiều vào thiết kế: prompt dài, gửi kèm cả lịch sử hội thoại hay gọi mô hình nhiều lần trong một lượt đều đẩy chi phí lên. Hãy ước tính theo lưu lượng thật và cách agent được thiết kế, không so đơn giá niêm yết. Cách tính tổng chi phí dự án xem ở bài chi phí triển khai AI Agent.

4. Khả năng tiếng Việt

Thử với tiếng Việt như khách thật viết: không dấu, viết tắt, lẫn tiếng Anh, sai chính tả, gọi sản phẩm theo cách địa phương. Xem cả chiều ngược lại: câu trả lời có tự nhiên, đúng xưng hô, đúng thuật ngữ ngành không. Có mô hình hiểu tốt nhưng viết tiếng Việt cứng hoặc chen từ tiếng Anh, và điều này ảnh hưởng trực tiếp tới trải nghiệm khách.

5. Cửa sổ ngữ cảnh

Cửa sổ ngữ cảnh là lượng nội dung mô hình xem được trong một lần xử lý. Cửa sổ lớn cho phép đưa tài liệu dài hoặc hội thoại dài, nhưng không thay được truy xuất tốt: nhồi quá nhiều nội dung làm chi phí tăng và mô hình dễ bỏ sót chi tiết ở giữa. Nên đo độ dài thật của tài liệu và hội thoại trong quy trình trước khi coi đây là tiêu chí quyết định.

6. Công cụ hỗ trợ

Agent cần mô hình gọi công cụ ổn định: chọn đúng công cụ, điền đúng tham số, trả kết quả theo cấu trúc định sẵn. Hãy thử các ca khó như thiếu tham số, hai công cụ có chức năng gần giống nhau, hay người dùng đổi ý giữa chừng. Mô hình hay tự điền tham số khi thiếu thông tin là rủi ro lớn với thao tác ghi.

7. Bảo mật

Cần xem dữ liệu gửi cho mô hình được xử lý và lưu ở đâu, có bị dùng để huấn luyện không, có lựa chọn vùng lưu trữ hay triển khai riêng không. Những điều này nằm trong điều khoản dịch vụ của nhà cung cấp mô hình và phải đọc bản hiện hành, không dựa vào hiểu biết cũ. Với dữ liệu nhạy cảm, nên che hoặc lược bớt trước khi gửi, dù dùng mô hình nào.

8. Khả năng thay thế

Mô hình thay đổi rất nhanh: phiên bản mới ra, phiên bản cũ ngừng hỗ trợ, giá điều chỉnh. Agent nên gọi mô hình qua một lớp trung gian để việc đổi mô hình chủ yếu là đổi cấu hình, kèm bộ đánh giá để chạy lại trước khi chuyển. Nếu prompt và định dạng đầu ra gắn chặt vào đặc điểm riêng của một mô hình, lần đổi sau sẽ tốn công hơn nhiều.

3. Quy trình chọn mô hình thực tế

Bước 1: Xác định phạm vi và kết quả cần đo

Chia agent thành các việc con: phân loại, trích xuất, trả lời theo tài liệu, gọi công cụ, soạn câu trả lời. Với mỗi việc, ghi yêu cầu về độ chính xác, độ trễ và mức chi phí chấp nhận được. Đầu ra là bảng yêu cầu theo từng việc, làm căn cứ nếu cần chọn mô hình khác nhau cho từng phần.

Bước 2: Chuẩn hóa dữ liệu cùng quyền truy cập

Dựng bộ đánh giá từ dữ liệu thật đã che thông tin: câu hỏi của khách, email, tài liệu, kèm đáp án mong đợi do người nghiệp vụ xác nhận. Quyết định trước dữ liệu nào được phép gửi cho từng nhà cung cấp mô hình trong lúc thử. Bộ đánh giá này được giữ lại và dùng cho mọi lần đổi mô hình về sau.

Bước 3: Thiết kế tích hợp ngoại lệ và phê duyệt

Thiết kế cách định tuyến: việc đơn giản đi mô hình nhỏ; việc phức tạp, hoặc khi mô hình nhỏ không chắc chắn, thì chuyển mô hình mạnh hơn hoặc chuyển người. Xác định cả phương án khi dịch vụ mô hình chính lỗi: có mô hình dự phòng hay tạm dừng. Người phụ trách kỹ thuật duyệt thiết kế, người nghiệp vụ duyệt các ngưỡng chuyển người.

Bước 4: Kiểm thử vận hành rồi cải thiện theo log

Chạy các mô hình ứng viên trên cùng bộ đánh giá, chấm theo từng tiêu chí và từng loại việc. Sau khi chọn, tiếp tục ghi lại những câu sai trong vận hành thật và bổ sung vào bộ đánh giá. Khi nhà cung cấp ra phiên bản mới, chạy lại toàn bộ trước khi quyết định nâng cấp.

4. Ví dụ giả định

Doanh nghiệp dùng mô hình nhỏ cho phân loại và mô hình mạnh hơn cho trường hợp phức tạp, dựa trên bộ đánh giá thay vì cảm nhận.

Bài học từ ví dụ này nằm ở điểm chuyển giữa hai mô hình. Ca thử cần gồm những tin nhắn sát ranh giới: câu hỏi đơn giản nhưng viết mơ hồ, lời khiếu nại lẫn trong câu hỏi giá, một tin nhắn chứa hai yêu cầu. Với từng ca, ghi mô hình nhỏ phân loại thế nào, có chuyển đúng sang mô hình mạnh không, và kết quả cuối có đúng không. Nếu nhiều ca bị giữ sai ở mô hình nhỏ, nên sửa ngưỡng hoặc danh sách nhãn trước khi nghĩ tới đổi mô hình.

5. Rủi ro và giới hạn

• Không tự động hóa khi dữ liệu hoặc thẩm quyền chưa rõ
• Giới hạn quyền đọc ghi theo nhu cầu tối thiểu
• Giữ người phụ trách cho ngoại lệ và quyết định quan trọng
• Theo dõi log và kiểm thử lại sau mỗi thay đổi

Rủi ro phổ biến là tin rằng mô hình mạnh hơn sẽ tự sửa được lỗi dữ liệu hay lỗi thiết kế. Nếu tài liệu cũ hoặc công cụ trả dữ liệu sai, mô hình nào cũng trả lời sai, chỉ là trôi chảy hơn; các kỹ thuật chặn điều này có ở bài giảm hallucination khi AI Agent trả lời khách. Rủi ro thứ hai là phiên bản mô hình thay đổi phía nhà cung cấp làm kết quả khác đi mà không ai để ý; cần cố định phiên bản khi có thể và chạy bộ đánh giá định kỳ. Quyền truy cập dữ liệu và bước duyệt phải nằm ở lớp hệ thống, không phụ thuộc vào việc mô hình tuân theo prompt.

6. Phân chia trách nhiệm vận hành

Đội kỹ thuật dựng bộ đánh giá, chạy so sánh, theo dõi độ trễ, chi phí và các thông báo thay đổi phiên bản từ nhà cung cấp mô hình. Người sở hữu nghiệp vụ xác nhận đáp án đúng trong bộ đánh giá và chấm những câu cần hiểu nghiệp vụ, như giọng văn với khách hay cách diễn giải chính sách. Bộ phận an toàn thông tin hoặc pháp chế rà điều khoản xử lý dữ liệu của nhà cung cấp mô hình.

Quyết định đổi mô hình nên đi qua quy trình như mọi thay đổi khác: lý do đổi, kết quả bộ đánh giá so với mô hình cũ, người duyệt và thời điểm áp dụng. Nên giữ khả năng quay lại mô hình cũ một thời gian sau khi đổi, phòng khi vận hành thật lộ ra vấn đề mà bộ đánh giá chưa bắt được.

7. Chỉ số nên theo dõi

• Tỷ lệ hoàn thành đúng theo tiêu chí đã duyệt
• Tỷ lệ từ chối đúng và chuyển người phụ trách
• Lỗi tích hợp, độ trễ và số thao tác phải sửa
• Chi phí cùng tác động kinh doanh của quy trình

Khi so mô hình, nên nhìn chi phí trên mỗi yêu cầu hoàn thành đúng thay vì chi phí trên mỗi lượt gọi, vì một mô hình rẻ nhưng hay sai sẽ đẩy thêm việc cho nhân viên. Tách chỉ số theo loại việc để thấy mô hình yếu ở đâu: có khi nó tốt khi trả lời theo tài liệu nhưng kém khi gọi công cụ, và cách xử lý là định tuyến lại chứ không phải đổi hẳn.

8. Checklist trước khi vận hành

• Nguồn dữ liệu và chủ sở hữu đã xác nhận
• Quyền đọc ghi đã thử với nhiều vai trò
• Có phương án khi hệ thống lỗi hoặc thiếu dữ liệu
• Có log, phê duyệt và cơ chế chống thao tác trùng
• Có bộ kiểm thử hồi quy và người vận hành

9. Câu hỏi thường gặp

Có nên chọn mô hình AI ngay từ đầu dự án không? Có thể chọn một mô hình tạm để dựng bản thử, nhưng quyết định chính thức nên đợi đến khi có bộ đánh giá từ dữ liệu thật. Agent cũng nên được thiết kế sao cho đổi mô hình không phải viết lại toàn bộ.

Nên bắt đầu chọn mô hình AI từ đâu? Bắt đầu bằng việc chia agent thành các việc con và dựng một bộ đánh giá nhỏ cho từng việc. Chạy vài mô hình ứng viên trên cùng bộ đó cho kết quả đáng tin hơn nhiều so với đọc bảng xếp hạng chung.

Khi nào việc đổi mô hình AI cần người duyệt? Khi đổi mô hình cho phần trả lời khách, phần gọi công cụ ghi dữ liệu, hoặc khi đổi sang nhà cung cấp mô hình khác. Người nghiệp vụ duyệt kết quả bộ đánh giá, bộ phận an toàn thông tin duyệt điều khoản xử lý dữ liệu mới.

Có nên dùng nhiều mô hình trong một AI Agent không? Nên cân nhắc khi các việc con khác nhau rõ về độ khó và lưu lượng, ví dụ phân loại tin nhắn và xử lý yêu cầu phức tạp. Đổi lại, hệ thống phức tạp hơn và phải kiểm thử cả điểm chuyển giữa các mô hình.

Kết luận

Chọn mô hình AI cho agent là quyết định dựa trên bộ đánh giá, không dựa trên danh tiếng. Tám tiêu chí cần được đo bằng chính dữ liệu và cách viết của khách hàng doanh nghiệp, còn kiến trúc phải để ngỏ khả năng đổi mô hình khi có lựa chọn phù hợp hơn.

Trao đổi với Naventic để dựng bộ đánh giá và chọn mô hình theo đúng bài toán. Đọc thêm: Dịch vụ.