Prompt evaluation: porównanie Promptfoo, LangSmith i Langfuse (2026)

Ewaluacja promptów to systematyczne, mierzalne testowanie promptów i odpowiedzi LLM na stałym zbiorze ewaluacyjnym. Metody to asercje oparte na regułach, LLM-as-Judge, testy regresyjne i ocena przez ludzi. Narzędzia takie jak Promptfoo, LangSmith, Langfuse i DeepEval automatyzują ocenę i integrują ją z pipeline'ami CI/CD. Sedno: zmiany promptów i kontekstu weryfikuje się na podstawie danych, a nie intuicji. Najbardziej bezlitosny wniosek dla tech leadów w 2026 roku brzmi: kto nie mierzy, ten nic nie zrobił.

• Metody: asercje (deterministyczne reguły) + LLM-as-Judge (jakość subiektywna) + testy regresyjne (ochrona przed pogorszeniem) + ocena przez ludzi (kalibracja).
• Narzędzia w centrum uwagi: Promptfoo (lekkie, przyjazne dla CI), LangSmith (blisko LangGraph), Langfuse (open source, hosting w UE), DeepEval (natywny dla pytest).
• Domyślny wybór w DACH: Langfuse hostowany samodzielnie w UE, bo trace'y i dane ewaluacyjne nie opuszczają wtedy UE (RODO). Obowiązek rejestrowania zdarzeń z art. 12 AI Act nie zależy od miejsca hostingu i dotyczy tylko systemów wysokiego ryzyka.

Dlaczego ewaluacja promptów jest w 2026 roku obowiązkowa

Cykl iteracji się zmienił: dostrajanie promptów metodą prób i błędów ustępuje testom A/B opartym na ewaluacjach. Uczciwy wniosek z lat 2024–2026 jest taki, że wiele popularnych porad dotyczących promptów daje w rygorystycznych ewaluacjach minimalną poprawę albo żadną. „Jesteś ekspertem” na współczesnych modelach zwykle nie ma mierzalnego efektu. „Think step by step” jest w modelach rozumujących już domyślnym zachowaniem, a dodawane ręcznie często bywa kontrproduktywne. „Take a deep breath” czy „I'll tip you $200” to anegdoty, których nie da się odtworzyć w kontrolowanych ewaluacjach.

Konsekwencją jest empiryczne podejście: jeśli czegoś nie da się zmierzyć, to się nie wydarzyło. Folklorystyczne porady mogą służyć jako hipotezy, ale trzeba je zweryfikować na zbiorze ewaluacyjnym. Właśnie do tego służy ewaluacja promptów.

Cztery metody ewaluacji

Ewaluacja gotowa do produkcji nakłada na siebie kilka metod, bo żadna nie wystarcza sama.

1. Asercje i reguły (deterministyczne)

Kontrole oparte na regułach to najtańsza i najszybsza warstwa. Należą do nich walidacja schematu (JSON Schema, Pydantic, Zod), sprawdzanie podciągów i wyrażeń regularnych, liczbowe testy poprawności („Suma całkowita musi być większa lub równa sumie pozycji”) i pokrycie pól. Asercje są deterministyczne, szybkie i darmowe, a zanim wkroczą droższe metody, powinny pokrywać większość obiektywnie sprawdzalnych wymagań.

2. LLM-as-Judge (jakość subiektywna)

Przy jakości subiektywnej osobne wywołanie modelu sędziego ocenia odpowiedź według rubryki, często tańszy model ocenia wynik mocniejszego. LLM-as-Judge to w 2026 roku standard, ale ma udokumentowane skrzywienia, które trzeba aktywnie ograniczać:

• Length bias: preferowane są dłuższe odpowiedzi.
• Confidence bias: preferowane są odpowiedzi brzmiące pewnie, nawet jeśli są błędne.
• Position bias: w porównaniach parami nieproporcjonalnie często wybierana jest opcja A.
• Self-preference: modele preferują własne odpowiedzi (powtórzone ustalenie Panickssery et al. 2024).

Sposoby ograniczania: jawna rubryka z konkretnymi kryteriami zamiast „czy to jest dobre?”, przykłady few-shot (pozytywne i negatywne) w prompcie sędziego, porównania parami z losową kolejnością oraz kalibracja na własnym zbiorze ewaluacyjnym. Rekomendacja Hamela Husaina: ewaluacje typu LLM-as-Judge wymagają ponad 100 oznaczonych przykładów oraz cotygodniowej konserwacji.

3. Testy regresyjne

Stały zbiór ewaluacyjny pełni funkcję zestawu testów regresyjnych. Każdą zmianę promptu, katalogu narzędzi lub indeksu wyszukiwania uruchamia się na nim, aby wykryć pogorszenie, zanim trafi na produkcję. Ważne: zmieniaj tylko jedną zmienną na test, a nie jednocześnie top-k, re-ranking i opis narzędzia.

4. Ocena przez ludzi

Ocena przez ludzi pozostaje złotym standardem, szczególnie przy decyzjach o wysokiej stawce i do kalibracji sędziów LLM. W praktyce stosuje się ją wyrywkowo i do tworzenia oznaczonych danych referencyjnych, na których kalibruje się automatycznego sędziego.

Najpierw ewaluacja czy najpierw analiza błędów?

W 2026 roku istnieją dwa obozy. Obóz „eval-first” pisze ewaluację, zanim powstanie agent, aby zdefiniować kryteria sukcesu i zapobiec rozrastaniu się zakresu. Hamel Husain opowiada się natomiast za podejściem „error-analysis-first”: w przeciwieństwie do klasycznego oprogramowania tryby awarii LLM są nieprzewidywalne, dlatego ewaluatory należy pisać dla wykrytych, a nie wyobrażonych błędów.

W praktyce oba podejścia da się pogodzić: zacznij od małej ewaluacji end-to-end (od 10 do 50 reprezentatywnych zadań), iteruj agenta, zbieraj trace'y produkcyjne, analizuj błędy na rzeczywistych awariach i buduj konkretne podewaluacje dla wykrytych trybów awarii.

Porównanie narzędzi (stan na 2026)

Frameworki ugruntowane w stacku istotnym dla firm w Europie różnią się przede wszystkim profilem i modelem hostingu.

Uwaga do wyboru narzędzia: w 2026 roku Langfuse jest w korporacjach z regionu DACH często domyślnym wyborem, bo umożliwia hosting w UE i hosting samodzielny. To ułatwia zgodność z RODO, ponieważ zapisane trace'y i dane ewaluacyjne pozostają w UE. Prompty wysyłane do API modeli spoza EOG, także na potrzeby LLM-as-Judge, są jednak transferem do państwa trzeciego, jeśli zawierają dane osobowe. Dla AI Act miejsce hostingu nie ma znaczenia: zgodnie z art. 12 systemy wysokiego ryzyka muszą technicznie umożliwiać automatyczne rejestrowanie zdarzeń, niezależnie od tego, gdzie działają. Zgodnie z pakietem Digital Omnibus obowiązek ten dotyczy systemów z załącznika III od 2 grudnia 2027 r., a produktów z załącznika I od 2 sierpnia 2028 r. Typowi agenci marketingowi i obsługi klienta nie podlegają załącznikowi III. Jeśli jednak tworzysz system wysokiego ryzyka, możesz generować logi za pomocą narzędzi do tracingu, takich jak Langfuse. Promptfoo i DeepEval sprawdzają się tam, gdzie ewaluacja jako kod ma trafić do istniejącego pipeline'u CI.

Jakie metryki mierzyć

Sama jakość nie wystarczy. Zbiór ewaluacyjny gotowy do produkcji obejmuje kilka wymiarów:

Koszty wymagają w regionie DACH szczególnej uwagi: w popularnych tokenizerach niemiecki generuje o 30 do 50 procent więcej tokenów niż angielski przy tej samej treści semantycznej. Raporty z ewaluacji powinny więc mierzyć zużycie tokenów względem rzeczywistego, niemieckojęzycznego profilu obciążenia.

Integracja z CI/CD

Gotowość produkcyjna oznacza w 2026 roku, że ewaluacje uruchamiają się automatycznie przy każdej zmianie promptu, katalogu narzędzi, indeksu wyszukiwania lub modułów skilli. Sprawdzony wzorzec czteroetapowy:

1. Ewaluacja PR na zestawie smoke testów (od 20 do 50 zadań): blokuje merge w razie regresji.
2. Ewaluacja przed wdrożeniem na pełnym zestawie (od 200 do 2000 zadań): blokuje wdrożenie w razie regresji.
3. Ewaluacja po wdrożeniu na trace'ach produkcyjnych: wykrywanie dryfu, co tydzień.
4. Kwartalna rewalidacja: sprawdzenie aktualności samego zbioru ewaluacyjnego, uwzględnienie nowych trybów awarii.

Rzetelną metodą walidacji jest kontrolowany test A/B ze stałym zbiorem ewaluacyjnym: jedna zmienna na test, co najmniej od 50 do 200 reprezentatywnych zadań, przy małych zbiorach jawne raportowanie wielkości efektu zamiast samego „lepiej/gorzej” oraz równoległe uruchamianie nowych wariantów przez shadowing ruchu produkcyjnego.

Konkretny przykład: Promptfoo w pipelinie

Agent obsługi klienta ma na pytanie „Gdzie jest moja paczka?” deterministycznie wywołać narzędzie check_shipment_status i zwrócić odpowiedź JSON zgodną ze schematem. Uproszczona konfiguracja Promptfoo zawiera w tym celu w sekcji prompts plik file://system_prompt_v3.txt, w sekcji providers model Claude Sonnet (na przykład anthropic:messages:claude-sonnet-5-5), a w sekcji tests przypadek testowy z vars: { frage: "Wo ist mein Paket?" }. Ten przypadek testowy sprawdzają cztery asercje:

W GitHub Actions promptfoo eval działa jako krok testowy. Przykład liczbowy: zestaw smoke testów dla PR obejmuje 40 zadań, zestaw przed wdrożeniem 600. Po przejściu z wariantu promptu A na B trafność wyboru narzędzia w ewaluacji rośnie z 79 do 88 procent, latencja p95 pozostaje poniżej 4 sekund, a zużycie tokenów p95 spada o 12 procent. Ponieważ poprawa jest statystycznie widoczna i nie ma regresji, merge zostaje zatwierdzony. Jeśli którakolwiek z asercji nie przejdzie, pipeline automatycznie się blokuje.

Dla agencji i B2B

Dla agencji marketingowych i zespołów B2B w Europie ewaluacja promptów to różnica między „bot działa” a „bot działa niezawodnie i da się to udowodnić”. Kto dostarcza klientom funkcje oparte na LLM, potrzebuje wspólnego frameworka ewaluacyjnego (na przykład samodzielnie hostowanego Langfuse albo Braintrust) z zestawami ewaluacyjnymi dla każdego klienta, zgodnej z RODO warstwy logowania w regionie UE i bramek regresyjnych w pipelinie. Dzięki temu zmiany modeli, aktualizacje promptów i nowe narzędzia można zabezpieczyć dowodami zamiast zgadywać. Blck Alpaca z Wiednia buduje takie pipeline'y oparte na ewaluacjach dla firm w całej Europie, łącznie z wyborem narzędzi, integracją CI/CD i logowaniem, które w systemach wysokiego ryzyka spełnia wymagania art. 12 AI Act. Odezwij się, jeśli chcesz, żeby Twoje funkcje AI były mierzalne i gotowe na audyt.