Tính chi phí AI: cả lượt gọi, thời gian chờ và công sửa

Demo chạy ngon, mỗi lần hỏi chỉ tốn một khoản nhỏ. Cả nhóm đồng ý đưa chatbot vào hỗ trợ khách. Đến cuối tháng, hóa đơn tăng mà nhân viên vẫn ngồi sửa câu trả lời. Câu hỏi lúc này không còn là “mỗi lượt giá bao nhiêu?”, mà là “mình trả tiền để giải quyết được bao nhiêu việc?”.

Đó là một tình huống giả định để bắt đầu cách tính chi phí AI. Muốn biết công cụ có đáng dùng, hãy tính tới lúc kết quả đạt yêu cầu. Ngoài tiền gọi mô hình, còn có tìm kiếm, chạy lại, hạ tầng và thời gian người kiểm tra.

Bài này dùng ví dụ bot trả lời chính sách đổi hàng. Bạn có thể thay bằng việc của nhóm mình, nhưng cần giữ một nguyên tắc: so chi phí trên cùng chất lượng đầu ra, thay vì chỉ nhìn đơn giá thấp nhất.

Token là đơn vị xử lý, không phải số từ

Token là đơn vị mô hình dùng để xử lý nội dung. Với văn bản, một token có thể ứng với một phần từ hoặc dấu câu. Đừng lấy số từ trong tài liệu rồi coi đó là số token sẽ tính phí.

Với bot đổi hàng, đầu vào không chỉ có câu “mua tuần trước có đổi được không?”. Nó có thể gồm hướng dẫn hệ thống, lịch sử chat và các đoạn chính sách được tìm thấy. Câu khách hỏi ngắn, nhưng phần gửi cho mô hình vẫn dài.

Đầu ra cũng cần theo dõi riêng. Nếu nhân viên chỉ cần điều kiện đổi hàng và đường dẫn chính sách, một bài giải thích dài có thể chẳng giúp thêm. Yêu cầu trả lời vừa đủ sẽ dễ đọc và dễ kiểm tra hơn.

Nếu dùng Claude, tài liệu đếm token của Anthropic hướng dẫn ước lượng đầu vào trước khi gửi. Khi lập dự toán, nên đo bằng công cụ phù hợp với mô hình, rồi đối chiếu số sử dụng thực tế. Đừng lấy kết quả của mô hình khác thay vào mà không kiểm tra.

Trong bảng tính, ghi tên mô hình, ngày xem giá và đơn vị tính. Tách đầu vào, đầu ra và các loại phí khác theo bảng giá đang áp dụng. Một con số không kèm điều kiện rất dễ bị dùng sai khi nhóm đổi cấu hình.

Tính cả các bước ngoài lời nhắc

Hãy đi theo một yêu cầu từ đầu đến cuối. Khách hỏi đổi hàng. Ứng dụng tìm chính sách, đưa đoạn liên quan cho mô hình, nhận bản nháp rồi kiểm tra định dạng. Nếu thiếu nguồn, nó có thể tìm lại và gọi thêm lần nữa.

Chỉ ghi lượt trả lời cuối sẽ bỏ sót phần đã chạy trước đó. Vì vậy, mỗi yêu cầu nên có mã theo dõi để cộng được các lượt xử lý liên quan. Không cần lưu toàn bộ nội dung riêng tư của khách để biết đã gọi bao nhiêu lần.

Tạo vài cột dễ hiểu: lượt gọi mô hình, phí tìm kiếm, số lần thử lại và phút nhân viên sửa. Phần hạ tầng dùng chung nên ghi riêng, rồi nêu rõ cách phân bổ nếu cần tính cho từng yêu cầu.

Ví dụ bot tìm nhầm chính sách cũ, gọi lại ba lần vẫn không khá hơn. Khoản tốn thêm ở đây không được giải quyết bằng một prompt hay hơn mãi mãi. Nhóm cần sửa nguồn dữ liệu và điều kiện dừng khi không tìm được căn cứ.

Cũng phân biệt chi phí thiết lập với chi phí vận hành. Dọn tài liệu ban đầu có thể mất nhiều công, nhưng không phát sinh y hệt mỗi tháng. Gộp hai khoản vào một số rồi nhân lên cả năm sẽ làm dự toán méo đi.

Độ trễ cũng có giá

Trong lúc chờ bot, nhân viên mở chính sách tự tìm. Bot trả lời xong thì người đã xử lý gần hết. Hệ thống có thể chạy đúng, nhưng lợi ích thực tế thấp vì kết quả đến muộn so với lúc cần.

Đo từ lúc gửi yêu cầu tới khi có câu trả lời dùng được. Nếu màn hình hiện chữ ngay nhưng phải đợi lâu mới có nguồn, đừng coi ký tự đầu tiên là lúc công việc đã xong. Hai mốc này phục vụ hai câu hỏi khác nhau.

Thử cả giờ nhiều người dùng, câu hỏi dài và trường hợp cần tìm lại. Một lượt demo suôn sẻ chưa cho thấy nhân viên sẽ chờ bao lâu trong ca bận. Ghi những lượt chậm bất thường để tìm bước đang giữ cả quy trình lại.

Không nhất thiết quy đổi mọi giây chờ thành tiền lương. Nếu nhân viên vẫn làm việc khác được, ảnh hưởng khác với việc họ phải đứng chờ trên màn hình. Hãy quan sát cách dùng thật rồi mới quyết định nên tính thời gian ấy thế nào.

Với yêu cầu kéo dài, thông báo rõ hệ thống đang xử lý và cho người dùng một đường tiếp tục phù hợp. Chẳng hạn, mở chính sách gốc hoặc chuyển nhân viên phụ trách. Đừng để họ bấm gửi lại vì tưởng ứng dụng bị treo.

Tính chi phí đến lúc kết quả dùng được

Trước khi thử hai phương án, thống nhất thế nào là đạt. Với bot đổi hàng, câu trả lời cần đúng chính sách hiện hành, nêu điều kiện liên quan và có nguồn để nhân viên kiểm. Câu văn mượt nhưng sai thời hạn vẫn tính là chưa đạt.

Lấy một bộ câu hỏi đại diện, gồm cả ca dễ và ca thiếu thông tin. Chạy các phương án trên cùng bộ ấy. Người chấm dùng cùng tiêu chí, đồng thời ghi thời gian sửa. Như vậy, nhóm mới biết khoản tiền thêm có đổi lấy kết quả tốt hơn không.

Giả sử phương án A tốn 100 đơn vị chi phí cho 80 kết quả đạt. Phương án B tốn 120 cho 100 kết quả đạt. Đây là số minh họa: A tốn 1,25 đơn vị trên mỗi kết quả đạt, B tốn 1,2. Đơn giá ban đầu thấp hơn chưa đủ để chọn A.

Phép chia ấy cần dùng tổng chi phí theo phạm vi đã thống nhất, kể cả các lần thất bại. Nếu đã đưa công rà soát vào tổng, đừng cộng lại lần nữa. Cũng cần tách lỗi nghiêm trọng khỏi lỗi trình bày; một câu trả lời sai chính sách không thể được bù bằng nhiều câu đúng chính tả.

Cách giảm chi phí mà không làm giảm chất lượng

Bắt đầu từ khoản gây tốn nhất trong dữ liệu đo được. Nếu đầu vào quá dài, chọn đúng đoạn chính sách liên quan. Nếu phải sửa nhiều vì câu trả lời lan man, yêu cầu định dạng ngắn hơn. Nếu lỗi do tài liệu cũ, cập nhật tài liệu trước.

Mỗi lần chỉ đổi vài yếu tố đủ để biết nguyên nhân. Sau khi rút ngắn prompt, chạy lại bộ câu hỏi cũ và xem có bỏ sót điều kiện nào không. Tiết kiệm tiền nhưng làm sai thêm thì chưa phải cải thiện.

Đặt giới hạn lượt thử lại, mức sử dụng và cảnh báo phù hợp với công việc. Khi chạm giới hạn, hệ thống cần biết dừng ở đâu và chuyển cho ai, thay vì tiếp tục chạy mà không tạo thêm giá trị.

Cuối cùng, giữ một bảng theo dõi nhỏ: tổng chi phí, số kết quả đạt và công người sửa. Ba số này giúp nhóm quyết định mở rộng hay chỉnh lại quy trình. Mục tiêu là giải quyết việc với chi phí hợp lý, không phải có hóa đơn token thấp nhất bằng mọi giá.