Khi mặc định dùng Opus ở khắp mọi nơi khiến chi phí đội lên gấp 7 lần

90 ngày sau khi launch

• Triệu chứng (Symptom): Chi phí hàng tháng tăng vọt gấp 7 lần so với dự toán ban đầu. Median latency trên luồng phục vụ người dùng chạm mức 2.3 giây, cao hơn nhiều so với mục tiêu 800 mili-giây mà đối tác đã thống nhất lúc ban đầu. Điểm hài lòng của khách hàng (CSAT) thì không hề suy chuyển so với mốc trước khi launch.

• Nguyên nhân (Cause): Mọi lệnh gọi trong toàn bộ stack đều dùng Opus. Hoàn toàn không có cơ chế lựa chọn model theo từng bước (per-step model selection) trong kiến trúc, đơn giản vì không có bài đánh giá riêng cho từng bước (per-step eval) để chỉ ra sự cần thiết của việc đó. Team đã mặc định chọn "model tốt nhất" trong lúc phát triển và không bao giờ đánh giá lại khi hệ thống đã có lưu lượng truy cập thực tế.

• Các yếu tố cộng hưởng (Contributing factors): 3 sai lầm đã cộng hưởng tạo nên thảm họa này:

  1. Bản tài liệu kiến trúc ban đầu không hề chỉ định cấp bậc model (model-tier decision) ở từng bước, khiến quyết định ngầm định này đi thẳng vào môi trường deployment.

  2. Chi phí chỉ được đối soát theo tháng thay vì được đo lường ngay trong giai đoạn phát triển, khiến khoảng cách giữa chi phí ước tính và thực tế chỉ phát lộ nhiều tuần sau khi launch.

  3. Tính năng Extended thinking bị bật trên một routing classifier (bộ phân loại định tuyến) – nơi vốn dĩ chẳng cần đến năng lực suy luận phức tạp, trực tiếp làm tăng độ trễ và chi phí trên từng request đi qua bộ phân loại này.

• Team đã thay đổi những gì (What the team changed): Team đã hồi tố xây dựng một eval set, mô phỏng chính xác công việc thực tế của từng bước trong pipeline:

  • Họ chuyển bước phân loại sang dùng Haiku và xác nhận không có bất kỳ lỗi thụt lùi chất lượng (regression) nào trên tập eval.

  • Họ chuyển bước tóm tắt ở giữa pipeline sang dùng Sonnet và cũng xác nhận chất lượng giữ nguyên.

  • Họ chỉ giữ lại Opus cho bước tổng hợp câu trả lời cuối cùng (response-composition) – vị trí duy nhất mà kết quả eval chứng minh model phân cấp cao là thực sự cần thiết.

  • Kết quả: Chi phí hàng tháng giảm ngay 71%. Median latency giảm xuống còn 940 mili-giây. Điểm CSAT vẫn giữ nguyên không đổi.

Cách một quyết định chọn Model biến thành một cuộc khủng hoảng ngân sách

3 cơ chế thất bại đã chồng chéo lên nhau, và mỗi cơ chế đều có thể nhận diện từ trước:

1. "Không đưa ra quyết định chọn tier model nào" thực chất chính là một quyết định ngầm, và hệ thống sẽ tự động chọn phương án đắt đỏ nhất. Sự thiếu vắng một lựa chọn có chủ đích không bao giờ mang tính trung lập.

2. Khả năng theo dõi chi phí bị trễ nhiều tuần so với quá trình build. Hóa đơn chỉ tới sau khi đã launch, khi đối tác đã chính thức vận hành. Điều đó đẩy cuộc thảo luận về chi phí ra khỏi bàn thiết kế và biến thành bài toán quản trị sự thay đổi (change management).

3. Eval set không tồn tại trong giai đoạn build, nên khi ai đó đề xuất "cứ dùng model tốt nhất", cả team chẳng có dữ liệu cụ thể nào để làm căn cứ đưa ra lựa chọn khác. Eval set không chỉ là một release gate (chốt chặn phát hành), nó là thứ duy nhất giúp bảo vệ và chứng minh tính đúng đắn cho quyết định chọn model của bạn trong các buổi thảo luận kiến trúc.

Vì sao thiết kế này sụp đổ?

Không chủ động chọn model cũng đồng nghĩa với việc chọn model đắt nhất. Xây dựng một eval set có vẻ tốn thêm công sức ở giai đoạn đầu, nhưng đó lại là điểm tựa duy nhất giúp bạn bảo vệ được quyết định kiến trúc của mình trước mọi câu hỏi về chi phí.