Chất lượng đầu ra của tác nhân AI có liên quan đến việc đốt token

Tác giả: Systematic Long Short

Biên dịch: Deep潮 TechFlow

DeepChao dẫn nhập: Luận điểm chính của bài viết này chỉ gồm một câu: Chất lượng đầu ra của AI Agent tỷ lệ thuận với số lượng Token bạn đầu tư.

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

Đối với độc giả đang dùng Agent để viết mã hoặc chạy quy trình làm việc, mật độ thông tin và tính khả thi都非常 cao.

Được rồi, bạn phải thừa nhận tiêu đề này thực sự rất thu hút sự chú ý—nhưng thật lòng mà nói, đây không phải là trò đùa.

Năm 2023, khi chúng tôi vẫn đang sử dụng LLM để chạy mã sản xuất, mọi người xung quanh đều kinh ngạc, vì lúc đó quan điểm phổ biến là LLM chỉ có thể tạo ra những thứ vô dụng. Nhưng chúng tôi 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ố lượng Token bạn đầu tư. Đơn giản vậy thôi.

Bạn có thể tự chạy vài thí nghiệm để thấy rõ điều này. Hãy yêu cầu Agent thực hiện một nhiệm vụ lập trình phức tạp và tương đối í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. Trước tiên, sử dụng mức suy nghĩ thấp nhất; sau đó chuyển sang mức suy nghĩ cao nhất, để nó kiểm tra lại mã của mình và xem có thể phát hiện được bao nhiêu lỗi. Thử cả các mức trung bình và cao. Bạn sẽ trực quan nhận thấy: số lượng lỗi giảm dần một cách đơn điệu theo lượng Token được đầu tư.

This isn't hard to understand, right?

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

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

Vì vậy, nếu bạn vẫn đang băn khoăn vì Agent không thể tạo ra mã sản xuất — nói một cách thẳng thắn, vấn đề nằm ở chính bạn. Hoặc nói cách khác, nằm ở ví của bạn.

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

This is the reply.

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

Số lượng Token cần đầu tư để 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.

Hãy 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 những thị trường có ý nghĩa tương đồng và nên được thanh toán cùng một sự kiện, thiết lập ranh giới không arbitrage, và tự động giao dịch ngay khi phát hiện cơ hội arbitrage với độ trễ thấp — điều này sẽ tốn rất nhiều Token.

Chúng tôi đã phát hiện ra một điều thú vị trong thực tế.

Nếu bạn đầu tư đủ nhiều Token để xử lý các vấn đề phát sinh từ quy mô và độ phức tạp, thì Agent nhất định sẽ giải quyết được. 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 với nhiều thành phần và dòng mã, chỉ cần ném đủ nhiều Token vào những vấn đề này, chúng cuối cùng đều sẽ được giải quyết triệt để.

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

Câu hỏi 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 vấn đề “tính mới mẻ”. Một lượng Token đủ lớn có thể giảm lỗi do độ phức tạp gây ra về gần như bằng không, nhưng không thể khiến Agent tự sáng tạo ra những điều nó không biết.

Kết luận này thực sự khiến chúng ta nhẹ nhõm.

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

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

Có một nguyên tắc heuristics đơn giản: Ngân sách token nên tăng tỷ lệ thuận với số dòng mã.

Trong thực tế, các Token bổ sung thường nâng cao chất lượng dự án của Agent thông qua một số cách sau:

Hãy để nó dành nhiều thời gian hơn để suy luận trong cùng một lần cố gắng, tạo cơ hội tự phát hiện các lỗi logic. Suy luận càng sâu sắc = Kế hoạch càng tốt = Xác suất thành công ngay lần đầu càng cao.

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

Tương tự, nhiều nỗ lực lập kế hoạch độc lập nhằm giúp nó từ bỏ các hướng yếu và giữ lại những hướng đầy hứa hẹn nhất.

Nhiều token hơn cho phép nó tự đánh giá lại công việc trước đó trong bối cảnh hoàn toàn mới, tạo cơ hội cải thiện thay vì bị kẹt trong một “sức ì suy luận” nào đó.

Tất nhiên, điểm tôi thích nhất là: nhiều token hơn có nghĩa là nó có thể được xác minh bằng các bài kiểm tra và công cụ. Việc chạy mã thực tế để xem nó có hoạt động không là cách đáng tin cậy nhất để xác nhận câu trả lời đúng.

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

Câu chuyện là vậy. Token về mặt chữ nghĩa chính là chất lượng quyết định bạn mua được. Hãy tưởng tượng nó như một công việc nghiên cứu: nếu bạn yêu cầu 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 xuống khi áp lực thời gian tăng lên.

Nghiên cứu, về cơ bản, là thứ tạo ra nền tảng của việc “biết câu trả lời”. Con người dành thời gian về mặt sinh học để tạo ra những câu trả lời tốt hơn, trong khi Agent dành nhiều thời gian tính toán hơn để tạo ra những câu trả lời tốt hơn.

Bạn có thể vẫn còn nghi ngờ, nhưng có rất nhiều bài báo nghiên cứu ủng hộ điều này; thật ra, sự tồn tại của nút điều chỉnh "suy luận" chính là bằng chứng đầy đủ mà bạn cần.

Một bài báo tôi đặc biệt yêu thích, các nhà nghiên cứu đã huấn luyện bằng một lượng nhỏ các mẫu suy luận được lựa chọn cẩn thận, sau đó sử dụng một phương pháp buộc mô hình tiếp tục suy nghĩ khi nó muốn dừng lại—cụ thể là thêm từ “Wait” (chờ đã) vào vị trí mà nó định dừng. Chỉ riêng thao tác này đã giúp một bài kiểm tra chuẩn tăng từ 50% lên 57%.

Tôi muốn nói một cách trực tiếp nhất: Nếu bạn luôn phàn nàn về mã do Agent viết ra chưa tốt, thì mức suy nghĩ cao nhất trong một lần có lẽ vẫn chưa đủ với bạn.

Tôi đưa cho bạn hai giải pháp rất đơn giản.

Cách đơn giản thứ nhất: WAIT (chờ)

Việc đơn giản nhất bạn có thể bắt đầu làm ngay hôm nay: thiết lập một chu trình tự động — sau khi xây dựng xong, để Agent xem lại N lần với ngữ cảnh mới mỗi lần, và sửa lỗi khi phát hiện.

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

Cách đơn giản thứ hai: VERIFY (Xác minh)

Hãy để Agent xác minh công việc của mình càng sớm và thường xuyên càng tốt. Viết các bài kiểm tra để chứng minh rằng con đường đã chọn thực sự hoạt động được. Điều này đặc biệt hữu ích cho các dự án phức tạp cao và có độ sâu lồng ghép lớn—một hàm có thể được nhiều hàm khác ở phía dưới gọi đến. Việc phát hiện lỗi ở giai đoạn đầu sẽ giúp bạn tiết kiệm rất nhiều thời gian tính toán (Token) về sau. 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 suốt quá trình xây dựng.

Sau khi hoàn thành một đoạn nội dung, agent chính nói đã xong? Hãy để agent thứ hai xác minh lại. Dòng suy nghĩ không liên quan có thể che phủ nguồn gốc của sự thiên lệch hệ thống.

Chỉ có vậy thôi. Tôi có thể viết nhiều hơn về chủ đề này, nhưng tôi tin rằng chỉ cần nhận thức được hai điều này và thực thi chúng một cách bài bản, bạn sẽ giải quyết được 95% vấn đề. Tôi tin tưởng mạnh mẽ vào việc làm thật xuất sắc những điều đơn giản, rồi mới từ từ bổ sung độ phức tạp khi cần thiết.

Tôi đã nhắc đến tính mới mẻ là vấn đề 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ớm muộn gì cũng sẽ gặp phải cái bẫy này, rồi đến than thở với tôi rằng việc tích lũy Token không có tác dụng.

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