Điểm benchmark tăng chưa phải vé vào production

Một AI agent chạy ổn trong vài tuần bắt đầu để lại hàng trăm trace: có lượt thành công, lượt gọi nhầm tool, lượt đi vòng và lượt thất bại ở một quyết định rất cụ thể. Từ đây xuất hiện một ý tưởng hấp dẫn: cho một agent khác đọc các trace đó, sửa system prompt và tự làm agent chính tốt lên.

AWS vừa mô tả cách Amazon Bedrock AgentCore Optimization làm gần với mô hình này. Điểm đáng chú ý không nằm ở việc một dịch vụ mới có thể viết lại prompt, mà ở ranh giới AWS đặt giữa đề xuất một cấu hình tốt hơn và cho cấu hình đó đi vào production. Hai việc này không nên là một nút bấm duy nhất.

Trace là nguyên liệu để tạo giả thuyết

Trong thiết kế AWS công bố ngày 16/09/2026, evaluator chấm một tập trace rồi ghi chúng vào vùng mà một reflector agent có thể đọc. Reflector không nhất thiết nhét toàn bộ trace vào một prompt dài. Nó có thể liệt kê file, tìm bằng grep, đọc những lượt đáng chú ý và so sánh các lần thành công với thất bại trước khi đề xuất thay đổi system prompt.

Cách nhìn hữu ích ở đây là: trace không trực tiếp cấp quyền sửa production. Trace giúp tạo candidate — một cấu hình ứng viên kèm lý do vì sao thay đổi đó có thể tốt hơn.

Điều này quan trọng vì cùng một mẫu lỗi có thể dẫn tới nhiều cách sửa. Agent gọi sai tool có thể do system prompt, mô tả tool, dữ liệu context, quyền truy cập hoặc evaluator. Nếu cứ thấy điểm thấp rồi tự động thêm câu vào prompt, hệ thống rất dễ tích lũy một cấu hình ngày càng dài mà chưa chắc sửa đúng nguyên nhân.

AWS chặn ba kiểu tối ưu có vẻ tốt nhưng nguy hiểm

Bài kỹ thuật của AWS nêu ba guardrail cho candidate trước khi chấp nhận. Thứ nhất, nếu cấu hình mới dài hơn phiên bản trước quá 20%, candidate bị từ chối và optimizer phải làm gọn lại. Thứ hai, candidate được kiểm tra về safety để tránh việc cải thiện điểm số bằng cách làm mềm ràng buộc an toàn. Thứ ba, prompt mới không được chép nguyên văn cụm từ từ các trace dùng để tối ưu, nhằm giảm nguy cơ học thuộc bề mặt của tập dữ liệu.

Ba điều kiện này cho thấy một vấn đề rộng hơn: optimizer cũng có failure mode của riêng nó. Một thay đổi có thể làm evaluator hài lòng nhưng vẫn là thay đổi tệ cho hệ thống thật.

Ví dụ, nếu agent thường thất bại ở các yêu cầu có từ khóa hiếm, optimizer có thể học cách nhét chính từ khóa đó vào prompt. Điểm trên tập trace cũ tăng, nhưng đó có thể chỉ là overfit. Hoặc optimizer có thể bỏ một câu hạn chế hành động để agent hoàn thành nhiều task hơn. Reward tăng nhưng rủi ro cũng tăng.

Benchmark của AWS đáng đọc, nhưng không phải bằng chứng để auto-promote

AWS báo cáo Single Agent Reflector đạt 81,55% trên AppWorld trong 6 phút với 20 turns; Sub-Agent Reflector đạt 95,83% trên cùng benchmark. Trên WebShop, hai biến thể lần lượt đạt 78,31% và 79,15%. AWS cũng so sánh với GEPA và MIPROv2 và cho thấy Single Agent Reflector dùng ít turns và thời gian hơn trong cấu hình được báo cáo.

Đây là kết quả có ích để hiểu trade-off giữa một reflector đọc cả tập trace và nhiều sub-agent phân tích từng trace. Nhưng các con số này là benchmark do AWS công bố, với model, tập benchmark và không gian cấu hình cụ thể. Chúng không chứng minh rằng một prompt được optimizer đề xuất sẽ cải thiện agent của doanh nghiệp bạn, càng không chứng minh rằng nó an toàn để tự động thay production prompt.

Chính AWS cũng mô tả bước sau recommendation là validation: offline batch evaluation và controlled A/B testing trước khi promote winner. Đây mới là phần nên mang về cho hệ thống của mình.

Một promotion gate tối thiểu

Thay vì nối thẳng trace -> optimizer -> production, hãy tách thành chuỗi:

trace đã chấm -> candidate prompt -> guardrail -> evaluation độc lập -> A/B có kiểm soát -> promotion

Mỗi mũi tên trả lời một câu hỏi khác nhau. Trace cho biết điều gì đã xảy ra. Reflector đề xuất nên thay đổi gì. Guardrail loại các thay đổi không được phép dù điểm số có vẻ tốt. Evaluation kiểm tra candidate trên dữ liệu không dùng để tạo đề xuất. A/B test xem thay đổi có còn giữ lợi ích khi gặp traffic thực hay không. Chỉ sau đó mới có quyết định promotion.

Với đội nhỏ, không cần xây ngay một nền tảng tối ưu phức tạp. Có thể bắt đầu bằng cách lưu 20–50 trace đa dạng, giữ một evaluation set riêng và yêu cầu mọi thay đổi system prompt phải thắng phiên bản hiện tại trên tiêu chí task quality mà không làm xấu safety, latency hoặc cost vượt ngưỡng đã đặt. Con số 20–50 ở đây là khuyến nghị thực hành AWS đưa ra cho điểm bắt đầu, không phải ngưỡng chuẩn cho mọi hệ thống.

Nếu agent có failure mode rất khác nhau, phân tích từng trace độc lập có thể giúp nhìn thấy nhóm lỗi thiểu số mà một lượt đọc tổng thể bỏ qua. AWS dùng chính lập luận này để giải thích Sub-Agent Reflector. Nhưng thêm nhiều agent phân tích cũng làm tăng số turns và thời gian tối ưu; benchmark của AWS cho thấy biến thể sub-agent đạt điểm cao hơn nhưng không phải lựa chọn rẻ nhất.

Khi nào chưa nên tự động hóa vòng này

Nếu đội chưa có evaluator đủ tin cậy, chưa tách evaluation set khỏi trace dùng để tối ưu, hoặc chưa biết metric nào đại diện cho chất lượng production, tự động viết lại prompt chỉ làm vòng lặp nhanh hơn chứ chưa làm nó đáng tin hơn.

Một dấu hiệu khác là mỗi lần lỗi lại phải sửa metric. Khi thước đo còn thay đổi liên tục, optimizer đang tối ưu một mục tiêu chưa ổn định. Lúc đó, giá trị lớn nhất của trace là giúp con người hiểu failure mode, không phải cấp quyền cho hệ thống tự sửa mình.

Tự tối ưu prompt vì thế nên được xem như một proposal engine trước khi được xem như autopilot. Phần khó không phải tạo ra phiên bản prompt tiếp theo; phần khó là chứng minh phiên bản đó tốt hơn trên bằng chứng chưa bị dùng để tạo nó, vẫn giữ các ràng buộc an toàn và chỉ được promotion sau một phép thử có kiểm soát.

Nguồn

• AWS Machine Learning Blog — Optimizing agent system prompts with Amazon Bedrock AgentCore (16/09/2026): nguồn chính cho thiết kế reflector, ba guardrail, benchmark AppWorld/WebShop và khuyến nghị review, offline evaluation, A/B testing trước promotion. Các kết quả benchmark trong bài là kết quả AWS công bố, không phải phép thử độc lập của AI NEWSROOM.

Nguồn tham khảo

1. aws.amazon.com