LLM‑First nebo Code‑First? Kde patří inteligence v produkční AI

Jak rozhodnout, co by měl model zpracovat, co by měl zpracovat váš kód a jak je propojit.

Před několika lety architektura AI aplikace vypadala takto: poslat výzvu velkému jazykovému modelu → získat odpověď → zobrazit ji uživateli. To už dnes není celý příběh. Modely jsou požádány, aby interpretovaly záměr, získávaly informace, vybíraly nástroje, volaly API, vytvářely plány a prováděly víceúrovňové pracovní postupy.

Tento posun rozdělil oblast na dvě – LLM‑First nebo Code‑First

V architektuře LLM‑first je model ve středu a rozhoduje, co se stane dál. Přečte požadavek, vybere nástroj, určí pořadí operací, zkontroluje mezivýsledky a podle potřeby změní směr.

V architektuře code‑first zůstává software/kód zodpovědný za sekvenci, obchodní pravidla, validaci, oprávnění a provádění. LLM zde funguje jako specialista, kterého kód volá, když je potřeba porozumění nebo generování jazyka.

Lidé rádi diskutují o tom, co je lepší. Myslím, že to je špatná otázka. Správnější otázka je, kam patří každý druh inteligence. Nejsilnější produkční systémy, které jsem viděl, jsou zřídka čistě jeden nebo druhý. Kombinují pravděpodobnostní uvažování s deterministickou kontrolou a dělají tak úmyslně.

Proč je LLM‑First tak přitažlivé

Tradiční software funguje skvěle, když můžete přesně vyjádřit požadavky. Například uživatel vybere produkt, zadá částku a odešle platbu. V kódu definujete povolené stavy, validační pravidla, chybové podmínky a sekvenci transakcí. Hotovo.

Přirozený jazyk tak ne spolupracuje. Představte si uživatele, který napíše: „Najdi transakce, které vypadají neobvykle, vysvětli, co se stalo, a řekni mi, co bych měl nejdříve prozkoumat.“

Neexistuje pevná cesta tímto požadavkem. Systém zde musí rozhodnout, co „neobvyklé“ znamená, zjistit, která data jsou podstatná, možná zavolat několik nástrojů, vyhodnotit odpověď a napsat vysvětlení, které člověk může použít. Žádný tým inženýrů/žádný kód nedokáže předem předvídat každé znění a každou kombinaci požadavků.

Je to místo, kde LLM hraje zásadní roli, funguje jako flexibilní vrstva uvažování mezi lidským jazykem a vašimi deterministickými službami. To je také důvod, proč získávají agenti tolik pozornosti. Google Cloud směrnice pro agentní AI architekturupopisuje agenta jako aplikaci, kde AI model funguje jako motor uvažování, zatímco nástroje mu umožňují přistupovat k externím systémům a datům.

Anthropic’s Building Effective AI Agents průvodce činí rozlišení, ke kterému se stále vracím. V workflow, modely a nástroje následují cesty, které definuje váš kód. V agent, LLM řídí vlastní proces a rozhoduje, jak použít své nástroje. Ten samý průvodce doporučuje začít s nejjednodušší architekturou, která problém vyřeší, místo aby se reflexně přidávala agentní složitost. Toto doporučení bych podtrhl dvakrát.

Limity „Nechte model rozhodnout“

Model může uvažovat o tom, co by se mělo stát. Uvažování není totéž jako vynucení pravidla.

Například vezměte finanční pracovní postup. LLM může být výborný v pochopení „pošli stejnou částku, kterou jsem poslal minulý měsíc stejnému dodavateli.“ Ale měl by také rozhodovat, zda je převod autorizován, vypočítat regulatorní limity, ověřit vlastnictví účtu, obejít bezpečnostní politiku a provést transakci?

Pravděpodobně ne. Tyto úkoly jsou deterministické, testovatelné, auditovatelné a vynutitelné, a to je přesně to, v čem tradiční software vyniká. Riziko roste, jakmile modely získají přístup k nástrojům. OWASP směrnice pro bezpečnost generativní AIoznačujenadměrná agentnostjako významné riziko: poskytovat systému založenému na LLM více funkcionality, oprávnění nebo autonomie, než jeho úkol vyžaduje. Podivný nebo manipulovaný výstup modelu je jedna věc, když produkuje text. Je to mnohem větší problém, když model může jednat ve skutečném světě.

Toto neznamená, že modely by nikdy neměly vykonávat akce. Znamená to, že autonomie modelu by měla být omezena deterministickou autoritou.

Code‑First stále má význam

S AI se vyvíjející tak rychle je snadné mít pocit, že konvenční inženýrství je mimo módu. Já bych argumentoval opačně. AI činí dobré deterministické systémy důležitějšími, ne méně.

Kód je stále správnou volbou, kdykoli úloha vyžaduje naprostou opakovatelnost. Autentizace je nejjednodušší příklad. Model by neměl „uvažovat“ o tom, zda má někdo administrátorská oprávnění. Vaše aplikace by měla požádat autoritativní systém pro identitu a správu přístupů. Totéž platí pro finanční výpočty, kontrolu oprávnění, validaci dat, regulatorní omezení, limity transakcí, validaci schémat a vše, co je nevratné. To vyžaduje explicitní smlouvy, ne odhady.

Toto se shoduje s širším myšlením o správě. NIST AI Risk Management Framework požaduje, aby organizace řídily rizika AI napříč návrhem, vývojem, nasazením a používáním. Jeho doprovodný Generative AI Profile uvádí, že generativní systémy mohou vyžadovat další dohled, dokumentaci, revizi a kontroly, v závislosti na souvisejícím riziku.

Proto mi přijde užitečné rozdělit každé rozhodnutí o designu na dvě otázky:

Co by se mělo stát?

a

Co je povoleno, aby se stalo?

LLM může často pomoci s první. Deterministické systémy by měly obvykle převzít druhou.

Hybridní vzor: uvažovat pravděpodobnostně, vykonávat deterministicky

Pro většinu podnikových aplikací je praktickou odpovědí hybrid. LLM funguje jako vrstva interpretace a uvažování. Deterministické služby fungují jako vrstva vykonávání a vynucování.

Zde je příklad. Představte si, že AI asistent pomáhá vývojářům vytvořit dočasná testovací prostředí API a vývojář napíše: \”Dej mi sandbox pro workflow onboarding zákazníka.\”

LLM to může interpretovat, zjistit, který workflow je pravděpodobně zamýšlen, přečíst dokumentaci a navrhnout, které API jsou pravděpodobně relevantní. Ale samotné vytvoření prostředí by nemělo záviset na volně generovaném textu. Kód může ověřit, že požadovaná API existují, validovat jejich smlouvy, zkontrolovat autorizaci, vynutit limity zdrojů, vygenerovat schválenou konfiguraci a spustit nasazení.

Hrubé rozdělení vypadá takto:

• LLM: rozumět, uvažovat, klasifikovat, navrhovat, shrnovat.
• Kód: validovat, autorizovat, počítat, uchovávat, vynucovat, spouštět.

Každá strana vykonává práci, ve které je nejlepší, a žádná není požadována, aby napodobovala silné stránky té druhé.

Hranice jsou důležitější, jak se agenti stávají výkonnějšími

Toto oddělení se stává důležitějším, když přecházíme od asistentů k agentům. Asistent, který poskytne špatnou odpověď, někoho obtěžuje. Agent s právy zápisu do produkce může způsobit mnohem větší nepořádek.

Řešení není nutně odstranit autonomii. Jde o to přidávat autonomii postupně, zatímco zachováváme explicitní kontrolní body. Google směrnice pro multi‑agentní systémydoporučuje spojovat dynamické chování AI s deterministickými bezpečnostními kontrolami, sledovatelností, jasně definovanou autonomií a lidským dohledem pro scénáře kritické pro podnikání.

Lidské schválení může být také zabudováno přímo do pracovního postupu místo neformální bezpečnostní sítě. Microsoft’s agent framework documentation, například podporuje volání nástrojů, která se pozastaví, dokud osoba výslovně neschválí požadovanou operaci.

Princip je jednoduchý: čím vyšší jsou důsledky akce, tím silnější by měly být deterministické kontroly kolem ní.

Pět otázek, které se zeptat před předáním úkolu LLM

Když rozhoduji, zda by komponenta měla být LLM‑first nebo code‑first, projdu si následující:

1. Má úkol jednu objektivně správnou odpověď? Pokud ano, upřednostněte deterministický kód. Daňové výpočty, oprávnění a validace schématu by se neměly měnit, protože model je dnes čte jinak.
2. Zahrnuje nejasný jazyk nebo nestrukturované informace? Pokud ano, LLM může přinést skutečnou hodnotu.
3. Co se stane, pokud model udělá chybu? Správná architektura pro souhrn schůzky se výrazně liší od správné architektury pro zahájení platby.
4. Může být výstup nezávisle ověřen? Plány generované LLM jsou mnohem bezpečnější, když je lze před spuštěním zkontrolovat deterministickými pravidly.
5. Potřebuje to opravdu agenta? Pokud již znáte kroky, běžný pracovní tok s několika cílenými voláními LLM je obvykle jednodušší, levnější, snáze testovatelný a snáze provozovatelný.

Poslední otázka si zaslouží zvláštní pozornost. Agentové jsou výkonní právě proto, že dokážou zvládat situace, kdy nemůžete předvídat každý krok. Ale pokud můžete předvídat kroky, proměnit je v otevřený problém uvažování často přidává variabilitu, aniž by přidával inteligenci.

Spolehlivost je architektonická vlastnost, ne prompt

Mnoho týmů začíná snažit se zlepšit spolehlivost téměř výhradně pomocí prompt engineeringu. Promptů je důležitých, ale nemohou nést celou zátěž.

Produkční systém by měl předpokládat, že výstup modelu bude někdy neúplný, poškozený, neočekávaný nebo prostě špatný. OWASP Top 10 pro LLM aplikace uvádí rizika jako prompt injection a improper output handling, což posiluje klíčový zvyk: zacházet s výstupem modelu jako s nedůvěryhodným vstupem pro downstream systémy, nikoli jako s instrukcemi k automatickému spuštění.

To mění otázku, kterou si kladete. Místo „Jak napsat výzvu, která vždy přiměje model dodržet pravidlo?“, se ptejte „Jak navrhnout systém tak, aby pravidlo nemohlo být porušeno i když model udělá chybu?“

To je problém softwarové architektury, ne problém výzev. Výzva může agentovi říci, aby neprovedl neautorizovanou akci. Autorizační služba ji může skutečně zastavit. Tyto dva ovládací prvky nejsou ekvivalentní.

Za debatou: systémy založené na záměru

Při úvahách o všem tom jsem dospěl k názoru, že debata LLM‑first versus code‑first směřuje k třetí myšlence: intent-first architektuře.

V systému založeném na záměru aplikace začíná tím, že pochopí, co uživatel chce dosáhnout. To je místo, kde je LLM nejcennější, protože lidé zřídka přesně formulují, co chtějí. Odtud systém postupně převádí tuto nejasnost na strukturované, deterministické operace.

Požadavek jako „Pomozte mi vyřešit problém s platbou zákazníka“ se může proměnit v pipeline: pochopit záměr, načíst transakci, identifikovat příčinu selhání, navrhnout řešení, požádat o schválení, provést schválenou operaci.

Některé z těchto fází těží z uvažování jazykových modelů. Ostatní by měly být pevné služby. Architektura není definována tím, zda AI nebo kód „vyhrává“. Je definována tím, kde je nejprve přijatelné nejisté.

Závěr

Jak se modely zlepšují, bude lákavé svěřit jim kontrolu nad stále většími částmi stacku. Někdy to bude správné rozhodnutí. V jiných systémech bude nejsofistikovanějším návrhem ten, který modelu úmyslně dává méně pravomocí.

Produkční AI inženýrství je v konečném důsledku o umístění inteligence na správnou hranici. Používejte jazykové modely tam, kde interpretace, uvažování, syntéza a adaptace přinášejí hodnotu. Používejte deterministický software tam, kde jsou důležité konzistence, autorizace, přesnost a vynucení. Pak propojte oba prostřednictvím úzkých, pozorovatelných, dobře otestovaných rozhraní.

Budoucnost podnikové AI pravděpodobně nebude čistě LLM‑first ani čistě code‑first. Je to LLM tam, kde nejistota vyžaduje inteligenci, a kód tam, kde jistota vyžaduje kontrolu.

Tento rozdíl může mít mnohem větší význam než výběr konkrétního modelu.