Observability cho AI Agent: cần theo dõi những tín hiệu nào?

Một agent chăm sóc khách hàng có thể chạy suốt nhiều ngày với độ trễ ổn định, không một lỗi máy chủ nào, trong khi tỷ lệ câu trả lời sai tăng dần vì kho kiến thức bị nạp thiếu sau một lần cập nhật. Ngược lại, có ngày bảng chỉ số đỏ rực vì nhà cung cấp mô hình chậm, nhưng chất lượng câu trả lời vẫn tốt và khách chỉ phải chờ lâu hơn một chút. Đội vận hành nhìn vào chỉ số hạ tầng quen thuộc sẽ thấy tình huống thứ hai và bỏ lỡ tình huống thứ nhất, trong khi tình huống thứ nhất mới gây hại thật.

Observability, tạm hiểu là khả năng quan sát được trạng thái bên trong của hệ thống từ các tín hiệu nó phát ra, với AI Agent cần rộng hơn phần mềm thông thường: ngoài sức khỏe hệ thống còn có chất lượng, hành vi và chi phí. Bài này vẽ bức tranh các nhóm tín hiệu, cách đặt SLO và ngưỡng cảnh báo, và cách chia bảng điều khiển theo người xem. Ranh giới với các bài gần: nhật ký cần ghi những trường gì có ở bài nhật ký AI Agent; chỉ số kinh doanh của chatbot có ở bài dashboard chatbot; cách truy vết chi tiết một yêu cầu qua nhiều dịch vụ có ở bài tracing cho AI Agent.

1. Một agent “đang chạy” chưa chắc là đang làm đúng việc

Với phần mềm thông thường, nếu yêu cầu được xử lý nhanh và không có lỗi thì gần như chắc chắn kết quả đúng, vì logic là cố định. AI Agent phá vỡ giả định đó. Cùng một đầu vào, mô hình có thể cho ra câu trả lời khác nhau; câu trả lời có thể trôi chảy, đúng định dạng, trả về mã thành công mà nội dung vẫn sai. Agent cũng tự quyết định gọi công cụ nào, bao nhiêu lần, nên có thể rơi vào vòng lặp hoặc gọi công cụ không cần thiết mà không phát sinh lỗi kỹ thuật nào.

Vì vậy observability cho agent dựng trên bốn nhóm tín hiệu thay vì một: sức khỏe hệ thống cho biết agent có phục vụ được không; chất lượng cho biết câu trả lời có đúng và an toàn không; hành vi cho biết agent có làm việc theo cách mong đợi không; chi phí cho biết mỗi lượt phục vụ tốn bao nhiêu và có bất thường không. Bốn nhóm này nên được nhìn cùng nhau, vì nhiều sự cố chỉ hiện ra khi đặt hai nhóm cạnh nhau, ví dụ chi phí tăng cùng lúc với số lần gọi công cụ mỗi phiên tăng là dấu hiệu vòng lặp.

2. Các nhóm tín hiệu cần thiết kế

1. Độ trễ theo phân vị và theo chặng

Độ trễ trung bình che giấu trải nghiệm tệ của một phần người dùng. Nên theo dõi theo phân vị, tức mức mà phần lớn yêu cầu nhanh hơn, ở mức trung vị và ở mức cao như phân vị chín mươi lăm, chín mươi chín. Độ trễ cũng nên tách theo chặng: thời gian truy xuất kho kiến thức, thời gian chờ mô hình trả token đầu tiên, thời gian sinh toàn bộ câu trả lời, thời gian gọi từng công cụ. Khi độ trễ tổng tăng, tách chặng cho biết ngay phải nhìn vào đâu.

Với kênh chat có hiển thị chữ chạy dần, thời gian tới token đầu tiên quan trọng với cảm nhận của người dùng hơn tổng thời gian. Với luồng chạy nền như xử lý email, tổng thời gian xử lý và độ dài hàng đợi quan trọng hơn.

2. Lỗi và sức khỏe của phụ thuộc bên ngoài

Agent phụ thuộc vào nhiều dịch vụ: nhà cung cấp mô hình, kho vector, CRM, ERP, cổng nhắn tin. Mỗi phụ thuộc cần tín hiệu riêng: tỷ lệ lỗi, tỷ lệ bị giới hạn tần suất, tỷ lệ hết thời gian chờ, số lần thử lại. Lỗi nên được phân loại: lỗi do phía mình, lỗi do phụ thuộc, lỗi do đầu vào của người dùng, vì cách xử lý khác nhau.

Một tín hiệu hay bị bỏ qua là tỷ lệ phản hồi của mô hình không đúng định dạng mong đợi, như thiếu trường bắt buộc trong kết quả có cấu trúc hay gọi công cụ với tham số không hợp lệ. Tỷ lệ này tăng thường là dấu hiệu nhà cung cấp đổi phiên bản mô hình hoặc prompt vừa bị sửa.

3. Chất lượng qua chấm mẫu định kỳ

Không thể chấm mọi câu trả lời, nhưng có thể lấy mẫu ngẫu nhiên đều đặn và chấm theo tiêu chí cố định: đúng nội dung, đúng nguồn, đúng phạm vi, giọng điệu phù hợp. Người chấm có thể là chuyên viên nghiệp vụ hoặc một mô hình chấm được hiệu chỉnh với người chấm. Bộ tiêu chí nên dùng chung với scorecard đánh giá agent để kết quả so sánh được qua thời gian, xem bài scorecard AI Agent.

Ngoài lấy mẫu ngẫu nhiên, nên chạy lại bộ câu hỏi kiểm thử cố định theo lịch trên môi trường thật. Kết quả của bộ cố định thay đổi là tín hiệu sớm của drift, khi có thay đổi ở mô hình, dữ liệu hay hành vi người dùng; cách phát hiện và xử lý drift có ở bài model drift.

4. Bám nguồn và từ chối

Hai tín hiệu tự động tính được cho mọi câu trả lời: câu trả lời có trích ít nhất một nguồn hợp lệ không, và agent có từ chối hay trả lời “không tìm thấy thông tin” không. Tỷ lệ bám nguồn giảm có thể do truy xuất kém đi. Tỷ lệ từ chối tăng đột ngột thường do kho kiến thức thiếu tài liệu sau lần nạp, còn giảm đột ngột về gần không lại đáng lo, vì có thể agent đang trả lời cả những câu lẽ ra phải từ chối.

Những tín hiệu này nên tách theo chủ đề hoặc theo luồng. Tỷ lệ từ chối chung ổn định có thể che giấu việc một chủ đề cụ thể bị từ chối hàng loạt.

5. Chuyển người và lý do

Tỷ lệ hội thoại được chuyển sang nhân viên là tín hiệu nằm giữa chất lượng và nghiệp vụ. Với observability, quan trọng là lý do chuyển: người dùng yêu cầu, agent không đủ thông tin, chủ đề thuộc diện bắt buộc chuyển, công cụ lỗi, phát hiện cảm xúc tiêu cực. Mỗi lý do thay đổi theo kiểu khác nhau báo hiệu vấn đề khác nhau; chuyển người vì công cụ lỗi tăng là sự cố kỹ thuật, chuyển vì người dùng yêu cầu tăng là dấu hiệu chất lượng.

Cần theo dõi cả phía nhận: hàng chờ của nhân viên dài ra, thời gian nhận hội thoại tăng. Agent chuyển đúng nhưng không ai nhận thì với khách vẫn là sự cố.

6. Hành vi gọi công cụ và vòng lặp

Mỗi phiên nên có các tín hiệu: số lần gọi công cụ, số bước suy luận, công cụ nào được gọi, có gọi lặp cùng công cụ với cùng tham số không. Phân bố số lần gọi mỗi phiên thường ổn định; phần đuôi dài ra là dấu hiệu agent đang loay hoay. Gọi lặp cùng tham số là dấu hiệu vòng lặp, nên có giới hạn cứng và cảnh báo.

Theo dõi cả công cụ không được gọi: một công cụ trước đây được dùng thường xuyên đột nhiên không còn được gọi, có thể vì mô tả công cụ vừa bị sửa hoặc mô hình mới hiểu khác. Các lượt gọi bị lớp thực thi từ chối, do sai tham số hay không có quyền, cũng là tín hiệu hành vi đáng xem.

7. Chi phí token theo luồng và theo phiên

Chi phí của agent chủ yếu đến từ token đầu vào và đầu ra của mô hình, cộng với phí các API khác. Tín hiệu cần có là chi phí trung bình và phân vị cao theo phiên, tách theo luồng, theo mô hình, theo kênh. Phiên có chi phí bất thường thường đi kèm ngữ cảnh phình to, như lịch sử hội thoại quá dài hoặc truy xuất trả về quá nhiều đoạn, hoặc vòng lặp công cụ.

Chi phí nên được nhìn theo đơn vị nghiệp vụ, như chi phí mỗi hội thoại được giải quyết, chứ không chỉ tổng theo ngày. Khi chi phí mỗi đơn vị tăng mà chất lượng không đổi, đó là lúc xem lại độ dài ngữ cảnh, số đoạn truy xuất và lựa chọn mô hình cho từng bước.

8. SLO, ngưỡng cảnh báo và bảng điều khiển theo người xem

SLO, mục tiêu mức dịch vụ nội bộ, là cam kết đo được cho một luồng, ví dụ phần lớn yêu cầu của luồng tra đơn phải có token đầu tiên trong một khoảng thời gian nhất định và tỷ lệ lỗi phải dưới một mức nhất định trong mỗi kỳ. Con số cụ thể do doanh nghiệp chọn theo nghiệp vụ và năng lực hạ tầng. SLO khác SLA ở chỗ là mục tiêu nội bộ để vận hành, còn SLA là cam kết hợp đồng; phần cam kết hợp đồng có ở bài SLA cho AI Agent.

Cảnh báo nên gắn với SLO và với các dấu hiệu cần người xử lý ngay, không gắn với mọi chỉ số. Bảng điều khiển chia theo người xem, như bảng dưới.

3. Quy trình triển khai thực tế

Bước 1: Viết các câu hỏi vận hành cần trả lời

Trước khi chọn chỉ số, liệt kê những câu hỏi mà đội vận hành và chủ nghiệp vụ cần trả lời được: agent có đang phục vụ được không, chậm ở đâu, có đang trả lời sai một chủ đề nào không, có phiên nào đang lặp không, vì sao chi phí tuần này tăng. Mỗi câu hỏi dẫn tới một hoặc vài tín hiệu. Tín hiệu không trả lời câu hỏi nào thì chưa cần.

Bước 2: Đặt SLO cho vài luồng chính

Chọn vài luồng quan trọng nhất, đặt SLO cho độ trễ và tỷ lệ lỗi dựa trên dữ liệu đo thực tế giai đoạn thử, không lấy con số tùy ý. Với chất lượng, đặt mức chấp nhận cho kết quả chấm mẫu và bộ kiểm thử cố định. Thống nhất khi SLO bị vi phạm thì làm gì: dừng phát hành tính năng mới để sửa, chuyển sang phương án dự phòng, hay báo chủ nghiệp vụ.

Bước 3: Gắn tín hiệu và dựng bảng theo đối tượng

Bổ sung các trường còn thiếu vào nhật ký và chỉ số: thời gian theo chặng, phân loại lỗi, số lần gọi công cụ, token, lý do chuyển người. Gắn mã trace để từ một điểm bất thường trên biểu đồ có thể mở tới các yêu cầu cụ thể. Dựng bảng theo từng nhóm người xem, mỗi bảng ít biểu đồ, mỗi biểu đồ trả lời một câu hỏi đã viết ở bước một.

Bước 4: Tinh chỉnh cảnh báo sau vài chu kỳ trực

Sau một thời gian vận hành, rà lại từng cảnh báo đã bắn: có cần người xử lý ngay không, có ai làm gì sau khi nhận không. Cảnh báo không dẫn tới hành động nên chuyển thành báo cáo định kỳ hoặc bỏ. Sự cố đã xảy ra mà không có cảnh báo nào báo trước thì bổ sung tín hiệu. Mỗi cảnh báo nên kèm đường dẫn tới hướng dẫn xử lý ngắn.

4. Ví dụ giả định

Một công ty bảo hiểm phi nhân thọ vận hành agent hỗ trợ khách tra hợp đồng và hướng dẫn hồ sơ bồi thường. Ban đầu đội vận hành chỉ có bảng hạ tầng với độ trễ và lỗi máy chủ. Sau một lần cập nhật kho tài liệu, khách liên tục được chuyển sang nhân viên với lý do agent không đủ thông tin cho câu hỏi về bảo hiểm xe, nhưng bảng hạ tầng vẫn xanh và phải vài ngày sau trưởng nhóm tổng đài mới phản ánh.

Công ty bổ sung tín hiệu từ chối và chuyển người theo chủ đề, chạy lại bộ câu hỏi kiểm thử cố định mỗi ngày, và đặt cảnh báo khi tỷ lệ từ chối của một chủ đề lệch mạnh so với mức thường thấy. Người trực vận hành có bảng thời gian thực; chủ nghiệp vụ nhận báo cáo tuần về kết quả chấm mẫu theo chủ đề. Ở lần cập nhật kho sau, cảnh báo bắn trong vài giờ đầu, đội vận hành mở trace của các phiên bị từ chối và thấy nhóm tài liệu về bảo hiểm xe bị lỗi ở bước nạp. Ví dụ này là giả định để minh họa cách dựng tín hiệu.

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

• Chỉ theo dõi sức khỏe hạ tầng, bỏ lỡ sự cố chất lượng khi hệ thống vẫn chạy bình thường
• Quá nhiều cảnh báo khiến người trực bỏ qua, kể cả cảnh báo quan trọng
• Mô hình chấm tự động lệch khỏi đánh giá của người mà không được hiệu chỉnh lại
• Tín hiệu gộp chung che giấu vấn đề của một chủ đề hay một kênh cụ thể

Observability không tự sửa lỗi. Nó chỉ rút ngắn thời gian từ lúc sự cố bắt đầu đến lúc có người biết và biết nhìn vào đâu. Tín hiệu chất lượng cũng luôn là gián tiếp: chấm mẫu chỉ đại diện cho một phần, bám nguồn không chứng minh câu trả lời đúng. Cần chấp nhận một số lỗi chỉ được phát hiện qua phản hồi của người dùng, và thiết kế kênh nhận phản hồi đó tốt.

Dữ liệu observability cũng là dữ liệu nhạy cảm: nhật ký và trace chứa nội dung hội thoại. Quyền xem bảng điều khiển chi tiết nên theo vai trò, và nội dung cần được che theo chính sách chung.

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

Đội vận hành nền tảng sở hữu hạ tầng thu thập tín hiệu, bảng thời gian thực, cảnh báo và lịch trực. Đội phát triển agent chịu trách nhiệm phát đủ tín hiệu từ mã, xem các tín hiệu hành vi và định dạng sau mỗi lần phát hành, và sửa khi SLO bị vi phạm do phía agent. Chủ nghiệp vụ sở hữu tiêu chí chấm chất lượng, tham gia chấm mẫu hoặc hiệu chỉnh mô hình chấm, và quyết định mức chấp nhận về chất lượng. Người phụ trách ngân sách xem báo cáo chi phí và cùng đội phát triển quyết định khi chi phí vượt kế hoạch.

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

• Tỷ lệ thời gian các luồng chính đạt SLO về độ trễ và lỗi trong mỗi kỳ
• Thời gian từ khi sự cố bắt đầu đến khi có cảnh báo hoặc có người phát hiện
• Tỷ lệ cảnh báo dẫn tới hành động xử lý thật
• Mức đồng thuận giữa mô hình chấm và người chấm trên cùng mẫu

Thời gian phát hiện là chỉ số phản ánh trực tiếp giá trị của observability. Nếu phần lớn sự cố vẫn được biết qua phản ánh của khách hay của bộ phận nghiệp vụ, hệ thống tín hiệu đang thiếu ở đúng chỗ quan trọng.

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

• Có tín hiệu cho cả bốn nhóm: sức khỏe hệ thống, chất lượng, hành vi và chi phí
• Độ trễ được đo theo phân vị và tách theo chặng
• Các luồng chính có SLO và cách xử lý khi vi phạm đã thống nhất
• Có giới hạn cứng và cảnh báo cho vòng lặp gọi công cụ
• Bảng điều khiển tách theo người xem, mỗi cảnh báo có hướng dẫn xử lý
• Từ một điểm bất thường có thể mở tới nhật ký và trace của các yêu cầu cụ thể

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

Observability khác gì giám sát thông thường? Giám sát thông thường trả lời câu hỏi hệ thống có đang chạy không, dựa trên các chỉ số đã định sẵn. Observability là khả năng trả lời cả những câu hỏi chưa nghĩ tới trước, nhờ có đủ chỉ số, nhật ký và trace để đào sâu. Với AI Agent, hệ thống có thể chạy rất ổn mà vẫn trả lời sai, nên cần thêm tín hiệu về chất lượng và hành vi chứ không chỉ độ trễ và lỗi.

Làm sao đo chất lượng câu trả lời khi không có đáp án đúng cho mỗi câu hỏi? Dùng nhiều tín hiệu gián tiếp kết hợp: chấm mẫu định kỳ bởi người hoặc bởi mô hình chấm theo tiêu chí rõ, tỷ lệ câu trả lời có trích nguồn hợp lệ, tỷ lệ từ chối, tỷ lệ chuyển người và lý do, phản hồi của người dùng. Không tín hiệu nào đủ một mình, nhưng khi nhiều tín hiệu cùng xấu đi thì gần như chắc chắn có vấn đề.

Nên đặt cảnh báo cho những tín hiệu nào? Cảnh báo tức thời chỉ nên dành cho những gì cần người xử lý ngay: tỷ lệ lỗi tăng vọt, độ trễ vượt ngưỡng kéo dài, agent lặp gọi công cụ, chi phí tăng đột biến. Tín hiệu chất lượng thay đổi chậm nên xem theo báo cáo định kỳ. Cảnh báo quá nhiều sẽ khiến người trực bỏ qua cả cảnh báo quan trọng.

Bảng điều khiển vận hành có dùng chung với bảng chỉ số kinh doanh được không? Không nên gộp. Người trực vận hành cần thấy sức khỏe hệ thống, lỗi, độ trễ, hành vi bất thường theo thời gian thực. Quản lý nghiệp vụ cần thấy tỷ lệ giải quyết, chủ đề, chuyển người theo tuần hoặc tháng. Cùng nguồn dữ liệu, nhưng nên là các bảng khác nhau cho từng đối tượng.

Kết luận

Observability cho AI Agent phải nhìn được bốn mặt cùng lúc: hệ thống có phục vụ được không, câu trả lời có đúng không, agent có hành xử như mong đợi không, và mỗi lượt phục vụ tốn bao nhiêu. Đo độ trễ theo phân vị và theo chặng, theo dõi lỗi của từng phụ thuộc, chấm mẫu chất lượng đều đặn, đếm bám nguồn, từ chối và chuyển người theo chủ đề, canh vòng lặp công cụ và chi phí theo phiên, rồi gom lại bằng SLO, cảnh báo có chọn lọc và bảng điều khiển theo đúng người xem.

Trao đổi với Naventic để dựng hệ thống tín hiệu và cảnh báo cho AI Agent đang vận hành. Đọc thêm: AI Workflow Automation.