Prompt Evaluation: Promptfoo, LangSmith, Langfuse v porovnaní (stav 2026)

Prompt Evaluation je systematické, merateľné testovanie promptov a výstupov LLM oproti pevnej evaluačnej sade. Metódy sú pravidlové assertions, LLM-as-Judge, regresné testy a Human-Eval. Nástroje ako Promptfoo, LangSmith, Langfuse a DeepEval automatizujú hodnotenie a integrujú ho do CI/CD pipeline. Podstata: zmeny promptu a kontextu sa validujú na základe dát, nie podľa intuície. Najtvrdší poznatok pre tech leadov v roku 2026 znie: kto nemeria, neurobil nič.

• Metódy: assertions (deterministické pravidlá) + LLM-as-Judge (subjektívna kvalita) + regresné testy (ochrana pred zhoršením) + Human-Eval (kalibrácia).
• Nástroje v centre pozornosti: Promptfoo (odľahčený, vhodný pre CI), LangSmith (úzko previazaný s LangGraph), Langfuse (open-source, hostovateľný v EÚ), DeepEval (natívny pre pytest).
• Štandardná voľba v DACH: Langfuse prevádzkovaný na vlastnej infraštruktúre v EÚ, pretože trace záznamy a eval dáta tak neopustia EÚ (GDPR). Povinnosť logovania podľa čl. 12 EU AI Act nezávisí od miesta hostingu a platí len pre vysokorizikové systémy.

Prečo je Prompt Evaluation v roku 2026 povinnosťou

Iteračný cyklus sa posunul: ladenie promptov metódou pokusu a omylu nahrádzajú A/B testy riadené evalmi. Úprimný poznatok z rokov 2024 až 2026 je, že mnohé populárne tipy na prompty vykazujú v dôsledných evaloch minimálne alebo žiadne zlepšenie. „Si expert“ nemá na moderných modeloch väčšinou žiadny merateľný efekt. „Think step by step“ je pri reasoning modeloch už predvolené správanie a ručne pridané je často kontraproduktívne. „Take a deep breath“ alebo „I'll tip you $200“ sú anekdotické a v kontrolovaných evaloch sa nedajú zopakovať.

Dôsledkom je empirický základný postoj: ak sa to nedá zmerať, nestalo sa to. Folklórne tipy môžu slúžiť ako hypotézy, musia sa však overiť oproti evaluačnej sade. Presne to zabezpečuje Prompt Evaluation.

Štyri metódy evaluácie

Evaluácia pripravená na produkciu vrství viacero postupov na seba, pretože žiadny z nich sám nestačí.

1. Assertions a pravidlá (deterministické)

Pravidlové kontroly sú najlacnejšia a najrýchlejšia vrstva. Patria sem validácia schémy (JSON Schema, Pydantic, Zod), kontroly podreťazcov a regulárnych výrazov, numerické kontroly zmysluplnosti („Total musí byť väčší alebo rovný súčtu položiek“) a pokrytie polí. Assertions sú deterministické, rýchle a bezplatné a mali by pokryť väčšinu objektívne overiteľných požiadaviek skôr, než nastúpia drahšie metódy.

2. LLM-as-Judge (subjektívna kvalita)

Pri subjektívnej kvalite hodnotí výstup samostatné volanie judge modelu podľa hodnotiacej rubriky, často lacnejší model posudzuje výsledok silnejšieho. LLM-as-Judge je v roku 2026 štandard, má však zdokumentované skreslenia, ktoré treba aktívne zmierňovať:

• Length bias: uprednostňujú sa dlhšie výstupy.
• Confidence bias: uprednostňujú sa sebaisto znejúce výstupy, aj keď sú nesprávne.
• Position bias: v párových porovnaniach sa neúmerne často volí možnosť A.
• Self-preference: modely uprednostňujú vlastné výstupy (replikované zistenie Panickssery et al. 2024).

Zmierňovanie: explicitná hodnotiaca rubrika s konkrétnymi kritériami namiesto „je to dobré?“, few-shot príklady (pozitívne aj negatívne) v prompte judge modelu, párové porovnania s náhodne určenou pozíciou a kalibrácia podľa vlastnej evaluačnej sady. Odporúčanie Hamela Husaina: evaly typu LLM-as-Judge potrebujú 100+ označených príkladov a k tomu týždennú údržbu.

3. Regresné testy

Pevná evaluačná sada slúži ako regresná sada testov. Každú zmenu promptu, katalógu nástrojov alebo retrieval indexu na nej otestuj, aby sa zhoršenia odhalili skôr, než sa dostanú do produkcie. Dôležité: v jednom teste meň len jednu premennú, nie súčasne top-K, re-ranking a popis nástroja.

4. Human-Eval

Ľudské hodnotenie (human review) zostáva zlatým štandardom, najmä pri rozhodnutiach s vážnymi dôsledkami a pri kalibrácii LLM judge modelov. V praxi sa používa na kontrolu vzoriek a na tvorbu označených referenčných dát, podľa ktorých sa automatický judge kalibruje.

Eval-first alebo error-analysis-first?

V roku 2026 existujú dva tábory. Tábor „eval-first“ píše eval skôr, než vznikne agent, aby definoval kritériá úspechu a zabránil rozširovaniu rozsahu (scope drift). Hamel Husain naopak presadzuje prístup „error-analysis-first“: na rozdiel od klasického softvéru sa spôsoby zlyhania (failure modes) LLM nedajú predvídať, preto treba písať evaluátory pre zistené, nie pre domnelé chyby.

V praxi sú oba prístupy zlučiteľné: začni malým end-to-end evalom (10 až 50 reprezentatívnych úloh), iteruj agenta, zbieraj produkčné trace záznamy, rob analýzu chýb na reálnych zlyhaniach a postav špecifické čiastkové evaly pre zistené spôsoby zlyhania.

Nástroje v porovnaní (stav 2026)

Frameworky etablované v stacku relevantnom pre DACH sa líšia predovšetkým zameraním a modelom hostingu.

Poznámka k výberu nástroja: Langfuse je v roku 2026 v koncernovom prostredí DACH často štandardnou voľbou, pretože umožňuje hosting v EÚ aj prevádzku na vlastnej infraštruktúre. To zjednodušuje súlad s GDPR, keďže uložené trace záznamy a eval dáta zostávajú v EÚ. Prompty posielané do API modelov mimo EHP, aj pri LLM-as-Judge, sú napriek tomu prenosom do tretej krajiny, len čo obsahujú osobné údaje. Pre EU AI Act miesto hostingu nehrá rolu: podľa čl. 12 musia vysokorizikové systémy technicky umožňovať automatické zaznamenávanie udalostí bez ohľadu na to, kde bežia. Po úprave nariadením Digital Omnibus platí táto povinnosť pre systémy podľa prílohy III od 2. decembra 2027 a pre produkty podľa prílohy I od 2. augusta 2028. Typickí agenti pre marketing a zákaznícky servis pod prílohu III nespadajú. Kto napriek tomu vyvíja vysokorizikový systém, môže logy vytvárať pomocou tracing nástrojov, ako je Langfuse. Promptfoo a DeepEval bodujú tam, kde evaluácia ako kód patrí do existujúcej CI pipeline.

Aké metriky sa merajú

Samotná kvalita nestačí. Evaluačná sada pripravená na produkciu pokrýva viacero dimenzií:

Náklady si v regióne DACH zaslúžia osobitnú pozornosť: nemčina vytvára v bežných tokenizéroch o 30 až 50 percent viac tokenov ako angličtina pri rovnakom sémantickom obsahu. Eval reporty by preto mali merať spotrebu tokenov oproti skutočnému profilu záťaže v nemčine.

Integrácia do CI/CD

Pripravenosť na produkciu v roku 2026 znamená, že evaly bežia automaticky pri každej zmene promptu, katalógu nástrojov, retrieval indexu alebo skill modulov. Osvedčený štvorstupňový postup:

1. PR-Eval na smoke-test sade (20 až 50 úloh): pri regresii zablokuje merge.
2. Pre-deploy eval na plnej sade (200 až 2 000 úloh): pri regresii zablokuje deploy.
3. Post-deploy eval na produkčných trace záznamoch: detekcia driftu, týždenne.
4. Štvrťročná revalidácia: preveriť relevanciu samotnej evaluačnej sady, zapracovať nové spôsoby zlyhania.

Seriózna metóda validácie je kontrolované A/B testovanie s pevnou evaluačnou sadou: jedna premenná na test, aspoň 50 až 200 reprezentatívnych úloh, pri malých sadách výslovne uvádzať veľkosť efektu (effect size) namiesto iba „lepšie/horšie“ a nové varianty nechať bežať paralelne cez shadowing produkčnej prevádzky.

Konkrétny príklad: Promptfoo v pipeline

Agent zákazníckeho servisu má na otázku „Kde je môj balík?“ deterministicky zavolať nástroj check_shipment_status a vrátiť JSON odpoveď zodpovedajúcu schéme. Zjednodušená konfigurácia Promptfoo na to obsahuje v časti prompts súbor file://system_prompt_v3.txt, v časti providers model Claude Sonnet (napríklad anthropic:messages:claude-sonnet-5-5) a v časti tests testovací prípad s vars: { otazka: "Kde je môj balík?" }. Tento testovací prípad overujú štyri assertions:

V GitHub Actions beží promptfoo eval ako testovací krok. Výpočtový príklad: PR smoke sada obsahuje 40 úloh, pre-deploy sada 600. Pri prechode z varianty promptu A na B stúpne presnosť výberu nástroja v evale zo 79 na 88 percent, p95 latencia zostane pod 4 sekundami a p95 spotreba tokenov klesne o 12 percent. Keďže je zlepšenie štatisticky viditeľné a bez regresie, merge sa schváli. Ak niektorá z assertions zlyhá, pipeline automaticky zablokuje merge.

Pre agentúry a B2B

Pre marketingové agentúry a B2B tímy v regióne DACH je Prompt Evaluation rozdielom medzi „bot beží“ a „bot beží preukázateľne spoľahlivo“. Kto dodáva LLM funkcie klientom, potrebuje zdieľaný eval framework (napríklad Langfuse na vlastnej infraštruktúre alebo Braintrust) s evaluačnými sadami pre každého klienta, logovaciu vrstvu v súlade s GDPR v regióne EÚ a regresné brány v pipeline. Zmeny modelov, aktualizácie promptov a nové nástroje tak vieš preukázateľne overiť a nemusíš hádať. Blck Alpaca z Viedne buduje takéto pipeline riadené evalmi pre firmy v regióne DACH vrátane výberu nástrojov, integrácie do CI/CD a logovania, ktoré pri vysokorizikových systémoch spĺňa požiadavky podľa čl. 12 EU AI Act. Ozvi sa nám, ak chceš svoje AI funkcie urobiť merateľnými a pripravenými na audit.