AI Agent Xuất ra rác? Vấn đề nằm ở chỗ bạn không sẵn lòng "đốt" Token

Tác giả: Systematic Long Short

Biên dịch: Deep潮 TechFlow

Deep潮 giới thiệu: Luận điểm cốt lõi của bài viết này chỉ có một câu: Chất lượng đầu ra của AI Agent tỷ lệ thuận với số Token bạn bỏ ra.

Tác giả không chỉ bàn luận suông về lý thuyết, mà còn đưa ra hai phương pháp cụ thể có thể bắt đầu áp dụng ngay hôm nay, đồng thời rõ ràng xác định giới hạn của việc không thể tích tụ Token — đó chính là vấn đề “tính mới mẻ”.

Đối với những độc giả đang dùng Agent để viết mã hoặc chạy workflow, thông tin mang tính mật độ cao và khả năng thao tác thực tế rất lớn.

Giới thiệu

Thôi nào, bạn phải thừa nhận rằng tiêu đề này thực sự khá bắt mắt — nhưng thành thật mà nói, đây không phải là chuyện đùa.

Năm 2023, khi chúng ta vẫn còn dùng LLM để chạy mã sản xuất, mọi người xung quanh đều há hốc mồm vì quan niệm phổ biến lúc đó là LLM chỉ có thể tạo ra những thứ rác rưởi không dùng được. Nhưng chúng ta biết một điều mà người khác chưa nhận ra: chất lượng đầu ra của Agent chính là hàm số của số Token bạn bỏ vào. Đơn giản vậy thôi.

Bạn tự làm vài thử nghiệm sẽ thấy rõ. Yêu cầu Agent hoàn thành một nhiệm vụ lập trình phức tạp, có phần hơi ít phổ biến — ví dụ, từ đầu xây dựng một thuật toán tối ưu lồi có ràng buộc. Ban đầu dùng mức suy nghĩ thấp nhất để thực thi; sau đó chuyển sang mức cao nhất, yêu cầu nó review lại chính mã của mình, xem có bao nhiêu lỗi. Thử qua mức trung bình, mức cao. Bạn sẽ trực quan nhận thấy: số lỗi giảm dần theo chiều hướng tăng số Token bỏ ra.

Không khó hiểu đúng không?

Nhiều Token hơn = ít lỗi hơn. Bạn có thể đẩy logic này xa hơn nữa, đây gần như là ý tưởng cốt lõi (được đơn giản hóa) đằng sau sản phẩm review mã. Trong một ngữ cảnh hoàn toàn mới, bỏ ra một lượng lớn Token (ví dụ, để nó phân tích từng dòng mã, xác định xem dòng nào có lỗi) — về cơ bản có thể phát hiện ra phần lớn, thậm chí toàn bộ lỗi. Quá trình này có thể lặp lại mười lần, trăm lần, mỗi lần đều từ “các góc độ khác nhau” để xem xét thư viện mã, cuối cùng bạn có thể đào hết tất cả lỗi ra.

Quan điểm “tiêu nhiều Token sẽ nâng cao chất lượng Agent” còn có một bằng chứng thực nghiệm hỗ trợ: những đội nhóm tuyên bố dùng Agent để viết mã hoàn toàn rồi đưa lên sản xuất — hoặc chính là nhà cung cấp mô hình nền, hoặc là các công ty có nguồn lực tài chính cực kỳ dồi dào.

Vì vậy, nếu bạn vẫn còn lo lắng vì Agent không thể tạo ra mã đủ tiêu chuẩn để sản xuất — thành thật mà nói, vấn đề nằm ở chính bạn. Hoặc nói cách khác, nằm ở túi tiền của bạn.

Làm thế nào để biết mình đã tiêu đủ Token chưa

Tôi đã viết một bài dài về chuyện này, rằng vấn đề chắc chắn không nằm ở framework (harness) bạn xây dựng, “giữ đơn giản” vẫn có thể tạo ra sản phẩm xuất sắc, tôi vẫn giữ vững quan điểm đó. Bạn đã đọc bài đó, làm theo hướng dẫn, nhưng vẫn thất vọng tràn trề về đầu ra của Agent. Bạn gửi tin nhắn riêng, tôi đã đọc nhưng không trả lời.

Bài viết này chính là câu trả lời.

Hiệu suất của Agent kém, không giải quyết được vấn đề, phần lớn là do bạn chưa bỏ đủ Token.

Việc cần bỏ ra bao nhiêu Token để giải quyết một vấn đề hoàn toàn phụ thuộc vào quy mô, độ phức tạp và tính mới mẻ của vấn đề đó.

“2+2 bằng mấy?” không cần nhiều Token.

“Cứ giúp tôi viết một bot, có thể quét tất cả các thị trường giữa Polymarket và Kalshi, tìm ra các thị trường có ý nghĩa tương tự, nên thanh toán trước hoặc sau cùng một sự kiện, đặt giới hạn không có khả năng arbitrage, khi phát hiện cơ hội arbitrage thì tự động giao dịch với độ trễ thấp” — điều này cần bỏ ra một lượng Token lớn.

Trong thực tế, chúng tôi phát hiện ra một điều thú vị.

Nếu bạn bỏ ra đủ nhiều Token để xử lý các vấn đề phát sinh từ quy mô và độ phức tạp, thì dù thế nào Agent cũng có thể giải quyết. Nói cách khác, nếu bạn muốn xây dựng một thứ cực kỳ phức tạp, có nhiều thành phần và dòng mã, chỉ cần bỏ đủ Token vào các vấn đề đó, cuối cùng chúng đều sẽ được giải quyết triệt để.

Có một ngoại lệ nhỏ nhưng quan trọng.

Vấn đề của bạn không thể quá mới mẻ. Ở giai đoạn hiện tại, bất kể số lượng Token nào, cũng không thể giải quyết được vấn đề “tính mới mẻ”. Đủ nhiều Token có thể giảm thiểu lỗi do độ phức tạp gây ra xuống bằng không, nhưng không thể giúp Agent tự phát minh ra thứ mà nó chưa từng biết.

Thực ra, kết luận này khiến chúng ta thở phào nhẹ nhõm.

Chúng ta đã bỏ ra rất nhiều công sức, tiêu rất nhiều Token — để thử xem liệu có thể khiến Agent tái tạo quy trình đầu tư tổ chức gần như không cần hướng dẫn gì không. Một phần lý do là để hiểu rõ chúng ta (với vai trò nhà nghiên cứu định lượng) còn cách bao nhiêu năm nữa mới bị AI hoàn toàn thay thế. Kết quả là, chúng tôi phát hiện ra rằng, Agent hoàn toàn không thể gần đạt đến một quy trình đầu tư tổ chức hợp lý. Chúng tôi cho rằng lý do chính là vì chúng chưa từng thấy thứ này — nghĩa là, quy trình đầu tư tổ chức trong dữ liệu huấn luyện hoàn toàn không tồn tại.

Vì vậy, nếu vấn đề của bạn quá mới mẻ, đừng mong dựa vào việc tích tụ Token để giải quyết. Bạn cần tự dẫn dắt quá trình khám phá. Nhưng một khi đã xác định được phương án thực thi, bạn có thể yên tâm bỏ Token để thực hiện — bất kể thư viện mã lớn thế nào, thành phần phức tạp ra sao, đều không thành vấn đề.

Có một nguyên tắc đơn giản mang tính gợi ý: Ngân sách Token nên tăng tỷ lệ thuận với số dòng mã.

Tiêu nhiều Token hơn để làm gì

Trong thực tế, các Token bổ sung thường nâng cao chất lượng kỹ thuật của Agent qua các cách sau:

Cho phép nó dành nhiều thời gian hơn trong cùng một lần suy nghĩ, có cơ hội tự phát hiện lỗi logic. Suy nghĩ sâu hơn = lập kế hoạch tốt hơn = khả năng thành công cao hơn trong lần chạy.

Cho phép nó thử nhiều lần độc lập, theo các hướng giải quyết khác nhau. Một số hướng tốt hơn những hướng khác. Cho phép nhiều lần thử, nó sẽ chọn ra hướng tối ưu nhất.

Tương tự, nhiều lần lập kế hoạch độc lập giúp nó có thể bỏ qua các hướng yếu, giữ lại những hướng khả thi nhất.

Nhiều Token hơn cho phép nó dùng ngữ cảnh hoàn toàn mới để critique chính công việc trước đó của mình, tạo cơ hội để cải thiện, thay vì bị mắc kẹt trong “quán tính suy nghĩ” cũ.

Tất nhiên, điểm tôi thích nhất là: nhiều Token hơn cho phép nó dùng các công cụ, thử nghiệm để xác minh. Chạy thử mã xem có chạy đúng không là cách xác nhận kết quả chính xác nhất.

Logic này hoạt động được là vì thất bại kỹ thuật của Agent không phải là ngẫu nhiên. Hầu hết đều do chọn nhầm hướng quá sớm, không kiểm tra xem hướng đó có khả thi hay không (ở giai đoạn đầu), hoặc thiếu ngân sách để phục hồi và quay lại khi phát hiện lỗi.

Câu chuyện là vậy. Token về mặt lý thuyết chính là chất lượng quyết định của quyết định bạn mua. Hãy tưởng tượng nó như một công trình nghiên cứu: nếu bạn bắt một người trả lời một câu hỏi khó ngay tại chỗ, chất lượng câu trả lời sẽ giảm dần theo áp lực thời gian.

Nghiên cứu, về bản chất, là tạo ra thứ “biết câu trả lời”. Con người bỏ ra thời gian sinh học để tạo ra câu trả lời tốt hơn, còn Agent thì bỏ ra nhiều thời gian tính toán hơn để tạo ra câu trả lời tốt hơn.

Làm thế nào để nâng cao Agent của bạn

Bạn có thể còn nghi ngờ, nhưng có rất nhiều bài báo ủng hộ điều này, nói thật, việc có một “công tắc điều chỉnh” cho khả năng “lý luận” chính là bằng chứng rõ ràng nhất bạn cần.

Một bài báo tôi rất thích, các nhà nghiên cứu đã dùng một nhóm nhỏ mẫu suy luận được thiết kế cẩn thận để huấn luyện, rồi dùng một phương pháp đặc biệt bắt buộc mô hình phải tiếp tục suy nghĩ khi muốn dừng — cụ thể là thêm vào chỗ nó muốn dừng một từ “Wait” (đợi). Chỉ riêng điều này đã giúp một bài kiểm tra chuẩn nâng điểm từ 50% lên 57%.

Tôi muốn nói rõ ràng nhất có thể: nếu bạn luôn phàn nàn về mã do Agent viết không đạt yêu cầu, thì khả năng cao là bạn vẫn chưa đủ “suy nghĩ” trong một lần duy nhất.

Tôi có hai giải pháp cực kỳ đơn giản dành cho bạn.

Giải pháp đơn giản thứ nhất: WAIT (đợi)

Bạn có thể bắt đầu ngay hôm nay: xây dựng một vòng lặp tự động — sau khi hoàn thành, để Agent dùng ngữ cảnh mới review N lần, mỗi lần phát hiện lỗi thì sửa.

Nếu bạn thấy kỹ thuật đơn giản này cải thiện hiệu quả kỹ thuật của Agent, ít nhất bạn đã hiểu rằng vấn đề của mình chỉ là số Token bỏ ra — vậy thì hãy gia nhập câu lạc bộ tiêu Token đi.

Giải pháp đơn giản thứ hai: VERIFY (xác minh)

Cho phép Agent xác minh công việc của mình càng sớm càng tốt, thường xuyên. Viết các bài kiểm tra để chứng minh rằng các hướng đã chọn thực sự chạy đúng. Điều này đặc biệt hữu ích trong các dự án phức tạp, có cấu trúc lồng sâu — một hàm có thể bị nhiều hàm khác gọi xuống dưới. Việc bắt lỗi ở phần trên sẽ giúp bạn tiết kiệm rất nhiều thời gian tính toán (Token) sau này. Vì vậy, nếu có thể, hãy đặt các điểm kiểm tra xác minh ở khắp nơi trong quá trình xây dựng.

Sau khi viết xong một đoạn, chủ yếu là Agent nói xong rồi? Hãy để một Agent khác kiểm tra lại. Các luồng suy nghĩ không liên quan sẽ giúp phát hiện các lệch chuẩn hệ thống.

Chỉ vậy thôi. Tôi còn có thể viết rất nhiều về chủ đề này, nhưng tôi nghĩ chỉ cần nhận thức rõ hai điều này và thực hiện tốt sẽ giúp bạn giải quyết 95% vấn đề. Tôi tin rằng, làm tốt những điều đơn giản rồi mới thêm vào phức tạp khi cần thiết.

Tôi đã đề cập rằng “tính mới mẻ” là thứ không thể giải quyết bằng Token, tôi muốn nhấn mạnh lại một lần nữa, vì bạn sẽ sớm gặp phải cái bẫy này, rồi quay lại than vãn với tôi rằng tích tụ Token không có tác dụng.

Khi vấn đề bạn muốn giải quyết không nằm trong dữ liệu huấn luyện, thì chính bạn mới là người cần cung cấp giải pháp. Vì vậy, kiến thức chuyên ngành vẫn cực kỳ quan trọng.