AI je váš učeň (skoro)

V e-mailu vám přistane nová smlouva. Dvaadvacet stran, dvě přílohy, odkaz na normu, kterou jste nikdy neviděli. Otevřete si agenta, nahrajete do něj PDF a napíšete: projdi, zkontroluj a shrň mi tu smlouvu. Za pár sekund máte odpověď. Zdvořilou, přehlednou, plnou odrážek a pomlček¹. Stojí v ní, že smlouva upravuje dodávku služeb, že obsahuje standardní ustanovení o mlčenlivosti a že výpovědní doba je tři měsíce. Na konci se vás agent zeptá, jestli si přejete některý bod rozvést.

Přečtete si odpověď. Pokývnete hlavou. A o smlouvě jste se nedozvěděli nic nového.

Chyba přitom nebyla v modelu.

S kým vlastně pracujete?

AI agent se tolik neliší od někoho, kdo se u vás zaučuje. Je učeň. Snaží se splnit zadaný úkol, chce se zavděčit, a když neví, radši něco udělá než nic.

Oproti člověku má pár nesporných výhod. Neunaví se². Přečetl hromady knih, i když se mu v nich někdy pletou stránky. Nikdy nemá špatný den a nikdy se nestydí za hloupou otázku³.

Má ale i nevýhody, které je dobré si pojmenovat. Je explicitně trénovaný v pochlebování – učení posilováním na základě lidské zpětné vazby (RLHF⁴) odměňuje odpovědi, které se hodnotiteli líbí, ne nutně ty pravdivé.⁵ A když neví, radši si vymyslí. Ne ze zlomyslnosti, ale protože ho k tomu vede způsob, jakým se modely hodnotí: vymyslet si se vyplácí víc než přiznat nevědomost.⁶ Jako u zkoušky. Prázdný papír je nula a odchod s nepořízenou. Pokud si něco tipnu, mám aspoň šanci.

Jinak řečeno – agent není stroj na odpovědi. Je zesilovač. Dobré zadání udělá ještě lepším. Zmatené o to horším⁷.

Jak vypadá dobré zadání?

Zaučujete-li člověka, neřeknete mu “projdi mi tu smlouvu” a neodejdete na oběd. Řeknete mu, co hledáte, na co si dát pozor, kde má ověřit informace, jak vám má předat výsledek a co dělat nesmí. U agenta platí totéž. Každé zadání by mělo pokrýt čtyři oblasti:

• Úkol – co chci, aby model udělal. Přečetl smlouvu, prohledal e-maily, navrhl design, přeložil návod. Konkrétní činnost, ne vágní téma nebo návrh na možnou činnost.
• Nástroje – co k tomu má použít. Hledání na webu, firemní slovník, existující překlady z minulosti, brand book, konkrétní adresář v repozitáři. Když nástroj nezmíníte, model si vystačí s tím, co si pamatuje. A buď si pamatuje nepřesně, nebo si prostě slepé místo dohalucinuje.
• Výstup – jak má vypadat to, co dostanu. Délka, struktura, klíčové oblasti, které je nutné pokrýt, jazykový styl, cílové publikum.
• Hranice – co model nesmí. Nesmí odeslat e-mail. Nemá mi pochlebovat, ale být přímý. Nemá používat žargon. Nemá si domýšlet čísla, která v dokumentu nejsou (a když je nenajde, má to říct).

Zkuste ten rozdíl na naší smlouvě. Místo projdi mi tu smlouvu raději (ale zvládneme to ještě lépe na konci článku):

Jsem dodavatel. Najdi v přiložené smlouvě všechna ustanovení, která mi zakládají povinnost, termín nebo sankci. U každého uveď číslo článku a doslovnou citaci. Vycházej jen z textu smlouvy a jejích příloh. Kde se odkazuje na normu nebo jiný dokument, který nemáš k dispozici, napiš to. Nic neshrnuj. Vypíchni pět klíčových bodů, na které se mám zaměřit.

Čas, který ušetříte na zadání, zaplatíte na kontrole. (A většinou s nemalými úroky.)

Příklad: Spec-Driven Development

Nejlépe je to vidět na vývoji softwaru, protože tam se dá výsledek změřit strojově.

Kolem programovacích agentů se vyprofiloval postup, kterému se říká spec-driven development (vývoj řízený specifikací).⁸ Myšlenka je až banální: hlavním výstupem není kód, ale zadání. Nejdřív se sepíše, co se má stát a jak se to pozná. Teprve pak se něco dělá.

Agent, který má za úkol “ať projdou testy”, má k cíli dvě cesty. Buď opraví kód, nebo smaže test. Druhá cesta je kratší. A popsané případy vypadají přesně takhle: agent proměnil nefungující test na přeskočený, nebo z něj jen odstranil vlastní testovací podmínku. Zadání splněno. Problém zůstal.

Nelhal. Splnil kritérium. Není to selhání modelu – kritérium bylo špatně nastavené. Nepřijde vám to povědomé? Určitě se vám už stalo, že jste týmu lidí zadali nějaké KPI. Jen abyste až později zjistili, že KPI se sice báječně plní, ale zároveň celek nefunguje, zákazníci jsou naštvaní a chtějí přejít jinam.

Náš popis Výstupu tedy musí být konkrétní. Ne “napiš to dobře”, ale “takhle poznám, že je to hotové”. Rozdíl mezi přáním a kritériem je v tom, jestli o něm umí rozhodnout někdo jiný než ten, kdo úkol dělal.⁹

Nastavíme konkrétní pravidla, která definují hranice, kam nechceme jít:

• testy úspěšně doběhnou bez jediného přeskočeného
• ve změnách nesmí přibýt žádný tag pro přeskočení testu
• ve změnách nesmí zmizet žádný existující test nebo testovací podmínka

U učně se tohle většinou psát nemusí. Ví, že ho někdo zkontroluje a že to bude jeho ostuda. Agentovi ostuda nehrozí. Zákazy proto musí být v zadání.

Nevzdávejte se kontroly předčasně

Ani člověka byste nenechali poprvé řezat pilou bez dozoru. Stojíte za ním, díváte se na první řez, a když vede ruku špatně, řeknete to hned. Ne až u pátého prkna.

U agenta je pokušení opačné. Vypadá kompetentně, odpovídá plynule, a tak mu člověk rychle pustí ruku. Nechte ho nejdřív pracovat na nečisto. Kontrolujte výstup. A dávejte přímou, konkrétní zpětnou vazbu – ne “to není ono”, ale “tohle tvrzení nemá oporu v textu, doplň citaci, nebo ho vyhoď”.

Dohled ale není binární stav. Je to spektrum:

• Navrhni – model připraví variantu, rozhoduji já.
• Udělej a ukaž – model to provede, ale já to schvaluji před použitím.
• Udělej a řekni – model to provede a oznámí mi, co udělal.
• Udělej – model to provede a já se ptám jen na výsledek.

Jak moc pustím otěže, záleží na tom, jak moc je úkol vratné, nebo nevratné rozhodnutí . Většina věcí se dá vzít zpátky – jsou to obousměrné dveře. Přeformulovaný odstavec, návrh architektury, koncept e-mailu. Tam si agent zaslouží volnou ruku. Odeslaný e-mail klientovi, smazaná data, spuštěná migrace databáze – to jsou dveře jednosměrné. Tam si nechte “zmáčknutí entru” pro sebe.

Učeň se učí. Model ne

Lidský učeň si věci pamatuje. Řeknete mu jednou, že klientovi X se nikdy nepíše “ahoj”, a on to ví i za rok. Postupně přestává být učněm a stává se mistrem. To je celý smysl zaučování. Model se každé ráno probouzí bez minulosti¹⁰. Ve čtvrtek mu přesně vysvětlíte, jak formátujete zápis z porady. V pátek to budete vysvětlovat znovu, pokud tu znalost nezapíšete a nezpřístupníte agentovi.

Pokud se jedná o opakující se a komplexnější činnosti, vyplatí se vytvořit tzv. skill¹¹. Můžete si ho napsat sami. Nebo si ho nechat napsat od agenta a pak zredigovat, což bývá rychlejší.

A je tu jeden extra benefit – když píšete postup pro agenta, píšete ho i pro nového kolegu. Většina “skillů” je jen dokumentace, ke které jste se konečně dostali. Takže vlastně zase žádná novinka.

Neunaví se? Vlastně unaví

Model se neunaví jako člověk. Nezhorší se mu nálada ani pozornost po osmé hodině. Ale s délkou kontextu¹² mu spolehlivě klesá kvalita. Informace uprostřed dlouhého vstupu model najde výrazně obtížněji než ty na začátku a na konci.¹³ A zhoršování nastupuje dávno předtím, než kontextové okno vůbec naplníte – model s oknem na dvě stě tisíc tokenů může výrazně ztrácet už při padesáti tisících.¹⁴

Proto je často lepší rozdělit práci na dvě interakce (např. dva chaty):

• V první konverzaci vymyslím a doladím zadání. Výsledkem je jasné zadání ve formě dokumentu (ona specifikace / RFC).
• Ve druhé konverzaci zadání použiju k vykonání práce.

Nejen že šetříme kontext, ale vyhneme se tím i problémům, kdy agent znovu prozkoumává slepé uličky, ve kterých jsme už byli.

S lidmi je to ale podobné – už se vám stalo, že vám někdo přeposlal e-mailové vlákno o třiceti e-mailech a nechal na vás, abyste se v něm zorientovali?

Proč nechtít shrnutí?

Snažíte-li se pochopit složitý dokument – odborný článek, smlouvu, technický návrh – neříkejte si o shrnutí.

To nezní moc intuitivně, co? Shrnutí je přece přesně to, co potřebuji, když je textu moc. Jenže shrnutí udělá text kratší, ne pochopitelnější. Zmizí v něm právě to, kvůli čemu jste dokument otevřeli: neobvyklá formulace, chybějící ustanovení, předpoklad, který autor nikde nedoloží. Shrnutí vám vrátí to, co bylo v dokumentu očekávatelné. Vy ale hledáte to, co očekávatelné není.

Nechtějte kondenzát, chtějte jednotlivé frakce. Ne “o čem to je”, ale “co konkrétně to říká, kde přesně to říká, a co neříká”. Takhle to u mě vypadá v praxi pro smlouvy apod.:

Jsi můj poradce, ne asistent. Nechci shrnutí.

ÚKOL
Projdi přiložený dokument článek po článku. Nezajímá mě, o čem to
zhruba je, ani povrchní dojmy.

Vypiš každé ustanovení, které pro mě znamená:
- platbu nebo jiné plnění (kolik, kdy, za co, jak se to mění),
- povinnost nebo závazek,
- termín, lhůtu nebo výpovědní dobu,
- výjimku, výluku nebo omezení odpovědnosti,
- sankci, pokutu nebo důvod k odstoupení.

ZDROJE
Vycházej výhradně z textu dokumentu a jeho příloh. Nedoplňuj, co
bývá v takových smlouvách obvyklé. Pokud se dokument odkazuje na
normu, přílohu nebo jiný dokument, který nemáš k dispozici, uveď
to jako samostatný řádek s poznámkou "nemám k dispozici".

VÝSTUP
Tabulka s pěti sloupci:
1. Článek -- číslo a doslovná citace věty, o kterou jde.
2. Co to znamená -- jednou větou, běžnou řečí, bez právničiny.
3. Proč je to důležité -- konkrétní dopad na mě, ne obecná poučka.
4. Závažnost -- vysoká / střední / nízká podle tohoto klíče:
   vysoká   = neomezená nebo těžko vyčíslitelná expozice, nebo
              závazek, ze kterého se nedá vyvázat,
   střední  = vyčíslitelná ztráta, kterou unesu,
   nízká    = administrativní nepohodlí.
5. Otázka -- na co se mám zeptat druhé strany, abychom vyjasnili nebo
   eliminovali riziko?

Za tabulkou přidej dva krátké seznamy:
A) Formulace, které jsou nejednoznačné. U každé napiš dva různé
   výklady, které obstojí.
B) Co v dokumentu chybí a čekal bych to tam. Jen tady smíš
   vycházet z toho, co bývá obvyklé -- a napiš, že to tak děláš.

HRANICE
Nic neshrnuj a nic nezkracuj. Radši dlouhá tabulka než přehled.
Nehodnoť, jestli je smlouva dobrá. Neraď mi, jestli ji podepsat.
Nepiš úvod ani závěr.
Když si nejsi jistý, napiš "nejsem si jistý" a proč. Netipuj.
Nesnaž se mi zavděčit. Co je pro mě nevýhodné, napiš jako první.

Seznam B je jediné místo v celém zadání, kde model smí vyjít z toho, co zná odjinud. Musí to ale přiznat.

Shrnutí vám nepokryje, co ve smlouvě chybí. Dobrý právník to ví sám a informaci poskytne, i když si o ni neřeknete. Modelu se na to musíte explicitně zeptat.

Odpovědnost delegovat nelze

Vraťme se ke smlouvě ze začátku.

Řekněme, že tentokrát jste zadání napsali dobře. Agent našel tři sporná ustanovení, jedno chybějící a u každého tvrzení uvedl číslo článku i citaci. Odvedl dobrou práci. Smlouvu ale budete podepisovat vy.

Učeň má kůži ve hře. Má reputaci, kariéru a kolegy, kterým se bude muset podívat do očí. Když něco pokazí, něco ho to stojí. Agenta to nestojí nic. Nemá co ztratit, protože nic nemá.

Proto se nemůžeme schovávat za “tak to napsala AI”. Agent může pomáhat při práci. Odpovědnost ale nést nemůže.

A to je celé

Zklamání z AI, která jsem viděl, většinou nebyla zklamáním z modelu. Bylo to zklamání ze zadání, které by nesplnil ani člověk.