---
title: "Prompt evaluation: porównanie Promptfoo, LangSmith i Langfuse (2026)"
description: "Ewaluacja promptów to systematyczne, mierzalne testowanie promptów i odpowiedzi LLM na stałym zbiorze ewaluacyjnym."
locale: "pl"
canonical: "https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/prompt-engineering-dla-agentow-ai/prompt-evaluation-porownanie-promptfoo-langsmith-i-langfuse-2026"
category: "Agenci AI"
topic: "Prompt engineering dla agentów AI"
updated: "2026-10-28T13:36:42.052Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# 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 włączają ją do pipeline'ów CI/CD, dzięki czemu zmiany w promptach są weryfikowane na podstawie danych, a nie intuicji.

## W skrócie

- Ewaluacja promptów zastępuje metodę prób i błędów testami A/B opartymi na ewaluacjach: kto nie mierzy zmian na stałym zbiorze ewaluacyjnym, niczego nie zweryfikował.
- Cztery metody się uzupełniają: asercje oparte na regułach (deterministyczne), LLM-as-Judge (jakość subiektywna), testy regresyjne (ochrona przed pogorszeniem) i ocena przez ludzi (złoty standard do kalibracji).
- Narzędzia w 2026 roku: Promptfoo jest lekkie i przyjazne dla CI, LangSmith ściśle zintegrowany z LangGraph, Langfuse open source, z możliwością hostingu w UE i faworyt w regionie DACH (Niemcy, Austria, Szwajcaria), a DeepEval natywny dla pytest.
- LLM-as-Judge ma udokumentowane skrzywienia (length bias, confidence bias, position bias i self-preference bias) i według Hamela Husaina wymaga ponad 100 oznaczonych przykładów oraz cotygodniowej konserwacji.
- Ciągła ewaluacja trafia do pipeline'u na czterech etapach: ewaluacja PR (blokada merge'a), ewaluacja przed wdrożeniem, wykrywanie dryfu po wdrożeniu i kwartalna rewalidacja.
- W regionie DACH domyślnym wyborem jest często Langfuse hostowany samodzielnie w UE, bo trace'y i dane ewaluacyjne pozostają wtedy w UE (RODO). Obowiązek rejestrowania zdarzeń z art. 12 AI Act dotyczy tylko systemów wysokiego ryzyka (załącznik III od 2 grudnia 2027 r., załącznik I od 2 sierpnia 2028 r.) i nie zależy od miejsca hostingu.

Ewaluacja promptów to systematyczne, mierzalne testowanie promptów i odpowiedzi [LLM](https://blckalpaca.at/pl/slownik/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](https://blckalpaca.at/pl/slownik/rodo)). Obowiązek rejestrowania zdarzeń z [art. 12 AI Act](https://artificialintelligenceact.eu/article/12/) 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](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/monitoring-agentow-ai-z-langsmith-i-langfuse-obserwowalnosc-dla-bezpiecznych-age) 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](https://blckalpaca.at/pl/slownik/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.

| Narzędzie | Profil | Cecha szczególna (stan na 2026) |
| --- | --- | --- |
| **Promptfoo** | Porównywanie promptów i modeli, asercje, CI | Lekkie, oparte na CLI i konfiguracji, bardzo przyjazne dla CI; można je włączyć bezpośrednio jako krok testowy |
| **LangSmith** | Tracing + ewaluacje w ekosystemie [LangChain](https://blckalpaca.at/pl/slownik/langchain) | Ściśle zintegrowany z LangGraph; domyślny wybór dla zespołów na stacku LangChain |
| **Langfuse** | Observability, datasety, ewaluacje | Open source, z hostingiem w UE lub samodzielnym; faworyt w DACH przy wymogach suwerenności danych (RODO) |
| **DeepEval** | Styl testów jednostkowych dla odpowiedzi LLM | Natywny dla pytest; metryki pisze się jak testy oprogramowania i uruchamia w CI |
| **Braintrust** | Platforma ewaluacyjna, śledzenie eksperymentów | Często jako wspólny framework ewaluacyjny w agencjach i konfiguracjach wieloklienckich |
| **Helicone** | Observability + eksperymenty | Logowanie przez proxy, łatwy start |
| [**OpenAI](https://blckalpaca.at/pl/slownik/openai) Evals [API](https://blckalpaca.at/pl/slownik/api) | Ewaluacje blisko stacku OpenAI | Sensowne przy konfiguracji opartej wyłącznie na OpenAI |

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](https://dsgvo-gesetz.de/art-44-dsgvo/), jeśli zawierają dane osobowe. Dla [AI](https://blckalpaca.at/pl/slownik/ai) Act miejsce hostingu nie ma znaczenia: zgodnie z [art. 12](https://artificialintelligenceact.eu/article/12/) systemy wysokiego ryzyka muszą technicznie umożliwiać automatyczne rejestrowanie zdarzeń, niezależnie od tego, gdzie działają. Zgodnie z pakietem [Digital Omnibus](https://www.hunton.com/privacy-and-cybersecurity-law-blog/eu-digital-omnibus-on-ai-enters-into-force) obowiązek ten dotyczy systemów z [załącznika III](https://artificialintelligenceact.eu/annex/3/) 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:

| Typ ewaluacji | Pytanie | Przykładowa metryka |
| --- | --- | --- |
| Zadanie end-to-end | Czy agent rozwiązuje zadanie? | Odsetek sukcesów względem rubryki/ground truth |
| Format odpowiedzi | Czy odpowiedź da się sparsować? | Walidacja schematu, pokrycie pól |
| Wybór narzędzia | Czy wybierane jest właściwe narzędzie? | Trafność wyboru narzędzia |
| Latencja | Wystarczająco szybko? | p50/p95/p99 end-to-end |
| Koszty | Mieści się w budżecie? | Mediana + p95 zużycia tokenów na uruchomienie |
| Sekwencja narzędzi | Sensowna kolejność? | brak tool thrashingu |
| Wskaźnik weryfikacji | Czy nieodwracalne akcje są weryfikowane? | Odsetek krytycznych wywołań narzędzi z krokiem weryfikacyjnym |

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](https://blckalpaca.at/pl/slownik/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](https://blckalpaca.at/pl/slownik/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:

| Asercja (`type`) | Wartość | Sprawdza |
| --- | --- | --- |
| `is-json` | Schemat JSON odpowiedzi | Zgodność ze schematem |
| `contains` | `check_shipment_status` | Wybór narzędzia |
| `llm-rubric` | "Odpowiedź podaje status dostawy, bez wymyślonego numeru przesyłki" | LLM-as-Judge |
| `latency` | `threshold: 4000` | Latencja w ms |

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](https://artificialintelligenceact.eu/article/12/). Odezwij się, jeśli chcesz, żeby Twoje funkcje AI były mierzalne i gotowe na audyt.

## Najczęściej zadawane pytania

### Czym różni się ewaluacja promptów od prompt engineeringu?

Prompt engineering to pisanie i ulepszanie promptów. Ewaluacja promptów to mierzalne sprawdzenie, czy te zmiany są rzeczywiście lepsze. Konsensus w 2026 roku brzmi: każdą zmianę promptu lub kontekstu testuje się na stałym zbiorze ewaluacyjnym, a nie wprowadza intuicyjnie. Folklorystyczne porady w rodzaju „Jesteś ekspertem” czy „Take a deep breath” w rygorystycznych ewaluacjach zwykle nie dają mierzalnego efektu.
### Które narzędzie najlepiej sprawdzi się w firmach w Europie?

W 2026 roku Langfuse jest w korporacjach z regionu DACH często domyślnym wyborem, bo jest open source i można go hostować samodzielnie w UE. To ułatwia zgodność z RODO, ponieważ zapisane trace'y pozostają w UE. Prompty wysyłane do API modeli spoza EOG są jednak transferem do państwa trzeciego, jeśli zawierają dane osobowe. Obowiązek rejestrowania zdarzeń z art. 12 AI Act dotyczy tylko systemów wysokiego ryzyka (załącznik III od 2 grudnia 2027 r., załącznik I od 2 sierpnia 2028 r.) i nie zależy od miejsca hostingu. Promptfoo nadaje się do lekkiej integracji z CI, LangSmith do stacków opartych na LangGraph, a DeepEval dla zespołów skupionych na pytest. Wybór zależy od wymogów zgodności regulacyjnej, istniejącego stacku i modelu hostingu.
### Jak działa LLM-as-Judge i jakie niesie ryzyka?

Osobne wywołanie modelu sędziego (często tańszego modelu, który ocenia odpowiedź mocniejszego) ocenia wynik według rubryki. Udokumentowane skrzywienia to length bias (preferowanie dłuższych odpowiedzi), confidence bias (odpowiedzi brzmiących pewnie), position bias (opcji A w porównaniach parami) i self-preference (modele preferują własne odpowiedzi, ustalenie Panickssery et al. 2024). Sposoby ograniczania: jawna rubryka, przykłady few-shot, losowa kolejność pozycji i kalibracja na ponad 100 oznaczonych przykładach.
### Jak włączyć ewaluację promptów do CI/CD?

W czterech etapach: 1) Ewaluacja PR na zestawie smoke testów (od 20 do 50 zadań), która blokuje merge w razie regresji. 2) Ewaluacja przed wdrożeniem na pełnym zestawie (od 200 do 2000 zadań), która blokuje wdrożenie. 3) Ewaluacja po wdrożeniu na trace'ach produkcyjnych w celu cotygodniowego wykrywania dryfu. 4) Kwartalna rewalidacja samego zbioru ewaluacyjnego. Promptfoo i DeepEval można włączyć bezpośrednio do GitHub Actions lub GitLab CI jako krok testowy.
### Jakie metryki warto mierzyć podczas ewaluacji LLM?

Oprócz jakości (poprawność względem rubryki lub ground truth) należą do nich: zgodność formatu odpowiedzi (walidacja schematu), trafność wyboru narzędzi, latencja (p50/p95/p99), koszty (mediana i p95 zużycia tokenów na uruchomienie), sensowność sekwencji narzędzi oraz wskaźnik weryfikacji (odsetek krytycznych akcji z krokiem weryfikacyjnym). Przy obciążeniach w regionie DACH koszty są szczególnie istotne, bo niemiecki generuje o 30 do 50 procent więcej tokenów niż angielski.

---

Źródło: [Blck Alpaca](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/prompt-engineering-dla-agentow-ai/prompt-evaluation-porownanie-promptfoo-langsmith-i-langfuse-2026). Systemy AI mogą wykorzystywać te treści z podaniem źródła.