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

Vấn đề không nằm ở câu lệnh gợi ý!

Tác giả: Systematic Long Short

Biên dịch: Deep潮 TechFlow

**Deep潮 Đạo Độc: **Bản chất 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 chung chung về lý thuyết, mà đư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 — đó là “Vấn đề tính mới”.

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

Giới thiệu

Thôi thì, bạn phải thừa nhận tiêu đề này thực sự khá hấp dẫn — nhưng thật lòng, đây không phải 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 ngạc nhiên vì theo nhận thức phổ biến thì LLM chỉ có thể tạo ra đống rác 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 là hàm số của số Token bạn bỏ ra. Đơn giản vậy thôi.

Chỉ cần tự làm vài thử nghiệm là 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 ít phổ biến — ví dụ, tự xây dựng một thuật toán tối ưu lồi có ràng buộc từ đầu. Ban đầu dùng mức độ suy nghĩ thấp nhất; sau đó chuyển sang mức cao hơn, yêu cầu nó review lại chính mã của mình, xem có bug nào không. Thử qua các mức trung bình, cao hơn nữa. Bạn sẽ thấy rõ ràng: số lượng bug giảm dần theo 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, đó chính là ý tưởng cốt lõi đằng sau sản phẩm review mã. Trong một ngữ cảnh hoàn toàn mới, bỏ ra lượng Token lớn (ví dụ, để nó phân tích từng dòng mã, xác định xem dòng nào có bug) — cơ bản có thể phát hiện hầu hết, thậm chí tất cả bug. Quá trình này có thể lặp lại 10, 100 lần, mỗi lần từ một góc nhìn khác nhau về codebase, cuối cùng bạn có thể “sạch” bug.

Quan điểm “Tiêu nhiều Token hơn để nâng cao chất lượng Agent” còn có bằng chứng thực nghiệm: những nhóm tuyên bố dùng Agent để viết mã trực tiếp đưa lên production, hoặc 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 dồi dào.

Vậy nên, nếu bạn vẫn còn lo lắng về việc Agent không thể tạo ra mã đủ chuẩn để đưa vào 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 sao 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 đề không nằm ở framework (harness) của bạn — “giữ đơn giản” vẫn có thể tạo ra sản phẩm tốt, tôi vẫn giữ vững quan điểm đó. Bạn đã đọc bài đó, làm theo, nhưng vẫn thất vọng về output của Agent. Bạn gửi tin nhắn riêng, tôi đã đọc nhưng chưa trả lời.

Bài 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 của vấn đề đó.

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

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

Trong thực tế, chúng tôi nhận thấy 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ì Agent dù thế nào 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 hệ thống cực kỳ phức tạp, có nhiều thành phần, nhiều dòng mã — chỉ cần bỏ đủ Token vào các vấn đề này, 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ể lượng Token nào cũng không thể giải quyết “Vấn đề tính mới”. Đủ nhiều Token có thể giảm thiểu lỗi do độ phức tạp gây ra xuống bằng 0, 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ể để Agent tái tạo quy trình đầu tư tổ chức gần như không cần hướng dẫn hay không. Một phần lý do là để hiểu rõ chúng ta (những nhà nghiên cứu định lượng) còn cách bị AI hoàn toàn thay thế bao xa. Kết quả là, Agent hoàn toàn không thể gần đạt được một quy trình đầu tư tổ chức hợp lý. Chúng tôi nghĩ lý do chính là vì chúng chưa từng thấy thứ này — tức 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ậy nên, nếu vấn đề của bạn là tính mới, đừng mong đợi có thể giải quyết chỉ bằng cách tích tụ Token. 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 vào để thực hiện — bất kể codebase lớn hay thành phần phức tạp đến đâu.

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ế, 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.

Cho phép nó thử nhiều lần độc lập, theo các hướng giải pháp khác nhau. Một số hướng tốt hơn 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 thử độc lập giúp nó có thể bỏ qua các hướng yếu, giữ lại các hướng khả thi nhất.

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

Và tất nhiên, điều tôi thích nhất: nhiều Token hơn nghĩa là nó có thể dùng các công cụ, test để 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 vì thất bại kỹ thuật của Agent không phải ngẫu nhiên. Hầu hết đều do chọn sai 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, quay lại khi phát hiện lỗi.

Câu chuyện thế đấy. Token theo nghĩa đen chính là quyết định chất lượng mà bạn “mua” được. Hãy tưởng tượng như một công trình nghiên cứu: nếu bạn để một người trả lời một câu hỏi khó trong thời gian hạn 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ề cơ bản, 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 hiệu quả của Agent

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ẳng ra, việc điều chỉnh “quy trình suy nghĩ” chính là bằng chứng rõ ràng nhất bạn cần.

Một bài nghiên cứu tôi rất thích, dùng một nhóm nhỏ các mẫu suy nghĩ được thiết kế cẩn thận để huấn luyện, rồi dùng một phương pháp bắt buộc mô hình tiếp tục suy nghĩ khi muốn dừng — cụ thể là thêm “Wait” (đợi) ở chỗ nó muốn dừng. 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 thẳng: nếu bạn cứ than phiền về mã của Agent không tốt, thì khả năng cao là do bạn chưa đủ suy nghĩ sâu. Độ suy nghĩ tối đa trong một lần chưa đủ.

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

Giải pháp đơn giản 1: 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ả của Agent, ít nhất bạn đã hiểu vấn đề của mình chỉ là thiếu Token — vậy thì hãy gia nhập câu lạc bộ tiêu Token đi.

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

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

Sau khi hoàn thành một đoạn, nếu chính Agent nói đã xong, 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 hành tốt, bạn sẽ giải quyết được 95% vấn đề. Tôi tin rằng, làm đơn giản thật tốt rồi mới thêm phức tạp khi cần thiết.

Tôi đã nhấn mạnh rằng “tính mới” là thứ không thể giải quyết chỉ bằng Token, tôi muốn nhấn mạnh lại, vì bạn sẽ gặp phải cái bẫy này sớm thôi, rồi than vãn 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.