Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 4 — Đo Task Completion: agent có thực sự hoàn thành việc?

Đã đọc 0/10 mục · còn khoảng 4 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Bài 4 — Đo Task Completion: agent có THỰC SỰ hoàn thành việc không?

"Câu trả lời nghe hay" không bằng "việc được làm xong". Task completion rate — tỷ lệ nhiệm vụ hoàn thành đúng — là chỉ số bắc cầu giữa kỹ thuật và giá trị kinh doanh. Nhưng đo nó đúng khó hơn bạn nghĩ, vì "hoàn thành" thường mơ hồ. Bài này biến "hoàn thành" thành thứ đo được.

Định nghĩa "hoàn thành" thành tiêu chí kiểm được

Với mỗi loại nhiệm vụ, viết ra điều kiện nghiệm thu (acceptance criteria) — thứ kiểm được bằng máy sau khi agent xong:

  • Nhiệm vụ "đặt lịch họp" → hoàn thành khi: có 1 sự kiện mới trên calendar, đúng người tham dự, đúng khung giờ.
  • Nhiệm vụ "trả lời trạng thái đơn" → hoàn thành khi: câu trả lời chứa ngày giao khớp với dữ liệu tool.
  • Nhiệm vụ "tạo báo cáo" → hoàn thành khi: file được tạo, đủ 3 mục bắt buộc.
Nguyên tắc vàng: kiểm trạng thái thế giới sau khi chạy (end-state), không chỉ kiểm câu chữ.

Ba mức đo, chọn theo bối cảnh

1. Binary   : xong / không xong (0 hoặc 1)   — đơn giản, dễ tổng hợp
2. Partial  : xong bao nhiêu % bước con       — cho nhiệm vụ nhiều bước
3. Weighted : mỗi bước con có trọng số quan trọng

Ví dụ nhiệm vụ 4 bước con (tìm chuyến bay → chọn → điền thông tin → thanh toán). Nếu agent làm 3/4 nhưng trượt bước thanh toán thì với người dùng vẫn là thất bại — đây là lúc cần weighted (bước cuối trọng số cao) thay vì partial ngây thơ 75%.

Ví dụ: hàm chấm end-state

def check_meeting_task(case, world_after):
    ev = find_event(world_after, title=case["title"])
    if not ev:                      return 0, "không tạo được sự kiện"
    if set(ev.attendees) != set(case["attendees"]):
        return 0, "sai người tham dự"
    if ev.start != case["start"]:   return 0, "sai khung giờ"
    return 1, "hoàn thành đúng"

Các bước đo task completion

  • Phân loại nhiệm vụ agent xử lý (VD: tra cứu, đặt lịch, tạo file...).
  • Viết acceptance criteria end-state cho mỗi loại — kiểm được bằng máy.
  • Chạy agent trong môi trường sandbox (dữ liệu giả nhưng hành vi thật) để kiểm được end-state an toàn.
  • Chấm binary trước; nếu nhiệm vụ dài, thêm weighted cho bước then chốt.
  • Tính completion rate = số ca đạt / tổng ca, tách theo từng loại nhiệm vụ.
  • Soi các ca fail: phân nhóm nguyên nhân (đi lạc, tool lỗi, bịa, bỏ dở).

Phân biệt 2 chỉ số dễ nhầm

  • Completion rate: agent làm xong đúng bao nhiêu %? (đo giá trị)
  • Success-without-help / autonomy: làm xong mà không cần người can thiệp bao nhiêu %? (đo độ tự chủ)
Một agent completion 90% nhưng 40% cần người cứu → chưa sẵn sàng tự động hoàn toàn.

Ba cách lấy "ground truth" để chấm

Muốn chấm completion, bạn cần biết đâu là đúng. Ba nguồn theo thứ tự ưu tiên:

  • Kiểm được bằng máy từ end-state (tốt nhất): sự kiện có trên calendar, file có tồn tại, số dòng đúng. Không cần người, chạy lại được vô hạn.
  • Đáp án tham chiếu do người soạn cho từng ca (khi end-state khó tự kiểm): lưu kèm dataset.
  • LLM-as-judge có rubric (khi hai cách trên không khả thi): dùng cho output tự do, nhưng phải hiệu chỉnh judge bằng một mẫu do người chấm.
Càng đẩy về (1) càng tốt: rẻ, khách quan, lặp lại được.

Khung tư duy: "Definition of Done" cho agent

Trước khi đo, trả lời: "Ai đó nhìn vào đâu để biết chắc việc đã xong đúng?" Nếu câu trả lời là "đọc và cảm nhận" → chưa đo được. Ép nó về một artifact hoặc thay đổi trạng thái cụ thể.

Sai lầm thường gặp

  • Đo bằng độ dài/độ mượt câu trả lời: Agent nói nhiều ≠ làm xong.
  • Chỉ kiểm câu chữ, không kiểm end-state: Agent nói "đã đặt lịch xong" nhưng calendar trống rỗng.
  • Partial credit ngây thơ: 75% nghe ổn nhưng nếu bước cuối là bước sống-còn thì thực chất là 0%.
  • Gộp mọi loại nhiệm vụ vào 1 số: Che giấu việc một loại nhiệm vụ đang hỏng nặng.
  • Quên đo độ tự chủ: Completion cao nhờ người liên tục cứu → ảo tưởng sẵn sàng.

Checklist kết bài

  • [ ] Mỗi loại nhiệm vụ có acceptance criteria end-state.
  • [ ] Chấm được binary; nhiệm vụ dài có weighted.
  • [ ] Completion rate tách theo loại nhiệm vụ.
  • [ ] Có theo dõi cả độ tự chủ (không cần người cứu).
Bài sau: săn hai lỗi nguy hiểm nhất — agent đi lạc và lặp vô hạn.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi