Automation trước, AI sau: chỉ dùng LLM ở bước cần “phán đoán”

Khi có LLM trong tay, rất dễ rơi vào cám dỗ “cho AI làm hết”: AI đọc email, AI lọc spam, AI tính tiền hoàn, AI quyết định gửi cho ai. Kết quả thường là một hệ thống đắt, chậm và thỉnh thoảng sai theo những cách khó đoán. Nguyên tắc ngược lại hiệu quả hơn nhiều: tự động hoá bằng logic thường trước, chỉ dùng LLM ở những bước thật sự cần “phán đoán”.

Hai loại bước trong mọi quy trình

Ví dụ: xử lý email yêu cầu hoàn tiền

Trong 7 bước, chỉ 2–3 bước cần LLM. Phần còn lại rẻ hơn, nhanh hơn và kiểm thử được bằng unit test thông thường.

Vì sao cách này tốt hơn?

• Chi phí: mỗi bước chuyển từ LLM sang code là bớt một lượt gọi model cho mọi bản ghi.
• Độ tin cậy: lỗi của LLM khó đoán; lỗi của code có stack trace và tái hiện được.
• Dễ debug: khi kết quả sai, bạn biết khoanh vùng ở bước nào.
• Dễ thay model: phần LLM nhỏ, rõ ràng → đổi model hay prompt không ảnh hưởng phần còn lại.

Đây cũng là tinh thần trong bài “Building effective agents” của Anthropic: tìm giải pháp đơn giản nhất có thể, chỉ thêm độ phức tạp khi đo được rằng nó cải thiện kết quả. Nhiều bài toán chỉ cần một lần gọi LLM được thiết kế tốt kèm retrieval và ví dụ — chưa cần tới agent.

Bốn câu hỏi kiểm tra cho từng bước

1. Viết được if/else, regex hoặc SQL cho nó không? Có → đừng dùng AI.
2. Sai một lần thì thiệt hại bao nhiêu? Cao (tiền, pháp lý, khách hàng lớn) → cần người duyệt, AI chỉ đề xuất.
3. Đầu ra có cần cấu trúc cố định không? Có → ép JSON schema (structured outputs) và validate.
4. Có dữ liệu mẫu để đánh giá không? Chưa → chuẩn bị 50–100 ví dụ gán nhãn tay trước khi đưa vào chạy thật.

Mẫu kiến trúc “bánh mì kẹp”

[Code: lọc, chuẩn hoá đầu vào]
        ↓
[LLM: hiểu / phân loại / soạn thảo]  → JSON theo schema
        ↓
[Code: validate, tra cứu, tính toán, route]
        ↓
[Người: duyệt nếu rủi ro cao / độ tin cậy thấp]

LLM bị “kẹp” giữa hai lớp code: lớp trước cắt giảm và làm sạch đầu vào, lớp sau kiểm tra và thực thi. Đầu ra LLM không bao giờ đi thẳng tới hành động có hậu quả.

Áp dụng thế nào?

• Dev: Rà workflow hiện có: bước nào đang gọi LLM mà có thể thay bằng rule? Bắt đầu từ bước lọc đầu vào — thường tiết kiệm nhiều token nhất.
• Tech Lead: Yêu cầu sơ đồ workflow tô màu rõ “phần deterministic” và “phần AI” trong design review.
• PM: Khi ước lượng dự án automation, tách hai phần. Phần AI cần thêm thời gian cho bộ dữ liệu đánh giá, chỉnh prompt và xử lý ngoại lệ — đừng ước lượng như code thường.