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

Prompt Evaluation je systematické, merateľné testovanie promptov a výstupov LLM oproti fixnej eval-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. Jadro: zmeny promptu a kontextu sa validujú dátovo, nie intuíciou. Najbrutálnejší 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 zameraní: Promptfoo (odľahčený, CI-friendly), LangSmith (blízky LangGraph), Langfuse (open-source, hostovateľný v EU), DeepEval (pytest-natívny).
• DACH default: Langfuse self-hosted v EU kvôli GDPR a logovaniu podľa EU AI Act (čl. 12, plne použiteľný od 2. augusta 2026).

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

Iteračný cyklus sa posunul: ladenie promptov metódou pokus-omyl nahrádzajú eval-riadené A/B testy. Úprimným poznatkom z rokov 2024 až 2026 je, že mnohé populárne tipy na prompty na rigoróznych evaloch vykazujú minimálne alebo žiadne zlepšenie. „Si expert“ nemá na moderných modeloch väčšinou žiadny merateľný efekt. „Think step by step“ je na reasoning modeloch už default správanie a manuálne často kontraproduktívne. „Take a deep breath“ alebo „I'll tip you $200“ sú anekdotické a v kontrolovaných evaloch nereprodukovateľné.

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 eval-sade. Práve to zabezpečuje Prompt Evaluation.

Štyri metódy evaluácie

Evaluácia pripravená na produkciu vrství viacero postupov na seba, pretože žiaden samotný nestačí.

1. Assertions a pravidlá (deterministické)

Pravidlové kontroly sú najlacnejšia a najrýchlejšia vrstva. Patria sem schema validation (JSON-Schema, Pydantic, Zod), kontroly substring a regex, numerické sanity checks („Total musí byť väčší alebo rovný súčtu položiek“) a field-coverage. Assertions sú deterministické, rýchle a bezplatné a mali by pokryť väčšinu objektívne overiteľných požiadaviek skôr, než sa použijú drahšie metódy.

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

Pre subjektívnu kvalitu hodnotí samostatný judge-call výstup oproti rubriku, často lacnejší model oproti výsledku silnejšieho. LLM-as-Judge je v roku 2026 štandardom, má však zdokumentované skreslenia, ktoré treba aktívne mitigovať:

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

Mitigácia: explicitný rubrik s konkrétnymi kritériami namiesto „je to dobré?“, few-shot príklady (pozitívne aj negatívne) v judge-prompte, párové porovnania s randomizovanou pozíciou a kalibrácia na vlastnú eval-sadu. Odporúčanie Hamela Husaina: LLM-as-Judge evaly potrebujú 100+ olabelovaných príkladov plus týždennú údržbu.

3. Regresné testy

Fixná eval-sada funguje ako regresná suita. Každá zmena promptu, tool-katalógu alebo retrieval indexu sa proti nej spustí, aby sa zhoršenia odhalili skôr, než prejdú do produkcie. Dôležité: meniť len jednu premennú na test, nie súčasne top-K, re-ranking a tool-description.

4. Human-Eval

Human-Review zostáva zlatým štandardom, najmä pre high-stakes rozhodnutia a na kalibráciu LLM-judgeov. V praxi sa využíva ako vzorka a na tvorbu olabelovaných referenčných dát, oproti ktorým sa automatický judge ciachuje.

Eval-first alebo error-analysis-first?

V roku 2026 existujú dva tábory. Tábor „eval-first“ napíše eval skôr, ako sa agent postaví, aby definoval kritériá úspechu a zabránil scope-driftu. Hamel Husain naopak argumentuje za „error-analysis-first“: na rozdiel od klasického softvéru nie sú failure-mody LLM predvídateľné, preto by sa mali písať evaluátory pre objavené, nie pre vymyslené chyby.

V praxi sú obe kompatibilné: začni s malým end-to-end evalom (10 až 50 reprezentatívnych úloh), iteruj agenta, zbieraj produkčné trace, urob error-analysis na reálnych failuroch a postav špecifické sub-evaly pre objavené failure-mody.

Nástroje v porovnaní (stav 2026)

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

Poznámka k voľbe nástroja: Langfuse je v roku 2026 v koncernovom kontexte DACH často default, pretože je možný EU-hosting a self-hosting, a tým sa pokrýva GDPR a logovanie podľa EU AI Act (čl. 12). Promptfoo a DeepEval bodujú tam, kde evaluácia ako kód patrí do existujúcej CI pipeline.

Aké metriky sa merajú

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

Náklady si v priestore 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 pre rovnaký sémantický obsah. Eval-reporty by preto mali merať spotrebu tokenov oproti skutočnému, nemecky hovoriacemu profilu workloadu.

Integrácia do CI/CD

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

1. PR-Eval na smoke-test sade (20 až 50 úloh): blokuje merge pri regresii.
2. Pre-deploy eval na plnej sade (200 až 2 000 úloh): blokuje deploy pri regresii.
3. Post-deploy eval na produkčných trace: drift detection, týždenne.
4. Štvrťročná re-validácia: previerka samotnej eval-sady na relevanciu, integrácia nových failure-modov.

Seriózna validačná metóda je kontrolované A/B testovanie s fixnou eval-sadou: jedna premenná na test, minimálne 50 až 200 reprezentatívnych úloh, pri malých sadách explicitne reportovať effect-size namiesto len „lepšie/horšie“ a nové varianty nechať bežať paralelne cez production-traffic shadowing.

Konkrétny príklad: Promptfoo v pipeline

Customer-service agent má na otázku „Kde je môj balík?“ deterministicky zavolať tool check_shipment_status a dodať schéme zodpovedajúcu JSON odpoveď. Eval ako pseudo-config:

```yaml
prompts: [file://system_prompt_v3.txt]
providers: [anthropic:claude-sonnet]
tests:

• vars: { frage: "Wo ist mein Paket?" }
  assert:
• • type: is-json # Schema/Assertion
  • type: contains
    value: "check_shipment_status" # Tool-Selection
  • type: llm-rubric # LLM-as-Judge
    value: "Antwort nennt Lieferstatus, keine erfundene Tracking-Nummer"
  • type: latency
    threshold: 4000 # Metrik: Latenz in ms
    ```

V GitHub Actions beží promptfoo eval ako test-step. Výpočtový príklad: PR-smoke sada zahŕňa 40 úloh, pre-deploy sada 600. Pri prechode z prompt-varianty A na B stúpne tool-selection accuracy v evale zo 79 na 88 percent, p95-latencia zostáva pod 4 sekundami, p95-spotreba tokenov klesne o 12 percent. Keďže je zlepšenie štatisticky viditeľné a bez regresie, merge sa uvoľní. Ak padne niektorá z assertions, pipeline sa automaticky zablokuje.

Pre agentúry a B2B

Pre marketingové agentúry a DACH-B2B tímy je Prompt Evaluation rozdielom medzi „bot beží“ a „bot beží preukázateľne spoľahlivo“. Kto dodáva LLM-funkcie pre klientov, potrebuje zdieľaný eval-framework (napríklad Langfuse self-hosted alebo Braintrust) s eval-sadami na klienta, GDPR-konformnú logovaciu vrstvu v EU regióne a regresné gates v pipeline. Tak sa dajú zmeny modelu, prompt-updaty a nové nástroje preukázateľne zabezpečiť namiesto hádania. Blck Alpaca z Viedne stavia tieto eval-riadené pipeline pre firmy v regióne DACH vrátane výberu nástrojov, CI/CD integrácie a logovania v súlade s EU AI Act. Ozvite sa nám, ak chcete svoje AI-funkcie urobiť merateľnými a audit-odolnými.