Thử nghiệm của một nhà phát triển độc lập với ba mô hình Claude đã cắt giảm 35% chi phí API hàng tháng và giảm độ trễ tác vụ trung vị từ 42 giây xuống còn 27 giây. Bằng cách điều hướng các công việc đơn giản, ít mơ hồ đến mô hình Haiku giá rẻ, các công việc định kỳ đến Sonnet, và dành riêng mô hình Opus nặng ký cho các vấn đề quan trọng, tác giả đã chứng minh rằng thói quen “dùng mô hình tốt nhất cho mọi thứ” là một sự lãng phí tốn kém.

Tại sao việc điều hướng lại quan trọng

Tác giả vận hành một tác nhân lập trình tự trị (autonomous coding agent) nhận được một luồng công việc phát triển liên tục—từ sửa lỗi lint, thêm tính năng, đánh giá bảo mật cho đến các phiên gỡ lỗi chuyên sâu. Trong nhiều tháng, tác nhân này đã gửi mọi yêu cầu đến Opus, mô hình Claude mạnh mẽ nhất, với giả định rằng chất lượng cao hơn sẽ luôn bù đắp được chi phí. Tuy nhiên, Opus có mức giá cao hơn trên mỗi token, khiến hóa đơn tăng lên không kiểm soát.

Khi tác giả áp dụng sơ đồ điều hướng phân tầng, chi phí đã giảm xuống còn 65% so với mức ban đầu và mức sử dụng Opus giảm xuống chỉ còn 11% tổng số tác vụ.

Cách thức hoạt động của hệ thống ba tầng

Logic điều hướng dựa trên tính mơ hồ (ambiguity), chứ không dựa trên số lượng dòng code mà một tác vụ tác động đến. Tác giả đã chia thành ba nhóm:

  • Haiku – các công việc ít mơ hồ, có tính xác định. Ví dụ: sửa các cảnh báo lint, đổi tên biến, tóm tắt các tệp nhật ký (log files). Câu trả lời đúng thường chỉ là một dòng code hoặc văn bản duy nhất.
  • Sonnet – công cụ chủ lực mặc định. Xử lý việc triển khai tính năng, sửa lỗi định kỳ và tái cấu trúc (refactor) tiêu chuẩn, nơi vấn đề đã rõ ràng nhưng giải pháp có thể bao gồm nhiều bước.
  • Opus – các công việc quan trọng và có độ mơ hồ cao. Các quyết định về kiến trúc, kiểm tra bảo mật, các phiên gỡ lỗi phức tạp, hoặc bất kỳ tác vụ nào mà lộ trình đúng đắn chưa rõ ràng và một sai sót nhỏ cũng có thể làm hỏng toàn bộ quy trình (pipeline).

Một bảng tra cứu tĩnh sẽ ánh xạ mỗi yêu cầu đến mô hình phù hợp dựa trên các quy tắc này. Tác giả đã thử nghiệm một mô hình "thông minh" để tự quyết định tầng ngay lập tức, nhưng lượng token tiêu thụ thêm đã xóa sạch mọi khoản tiết kiệm được. Các quy tắc tĩnh đơn giản đã bao quát được khoảng 80% khối lượng công việc, giúp hệ thống vừa rẻ vừa dễ dự đoán.

Lưới an toàn chuyển cấp

Các mô hình giá rẻ vẫn có thể mắc lỗi. Để ngăn chặn một phản hồi sai sót từ Haiku hoặc Sonnet làm hỏng quá trình build, hệ thống sẽ chuyển cấp (escalate) một yêu cầu sau hai lần thất bại, đẩy nó lên tầng tiếp theo. Lưới an toàn này giúp phát hiện lỗi sớm và giữ cho quy trình vận hành trơn tru mà không cần sự can thiệp thủ công.

Những con số biết nói

Sau bốn tuần vận hành bộ điều hướng phân tầng, tác giả đã ghi nhận những thay đổi sau:

  • Chi phí API giảm xuống còn 65% so với chi phí ban đầu (giảm 35%).
  • Thời gian hoàn thành trung vị giảm từ 42 giây xuống còn 27 giây.
  • Mức sử dụng Opus giảm từ việc xử lý mọi yêu cầu xuống chỉ còn 11% tổng số tác vụ.

Những con số này cho thấy hầu hết các công việc phát triển có thể được giao cho các mô hình rẻ hơn mà không làm giảm chất lượng đáng kể, trong khi các vấn đề khó nhất vẫn được hưởng lợi từ cửa sổ ngữ cảnh (context window) lớn hơn của Opus.

Bài học cho các nhà phát triển khác

  1. Bắt đầu từ mức thấp, đừng bắt đầu từ mức cao. Hầu hết các công việc lập trình hàng ngày không cần đến mô hình mạnh mẽ nhất. Việc đặt Sonnet làm mặc định cho các tác vụ mơ hồ đã tiết kiệm được nhiều tiền hơn so với việc đẩy mọi thứ qua Haiku.
  2. Đo lường độ khó, không phải kích thước. Một lỗi race condition chỉ cần một dòng để sửa có thể khó hơn cả việc tái cấu trúc cả một tệp tin. Hãy điều hướng dựa trên mức độ mơ hồ của giải pháp, chứ không phải dựa trên số lượng dòng code thay đổi.
  3. Theo dõi tỷ lệ chuyển cấp. Số lượng các yêu cầu cần chuyển cấp tăng lên là dấu hiệu cho thấy các quy tắc tĩnh không còn phù hợp với khối lượng công việc. Hãy điều chỉnh lại các nhóm (buckets) trước khi các mô hình giá rẻ bắt đầu gây ra nhiều lỗi quy trình hơn.

Việc dành riêng mô hình đắt nhất cho những vấn đề khó nhất và để các mô hình rẻ hơn xử lý phần còn lại giúp việc phát triển với sự hỗ trợ của AI trở nên nhanh chóng và hợp túi tiền. Lợi thế thực sự nằm ở một chiến lược điều hướng có kỷ luật, giúp kết hợp đúng công cụ cho đúng công việc.