Gần 10.000 phản hồi AI, cuộc kiểm toán khiến mình đổi cách vận hành

Khi mở log sử dụng AI, mình thấy 9.995 phản hồi riêng biệt trong kỳ kiểm toán bắt đầu từ 6 giờ sáng ngày 19 tháng 9 đến ngày 21 tháng 9.

Phản xạ đầu tiên của mình là đi tìm một câu lệnh quá dài, một model quá mạnh, hoặc một lỗi chạy lặp. Nhưng khi tách dữ liệu, mình nhận ra vấn đề không nằm ở một câu trả lời nào cả.

Nó nằm ở cách cả hệ thống vận hành.

Tổng lượng context được đưa qua các lượt xử lý là hơn 2,91 tỷ đơn vị input.

Con số lớn nhất lại là thứ dễ bị hiểu sai nhất: 97,8% input là cache read.

Cache read không có nghĩa là 97,8% bị lãng phí. Nó cũng không có nghĩa là hệ thống đã tối ưu. Cache giúp xử lý phần ngữ cảnh cũ hiệu quả hơn, nhưng mỗi lượt gọi mới vẫn đang mang theo một cuộc hội thoại ngày càng dài.

Vì vậy, mình ngừng hỏi: “Câu trả lời nào tốn nhất?”

Mình chuyển sang hỏi: “Vì sao hệ thống cần gọi AI nhiều lần đến vậy?”

Ba con số cho mình ba dấu hiệu

Khi tách dữ liệu ra, mình thấy ba dấu hiệu rõ hơn nhiều so với tổng token.

Thứ nhất, agent phụ tạo ra 4.493 phản hồi, chiếm 45% tổng số lượt, nhưng chỉ tạo 6,7% lượng output. Đây là dấu hiệu phần phối hợp có thể đang lớn hơn giá trị đầu ra mà nó tạo ra.

Thứ hai, có 715 phản hồi được tạo khi context của phiên đã vượt 60%. Ở giai đoạn này, mỗi lượt gọi tiếp theo phải mang theo quá nhiều lịch sử cũ.

Thứ ba, một phiên theo dõi website chạy hơn 14 giờ, tạo 583 phản hồi và chiếm khoảng 9,6% toàn bộ input quan sát được. Công việc của nó chủ yếu là chờ thay đổi, nhưng hệ thống lại dùng model để tiếp tục theo dõi.

Ba con số này tạo thành một giả thuyết mình cần kiểm tra: hệ thống có thể đang gọi AI quá nhiều lần cho những việc có thể xử lý bằng quy trình hoặc script thông thường.

Luật 1: Tách người nghĩ khỏi người làm

Trước đây, một AI có thể vừa lập kế hoạch, vừa thực thi, vừa tự kiểm tra chính nó. Cách này tiện lúc đầu, nhưng rất dễ tạo vòng lặp: đọc lại yêu cầu, làm một phần, báo cáo, đọc lại, sửa tiếp, rồi tự review.

Bây giờ mình chia vai rõ. Đây là cách mình vận hành trong bối cảnh tài khoản và khối lượng công việc của mình, chưa phải công thức đúng cho mọi đội.

Claude chỉ phản biện, điều phối, giám sát và đảm bảo chất lượng.

Codex thực thi toàn bộ: nghiên cứu phục vụ đầu ra, viết nội dung, sửa mã, chạy test, triển khai và kiểm tra live.

Trong quy trình mới, mỗi việc chỉ có một brief đầu vào và một vòng QA đầu ra. Phần thực thi ở giữa không được quay về Claude để hỏi từng bước nhỏ.

Mục tiêu của việc chia vai không phải là chọn AI nào “giỏi hơn”. Mục tiêu là tránh trả nhiều lần cho cùng một phần bối cảnh.

Luật 2: Chọn model theo ba yếu tố, không theo thói quen

Mỗi phiên, hệ thống phải chốt model và mức suy luận dựa trên ba câu hỏi.

Một, chất lượng cần tới đâu? Việc có rủi ro cao, kiến trúc phức tạp hoặc cần quyết định khó thì dùng model mạnh. Việc cơ học, có tiêu chí rõ thì dùng model vừa đủ.

Hai, hạn mức thực tế còn bao nhiêu? Không được đoán một model còn nhiều quota chỉ vì tên nó vẫn xuất hiện trong danh sách.

Ba, tổng chi phí hoàn thành là bao nhiêu? Model rẻ nhưng làm sai ba lần có thể đắt hơn model mạnh làm đúng một lần. Chi phí phải gồm cả sửa sai và review.

Trước khi nghĩ tới chuyện mua thêm, hệ thống phải kiểm tra xem nhóm hạn mức khác đang có sẵn có đáp ứng được chất lượng hay không.

Luật 3: Một phiên chỉ có một mục tiêu chính

Phiên càng dài, context càng nặng. Nếu vừa sửa sản phẩm, vừa viết tài liệu, vừa điều tra log trong cùng một cuộc hội thoại, mọi lượt gọi sau đều phải kéo theo những phần không còn liên quan.

Mình đặt hai mốc:

40% context là mốc chuẩn bị. Bắt đầu đóng gói kết quả, bỏ log thừa và chuẩn bị bàn giao.

60% context là mốc dừng. Dừng ở điểm an toàn, mở phiên mới bằng một bản bàn giao ngắn.

Bản bàn giao chỉ cần mục tiêu, trạng thái hiện tại, quyết định đã chốt, file liên quan, kiểm tra đã chạy và việc tiếp theo. Không cần chép lại toàn bộ cuộc trò chuyện.

Luật 4: Monitor phải là script, không phải một cuộc trò chuyện kéo dài

Nếu việc chỉ cần kiểm tra “đã thay đổi chưa”, “đã xong chưa” hoặc “có lỗi mới không”, mình dùng script hoặc lịch chạy tự động không cần AI suy luận.

Model chỉ được gọi khi có thay đổi đáng kể, có lỗi cần suy luận, hoặc cần một quyết định mới.

Sau khi thấy một phiên monitor tạo 583 phản hồi, mình quyết định thay đổi cách theo dõi này. Chờ đợi không phải là công việc cần trí tuệ ở mỗi nhịp.

Luật 5: Review một gói bằng chứng, không review từng mẩu

Người thực thi phải gom đủ bằng chứng trước khi gửi QA:

Phạm vi đã làm. Kết quả test. Diff hoặc file thay đổi. Rủi ro còn lại. Bằng chứng live nếu đã triển khai.

QA đọc một gói hoàn chỉnh và trả lời ĐẠT hoặc trả lại kèm lỗi cụ thể. Không mở nhiều vòng “xem giúp chỗ này” khi công việc chưa đủ dữ liệu để nghiệm thu.

Mình kỳ vọng cách này sẽ giảm token và thời gian chờ giữa hai hệ thống. Kết quả sẽ được đo sau một tuần.

Luật 6: Kiểm toán hàng tuần, nhưng không tự kể câu chuyện đẹp

Mỗi tuần, hệ thống phải đo lại ít nhất sáu thứ: tổng lượt gọi, input theo context, tỷ lệ cache read, số phiên vượt 40% và 60%, phần dùng bởi agent phụ, và các monitor dài.

Sau đó mới sửa luật.

Mình chưa công bố phần trăm tiết kiệm, vì bộ luật này vừa được lắp. Một tuần vận hành mới cho mình dữ liệu trước và sau đủ để đánh giá.

Nếu số lượt gọi giảm nhưng chất lượng đầu ra giảm theo, đó không phải tối ưu. Nếu token giảm nhưng phải sửa lại nhiều hơn, tổng chi phí vẫn tăng.

Tối ưu đúng phải giữ được ba thứ cùng lúc: chất lượng đầu ra, hạn mức còn lại và tổng chi phí hoàn thành.

Bạn có thể làm ngay hôm nay

Không cần xây cả hệ thống như mình. Bạn có thể bắt đầu bằng bốn việc nhỏ.

Đặt một mục tiêu cho mỗi phiên. Khi đổi loại việc, mở phiên khác.

Đặt mốc dừng cho context. Dùng 40% để chuẩn bị bàn giao và 60% để chuyển phiên.

Đổi monitor thành script. Chỉ gọi AI khi có thay đổi cần suy luận.

Ghi lại lý do mỗi lần retry. Nếu không có nguyên nhân mới hoặc phiên bản mới, đừng chạy lại cùng một việc.

Và đừng nhìn cache read rồi vội kết luận. Cache là một cơ chế kỹ thuật. Điều cần đo là hệ thống có tạo ra kết quả với số lượt gọi hợp lý hay không.

Điều mình đang chờ sau một tuần

Mình muốn thấy ít phiên vượt 60% context hơn, ít agent phụ hơn, không còn monitor hàng giờ trong phiên model, và số vòng review giảm xuống.

Nhưng mình chỉ giữ những luật không làm giảm chất lượng.

Đây là điểm khác nhau giữa “cắt token” và quản lý AI bằng số liệu. Cắt token chỉ nhìn vào số dùng. Quản lý bằng số liệu nhìn vào kết quả cuối cùng và toàn bộ chi phí để đi tới kết quả đó.

Bạn đang đo token của mình theo cách nào? Để lại một dòng bên dưới, mình muốn biết chỗ nào đang làm bạn tốn nhất.