Testovanie a evaluácia LLM aplikácií: Praktický sprievodca s DeepEval a RAGAS

Úvod: Prečo stavať AI systémy bez evaluácie je ako šoférovať so zaviazanými očami

Ak ste čítali naše predchádzajúce články o Agentic RAG pipeline, multi-agentných systémoch či context engineeringu, viete, ako tieto komplexné AI systémy vybudovať. Ale ruku na srdce — ako naozaj viete, že fungujú tak, ako majú? Podľa LangChain State of AI Agents reportu z roku 2026 má 57 % organizácií agentov v produkcii a kvalita výstupov je prekážkou číslo 1 pre ďalšie nasadenie. Bez systematického testovania sa o problémoch dozviete až od nahnevaných používateľov. A to naozaj nechcete.

LLM aplikácie sú nedeterministické — rovnaký vstup môže produkovať rôzne výstupy. Tradičné unit testy tu jednoducho nestačia. Potrebujete evals — špecializované evaluačné testy, ktoré merajú kvalitu AI výstupov pomocou metrík, LLM sudcov a automatizovaných kontrol. V tomto článku vám ukážem, ako ich nastaviť od nuly pomocou frameworkov DeepEval a RAGAS, vrátane fungujúcich príkladov kódu, ktoré si môžete hneď vyskúšať.

Čo sú evals a prečo sú dôležité

Evaluácia (eval) je v podstate test pre AI systém: dáte AI vstupy, aplikujete hodnotiace kritériá na jeho výstupy a meriate úspešnosť. Na rozdiel od klasických testov, kde porovnávate presný výstup, LLM evals hodnotia kvalitatívne vlastnosti — relevantnosť, faktuálnu presnosť, koherenciu a bezpečnosť.

Tri piliere evaluácie LLM

• Automatizované evals — kódom riadené kontroly, ktoré automaticky bodujú výstupy. Sú rýchle, škálovateľné a konzistentné. Ideálne na zachytenie zjavných zlyhaní.
• LLM-as-a-Judge — hybridný prístup, kde jazykový model hodnotí výstupy iného modelu podľa definovaných kritérií. Rýchlejší ako ľudia a zachytáva nuansy lepšie ako čisto automatizované metriky.
• Ľudské hodnotenie (HITL) — zlatý štandard pre subjektívnu kvalitu. Ľudskí hodnotitelia podľa štruktúrovaného rubríka posudzujú tón, koherenciu a vernosť kontextu. Je to samozrejme najpomalší prístup, ale nič ho zatiaľ plne nenahradí.

Kľúčové metriky pre testovanie LLM aplikácií

Výber správnych metrík závisí od typu vašej aplikácie. Poďme sa pozrieť na najdôležitejšie kategórie.

Metriky pre RAG systémy

• Faithfulness (vernosť) — meria, či výstup obsahuje len informácie z poskytnutého kontextu, bez halucinácie
• Answer Relevancy (relevantnosť odpovede) — hodnotí, či odpoveď adresuje pôvodnú otázku informatívne a stručne
• Contextual Precision (kontextová presnosť) — overuje, či retriever zaraďuje relevantné výsledky na vyššie pozície
• Contextual Recall (kontextový recall) — meria, či embedding model zachytáva všetky relevantné informácie

Metriky pre AI agentov

• Tool Correctness (správnosť nástrojov) — overuje, či agent volí správne nástroje pre danú úlohu
• Task Completion (dokončenie úlohy) — meria, či agent úspešne dosiahol cieľ
• Trajectory Quality (kvalita trajektórie) — hodnotí celú cestu rozhodovaní, nie len konečný výstup (čo je podľa mňa jedna z najdôležitejších metrík, pretože agent môže trafiť správny výsledok úplne náhodou)
• Reasoning Coherence (koherencia uvažovania) — kontroluje logickú konzistentnosť naprieč krokmi

Univerzálne metriky

• Hallucination Score — percentuálna miera vymyslených informácií vo výstupe
• Toxicity — detekcia škodlivého alebo urážlivého obsahu
• Bias — identifikácia zaujatosti vo výstupoch
• G-Eval — univerzálna metrika založená na výskume, ktorá používa LLM na hodnotenie ľubovoľných vlastných kritérií (veľmi užitočné, keď žiadna z predefinovaných metrík nepokrýva to, čo potrebujete)

DeepEval: Unit testy pre LLM aplikácie

DeepEval je open-source evaluačný framework pre Python, ktorý funguje podobne ako Pytest, ale je špecializovaný na testovanie LLM výstupov. Obsahuje viac ako 30 predefinovaných metrík a integruje sa priamo do CI/CD pipeline. Osobne ho považujem za najlepší štartovací bod, ak s LLM evaluáciami začínate.

Inštalácia a nastavenie

pip install deepeval

# Nastavenie OpenAI API kľúča (predvolený LLM sudca)
export OPENAI_API_KEY="váš-api-kľúč"

# Alebo použitie iného providera
deepeval set-azure-openai --api-key="kľúč" --endpoint="url" --model-name="gpt-4.1"

DeepEval štandardne používa GPT-4.1 ako LLM sudcu. Podporuje aj Anthropic Claude, Google Gemini, Ollama (lokálne modely) a ľubovoľný OpenAI-kompatibilný endpoint. Takže nemusíte byť naviazaní na OpenAI, ak to nie je váš preferovaný provider.

Prvý test: detekcia halucinácie

Poďme na to. Vytvorte súbor test_hallucination.py:

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

def test_no_hallucination():
    """Test overuje, že chatbot nehallucinuje mimo poskytnutý kontext."""
    
    input_text = "Aká je vaša politika vrátenia tovaru?"
    
    # Kontext z knowledge base / RAG retrievera
    context = [
        "Zákazníci majú nárok na plnú náhradu do 30 dní od nákupu.",
        "Vrátenie je bezplatné pre všetky produkty okrem elektroniky."
    ]
    
    # Simulovaný výstup chatbota
    actual_output = (
        "Ponúkame 30-dňovú plnú náhradu bez ďalších nákladov. "
        "Vrátenie je bezplatné pre všetky produkty okrem elektroniky."
    )
    
    hallucination_metric = HallucinationMetric(threshold=0.7)
    
    test_case = LLMTestCase(
        input=input_text,
        actual_output=actual_output,
        context=context
    )
    
    assert_test(test_case, [hallucination_metric])

Test spustíte jednoducho:

deepeval test run test_hallucination.py

Ak všetko prejde, uvidíte zelené výstupy ako pri bežnom pytest. Ak nie — DeepEval vám ukáže detailné vysvetlenie, prečo metrika zlyhala.

Testovanie AI agenta s nástrojmi

Pre agentov, ktorí volajú nástroje (funkcie, API), DeepEval ponúka metriku ToolCorrectnessMetric. Tu je príklad, ako to vyzerá v praxi:

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

def test_agent_tool_selection():
    """Test overuje, že agent vyberá správne nástroje."""
    
    test_case = LLMTestCase(
        input="Aké je počasie v Bratislave?",
        actual_output="V Bratislave je 22°C a slnečno.",
        tools_called=["get_weather"],
        expected_tools=["get_weather"]
    )
    
    metric = ToolCorrectnessMetric(threshold=0.8)
    assert_test(test_case, [metric])


def test_agent_uses_correct_sequence():
    """Test overuje správnu sekvenciu nástrojov pre zložitú úlohu."""
    
    test_case = LLMTestCase(
        input="Nájdi najlacnejší let do Paríža na budúci víkend a zarezervuj ho.",
        actual_output="Zarezervoval som let s Ryanair za 49€ na sobotu 8:30.",
        tools_called=["search_flights", "compare_prices", "book_flight"],
        expected_tools=["search_flights", "compare_prices", "book_flight"]
    )
    
    metric = ToolCorrectnessMetric(threshold=0.8)
    assert_test(test_case, [metric])

Všimnite si, že v druhom teste kontrolujeme aj poradie volaných nástrojov. Agent, ktorý by sa pokúsil rezervovať let pred vyhľadaním, by tento test neprešiel.

Viacero metrík naraz s @observe dekorátorom

Pre komplexnejšie evaluácie môžete použiť dekorátor @observe, ktorý trasuje komponenty vašej aplikácie a aplikuje metriky na úrovni jednotlivých krokov. Toto je veľmi užitočné, keď chcete vidieť, kde presne v pipeline niečo zlyháva:

from deepeval.tracing import observe, update_current_span
from deepeval.test_case import LLMTestCase
from deepeval.dataset import EvaluationDataset, Golden
from deepeval.metrics import (
    AnswerRelevancyMetric,
    FaithfulnessMetric,
    HallucinationMetric
)

@observe()
def my_rag_app(query: str):
    """Hlavná RAG aplikácia s trasovaním."""
    
    # Retrieval krok
    @observe(metrics=[FaithfulnessMetric()])
    def retrieve_and_generate(q: str):
        # Váš skutočný retrieval a generovanie
        context = retriever.search(q)
        response = llm.generate(q, context)
        
        update_current_span(
            test_case=LLMTestCase(
                input=q,
                actual_output=response,
                retrieval_context=[doc.text for doc in context]
            )
        )
        return response
    
    return retrieve_and_generate(query)

# Evaluácia na datasete
dataset = EvaluationDataset(
    goldens=[
        Golden(input="Čo je RAG?"),
        Golden(input="Ako funguje vektorová databáza?"),
        Golden(input="Vysvetli fine-tuning vs RAG.")
    ]
)

for golden in dataset.evals_iterator():
    my_rag_app(golden.input)

RAGAS: Špecializovaná evaluácia RAG pipeline

RAGAS (Retrieval Augmented Generation Assessment) je framework navrhnutý špeciálne pre hodnotenie RAG systémov. Kým DeepEval je univerzálny a pokrýva všetko od agentov po bezpečnosť, RAGAS sa zameriava čisto na meranie kvality retrievalu a generovania v kontexte RAG. A v tom je naozaj dobrý.

Inštalácia a základné použitie

pip install ragas

# Základná evaluácia RAG pipeline
from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_precision,
    context_recall
)
from datasets import Dataset

# Príprava evaluačného datasetu
eval_data = {
    "question": [
        "Čo je vektorová databáza?",
        "Ako funguje embedding?"
    ],
    "answer": [
        "Vektorová databáza ukladá dáta ako numerické vektory pre efektívne vyhľadávanie podobnosti.",
        "Embedding transformuje text na hustý numerický vektor, ktorý zachytáva sémantický význam."
    ],
    "contexts": [
        ["Vektorové databázy sú optimalizované na ukladanie a vyhľadávanie vysokodimenzionálnych vektorov."],
        ["Embeddingy sú numerické reprezentácie textu vytvorené neurónovými sieťami."]
    ],
    "ground_truth": [
        "Vektorová databáza je databáza optimalizovaná na ukladanie a vyhľadávanie vektorových embeddingov.",
        "Embedding je proces prevodu textu na numerický vektor pomocou neurónových sietí."
    ]
}

dataset = Dataset.from_dict(eval_data)

# Spustenie evaluácie
results = evaluate(
    dataset,
    metrics=[
        faithfulness,
        answer_relevancy,
        context_precision,
        context_recall
    ]
)

print(results)
# Výstup: {'faithfulness': 0.92, 'answer_relevancy': 0.88, ...}

Známy problém: NaN skóre

Toto vás možno prekvapí, ale pri používaní RAGAS sa pomerne bežne stretnete s problémom NaN skóre. Stáva sa to, keď LLM sudca vráti neplatný JSON. Neexistuje žiadny elegantný fallback — jedna zlá API odpoveď dokáže znehodnotiť celý evaluačný beh. Preto odporúčam obaľovať evaluácie do try/except, najmä v CI prostredí:

# Obalenie evaluácie try/except pre CI stabilitu
import logging

try:
    results = evaluate(dataset, metrics=[faithfulness, answer_relevancy])
    
    # Kontrola NaN hodnôt
    for metric_name, score in results.items():
        if score != score:  # NaN check
            logging.warning(f"Metrika {metric_name} vrátila NaN - preskakujem")
            continue
        
        if score < 0.7:
            logging.error(f"Metrika {metric_name} pod prahom: {score:.2f}")
            
except Exception as e:
    logging.error(f"Evaluácia zlyhala: {e}")
    # V CI - retry alebo fail gracefully

LLM-as-a-Judge: Výhody a úskalia

Väčšina moderných evaluačných metrík používa LLM ako sudcu — jeden jazykový model hodnotí výstupy iného. Je to elegantný prístup, ale má dôležité obmedzenia, o ktorých by ste mali vedieť.

Známe biasy LLM sudcov

Výskum odhalil chybovosť presahujúcu 50 % pri LLM evaluátoroch. Áno, čítate správne — nad 50 %. Spôsobujú to predovšetkým:

• Pozičný bias — uprednostňovanie odpovedí prezentovaných na prvom mieste
• Bias dĺžky — preferovanie dlhších výstupov bez ohľadu na kvalitu (LLM jednoducho milujú dlhé odpovede)
• Bias súhlasu — nadmerné akceptovanie výstupov bez dostatočnej kritickej evaluácie

Ako minimalizovať biasy

# Ensemble prístup - viacero LLM sudcov s náhodným poradím
from deepeval.metrics import GEval
from deepeval.test_case import LLMTestCaseParams

# Vytvorenie vlastnej metriky s G-Eval
custom_metric = GEval(
    name="Kvalita odpovede",
    criteria=(
        "Odpoveď musí byť faktuálne presná, relevantná k otázke "
        "a dostatočne podrobná bez zbytočného opakovania."
    ),
    evaluation_params=[
        LLMTestCaseParams.INPUT,
        LLMTestCaseParams.ACTUAL_OUTPUT
    ],
    threshold=0.7
)

# Pre produkčné použitie cieľte na 0.80+ Spearman koreláciu
# s ľudskými hodnotiteľmi

Pre produkčné nasadenie odporúčam kalibrovať vášho LLM sudcu: nechajte ľudských hodnotiteľov obodovať sadu odpovedí, potom porovnajte ich hodnotenie s LLM sudcom. Ak sa zhodujú na 85–90 %+, váš LLM sudca je pripravený na automatizované použitie. Ak nie, skúste zmeniť prompt pre sudcu alebo prejsť na iný model.

Integrácia evaluácií do CI/CD pipeline

Evaluácie majú najväčšiu hodnotu vtedy, keď bežia automaticky pri každej zmene kódu alebo promptu. Spúšťať ich ručne raz za čas nestačí. DeepEval sa natívne integruje s pytest, takže napojenie na CI/CD je prekvapivo priamočiare.

GitHub Actions workflow

# .github/workflows/llm-evals.yml
name: LLM Evaluations

on:
  pull_request:
    paths:
      - 'prompts/**'
      - 'src/agents/**'
      - 'src/rag/**'

jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      
      - name: Install dependencies
        run: |
          pip install deepeval ragas
          pip install -r requirements.txt
      
      - name: Run LLM evals
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          deepeval test run tests/evals/ --verbose
      
      - name: Check thresholds
        run: |
          python scripts/check_eval_thresholds.py

Všimnite si, že workflow sa spúšťa len pri zmenách v priečinkoch s promptami a agentmi. Nemá zmysel spúšťať evaluácie pri každej kozmetickej zmene v README.

Štruktúra evaluačných testov v projekte

project/
├── src/
│   ├── agents/
│   └── rag/
├── tests/
│   ├── evals/
│   │   ├── test_rag_faithfulness.py
│   │   ├── test_rag_relevancy.py
│   │   ├── test_agent_tools.py
│   │   └── test_agent_completion.py
│   └── golden_datasets/
│       ├── rag_questions.json
│       └── agent_scenarios.json
├── prompts/
└── scripts/
    └── check_eval_thresholds.py

Začnite s 10–20 testovacími prípadmi na jednu funkciu — to stačí na odhalenie regresií a potvrdenie vylepšení v raných fázach vývoja. Nemusíte hneď budovať obrovský benchmark. Dataset postupne rozširujte o reálne zlyhania, ktoré nájdete počas vývoja alebo v produkcii.

Monitoring v produkcii: Evaluácia sa nekončí nasadením

LLM sú nedeterministické — kvalita sa môže ticho degradovať pri aktualizáciách modelov, zmenách promptov alebo posune v správaní používateľov. Bez monitoringu sa o problémoch dozviete len cez sťažnosti. A v tom momente už môže byť neskoro.

Vrstvený evaluačný prístup

Vrstva	Nástroj	Frekvencia	Účel
Unit testing	DeepEval	Každý commit / CI	Zachytenie regresií
Batch evaluácia	RAGAS / vlastné skripty	Týždenne / pred releasom	Holistický výkon
Produkčný monitoring	Langfuse / LangSmith	Real-time	Drift, spokojnosť používateľov

Náklady na evaluáciu

S GPT-4o-mini ako sudcom počítajte s približne $0,001–$0,003 na testovací prípad s piatimi metrikami. Dataset 200 otázok vás teda vyjde pod $1 na evaluačný beh. To je úprimne zanedbateľná suma za istotu, že váš systém funguje správne.

Lokálne evaluácie bez OpenAI

Pre tímy s požiadavkami na dátovú rezidenciu mám dobrú správu: DeepEval aj RAGAS podporujú ľubovoľný OpenAI-kompatibilný endpoint. Môžete ich napojiť na lokálny model cez Ollama alebo vLLM a evaluácie bežia kompletne na vašej infraštruktúre, bez toho aby akékoľvek dáta opustili vašu sieť:

# Použitie lokálneho modelu cez Ollama
deepeval set-local-model \
  --model-name="llama3.1:70b" \
  --base-url="http://localhost:11434/v1"

DeepEval vs RAGAS: Ktorý framework kedy použiť

Kritérium	DeepEval	RAGAS
Zameranie	Univerzálne LLM testovanie	Špecificky RAG systémy
Integrácia	Natívne pytest, CI/CD	Standalone skripty
Metriky	30+ (RAG, agenti, bezpečnosť)	~10 (RAG-orientované)
Debugging	Detailné vysvetlenia skóre	Základné skóre
Syntetické dáta	Áno	Áno (silný generátor)
Produkčný monitoring	Cez Confident AI cloud	Vyžaduje externú integráciu

Praktické odporúčanie: Začnite s RAGAS na rýchlu exploráciu a generovanie golden datasetu — na to je fakt skvelý. Potom presúňte evaluácie do DeepEval pre systematické testovanie a CI/CD integráciu. Oba frameworky sa dopĺňajú a nie je medzi nimi žiadny konflikt — RAGAS metriky môžete dokonca spustiť priamo v DeepEval cez RagasMetric.

Často kladené otázky (FAQ)

Koľko testovacích prípadov potrebujem na začiatok?

Na zmysluplné evaluácie stačí 10–20 prípadov na funkciu. Nemusíte vytvárať obrovský benchmark — aj malý, dobre pripravený dataset odhalí regresie a potvrdí vylepšenia. Postupne ho rozširujte o reálne zlyhania z vývoja a produkcie.

Aký je rozdiel medzi evaluáciou RAG systému a AI agenta?

RAG evaluácia sa zameriava na kvalitu retrievalu a generovania — meria vernosť kontextu, relevantnosť a presnosť. Evaluácia agenta je výrazne komplexnejšia: hodnotí správnosť výberu nástrojov, kvalitu plánovania, koherenciu uvažovania a dokončenie úlohy naprieč viacerými krokmi. Zjednodušene povedané, agent vyžaduje trajektóriové metriky, nie len hodnotenie konečného výstupu.

Dá sa evaluácia bežať bez OpenAI API kľúča?

Áno, bez problémov. DeepEval aj RAGAS podporujú ľubovoľný OpenAI-kompatibilný endpoint. Môžete použiť lokálny model cez Ollama (napr. Llama 3.1) alebo self-hosted inference server. Pre tímy s prísnymi požiadavkami na dátovú bezpečnosť je to úplne štandardný prístup.

Ako často by som mal spúšťať evaluácie v produkcii?

Odporúčam trojvrstvový prístup: unit testy pri každom commite v CI, batch evaluácie týždenne alebo pred každým releasom, a real-time monitoring v produkcii cez nástroje ako Langfuse alebo LangSmith. Trendy metrík v čase odhalia postupné zmeny kvality, ktoré jednorazové hodnotenie jednoducho nezachytí.

Je LLM-as-a-Judge spoľahlivý? Nemôže byť zaujatý?

Uprimne — LLM sudcovia majú dokumentované biasy a výskum ukazuje chybovosť až nad 50 % v niektorých scenároch. To znie desivo, ale riešenie existuje. Pomáha ensemble prístup (viacero sudcov s náhodným poradím), kalibrácia oproti ľudským hodnotiteľom (cieľte na 85 %+ zhodu) a kombinácia automatizovaných metrík s občasným ľudským review. Žiadna metóda nie je dokonalá, ale kombinácia viacerých prístupov funguje prekvapivo dobre.