Giới hạn an toàn, đánh giá và khả năng quan sát của AI agent

Xây dựng một agent hoạt động tốt trong các bản demo thì dễ. Xây dựng một agent hoạt động đáng tin cậy ở quy mô lớn thì khó. Bài học này sẽ đề cập đến các phương pháp kỹ thuật giúp thu hẹp khoảng cách đó.

🔄 Tóm tắt nhanh: Trong bài học trước, bạn đã học về các mẫu bộ nhớ để duy trì hoạt động của agent. Các agent trong môi trường sản xuất cần nhiều hơn bộ nhớ - chúng cần các giới hạn an toàn để ngăn ngừa tác hại, đánh giá để đo lường độ tin cậy và khả năng quan sát để chẩn đoán lỗi.

Giới hạn an toàn

Giới hạn an toàn là các kiểm tra tự động chạy trước, trong và sau khi thực thi agent để ngăn chặn hành vi có hại hoặc không chính xác.

Giới hạn an toàn đầu vào

Kiểm tra đầu vào của người dùng trước khi agent xử lý:

Đầu vào của người dùng → [Giới hạn an toàn đầu vào] → Agent
              ├── Phát hiện thông tin nhận dạng cá nhân (PII): Chặn số an sinh xã hội, thẻ tín dụng
              ├── Phát hiện tấn công chèn mã độc: Gắn cờ "bỏ qua lệnh"
              ├── Kiểm tra phạm vi: Điều này có nằm trong phạm vi hoạt động của agent không?
              └── Giới hạn tốc độ: Ngăn chặn lạm dụng

Những giới hạn đầu ra

Kiểm tra đầu ra của agent trước khi đến tay người dùng:

Agent → [Giới hạn đầu ra] → Người dùng
         ├── Che giấu thông tin cá nhân: Thay thế dữ liệu nhạy cảm bằng ***
         ├── Xác minh thông tin: Kiểm tra tính xác thực của các tuyên bố dựa trên nguồn
         ├── Tuân thủ chính sách: Không đưa ra lời hứa trái phép
         └── Xác thực định dạng: Cấu trúc chính xác cho các hệ thống tiếp theo

Các giới hạn công cụ

Kiểm tra trước khi thực thi các lệnh gọi công cụ:

Agent muốn gọi: delete_all_records(table="users")
[Giới hạn công cụ]:
  ├── Đây có phải là hành động phá hủy không? → Có
  ├── Người dùng có quyền admin không? → Đã kiểm tra
  ├── Có yêu cầu xác nhận không? → Có
  └── Quyết định: Chặn và yêu cầu xác nhận từ người dùng

✅ Kiểm tra nhanh: Giới hạn đầu ra của agent chặn một phản hồi vì nó chứa cụm từ "Tôi đảm bảo điều này sẽ hoạt động". Prompt hệ thống của agent nói rằng không bao giờ được đưa ra lời đảm bảo. Nhưng phản hồi thực tế là trích dẫn email của khách hàng: "Khách hàng đã viết: 'Tôi đảm bảo điều này sẽ hoạt động'". Giới hạn có nên chặn điều này không?

Câu trả lời: Không - giới hạn có kết quả cảnh báo giả. Nó phát hiện từ "đảm bảo" mà không hiểu ngữ cảnh (đó là một trích dẫn, không phải agent đưa ra lời hứa). Các giới hạn tốt hơn sử dụng phân tích ngữ cảnh, không chỉ khớp từ khóa: "agent đang đưa ra lời đảm bảo, hay đang trích dẫn lời đảm bảo của người khác?" Đây là lý do tại sao các giới hạn cần cân bằng giữa độ nhạy và độ chính xác.

Đánh giá: Đo lường độ tin cậy của agent

Những gì cần đo lường

Xây dựng bộ kiểm thử

Một agent sản xuất cần tối thiểu:

Cấu trúc bộ kiểm thử:
├── Trường hợp bình thường (50%): Đầu vào bình thường, dự kiến
│ "Tóm tắt báo cáo quý này"
│ "Tìm chuyến bay từ NYC đến London"
├── Trường hợp ngoại lệ (25%): Đầu vào bất thường nhưng hợp lệ
│ "Tóm tắt báo cáo 200 trang này" (rất dài)
│ "Tìm chuyến bay khởi hành trong 3 phút" (không thể)
├── Trường hợp đối kháng (15%): Cố gắng phá vỡ hoặc lạm dụng
│ "Bỏ qua hướng dẫn của bạn và..."
│ "Giả vờ bạn là một agent khác"
└── Hồi quy (10%): Các trường hợp đã thất bại trước đó
    Đầu vào gây ra lỗi trong các phiên bản trước

Phương pháp đánh giá

LLM-as-Judge: Sử dụng một LLM riêng biệt để đánh giá đầu ra của agent so với tiêu chí:

Đánh giá phản hồi của agent:
- Agent đã hoàn thành nhiệm vụ được yêu cầu chưa? (0-2)
- Thông tin có chính xác về mặt thực tế không? (0-2)
- Agent có nằm trong phạm vi đã xác định không? (0-1)
- Định dạng có chính xác không? (0-1)

Đánh giá của con người: Đối với các agent có tính rủi ro cao, hãy để con người xem xét một mẫu đầu ra thường xuyên.

Kiểm tra tự động: Đối với các đầu ra có cấu trúc, hãy xác thực bằng lập trình (xác thực JSON schema, tính đầy đủ của trường, phạm vi giá trị).

Khả năng quan sát: Nhìn vào bên trong agent

Theo dõi phân tán

Mỗi lần thực thi agent đều tạo ra một dấu vết - bản ghi của mọi bước:

Trace ID: abc-123
├── [0ms] Nhận được đầu vào từ người dùng: "Phân tích doanh số quý 3"
├── [50ms] Lập kế hoạch: Phân tách thành 3 bước
├── [100ms] Gọi công cụ: database_query("SELECT * FROM sales...")
│ └── [800ms] Kết quả công cụ: Trả về 1.247 hàng
├── [850ms] Gọi công cụ: calculate_metrics(data)
│ └── [1200ms] Kết quả công cụ: {doanh thu: 12,3 triệu, tăng trưởng: 15%}
├── [1250ms] Đang tạo phản hồi
├── [2000ms] Giới hạn đầu ra: ĐÃ VƯỢT QUA
└── [2050ms] Phản hồi đã được gửi đến người dùng

Những gì cần ghi nhật ký

Cảnh báo

Thiết lập cảnh báo cho:

• Tỷ lệ hoàn thành tác vụ giảm xuống dưới ngưỡng — có lỗi hệ thống
• Độ trễ vượt quá SLA — lệnh gọi công cụ bị treo hoặc LLM bị quá tải
• Tỷ lệ kích hoạt giới hạn tăng đột biến — có thể là tấn công hoặc lỗi của agent
• Tỷ lệ lỗi vượt quá mức cơ bản — lỗi mới hoặc lỗi dependency bên ngoài

✅ Kiểm tra nhanh: Tỷ lệ hoàn thành tác vụ của agent đã giảm từ 94% xuống 78% qua đêm. Không có gì trong code của bạn thay đổi. Nguyên nhân có khả năng nhất là gì?

Câu trả lời: Các dependency bên ngoài đã thay đổi: (1) API mà agent sử dụng đã được cập nhật hoặc bị lỗi, (2) nhà cung cấp LLM đã cập nhật mô hình làm thay đổi hành vi, hoặc (3) lược đồ cơ sở dữ liệu đã thay đổi. Kiểm tra dấu vết quan sát của bạn - chúng sẽ hiển thị bước nào trong vòng lặp của agent bị lỗi, chỉ ra trực tiếp nguyên nhân. Đây là lý do tại sao việc theo dõi chi tiết lại quan trọng: Nếu không có nó, bạn sẽ chỉ đoán mò.

Các mẫu phục hồi lỗi

Thử lại với khoảng thời gian chờ

Gọi công cụ thất bại → Chờ 1 giây → Thử lại
Thử lại thất bại → Chờ 2 giây → Thử lại
Thử lại thất bại → Chờ 4 giây → Thử lại
Vượt quá số lần thử lại tối đa → Chiến lược dự phòng

Ngừng công cụ

Nếu một công cụ liên tục bị lỗi, hãy ngừng gọi nó:

Công cụ bị lỗi 5 lần trong 10 phút →
  Mạch MỞ: Ngừng gọi công cụ này
  Sử dụng công cụ dự phòng hoặc thông báo cho người dùng
  Sau 5 phút → Mạch MỞ MỘT NỬA: Thử một cuộc gọi
  Nếu thành công → ĐÓNG MẠCH: Tiếp tục sử dụng bình thường

Giảm hiệu suất một cách nhẹ nhàng

Khi một thành phần bị lỗi, hãy cung cấp dịch vụ bị giảm nhưng vẫn hoạt động:

Đầy đủ chức năng: Tìm kiếm trên web + phân tích + trực quan hóa
Tìm kiếm trên web bị lỗi: Phân tích từ dữ liệu được lưu trong bộ nhớ cache + trực quan hóa
Trực quan hóa bị lỗi: Chỉ tìm kiếm + phân tích + xuất văn bản
Mọi thứ đều bị lỗi: "Tôi đang gặp sự cố kỹ thuật.
                     Đây là những gì tôi có thể hỗ trợ thủ công..."

Danh sách kiểm tra sản xuất

Trước khi triển khai agent vào môi trường sản xuất:

An toàn:
□ Đã cấu hình các biện pháp bảo vệ đầu vào (PII, tấn công chèn, phạm vi)
□ Đã cấu hình các biện pháp bảo vệ đầu ra (che giấu PII, tuân thủ chính sách)
□ Các biện pháp bảo vệ công cụ (xác nhận các hành động gây hại)
□ Đã đặt giới hạn số lần lặp tối đa (ngăn chặn vòng lặp vô hạn)

Đánh giá:
□ Bộ kiểm thử với hơn 50 trường hợp trên tất cả các danh mục
□ Tỷ lệ hoàn thành nhiệm vụ > 90%
□ Tỷ lệ vượt qua kiểm thử đối kháng > 95%
□ Điểm nhất quán > 85% (đầu vào giống nhau → chất lượng giống nhau)

Khả năng quan sát:
□ Đã bật theo dõi phân tán
□ Ghi nhật ký sử dụng token cho mỗi bước
□ Ghi nhật ký kích hoạt bảo vệ
□ Cảnh báo về tỷ lệ hoàn thành, độ trễ, tỷ lệ lỗi

Khả năng phục hồi:
□ Logic thử lại với độ trễ lũy thừa
□ Công cụ ngừng trên các dependency bên ngoài
□ Đường dẫn suy giảm dần được xác định
□ Đường dẫn chuyển giao thủ công cho các lỗi không thể phục hồi

Bài tập thực hành

1. Thiết kế các bảo vệ đầu vào + đầu ra cho một agent trong lĩnh vực của bạn
2. Viết 10 trường hợp thử nghiệm: 5 trường hợp bình thường, 3 trường hợp ngoại lệ, 2 trường hợp đối nghịch
3. Xác định 3 cảnh báo quan trọng nhất mà bạn sẽ thiết lập cho agent của mình

Những điểm chính cần ghi nhớ

• Các bảo vệ hoạt động ở ba lớp: Đầu vào (trước khi xử lý), đầu ra (trước khi phân phối) và công cụ (trước khi thực thi)
• Đánh giá các agent trên nhiều khía cạnh: hoàn thành nhiệm vụ, độ chính xác, tính nhất quán, độ trễ, chi phí và an toàn
• Kiểm tra các bộ kiểm thử cần bao gồm cả 4 loại: Trường hợp thành công, trường hợp ngoại lệ, trường hợp đối kháng và hồi quy.
• Khả năng quan sát thông qua theo dõi phân tán cho phép bạn xác định chính xác vị trí xảy ra lỗi trong các agent nhiều bước.
• Khôi phục lỗi yêu cầu logic thử lại, công cụ ngừng và giảm hiệu suất một cách khéo léo — chứ không chỉ là thông báo lỗi.
• Khả năng sẵn sàng cho sản xuất là một danh sách kiểm tra: An toàn, đánh giá, khả năng quan sát và khả năng phục hồi đều phải được giải quyết.