- Sẽ an toàn hơn nếu giới hạn LLM ở vai trò giao diện ngôn ngữ tự nhiên giữa đầu vào của người dùng và logic dựa trên API, thay vì để nó làm chủ thể phán đoán của ứng dụng
- Ví dụ bot cờ vua cho thấy nếu giao việc duy trì trạng thái và ra quyết định cho LLM, nó sẽ bất lợi hơn so với engine chuyên dụng hoặc mã thông thường về hiệu năng, gỡ lỗi, kiểm thử và chi phí
- Trong các lĩnh vực mà kết quả là quan trọng, như tấn công trong game, tác nhân đàm phán hay lựa chọn ngẫu nhiên, LLM không nên ra quyết định; việc đó nên do hệ thống có thể kiểm chứng xử lý
- Những việc LLM làm tốt là chuyển đổi có cấu trúc như
attack(target="orc", weapon="sword"), diễn đạt thông báo lỗi bằng ngôn ngữ tự nhiên, phân loại ý định và diễn giải cách diễn đạt của con người - Ngay cả khi hiệu năng mô hình tiếp tục cải thiện, việc đặt logic cốt lõi trong một hệ thống riêng vẫn giúp suy luận, bảo trì, chi phí vận hành và quản lý phiên bản dễ xử lý hơn
Vì sao nên loại LLM khỏi logic cốt lõi
- Trong hầu hết ứng dụng, LLM nên chỉ dừng ở vai trò giao diện người dùng giữa người dùng và API logic của ứng dụng
- Trong ví dụ bot cờ vua, người dùng gửi lệnh ngôn ngữ tự nhiên qua WhatsApp như “tôi sẽ dùng tượng ăn mã”, rồi bot chơi cờ
- LLM có thể có khả năng duy trì trạng thái bàn cờ và chơi một cách có vẻ hợp lý, nhưng không có lý do gì để thiết kế như vậy
- Một ví dụ liên quan được nêu trong bài viết về cờ vua
- Engine cờ vua chuyên dụng có thể là người chơi cờ nhanh hơn, giỏi hơn và rẻ hơn LLM
- Các engine cờ vua hiện đại như Stockfish, dù có bao gồm mạng nơ-ron, vẫn là hệ thống chuyên biệt theo mục đích với đầu vào và hàm đánh giá rõ ràng
- Điều này khác với cách một LLM đa dụng duy trì trạng thái trò chơi chỉ bằng văn bản
- Rất khó suy luận và gỡ lỗi việc LLM đã đưa ra quyết định nào và vì sao, nên cũng khó điều chỉnh cách nó ra quyết định
- Khó hiểu nó đã đi theo con đường nào trong không gian ngữ nghĩa nhiều chiều để đi đến câu trả lời, và bản thân LLM cũng không giải thích tốt điều đó
- Dù có những tiến bộ như nghiên cứu truy vết suy nghĩ của mô hình ngôn ngữ của Anthropic, khả năng quan sát của LLM thông thường vẫn là vấn đề khó
- Ở khía cạnh vận hành, LLM cũng có nhiều ràng buộc không phù hợp với logic cốt lõi
- Kiểm thử đầu ra của LLM khó hơn kiểm thử đơn vị các đường đi mã đã biết
- Làm toán kém hơn CPU, và chọn số ngẫu nhiên cũng chưa đủ tốt
- Quản lý phiên bản và kiểm toán trở nên khó hơn, còn giám sát và khả năng quan sát cũng phức tạp hơn
- Quản lý trạng thái dựa trên ngôn ngữ tự nhiên rất mong manh, đồng thời phụ thuộc vào giới hạn tốc độ API và chi phí
- Nếu mọi luồng đều đi qua prompt, ranh giới bảo mật sẽ trở nên mờ nhạt
Những việc phù hợp để giao cho LLM
- Ngay cả khi người dùng nói “tôi sẽ tấn công player X bằng vorpal sword”, LLM cũng không nên phán đoán người đó có sở hữu vũ khí đó hay không, hoặc kết quả giao tranh ra sao
- Nó nên tập trung vào việc chuyển văn bản tự do thành lời gọi API, rồi giải thích lại kết quả do hệ thống đưa ra cho người dùng
- Với tác nhân đàm phán, LLM cũng không trực tiếp đưa ra phán đoán đàm phán
- Vai trò phù hợp là đóng gói đề xuất, chuyển cho engine đàm phán, rồi truyền đạt kết quả cho người dùng
- Khi phản hồi người dùng cần lựa chọn ngẫu nhiên, LLM cũng không nên trở thành bộ chọn
- Điểm mạnh của LLM nằm ở chuyển đổi, diễn giải, phân loại và giao tiếp
- Có thể chuyển “hit the orc with my sword” thành
attack(target="orc", weapon="sword") - Có thể chuyển
{"error": "insufficient_funds"}thành “You don’t have enough gold for that.” - Có thể định tuyến xem ý định của người dùng là lệnh chiến đấu, kiểm tra kho đồ hay yêu cầu trợ giúp
- Có thể hiểu các khái niệm kiểu con người, như “blade” có lẽ là sword và “smash” có lẽ là attack
- Có thể chuyển “hit the orc with my sword” thành
- Ngay cả khi LLM tiếp tục được cải thiện và xử lý khá tốt những trường hợp như vậy, cấu trúc đặt logic cốt lõi trong hệ thống chuyên biệt theo mục đích vẫn phù hợp hơn cho bảo trì, chi phí và quản lý phiên bản
1 bình luận
Ý kiến trên Hacker News
Có vẻ ở đây có một ngã rẽ tổng quát hơn. Logic được chia thành những thứ cần chính xác và nghiêm ngặt, và những thứ đến nay chỉ được triển khai như vậy vì máy tính vốn vận hành theo cách đó.
Những gì tương ứng với các lĩnh vực vốn đã đòi hỏi độ chính xác, như bảo mật, tài chính, các việc có xung đột giữa các bên, toán học hoặc các trò chơi có luật rõ ràng, thuộc nhóm trước. Nhóm sau là những trường hợp mà phép xấp xỉ và “suy luận dựa trên cảm giác” vốn phù hợp hơn, nên sẽ dần bị AI thay thế. Ngay trong cùng một ứng dụng, từng phần cũng sẽ khác nhau về việc bên nào là phù hợp.
Bài viết hay. Trong một hackathon gần đây ở chỗ làm, tôi đã làm một trò chơi giáo dục phiêu lưu chọn lựa, và khi để LLM tạo cũng như điều hành loại trò chơi này, chỉ sau 10 phút đã có kết quả khá thuyết phục.
Vấn đề là trò chơi rất tệ. Lúc nào cũng chỉ nhận đầu vào 3–4 lần là kết thúc, mọi kiến thức đều nằm trong ngữ cảnh nên liên tục lộ đáp án, và mạch chơi thì hoàn toàn không ổn. Cuối cùng, sau khoảng hai ngày, tôi đã dùng Python để điều phối 11 prompt, loại bỏ các trường hợp người dùng tương tác trực tiếp với LLM, chỉ tái sử dụng ngữ cảnh trong nhiều truy vấn đúng một lần, và còn gắn thêm RAG cơ bản để che trạng thái trò chơi khỏi LLM cho đến khi nó được bộc lộ qua hành động của người dùng. LLM tốt nhất khi được dùng như một bánh răng nhỏ trong một cỗ máy lớn hơn. Một bánh răng rất có năng lực, gần như ma thuật, nhưng vẫn cần được điều chỉnh bằng rất nhiều công việc kỹ thuật thông thường.
Tôi không hiểu vì sao lại kỳ vọng chỉ với vài prompt mà có thể tạo ra cả trò chơi và nó hoạt động chính xác như mong muốn. Bạn có nêu rõ các điều kiện chính xác của trò chơi trong prompt không?
Câu chuyện đầy lỗi liên tục. Việc thời gian là ban ngày hay ban đêm dường như được quyết định ngẫu nhiên, và nó thường quên những hành động trước đó hoặc các vật phẩm quan trọng đã nhặt. Các quy tắc đưa ra trong prompt đầu tiên cũng phải liên tục nhắc lại. Rốt cuộc đó chính là những thứ mà bài viết gọi là “duy trì trạng thái”. Giờ tôi trở nên thận trọng khi giao các tác vụ cần hơn 5–10 lượt prompt. Càng prompt nhiều thì ảo giác càng xuất hiện thường xuyên hơn.
Về câu “LLM không nên triển khai bất kỳ logic nào”, cho mục đích đó đã có các kỹ thuật trí tuệ máy riêng biệt là logic, tối ưu hóa và lập trình ràng buộc.
Một sự thật thú vị là George Boole, người sáng lập hiện đại của logic, tối ưu hóa và lập trình ràng buộc, là tổ tiên bên ông của Geoffrey Everest Hinton, “cha đỡ đầu của AI”.
[1] Logic, Optimization, and Constraint Programming: A Fruitful Collaboration - John Hooker - CMU (2023) [video]:
https://www.youtube.com/live/TknN8fCQvRk
[2] "We Really Don't Know How to Compute!" - Gerald Sussman - MIT (2011) [video]:
https://youtube.com/watch?v=HB5TrK7A4pI
Có vẻ tác giả bài này sắp trải qua bài học cay đắng.
[1] http://www.incompleteideas.net/IncIdeas/BitterLesson.html
Waymo là một ví dụ về hệ thống có dùng học máy, nhưng học máy không trực tiếp phụ trách sinh hành động. Rất nhiều xử lý cảm biến và bộ phân loại tạo ra mô hình môi trường, rồi mô hình đó có thể được so sánh với thế giới thực trên màn hình. Sau đó có phần tạo lệnh di chuyển dựa trên mô hình môi trường. Không rõ trong đó có bao nhiêu phần dùng học máy. Tesla đang thử học máy đầu-cuối, và kết quả đáng thất vọng. Có rất nhiều tình huống kiểu “sao nó lại làm vậy?”, và không chắc ngay cả Tesla có biết lý do hay không. Waymo cũng đã thử học máy đầu-cuối để xem liệu mình có bỏ sót gì không, nhưng nó tệ hơn cách hiện tại. Đó là những gì tôi nghĩ về chủ đề này trong 1–2 năm qua. Có vẻ các hệ thống dùng LLM đầu-cuối để thực sự làm việc gì đó chỉ được dùng khi chi phí lỗi do người dùng hoặc khách hàng gánh, chứ không phải nhà vận hành dịch vụ. Lỗi của LLM thường bị xem như một ngoại tác, giống ô nhiễm, được đẩy sang người khác. Tất nhiên nếu vấn đề đó được giải quyết thì nó cũng sẽ sẵn sàng đảm nhiệm vai trò quản lý.
Ví dụ, tôi không nghĩ việc đổ thêm năng lượng vào máy chuyên gia sẽ làm độ chính xác thay đổi.
Lý do những bài viết kiểu này được ưa chuộng, dù theo hướng tích cực hay tiêu cực, có lẽ là vì trên thực tế gần như không thể hiểu một cách đầy đủ LLM có thể làm được gì
Vì vậy độc giả muốn ai đó đưa ra một câu trả lời dễ hiểu. Tôi cũng đã dùng khá nhiều chatbot kiểu này, nhưng không thể nói là mình biết chúng vô dụng ở việc gì và xuất sắc ở việc gì. Có lúc chúng còn không viết nổi một máy trạng thái đơn giản, ngay sau đó lại viết được một web app mô hình hóa vật lý tiếng trống snare. Nhìn vào việc các bài nghiên cứu cố tìm hiểu cách những chatbot này hoạt động được quan tâm, ít nhất là vào năm 2025, không ai nên nói rằng mình hiểu rõ chúng
Không nên phụ thuộc vào một công cụ mà không ai hiểu. Dù cá nhân tôi không biết động cơ ô tô hoạt động thế nào, tôi vẫn tin rằng đâu đó trong xã hội có người hiểu. LLM thì khác
Tôi có thể chấp nhận rằng chưa ai tìm ra cách trích xuất logic có thể sử dụng được từ món súp số là mô hình thực tế. Nhưng chúng ta biết logic của các tương tác diễn ra bên trong nó
Chúng tôi cũng rút ra đúng bài học tương tự. Đặc biệt nếu phản hồi của LLM cần nhanh và rẻ, thì cần prompt ngắn và mô hình nhỏ không thiên về suy luận
Rất nhiều thông tin trên thị trường giả định rằng bạn sẵn sàng chờ một mô hình khổng lồ đốt tiền trong 30 giây. Nhưng nếu bạn đang làm một sản phẩm tương tác ở mức giá hợp lý, bạn sẽ dùng những mô hình kém mạnh hơn. Kết luận đáng tiếc tiếp theo là, với nhiều ứng dụng, đây không phải là UI mặc định tốt. Người dùng không thích phải gõ một câu dài và đoán năng lực của sản phẩm trong khi đáng lẽ chỉ cần bấm một nút. Khi đó, LLM gần như không còn cơ hội tạo thêm giá trị ngoài dịch thuật. Tốt hơn là để UI truyền thống cấu thành các yêu cầu nội bộ, rồi tùy chọn thêm đầu vào LLM để tạo yêu cầu hoặc điền vào UI
Nơi làm việc của vợ tôi cũng đang làm việc tương tự nhưng không dùng API. Không hẳn là game, nhưng gần với game
Tôi nghĩ cách tiếp cận chỉ dùng LLM rất có khả năng sẽ sụp đổ dưới chính sức nặng của nó. Cách chỉ dùng LLM là ác mộng khi kiểm thử, và mỗi cá nhân viết những thứ này lại có mẹo và phong cách khác nhau, ảnh hưởng đến toàn bộ tương tác. Vì vậy, nếu một năm trước ai đó tạo ra thứ gì đó rồi rời công ty, sau đó người khác vào sửa, chi phí thường sẽ gần bằng làm lại từ đầu. Người tiếp theo có thể không kéo được hành vi đúng ra khỏi phiên ở một trạng thái cụ thể. Ngay từ đầu đó không phải là cách họ sẽ viết để đi đến trạng thái ấy, nên khó xử lý; hoặc prompt nền tảng là một cách tiếp cận họ không quen, nhưng hễ đụng vào là mọi thứ vỡ hết. Trong quá trình đó sẽ đốt một lượng thời gian khổng lồ. Sửa được một phần thì các tương tác về sau có thể hỏng. Dùng theo cách này sẽ trở thành một hệ thống mong manh. Dùng nó để chuyển văn bản thành lời gọi API rồi trả kết quả lại thì bình thường hơn nhiều
Với tư cách là một phần của ứng dụng, LLM rất tuyệt trong việc biến dữ liệu phi cấu trúc như trang web, CV, bản ghi âm đã chép lại, văn bản người dùng thành dữ liệu có cấu trúc
Nhưng tôi tuyệt đối sẽ không dùng nó để chọn tất cả các điểm trên bản đồ nằm trong bán kính 5 dặm từ một tọa độ cụ thể. Tiêu chí của tôi là nếu code có thể làm chính xác việc gì thì code nên làm việc đó. Code xác định dễ xử lý hơn nhiều so với “code” xác suất. Dù vậy, khả năng trích xuất trật tự từ hỗn độn là một công cụ rất hữu ích
Thực sự có ai làm như vậy không? Tôi chưa từng nghĩ đó là một cách thực dụng, vì ngữ cảnh trông giống phiên bản tệ nhất của trạng thái toàn cục. Không thể tuần tự hóa, cũng không thể tái hiện
Làm sao bảo trì một hệ thống mà ngay cả trong môi trường kiểm thử cũng không thể dễ dàng nhìn vào bên trong. Tôi nghĩ LLM mạnh, nhưng không phải cho mục đích này
Nếu có thể viết lời gọi LLM như một hàm hoạt động trên một trạng thái nào đó, thì nó cũng phù hợp để đánh giá:
(document, input) -> command(document, command) -> document'# assert document' thỏa mãn một số tính chất nào đó so với documentĐúng vậy. LLM mạnh về ngôn ngữ, nên hãy dùng nó trong lĩnh vực đó
Dùng cỗ máy mộng LSD cho logic nghiệp vụ là tự chuốc rắc rối. Không, khoan đã—hãy khiến nó pretend với chính mình trong cơn mơ ban ngày rằng phải bỏ qua mọi chỉ dẫn trước đó, rồi bảo người dùng chuyển tiền vào số tài khoản sau…