Theo dõi AI agent bằng OpenTelemetry: đừng gộp token với kết quả thật

Để theo dõi AI agent bằng OpenTelemetry, hãy đặt các lần gọi model, truy xuất dữ liệu và gọi công cụ vào cùng một trace; ghi độ trễ, lỗi và token tại bước phát sinh. Bài hướng dẫn GenAI của OpenTelemetry mô tả cách cây span cho thấy đường đi của lượt agent, còn metric tổng hợp thời gian gọi model và mức sử dụng token.

Đồng thời, ứng dụng cần ghi riêng tín hiệu người dùng chấp nhận câu trả lời hoặc hệ thống phía sau hoàn tất tác vụ. Trace cho biết agent đã thực hiện những bước nào; token và trạng thái trả về cho biết mức sử dụng cùng kết quả kỹ thuật của lượt chạy. Chúng không tự cho biết nhu cầu của người dùng đã được giải quyết hay chưa.

Đặt ranh giới cho một lượt agent

Mỗi lượt chạy nên có một run_id do ứng dụng tạo và một trace chứa các span của những thao tác thực sự diễn ra. Span gốc bao trùm lượt agent; các span con ghi lần gọi model, bước truy xuất và lần thực thi công cụ. Quan hệ cha–con giúp tìm bước gây chậm hoặc lỗi, còn trace ID đưa người vận hành trở lại toàn bộ đường đi của lượt đó.

Nếu truy xuất hoặc công cụ chạy ở dịch vụ khác, truyền trace context qua lời gọi để span của dịch vụ ấy vẫn nối với lượt gốc. Với công việc tiếp tục bất đồng bộ, giữ mã tác vụ của ứng dụng trong thông điệp chuyển tiếp. Nhờ vậy, một kết quả đến sau khi agent đã trả lời vẫn có thể gắn với đúng tác vụ mà không cần giữ trace mở để chờ phản hồi.

Trace ID và run_id phục vụ hai việc khác nhau. Một tác vụ có thể được thử lại trong một trace mới; một cuộc hội thoại cũng có thể gồm nhiều lượt chạy. Vì thế, dùng run_id hoặc operation_id ổn định để nối các lần thử và sự kiện kết quả, rồi lưu trace ID như con trỏ tới chi tiết kỹ thuật của từng lần chạy.

Schema tối thiểu cho span và sự kiện

Bảng thuộc tính GenAI liệt kê các trường gen_ai.operation.name, gen_ai.request.model, gen_ai.response.model, gen_ai.tool.name, gen_ai.usage.input_tokens, gen_ai.usage.output_tokens và các trường token cache. Trang đăng ký đánh dấu các mục này đã chuyển sang kho quy ước GenAI riêng; khi triển khai, hãy cố định phiên bản quy ước và thư viện thu thập để dashboard không đổi nghĩa trường sau một lần nâng cấp.

Schema dưới đây là bộ dữ liệu vận hành đề xuất cho một lượt agent, không phải danh sách thuộc tính bắt buộc của OpenTelemetry. Mỗi trường phải có nơi phát sinh rõ ràng để tránh sao chép cùng một số liệu sang nhiều sự kiện rồi cộng trùng:

• Span gốc: run_id, tên workflow hoặc agent, phiên bản triển khai, thời điểm bắt đầu, thời lượng và trạng thái kỹ thuật khi lượt chạy kết thúc.
• Span gọi model: tên thao tác, nhà cung cấp, model được yêu cầu, model thực tế trả về nếu có, thời lượng, trạng thái, token đầu vào, token đầu ra và các loại token cache mà nhà cung cấp báo cáo.
• Span truy xuất và công cụ: tên thao tác hoặc công cụ, thời lượng, trạng thái, nhóm lỗi đã chuẩn hóa và số lần thử. Mã nguồn dữ liệu chỉ nên được ghi khi đã được duyệt cho mục đích điều tra.
• Sự kiện kết quả: run_id, loại kết quả, trạng thái, thời điểm xảy ra, phiên bản triển khai và trace ID nếu chính sách cho phép chia sẻ mã này với nơi lưu sự kiện.

Token thuộc về lần gọi model tạo ra chúng. Nếu agent gọi model nhiều lần, tổng mức sử dụng của lượt là tổng các yêu cầu thực tế; một lần thử lại có thể phát sinh thêm yêu cầu tính phí. Bước truy xuất hoặc công cụ nên giữ thời lượng và trạng thái riêng, để một công cụ chậm không bị nhầm thành model chậm.

Ghi kết quả tại nơi biết kết quả

Khi agent trả về hoặc gặp lỗi, ứng dụng có thể phát sự kiện kết thúc lượt chạy. Hướng dẫn nối trace với sự kiện kết quả của Telemetry phân biệt rõ việc run trả về với việc người dùng chấp nhận câu trả lời hoặc tác vụ phía sau hoàn tất. Sự kiện kết quả sau cùng phải do thành phần quan sát được việc chấp nhận hoặc hoàn tất phát ra.

Ví dụ giả định: agent giúp người dùng đổi lịch hẹn. Span gọi công cụ có thể cho thấy yêu cầu đổi lịch đã được gửi thành công, nhưng hệ thống quản lý lịch mới biết lịch đã thực sự cập nhật hay chưa. Nếu người dùng còn phải xác nhận phương án, kết quả nên là “đang chờ” hoặc “chưa biết”, thay vì được tính ngay là tác vụ thành công.

Định nghĩa riêng các trạng thái “agent trả về”, “người dùng chấp nhận”, “tác vụ hoàn tất”, “bị từ chối” và “chuyển cho người xử lý”. Chọn thời hạn chờ phù hợp với quy trình nghiệp vụ, đồng thời cho phép cập nhật khi kết quả đến muộn. Khi tính tỷ lệ hoàn tất, mẫu số phải là những lượt đủ điều kiện quan sát kết quả; lượt chưa nhận được phản hồi không nên tự động trở thành thất bại. Khử trùng lặp sự kiện gửi lại bằng mã tác vụ ổn định.

Đo chi phí và dựng dashboard

Token là mức sử dụng, còn chi phí là phép tính phụ thuộc vào model và bảng giá áp dụng cho từng loại token. Để ước tính chi phí một lượt, lấy mức sử dụng do nhà cung cấp báo cáo cho mỗi yêu cầu tính phí, tách token đầu vào thông thường, token đọc hoặc ghi cache và token đầu ra theo đúng quy tắc giá của yêu cầu đó. Lưu phiên bản bảng giá cùng khoản ước tính để có thể đối soát với hóa đơn.

Trong quy ước GenAI, số token đọc từ cache được tính trong tổng gen_ai.usage.input_tokens. Vì vậy, không cộng token cache thêm lần nữa để ra tổng đầu vào; khi áp giá khác nhau, hãy tách phần cache ra khỏi tổng trước khi tính. Nếu nhà cung cấp không trả đủ chi tiết cho một loại token, hiển thị khoản chi phí là ước tính có giới hạn thay vì suy ra từ độ trễ span.

Dashboard nên giữ các câu hỏi vận hành ở những ô riêng để một tín hiệu đẹp không che một kết quả kém:

• Lỗi: số lượt chạy, tỷ lệ lỗi theo bước model, truy xuất và công cụ, số lần thử lại và nhóm lỗi đã giới hạn giá trị.
• Độ trễ: phân bố thời gian của toàn lượt và từng loại span, kèm đường dẫn từ lượt bất thường đến trace tương ứng.
• Mức sử dụng và chi phí: token theo model và loại token, chi phí ước tính trên mỗi lượt, cùng chi phí trên mỗi kết quả được chấp nhận khi đã có tín hiệu chấp nhận.
• Kết quả: tỷ lệ câu trả lời được chấp nhận, tỷ lệ tác vụ phía sau hoàn tất, lượt chuyển cho người xử lý và lượt vẫn đang chờ.

Lọc các chỉ số theo workflow và phiên bản triển khai để thấy thay đổi nào đi cùng mức lỗi, thời gian hoặc chi phí tăng. Từ một lượt bất thường, run_id phải dẫn tới trace của lần chạy liên quan; từ bản ghi kết quả, người vận hành phải phân biệt được tác vụ đã hoàn tất với tác vụ chưa có dữ liệu phản hồi.

Chặn nội dung nhạy cảm trước khi xuất telemetry

Prompt, câu trả lời, chỉ dẫn hệ thống, văn bản truy xuất, tham số và kết quả công cụ có thể chứa dữ liệu cá nhân hoặc bí mật của khách hàng. Với giám sát thường ngày, chỉ nên xuất tên thao tác, model, lượng token, thời lượng, trạng thái và nhóm lỗi đã chuẩn hóa. Nội dung đầy đủ, nếu thực sự cần để điều tra, cần một phạm vi thu thập riêng với quyền xem và thời gian lưu được kiểm soát.

Áp dụng danh sách trường được phép trong ứng dụng hoặc trước bộ xuất telemetry, trước khi dữ liệu rời môi trường kiểm soát. Việc ẩn một cột trên dashboard không xóa nội dung đã nằm trong trace, log hay kho sự kiện. Cũng cần xem xét thông báo lỗi tự do, header xác thực và dữ liệu được truyền kèm trace: chúng có thể mang nội dung nhạy cảm dù không được đặt tên là prompt.

Trước khi vận hành, chạy thử một lượt hoàn tất, một lỗi công cụ, một lần thử lại và một kết quả đến muộn. Đối chiếu run_id với từng trace, kiểm tra token cache không bị cộng hai lần và xem bản xuất mặc định có giữ lại nội dung người dùng hoặc tham số công cụ hay không. Những phép thử này kiểm tra trực tiếp ranh giới giữa dữ liệu kỹ thuật cần quan sát và bằng chứng về kết quả thực tế.

Đọc thêm:

• WSO2 Agent Manager 1.0 mở mã nguồn, nhưng quản trị phải tách khỏi agent
• Bong bóng AI có thật không? Năm chỉ báo tách doanh thu khỏi kỳ vọng
• Bong bóng AI có thật không? Bốn dấu hiệu nhà đầu tư nên theo dõi