LLM jako virtuální projektový tým III: od myšlenky k agentovi

V prvním dílu jsem v zásadě objevil Ameriku.

Zjistil jsem, že když nechám jeden jazykový model něco navrhnout a jiný model návrh kritizovat, dostanu často lepší výsledek než při jediné konverzaci s jedním chatbotem.

Ve druhém dílu přišel další krok: uvědomění, že ono přehazování textu mezi chatboty vlastně není žádná magie. Je to pracovní postup.

A pracovní postup se dá formalizovat.

Tentokrát tedy zkusím jít ještě o krok dál.

Co kdyby mezi uživatelem a jednotlivými modely stál program, který by celý proces řídil?

Ne chatbot.

Agent.

Nejprve jedna důležitá změna pohledu

Při běžném používání LLM si většinou představujeme něco takového:

člověk → chatbot → odpověď

Člověk něco napíše, model odpoví, člověk doplní otázku, model pokračuje.

Konverzace se postupně nabaluje.

To je velmi pohodlné, ale současně tím vzniká dlouhodobý kontext, který ovlivňuje další odpovědi.

Pro běžné povídání je to žádoucí.

Pro oponenturu už méně.

Pokud chci, aby někdo skutečně kritizoval návrh, nechci mu nejprve několik hodin vysvětlovat, proč je ten návrh skvělý.

Proto mi dává větší smysl jiná architektura:

člověk → agent → pracovní role → modely a nástroje

Uživatel komunikuje s agentem.

Agent si ale pro každý dílčí úkol vytváří vlastní pracovní kontext.

Autor tedy nemusí vědět, co bude tvrdit oponent.

Oponent nemusí vědět, jak dlouho autor k řešení docházel.

A arbitr nemusí vědět, který z nich je „ten hlavní“.

Dostane pouze materiály potřebné ke svému rozhodnutí.

Jedna úloha, několik kontextů

Představme si jednoduché zadání:

Navrhni podnikatelský model pro rekonstrukci historického objektu.

Klasický chatbot vytvoří odpověď a čeká na další otázku.

Agent může postupovat jinak.

Nejprve vytvoří pracovní návrh.

Ten ale nemusí okamžitě ukázat uživateli.

Místo toho vytvoří nový požadavek:

Jsi ekonomický oponent. Najdi slabá místa následujícího návrhu. Zaměř se na cash-flow, investiční náklady, provozní rizika a nereálné předpoklady.

A do tohoto požadavku vloží pouze samotný návrh.

Pak může vytvořit další:

Jsi technický oponent. Posuď proveditelnost navrženého řešení.

A další:

Jsi právní oponent. Identifikuj oblasti, které vyžadují právní ověření.

Nakonec může vzniknout ještě jeden kontext:

Máš původní návrh a tři nezávislé oponentury. Rozděl připomínky na zásadní, pravděpodobné a sporné a navrhni přepracovanou verzi.

Výsledkem už není jedna odpověď modelu.

Je to malý řízený proces.

Model není role

Tady je podle mě dobré oddělit dvě věci, které při práci s chatboty snadno splývají.

Model je technický prostředek.

Role je součást pracovního procesu.

Například:

Autor

• vytváří řešení,
• hledá varianty,
• snaží se splnit zadání.

Oponent

• hledá chyby,
• zpochybňuje předpoklady,
• aktivně hledá důvody, proč řešení nemusí fungovat.

Arbitr

• porovnává argumenty,
• hledá rozpory mezi jednotlivými stanovisky,
• rozhoduje, co má být vráceno autorovi k přepracování.

Všechny tři role může teoreticky vykonávat stejný jazykový model.

Agent mu pokaždé pouze vytvoří nový, nezávislý kontext.

To ale neznamená, že bych chtěl zůstat u jednoho modelu.

Právě naopak.

Když se modely neshodnou, začíná být práce zajímavá

Pokud autor i oponent používají stejný model, mohou mít podobná slepá místa.

Proto je užitečné mít možnost role rozdělovat také mezi různé poskytovatele.

Například:

• lokální model připraví podklady,
• jeden externí model vytvoří návrh,
• jiný provede oponenturu,
• třetí zkontroluje rozpory.

Agent přitom vůbec nemusí mít pevně napsáno:

Autor bude vždy model A.

Může pracovat spíš s požadavkem:

Potřebuji silný model pro rozsáhlé strategické uvažování.

Nebo:

Potřebuji levný model na klasifikaci dokumentů.

Nebo:

Potřebuji model s velkým kontextovým oknem.

Tím vzniká další zajímavá vrstva.

Agent už nevybírá pouze co se má udělat, ale také čím se to má udělat.

Lokální model nemusí být nejchytřejší

Zpočátku jsem měl tendenci uvažovat o lokálním LLM hlavně jako o levnější nebo soukromější náhradě cloudového modelu.

Postupně mi ale připadá zajímavější jiná role.

Lokální model může být koordinátor.

Nemusí psát nejlepší analýzu.

Stačí, když dokáže například:

• rozpoznat typ požadavku,
• najít relevantní dokumenty,
• vybrat potřebné části kontextu,
• rozdělit úlohu,
• rozhodnout, který nástroj použít,
• odstranit z podkladů informace, které není nutné odesílat ven,
• zpracovat odpovědi externích služeb.

To je podstatně méně efektní než generování dvacetistránkové studie.

Ale z hlediska architektury systému možná důležitější.

Lokální model se tak stává dispečerem.

Externí model nemusí znát celý projekt

Tohle považuji za jednu z nejzajímavějších vlastností celého návrhu.

Představme si, že mám projekt obsahující stovky dokumentů.

Nemusím všechny poslat do cloudového LLM.

Lokální část systému může nejprve určit, které informace jsou pro konkrétní problém relevantní.

Externí model potom dostane třeba jen toto:

Objekt má kapacitu 40 pokojů.
Odhad investičních nákladů je X.
Předpokládaná cena ubytování je Y.
Sezóna trvá Z měsíců.

Proveď ekonomický stress-test tohoto modelu.

Model nepotřebuje vědět:

• kdo projekt vlastní,
• jaké další projekty uživatel řeší,
• co bylo napsáno před měsícem,
• jaké jsou interní poznámky týmu.

Dostane pracovní balíček.

Odpoví.

A tím jeho role skončí.

Pro systém je to mnohem čistší než nekonečná konverzace.

Jenže proč vůbec používat LLM na všechno?

Nemusíme.

A tady se podle mě architektura začne definitivně vzdalovat představě „AI chatbotu“.

Řekněme, že agent dostane úkol:

Posuď ekonomickou udržitelnost projektu.

Jazykový model může navrhnout strukturu výpočtu.

Například zjistí, že potřebujeme:

• investiční náklady,
• počet jednotek,
• obsazenost,
• cenu,
• fixní náklady,
• variabilní náklady,
• úrok,
• dobu splácení.

Ale samotný výpočet nemusí dělat LLM.

Agent může zavolat Python.

Nebo spreadsheet.

Nebo Mathcad.

Nebo jiný matematický systém.

Výsledek může být například:

Při 45% obsazenosti je cash-flow záporné.
Bod zvratu nastává přibližně při 61 %.
Varianta s vyšší cenou snižuje potřebnou obsazenost na 54 %.

Teprve to se vrátí jazykovému modelu:

Interpretuj tyto výsledky a upozorni na hlavní rizika.

To mi připadá mnohem zdravější než žádat LLM:

Spočítej mi to a doufám, že ses někde nespletl.

Agent tedy není LLM

Agent je program.

To je možná nejdůležitější věta celého článku.

LLM může být jeho významnou součástí.

Ale agent sám může být úplně klasický software.

Může obsahovat:

• stav úlohy,
• databázi,
• historii jednotlivých kroků,
• šablony rolí,
• pravidla,
• frontu požadavků,
• správu nákladů,
• přístupová práva,
• rozhraní k externím API,
• rozhraní k lokálním nástrojům.

Jazykový model pouze pomáhá tam, kde je potřeba práce s významem.

To je podle mě důležitý rozdíl oproti představě, že postavíme jednoho „superagenta“ tím, že napíšeme extrémně dlouhý prompt.

Jednoduchý pracovní cyklus

Zkusme si celý proces představit velmi jednoduše.

Uživatel zadá:

Navrhni způsob financování projektu.

Agent nejprve vytvoří plán:

1. Získat dostupná data.

Lokální systém najde ekonomické podklady projektu.

2. Identifikovat chybějící údaje.

Pokud některé chybí, agent se zeptá uživatele.

3. Vytvořit varianty.

Jeden nebo více LLM vytvoří několik modelů financování.

4. Spočítat je.

Výpočetní nástroj spočítá cash-flow jednotlivých scénářů.

5. Provést oponenturu.

Nezávislý model dostane návrhy a výsledky.

6. Provést stress-test.

Agent změní několik vstupních parametrů a nechá výpočty zopakovat.

7. Vytvořit závěr.

LLM výsledky shrne do srozumitelného dokumentu.

Tady už začíná být zajímavé, že jednotlivé kroky nemusí být lineární.

Pokud například stress-test odhalí zásadní problém, může agent vrátit proces zpět:

oponentura → nový návrh → nový výpočet → nová oponentura

Vzniká smyčka.

A kdy má smyčka skončit?

Tohle je překvapivě důležitá otázka.

Bez omezení bychom totiž mohli vytvořit systém, ve kterém jeden model neustále opravuje druhý.

Autor něco navrhne.

Oponent to rozbije.

Autor to opraví.

Oponent najde další problém.

A za chvíli jsme utratili desítky dolarů za velmi sofistikovanou diskusi strojů mezi sebou.

Proto potřebuje agent nějakou formu stop podmínek.

Například:

• maximálně tři kola revize,
• skončit, pokud nejsou nalezeny zásadní námitky,
• skončit, pokud se skóre řešení už výrazně nezlepšuje,
• požádat člověka o rozhodnutí, pokud se modely zásadně neshodnou.

Člověk tedy z procesu nemizí.

Pouze se přesouvá na místa, kde má jeho rozhodování největší cenu.

Člověk jako eskalační úroveň

U klasického chatbota člověk řídí každý krok.

U agenta by měl řídit především cíle a zásadní rozhodnutí.

Například agent zjistí:

Varianta A je ekonomicky bezpečnější.
Varianta B nabízí větší potenciální výnos, ale výrazně vyšší riziko.

To už není technická otázka.

To je rozhodnutí vlastníka projektu.

Agent může připravit argumenty.

Neměl by ale automaticky předstírat, že zná uživatelovu ochotu riskovat.

Stejně tak může dojít k situaci:

Právní oponent tvrdí A, ekonomický model předpokládá B a tyto dva požadavky jsou pravděpodobně neslučitelné.

To je ideální okamžik pro eskalaci.

Ne další prompt.

Člověka.

Zajímavý vedlejší efekt: audit práce

Jakmile se celý proces formalizuje, vzniká něco, co u běžného chatování často chybí.

Stopa.

Je možné uložit:

• původní zadání,
• použité zdroje,
• návrh,
• oponenturu,
• výsledky výpočtů,
• jednotlivé revize,
• finální rozhodnutí.

Najednou je možné zpětně zjistit:

Proč systém doporučil právě tuto variantu?

Ne ve smyslu nějakého magického „myšlenkového pochodu“ modelu.

Ale jako velmi praktický pracovní záznam:

Protože varianta A byla navržena zde, výpočet ukázal toto, oponentura našla tyto problémy a po jejich zapracování vznikla varianta B.

To už začíná připomínat projektovou dokumentaci.

A tady se dostávám k tomu, co vlastně stavím

Na začátku jsem experimentoval s několika chatboty.

Postupně ale vzniká něco jiného.

Ne aplikace pro chatování s AI.

Spíš pracovní prostředí, ve kterém může mít každý projekt:

• dokumenty,
• úkoly,
• historii,
• zdroje,
• role,
• lokální nástroje,
• externí modely,
• automatické analýzy,
• lidská rozhodnutí.

LLM je v něm velmi důležitá součást.

Ale není středem vesmíru.

Je jedním z pracovníků.

Někdy autorem.

Někdy kritikem.

Někdy překladatelem mezi člověkem a matematickým nástrojem.

Někdy jen rychlým pomocníkem, který vytáhne z dokumentu několik relevantních údajů.

A možná právě to je směr, který mi připadá zajímavější než hledání jednoho stále chytřejšího chatbota.

Ne jeden virtuální génius.

Ale virtuální pracovní prostředí, které dokáže podle potřeby sestavit tým.