Đánh đổi độ chính xác và độ trễ

"Nhanh hơn" và "đúng hơn" thường kéo về hai phía. Người kiến trúc sư phải chọn một điểm cân bằng cho từng khối việc, và quan trọng hơn, phải giải thích được vì sao chọn điểm đó bằng số liệu, không bằng cảm giác.

Bài này giúp bạn trả lời: có những đòn bẩy nào để đổi giữa độ chính xác và độ trễ, mỗi cái tác động vào đâu, và chứng minh cấu hình của mình ra sao?

Ví dụ xuyên suốt: chuỗi nhà hàng với hai khối việc

Một chuỗi nhà hàng dùng Claude cho hai việc:

1. Trợ lý đặt bàn qua giọng nói ở tổng đài: khách nói, hệ thống chuyển thành chữ, Claude trả lời, hệ thống đọc lên. Khách im lặng chờ quá hai giây là thấy khó chịu.
2. Báo cáo phản hồi khách hằng tuần: đọc vài nghìn đánh giá, gom vấn đề theo chi nhánh. Chạy ban đêm, không ai chờ, nhưng sai thì quản lý ra quyết định sai.

Trợ lý giọng nói hiện truy xuất 20 đoạn thực đơn và chính sách mỗi lượt, và đang chạy ở mức effort cao.

Đo loại độ trễ nào

Docs của Anthropic về giảm độ trễ phân biệt hai thước đo: độ trễ tổng (thời gian xử lý prompt và sinh xong câu trả lời) và thời gian tới chữ đầu tiên (time to first token, TTFT). Trang fast mode thêm thước đo thứ ba: tốc độ sinh chữ, tính bằng số token đầu ra mỗi giây.

Với trợ lý giọng nói, thứ khách cảm nhận là khoảng lặng trước khi nghe được câu đầu tiên, nên TTFT quan trọng nhất. Với báo cáo ban đêm, độ trễ gần như không quan trọng.

Đòn bẩy và cái giá

Effort: chỉnh trong cùng một model

Docs nói effort ảnh hưởng mọi token đầu ra: câu trả lời, lời gọi tool và tham số, và thinking nếu đang bật; vì vậy nó có tác dụng cả khi không bật thinking. Effort thấp thì ít lời gọi tool hơn, ít giải thích hơn. Các mức: low, medium, high, xhigh, max. Phần lớn model mặc định high; Opus 5.5 và Haiku 5.5 mặc định medium.

Docs gợi ý low cho việc đơn giản cần tốc độ và chi phí thấp nhất, như subagent; còn max thì trên đa số khối việc tăng chi phí đáng kể mà chất lượng chỉ nhích lên chút ít. Effort đặt ở output_config.effort. Lưu ý đổi effort giữa các yêu cầu làm mất prompt cache.

Bắt đầu từ đâu

Docs về giảm độ trễ khuyên làm prompt chạy tốt trước, khi chưa có ràng buộc về model hay độ dài, rồi mới áp các cách giảm độ trễ. Docs về chọn model khuyên chỉnh effort trước khi đổi model.

Áp vào trợ lý giọng nói:

1. Bật cache cho system prompt và chính sách nhà hàng (giống nhau mọi lượt).
2. Xem lại dữ liệu cũ: câu trả lời gần như luôn nằm trong vài đoạn đầu, nên giảm từ 20 đoạn xuống số đoạn thực tế đã đủ.
3. Hạ effort, rồi thử Haiku 5.5; bật streaming để phần đọc bắt đầu sớm.

Báo cáo ban đêm thì ngược lại: giữ effort cao, chọn model mạnh, và đưa vào Batch API vì không ai chờ.

Chứng minh cấu hình bằng số

Một cấu hình "nghe hợp lý" chưa đủ; phải đo trên bộ test của chính bạn.

• Quét effort: docs khuyên chạy lại một lượt quét các mức effort trên bộ đánh giá của mình mỗi khi đổi model, thay vì mang cấu hình cũ sang.
• So bằng chi phí trên mỗi việc xong, không bằng giá mỗi token. Docs về tối ưu chi phí còn nêu một cách: chạy mọi việc ở effort thấp, chỉ chạy lại các việc hỏng ở effort cao. Trong thử nghiệm của Anthropic, cách này rẻ hơn khoảng 40% so với chạy tất cả ở mức cao mà tỉ lệ đạt như nhau, với điều kiện có tín hiệu cho biết việc nào hỏng, và chấp nhận việc hỏng mất gấp đôi thời gian.
• Ghi lại lý do: cấu hình nào, đo trên bộ test nào, đạt độ chính xác bao nhiêu, độ trễ phân vị nào. Đó là thứ bạn đem ra khi phải giải thích với các bên liên quan (bài 6.2).