Evals for taste: Hill-climbing a slide-generation agent

• Một workshop thực hành cho thấy eval biến những "cảm nhận" mơ hồ về chất lượng agent thành phép đo cụ thể, lặp lại được — minh họa qua việc cải tiến dần (hill-climbing) một agent tạo slide.
• Diễn giả trình bày ba loại grader — dựa trên code, dựa trên model (LLM judge), và con người — rồi kết hợp chúng (đếm emoji, slide rối, cỡ chữ, cùng các judge theo rubric cho màu/bố cục/văn bản) để chẩn đoán và sửa một bộ slide cố tình làm xấu.
• Qua các vòng cải tiến (prompt tốt hơn, yêu cầu có biểu đồ, thêm vòng lặp QA đối kháng, rồi đổi sang model thông minh hơn), điểm số tăng đều, đồng thời điểm judge bão hòa cho thấy eval cũng là "tài liệu sống" cần được hiệu chỉnh lại.

• Eval là các bài kiểm tra hệ thống gồm tác vụ và logic chấm điểm; chúng buộc bạn định nghĩa thế nào là thành công và biến việc chữa cháy bị động (chỉ ở production) thành sự tự tin chủ động trước khi ra mắt.
• Benchmark công khai (SWE-bench, Terminal-Bench, OSWorld, ARC-AGI) đo năng lực tổng quát chứ hiếm khi đo đúng use case của bạn — hãy tự xây eval để so sánh model và chọn đúng model cho công việc.
• Ba loại grader đánh đổi chi phí và độ tinh tế: grader dựa code (chuỗi/regex/đếm) nhanh, rẻ, tất định nhưng giòn; grader dựa model (rubric, so sánh cặp, đồng thuận nhiều judge) linh hoạt, tinh tế nhưng bất định và cần hiệu chỉnh; grader con người chất lượng cao nhất nhưng chậm và đắt.
• Cải tiến agent bằng cách đọc kết quả eval rồi cập nhật system prompt — thêm cỡ chữ rõ ràng, quy tắc bố cục/mật độ, và chỉ dẫn "tránh dấu hiệu AI" (không dùng đường nhấn mảnh, không emoji trang trí) dựa trên các lỗi quan sát được.
• Yêu cầu mỗi slide phải có ít nhất một biểu đồ, rồi thêm vòng lặp QA đối kháng ("giả định có vấn đề, nhiệm vụ của bạn là tìm ra; kiểm tra từng ảnh slide, sửa, render lại, soi lại") giúp bộ slide tốt hơn rõ rệt và nâng điểm judge lên khoảng 4.2–4.4.
• LLM judge phải xuất lý do TRƯỚC điểm số, không bao giờ ngược lại — vì model hoạt động tự hồi quy (autoregressive), neo vào con số trước sẽ khiến nó hợp lý hóa con số đó; hãy hỏi ưu/nhược điểm trước rồi mới quyết định.
• Eval là tài liệu sống: một judge cho điểm cao đồng đều (ví dụ "5" cho chất lượng ảnh trong bộ slide không hề có ảnh) là dấu hiệu bão hòa hoặc lệch hiệu chỉnh, cần sửa lại grader.

• eval — eval (đánh giá có hệ thống)
• grader — grader (bộ chấm điểm)
• grader dựa code — code-based grader
• LLM judge — model-based grader / LLM judge
• so sánh cặp — pairwise comparison
• đồng thuận nhiều judge — multi-judge consensus
• rubric — rubric (tiêu chí chấm)
• bão hòa — saturation
• vòng lặp QA — QA loop
• hill-climbing — hill-climbing (cải tiến dần)

Eval là gì và tại sao quan trọng

Eval là các bài kiểm tra hệ thống đo lường mức độ hoạt động tốt của một hệ thống AI trên một lĩnh vực hoặc use case cụ thể. Chúng gồm các tác vụ định nghĩa kịch bản, mã hóa kỳ vọng qua logic chấm điểm. Eval là cầu nối giữa "có vẻ chạy được" / "hôm nay thấy hơi tệ hơn" và một thứ có thể hành động được — khác với "cảm nhận" (vibes) vốn không thể hành động. Khi không có eval, bạn luôn ở trong vòng lặp bị động: chỉ phát hiện lỗi ở production, khó tách phản hồi thật khỏi nhiễu, và không có cách kiểm chứng cải tiến hay thoái lui. Khi có eval, bạn buộc phải định nghĩa thành công trông như thế nào, lặp lại để tối ưu cấu hình agent, áp dụng model mới nhanh hơn và phơi bày vấn đề trước khi ra mắt.

Benchmark công khai như SWE-bench, Terminal-Bench, OSWorld hay ARC-AGI đo năng lực tổng quát, nhưng hiếm khi phản ánh use case riêng của bạn. Vì vậy hãy tự xây eval để so sánh các model và chọn đúng model cho công việc.

Ba loại grader

• Grader dựa code: giống unit test — string match, regex, fuzzy match. Ưu điểm: nhanh, rẻ, tất định. Nhược điểm: giòn, thiếu tinh tế. Phù hợp khi cần kiểm tra cứng, ví dụ "có một bộ slide tồn tại hay không".
• LLM judge (dựa model): lập luận theo rubric, ví dụ "slide này có chất lượng cao không?". Có thể dùng so sánh cặp (đưa hai output, hỏi model thích cái nào và vì sao) hoặc đồng thuận nhiều judge (best-of-three, đa số thắng) để thêm tính tất định. Linh hoạt, có khả năng mở rộng, tinh tế — nhưng bất định, tốn tiền và cần hiệu chỉnh.
• Grader con người: đắt và chậm nhất, dùng ít nhất, nhưng chất lượng và độ tinh tế cao nhất; tốt cho A/B testing và kiểm tra ngẫu nhiên.

Thiết lập agent tạo slide và các grader đầu tiên

Agent được định nghĩa trong agent.yaml với system prompt: "Bạn là agent tạo slide; khi người dùng đưa chủ đề, hãy tạo file PowerPoint... Bạn có một shell với Python PPTX cài sẵn." Repo có hai thư mục grader: code (như đếm emoji, đếm slide rối/cluttered, đếm slide, slide có ảnh, font nhỏ, slide nhiều chữ) và judge (chấm màu sắc, ảnh, bố cục, văn bản theo thang 0–5). Diễn giả nhấn mạnh: nếu một grader không cho thông tin hữu ích thì đừng đưa nó vào eval. Với mỗi kịch bản, bạn phải nói được mình muốn lấy thông tin gì và sẽ hành động ra sao nếu nó suy giảm.

Bộ slide ban đầu khá tệ — chữ chồng lấn, màu kỳ quặc, có emoji. Một script tự động chấm điểm liệt kê số slide, slide có ảnh, slide nhiều chữ, slide rối, font nhỏ, cùng điểm judge 2.8–4.0, vốn khá cao so với chất lượng thực — đây chính là phần cần hiệu chỉnh. Quan trọng: eval không phải chân lý cố định; nó là "tài liệu sống" và có thể bị bão hòa khi không còn cho thông tin hành động được.

Cải tiến dần qua từng vòng

1. Prompt tốt hơn: Thêm thông tin về typography (cỡ tiêu đề, header, body, caption), bố cục và mật độ (chữ súc tích, chừa khoảng trống, căn trái), và "tránh dấu hiệu AI" (không đường nhấn mảnh, không emoji trang trí). Kết quả sạch hơn rõ rệt — nhưng điểm eval lại báo emoji count 20, làm lộ ra rằng chính grader có thể đang chấm sai. Đây là lúc cần human review để hiệu chỉnh lại grader.
2. Yêu cầu biểu đồ: Bắt mỗi slide phải có ít nhất một biểu đồ/chart chèn dưới dạng ảnh thật. Slide trở nên có căn cứ ("grounded") thay vì lan man. Tuy vậy image judge cho 3.8/5 mà không kèm lý do — chỉ là một con số.
3. Vòng lặp QA đối kháng: Áp dụng mẫu generator–critic — yêu cầu agent "giả định có vấn đề, nhiệm vụ là tìm ra; coi QA như cuộc săn bug, không phải bước xác nhận; sau khi viết deck hãy chuyển thành ảnh, tự soi từng slide, sửa, render lại, soi lại, không dừng đến khi hoàn thành ít nhất một chu kỳ sửa-và-xác minh." Kết quả tốt hơn hẳn, điểm judge lên 4.2–4.4.
4. Đổi sang model thông minh hơn: Chuyển từ Sonnet 4.6 sang Opus 4.7 với prompt ban đầu đơn giản. Kết quả tốt hơn đáng kể: Opus không dùng emoji, ít slide font nhỏ hơn nhờ "hiểu" rằng slide cần dễ đọc.

Hiệu chỉnh judge và bẫy thứ tự

Điểm judge của Opus cao đồng đều một cách đáng ngờ (ví dụ "5" cho ảnh trong bộ slide không có ảnh) cho thấy ta có thể đang đo sai thứ. Vấn đề là judge "không có gì để neo vào" — nó không biết thế nào là tốt/xấu. Một bài học quan trọng: vì LLM hoạt động tự hồi quy (autoregressive), nếu bạn yêu cầu xuất điểm số trước rồi mới giải thích, model sẽ cố hợp lý hóa con số đó dù sai. Cách đúng là yêu cầu lý do, ưu điểm, nhược điểm trước, rồi mới đưa ra điểm cuối cùng. Điều này gắn với vòng lặp QA: có thể dùng nhiều agent xác minh, một agent tìm lỗi và một agent phản biện, và nhiều grader để xem lỗi nào lặp lại — vì grader cũng có thể "ảo giác", nhất là trong các kịch bản tinh tế (ví dụ tóm tắt án pháp lý).

Kết luận

Đây mới chỉ là phần giới thiệu ngắn — chủ đề eval rất sâu. Benchmark về bản chất cũng là eval, và lý do mọi nhà cung cấp model đều quan tâm là vì cần tìm ra mình đang thất bại ở đâu, giỏi ở đâu, để cải thiện thế hệ sau. Xây ứng dụng dùng AI agent cũng vậy: tìm cái gì hiệu quả, cái gì không, lặp lại, và đảm bảo mỗi thay đổi đều có tác động tích cực lên kết quả cuối.