Kalidad ng AI Agent ay nauugnay sa pag-burn ng token

May-akda: Systematic Long Short

Isinalin: Deep潮 TechFlow

DeepChao Summary: Ang pangunahing argumento ng artikulong ito ay isang pangungusap lamang: Ang kalidad ng output ng AI Agent ay direktang proporsyonal sa bilang ng mga token na inilalagay mo.

Hindi nagtatanghal ang may-akda ng mga teorya lamang, kundi ibinibigay ang dalawang konkretong paraan na maaari mong gamitin agad ngayon, at malinaw na tinukoy ang hangganan kung де saan hindi maaaring gawin ang Token — ang "problem ng pagkakakilanlan".

mataas ang density ng impormasyon at pagkakaroon ng aksyon para sa mga mambabasa na gumagamit ng Agent para isulat ang code o patakbuhin ang workflow.

Sige, kailangan mong承认 na ang pamagat ay talagang nakakaakit—pero seryoso lang, hindi ito palaisipan.

Noong 2023, nang gamit pa namin ang LLM para sa production code, nabigla ang lahat sa paligid namin, dahil sa paniniwala noon na ang LLM ay nagpapalabas lamang ng kalokohan na hindi gagamitin. Ngunit alam namin ang isang bagay na hindi naunawaan ng iba: ang kalidad ng output ng Agent ay isang punsiyon ng bilang ng mga token na inilalagay mo. Ganito lang.

Maaari mong makita ito sa pamamagitan ng pagpapatakbo ng ilang sariling eksperimento. Hayaan ang Agent na makumpleto ang isang kumplikado at kaunting kilalang programming task—halimbawa, mula sa simula ay isagawa ang isang convex optimization algorithm na may mga constraint. Unang gamitin ang pinakamababang thinking tier; pagkatapos ay i-switch sa pinakamataas na thinking tier at hayaan itong i-review ang sarili nitong code upang makita kung ilang bug ang maaari nitong makita. Subukan din ang intermediate at high tiers. Makikita mo nang direkta: ang bilang ng mga bug ay bumababa nang monotonically kasabay ng pagtaas ng ginugastong halaga ng Token.

Hindi ito mahirap maintindihan, di ba?

Mas maraming token = mas kaunting error. Maaari mong i-extend ang lohikang ito, na sa kanyang pinakasimpleng anyo ay ang pangunahing ideya sa likod ng product na code review. Sa isang bagong konteksto, ilagay ang malaking halaga ng token (halimbawa, hayaan itong i-parse ang code line by line at tukuyin kung may bug bawat linya)—ganoon ay maaari mong matuklasan ang karamihan, kahit lahat, ng mga bug. Maaari mong paulit-ulitin ang prosesong ito nang sampu o daan-daang beses, bawat pagkakataon ay nagmumula sa “iba’t ibang pananaw” sa codebase, at sa huli, maaari mong alisin ang lahat ng mga bug.

Ang paniniwala na “mas maraming Token na nasusunog ay nagpapabuti sa kalidad ng Agent” ay may suportang ebidensya: ang mga koponan na nag-uusisa na makakasulat ng code nang buo gamit ang Agent at direktang i-deploy sa production ay o ang mga sariling provider ng base model, o ang mga kumpanya na may napakalaking pondo.

Kaya kung nag-iisip pa rin ka kung bakit hindi makapag-output ng production-grade code ang Agent—sabi nang direkta, ang problema ay nasa iyo. O, sa iyong wallet.

Isinulat ko ang isang buong artikulo na ang problema ay hindi nasa framework na iyong ginawa, "magmanatili sa simpleng paraan" ay maaari pa ring gumawa ng mahusay na bagay, at nananatili pa rin akong naniniwala sa pananaw na ito. Binasan mo ang artikulong iyon, isinagawa mo ito, ngunit patuloy kang nabigla sa output ng Agent. Nag-send ka ng DM sa akin, nakita mo na ang aking "read" pero wala kang sumagot.

Ito ang sagot.

Ang iyong Agent ay nagtatampok ng mahinang performans at hindi nakakasolve ng mga problema, at sa karamihan ng mga kaso, dahil kulang ang iyong na-burn na Token.

Ang bilang ng Token na kailangan upang lutasin ang isang problema ay depende sa sukat, kumplikado, at pagkakatangi nito.

Ilan ang «2+2»? Hindi kailangan ng maraming Token.

“Gumawa ng isang bot na makakascan ng lahat ng mga market sa pagitan ng Polymarket at Kalshi, upang makahanap ng mga market na may magkatulad na kahulugan at dapat mag-settle sa parehong pangyayari, tukuyin ang mga hangganan ng walang arbitrage, at awtomatikong mag-trade nang mababa ang latency kapag may arbitrage opportunity” — kailangan nito ng maraming Token.

Nakita namin sa praktika ang isang interesanteng bagay.

Kung maglalagay ka ng sapat na mga Token upang sagutin ang mga problema na dulot ng sukat at kumplikado, ang Agent ay laging makakasolve. Sa ibang salita, kung gusto mong bumuo ng isang napakakomplikadong bagay na may maraming komponente at linya ng code, kahit anong problema ay masosolusyunan nang buo kung ikokonsidera mo ang sapat na mga Token.

Mayroon dito isang maliit ngunit mahalagang pagkakaiba.

Hindi masyadong bago ang iyong tanong. Sa kasalukuyang yugto, anumang dami ng Token ay hindi makakalutas ng problema ng 'novelty'. Sapat na maraming Token ay maaaring bawasan ang mga kamalian dulot ng kumplikado hanggang zero, ngunit hindi ito makakagawa ng bagong bagay na hindi alam ng Agent.

Ang konklusyon na ito ay nagbigay sa amin ng pagkakataon na huminga nang malaya.

Naglagay kami ng malaking pagsisikap, sinunog namin—napakarami, napakarami, napakarami—mga Token, upang subukan kung kaya ng Agent na muling ibalik ang proseso ng pagsisikap ng institusyon nang walang anumang gabay. Ang bahaging ito ay dahil gusto naming malaman kung ilang taon pa ang kulang para sa amin (bilang mga quantitative researcher) na ganap na palitan ng AI. Nakuha namin ang resulta na hindi kayang gawin ng Agent ang isang makatotohanang proseso ng pagsisikap ng institusyon. Naniniwala kami na ang bahaging ito ay dahil sa katotohanang hindi pa sila nakakakita ng ganitong uri—ibig sabihin, wala sa training data ang proseso ng pagsisikap ng institusyon.

Kaya kung ang iyong tanong ay nakakabago, huwag asahan na lutasin ito sa pamamagitan ng pagpupuno ng Token. Kailangan mong gabayan ang proseso ng pag-aaral. Ngunit matapos mong matukoy ang implementasyon, maaari mo nang maging mapagkakatiwalaan na punuin ang Token para sa pagsasagawa—anuman ang laki ng codebase o kumplikado ng mga komponente, hindi ito isang problema.

May simpleng prinsipyong heuristiko dito: Dapat tumataas ang budget para sa Token nang patagalan kasabay ng pagdami ng mga linya ng code.

Sa praktika, karagdagang Token ay karaniwang nagpapabuti sa kalidad ng engineering ng Agent sa mga sumusunod na paraan:

Gumawa ng higit pang pag-iisip sa iisang pagkakataon upang makahanap ng sariling mali na lohika. Mas malalim ang pag-iisip = mas magandang plano = mas mataas ang posibilidad na makamit sa isang pagkakataon.

Bigyan ito ng maraming independiyenteng pagkakataon na subukan ang iba’t ibang paraan ng paglutas. May mga paraan na mas mabuti kaysa sa iba. Kapag pinapayagan itong subukan nang higit sa isang beses, makakapili ito ng pinakamahusay.

Kaugnay nito, higit pang mga independiyenteng plano ay sinubukan upang itago ang mahinang direksyon at panatilihin ang pinakamalayong posibilidad.

Mas maraming token ang nagpapahintulot sa ito na mag-critique ng sariling nakaraang trabaho gamit ang isang bagong konteksto, na nagbibigay sa ito ng pagkakataon na mapabuti, kesa sa maging nakaputol sa isang partikular na “推理惯性”.

Oo, at isa pa sa aking paborito: mas maraming Token ay nangangahulugan na maaari itong masuri at patunayan gamit ang mga tool. Ang pagpapatakbo ng code upang makita kung gumagana ito ay ang pinakamakatotohanang paraan upang matiyak ang tamang sagot.

Nakakapagpapatakbo ang lohikang ito dahil ang pagkabigo ng engineering ng Agent ay hindi random. Halos laging dahil sa maling pagpili ng daan sa maagang yugto, hindi pag-check kung talagang maaaring sundin ang daan (sa maagang bahagi), o kulang sa budget upang mabawi at mabalewala pagkatapos makita ang kamalian.

Ganito ang kuwento. Ang Token ay literal na ang kalidad ng desisyon na binili mo. Isipin ito bilang isang pag-aaral: kung hihingin mo sa isang tao na sagutin ang isang mahirap na tanong nang agad, bababa ang kalidad ng sagot habang tumataas ang presyur ng oras.

Ang pag-aaral, sa huling tinitiyak, ay ang pagbuo ng pangunahing bagay na “alam ang sagot.” Ang mga tao ay gumagastos ng oras sa biyolohikal na kahulugan upang magbigay ng mas mahusay na sagot, habang ang mga agent ay gumagastos ng higit pang oras sa pagkalkula upang magbigay ng mas mahusay na sagot.

Maaari pa ring mag-iiwanan ka ng pag-aalinlangan, ngunit may maraming pananaliksik na sumusuporta dito; sa totoo lang, ang pagkakaroon ng sariling control knob para sa "reasoning" ay sapat na patunay na kailangan mo.

Isang papel na napakagustuhan ko, kung saan ang mga mananaliksik ay nagtratrabaho gamit ang isang maliit na grupo ng maingat na pinili na mga halimbawa ng pag-iisip, at pagkatapos ay gumamit ng isang paraan upang pilitin ang modelo na magpatuloy sa pag-iisip kapag nais itong tumigil—ang konkretong paraan ay ang pagdaragdag ng “Wait” (hintayin) sa lugar kung saan nais nitong tumigil. Sa pagsasagawa lamang nito, tumaas ang isang benchmark mula sa 50% patungo sa 57%.

Gusto kong sabihin nang diretso: kung palaging nagpapapunta ka sa code na isinulat ng Agent na hindi gaanong maganda, ang pinakamataas na antas ng pag-iisip sa isang pagkakataon ay maaaring hindi pa sapat para sa iyo.

May ibibigay ako sa iyo na dalawang napakasimpleng solusyon.

Simpleng paraan 1: WAIT (hintayin)

Ang pinakasimpleng bagay na pwedeng gawin mo ngayon: gumawa ng isang automated loop—pagkatapos mong buuin, pahintulutan ang Agent na i-review ang N beses gamit ang bagong konteksto, at ayusin ang anumang problema na makikita.

Kung nakita mo na nagbago ang epekto ng iyong Agent engineering dahil sa simpleng trick na ito, naiintindihan mo na ang problema mo ay tungkol lamang sa bilang ng mga token—kaya sumali na sa club ng pagpapalit ng token.

Simpleng paraan 2: VERIFY (Pagsusuri)

Huwag maghintay ng masyadong haba upang i-verify ang sariling trabaho ng Agent. Sumulat ng mga pagsubok upang patunayan na ang napiling path ay talagang gumagana. Lalo itong makakatulong sa mga napakakomplikado at malalim na nakakabit na proyekto—isang function ay maaaring tawagan ng maraming iba pang function sa ibaba. Ang pagkakaroon ng kakayahang makahanap ng mga error sa itaas ay makakatipid sa iyo ng malaking halaga ng pagkakalawak na oras (Token). Kaya, kung posible, maglagay ng mga “checkpoints ng pag-verify” sa buong proseso ng pagbuo.

Matapos isulat ang isang bahagi, sinabi ng pangunahing Agent na natapos na? Hingin ang pagsusuri ng ikalawang Agent. Ang mga di-kaugnay na pag-iisip ay maaaring kapitanin ang pinagmulan ng sistematisyang bias.

Ito na lang ang pangunahin. Marami pa akong maipapalit tungkol sa paksa na ito, ngunit naniniwala ako na kung maunawaan mo ang dalawang bagay na ito at isasagawa mo nang maayos, makakatulong ito upang lutasin ang 95% ng mga problema. Naniniwala ako na ang paggawa nang husto sa mga simpleng bagay, at pagdaragdag ng kumplikado ayon sa pangangailangan, ay ang tamang paraan.

Sinabi kong ang "novelty" ay isang problema na hindi malulutas ng Token, at gustong pahalagahan ko muli dahil sa isang panahon ay makakatagpo ka ng ganitong problema, at sasabihin mo sa akin na ang pagpupuno ng Token ay walang epekto.

Kapag ang problema na nais mong lutasin ay hindi nasa training set, ikaw ang tunay na kailangang magbigay ng solusyon. Kaya, ang mga kaalaman sa larangan ay patuloy na napakahalaga.