AI Agent xuất ra rác? Vấn đề nằm ở chỗ bạn tiếc token để đốt!
Tuyển chọn TechFlowTuyển chọn TechFlow
AI Agent xuất ra rác? Vấn đề nằm ở chỗ bạn tiếc token để đốt!
Vấn đề không nằm ở prompt!
Chuyên sâu báo cáo Web3Tác giả: Systematic Long Short
Biên dịch: TechFlow
Dẫn nhập từ TechFlow: Luận điểm cốt lõi của bài viết này chỉ gói gọn trong một câu: Chất lượng đầu ra của Agent AI tỷ lệ thuận với số lượng token bạn đầu tư vào.
Tác giả không chỉ bàn luận chung chung trên lý thuyết, mà còn đưa ra hai phương pháp cụ thể — có thể áp dụng ngay hôm nay — đồng thời xác định rõ ranh giới mà việc “chồng token” không thể vượt qua: vấn đề “tính mới”.
Với độc giả đang sử dụng Agent để viết mã hoặc chạy quy trình công việc, bài viết này vừa giàu thông tin vừa cực kỳ khả thi.
Lời mở đầu
Thôi nào, bạn phải thừa nhận tiêu đề này thực sự gây tò mò — nhưng thật lòng mà nói, đây hoàn toàn không phải trò đùa.
Năm 2023, khi chúng tôi vẫn đang dùng LLM để sản xuất mã thực tế, những người xung quanh đều há hốc mồm kinh ngạc, bởi lúc ấy quan niệm phổ biến vẫn cho rằng LLM chỉ tạo ra rác thải không thể sử 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ố token bạn đầu tư vào. Đơn giản vậy thôi.
Bạn chỉ cần tự chạy vài thí nghiệm là sẽ thấy rõ. Hãy yêu cầu Agent giải quyết một nhiệm vụ lập trình phức tạp và khá chuyên biệt — ví dụ như triển khai từ đầu một thuật toán tối ưu lồi có ràng buộc. Đầu tiên, chạy ở mức độ suy luận thấp nhất; sau đó chuyển sang mức cao nhất, để Agent tự kiểm tra lại mã của chính mình và xem nó phát hiện được bao nhiêu lỗi. Thử cả mức trung bình và mức cao. Bạn sẽ trực quan cảm nhận được: Số lỗi giảm đơn điệu khi số token đầu tư tăng lên.
Điều này dễ hiểu, đúng không?
Càng nhiều token = càng ít lỗi. Bạn có thể đẩy lập luận này xa hơn một chút — đây cơ bản chính là tư tưởng cốt lõi (đã được đơn giản hóa) đứng sau các sản phẩm kiểm tra mã (code review). Trong một ngữ cảnh hoàn toàn mới, đầu tư một lượng token khổng lồ (ví dụ: yêu cầu Agent phân tích từng dòng mã và đánh giá xem từng dòng có lỗi hay không) — cách làm này gần như có thể bắt được 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, một trăm lần, mỗi lần đều “nhìn” kho mã từ một “góc độ” khác nhau, cuối cùng giúp bạn đào hết mọi lỗi ra.
Quan điểm “đốt thêm token sẽ nâng cao chất lượng Agent” còn được củng cố bởi bằng chứng thực tiễn: Những nhóm tuyên bố có thể dùng Agent viết mã hoàn chỉnh và đưa thẳng vào sản xuất, hoặc là nhà cung cấp mô hình nền tảng, 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 đang đau đầu vì Agent không tạo ra được mã đạt chuẩn sản xuất — nói thẳng ra thì, vấn đề nằm ở bạn. Hoặc nói chính xác hơn, nằm ở ví tiền của bạn.
Làm sao biết mình đã “đốt” đủ token chưa?
Tôi từng viết hẳn một bài luận khẳng định chắc chắn rằng vấn đề tuyệt đối không nằm ở framework (bộ khung) bạn xây dựng — “giữ mọi thứ đơn giản” vẫn có thể tạo ra sản phẩm xuất sắc. Đến giờ tôi vẫn kiên định với 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ới đầu ra của Agent. Bạn gửi DM cho tôi, rồi thấy tôi đã đọc nhưng không phản hồi.
Bài viết này chính là lời trả lời.
Agent của bạn hoạt động kém, không giải quyết được vấn đề — trong đa số trường hợp, nguyên nhân chỉ là bạn chưa “đốt” đủ token.
Số token cần thiết để giải quyết một vấn đề phụ thuộc hoàn toàn vào quy mô, độ phức tạp và tính mới của vấn đề đó.
“2 + 2 bằng mấy?” — chẳng cần bao nhiêu token.
“Hãy viết giúp tôi một bot có khả năng quét toàn bộ thị trường trên Polymarket và Kalshi, tìm ra những thị trường có ý nghĩa tương đồng về mặt ngữ nghĩa và lẽ ra nên thanh toán trước/sau cùng một sự kiện, thiết lập ranh giới không chênh lệch giá (no-arbitrage boundary), và tự động giao dịch với độ trễ thấp ngay khi xuất hiện cơ hội chênh lệch giá” — cái này thì cần “đốt” một núi token.
Trong thực tiễn, chúng tôi phát hiện một điều thú vị.
Nếu bạn đầu tư đủ token để xử lý các vấn đề phát sinh từ quy mô và độ phức tạp, Agent luôn có thể giải quyết được. 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, gồm rất nhiều thành phần và hàng ngàn dòng mã, chỉ cần bạn đổ đủ token vào những vấn đề đó, cuối cùng chúng đều sẽ được giải quyết triệt để.
Tuy nhiên, tồn tại một ngoại lệ nhỏ nhưng quan trọng.
Vấn đề của bạn không được quá mới. Ở giai đoạn hiện tại, bất kỳ số lượng token nào cũng đều không thể giải quyết được vấn đề “tính mới”. Token dồi dào có thể loại bỏ hoàn toàn sai sót do độ phức tạp gây ra, nhưng không thể khiến Agent “sáng tạo ra từ hư vô” những điều mà nó chưa từng biết.
Kết luận này thực ra khiến chúng tôi nhẹ nhõm.
Chúng tôi đã dành rất nhiều công sức, “đốt” — rất, rất, rất nhiều — token, để thử nghiệm xem liệu Agent có thể tái hiện quy trình đầu tư tổ chức mà gần như không có bất kỳ hướng dẫn nào. Một phần mục đích là để xác định rõ: Chúng tôi (như những 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 bất lực trong việc tái hiện một quy trình đầu tư tổ chức đạt mức chấp nhận được. Theo chúng tôi, nguyên nhân chủ yếu là vì Agent chưa từng “thấy” thứ này trước đây — tức là quy trình đầu tư tổ chức hoàn toàn vắng mặt trong dữ liệu huấn luyện.
Vì vậy, nếu vấn đề của bạn mang tính mới, đừng hy vọng “chồng token” sẽ giải quyết được. Bạn cần tự mình dẫn dắt quá trình khám phá. Nhưng một khi đã xác định được phương án thực hiện, bạn có thể yên tâm “đổ” token để triển khai — dù kho mã có lớn đến đâu, thành phần có phức tạp đến mức nào, cũng không thành vấn đề.
Dưới đây là một quy tắc kinh nghiệm đơn giản: Ngân sách token nên tăng tỷ lệ thuận với số dòng mã.
Vậy những token “đốt thêm” thực chất đang làm gì?
Trong thực tiễn, token bổ sung thường cải thiện chất lượng kỹ thuật của Agent theo những cách sau:
Cho phép nó dành nhiều thời gian hơn để suy luận trong cùng một lần thử, nhờ đó có cơ hội tự phát hiện logic sai. Suy luận càng sâu = lập kế hoạch càng tốt = xác suất “trúng đích” ngay từ lần đầu càng cao.
Cho phép nó thực hiện nhiều lần thử độc lập, đi theo những hướng tiếp cận khác nhau. Một số hướng hiệu quả hơn những hướng khác. Cho phép nhiều lần thử giúp nó chọn ra phương án tối ưu nhất.
Tương tự, nhiều lần lập kế hoạch độc lập hơn giúp nó từ bỏ những hướng yếu và giữ lại những hướng tiềm năng nhất.
Nhiều token hơn cho phép nó dùng một ngữ cảnh hoàn toàn mới để phản biện công việc trước đó của chính mình, từ đó có cơ hội cải tiến, thay vì bị mắc kẹt trong một “quán tính suy luận” nào đó.
Đương nhiên, còn có điểm tôi thích nhất: Nhiều token hơn đồng nghĩa với việc nó có thể dùng các bài kiểm thử và công cụ để xác minh. Chạy thử mã thực tế để kiểm tra xem nó có hoạt động đúng hay không — đây là cách đáng tin cậy nhất để xác nhận tính đúng đắn của câu trả lời.
Luận điểm này vận hành được là vì thất bại kỹ thuật của Agent không mang tính ngẫu nhiên. Gần như luôn xuất phát từ việc lựa chọn sai hướng quá sớm, không kiểm tra xem hướng đã chọn có thực sự khả thi hay không (ở giai đoạn đầu), hoặc không có ngân sách đủ để phục hồi và quay lui sau khi phát hiện lỗi.
Câu chuyện đến đây là rõ ràng. Token, theo nghĩa đen, chính là chất lượng ra quyết định mà bạn mua được. Hãy hình dung nó như công việc nghiên cứu: Nếu bạn yêu cầu một người trả lời ngay lập tức một bài toán khó dưới áp lực thời gian, chất lượng câu trả lời sẽ giảm dần.
Nghiên cứu, xét cho cùng, là quá trình tạo ra thứ nền tảng nhất: “biết đáp án”. Con người dành thời gian sinh học để tạo ra câu trả lời tốt hơn; còn Agent dành thêm thời gian tính toán để tạo ra câu trả lời tốt hơn.
Làm sao nâng cao hiệu năng Agent của bạn?
Có thể bạn vẫn bán tín bán nghi, nhưng thực tế có rất nhiều bài báo khoa học ủng hộ quan điểm này. Thật lòng mà nói, sự tồn tại của “núm điều chỉnh suy luận” (reasoning knob) đã là bằng chứng đầy đủ nhất mà bạn cần.
Một bài báo tôi đặc biệt yêu thích cho thấy: Các nhà nghiên cứu huấn luyện mô hình trên một tập mẫu suy luận được tuyển chọn kỹ lưỡng, sau đó dùng một kỹ thuật ép mô hình tiếp tục suy luận ngay cả khi nó muốn dừng lại — cụ thể là chèn từ “Wait” (Đợi đã) ngay tại điểm mô hình muốn kết thúc. Chỉ riêng thao tác này đã nâng điểm số trên một bộ kiểm tra chuẩn từ 50% lên 57%.
Tôi muốn nói một cách thẳng thắn nhất: Nếu bạn liên tục phàn nàn rằng mã do Agent viết ra chỉ ở mức “cũng được”, thì khả năng cao mức độ suy luận tối đa trong một lần chạy vẫn chưa đủ với bạn.
Tôi xin đề xuất hai giải pháp cực kỳ đơn giản.
Cách làm đơn giản thứ nhất: WAIT (Đợi đã)
Việc đơn giản nhất bạn có thể thực hiện ngay hôm nay: Xây dựng một vòng lặp tự động — sau khi Agent hoàn tất việc xây dựng, hãy để nó tự kiểm tra lại N lần trong các ngữ cảnh hoàn toàn mới, mỗi lần phát hiện vấn đề đều sửa chữa.
Nếu bạn thấy thủ thuật đơn giản này cải thiện đáng kể hiệu quả kỹ thuật của Agent, ít nhất bạn đã hiểu rõ vấn đề chỉ nằm ở số lượng token — vậy thì hãy gia nhập Câu lạc bộ “Đốt token” đi thôi.
Cách làm đơn giản thứ hai: VERIFY (Xác minh)
Hãy yêu cầu Agent xác minh công việc của chính mình càng sớm và càng thường xuyên càng tốt. Viết các bài kiểm thử để chứng minh hướng tiếp cận đã chọn thực sự khả thi. Phương pháp này đặc biệt hữu ích với các dự án cực kỳ phức tạp và lồng ghép sâu — một hàm có thể được gọi bởi rất nhiều hàm khác ở phía下游. Việc bắt lỗi ở thượng nguồn 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 “điểm kiểm tra xác minh” rải rác suốt toàn bộ quá trình xây dựng.
Vừa viết xong một đoạn mã, Agent chính tuyên bố đã xong? Hãy để một Agent khác kiểm tra lại. Dòng suy luận không liên quan sẽ giúp bù đắp các nguồn thiên lệch hệ thống.
Cơ bản là như vậy. Về chủ đề này tôi còn có thể viết rất nhiều, nhưng tôi tin rằng chỉ cần bạn nhận thức rõ hai điều trên và triển khai nghiêm túc, bạn đã có thể giải quyết được 95% vấn đề. Tôi kiên định tin tưởng vào triết lý: Làm những việc đơn giản tới mức tuyệt đỉnh, rồi mới tăng dần độ phức tạp khi thực sự cần thiết.
Tôi đã nhắc đến “tính mới” là vấn đề không thể giải quyết bằng token — tôi muốn nhấn mạnh lại điều này một lần nữa, bởi bạn chắc chắn sẽ sớm vấp phải “cái hố” này và quay lại than thở với tôi rằng “đổ token cũng vô ích”.
Khi vấn đề bạn muốn giải quyết không tồn tại trong tập huấn luyện, chính bạn mới là người thực sự phải cung cấp lời giải. Do đó, kiến thức chuyên môn lĩnh vực vẫn cực kỳ quan trọng.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@systematicls
