Mỗi khi một mô hình mới được ra mắt, một cuộc tranh luận cũ rích lại nổ ra. Các nhà bình luận vội vã tôn vinh người chiến thắng và tuyên bố thế hệ trước đã lỗi thời. Với sự xuất hiện của GPT-5.6 Luna bên cạnh Terra và Sol, kịch bản tự viết ra chính nó: Luna đủ rẻ và đủ năng lực để khiến Terra trở nên không còn quan trọng. Điều này là sai lầm. Việc đó cũng rất tốn kém. Việc lựa chọn một mô hình cho các agent lập trình của bạn không phải là một cuộc thi sắc đẹp, một bản sắc đội ngũ, hay một cuộc đua điểm số benchmark. Đó là một chính sách vận hành. Những đội ngũ hiểu rõ sự khác biệt này sẽ chi tiêu ít hơn, di chuyển nhanh hơn và ít gây ra lỗi hơn so với những đội ngũ mặc định sử dụng mô hình mạnh nhất cho mọi yêu cầu.
Lựa chọn mặc định của bạn nên là công cụ rẻ nhất mà vẫn đáp ứng được yêu cầu
Luna thuộc phân khúc giá trị, và đây không phải là một lời khen giảm nhẹ. Nó phát huy thế mạnh trong các tác vụ có phạm vi giới hạn, rõ ràng và dễ dàng. Hãy nghĩ đến việc phân loại, tóm tắt, chỉnh sửa mã ngắn và nghiên cứu sơ bộ. Khi một agent phân tích một phiếu hỗ trợ (support ticket) để gán nhãn ưu tiên, Luna là đủ. Khi nó đổi tên một biến trong vài tệp hoặc soạn thảo một bản tóm tắt ngắn gọn về một git diff, Luna là đủ. Đây là những công việc có phạm vi hẹp, đầu vào rõ ràng và đầu ra có thể kiểm tra khách quan.
Hiệu ứng kinh tế là yếu tố thay đổi cuộc chơi. Luna rất rẻ. Ở quy mô lớn, điều này chuyển đổi tự động hóa từ một nghi thức tốn kém thành cơ sở hạ tầng. Bạn ngừng đếm token và bắt đầu đo lường thông lượng (throughput). Một mô hình rẻ tiền giải quyết được 80% các tác vụ định kỳ sẽ có giá trị hơn một mô hình đắt tiền giải quyết được 85% nếu 5% tăng thêm đó không làm thay đổi kết quả cuối cùng. Nếu Luna tạo ra một unit test trong hai giây và Terra tạo ra một bản sạch hơn một chút trong tám giây với chi phí gấp năm lần, thì phép toán này chỉ có hiệu quả nếu có ai đó đang kiểm tra kỹ lưỡng từng dòng mã. Hầu hết thời gian, không ai làm vậy cả. Luna nên là lựa chọn mặc định của bạn cho các công việc có giới hạn, chính vì hầu hết các công việc đều có giới hạn.
Nâng cấp khi các ranh giới biến mất
Terra không hề vô dụng. Nó là phân khúc xử lý nâng cao (escalation tier), và nó chứng minh giá trị của mình trong các tác vụ không có ranh giới rõ ràng. Hãy sử dụng nó khi mục tiêu chưa được chỉ định cụ thể hoặc khi công việc liên quan đến các hệ thống phức tạp như lộ trình triển khai (deployment paths), thay đổi liên module, hoặc phân loại sự cố (incident triage). Một lộ trình triển khai len lỏi qua các môi trường staging, canary và production với các feature flags không hề có một bảng thông số kỹ thuật gọn gàng. Một đợt tái cấu trúc (refactor) chạm vào logic thanh toán và âm thầm gây ảnh hưởng đến luồng báo cáo không phải là một tác vụ có giới hạn. Một sự cố production nơi các bản log gào thét về lỗi API timeout nhưng nguyên nhân gốc rễ lại nằm trong một script migration từ quý trước đòi hỏi sự phán đoán.
Terra cung cấp sự phán đoán đó. Nó phân biệt giữa triệu chứng và nguyên nhân. Luna có thể vá một vòng lặp retry để ngăn chặn tình trạng tồi tệ hơn. Terra sẽ đặt câu hỏi liệu vòng lặp retry đó có nên tồn tại hay không, hoặc liệu kiến trúc timeout bên dưới mới là vấn đề thực sự. Sự khác biệt đó rất quan trọng khi một bản sửa lỗi sai lầm có thể biến một sự chậm trễ tạm thời thành một lỗi dây chuyền (cascading failure). Một mô hình mạnh mẽ hơn giúp ngăn chặn một đợt migration production lỗi đáng giá hơn mức chi phí của nó nếu nó giúp kỹ sư tiết kiệm được cả một ngày dọn dẹp hậu quả. Một sự cố được ngăn chặn sẽ chi trả cho nhiều tháng chi phí nâng cấp.
Sol là chính sách bảo hiểm, không phải là công cụ sử dụng hàng ngày
Sol tồn tại cho những trường hợp mà khả năng vượt trội bù đắp được chi phí cao. Hãy sử dụng nó cho các đợt đánh giá rủi ro cao hoặc các thay đổi về kiến trúc. Việc xây dựng lại luồng xác thực (authentication flow), thiết kế lại việc phân mảnh cơ sở dữ liệu (database sharding), hoặc phê duyệt một pull request chạm vào cổng thanh toán không phải là những việc xảy ra hàng ngày. Chúng là những sự kiện. Sol không nên là lựa chọn mặc định của bạn. Nó nên là trình xử lý ngoại lệ (exception handler), được triệu hồi khi chi phí của sự thất bại quá cao để các mô hình rẻ hơn có thể tự gánh vác.
Đối với danh mục rủi ro cao nhất, hãy kết hợp Sol với một trình xác thực có tính xác định (deterministic verifier). Hãy để Sol đề xuất thay đổi schema hoặc suy luận về các đánh đổi kiến trúc. Hãy để pipeline CI, phân tích tĩnh và các bài kiểm thử tích hợp của bạn xác nhận các chi tiết kỹ thuật. Mô hình mang lại trực giác. Trình xác thực mang lại sự đảm bảo. Sự kết hợp đó là thứ bảo vệ bạn khi phạm vi ảnh hưởng (blast radius) là lớn nhất.
Hãy xây dựng một bộ định tuyến, đừng xây dựng một tôn giáo
Chỉ số thực sự không phải là mô hình nào tốt nhất. Câu hỏi là mô hình nào nên xử lý tác vụ này dựa trên chi phí, độ trễ và phạm vi ảnh hưởng. Đừng coi việc lựa chọn mô hình là một bản sắc.
Xây dựng một bộ phân loại đơn giản. Các tác vụ đến sẽ được gắn thẻ theo phạm vi ảnh hưởng (blast radius). Công việc có phạm vi ảnh hưởng thấp sẽ được giao cho Luna. Công việc có phạm vi ảnh hưởng trung bình sẽ được giao cho Terra. Công việc có phạm vi ảnh hưởng cao sẽ được giao cho một mô hình mạnh kết hợp với một bộ xác thực tất định (deterministic verifier). Bạn không cần một bộ phân loại học máy hoàn hảo để bắt đầu. Chỉ cần một vài quy tắc kinh nghiệm (heuristics) là đủ. Các đợt review code chỉ chạm vào các tiện ích nội bộ và có số dòng thay đổi ít? Luna. Các ticket đề cập đến pipeline triển khai, các cuộc gọi liên dịch vụ (cross-service calls), hoặc các yêu cầu mơ hồ? Terra. Bất cứ thứ gì chạm đến dữ liệu khách hàng, các luồng xử lý quan trọng (critical paths), hoặc tuân thủ pháp lý? Hãy chuyển lên Sol và yêu cầu sự kiểm duyệt của con người hoặc bộ xác thực tất định.
Hãy đo lường kết quả, đừng đo lường tên mô hình. Theo dõi chi phí trên mỗi tác vụ, tỷ lệ thử lại và các lỗi lọt lưới (escape defects). Nếu Luna thất bại ở những tác vụ bạn giao cho nó, hãy nâng ranh giới lên. Nếu Terra là quá mức cần thiết cho một mẫu công việc lặp lại hàng ngày, hãy hạ cấp nó xuống Luna và chứng kiến mức tiêu thụ của bạn giảm xuống. Mục tiêu là tăng cường tự động hóa mà không làm vỡ ngân sách của bạn. Luna xử lý các công việc nền có khối lượng lớn. Terra xử lý những thời điểm cần đến sự phán đoán. Sol đứng gác cho những trường hợp ngoại lệ có thể làm đảo lộn cả tuần làm việc của bạn.
Những đội ngũ làm tốt điều này sẽ đối xử với đội ngũ agent của họ như một tổ chức kỹ thuật được vận hành bài bản. Họ không bố trí kiến trúc sư cho mọi dự án, và họ cũng không yêu cầu thực tập sinh thiết kế lại mô hình dữ liệu cốt lõi. Họ khớp năng lực với mức độ rủi ro. Hãy làm điều tương tự với các mô hình của bạn.
Đọc thảo luận gốc: GPT-5.6 Luna Is The Value Tier. Terra Is Not Useless
Tham gia cộng đồng học tập GyaanSetu: t.me/GyaanSetuAi