AI Waste: 9 Lãng Phí Khi Dùng AI Và Cách Cắt Lãng Phí Token

1. Đặt lại vấn đề

Trong sản xuất tinh gọn, lãng phí là mọi hoạt động tiêu tốn nguồn lực mà khách hàng không sẵn sàng trả tiền cho nó. Chuyển sang AI, định nghĩa gần như giữ nguyên.

Có một lý do thực tế để bắt đầu từ lãng phí thay vì từ năng suất: cảm nhận về hiệu quả AI không đáng tin.

Thử nghiệm ngẫu nhiên có đối chứng của METR (7/2025) trên 16 lập trình viên giàu kinh nghiệm với 246 task thật cho thấy khi được dùng AI họ chậm hơn 19%, trong khi trước đó dự đoán nhanh hơn 24% và sau khi làm xong vẫn tin mình nhanh hơn 20%. Khoảng cách 39 điểm giữa cảm nhận và thực đo mới là phần đáng giá, không phải con số 19%.

Hai con số vừa nêu cần được đọc đúng giới hạn của chúng.

• Tháng 2/2026, METR công bố thay đổi thiết kế nghiên cứu, cho biết dữ liệu vòng sau có dấu hiệu tăng tốc nhưng bị nhiễu nặng bởi hiệu ứng chọn mẫu. Vì vậy con số 19% không đủ để kết luận "AI làm chậm người". Nó chỉ đủ cho một kết luận: tự đánh giá năng suất AI có thể sai rất xa mà vẫn rất tự tin.
• Con số khoảng 95% pilot GenAI không tạo tác động đo được lên P&L, trong báo cáo sơ bộ "The GenAI Divide" của MIT Project NANDA (7/2025), bị trích dẫn sai rất nhiều. Đây là báo cáo chưa bình duyệt, dựa trên 52 phỏng vấn, khảo sát 153 lãnh đạo và 300 triển khai công khai, với định nghĩa thành công rất hẹp: có ROI đo được trong 6 tháng sau pilot. Phần đáng dùng của báo cáo không phải con số 95%, mà là kết luận rằng nguyên nhân nằm ở tích hợp và quy trình chứ không ở chất lượng mô hình.

Điểm chung của cả hai nguồn là không nguồn nào nói về prompt, nhưng cả hai cùng chỉ về một hướng. Nếu vấn đề nằm ở quy trình, và nếu cảm nhận về hiệu quả không đáng tin, thì lãng phí phải được tìm ngay trong cách làm việc hàng ngày với AI. Đó là nội dung phần còn lại.

2. Nguyên lý xuyên suốt: token có định hướng và token vô định hướng

Phần sau của bài có hai lời khuyên thoạt nhìn ngược nhau: một mặt cắt bớt ngữ cảnh, mặt khác lại viết prompt dài hơn. Chúng không mâu thuẫn, vì cùng phục vụ một nguyên lý:

Một câu ràng buộc "độ dài 600 từ, giọng trung tính, không dùng câu cảm thán" tốn khoảng 20 token và loại bỏ hàng nghìn phiên bản đầu ra sai hướng. Đó là token có định hướng. Bốn mươi trang hợp đồng đính kèm để hỏi một điều khoản tốn hàng chục nghìn token và không loại bỏ gì cả, thậm chí làm loãng chú ý của mô hình. Đó là token vô định hướng.

Mọi phương pháp ở phần 4 đều là hệ quả của nguyên lý này.

3. Framework: 9 lãng phí khi dùng AI

Tôi xếp 9 loại theo chuỗi nhân quả chứ không theo vị trí quan sát, vì lãng phí ở nhóm sau hầu như luôn có gốc ở nhóm trước.

Nhóm A: Lãng phí gốc, nằm ở người đặt yêu cầu

W1. Mơ hồ (Ambiguity). Yêu cầu không nêu mục tiêu, đối tượng, ràng buộc, định dạng, tiêu chí chấp nhận. AI buộc phải đoán. Ví dụ: "Viết bài giới thiệu dịch vụ" rồi sửa qua 5 lượt.

W2. Sai bài toán (Misapplication). Dùng AI cho việc mà công cụ tất định làm nhanh hơn và chắc chắn hơn. Ví dụ: hỏi AI tổng doanh thu 12 tháng trong khi file Excel đã có sẵn công thức SUM.

W3. Tái phát minh (Reinvention). Không có chuẩn, nên mỗi người và mỗi lần đều tự nghĩ lại prompt từ đầu. Ví dụ: năm người trong nhóm tự viết năm prompt khác nhau cho cùng việc tóm tắt biên bản họp, chất lượng chênh nhau và không ai học được từ ai.

Nhóm B: Lãng phí trong vận hành, nơi tiêu tiền

W4. Ngữ cảnh thừa (Context Bloat). Nạp dữ liệu theo tâm lý cho chắc. Tốn token và làm giảm chất lượng. Ví dụ: đính cả thư mục 40 tài liệu để hỏi một chi tiết nằm ở một tài liệu.

W5. Xử lý quá mức (Over-processing). Sai tầng model, sai chế độ gọi. Trả tiền cho năng lực không dùng đến. Ví dụ: dùng model mạnh nhất kèm suy luận sâu để đổi định dạng ngày tháng trong 200 dòng.

W6. Vòng lặp làm lại (Rework Loop). Chuỗi sửa qua sửa lại. Đây là nơi lãng phí token hiện hình rõ nhất, phân tích kỹ ở phần 4.

Nhóm C: Lãng phí ở đầu ra và con người, nơi mất giá trị

W7. Lỗi phải sửa và lỗi lọt lưới (Defect & Verification Gap). Hai mặt của một vấn đề. Lỗi bị bắt thì tốn công sửa. Lỗi không bị bắt thì đi vào quyết định. Ví dụ: AI đưa quy mô thị trường kèm tên nguồn nghe rất thật, không ai kiểm, con số đi thẳng vào slide gọi vốn.

W8. Sản xuất thừa (Overproduction). Sinh nhiều hơn năng lực review, duyệt và dùng của tổ chức. Ví dụ: sinh 30 bài blog trong một buổi, đăng được 4, 26 bài còn lại thành tồn kho không ai đụng tới nhưng vẫn tốn công đọc lướt.

W9. Trung chuyển thủ công (Manual Handoff). Người trở thành đường ống dẫn dữ liệu giữa AI và các hệ thống khác. Ví dụ: copy từ chat sang Excel, định dạng lại, dán sang email, cập nhật CRM, lặp 20 lần một ngày.

Đối chiếu với 9 lãng phí kinh điển

Hai ghi chú về bảng này:

Vì sao bỏ Waiting. Chờ chỉ là lãng phí khi người bị khóa chờ. Trong phần lớn trường hợp, chờ là triệu chứng của W5 và W6 chứ không phải nguyên nhân độc lập. Giữ nó lại làm loãng framework.

Điểm khác biệt cốt lõi so với sản xuất. Trong nhà máy, phế phẩm thường lộ ra khi kiểm. Với AI, đầu ra sai vẫn trông hợp lý, đúng ngữ pháp, đúng cấu trúc, thậm chí có trích dẫn. Vì vậy chi phí kiểm tra cao hơn nhiều và không thể dựa vào kiểm tra để thay cho phòng ngừa. Đây là lý do W1 phải được xử lý trước W7.

Cách tiếp cận này là phần mở rộng của tư duy loại bỏ lãng phí trong sản xuất tinh gọn. Xem thêm Loại bỏ 7 lãng phí trong sản xuất tinh gọn.

Ngoài phạm vi bài này

Chín loại trên là lãng phí ở cấp tác vụ. Còn hai loại ở cấp danh mục mà tôi không đưa vào để giữ framework thuần nhất, nhưng đáng đo riêng: tồn kho công cụ (mua sáu gói AI, thực dùng hai) và rủi ro dữ liệu do dùng công cụ ngoài luồng.

4. Đi sâu: lãng phí token

Tôi chọn lãng phí token vì nó là loại duy nhất đo được chính xác, tự động, và là chỉ báo sớm của các lãng phí khác. W1 không tự nó tốn gì. Nó tốn thông qua W6.

4.1 Token quy ra cái gì

Phải phân biệt, nếu không toàn bộ lập luận về chi phí sẽ sai đối tượng:

• Dùng qua API: token quy thẳng ra tiền trên hóa đơn.
• Dùng qua gói thuê bao: token không quy ra tiền. Nó quy ra hạn mức sử dụng và thời gian của người. Đây mới là chi phí thật với phần lớn người dùng doanh nghiệp.

Trong cả hai trường hợp, chi phí đắt nhất vẫn là giờ công. Token chỉ là thứ đo được dễ nhất, nên dùng nó làm proxy.

4.2 Bốn cơ chế làm prompt mơ hồ đắt hơn cảm nhận

Chi phí lũy tiến theo hình tam giác. Mỗi lượt hỏi mới gửi lại toàn bộ lịch sử trước đó làm đầu vào. Lượt thứ năm đắt gấp nhiều lần lượt đầu dù câu hỏi chỉ dài một dòng.

Vòng xoáy tự tăng cường. Càng sửa nhiều, ngữ cảnh càng dài, thông tin quan trọng càng bị đẩy vào vùng giữa. Nghiên cứu Liu et al. về hiện tượng lost in the middle cho thấy độ chính xác theo hình chữ U và giảm hơn 30% khi thông tin cần thiết nằm ở giữa ngữ cảnh. Cần nói rõ: kết quả này đo trên tác vụ hỏi đáp đa tài liệu và truy hồi key-value, không phải mọi loại tác vụ. Nhưng cơ chế thì áp dụng chung, và nó lý giải vì sao một cuộc chat 30 lượt thường tệ hơn một cuộc chat 3 lượt được chuẩn bị kỹ.

Đầu ra mặc định luôn dài. Không nêu giới hạn thì mô hình trả về theo độ dài mặc định của nó. Token đầu ra thường có đơn giá cao hơn đầu vào.

Chi phí kiểm chứng. Đầu ra không có tiêu chí thì người đọc phải đọc hết mới biết dùng được hay không.

4.3 Ví dụ tính toán và các giới hạn của nó

Đây là ví dụ giả định để minh họa cơ chế, không phải số đo thực tế.

Kịch bản A, prompt mơ hồ. Giả định: prompt gốc 300 token, mỗi lượt sửa thêm 100 token, mỗi đầu ra 800 token, mất 5 lượt.

Tổng 14.500 token. Token tiêu từ lượt 2 trở đi là 13.400, tức 92% tổng token là làm lại.

Kịch bản B, prompt đầy đủ. Prompt 600 token, dài gấp đôi, nêu rõ đối tượng đọc, mục tiêu, ba thông điệp, giọng văn, độ dài, cấu trúc, tiêu chí chấp nhận. Giả định mất 2 lượt.

Tổng 3.280 token. Chênh lệch khoảng 4,4 lần.

Ví dụ này có bốn giới hạn cần nói rõ:

1. Toàn bộ kết quả nằm ở giả định 5 lượt so với 2 lượt. Đây là giả định, không phải số đo. Muốn dùng ví dụ này để thuyết phục ai, hãy thay bằng số đo của chính bạn, nếu không nó chỉ là số học vòng tròn.
2. Ví dụ cộng token đầu vào và đầu ra như nhau. Nếu tính theo đơn giá thật, với đầu ra đắt hơn đầu vào khoảng 5 lần, tỷ lệ chênh còn khoảng 3,8 lần. Vẫn cùng bậc độ lớn, nhưng không nên nói "4 lần" như một con số chắc chắn.
3. Nếu nền tảng có cache phần đầu hội thoại thì tam giác xẹp đi rất nhiều, chênh lệch có thể chỉ còn dưới hai lần. Tuy nhiên cache có thời hạn ngắn và mất hiệu lực khi nội dung phía trước bị sửa, mà sửa nội dung phía trước lại chính là việc vòng lặp làm lại hay làm. Quan trọng hơn: cache không cứu được ba lượt đọc và ba lần thất vọng của người.
4. Kết luận "prompt dài hơn thì rẻ hơn" chỉ đúng có điều kiện. Xem ngưỡng ngay dưới đây.

4.4 Ngưỡng hoàn vốn của việc viết prompt kỹ

Viết prompt kỹ tốn thời gian. Nó hoàn vốn khi thỏa ít nhất một trong ba điều kiện:

• Kỳ vọng phải sửa từ hai lượt trở lên.
• Tác vụ sẽ lặp lại nhiều lần, prompt trở thành mẫu dùng chung.
• Đầu ra đi ra ngoài, tức chi phí sai cao hơn chi phí sửa.

Ngược lại, với một câu tra cứu dùng một lần, prompt kỹ chính là W5 xử lý quá mức. Đừng áp dụng đại trà.

4.5 Ba chỉ số nên đo, và giới hạn của chúng

1. Số lượt tới khi đạt. Rẻ nhất, lấy được tự động từ lịch sử hội thoại, không cần ai chấm điểm. Nên là chỉ số chính.
2. Tỷ lệ token làm lại. Token từ lượt 2 trở đi chia tổng token. Tính được từ log, phản ánh trực tiếp lãng phí W6.
3. Tỷ lệ đạt ngay lần đầu. Ý nghĩa nhất nhưng đắt nhất, vì phải có người phán "đạt hay không đạt". Nếu bản thân việc đo tốn hơn cái tiết kiệm được thì chính nó là lãng phí. Chỉ đo trên mẫu, theo đợt, không đo liên tục.

5. Mười phương pháp giảm lãng phí token

Xếp theo ROI. Mỗi phương pháp kèm điều kiện không nên dùng.

1. Chuẩn hóa prompt theo sáu khối. Vai trò và bối cảnh, mục tiêu, đầu vào, ràng buộc, định dạng đầu ra, tiêu chí chấp nhận. Khối thứ sáu hay bị bỏ nhất và tiết kiệm nhất. Không viết được tiêu chí chấp nhận nghĩa là chính bạn chưa rõ mình muốn gì. Không dùng khi: tra cứu một lần, dùng xong bỏ.

2. Làm mẫu nhỏ trước khi chạy toàn bộ. Cần 20 bài thì duyệt 1 bài mẫu trước. Đây là mẫu đầu chuyền. Cắt lãng phí lớn nhất khi làm theo lô. Không dùng khi: các phần tử trong lô khác nhau hoàn toàn, mẫu không đại diện.

3. Ràng buộc đầu ra bằng con số. Số từ, số mục, số phương án, định dạng. Chỗ nào bỏ trống là chỗ đó chạy theo mặc định dài. Không dùng khi: đang cần khám phá, chưa biết hình dạng đầu ra.

4. Đưa ví dụ thay vì mô tả. Một đoạn mẫu 100 từ đúng ý truyền đạt nhiều hơn 500 từ giải thích về giọng văn. Không dùng khi: ví dụ có thể khiến đầu ra bắt chước quá sát và mất tính mới.

5. Hỏi làm rõ trước khi làm. Thêm: "Trước khi thực hiện, liệt kê tối đa 5 câu hỏi cần làm rõ, đừng viết gì thêm." Không dùng khi: tác vụ đơn giản. Nó tốn thêm một lượt, chỉ đáng khi bạn dự đoán sẽ mất từ ba lượt trở lên.

6. Cắt hội thoại, mở chat mới khi đổi việc. Dán lại kết luận đã chốt thay vì kéo lịch sử. Vừa cắt chi phí tam giác vừa tránh loãng ngữ cảnh. Không dùng khi: mạch việc thật sự liên tục và bối cảnh trước đó còn cần.

7. Xây thư viện prompt có biến số. Prompt nào đã đạt thì lưu thành mẫu có ô trống thay được. Đây là chuẩn hóa công việc. Không có thư viện thì mỗi người tự trả học phí riêng cho cùng một bài học. Không dùng khi: chưa có prompt nào chạy ổn định. Đừng chuẩn hóa cái chưa đúng.

8. Chỉ nạp phần tài liệu thật sự cần. Trích đoạn thay vì đính cả file. Giảm token và tăng độ chính xác. Không dùng khi: chưa biết thông tin nằm ở đâu, khi đó phải nạp rộng rồi thu hẹp ở lượt sau.

9. Đưa nội dung tĩnh lên đầu, nội dung động xuống cuối. Với ứng dụng qua API, prompt caching tái dùng phần đầu vào cố định. Anthropic công bố mức giảm chi phí tới 90% và giảm độ trễ tới 85% với prompt dài; AWS công bố con số tương đương cho prompt caching trên Amazon Bedrock. Điều kiện là phần tĩnh phải nằm ổn định ở đầu. Không dùng khi: dùng qua giao diện chat thông thường, bạn không kiểm soát được cache.

10. Chọn đúng tầng model và đúng chế độ gọi. Việc đơn giản khối lượng lớn dùng model nhỏ. Việc không cần thời gian thực chạy theo lô; Anthropic áp mức giảm 50% cho Batch API và mức này cộng dồn với prompt caching. Không dùng khi: cần phản hồi tức thời hoặc chất lượng là ràng buộc cứng.

6. Triển khai trong tổ chức

Bốn bước, không cần dự án lớn:

1. Đo cơ sở. Chọn 10 tác vụ AI lặp lại nhiều nhất. Ghi số lượt tới khi đạt trong một tuần.
2. Chuẩn hóa. Mỗi tác vụ một prompt mẫu theo sáu khối, bắt buộc có tiêu chí chấp nhận.
3. Đo lại. Sau hai tuần so sánh số lượt tới khi đạt, kèm một lần kiểm mẫu chất lượng để chắc chắn không phải do hạ tiêu chuẩn.
4. Cố định và nhân rộng. Prompt cải thiện thì đưa vào thư viện dùng chung, kèm ghi chú trường hợp không nên dùng.

Nguyên tắc cuối: lãng phí token là triệu chứng, không phải bệnh. Bệnh là sự mơ hồ trong chính yêu cầu. Không model nào đủ mạnh để bù cho việc người dùng chưa biết mình muốn gì.

Tự chấm: nhóm bạn đang lãng phí token cỡ nào

Câu hỏi mang tính tự rà soát, ánh xạ trực tiếp từ 9 lãng phí trong bài. Kết quả chỉ để tham khảo cho việc lập kế hoạch nội bộ.

Nguồn tham khảo

Ghi chú về số liệu trong bài: mọi con số trích dẫn đều kèm nguồn và phạm vi đo. Mọi con số trong ví dụ tính toán ở mục 4.3 là giả định minh họa, không phải số đo thực tế. Sơ đồ lost in the middle là minh hoạ cơ chế theo hình chữ U, không phải số đo cụ thể của nghiên cứu.