Model drift là gì và khi nào cần đánh giá lại AI Agent?

Một AI Agent vượt qua nghiệm thu với kết quả tốt, chạy ổn vài tháng, rồi dần dần có phản ánh: câu trả lời dài dòng hơn, hay từ chối những câu trước đây vẫn trả lời được, đôi khi dẫn sai chính sách mới ban hành. Không ai sửa gì trong hệ thống, nhưng chất lượng đã trượt. Hiện tượng này thường được gọi là model drift, hay trôi mô hình.

Với mô hình học máy truyền thống, drift chủ yếu là dữ liệu đầu vào khác dần dữ liệu huấn luyện. Với AI Agent dùng mô hình ngôn ngữ lớn (LLM), nguồn gây trôi rộng hơn: người dùng hỏi kiểu mới, tài liệu nguồn thay đổi, và nhà cung cấp mô hình có thể cập nhật phiên bản. Bài viết giải thích từng nguồn trôi, cách lập mốc so sánh, tín hiệu cảnh báo, ngưỡng để quyết định đánh giá lại, và cách ghim phiên bản để có đường lui.

1. Model drift trong AI Agent dùng LLM

Hầu hết doanh nghiệp không tự huấn luyện mô hình mà gọi mô hình của nhà cung cấp qua API, kết hợp kho kiến thức và công cụ nghiệp vụ. Vì vậy “mô hình” trong bài này là cả cụm: mô hình ngôn ngữ, prompt hướng dẫn, kho kiến thức, cách truy xuất tài liệu và các công cụ được gọi. Chỉ cần một thành phần đổi, hành vi của agent có thể đổi theo.

Có ba nguồn trôi chính. Thứ nhất là người dùng: sản phẩm mới ra mắt, mùa vụ đổi, khách bắt đầu hỏi những câu chưa có trong bộ kiểm thử lúc nghiệm thu. Thứ hai là dữ liệu: tài liệu được sửa, bảng giá cập nhật, chính sách cũ hết hiệu lực nhưng vẫn nằm trong kho. Thứ ba là chính mô hình: nhà cung cấp phát hành phiên bản mới, ngừng phiên bản cũ, hoặc cập nhật một bí danh mô hình trỏ sang bản khác. Nguồn thứ ba đặc biệt dễ bị bỏ qua vì phía doanh nghiệp không thay đổi dòng mã nào.

Drift khác với lỗi. Lỗi thường xuất hiện đột ngột và có nguyên nhân rõ, như API hết hạn hay tài liệu bị xóa. Drift diễn ra từ từ, từng câu trả lời riêng lẻ vẫn có vẻ chấp nhận được, chỉ khi so với mốc cũ mới thấy chất lượng đã khác.

2. Các yếu tố cần thiết kế để phát hiện drift

1. Thay đổi dữ liệu

Kho kiến thức cần ghi ngày cập nhật và người sở hữu cho từng tài liệu, để khi chất lượng trượt có thể đối chiếu với những thay đổi gần đây. Những dấu hiệu cần theo dõi: tỷ lệ câu hỏi không tìm được tài liệu phù hợp tăng lên, tài liệu hết hiệu lực vẫn được trích dẫn, nhiều phiên bản của cùng một chính sách cùng tồn tại. Việc quản lý phiên bản tài liệu đã có bài riêng về phiên bản kho kiến thức AI; với drift, điều quan trọng là mỗi thay đổi kho kiến thức đều để lại dấu vết thời gian.

2. Thay đổi hành vi người dùng

Hãy phân loại câu hỏi theo chủ đề và theo dõi tỷ trọng từng chủ đề theo tuần. Khi một chủ đề mới xuất hiện hoặc một chủ đề nhỏ bỗng tăng mạnh, rất có thể agent đang gặp những câu mà nó chưa được chuẩn bị. Các dấu hiệu khác: câu hỏi dài hơn, nhiều ngôn ngữ trộn lẫn hơn, người dùng phải hỏi lại nhiều lần trong một phiên.

3. Baseline

Không có mốc thì không đo được trôi. Baseline là bộ kết quả được ghi lại tại thời điểm agent được nghiệm thu: điểm chất lượng trên bộ câu hỏi chuẩn, tỷ lệ từ chối, tỷ lệ chuyển người, độ dài câu trả lời trung bình, độ trễ và chi phí mỗi lượt. Baseline phải ghi kèm cấu hình tạo ra nó, gồm phiên bản mô hình, phiên bản prompt và ảnh chụp kho kiến thức, để sau này so sánh cùng điều kiện.

4. Bộ test

Bộ câu hỏi dùng để đo drift nên gồm ba phần. Phần cố định là các câu hỏi đại diện cho nghiệp vụ cốt lõi, không đổi theo thời gian, dùng để so sánh dài hạn. Phần cập nhật được bổ sung định kỳ từ câu hỏi thật mới xuất hiện. Phần bẫy gồm những câu agent phải từ chối hoặc chuyển người. Tiêu chí chấm từng câu nên dùng lại khung đã thống nhất lúc nghiệm thu, chi tiết ở bài scorecard đánh giá AI Agent.

5. Cảnh báo

Cảnh báo nên dựa trên xu hướng chứ không dựa trên từng câu trả lời. Một số tín hiệu đáng đặt ngưỡng: điểm trung bình trên bộ test cố định giảm so với baseline, tỷ lệ phản hồi tiêu cực tăng nhiều tuần liền, tỷ lệ từ chối hoặc chuyển người thay đổi rõ rệt, độ dài câu trả lời lệch nhiều so với mốc, và chi phí mỗi lượt tăng mà lưu lượng không đổi. Mỗi cảnh báo cần có người nhận và hướng xử lý ban đầu, nếu không sẽ chỉ là thêm một biểu đồ không ai xem.

6. Phiên bản mô hình

Nếu API cho phép, hãy gọi mô hình bằng mã phiên bản cụ thể thay vì bí danh luôn trỏ tới bản mới nhất. Ghim phiên bản giúp hành vi agent chỉ thay đổi khi doanh nghiệp chủ động đổi. Cần theo dõi lịch ngừng hỗ trợ phiên bản của nhà cung cấp để có thời gian kiểm thử bản thay thế, thay vì bị buộc chuyển vào phút chót. Các tiêu chí khi chọn mô hình thay thế được bàn ở bài chọn mô hình AI cho AI Agent.

7. Đánh giá lại

Nên xác định trước những sự kiện bắt buộc chạy lại toàn bộ bộ test: đổi phiên bản mô hình, sửa prompt hướng dẫn, thay đổi lớn trong kho kiến thức, thêm công cụ mới, hoặc cảnh báo drift vượt ngưỡng. Ngoài ra nên có lịch đánh giá định kỳ kể cả khi không có sự kiện nào, vì drift từ phía người dùng không báo trước. Kết quả đánh giá lại được so với baseline, và nếu chấp nhận, trở thành baseline mới.

8. Rollback

Rollback là khả năng quay về cấu hình trước đó khi thay đổi mới làm chất lượng giảm. Muốn rollback được, mọi thành phần phải có phiên bản: mô hình, prompt, cấu hình truy xuất và ảnh chụp kho kiến thức. Nên có quy định ai được quyết định rollback, trong bao lâu, và thông báo cho ai. Có những trường hợp không thể quay lại, ví dụ nhà cung cấp đã ngừng phiên bản cũ; khi đó phương án dự phòng là thu hẹp phạm vi agent hoặc tăng tỷ lệ chuyển người trong lúc chỉnh sửa.

3. Quy trình thiết lập theo dõi drift

Bước 1: Chốt baseline ngay tại thời điểm nghiệm thu

Chạy bộ test cố định trên cấu hình được nghiệm thu, lưu kết quả kèm toàn bộ số phiên bản. Ghi thêm các chỉ số vận hành của vài tuần đầu làm mốc tham chiếu. Nếu agent đã chạy lâu mà chưa có baseline, hãy lập ngay với cấu hình hiện tại và chấp nhận rằng đó là mốc mới.

Bước 2: Gắn phiên bản cho mọi thành phần của agent

Mỗi câu trả lời trong nhật ký nên ghi được phiên bản mô hình, phiên bản prompt và phiên bản kho kiến thức đã tạo ra nó. Thiếu thông tin này, khi chất lượng trượt sẽ không biết trượt từ lúc nào và vì thay đổi nào. Cách ghi nhật ký đủ để truy vết được trình bày ở bài nhật ký AI Agent.

Bước 3: Đặt ngưỡng cảnh báo và người nhận

Chọn vài tín hiệu quan trọng nhất, đặt ngưỡng dựa trên biến động bình thường đã quan sát được, và chỉ định người nhận. Ngưỡng ban đầu nên để rộng rồi siết dần, tránh báo động giả liên tục làm mọi người bỏ qua cảnh báo.

Bước 4: Diễn tập đánh giá lại và rollback

Thử một lần trọn quy trình trên môi trường thử: đổi phiên bản mô hình, chạy bộ test, so với baseline, quyết định giữ hay quay lại. Diễn tập cho thấy quy trình mất bao lâu và thiếu gì, trước khi phải làm thật dưới áp lực.

4. Ví dụ giả định

Một agent hỗ trợ khách hàng trả lời câu hỏi về chính sách đổi trả và bảo hành. Sau khi nhà cung cấp phát hành phiên bản mô hình mới và bí danh mô hình được trỏ sang bản này, nhóm vận hành thấy tỷ lệ từ chối tăng và câu trả lời dài hơn hẳn so với baseline. Vì nhật ký có ghi phiên bản mô hình, nhóm xác định được thời điểm thay đổi trùng với ngày đổi bản.

Nhóm ghim lại phiên bản cũ, chạy bộ test cố định trên bản mới trong môi trường thử và thấy bản mới thận trọng hơn với các câu có nhắc đến tiền hoàn. Họ chỉnh prompt để nêu rõ agent được phép trích nguyên văn chính sách hoàn tiền, chạy lại bộ test, rồi mới chuyển sang bản mới và lập baseline mới. Ví dụ này minh họa quy trình, không phải số liệu của một dự án cụ thể.

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

• Không có baseline thì mọi nhận định “agent kém đi” chỉ là cảm giác
• Gọi mô hình bằng bí danh khiến hành vi đổi mà không ai chủ động quyết định
• Bộ test cố định quá cũ không còn đại diện cho câu hỏi thật
• Chấm điểm tự động bằng một mô hình khác cũng có thể bị trôi theo thời gian

Một giới hạn khác là không phải mọi drift đều xấu. Người dùng hỏi chủ đề mới có thể là tín hiệu kinh doanh tốt, chỉ cần bổ sung tài liệu. Mục tiêu của theo dõi drift là phát hiện sớm và biết nguyên nhân, không phải giữ agent đứng yên. Việc bảo trì định kỳ như cập nhật dữ liệu, rà quyền và kiểm soát chi phí là phạm vi rộng hơn, xem bài bảo trì AI Agent.

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

Chủ sở hữu nghiệp vụ quyết định câu trả lời thế nào là đúng, duyệt bộ test cố định và chấp nhận baseline mới. Đội kỹ thuật quản lý phiên bản các thành phần, theo dõi lịch ngừng hỗ trợ của nhà cung cấp, chạy đánh giá lại và thực hiện rollback. Người vận hành hằng ngày đọc cảnh báo, gom câu hỏi mới vào bộ test cập nhật và báo lên khi xu hướng lạ kéo dài.

Quyền quyết định rollback nên được giao trước cho một người cụ thể, kèm người thay thế. Khi chất lượng giảm ở một quy trình có ảnh hưởng tới khách hàng, chờ họp để quyết định thường quá chậm.

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

• Điểm trên bộ test cố định so với baseline theo từng lần đánh giá
• Tỷ lệ từ chối, chuyển người và phản hồi tiêu cực theo tuần
• Tỷ trọng chủ đề câu hỏi và tỷ lệ câu không tìm được tài liệu
• Độ dài câu trả lời, độ trễ và chi phí mỗi lượt theo phiên bản mô hình

Các chỉ số nên được xem theo phiên bản cấu hình, không chỉ theo thời gian. Khi đặt hai phiên bản cạnh nhau trên cùng bộ test, quyết định giữ hay quay lại sẽ dựa trên số liệu thay vì cảm nhận của người dùng nói to nhất. Phản hồi của người dùng vẫn rất có giá trị để bổ sung bộ test, cách thu và xử lý có hệ thống được bàn ở bài human feedback loop.

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

• Baseline đã lưu kèm phiên bản mô hình, prompt và kho kiến thức
• Mô hình được gọi bằng mã phiên bản cụ thể nếu nhà cung cấp hỗ trợ
• Bộ test có phần cố định, phần cập nhật và phần câu bẫy
• Ngưỡng cảnh báo có người nhận và hướng xử lý ban đầu
• Danh sách sự kiện bắt buộc đánh giá lại đã thống nhất
• Rollback đã diễn tập ít nhất một lần và có người được quyền quyết định

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

Model drift có xảy ra nếu doanh nghiệp không thay đổi gì trong AI Agent? Có. Người dùng vẫn đổi cách hỏi, tài liệu nguồn vẫn được cập nhật bởi các bộ phận, và nhà cung cấp có thể đổi phiên bản mô hình phía sau bí danh. Không sửa gì ở phía agent không có nghĩa là hành vi của nó đứng yên.

Bao lâu nên đánh giá lại AI Agent một lần? Nên đánh giá lại ngay sau mỗi thay đổi mô hình, prompt, kho kiến thức hoặc công cụ, và thêm một lịch định kỳ theo mức rủi ro của quy trình. Quy trình ảnh hưởng tới khách hàng hoặc tiền bạc nên có nhịp dày hơn quy trình hỏi đáp nội bộ.

Có nên luôn dùng phiên bản mô hình mới nhất? Không nên tự động. Bản mới có thể tốt hơn ở mặt này nhưng khác hành vi ở mặt khác. Hãy ghim phiên bản đang chạy, thử bản mới trên bộ test, so với baseline rồi mới chuyển.

Khi nào nên rollback thay vì sửa tiếp? Khi chất lượng giảm ảnh hưởng trực tiếp tới khách hàng hoặc nghiệp vụ quan trọng và chưa rõ nguyên nhân. Quay về cấu hình cũ để ổn định trước, rồi tìm hiểu và sửa trên môi trường thử.

Kết luận

Model drift ở AI Agent dùng LLM đến từ ba phía: người dùng, dữ liệu nguồn và chính mô hình. Không thể ngăn trôi hoàn toàn, nhưng có thể phát hiện sớm nếu có baseline, bộ test ổn định, cảnh báo theo xu hướng và phiên bản rõ ràng cho mọi thành phần. Khi đã ghim được phiên bản và diễn tập rollback, mỗi lần nhà cung cấp cập nhật mô hình sẽ là một quyết định có kiểm soát thay vì một bất ngờ.

Trao đổi với Naventic để thiết lập bộ đánh giá và theo dõi chất lượng AI Agent. Đọc thêm: Dịch vụ.