Đừng chọn model, hãy chọn đường ray

Đừng chọn model, hãy chọn đường ray

Case study từ Factory cho thấy bài toán không phải model nào giỏi nhất, mà là khi nào bẻ ghi sang model nào, với chi phí và rủi ro nào.

“Team mình nên dùng model nào cho coding agent?”

Nếu bạn hỏi câu này trong một nhóm developer lúc 11 giờ đêm, khả năng cao cuộc trò chuyện sẽ rẽ thành ba nhánh: một phe chọn frontier model vì “đỡ đau đầu”, một phe đẩy open-weight vì “rẻ và kiểm soát được”, phe còn lại lặng lẽ mở billing dashboard rồi thở dài.

Mình không chê câu hỏi đó. Nhưng với team đang build hệ thống AI thật, câu hỏi đúng hơn là: task nào được đi trên đường ray nào, khi nào bẻ ghi, và ai chịu trách nhiệm nếu tàu chạy sai ga?

Case của Factory đáng nhìn ở chỗ đó. Không phải vì họ dùng open-weight models tăng 2-3x trong sáu tháng. Con số ấy chỉ là tín hiệu. Điều đáng học là cách họ biến “chọn model” thành một quyết định vận hành có kiểm soát.

Sơ đồ minh họa cho bài Đừng chọn model, hãy chọn đường ray

Sơ đồ tóm tắt ý chính của bài viết.

Bối cảnh: agent coding ăn token như tàu dài toa

Factory xây các coding agents gọi là Droids, chạy qua nhiều bước trong software development lifecycle: triage, planning, code generation, validation, release, monitoring. Đây không còn là chatbot trả lời vài câu trong IDE. Đây là agent làm việc dài hơi, gọi tool, đọc repo, sửa nhiều file, chạy test, rồi lặp lại.

Khi workflow chuyển từ “hỏi đáp” sang “agent tự xử lý một phần công việc”, token consumption — lượng token model đọc và sinh ra — tăng rất nhanh. Và khi mọi bước đều đẩy lên model đắt nhất, chi phí không còn là dòng nhỏ trong hóa đơn nữa; nó trở thành biến kiến trúc.

Ở đây có hai áp lực kéo ngược nhau:

Factory chọn hướng model independence — không khóa Droids vào một model duy nhất, mà để chúng chạy trên nhiều coding model đáng tin, từ frontier models đến open-weight models. Open-weight model là model có trọng số được mở ở mức đủ để bên ngoài triển khai hoặc tùy biến, tùy giấy phép. Trong công việc thật, nó ảnh hưởng trực tiếp tới câu hỏi: bạn có thể chạy ở đâu, tối ưu giá thế nào, và có thoát phụ thuộc vendor được không.

Quyết định thật: xây model routing trước khi tranh luận model

Nhiều team nghe “open model dùng tăng 2-3x” rồi kết luận hơi vội: “Vậy bỏ frontier model đi.” Không nhanh vậy đâu.

Điểm đáng chú ý là Factory không chọn một model thắng tuyệt đối. Họ chọn model routing — cơ chế định tuyến task sang model phù hợp. Dịch sang tiếng người: cùng một hệ thống agent, nhưng không phải toa nào cũng kéo bằng cùng một đầu máy.

Một coding agent thường có nhiều loại việc:

| Loại task | Rủi ro nếu sai | Cách chọn model hợp lý |
|---|---:|---|
| Phân loại issue, tóm tắt log | Thấp đến vừa | Open-weight model nếu eval ổn |
| Viết patch nhỏ có test rõ | Vừa | Model rẻ hơn, có validation chặt |
| Refactor nhiều file | Cao | Frontier hoặc model đã chứng minh tốt trên repo tương tự |
| Debug lỗi production mơ hồ | Cao | Model mạnh, thêm human review |
| Generate release note | Thấp | Model rẻ, kiểm tra format |

Điểm mấu chốt không nằm ở tên model. Nó nằm ở routing policy — chính sách quyết định task nào đi đâu. Nếu policy mơ hồ, team sẽ quay lại kiểu “ai thích model nào thì dùng model đó”, và billing dashboard sẽ thành nơi kể chuyện buồn.

Để routing chạy được, bạn cần eval harness — bộ khung đánh giá tự động để test model trên task thật của team. Với builder, eval harness không phải bảng benchmark đẹp. Nó là danh sách case mà nếu model làm sai, bạn thật sự đau: sửa nhầm permission, bỏ sót migration, tạo SQL sai tenant, hoặc pass test giả nhưng phá behavior.

Hệ quả: open-weight thắng ở những đoạn có phanh

Factory nói open-weight models đã bắt kịp đáng kể so với khoảng cách trước đây, và usage của nhóm này tăng 2-3x trong sáu tháng. Nhưng nếu chỉ đọc thành tích, mình thấy dễ bị lạc.

Giá trị vận hành nằm ở chỗ: open-weight models trở nên hấp dẫn nhất khi task có guardrail rõ.

Guardrail là hàng rào an toàn: test, permission, schema validation, policy check, rollback, human approval. Với coding agent, guardrail có thể là:

Hình dung thế này: nếu agent chỉ cần phân loại ticket và gắn nhãn, open-weight model làm tốt đủ thì bạn tiết kiệm được đáng kể. Nhưng nếu agent chuẩn bị sửa logic thanh toán, bạn không muốn “rẻ hơn” là lý do duy nhất để giao việc. Đoạn đó cần model mạnh hơn, hoặc ít nhất cần validation dày hơn.

Nguồn từ AWS về multi-tenant LLM analytics cũng nhắc một bài học cùng họ hàng: text-to-SQL không chỉ là sinh SQL đúng, mà là đúng cho đúng người, đúng lát dữ liệu. Row-level security là bảo mật ở cấp từng dòng dữ liệu; nghĩa là hai user hỏi cùng một câu vẫn chỉ thấy phần họ được phép thấy. Với agent coding cũng vậy: model giỏi không thay thế được boundary. Nếu quyền truy cập sai, model tốt vẫn có thể gây hại rất nhanh.

Thử trong một buổi: routing audit cho team nhỏ

Nếu bạn đang là tech lead và muốn áp dụng bài học này, đừng bắt đầu bằng việc đổi toàn bộ model stack. Làm một buổi audit nhỏ trước.

Bước 1: gom 20 task thật gần nhất

Lấy từ issue, PR, log support, hoặc prompt history. Chia thành nhóm:

Đừng chọn case quá đẹp. Lấy cả case model từng làm sai.

Bước 2: gắn nhãn rủi ro

Dùng ba mức là đủ:

Ví dụ minh họa: giả sử team bạn có 5 developer, mỗi ngày agent xử lý 30 lượt task. Nếu 18 lượt là tóm tắt, phân loại, generate boilerplate, bạn không cần đưa cả 18 lượt đó qua model đắt nhất chỉ vì “cho chắc”. Nhưng 3 lượt liên quan migration dữ liệu thì nên được đối xử khác.

Bước 3: chạy A/B tối giản giữa hai loại model

Chọn một frontier model đang dùng và một open-weight model triển khai qua serverless inference. Serverless inference là cách gọi model qua API mà bạn không tự quản máy chủ; tiện để thử trước khi nghĩ tới self-host.

Với mỗi task, lưu lại:

task_id: issue-1842
task_type: bugfix
risk: medium
model_a_result: pass_tests_but_bad_style
model_b_result: fail_one_test
latency: qualitative_notes
reviewer_verdict: model_a
route_decision: frontier_for_now

Không cần hệ thống hoành tráng. Một spreadsheet cũng được, miễn là reviewer ghi lý do chọn.

Bước 4: đặt tiêu chí dừng trước khi scale

Đây là phần nhiều team bỏ qua. Trước khi tăng usage open-weight, hãy viết rõ:

Nói thẳng ra thì: tiết kiệm token mà tăng review debt thì chỉ là chuyển chi phí từ hóa đơn sang người trong team.

Khi nào bẻ ghi sang open-weight?

Mình sẽ dùng một mini-framework ba câu hỏi:

1. Task có output kiểm được không?
Nếu có test, schema, linter, policy checker, hoặc reviewer rõ ràng, bạn có thể thử model rẻ hơn. Nếu output là quyết định mơ hồ và khó kiểm, đừng vội.

2. Sai thì rollback được không?
Generate docs sai khác với sửa permission sai. Cùng là token, nhưng hậu quả không cùng trọng lượng.

3. Bạn có dữ liệu route chưa?
Nếu không biết task nào tốn token nhất, fail nhiều nhất, hoặc bị reviewer sửa nhiều nhất, bạn chưa đang tối ưu. Bạn chỉ đang đoán.

Ở đây, case Factory cho mình một góc nhìn khá thực dụng: open-weight không cần thắng mọi trận. Chỉ cần thắng đều ở những đoạn có kiểm soát, nó đã làm thay đổi cấu trúc chi phí và quyền lựa chọn của hệ thống.

Bài học cho team Việt Nam: đừng mua sự yên tâm bằng một model duy nhất

Với nhiều team ở Việt Nam, bài toán không phải “có nên build agent-native software factory không?” Nghe hơi xa. Bài toán gần hơn là: “Làm sao dùng coding agent mà cuối tháng không giật mình, và vẫn giữ được quyền kiểm soát dữ liệu?”

Nếu bạn phục vụ enterprise, sovereign deployment — triển khai theo nơi khách hàng yêu cầu, từ SaaS managed đến môi trường cô lập — không phải câu chuyện trang trí. Nó quyết định bạn có bán được cho khách hàng nhạy cảm dữ liệu hay không. Nếu bạn chỉ phụ thuộc một vendor, một API, một vùng triển khai, bạn đang đi chung ray với lịch trình của người khác.

Điều mình muốn bạn nghĩ khác sau bài này: đừng hỏi model nào tốt nhất cho agent; hãy hỏi hệ thống của bạn có đủ khả năng đổi model mà không đổi sản phẩm không.

Nếu là mình, mình sẽ bắt đầu bằng routing audit nhỏ, route open-weight cho task low-risk có validation rõ, giữ model mạnh cho đoạn khó, và viết tiêu chí dừng trước khi khoe “đã tối ưu chi phí”. Tàu chạy nhanh là tốt, nhưng biết bẻ ghi đúng lúc mới tới ga cuối mà không làm rơi hành lý.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo