Đo kết quả, đừng đếm token
Đánh giá agent bằng tổng công sức đến lúc có kết quả dùng được: thời gian giao việc, kiểm tra, sửa lỗi và chi phí duy trì một quy trình có thể lặp lại.
Một buổi tối làm việc với agent có thể trông rất hiệu quả: cửa sổ liên tục chạy, tệp mới xuất hiện, bản báo cáo ngày càng dài. Nhưng đến lúc đóng máy, bạn vẫn chưa dám dùng kết quả. Bạn đang mua được năng suất, hay chỉ đang có thêm một thứ cần kiểm tra?
Câu hỏi ấy quan trọng hơn việc hôm nay đã dùng bao nhiêu token. Người làm một mình thường thiếu cả thời gian lẫn sự tập trung. Một công cụ đáng giá cần trả lại cho họ một phần của hai thứ đó, đồng thời tạo ra kết quả đủ tốt để đi vào công việc thật.
Từ một quan sát của Naval đến câu hỏi của người sử dụng
Trong cuộc trò chuyện “Waste Tokens, Save Time” trên nav.al, ngày 27/05/2026, Naval đề nghị nhìn vào thời gian và đầu ra cuối cùng khi đánh giá việc dùng AI. Các khách mời cũng chất vấn việc lấy mức tiêu thụ token làm thước đo năng suất. Đó là điểm xuất phát của bài này; khung đo lường và các tình huống dưới đây là phân tích độc lập của La Bàn.
Đặt câu hỏi về đầu ra sẽ đưa ta đến một phân biệt hữu ích: hoạt động của máy và tiến bộ của công việc. Máy có thể đang làm nhiều việc, nhưng tiến bộ chỉ xuất hiện khi một trở ngại cụ thể được giải quyết. Với một bản hướng dẫn, đó có thể là người mới thực hiện được quy trình. Với một lần sửa lỗi, đó là tình huống từng hỏng nay chạy đúng và những chức năng liên quan vẫn sử dụng được.
Vì thế, trước khi chọn mô hình hoặc so chi phí, ta cần gọi tên thứ sẽ được nghiệm thu. “Viết lại tài liệu” còn quá rộng. “Một đồng nghiệp chưa biết dự án có thể cài đặt và chạy ví dụ bằng tài liệu này” đã gần với một kết quả có thể kiểm tra.
Đếm cả phần việc quay trở lại với bạn
Chi phí dễ nhìn nhất nằm trên hóa đơn công cụ. Phần khó nhìn hơn nằm trong lịch của người dùng: chuẩn bị ngữ cảnh, chờ, giải thích lại, tìm lỗi và khôi phục những thứ bị sửa nhầm. Một đầu ra rẻ có thể kéo theo một vòng kiểm tra dài. Một đầu ra tốn nhiều tài nguyên hơn có thể đáng giá nếu rút ngắn được vòng ấy.
Có thể bắt đầu bằng ba con số riêng biệt. Thứ nhất là thời gian bạn trực tiếp làm việc: giao việc, theo dõi, đọc và sửa. Thứ hai là thời gian từ khi bắt đầu đến lúc có kết quả dùng được. Thứ ba là chi phí công cụ. Giữ chúng riêng giúp tránh đánh đồng mười phút máy chạy nền với mười phút bạn phải nhìn màn hình.
Một agent chạy lâu nhưng để bạn làm việc khác có thể giảm công sức trực tiếp mà không giúp hoàn tất sớm hơn. Ngược lại, một agent trả lời rất nhanh có thể làm bạn ngắt việc liên tục. Đâu là phương án tốt hơn còn tùy điểm nghẽn: bạn cần giao hàng đúng giờ hay cần lấy lại một buổi tập trung?
Một phép so sánh giả định, làm đến nơi đến chốn
Giả sử một người vận hành blog cần chuẩn bị bản tổng hợp thay đổi hằng tuần. Làm thủ công mất 45 phút: đọc ghi chú, đối chiếu liên kết và viết lại phần hướng dẫn. Đây là tình huống minh họa, không phải số liệu đo từ một doanh nghiệp.
Với quy trình dùng agent thứ nhất, người đó mất 8 phút chuẩn bị dữ liệu, 6 phút giải thích trong quá trình chạy, 12 phút kiểm tra và 4 phút sửa. Tổng công sức trực tiếp là 30 phút. Máy chạy nền thêm 10 phút, nên thời gian hoàn tất theo đồng hồ có thể là 40 phút nếu các bước diễn ra nối tiếp. Lợi ích ở đây là 15 phút công sức và 5 phút hoàn tất sớm hơn.
Với quy trình thứ hai, thao tác giao việc chỉ mất 2 phút, nhưng đọc lại mất 25 phút và sửa mất 30 phút. Tổng công sức là 57 phút, còn chưa tính thời gian máy chạy. Một lời nhắc rất ngắn chưa tạo ra một quy trình hiệu quả. Phần việc bị đẩy sang cuối vẫn là công việc.
So sánh này cũng chưa tính chi phí xây quy trình ban đầu. Nếu cần hai giờ chuẩn bị bộ dữ liệu và biểu mẫu, lợi ích 15 phút mỗi lần cần nhiều lần sử dụng mới bù được công sức thiết lập. Một việc chỉ làm một lần có thể không đáng tự động hóa sâu đến vậy.
Chất lượng là điều kiện, không phải phần thưởng thêm
Hai phương án chỉ so được với nhau khi đạt cùng một chuẩn tối thiểu. Bản tổng hợp thiếu một thay đổi quan trọng không tương đương với bản đầy đủ, dù hoàn thành nhanh gấp đôi. Đo thời gian mà bỏ qua chất lượng sẽ tạo động lực làm ra những kết quả dễ hoàn tất nhưng khó sử dụng.
Một cách thực tế là xác định điều kiện đạt trước khi chạy. Chẳng hạn: mỗi thay đổi phải có nguồn đối chiếu; các liên kết còn mở được; hướng dẫn chỉ chứa bước đã kiểm tra; những điểm chưa chắc được đánh dấu. Người kiểm tra có thể quyết định đạt hay chưa đạt mà không cần dựa vào cảm giác văn bản trông chuyên nghiệp.
Với công việc có hậu quả lớn khi sai, điều kiện ấy cần nghiêm hơn và phần duyệt của người có trách nhiệm vẫn phải tồn tại. Tăng mức sử dụng mô hình không tự động giải quyết được vấn đề thiếu dữ liệu, thiếu tiêu chí hoặc thiếu người đủ hiểu để đánh giá.
Khi việc đo lường bắt đầu làm lệch mục tiêu
Một chỉ số thường trở nên nguy hiểm khi được dùng như mục tiêu duy nhất. Thưởng cho số tác vụ hoàn tất có thể khiến người ta chia nhỏ những việc dễ. Thưởng cho thời gian tiết kiệm tự báo cáo có thể khiến mốc thủ công bị ước lượng quá cao. Thưởng cho lượng token có thể biến tiêu thụ tài nguyên thành một biểu hiện của sự chăm chỉ.
Ta cũng dễ đánh giá quá cao một lần chạy đẹp. Một quy trình phục vụ mỗi tuần cần được xem qua nhiều loại đầu vào: tuần có ít thay đổi, tuần có dữ liệu thiếu, tuần tên sản phẩm bị viết không thống nhất. Ghi lại cả lần thất bại giúp biết phạm vi nào agent làm tốt và lúc nào cần quay về cách thủ công.
Điều nên tối ưu là một vòng công việc có thể lặp lại. Một kết quả ngoạn mục nhưng không giải thích được cách kiểm tra có thể kém hữu ích hơn một quy trình bình thường mà người khác tiếp quản được.
Một trang ghi chép cho lần thử tiếp theo
Chọn một việc bạn đã làm đủ quen để biết đầu ra đúng trông như thế nào. Ghi cách làm hiện tại, thời gian thực tế của một lần và tiêu chí nghiệm thu. Sau đó thử agent trên cùng phạm vi, với giới hạn rõ về thời gian và chi phí mà bạn chấp nhận cho lần thử.
Trong lúc làm, ghi các phút cần can thiệp và nguyên nhân. Cuối buổi, phân loại phần sửa: thiếu ngữ cảnh, sai dữ kiện, sai định dạng hay hiểu sai mục tiêu. Mỗi nhóm dẫn đến một thay đổi khác nhau. Thêm một câu vào lời nhắc có thể sửa định dạng; dữ liệu nguồn thiếu thì cần được bổ sung từ nơi khác.
Sau vài vòng, hãy hỏi một câu đơn giản: công việc này đã nhẹ đi ở chỗ nào, và phần nặng có chuyển sang một người khác hay một thời điểm khác không? Câu trả lời cụ thể sẽ giúp bạn chọn bước tiếp theo tốt hơn một con số tiêu thụ token đứng riêng lẻ.