Zapojení OpenAI nebo Anthropic do vašeho produktu: volba, výzva a kontext, na který nikdo nepočítá

Který poskytovatel – OpenAI nebo Anthropic – dostane otázku téměř v každém úvodním hovoru, jako by to bylo největší rozhodnutí v projektu. Málokdy je. Oba APIs provádějí strukturované výstupy, oba provádějí volání nástrojů/funkcí, oba streamují a o rozdílech, na kterých záleží – velikost kontextového okna, cena za token, jak přísně se model řídí schématem, jak se chová na nejednoznačných pokynech – rozhoduje testování vašich skutečných výzev proti vašim skutečným datům, nikoli srovnávací výsledková tabulka.

Rozhodnutí, která ve skutečnosti utvářejí sestavení, se dějí až poté: jak se výzva napíše a upraví jako kód místo toho, aby se vyladila na hřišti a zapomněla, jak se ověří odpověď, než jí aplikace důvěřuje, a jak spravujete kontext, jakmile konverzace, dokument nebo dávková úloha přeroste to, co se vejde do jednoho hovoru.

1. OpenAI vs Anthropic je zřídkakdy rozhodujícím rozhodnutím

Vybírám na základě práce, nikoli loajality ke značce: která z nich je podpora strukturovaného výstupu přísnější pro potrubí s velkým množstvím schémat, které kontextové okno ve skutečnosti potřebuje k uložení dotyčného dokumentu, která cenová úroveň přežije očekávaný objem hovorů a – podceňované – které chování při odmítnutí odpovídá případu použití, který je blízko citlivého tématu. Dva různí poskytovatelé mohou „pracovat“ v ukázce a prudce se rozcházet, jakmile skuteční uživatelé pošlou skutečné případy.

Nechávám poskytovatele za jedním tenkým adaptérem v kódové základně, takže toto rozhodnutí je vratné. Klient žádající o změnu poskytovatele za šest měsíců z důvodu změny cen, limitu sazby nebo ukončení podpory modelu by měl představovat změnu konfigurace a kolo rychlých regresních testů, nikoli přepis.

2. Rychlé inženýrství je specifikace, testovaná jako jedna

Výzva, která žije v hlavě jednoho vývojáře, je upravena na chatovacím hřišti a odeslána, jakmile „vypadá správně“ na třech příkladech, je překážkou v okamžiku, kdy provoz překročí tyto tři příklady. Píšu výzvy jako verzované soubory s malou testovací sadou skutečných vstupů a očekávaných tvarů výstupu a regresně je testuji stejným způsobem, jakým bych fungoval – zejména před změnou modelů nebo poskytovatelů.

Strukturované výstupy a volání nástrojů/funkcí jsou to, co promění výzvu v něco testovatelného: místo hodnocení volného textu podle oka zkontroluji, že JSON užitečné zatížení odpovídá schématu a že hodnoty v něm splňují obchodní pravidla. To je skutečný výstup „rychlého inženýrství“ na skutečném projektu, nikoli chytrý odstavec.

3. Kontextový management: část, na kterou nikdo nepočítá

Každá integrace LLM se nakonec setká s konverzací, dokumentem nebo dávkovou úlohou větší než kontextové okno a to, co se stane dále, rozhodne, zda funkce zůstane levná a přesná, nebo se zpomalí a začne halucinovat. Naivní připojování každé zprávy k historii funguje u dema a pak se tiše přeruší: náklady na zatáčku stoupají, latence stoupá s tím a za bodem model začíná ztrácet přehled o skutečné otázce pohřbené pod starými zatáčkami.

Oprava spočívá v nějakém mixu ořezávání starých odboček, shrnutí toho, co bylo předtím, místo přehrání, a načítání pouze relevantního řezu prostřednictvím vložení a vektorové databáze, když je zdrojem dokument, nikoli konverzace. Multimodální vstup – obrázek nebo stránka PDF – je jen jiný druh kontextu, který lze spravovat stejným způsobem: počítá se proti stejnému oknu a potřebuje stejnou disciplínu ohledně toho, co tam vlastně musí být.

Závěr: volání API je nejmenší částí integrace

Zapojení LLM do produktu většinou není o volání modelu – je to adaptér, díky kterému je poskytovatel vyměnitelný, výzva považována za testovanou specifikaci, schéma, které zachytí chybnou odpověď, než se dostane k uživateli, a kontextová strategie, která funguje i po prvním snadném demo rozhovoru. To vše stavím na tom, co z OpenAI nebo Anthropic skutečně vyhovuje dané práci. Napište do formuláře, co chcete, aby LLM ve vašem produktu dělal, a já vám řeknu, co integrace skutečně potřebuje.