Đừng để LLM đưa ra quyết định hoặc thực thi logic nghiệp vụ

Luận điểm cốt lõi: hãy thoát khỏi LLM càng sớm càng tốt và đừng ở lại trong đó quá lâu

• Không nên giao việc ra quyết định hay logic nghiệp vụ cho LLM → thiếu độ chính xác và tính ổn định
• Trong đa số trường hợp, LLM chỉ nên đóng vai trò là giao diện giữa người dùng và API của ứng dụng
• Logic cốt lõi nên được thực hiện trong các hệ thống hoặc engine chuyên dụng, còn LLM chỉ đảm nhiệm việc chuyển yêu cầu của người dùng thành lời gọi API và chuyển kết quả trở lại thành ngôn ngữ tự nhiên

Vì sao lại như vậy?

• Ví dụ bot cờ vua: người dùng gửi qua WhatsApp "hãy dùng tượng của tôi bắt mã" → LLM vẫn có thể duy trì trạng thái bàn cờ và chơi, nhưng sẽ phát sinh nhiều vấn đề về độ tin cậy, hiệu năng và khả năng bảo trì

• Hiệu năng: khả năng chơi cờ của LLM tuy ấn tượng nhưng vẫn chậm hơn và kém chính xác hơn các engine cờ chuyên dụng (ví dụ: Stockfish)

• Không thể debug và tinh chỉnh: khó biết vì sao nó đưa ra phán đoán như vậy, nên rất khó chỉnh để nó hoạt động theo đúng ý định

• Các vấn đề khác:

  • Đầu ra của LLM khó kiểm thử
  • Khả năng làm toán hoặc tạo số ngẫu nhiên kém
  • Khó quản lý phiên bản và kiểm toán
  • Cách duy trì trạng thái bằng ngôn ngữ tự nhiên rất mong manh
  • Phát sinh các vấn đề như phí API, giới hạn tốc độ
  • Ranh giới bảo mật trở nên mơ hồ

Phân tách vai trò đúng đắn qua nhiều ví dụ

• Trong game, "tôi muốn tấn công người chơi X bằng vorpal sword" → LLM chỉ nên chuyển đổi thành dạng attack(player=X, weapon="vorpal_sword") rồi chuyển cho logic game xử lý
• Tác tử đàm phán → LLM không tự đưa ra quyết định đàm phán, mà chỉ đóng gói đầu vào của người dùng để chuyển cho engine đàm phán rồi chuyển tiếp kết quả
• Tạo phản hồi ngẫu nhiên → không nên để LLM lựa chọn, mà phải xử lý bằng hàm ngẫu nhiên bên ngoài

Những việc LLM làm tốt

• LLM đặc biệt phù hợp với chuyển đổi, diễn giải, giao tiếp
• Ví dụ:
  • "đánh con orc bằng kiếm" → chuyển thành attack(target="orc", weapon="sword")
  • { "error": "insufficient_funds" } → giải thích tự nhiên thành "Không đủ vàng"
  • Có thể phân loại đầu vào của người dùng là lệnh chiến đấu, kiểm tra kho đồ hay yêu cầu trợ giúp
  • Hiểu tốt các khái niệm của con người (ví dụ: blade = sword, smash = attack)
• Điều cốt lõi không phải là phán đoán phức tạp hay quản lý trạng thái → mà chỉ là chiếc cầu nối ý định của người dùng với hệ thống

Triển vọng tương lai và nguyên tắc vẫn không đổi

• Công nghệ đang phát triển rất nhanh, nên những điều hiện chưa làm được có thể sớm trở nên khả thi
• Tuy nhiên, các vấn đề mang tính cấu trúc mà LLM không thể giải quyết nhiều khả năng vẫn sẽ tồn tại:
  • Logic không dùng LLM dễ hiểu hơn, và cũng dễ bảo trì cũng như quản lý phiên bản hơn
  • Chi phí vận hành cũng rẻ hơn
• Trong tương lai cũng vậy, LLM nên tập trung vào vai trò giao diện, còn logic cốt lõi nên giao cho các hệ thống chuyên dụng

[GN⁺]

Ý kiến trên Hacker News

• Có hai loại logic

  • 1. Logic về bản chất phải chính xác và nghiêm ngặt
  • 2. Logic đã vận hành theo cách đó do đặc tính của máy tính

• Loại 1 thuộc về các lĩnh vực như bảo mật, tài chính, toán học

• Loại 2 có khả năng cao sẽ được AI thay thế

• Các phần khác nhau của cùng một ứng dụng có thể phù hợp với loại 1 hoặc loại 2

• Gần đây đã làm một trò chơi giáo dục tại một hackathon

  • Dùng LLM để tạo và vận hành trò chơi, nhưng luồng chơi không tốt
  • Cuối cùng đã dùng nhiều mã Python và nhiều prompt để quản lý trạng thái trò chơi
  • Tốt nhất là dùng LLM như một bộ phận nhỏ trong một hệ thống lớn

• LLM không nên triển khai logic

  • Logic, tối ưu hóa và lập trình ràng buộc là các kỹ thuật riêng biệt
  • Người đặt nền móng cho logic học hiện đại là George Boole, ông là ông nội của Geoffrey Everest Hinton

• Rất khó để hiểu khả năng của LLM

  • Người đọc muốn câu trả lời đơn giản
  • LLM có thể gặp khó khăn khi viết một máy trạng thái đơn giản
  • Các bài báo nghiên cứu đang rất được chú ý, và đến năm 2025 có lẽ vẫn chưa ai hiểu hoàn toàn về LLM

• Nếu cần phản hồi từ LLM nhanh và rẻ, nên dùng prompt ngắn và mô hình nhỏ

  • Nhiều thông tin hiện nay mặc định rằng phải dùng mô hình lớn
  • UI truyền thống có thể là lựa chọn tốt hơn

• Chỉ dùng LLM thì rất khó kiểm thử

  • Phong cách cá nhân ảnh hưởng đến tương tác
  • Chi phí bảo trì có thể cao
  • Chuyển thành các lệnh gọi API sẽ hợp lý hơn

• Dùng LLM cho business logic là rủi ro

  • Nó phù hợp với xử lý ngôn ngữ

• Có thể dùng hình ảnh do AI tạo ra để tóm tắt bài viết