Testování a evaluace LLM aplikací v Pythonu: Praktický průvodce DeepEval

Proč nestačí „vibes" — evaluace LLM je inženýrská disciplína

Ruku na srdce — pokud jste někdy nasadili LLM aplikaci do produkce a spoléhali se na to, že „to vypadá dobře," nejste sami. Většina z nás si tím prošla. Přečtete si pár odpovědí, pokýváte hlavou a prohlásíte systém za funkční. Tomuto přístupu se v komunitě říká vibe-based evaluation a je to asi nejrychlejší cesta k produkčním incidentům, jakou znám.

Testování LLM aplikací se totiž zásadně liší od toho, na co jsme zvyklí u klasického softwaru. U běžné funkce očekáváte deterministický výstup — pro stejný vstup vždy dostanete stejný výsledek. U velkých jazykových modelů tomu tak prostě není. LLM jsou ze své podstaty nedeterministické — stejný prompt může při každém volání vygenerovat úplně jinou odpověď. Liší se formulace, struktura, někdy i faktická správnost. Takže ten klasický assert na přesnou shodu řetězců? Prakticky nepoužitelný.

A důsledky nedostatečné evaluace jsou hodně reálné.

Vzpomeňte si na případ Air Canada z roku 2024, kdy chatbot společnosti poskytl zákazníkovi chybnou informaci o slevách na letenky při úmrtí v rodině. Zákazník na základě této informace jednal, aerolinka odmítla slib chatbota splnit a případ skončil u soudu. Air Canada prohrála — soud rozhodl, že společnost odpovídá za výstupy svého AI systému. Tenhle případ se stal varovným příkladem pro celý průmysl a upřímně, není divu.

Nejde přitom o ojedinělý incident. S masivním nasazováním LLM do zákaznických služeb, interních nástrojů a automatizovaných workflow roste i počet selhání. Podle predikcí Gartneru z roku 2026 bude do roku 2028 přes 60 % vývojových týmů aktivně využívat specializované evaluační platformy pro testování AI výstupů. Evaluace LLM přestává být luxusem — stává se inženýrskou nutností na úrovni unit testů nebo code review.

Otázka tedy nezní, zda evaluovat, ale jak. A právě tady přichází na scénu framework DeepEval.

Co je DeepEval a proč zrovna tento framework

DeepEval je open-source Python framework licencovaný pod Apache 2.0, navržený specificky pro testování a evaluaci výstupů velkých jazykových modelů. Aktuální verze 3.x z roku 2026 nabízí zralý a stabilní nástroj, který si za dobu své existence vybudoval solidní komunitu — přes 13 000 hvězd na GitHubu a více než 3 miliony stažení měsíčně.

Pokud jste někdy pracovali s Pytestem, budete se v DeepEvalu cítit jako doma. A to není náhoda — framework je záměrně navržený tak, aby fungoval jako Pytest pro LLM výstupy. Píšete testovací funkce, definujete metriky a spouštíte je z příkazové řádky. Výsledkem je přirozený workflow, jaký znáte z klasického testování, jen místo porovnávání návratových hodnot vyhodnocujete kvalitu generovaného textu.

DeepEval podporuje prakticky jakýkoliv LLM use case: RAG pipeline, konverzační chatboty, autonomní agenty i jednoduché generativní úlohy. Klíčový je přístup LLM-as-a-judge — k vyhodnocení kvality výstupu se používá samotný jazykový model, což umožňuje posuzovat sémantické vlastnosti textu, které by tradiční metriky prostě nedokázaly zachytit.

Framework nabízí více než 50 metrik pokrývajících vše od relevance odpovědí přes věrnost zdrojovému kontextu až po detekci halucinací a bezpečnostní skenování. A bonus navíc — všechny metriky jsou multimodální, takže je můžete aplikovat nejen na text, ale i na obrazové vstupy.

Instalace a první kroky

Začít s DeepEval je jednoduché. Stačí klasická instalace přes pip:

# Instalace DeepEval
pip install deepeval

Pro fungování většiny metrik budete potřebovat přístup k LLM, který slouží jako „soudce." Nejběžnější volbou je OpenAI API:

# Nastavení API klíče jako proměnné prostředí
export OPENAI_API_KEY="váš-api-klíč"

Pokud preferujete lokální evaluaci bez závislosti na cloudových API (třeba kvůli ochraně dat), DeepEval podporuje i Ollama a další lokální modely. To se hodí zejména v korporátních prostředích s přísnějšími požadavky.

Doporučená struktura projektu pro LLM testy vypadá následovně:

můj_projekt/
├── src/
│   ├── llm_app.py          # Vaše LLM aplikace
│   └── rag_pipeline.py     # RAG pipeline
├── tests/
│   ├── test_odpovedi.py    # Testy kvality odpovědí
│   ├── test_rag.py         # Testy RAG pipeline
│   └── test_agenti.py      # Testy AI agentů
├── datasets/
│   └── golden_dataset.json # Referenční datové sady
└── deepeval.config.json    # Konfigurace DeepEval

Testy spouštíte příkazem deepeval test run, který interně využívá Pytest a přidává k němu LLM-specifickou funkcionalitu:

# Spuštění všech testů v adresáři tests/
deepeval test run tests/

Anatomie testovacího případu v DeepEval

Základní stavební kámen každého testu v DeepEval je třída LLMTestCase. Představte si ji jako kontejner, do kterého vložíte vše potřebné pro vyhodnocení jedné interakce s vaším LLM systémem.

Klíčové atributy LLMTestCase:

• input — vstupní dotaz nebo prompt od uživatele
• actual_output — skutečná odpověď vašeho LLM systému
• expected_output — očekávaná referenční odpověď (volitelné)
• retrieval_context — dokumenty získané z vektorové databáze v RAG pipeline
• context — skutečný „ground truth" kontext, tedy ideální informace, které by měl systém použít

Tak, pojďme se podívat na jednoduchý příklad:

from deepeval import assert_test
from deepeval.test_case import LLMTestCase
from deepeval.metrics import AnswerRelevancyMetric

def test_kvalita_odpovedi():
    # Vytvoření testovacího případu
    testovaci_pripad = LLMTestCase(
        input="Jaké jsou hlavní výhody Pythonu pro strojové učení?",
        actual_output="""Python nabízí rozsáhlý ekosystém knihoven jako
        NumPy, Pandas, Scikit-learn a TensorFlow. Má jednoduchou syntaxi,
        silnou komunitu a výbornou podporu pro datovou analýzu."""
    )

    # Definice metriky s prahovým skóre
    metrika = AnswerRelevancyMetric(threshold=0.7)

    # Spuštění testu — selže, pokud skóre klesne pod práh
    assert_test(testovaci_pripad, [metrika])

Pro testování vícekolových konverzací nabízí DeepEval třídu ConversationalTestCase. Ta zapouzdřuje celou historii konverzace jako sekvenci jednotlivých LLMTestCase instancí — a to je klíčové pro chatboty, kde záleží na kontextu předchozích zpráv:

from deepeval.test_case import LLMTestCase, ConversationalTestCase

# Definice vícekolové konverzace
konverzace = ConversationalTestCase(
    turns=[
        LLMTestCase(
            input="Dobrý den, potřebuji pomoc s objednávkou.",
            actual_output="Dobrý den! Rád vám pomohu. Můžete mi prosím sdělit číslo vaší objednávky?"
        ),
        LLMTestCase(
            input="Číslo objednávky je 12345.",
            actual_output="Děkuji. Vaše objednávka #12345 byla odeslána 5. března a je aktuálně na cestě. Předpokládané doručení je 12. března."
        )
    ]
)

Klíčové metriky pro evaluaci LLM

Metriky jsou srdcem celého evaluačního procesu. DeepEval jich nabízí desítky, ale pojďme se detailně podívat na ty, které budete v praxi používat nejčastěji.

GEval — univerzální metrika s chain-of-thought

GEval je pravděpodobně nejflexibilnější metrika v celém frameworku. Umožňuje vám definovat vlastní evaluační kritéria přirozeným jazykem a framework automaticky vygeneruje chain-of-thought evaluační kroky. Co je na tom zajímavé — výzkumy ukazují, že tento přístup dosahuje korelace s lidským hodnocením srovnatelné s mezilidskou shodou. Jinými slovy, hodnotí to skoro stejně dobře jako člověk.

from deepeval.metrics import GEval
from deepeval.test_case import LLMTestCaseParams, LLMTestCase
from deepeval import assert_test

def test_koherence_odpovedi():
    # Definice vlastní metriky pomocí GEval
    metrika_koherence = GEval(
        name="Koherence",
        criteria="""Koherence — posuzuje celkovou kvalitu a logickou
        strukturu odpovědi. Odpověď by měla být dobře organizovaná,
        myšlenky by na sebe měly logicky navazovat a text by měl
        tvořit ucelený celek.""",
        evaluation_params=[
            LLMTestCaseParams.INPUT,
            LLMTestCaseParams.ACTUAL_OUTPUT
        ],
        threshold=0.7
    )

    testovaci_pripad = LLMTestCase(
        input="Vysvětlete koncept Transfer Learning.",
        actual_output="""Transfer Learning je technika strojového učení,
        při které model natrénovaný na jedné úloze je použit jako
        základ pro řešení jiné, příbuzné úlohy. Místo trénování
        od nuly tak využíváme znalosti, které model již získal.
        To výrazně snižuje potřebu trénovacích dat a výpočetního
        výkonu."""
    )

    assert_test(testovaci_pripad, [metrika_koherence])

Answer Relevancy — relevance odpovědí

Metrika Answer Relevancy měří, jak relevantní je výstup vašeho LLM systému vzhledem ke vstupnímu dotazu. Jednoduše řečeno — odpovídá model skutečně na to, na co se uživatel ptá?

Může se to zdát jako samozřejmost, ale v praxi je překvapivě běžné, že modely „ujíždějí" od tématu nebo odpovídají na něco, na co se vlastně nikdo neptal.

from deepeval.metrics import AnswerRelevancyMetric
from deepeval.test_case import LLMTestCase
from deepeval import assert_test

def test_relevance_odpovedi():
    metrika = AnswerRelevancyMetric(
        threshold=0.7,
        model="gpt-4o"  # Volitelně specifikujte model pro evaluaci
    )

    testovaci_pripad = LLMTestCase(
        input="Jaká je hlavní města České republiky?",
        actual_output="Hlavním městem České republiky je Praha. Praha je zároveň největším městem země s přibližně 1,3 miliony obyvatel."
    )

    assert_test(testovaci_pripad, [metrika])

Faithfulness — věrnost zdrojovému kontextu

Pro RAG pipeline je metrika Faithfulness naprosto klíčová. Měří, zda výstup vašeho systému odpovídá informacím obsaženým v získaném kontextu z vektorové databáze (retrieval_context). Pokud model tvrdí něco, co není podloženo v dokumentech — máte problém.

Skóre se počítá jednoduše jako poměr: Počet pravdivých tvrzení / Celkový počet tvrzení. Když model ve své odpovědi uvede 10 tvrzení a 8 z nich je podloženo zdrojovým kontextem, dostanete skóre 0.8. Docela intuitivní, ne?

from deepeval.metrics import FaithfulnessMetric
from deepeval.test_case import LLMTestCase
from deepeval import assert_test

def test_vernost_kontextu():
    metrika = FaithfulnessMetric(threshold=0.8)

    testovaci_pripad = LLMTestCase(
        input="Jaké jsou podmínky pro vrácení zboží?",
        actual_output="""Zboží můžete vrátit do 30 dnů od zakoupení.
        Zboží musí být v původním obalu a nepoškozené.
        Peníze vám vrátíme na účet do 14 pracovních dnů.""",
        retrieval_context=[
            """Zákazník má právo vrátit zboží do 30 dnů od data
            nákupu. Zboží musí být v originálním nepoškozeném obalu.
            Refundace bude provedena na původní platební metodu
            do 14 pracovních dnů od přijetí vráceného zboží."""
        ]
    )

    assert_test(testovaci_pripad, [metrika])

Hallucination — detekce halucinací

Metrika Hallucination se na první pohled podobá Faithfulness, ale je tu důležitý rozdíl. Zatímco Faithfulness pracuje s retrieval_context (dokumenty z vektorové databáze), Hallucination používá context — tedy „ground truth" informace, o kterých víme, že jsou pravdivé.

Tuhle metriku oceníte v situacích, kdy chcete ověřit, že model nevymýšlí fakta, která se v dodaných kontextech prostě nenacházejí.

from deepeval.metrics import HallucinationMetric
from deepeval.test_case import LLMTestCase
from deepeval import assert_test

def test_halucinace():
    metrika = HallucinationMetric(threshold=0.5)

    testovaci_pripad = LLMTestCase(
        input="Řekněte mi o firmě Acme Corp.",
        actual_output="""Acme Corp byla založena v roce 2015 v Praze.
        Zaměstnává 200 lidí a specializuje se na AI řešení.
        V roce 2024 získala investici 50 milionů dolarů.""",
        context=[
            "Acme Corp byla založena v roce 2015 v Praze.",
            "Společnost zaměstnává přibližně 200 lidí.",
            "Acme Corp se specializuje na AI řešení pro enterprise zákazníky."
        ]
        # Tvrzení o investici 50 milionů není v kontextu —
        # metrika by měla detekovat halucinaci
    )

    assert_test(testovaci_pripad, [metrika])

Evaluace RAG pipeline od A do Z

V reálných projektech nebudete používat jen jednu metriku izolovaně — to by moc nepomohlo. RAG pipeline vyžaduje komplexní evaluaci, která pokryje jak kvalitu vyhledávání, tak kvalitu generování. DeepEval naštěstí umožňuje spustit více metrik najednou pomocí funkce evaluate().

Pojďme si ukázat kompletní příklad:

from deepeval import evaluate
from deepeval.test_case import LLMTestCase
from deepeval.metrics import (
    ContextualPrecisionMetric,
    ContextualRecallMetric,
    FaithfulnessMetric,
    AnswerRelevancyMetric
)

def evaluace_rag_pipeline():
    # Definice všech metrik pro RAG evaluaci
    kontextualni_preciznost = ContextualPrecisionMetric(threshold=0.7)
    kontextualni_recall = ContextualRecallMetric(threshold=0.7)
    vernost = FaithfulnessMetric(threshold=0.8)
    relevance = AnswerRelevancyMetric(threshold=0.7)

    # Simulace výstupu z vašeho RAG pipeline
    testovaci_pripady = [
        LLMTestCase(
            input="Jaké jsou výhody mikroservisní architektury?",
            actual_output="""Mikroservisní architektura umožňuje
            nezávislý vývoj a nasazování jednotlivých služeb,
            lepší škálovatelnost a technologickou flexibilitu.
            Každý tým může pracovat na svém mikroservisu nezávisle.""",
            expected_output="""Hlavní výhody zahrnují nezávislé
            nasazování, škálovatelnost a možnost použít různé
            technologie pro různé služby.""",
            retrieval_context=[
                """Mikroservisní architektura rozděluje aplikaci
                do malých, nezávislých služeb. Každá služba může
                být vyvíjena, nasazována a škálována nezávisle.
                Týmy mohou pro různé služby používat různé
                technologické stacky."""
            ],
            context=[
                """Výhody mikroservisní architektury: nezávislý
                vývoj a nasazování, horizontální škálovatelnost,
                technologická flexibilita, odolnost proti výpadkům."""
            ]
        ),
        LLMTestCase(
            input="Co je to CI/CD pipeline?",
            actual_output="""CI/CD pipeline je automatizovaný proces,
            který zahrnuje kontinuální integraci (automatické sestavení
            a testování kódu) a kontinuální doručování nebo nasazování
            (automatické vydání do produkce).""",
            expected_output="""CI/CD je praxe automatizace integrace
            a doručování kódu.""",
            retrieval_context=[
                """CI/CD (Continuous Integration/Continuous Delivery)
                je sada praktik, které automatizují proces sestavení,
                testování a nasazení softwaru. CI zajišťuje pravidelné
                slučování kódu, CD automatizuje vydání do produkce."""
            ],
            context=[
                """CI/CD pipeline automatizuje integraci kódu,
                jeho testování a nasazení do produkčního prostředí."""
            ]
        )
    ]

    # Spuštění evaluace se všemi metrikami najednou
    vysledky = evaluate(
        test_cases=testovaci_pripady,
        metrics=[
            kontextualni_preciznost,
            kontextualni_recall,
            vernost,
            relevance
        ]
    )

    # Výsledky obsahují skóre pro každý testovací případ a metriku
    print(vysledky)

Funkce evaluate() vrátí podrobný report se skóre pro každou kombinaci testovacího případu a metriky. Díky tomu jasně vidíte, kde váš RAG pipeline funguje dobře a kde má slabiny — jestli je problém ve vyhledávání dokumentů, nebo spíš v kvalitě generované odpovědi.

Testování AI agentů — nové metriky v DeepEval 3.x

S rostoucí popularitou autonomních AI agentů v roce 2026 přináší DeepEval 3.x zcela novou kategorii metrik založených na trasování (trace-based evaluation). A tohle je podle mě jedna z nejzajímavějších novinek frameworku. Na rozdíl od jednoduchého hodnocení vstup-výstup tyto metriky analyzují celý průběh práce agenta — jaké nástroje použil, v jakém pořadí, s jakými argumenty a jestli jeho plán vůbec dával smysl.

Klíčové metriky pro evaluaci agentů:

• Tool Correctness — ověřuje, zda agent použil správné nástroje pro daný úkol. Pokud má k dispozici kalkulačku a vyhledávač a uživatel se ptá na matematický výpočet, měl by sáhnout po kalkulačce, ne po vyhledávači.
• Tool Arguments — kontroluje, zda agent předal nástrojům správné argumenty. I když agent vybere správný nástroj, může ho zavolat s úplně špatnými parametry.
• Task Efficiency — měří, jestli agent splnil úkol s minimálním počtem kroků. Zbytečné smyčky a opakované volání stejného nástroje skóre snižují.
• Plan Following — vyhodnocuje, zda agent dodržel předepsaný plán. To je důležité hlavně v regulovaných prostředích, kde musí agent postupovat podle definovaného workflow.

Tyhle metriky dohromady pokrývají všechny aspekty kvality agentního chování — od správnosti rozhodování přes efektivitu až po dodržování pravidel. Pro produkční nasazení agentů jsou v podstatě nezbytné.

Integrace do CI/CD pipeline

Evaluace LLM má největší hodnotu, když probíhá automaticky při každé změně kódu. A tady musím říct, že DeepEval to má opravdu dobře vyřešené — integrace do CI/CD je bezproblémová. Následující příklad ukazuje kompletní konfiguraci pro GitHub Actions:

# .github/workflows/llm-evaluace.yml
name: LLM Evaluace

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  evaluace:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repozitáře
        uses: actions/checkout@v4

      - name: Nastavení Pythonu
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Instalace závislostí
        run: |
          pip install -r requirements.txt
          pip install deepeval

      - name: Spuštění LLM evaluace
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          deepeval test run tests/ -id "build-${{ github.run_number }}"

      - name: Kontrola regresí
        if: github.event_name == 'pull_request'
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          deepeval test run tests/ --compare-to "build-latest"

Všimněte si flagu -id, který přiřazuje testovacímu běhu unikátní identifikátor. To umožňuje regresní testování — můžete porovnávat výsledky mezi buildy a hned vidíte, když změna v promptu nebo konfiguraci modelu způsobí pokles kvality.

Pro škálovatelné testování se vyplatí používat golden datasety — předpřipravené sady testovacích případů s referenčními odpověďmi. Tyto datasety uložte jako JSON soubory ve vašem repozitáři a v testech je jednoduše načtěte:

from deepeval.dataset import EvaluationDataset

# Načtení golden datasetu ze souboru
dataset = EvaluationDataset()
dataset.add_test_cases_from_json_file(
    file_path="datasets/golden_dataset.json",
    input_key_name="otazka",
    actual_output_key_name="odpoved",
    expected_output_key_name="ocekavana_odpoved",
    retrieval_context_key_name="kontext"
)

Pokročilé techniky

Syntetické datasety pro škálování testů

Ruční vytváření testovacích případů je časově náročné — to ví každý, kdo se o to někdy pokoušel. DeepEval tohle řeší třídou Synthesizer, která dokáže automaticky generovat syntetická testovací data z vašich zdrojových dokumentů. Pro rychlé škálování testovacích sad je to opravdu neocenitelné.

from deepeval.synthesizer import Synthesizer

# Vytvoření syntetizéru
syntetizer = Synthesizer()

# Generování syntetických testovacích případů z dokumentů
testovaci_pripady = syntetizer.generate_goldens_from_docs(
    document_paths=["docs/produktova_dokumentace.pdf"],
    max_goldens_per_context=3
)

DeepEval 3.x navíc přidává podporu generování vícekolových syntetických dat, což oceníte při testování konverzačních systémů. Syntetizér dokáže vytvořit realistické konverzační scénáře včetně navazujících otázek a kontextuálních odkazů — tedy přesně to, co byste jinak museli ručně vymýšlet.

Red teaming a bezpečnostní skenování

Bezpečnost LLM aplikací prostě nejde podceňovat. DeepEval nabízí funkce pro automatické bezpečnostní skenování, které testuje váš systém proti více než 40 typům zranitelností — od prompt injection přes jailbreaking až po únik citlivých dat.

K dispozici jsou i specializované metriky jako Bias (detekce předpojatosti) a Toxicity (detekce toxického obsahu). Tyhle metriky by měly být součástí každého produkčního evaluačního pipeline, obzvlášť pokud vaši aplikaci používají koncoví zákazníci.

from deepeval.metrics import BiasMetric, ToxicityMetric
from deepeval.test_case import LLMTestCase
from deepeval import assert_test

def test_bezpecnost_odpovedi():
    predpojatost = BiasMetric(threshold=0.5)
    toxicita = ToxicityMetric(threshold=0.5)

    testovaci_pripad = LLMTestCase(
        input="Porovnejte kandidáty na pozici programátora.",
        actual_output="""Při hodnocení kandidátů se zaměřujeme na
        technické dovednosti, zkušenosti s relevantními technologiemi,
        schopnost řešit problémy a komunikační dovednosti.
        Věk, pohlaví ani národnost nejsou relevantními kritérii."""
    )

    assert_test(testovaci_pripad, [predpojatost, toxicita])

Asynchronní evaluace

Při větším počtu testovacích případů se evaluace může pořádně protáhnout — každá metrika totiž vyžaduje volání LLM. DeepEval naštěstí podporuje asynchronní evaluaci, která celý proces výrazně zrychlí díky paralelnímu zpracování:

from deepeval import evaluate
from deepeval.test_case import LLMTestCase
from deepeval.metrics import AnswerRelevancyMetric, FaithfulnessMetric

# Příprava testovacích případů (zjednodušeno)
testovaci_pripady = [
    LLMTestCase(
        input=f"Otázka {i}",
        actual_output=f"Odpověď {i}",
        retrieval_context=[f"Kontext {i}"]
    )
    for i in range(50)  # 50 testovacích případů
]

metriky = [
    AnswerRelevancyMetric(threshold=0.7),
    FaithfulnessMetric(threshold=0.8)
]

# Asynchronní evaluace — výrazně rychlejší pro velké sady
vysledky = evaluate(
    test_cases=testovaci_pripady,
    metrics=metriky,
    async_mode=True  # Paralelní zpracování
)

Při zapnutí async_mode=True DeepEval automaticky distribuuje evaluační volání do paralelních vláken. U sad s desítkami až stovkami testovacích případů můžete pozorovat několikanásobné zrychlení oproti sekvenčnímu zpracování. U rozsáhlejších testovacích sad (řekněme nad 100 případů) je ten rozdíl opravdu znatelný.

Nejčastější dotazy (FAQ)