Líná rezoluce a správně velké modely: Inteligenci utrácejte tam, kde se vyplatí

Sledujte, kde datový agent skutečně tráví čas a peníze, a vyskočí na vás vzorec: drtivá většina jeho práce není těžká. Je to vyhledávání. Namatchování „žena" na hodnotu kódu. Rozlišení, jestli je zpráva opravdová otázka, nebo jen pozdrav. Vytažení „Prahy" z věty. To nejsou výkony uvažování — je to úřednina. A přesto naivní návrh směruje každou z nich přes tentýž velký, pomalý, drahý model, který používá na opravdu náročnou práci.

Právě o tomto plýtvání je tenhle článek, a má dvě nápravy, které spolu krásně fungují: odlož vyhledávání a zvol pro každý úkol správně velký model.

Past zaplavení kontextu

Začněme konkrétním selháním. Agent potřebuje napsat dotaz filtrující na kódovaný sloupec — řekněme oborovou klasifikaci s přes tisícem možných hodnot. Instinkt velí dát generujícímu modelu vše, co by mohl potřebovat, takže systém poslušně nahraje všech tisíc kódů do promptu a požádá ho, ať napíše dotaz.

Teď je prompt z 95 % klasifikačních kódů. Ten jeden fakt, na kterém záleží — který kód znamená to, na co se uživatel ptal — je zahrabaný v šumu, a model, kterého žádáte, ať najde jehlu v kupce sena, kterou jste mu sami podali, ztrácí nit. Už jsme to pojmenovali: halucinace přes rušivé prvky. Ironie je ostrá. Zaplavili jste kontext, abyste pomohli, a právě ta záplava rozbila odpověď.

Hlubší problém je, že jste smíchali dvě různé práce — psaní dotazu a vyřešení hodnoty — a donutili jeden model dělat obojí naráz, špatně.

Líná rezoluce: napiš dotaz, hodnotu odlož

Rozdělte ty práce. Nechte generující model napsat strukturu dotazu a všude, kde potřebuje kódovanou hodnotu, ať místo hádání ID vypustí placeholder. Něco čitelného jako @ENUM_OSOBA_POHLAVI_ZENA — „sem patří kód pohlaví, který znamená žena, doplň později".

Generující model nikdy nevidí těch tisíc kódů. Dělá to, v čem je dobrý — strukturu — a vyhledání pošle dál. Pak přebírá samostatný, drobný krok rezoluce:

1. Zahlédne placeholder a odečte tabulku a sloupec.
2. Dotáhne kompletní seznam hodnot pro jen ten jeden sloupec — všechny, protože teď záleží na přesnosti a seznam je malý.
3. Předá malému modelu jednu zaostřenou otázku: „Tady je pojem ‚žena' a tady jsou platné hodnoty: 1 = muž, 2 = žena. Které ID?"
4. Dostane zpět 2, dosadí ho do dotazu a jde dál.

Tři věci dělají tohle lepším než zaplavený přístup. Není tu žádné zaplavení kontextu — velký model se nikdy neutopí v kódech. Je tu přesnost — resolver vidí celý seznam a soustředí se přesně na jedno mapování, což je úkol, který v podstatě nemůže zkazit. A je tu robustnost, kterou dostanete skoro zdarma: protože resolver matchuje podle významu, ne podle natvrdo zapsaného ID, v den, kdy někdo přečísluje databázi tak, že žena bude kód 5, to systém prostě najde. Nikdy se nespoléhal na číslo. Spoléhal se na slovo.

Správně velké modely: přestaňte najímat profesora na 1 + 1

Líná rezoluce připravuje druhou myšlenku, protože ten drobný krok rezoluce je dokonalým příkladem práce, která nepotřebuje výkonný model. Namatchování pojmu na krátký seznam je práce s nízkou inteligencí. Tak na ni neutrácejte peníze za vysokou inteligenci.

Princip: směrujte každý dílčí úkol k nejlevnějšímu modelu, který ho zvládne spolehlivě. Klasifikace záměru, extrakce entit, matchování hodnot, jednoduché ano/ne kontroly — ty jdou k rychlým, levným modelům. Těžké uvažování — plánování vícekrokového dotazu, diagnostika subtilního selhání — zůstává u toho drahého. Nezavolali byste statika, aby vyměnil žárovku; poslali byste učně s jasnými instrukcemi. Stejná logika, aplikovaná na rozpočet tokenů.

Věc, která tohle dělá bezpečným — a tu část týmy přeskakují — jsou strukturované výstupy. Levný model nechaný psát prózu bude plácat a chybovat. Tentýž levný model přinucený vrátit jedinou hodnotu z pevné sady, nebo malý JSON objekt s pojmenovanými poli, je najednou spolehlivý, protože jste mu odebrali prostor k bloudění. Nesestavuje odpověď; vyplňuje formulář. Omezte tvar a malý model bude matchovat hodnoty, klasifikovat záměry a extrahovat entity v kvalitě, která obstojí — za zlomek latence a nákladů.

Tohle je offloading v nejpravějším smyslu: vezměte velký objem triviálních rozhodnutí, přesuňte je na levné modely s těsnými kontrakty na výstup a uvolněte svůj nejlepší model, aby přemýšlel o těch jedné dvou věcech, které opravdu vyžadují přemýšlení.

Odštěp, deleguj, sluč

Tentýž instinkt se škáluje od „který model" k „kolik jich naráz". Když agent narazí na fázi s několika nezávislými podotázkami, nemusí je řešit v řadě. Může se odštěpit (fork) — podobně jako se na Linuxu odštěpí proces — do sady sub-agentů, každému dát malý úkol a všechny je spustit naráz.

Jeden sub-agent ověří, že je konkrétní JOIN validní. Druhý vyřeší hodnotu proti číselníku. Třetí spočítá řádky pro kontrolu tabulky. Pracují paralelně; hlavní agent čeká na checkpointu — joinu ve smyslu vláken — dokud se všichni neohlásí, pak výsledky integruje a pokračuje. Pokud je dílčí úkol sám složitý, může odštěpit vlastní sub-agenty, do rozumné hloubky.

Fork/join vám koupí dvě věci naráz. Rychlost, protože nezávislá práce probíhá souběžně místo za sebou. A náklady, protože každý malý, dobře ohraničený dílčí úkol je přesně ten druh nízkointeligenční práce, kterou předáte levnému modelu se strukturovaným výstupem. Paralelismus a správné dimenzování nejsou dvě oddělené optimalizace — je to tatáž myšlenka, aplikovaná na čas a na peníze.

Slovo o tom, „jak dlouho to trvá?"

Tahle architektura mění otázku, kterou klienti vždy položí: jak je to rychlé? Poctivá odpověď zní, že doba zpracování není pevné číslo — je to funkce dvou věcí: velikosti schématu a složitosti otázky. Triviální otázka proti databázi o tisíci tabulkách je stejně rychlá, protože díky předpočítání agent nepročesává celé schéma, a díky paralelismu se nezávislá práce smrskne do času své nejpomalejší větve. Opravdu složitá, vícedílná otázka trvá déle, protože je toho opravdu víc na práci.

To není vytáčka; je to pravda o systému a stojí za to ji říct na rovinu. Co můžete slíbit, je, že čas je utracen tam, kde má — na té těžké části — a že snadných devadesát procent jste udělali rychlými a levnými tím, že odkládáte, co může počkat, zmenšujete, co lze zmenšit, a paralelizujete, co může běžet vedle sebe.

---

Platíte ceny špičkového modelu za úřednickou práci — nebo sledujete, jak latence bobtná na velkých schématech? Správné nadimenzování pipeline je obvykle nejrychlejší výhra, kterou najdeme. Pojďme se podívat, kde váš bot přeplácí svou inteligenci.