Giảm chi phí LLM nhờ Opus: Khi mô hình đắt tiền chỉ làm việc thực sự cần thiết

Tuần trước, chúng tôi đã viết về việc nạp terabyte dữ liệu log CI (Continuous Integration) vào một Mô hình Ngôn ngữ Lớn (LLM). Tuy nhiên, phần lớn câu hỏi trên Hacker News không xoay quanh các log này, mà tập trung vào tác nhân (agent): sử dụng mô hình nào, chúng phối hợp ra sao và chi phí vận hành là bao nhiêu.

Hiện tại, chúng tôi đang vận hành Opus 4.6 và số tiền phải trả thậm chí thấp hơn so với thời điểm chạy mọi thứ trên Sonnet 4.0.

Lý do chính nằm ở những điều Opus không phải làm: 80% các lỗi thất bại không bao giờ được chuyển đến nó, và ngay cả khi được chuyển, nó không bao giờ phải đọc một dòng log nào.

Kiến trúc của hệ thống trông như sau:

Kiến trúc pipeline của hệ thống

Để tác nhân rẻ tiền quyết định khi nào cần mô hình đắt đỏ

Tuần trước, chúng tôi đã phân tích khoảng 4.000 lỗi CI. Trong đó có 818 vấn đề mới. 3.187 trường hợp còn lại là các vấn đề đã biết xuất hiện lại: một bài test không ổn định (flaky test), một trục trặc hạ tầng, hoặc một sự cố mạng ngắn hạn mà chúng tôi đã từng phát hiện.

Việc "đánh thức" một mô hình đắt tiền khi 80% thời gian câu trả lời chỉ là "đây là lỗi trùng lặp" là hoàn toàn vô nghĩa. Thật không may, chúng tôi không thể phát hiện các bản sao một cách xác định: cùng một công việc có thể thất bại nhiều lần vì những lý do hoàn toàn khác nhau, vì vậy bạn cần thực sự nhìn vào log để biết liệu bạn đã gặp vấn đề này trước đây chưa.

Ban đầu, chúng tôi sử dụng Sonnet để cân bằng giữa chi phí và hiệu suất. Nó hoạt động, nhưng đó là sự kết hợp tồi tệ nhất của cả hai thế giới: vẫn đắt đỏ, và kết quả không tốt bằng một mô hình tiên phong (frontier model).

Chúng tôi đã chuyển sang mô hình "người phân loại" (triager): một tác nhân Haiku với một công việc rất cụ thể và hẹp. Vấn đề này đã được theo dõi chưa? Nếu có, dừng lại ngay tại đó. Nếu chưa, chuyển lên Opus.

Việc phát hiện các bản sao với Haiku ban đầu khá thách thức. Chúng tôi cần làm cho công việc càng dễ càng tốt, vì vậy chúng tôi đính kèm các thông báo lỗi vào các thất bại trước đó và cung cấp cho Haiku hai công cụ tìm kiếm: khớp chính xác cho các đoạn lỗi đã biết và tìm kiếm ngữ nghĩa (pgvector) cho các lỗi tương tự nhưng không giống hệt nhau. RAG đã chết, nhưng tìm kiếm ngữ nghĩa thì rất tuyệt vời. "operator does not exist bigint character varying" và "migration type mismatch on installation_id" là hai chuỗi khác nhau nhưng cùng một nguyên nhân gốc rễ, và tìm kiếm ngữ nghĩa đã tìm ra điều đó.

Tác nhân Haiku đọc log, tìm kiếm thông báo lỗi, cố gắng khớp với các lỗi đã biết và đưa ra quyết định. Khi nghi ngờ, nó sẽ chuyển lên cấp trên. Một dương tính giả (báo sai là mới) tốn một ít tiền, nhưng một âm tính giả (báo sai là cũ) có nghĩa là chúng tôi bỏ lỡ một vấn đề thực sự.

4 trên 5 lỗi không bao giờ đến được Opus. Một lần phân loại khớp (triager match) có chi phí rẻ hơn khoảng 25 lần so với một cuộc điều tra đầy đủ.

Để tác nhân tự kéo ngữ cảnh, đừng đẩy dữ liệu vào

Nhiều người đã hỏi cách chúng tôi xử lý các tệp log dài hơn 200.000 dòng. Chúng tôi không đẩy chúng vào prompt (lệnh nhắc). Chúng tôi cung cấp cho tác nhân một giao diện SQL tới ClickHouse và để nó tự yêu cầu những gì nó cần.

Lý do không chỉ là chi phí token. Nếu bạn đưa cho tác nhân một tập hợp các dòng log cụ thể, bạn đã đưa ra phán đoán về những gì liên quan trước khi bạn thực sự biết vấn đề là gì. Tác nhân sẽ bị "neo" vào những gì bạn đưa cho nó. Nếu nguyên nhân thực sự nằm ở nơi khác, bạn đã khiến việc tìm kiếm trở nên khó khăn hơn. Đó cũng là lý do bạn không muốn dẫn dắt một phiên gỡ lỗi bằng cách nói "tôi nghĩ vấn đề nằm ở tệp này": bạn đã thiên vị cuộc điều tra trước khi nó bắt đầu.

Chúng tôi đã viết chi tiết về thiết lập SQL tuần trước, nhưng tóm tắt lại là: có một bảng với dữ liệu thô (github_logs, một dòng cho mỗi dòng log) và một tập hợp các chế độ xem vật lý (materialized views) với dữ liệu được tổng hợp trước: tỷ lệ thất bại theo quy trình công việc, thời gian chạy công việc, số lượng kết quả. Hầu hết các cuộc điều tra bắt đầu bằng các chế độ xem vật lý để thu hẹp nguyên nhân, sau đó khoan sâu vào log thô khi cần.

Chúng tôi không cho tác nhân biết nên truy vấn bảng nào. Thay vào đó, chúng tôi sử dụng các phản hồi chính nó để hướng dẫn nó từng bước. Nếu một truy vấn trả về quá nhiều hàng, chúng tôi cắt bớt và gợi ý một chế độ xem vật lý cụ thể hơn. Nếu log chưa được nạp, chúng tôi hướng nó đến GitHub CLI. Tác nhân tự nhận ra nó cần gì mà chúng tôi không cần phải dự đoán mọi đường đi trước.

Mô hình đắt lập kế hoạch, mô hình rẻ thực thi công việc

Opus xem xét cái gì đã thất bại, hình thành giả thuyết và tạo ra các tác nhân phụ Haiku để thực hiện việc đào bới thực tế. Mỗi tác nhân phụ nhận một prompt từ Opus: chính xác tìm kiếm gì, cách tìm kiếm, và trả lại cái gì. Các tác nhân phụ bị giới hạn ở một cấp độ sâu; chúng không thể tạo ra các tác nhân phụ của chính chúng. Sự phân nháng không giới hạn (unbounded fan-out) là cách bạn khiến chi phí tăng vọt.

Cách đây vài tuần, ba công việc CI Storybook thất bại trên cùng một commit, tất cả đều bị sập tại bước pnpm install.

Opus bắt đầu bằng cách yêu cầu một tác nhân phụ tìm nạp các thông báo lỗi từ bước cài đặt pnpm install thất bại. ClickHouse chưa có log, nên tác nhân phụ đã quay lại GitHub CLI.

Prompt của Tác nhân phụ #1:

Tìm nạp log CI cho lần chạy này. Trả lại chính xác các thông báo lỗi từ bước cài đặt pnpm install, toàn bộ đầu ra lỗi, đặc biệt là 50-100 dòng cuối.

Kết quả: gyp ERR! not found: make. [email protected] không thể biên dịch vì make không có trên runner.

Opus đã tìm kiếm các thông tin chi tiết hiện có (không khớp), sau đó truy vấn ClickHouse để xem xu hướng thất bại trong 14 ngày qua:

• 23 Tháng 2: tỷ lệ thất bại 0,2%
• 24 Tháng 2: 1,1%
• 25 Tháng 2: 8,0% <- điểm uốn

Rõ ràng có gì đó đã thay đổi vào ngày 25 Tháng 2. Opus đã tạo Tác nhân phụ #2:

Điều tra xem đã thay đổi gì vào khoảng ngày 24-25 Tháng 2. Tỷ lệ thất bại tăng từ 0,2% lên 8%. Lỗi là gyp ERR! not found: make. Chạy git log trên tệp quy trình công việc và package.json cho khoảng thời gian đó.

Các phụ thuộc xây dựng đã bị xóa trong quá trình di chuyển không liên quan. Đã sửa chữa cho quá trình di chuyển đó, nhưng re2 vẫn cần make để biên dịch nguyên bản. Opus đã tạo Tác nhân phụ #3 để xác minh trạng thái quy trình hiện tại, sau đó tạo thông tin chi tiết với nguyên nhân gốc rễ và bản sửa lỗi.

Sơ đồ điều phối của Opus và các tác nhân phụ

Bộ điều phối (orchestrator) chưa bao giờ đọc một dòng log, lịch sử git hay mã nguồn nào.

Một số điểm đáng chú ý

• Chi phí: Haiku xử lý khoảng 65% tất cả token đầu vào nhưng chỉ chiếm ~36% chi tiêu LLM của chúng tôi. Mô hình đắt tiền suy nghĩ; mô hình rẻ tiền đọc dữ liệu. Nếu không có hệ thống phân cấp mô hình này, hóa đơn hàng ngày sẽ tăng gấp đôi.
• Opus lập kế hoạch theo tiến trình. Nó bắt đầu với một giả thuyết, nhưng kết quả của mỗi tác nhân phụ định hình bước tiếp theo. Trong cuộc điều tra này, nó nhận được lỗi, tìm kiếm lịch sử, sau đó hỏi xem đã thay đổi gì. Mỗi vòng tròn thông báo cho vòng tiếp theo. Hơn một phần ba các cuộc điều tra của chúng tôi diễn ra đa vòng, và các vấn đề mới cần độ sâu điều tra khoảng gấp đôi các vấn đề đã biết.
• Vệ sinh ngữ cảnh (Context hygiene). Ngữ cảnh của bộ điều phối luôn sạch sẽ: các bản tóm tắt có cấu trúc từ các tác nhân phụ, không phải đầu ra log thô. Mỗi tác nhân phụ bắt đầu với một trang trắng và ngữ cảnh của nó bị loại bỏ khi hoàn thành. Đầu ra của lệnh gọi công cụ tích tụ rất nhanh và ngữ cảnh cũ từ sớm trong một phiên làm suy giảm các quyết định sau này.
• Tìm kiếm có định hướng. "Trả lại chính xác các thông báo lỗi từ bước cài đặt pnpm install" là một prompt rất khác so với "phân tích các log này". Opus quyết định cái cần tìm; Haiku tìm ra nó. Tỷ lệ đầu vào/đầu ra của Haiku là 86:1 (đọc rất nhiều, trả về các trích xuất tập trung), trong khi bộ điều phối là khoảng 50:1 (tổng hợp và quyết định). Haiku hấp thụ dữ liệu để Opus không phải làm thế.

Điều này không thể thực hiện được 6 tháng trước

Sáu tháng trước, chúng tôi đang dùng Sonnet 4.0. Nó gặp khó khăn trong việc viết các truy vấn ClickHouse đúng: sai bảng, thiếu bộ lọc, đọc quá nhiều dữ liệu. Haiku 4.0 không hữu ích cho bất cứ thứ gì ngoài việc phân loại có/không.

Ngày nay, Opus 4.6 có thể lập kế hoạch điều tra và viết các prompt tác nhân phụ chính xác. Haiku 4.5 có thể xử lý các nhiệm vụ hẹp, có định hướng vì các nhiệm vụ được giới hạn đủ chặt chẽ để một mô hình rẻ và nhanh có thể thực thi chúng.

Nâng cấp lên một mô hình tiên phong đã làm cho chi phí giảm xuống.

Mô hình này có thể tổng quát hóa

Chúng tôi xây dựng điều này cho log CI nhưng mô hình áp dụng cho bất cứ thứ gì có khối lượng sự kiện cao: log bảo mật, dữ liệu viễn thông IoT, dữ liệu tài chính. Hầu hết các sự kiện là nhiễu hoặc lặp lại, và mô hình đắt tiền chỉ nên nhìn thấy những cái không phải vậy.

Có một lớp thứ tư chúng tôi chưa đề cập: đánh giá lại. Hệ thống định kỳ kiểm tra xem những gì nó kết luận có còn đúng không, đóng các thông tin chi tiết cũ, bắt các dương tính giả, xác minh rằng các bản sửa lỗi đã hoạt động. Đó là nội dung cho một bài viết khác.

Chúng tôi vẫn đang tinh chỉnh ranh giới của tác nhân phụ nằm ở đâu. Đôi khi tạo ra một tác nhân phụ tốn nhiều tiền hơn là làm việc nội tuyến vì chi phí thiết lập lớn hơn tiền tiết kiệm được.

Phần khó nhất không phải là làm cho tác nhân thông minh hơn. Đó là xây dựng các lớp ngăn chặn nó chạy khi nó không nên chạy.