Prečo sa AI s istotou mýli

Túto scénu je dobré poznať, preto začneme ňou. Dopísali ste hru, skóre sa po reštarte vynuluje, a pýtate sa agenta:

Prečo sa po reštarte stráca skóre?

Odpoveď príde pokojná a uhladená:

Skóre sa v projekte už ukladá, len zápis nie je nikde zapnutý.
Stačí zmeniť jedno nastavenie a výsledok prežije reštart.

Idete to overiť. Nastavenie ani ukladanie skóre v projekte nie je a nikdy nebolo - ani riadok, ani náznak. Odpoveď sa čítala ako rozbor vášho kódu, no bol to predpoklad o tom, ako sú takéto projekty zvyčajne postavené.

A pritom predtým nezaznela žiadna pauza ani výhrada. Tón je presne ten istý ako pri všetkých predchádzajúcich odpovediach, ktoré sa ukázali ako správne. Nástroj pritom funguje a model nie je horší, než bol včera.

Príčina je v tom, ako odpoveď vôbec vzniká. Model nevyťahuje hotový fakt z úložiska - vyberá pravdepodobné pokračovanie vášho textu, kúsok po kúsku. Lenže pravdepodobné a správne nie je to isté, najmä keď ide o váš projekt, ktorý model nevidel. Vymyslené, ale vierohodné detaily sa zvyčajne nazývajú halucinácie.

Ďalej - kde sú rozmiestnené pasce, prečo má chyba vždy pokojný tón a aké tri kontroly pokryjú väčšinu takýchto prípadov.

Čo model vidí vo vašej požiadavke

Pasca je tu najjednoduchšia zo všetkých: zdá sa, že model sa pozerá na váš projekt. V skutočnosti vidí iba to, čo mu odovzdali, a odovzdávajú mu toto:

• Vstavané znalosti. Zákonitosti, ktoré sa pri tréningu zafixovali v parametroch modelu. Nie kartičky s faktami a odkazmi, ale čísla, preto aj známy fakt môže model zopakovať nepresne. A majú aj časovú hranicu: o knižnici, ktorá vyšla neskôr, model vie presne toľko, koľko mu ukázali.
• Aktuálny rozhovor. Vaša požiadavka, história konverzácie, súbory, ktoré agent prečítal, výstup príkazov, ktoré spustil.
• Pamäť aplikácie. To, čo je uložené v samostatných súboroch a na začiatku ďalšej relácie sa vkladá do rozhovoru. V Claude Code je to CLAUDE.md, ktorý píšete vy, a auto memory, kam si agent zapisuje poznámky sám.
• Externé zdroje. Dokumentácia, vyhľadávanie, databáza, súbory projektu - všetko, čo v trénovacích dátach možno nebolo alebo sa odvtedy zmenilo.

Posledné tri prichádzajú tou istou cestou: aby ovplyvnili odpoveď, musia sa dostať do aktuálneho rozhovoru. Sám od seba sa model do projektu nepozerá.

Z toho vyplýva dôsledok, ktorý sa oplatí raz si v hlave preskladať. Súbor, ktorý nikto neotvoril, pre model neexistuje. Kým sa jeho text nedostane do rozhovoru, otázku "kde sa u nás spracúva autorizácia" je poctivejšie čítať ako "ako sa v podobných projektoch zvyčajne volá takýto súbor". Odpoveď dostanete v oboch prípadoch a vyzerať bude rovnako.

Hneď vedľa číha menšia, zato nepríjemná pasca. Prečítaný súbor zostáva v rozhovore taký, aký bol pri čítaní. Opravili ste riadok vo svojom editore, ale v histórii rozhovoru leží stará verzia. Claude Code síce označí, že sa súbor zmenil, ale či si ho agent prečíta znova, už rozhoduje model. Upravovali ste ručne uprostred rozhovoru - spoľahlivejšie je priamo ho požiadať, aby súbor prečítal znova.

Prečo formulácia mení výsledok

Zo všetkého, čo sa dostane do rozhovoru, je vaša požiadavka jediná vec, ktorú píšete sami. Preto v nej rozhodujú maličkosti: prehodili ste pár slov, pridali upresnenie - a odpoveď sa pohla iným smerom. Nie je to rozmar nástroja.

Tu sa dá ľahko zamotať, preto to poviem zvlášť. Aj tá istá požiadavka dvakrát za sebou dáva rôzne odpovede: do odpovede nemusí ísť práve najpravdepodobnejšie pokračovanie, generovanie má nastavenia, ktoré určujú, ako ochotne sa vezme aj menej pravdepodobná možnosť. Ponúka sa otázka: ak odpoveď aj tak kolíše, čo s tým majú moje slová. Rozdiel je v tom, čo presne kolíše. Rozptyl medzi rovnakými požiadavkami je šum okolo jednej a tej istej voľby: formulácie sa budú líšiť, smer zostane rovnaký. Slová v požiadavke však posúvajú samotný smer, a robia to spoľahlivo.

Najhoršie funguje vágna prosba. Necháva modelu voľbu a model si vyberie to najpravdepodobnejšie vôbec - priemer zo všetkého, čo kedy videl. Vezmite si obyčajné "skráť text". O koľko - o percento, o tretinu, na polovicu? Čo sa dá vyhodiť a na čo sa nesmie siahnuť? Na žiadnu z týchto otázok prosba neodpovedá, takže odpovedať bude model, a formálne bude mať pravdu. Zato "skráť popis o 30 %" alebo "skráť popis na 300 znakov" mu nenechávajú voľbu tam, kde patrí vám.

Dobre to vidno na dvojici požiadaviek o tom istom. "Oprav triedenie" necháva otvorené všetko: aký zoznam, podľa ktorého poľa, čo sa vlastne považuje za chybu. Druhá formulácia však otvorené nenecháva takmer nič:

V zozname objednávok idú dátumy od starých k novým, potrebujem to opačne.
Najskôr ukáž súbor a riadok, kde je nastavené poradie triedenia, potom navrhni opravu.

Je dlhšia presne o toľko, koľko hádania si vyžadovala prvá. A navyše za vás urobí polovicu kontroly: agent prinesie miesto v kóde skôr, než sa naň spýtate.

Záver je jednoduchý: čím menej voľnosti v požiadavke, tým menej hádania v odpovedi. Nejde o čarovné zaklínadlá, ale o obyčajnú vec - buď rámec určíte vy, alebo ho vyberú za vás.

Sebavedomý tón sa nerovná faktu

A tu je hlavná pasca. Model nemá jednu intonáciu pre "toto viem naisto" a inú pre "toto som si práve doplnil": obe vety vznikajú tým istým spôsobom a vychádzajú rovnako pokojné. Nejaká súvislosť tu nie je úplne nulová, ale úžitok z nej nie je žiadny: istota modelu je vždy nadhodnotená, takže podľa tónu overené od doplneného nerozlíšite.

V bežnom texte vám zvláštne tvrdenie udrie do očí a sami spomalíte. V kóde táto ochrana nefunguje: názvy vyzerajú správne, konštrukcie sú známe a skutočnú metódu knižnice od metódy poskladanej podľa analógie okom nerozlíšite, ak knižnicu nepoznáte naspamäť. Preto chyba častejšie vypláva nie pri čítaní, ale pri spustení.

Navyše názov býva zriedka vymyslený úplne od nuly. V rozbore vygenerovaného kódu, kde sa hľadali odkazy na neexistujúce knižnice, sa viac ako tretina takých názvov ukázala ako zlepenec dvoch skutočných. Odtiaľ ten pocit dôveryhodnosti: časti názvu ste už niekde videli, len nie v tejto kombinácii.

Štyri prípady, ktoré rozpoznáte hneď napoprvé, ak viete, čo hľadať:

Všetky štyri majú jedno spoločné: odpoveď znie ako výsledok práce, hoci za ňou žiadna práca nebola.

Pri poslednom prípade sa oplatí zastaviť zvlášť, pretože vyzerá ako klamstvo, a klamstvo to nie je. Agent sa zastaví, keď práca vyzerá hotová. Ak nemá čo spustiť, "vyzerá hotová" je jediný dostupný signál a kontrolnou slučkou sa stávate vy.

Cena toho sa dá zmerať. V jednom rozbore logov agentov tvorili falošné "hotovo" takmer polovicu všetkých neúspechov. A tam, kde sa stav overoval nezávisle od hlásenia samotného agenta, takéto prípady takmer zmizli. Presne to je zmysel druhej kontroly z nasledujúcej časti: namiesto hlásenia dosadí to, čo si môžete pozrieť na vlastné oči.

Zostáva otázka, prečo model vôbec radšej dopĺňa, než by priznal nevedomosť. Ide o to, ako ho učili a ako ho hodnotili. Predstavte si test s možnosťami odpovede, kde je za prázdny hárok zaručená nula a za naslepo zaškrtnutú možnosť šanca na bod. Mlčať sa v takom systéme neoplatí nikdy a odpovedať pri akejkoľvek neistote je rozumné. Človek sa potom preučí na skutočných úlohách, kde nesprávna odpoveď vyjde drahšie ako poctivé "neviem". Model takéto preučenie nemá.

Požiadať model, aby poctivo upozorňoval, keď si nie je istý, pomáha - ale aj to je text poskladaný tým istým mechanizmom. Ako doplnkový signál sa hodí, ako náhrada kontroly nie.

Nástroje zmenšujú slepé miesta

Tu sa oplatí oddeliť dve slová, ktoré sa v bežnej reči zvyčajne hádžu do jedného vreca. Model vie presne jedno: dostať rozhovor a vrátiť pokračovanie. Agent je program okolo modelu, ktorý má nástroje: čítanie súboru, spustenie príkazu, úpravu projektu.

A teraz detail, od ktorého závisí, kde presne vzniká chyba. Nástroje nevyberá program. Model vo svojej odpovedi požiada otvoriť taký a taký súbor alebo spustiť taký a taký príkaz, a program túto požiadavku skontroluje, vykoná a vráti výsledok späť do rozhovoru. Rozhoduje model, vykonáva program. Takže sa môže mýliť aj samotné rozhodnutie: nie ten súbor, nie ten príkaz, nie ten test.

Rozdiel je aj tak obrovský. Kým súbor nie je otvorený, odpoveď o ňom sa skladá z pamäti na podobné projekty. Len čo je súbor prečítaný a test spustený, v rozhovore sa objaví fakt: tu je obsah, tu je výstup. To už nie je spomienka, ale kontrola, a kvalita odpovedí po nej je citeľne iná.

Z toho plynie trik, ktorý stojí jeden riadok na začiatku rozhovoru:

Najskôr nájdi a ukáž, kde to v projekte je, a až potom vysvetľuj.

Slepé miesta sa tým zužujú, ale nemiznú. Agent môže otvoriť vedľajší súbor namiesto potrebného, vyložiť si výstup príkazu po svojom alebo sa zastaviť pri prvom vierohodnom vysvetlení a k skutočnej príčine sa nedostať. To všetko som videl, a nie raz. Preto vonkajší signál - výstup testu, text dokumentácie, obsah súboru - váži viac než najsebavedomejšia úvaha bez opory.

Tri kontroly, ktoré stoja minútu

Dobrá správa je, že takéto chyby sa dajú chytať takmer bez námahy. Všetko sa zúži na jedno rázcestie.

Pozerať sa tu treba nie na to, ako presvedčivo je to napísané, ale na to, či je v odpovedi niečo, čoho sa dá chytiť: konkrétny súbor, konkrétny riadok, príkaz s jeho výstupom. Nie je opora - znamená to, že máte pred sebou zatiaľ hypotézu, nie výsledok. Mnohé odpovede sa tak aj začínajú, otázka je len v tom, čo urobíte ďalej.

Ďalej tri kontroly. Každá zaberie menej ako minútu a všetky tri naraz treba len zriedka.

1. Požiadať, aby ukázal miesto. Nie "vysvetli podrobnejšie", ale "ukáž súbor, riadok a samotný úryvok". Ak také miesto nie je, hneď sa to ukáže.
2. Otvoriť alebo spustiť výsledok sami. Stránku v prehliadači, príkaz v termináli, test v projekte. Hlásenie o práci a práca nie sú to isté.
3. Porovnať tvrdenie o nástroji so samotným nástrojom. Príkaz má vstavanú nápovedu, knižnica dokumentáciu. Spomenutý prepínač alebo kľúč konfigurácie tam buď je, alebo nie je, a zistí sa to za pol minúty. S metódou knižnice je to prísnejšie: do dokumentácie sa nedostane všetko, preto je jej absencia dôvodom sa dopytovať, nie rozsudkom.

Ukáž súbor a riadok, kde je to opísané.
Ak také miesto v projekte nie je, povedz rovno, že je to predpoklad.

A hneď jedna výhrada, aby nezostala zlá pachuť. Overovať neznamená nedôverovať nástroju. Aj svoj vlastný diff si pred commitom prečítate, hoci ste ho písali sami. Tu je to to isté, len dôvod je o niečo závažnejší.

Čo to znamená pre prácu s Claude Code

Čo z toho všetkého vyplýva priamo za klávesnicou:

• odpoveď s odkazom na súbor, riadok alebo výstup príkazu sa overí za pár sekúnd. Odpoveď bez nich nie je čím overiť: zostáva ju len prečítať a súhlasiť;
• nechajte agenta prečítať potrebné ešte predtým, než položíte otázku. Jeden krok navyše odstráni celú triedu chýb;
• podľa istoty súdiť nemožno: je nadhodnotená bez ohľadu na to, či je za slovami overenie, alebo odhad;
• "znie správne" a "funguje správne" sú rôzne veci a rozlíši ich iba spustenie;
• čím vyššia je cena chyby, tým skôr by sa v rozhovore malo objaviť niečo externé: test, dokumentácia, skutočný súbor. Pri drobnej úprave stačí pohľad na diff;
• ak sa agent pomýlil, povedzte mu to faktom, nie hodnotením. "Takáto funkcia v projekte nie je, v priečinku je toto" posúva prácu ďalej, "zase si si všetko vymyslel" ju nikam neposunie. A majte na pamäti: na sebavedomú námietku sa agent skôr prispôsobí, než by sa hádal, aj keď pravdu mal on. Súhlas agenta nie je potvrdením, že máte pravdu vy.

Mechanizmus, ktorý sa občas sebavedomo mýli, pritom zostáva mimoriadne užitočný. Poznať jeho hranice treba práve na to, aby ste nestrácali čas údivom a hneď prešli ku kontrole.