Khi LLM đủ tốt, người ta dễ rơi vào cái bẫy: cho nó vai "cố vấn" và để nó tự suy luận. Trong những lĩnh vực có hậu quả thật — tiền, sức khoẻ, pháp lý — đó là một ý tưởng tệ.
Đây là một nguyên tắc thiết kế tôi đã đi tới sau khi sửa hệ thống AI vài lần: để LLM làm phần "hiểu", để code deterministic làm phần "quyết".
Hai việc rất khác nhau
Một agent AI khuyến nghị / quyết định thường làm hai việc:
- Hiểu user và bối cảnh. "HPG dạo này có nên ôm không?" → mã = HPG, ý định = check recommendation, ngầm định = đang nắm hoặc đang cân nhắc mua.
- Ra quyết định / khuyến nghị. Trả lời: MUA, BÁN, hay GIỮ.
Cách dễ nhất là để LLM làm cả hai. Bạn nhồi cả "cách hiểu câu hỏi" lẫn "cách ra phán quyết" vào prompt, rồi nhìn vào output cuối cùng.
Cách này hấp dẫn vì nhanh. Nó cũng có ba vấn đề tệ.
Vấn đề 1: cùng input, khác output
LLM không deterministic. Cho cùng một câu hỏi, cùng một dữ liệu, hai lần gọi cách nhau 30 giây có thể ra hai khuyến nghị khác nhau. Sáng nói MUA, chiều nói GIỮ, không vì lý do nào ngoài việc nó là một mô hình sinh.
Trong sản phẩm có hậu quả, đây là vấn đề không sửa được bằng prompt tốt hơn — đó là bản chất công nghệ.
Vấn đề 2: bạn không backtest được
Sau một thời gian, bạn muốn biết: agent của bạn có chính xác không? Đáp án thường là chạy ngược lại trên dữ liệu lịch sử (backtest), xem nếu năm ngoái agent đưa ra khuyến nghị này, kết quả 12 tháng sau ra sao.
Nếu logic phán quyết nằm trong prompt LLM:
- Bạn không thể chạy "agent của tháng trước" — agent là một hàm của prompt + model + context, và cả ba đã thay đổi.
- Bạn không thể chạy đủ nhanh — mỗi recommendation tốn tiền và thời gian gọi LLM. Backtest 1000 mã x 5 năm = không khả thi.
- Bạn không biết khi nào logic divergence — bạn sửa prompt cho một use case, ngấm ngầm thay đổi logic ở use case khác.
Vấn đề 3: trách nhiệm mờ
Khi agent đưa ra khuyến nghị sai và gây thiệt hại, ai chịu trách nhiệm? Câu trả lời "model đã sinh ra như vậy" không thỏa đáng cho user, không thỏa đáng cho regulator, không thỏa đáng cho chính bạn.
Nếu logic ra phán quyết là một hàm code có thể đọc được — bạn có chỉ vào dòng nào, biện minh được, sửa được nếu sai.
Cách tôi tách ra
Mỗi quyết định quan trọng có một hàm deterministic — nhận đầu vào là số/biến, trả về kết quả rõ ràng. Hàm này:
- Sống ở một chỗ duy nhất trong codebase.
- Có test unit.
- Được cả agent (production) và script đánh giá (backtest, analytics) cùng gọi.
LLM trong setup này làm ba việc:
- Hiểu yêu cầu. Chuyển câu hỏi tự nhiên thành tham số cho hàm deterministic.
- Gọi đúng tool. Quyết định gọi hàm nào (tool use / function calling).
- Trình bày kết quả. Nhận output có cấu trúc, diễn giải thành ngôn ngữ tự nhiên, thêm bối cảnh.
Phần "ra phán quyết" nằm trong code, không trong prompt.
Một quy tắc, một chỗ
Có một hệ quả quan trọng: logic phán quyết phải sống ở một chỗ duy nhất. Nếu bạn có hai bản sao — một bản trong code production, một bản trong script backtest — chúng sẽ trôi xa nhau theo thời gian. Sau vài tháng, số liệu backtest không còn nói gì về hệ thống thật. Bạn vẫn nhìn vào "độ chính xác 67%" và tin nó, nhưng nó đang đo một thứ khác.
Đây là nguyên tắc tôi áp dụng cho mọi domain có rủi ro:
Một quy tắc. Một chỗ. Cả agent live và script đánh giá cùng gọi.
Khi nào để LLM ra quyết định trực tiếp
Không phải mọi quyết định đều cần tách. Khi:
- Hậu quả của một quyết định sai đơn lẻ rất nhỏ.
- Quyết định mang tính chủ quan, không có ground truth.
- Tốc độ iteration quan trọng hơn ổn định.
...thì để LLM tự quyết có khi tốt hơn. Ví dụ: viết một câu chào cho email marketing, gợi ý tag cho blog post, summarize một cuộc họp. Sai cũng không sao, sửa cũng dễ.
Khi quyết định liên quan tiền, sức khoẻ, pháp lý, danh tiếng — tách ra. LLM hiểu, code quyết.
Bài học rộng hơn
Pattern này có một tên cũ hơn AI: separation of concerns. LLM giỏi ngôn ngữ. Code giỏi nhất quán. Đừng yêu cầu một thứ làm cả hai chỉ vì có thể.