Ako si poradiť s hlúpym jazykovým modelom

Niektorí ľudia hovoria, že jazykové modely (LLM) sú ako horliví stážisti – inteligentné, ale potrebujúce dohľad. Podľa mňa to hrubo preceňuje inteligenciu súčasných jazykových modelov. Podľa mojich skúseností majú dnešné špičkové jazykové modely IQ niekde okolo 75. Sú ako Frankensteinov asistent Igor. Sú síce užitočné, ale vyžadujú oveľa viac dohľadu ako stážista.

Ako je potom možné, že sú jazykové modely v súťažiach také dobré?

Jazykové modely skutočne dosahujú v benchmarkoch dobré výsledky. Zvládajú vysokoškolské skúšky a v súťažiach sa umiestňujú na popredných priečkach medzi najšikovnejšími ľuďmi. Ale keď dám jazykovému modelu reálnu programátorskú úlohu v reálnom softvérovom projekte, má problém ju správne dokončiť. Robí neuveriteľne hlúpe chyby. Pri naivnom prompte sa následná kontrola kódu rýchlo stáva frustrujúcou. LLM sa správa ako idiot. Možno ako geniálny idiot, ale stále je to idiot. Čo teda vysvetľuje zjavný rozdiel medzi výkonom s IQ 150 v súťažiach a výkonom s IQ 75 v reálnych projektoch?

Prvým problémom sú peniaze. Jazykové modely dosahujú vysoké skóre v súťažiach len za cenu tokenov v hodnote tisícok dolárov. To by pokrylo ročné náklady na pomerne drahého programátorského asistenta. Takéto rýchle míňanie peňazí nebude v reálnom projekte ekonomické. Jazykové modely nemusia byť len kompetentné. Musia byť cenovo dostupné. Len cenovo dostupné jazykové modely sú pre túto diskusiu relevantné, a tie nie sú obzvlášť inteligentné. Áno, jazykové modely mi umožňujú urobiť viac práce, takže za nejaké peniaze stoja, ale má to svoje hranice, pretože cieľom bolo obohatiť seba, nie Anthropic. Prečo by som používal jazykový model, ktorý zarába peniaze len pre Anthropic?

Potom je tu podvádzanie. Rozdiel medzi výsledkami v benchmarkoch a výkonom v praxi sa dá čiastočne vysvetliť tým, že dodávatelia jazykových modelov špecificky navrhujú tréningové behy tak, aby maximalizovali výkon v benchmarkoch. Benchmarky sú nástrojom marketingu jazykových modelov. Vzbudzujú záujem používateľov a priťahujú peniaze investorov. Kto by si trochu nepomohol podvádzaním? Nehovorím, že do tréningových dát sprosto zahŕňajú odpovede z testov. Skôr ide o to, že tréningové dáta a fine-tuning sú optimalizované pre najlepší výkon v benchmarkoch, a nie pre najlepší výkon v praxi.

A nakoniec, reálne projekty sú veľmi odlišné od úloh, s ktorými sa jazykové modely stretávajú v benchmarkoch a súťažiach. Úlohy v benchmarkoch sú maličké, zatiaľ čo reálne projekty sú také obrovské, že do kontextu sa zmestí len malá časť projektu. Benchmarky používajú dobre známu terminológiu a koncepty a spoliehajú sa na verejne dostupné znalosti, zatiaľ čo reálne projekty si definujú vlastné koncepty a slovník a opierajú sa o internú dokumentáciu. Úlohy v benchmarkoch sú presne definované, zatiaľ čo reálne programátorské úlohy obsahujú nejednoznačnosti, medzery a chyby, napriek všetkému úsiliu vývojára, ktorý úlohu jazykovému modelu zadal.

Architektúra jazykových modelov sa optimalizuje pre úlohy podobné tým v benchmarkoch. Je to vedľajší účinok optimalizácie architektúry pre chatovanie a iné jednoduché úlohy s krátkym kontextom. Tieto úlohy sú väčšinou obmedzené znalosťami, takže na ne zaberajú obrovské MoE modely a dlhé tréningové behy. Naopak, programovanie vyžaduje, aby model zhromažďoval informácie z rozsiahleho kontextu plného neznámych konceptov, ktoré treba starostlivo poskladať. Programovanie tak zaťažuje mechanizmus pozornosti, veľkosť kontextu a schopnosť premýšľania, zatiaľ čo znalosti modelu zostávajú zväčša nevyužité. Dodávatelia modelov v skutočnosti mechanizmus pozornosti zlacňujú a optimalizujú, pretože alokuje pamäť pre každého používateľa, čo je v cloude drahé. Veľkosti kontextu sa síce výrazne zväčšili, ale krátka prompt cache v cloude robí dlhý kontext cenovo nedostupným. Premýšľanie pri kódovaní skutočne pomáha, ale súčasné implementácie premýšľania, ktoré sa údajne opierajú o niekoľko tisíc vzoriek z fine-tuningu, nie sú dostatočne robustné na to, aby sa model dokázal zorientovať vo veľkých softvérových projektoch.

Ktoré jazykové modely sú najmenej hlúpe?

V polovici roka 2025 som najspokojnejší s Claude Sonnet 4. Prideľujem mu väčšinu úloh.

Gemini Pro 2.5 je preceňovaný. Podľa mojich skúseností je veľmi nevyspytateľný. Nemôžem sa naň spoľahnúť, že urobí čokoľvek správne. Často nedodrží výstupný formát a iné základné inštrukcie. Dokonca som ho videl spadnúť do slučky opakovania. A v praxi je drahší ako Claude Sonnet, pretože pri každej úlohe premýšľa tisíce tokenov, zatiaľ čo Claude si vystačí s niekoľkými stovkami. Pôsobí ako model niekoľkokrát menší než Claude Sonnet. Myslím si, že cenu na úrovni Sonnetu dostal len preto, lebo Google je veľmi hrdý na jeho schopnosť premýšľania. Gemini Pro je však užitočný, keď potrebujem do kontextu napchať veľa súborov alebo keď si problém vyžaduje veľa premýšľania.

Ak zoradíte modely podľa kompetentnosti, zdá sa, že existuje prah, ktorý oddeľuje produktívne modely od tých frustrujúcich. Claude Sonnet je trochu nad týmto prahom, na produktívnej strane. Gemini Pro je trochu pod prahom, na frustrujúcej strane. Všetko menšie je beznádejne frustrujúce. Už sa ani nepokúšam zadávať čokoľvek Gemini Flash, pretože jeho odpovede sú plné chýb a opomenutí. Ešte som neskúšal o3 od OpenAI, ale vraj nie je v programovaní veľmi dobrý.

Ako teda riadiť idiota?

Keďže sa jazykový model pri reálnej úlohe v reálnom projekte správa ako idiot s IQ 75, musíme vymyslieť spôsob, ako ho napriek jeho obmedzenej inteligencii využiť.

Niektorí ľudia radi dávajú jazykovým modelom množstvo malých úloh, zvyčajne cez rozšírenie pre IDE, aby znížili réžiu pripadajúcu na každú úlohu. Ja nie som fanúšikom tohto prístupu. Početné dotazy sú drahé. Ste potom pod tlakom, aby ste udržiavali minimálny kontext, čo obmedzuje chápanie projektu modelom. Keďže model nepozná budúce kroky, má tendenciu písať kód, ktorý bude čoskoro potrebovať zmeny, čo zvyšuje náklady na kontrolu kódu. A keďže model nemá dostatočnú autonómiu, je tam veľa réžie s komunikáciou a k tomu ešte čakáte na model niekoľkokrát za hodinu.

Ja namiesto toho uprednostňujem zadávanie jednej väčšej úlohy naraz. Zvyčajne ide o jednu ucelenú funkciu alebo jednu refaktorizačnú úlohu, ktorá zasahuje do nanajvýš desiatky súborov. Model vtesnám medzi detailnú špecifikáciu na jednej strane a podrobnú kontrolu kódu riadok po riadku na druhej strane. To dáva modelu dostatočnú autonómiu na to, aby priniesol zmysluplné zvýšenie produktivity. A tento prístup prináše lepšie výsledky s rastúcou inteligenciou modelu, takže v budúcnosti sú možné vyššie zisky, pretože inteligentnejšie modely si poradia s menej detailnou špecifikáciou a nevyžadujú takú dôkladnú kontrolu. Model je nútený implementovať všetky zadané požiadavky tak, aby boli navzájom konzistentné. Rozdelenie práce na niekoľko veľkých úloh mi umožňuje používať relatívne veľký model s relatívne veľkým kontextom a zároveň udržať náklady na API v priemere pod 1€ na deň.

Pri súčasných jazykových modeloch je zlý nápad zanedbať špecifikáciu, pretože to pridáva viac práce počas kontroly kódu. Moje špecifikácie majú od 5 do 20 bodov, pričom každý obsahuje jasný príkaz alebo obmedzenie. Nemôžete zanedbať ani kontrolu kódu, pretože by to neskôr viedlo k nákladnému opravovaniu chýb.

Najlepšie úlohy pre jazykové modely sú široké a plytké. To umožňuje jazykovému modelu napísať veľa kódu bez toho, aby sa na niečom zasekol. Časom si všimnete, že chyby sú vždy tam, kde je kód najkomplikovanejší. Postupne sa naučíte predvídať, čo jazykový model zvládne a kde budú problémy. Aby som sa vyrovnal s nerovnomernou zložitosťou úlohy, robím špecifikáciu detailnejšou tam, kde má úloha väčšiu hĺbku, a naopak, dávam jazykovému modelu viac slobody tam, kde je úloha plytká. Podobne počas revízie kódu venujem viac pozornosti zložitému kódu a triviálne zmeny len rýchlo prejdem.

Toto funguje, ale len s Claude Sonnet. Ostatné jazykové modely sú príliš hlúpe na to, aby zvládli zadané úlohy, aj keď napíšem detailné špecifikácie. Jedna úloha trvá od 15 minút do niekoľkých hodín v závislosti od zložitosti. Zvýšenie produktivity je zjavné, ale nie je to ani 2x, a rozhodne nie 10x. Dokážem vyprodukovať viac ako tisíc nových alebo zmenených riadkov denne, hoci je to možné len vďaka tomu, že teraz žiadam jazykové modely, aby písali internú dokumentáciu a unit testy, čo nafukuje changesety. Produktivita je teraz čoraz viac obmedzovaná zložitou dizajnérskou prácou, ktorú súčasné jazykové modely rozhodne nedokážu robiť, aj keď v cykle špecifikácie, inferencie a kontroly je stále veľa priestoru na zlepšenie.

A čo agenti?

Možno ste si všimli, že o interakciách s jazykovými modelmi hovorím, akoby som robil len jeden dotaz a použil to, čo jazykový model vráti na prvý pokus. Máte pravdu. V súčasnosti nepoužívam agentickú slučku. Považujem kódovacích agentov za drahých a som skeptický, či sa za tú cenu oplatia.

Podľa mojich skúseností ani typové kontroly, ani unit testy, ani automatizované kontroly pravdepodobne výrazne nezlepšia kvalitu výstupu. Jazykové modely sú celkom dobré v tvorbe syntakticky správneho kódu, takže typové kontroly takmer vždy prejdú. Ak jazykový model nechá v kóde chybu, s najväčšou pravdepodobnosťou nechá rovnakú chybu aj v testoch, čo znamená, že testy prejdú, hoci kód je nesprávny. Momentálne robím nadväzné dotazy s výsledkami manuálne spravenej kontroly kódu a jazykový model zvyčajne nedokáže chyby opraviť. Automatizovaná kontrola bude pravdepodobne fungovať ešte horšie. To všetko ma robí skeptickým voči prínosom agentickej slučky.

Momentálne sa zameriavam na kvalitu kontextu. Z historických dôvodov používam vlastnú knižnicu llobot, ktorá je vlastne určená na neprogramátorské úlohy (preklady, zhrnutia atď.), ale považujem ju za vhodnejšiu aj na programátorské úlohy. Viem, že existuje Aider a OpenHands, ktoré sú určené na programátorské úlohy, ale nie som spokojný so spôsobom, akým napĺňajú kontext. Na llobotovi sa mi obzvlášť páči, že mi umožňuje ponechať v kontexte nedávno dokončené úlohy s finálnym, schváleným riešením. Verím (a mám nejaké predbežné dôkazy), že to pomáha modelu správne vykonať nasledujúcu úlohu. Som tiež fanúšikom vypchávania kontextu (context stuffing). Štandardné nástroje sa však časom zlepšia v tvorbe hodnotného kontextu a potom na ne prejdem.

Anthropic ponúka 90% zľavu na cachované vstupné tokeny za cenu o 25% drahšieho počiatočného promptu. To znamená, že 1-3 iterácie agentickej slučky by zvýšili celkové náklady len asi o 50%. Hoci agentická slučka nie je až taká efektívna, pri tejto cene je pravdepodobne ekonomickejšia ako použitie väčšieho modelu. Preto do budúcna plánujem používať LLM agentov.