Jak hodnotit AI agenty v produkci: 3vrstvý systém, který používáme na živých trasách

Jak hodnotit AI agenty v produkci: 3vrstvý systém, který používáme na živých trasách

Hodnocení AI agentů v produkci znamená bodování celé víceúrovňové trajektorie agenta, nejen jeho finální odpovědi, na živém provozu: kontrola každého kroku uvažování, ověření, že zavolal správné nástroje se správnými argumenty, a nepřetržité monitorování úspěšnosti úkolů, nákladů a bezpečnosti po spuštění, protože agenti selhávají tiše a nedeterministicky.

Během jednoho běhu našeho vlastního obsahu Techsy v červnu 2026 agent dodal blogový příspěvek, který vypadal perfektně, a skóre finálního výstupu ho propustilo. Čisté. Až na to, že o tři kroky zpět tvůrce briefu zavolal špatný nástroj pro vyhledávání interních odkazů, takže polovina odkazů v clusteru nikam nevedla. Vědět, jak hodnotit AI agenty v produkci, znamená bodovat celou cestu, kterou agent urazil, nejen odpověď, na kterou náhodou narazil.

Klíčová zjištění:

• Bodujte celou trajektorii, nejen finální odpověď: správná odpověď získaná špatnou cestou stále znamená selhání.
• Validujte volání nástrojů ve třech osách: správný nástroj, správné argumenty, správný krok.
• Spouštějte stejné metriky offline i online, na živých produkčních trasách, v nepřetržité smyčce.
• Nasazování podmíňte bezpečnostními zranitelnostmi (jailbreak, PII, zneužití nástrojů), nejen nízkým skóre přesnosti.

Proč je hodnocení AI agentů v produkci jiné než hodnocení LLM?

Hodnocení AI agentů v produkci je obtížnější než hodnocení modelu, protože agent podniká více kroků, volá externí nástroje a mění reálný stav, a to vše dělá nedeterministicky. Stejný vstup může při každém běhu vyprodukovat jinou sekvenci volání nástrojů, takže jeden chybný krok na začátku může zkazit každý následující krok.

Tento průvodce předpokládá, že již znáte obecné hodnocení LLM. Pokud ne, začněte naším kompletním průvodcem hodnocením LLM a poté se vraťte k tomu, co se změní, když se model stane agentem. (Stále budujete agenty, které budete hodnotit? Naše shrnutí nejlepších frameworků pro AI agenty pokrývá vrstvu pod tím.)

Čtyři věci se rozbijí ve chvíli, kdy vaše LLM začne jednat samostatně:

• Více kroků. Podpůrný agent může prohledat znalostní bázi, zavolat API objednávek a poté navrhnout odpověď. Pokud bodujete pouze odpověď, jste slepí ke dvěma krokům, které ji určily.
• Nedeterminismus. Teplota, aktualizace vah modelu a latence nástrojů znamenají, že stejný požadavek proběhne při každém spuštění jinou cestou. Vaše evaluace musí přežít pohybující se cíl.
• Stavovost. Agenti zapisují do databází, posílají e-maily, vrací peníze za objednávky. Špatná akce není špatná věta, je to vedlejší efekt, který nelze vzít zpět.
• Kumulace. Mírně chybný krok 2 ve 12krokovém běhu otráví vše následující a finální odpověď může stále vypadat v pořádku.

Zpráva Galileo „State of Eval Engineering“ z února 2026, která surveyovala více než 500 praktiků, zjistila, že 84,9 % týmů narazilo na AI incident během šesti měsíců od nasazení. Inženýrský tým Anthropic to říká jasně ve svém eseji o evaluaci agentů: agenti selhávají napříč kroky, nástroji a záměry, nejen ve finálním výstupu.

Agent, který vrátí správnou odpověď prostřednictvím špatné trajektorie, neprošel. Selhal tiše a příště selže hlasitě, až se šťastná záchrana nestane.

Které metriky jsou pro AI agenty v produkci skutečně důležité?

Metriky, které jsou pro agenty v produkci nejdůležitější, jdou nad rámec přesnosti: míra úspěšnosti úkolů, náklady na úspěšný úkol, percentily latence, přesnost volání nástrojů, věrnost, míra lidského zásahu, drift a míra průchodu bezpečnostní bránou. Tyto metriky hodnocení AI agentů společně zachycují tichá, nedeterministická selhání, která uniknou jedinému skóre výstupu.

Tohle je osm metrik, které skutečně sledujeme při našich vlastních bězích. Všimněte si, jak málo z nich záleží na tom, zda finální odpověď dobře zní:

Většina z těchto metrik se opírá o LLM jako rozhodčího (jeden model hodnotí výstup jiného). Je to standardní trik a škáluje se, ale je hlučný: rozhodčí často sdílí slepá místa agenta, takže berte jeho skóre jako signál, ne jako evangelium. Ke kalibraci rozhodčího se vrátíme v sedmé sekci.

Jedna metrika si zaslouží zvláštní pozornost. Náklady na úspěšný úkol je číslo, které přežije revizi rozpočtu. Běžné náklady na úkol odměňují levná selhání, protože agent, který rychle a špatně vzdá, vypadá v tabulce efektivně.

Jak bodovat trajektorii agenta místo jeho finální odpovědi?

Pro bodování trajektorie agenta hodnotíte trasu: uspořádaný záznam každého kroku uvažování, volání nástroje a mezivýstupu, který agent vytvořil. Hodnocení na úrovni spanů boduje každý jednotlivý krok (span), takže můžete přesně určit ten, který selhal, místo abyste se dozvěděli pouze to, že celý běh dopadl špatně.

Představte si trasu jako stack trace pro uvažování. Každý span je jeden krok: načtení, volání nástroje, předání sub-agentovi. Observabilita zachycuje tyto spány; evaluace je boduje. (Ještě nemáte tracing? Naše průvodce AI observabilitou pokrývá vrstvu sledování, na které bodování stojí, a naše srovnání LangGraph, CrewAI a OpenAI Agents SDK ukazuje, jak vypadá trasa v každém z nich.)

Proč bodovat každý span místo koncového bodu? Kumulativní chyby. Pokud krok 2 načte špatný dokument, kroky 3 až 12 staví na odpadu a šťastná finální formulace může stále proklouznout kontrolou pouze výstupu. Bodování na úrovni spanů vám řekne, že běh selhal ve kroku 2, nejen že někde selhal.

Zde je verze nezávislá na frameworku (prostá aserce nad objektem trasy), následovaná zkratkou DeepEval využívající jeho metriku dokončení úkolu založenou na trasách:

# Framework-agnostic: did the trajectory reach the goal via valid steps?
def score_trace(trace):
    assert trace.steps[-1].status == "success", "final step failed"
    assert all(s.error is None for s in trace.steps), "a mid-run step errored"
    assert "internal_link_lookup" in [s.tool for s in trace.steps], "skipped a required step"

# DeepEval: score the whole multi-step trace for task completion
from deepeval.tracing import observe
from deepeval.metrics import TaskCompletionMetric

@observe(metrics=[TaskCompletionMetric(threshold=0.7, model="gpt-4o")])
def content_pipeline(topic):
    ...  # your researcher -> brief -> writer -> validator run
    return final_post

Aserce nezávislá na frameworku je v pořádku pro tvrdé, deterministické kontroly. Dokončení úkolu je to, po čem sáhnete, když je úspěch nejasnější než kontrola rovnosti: extrahuje zamýšlený úkol a dosažený výsledek z trasy a boduje, jak dobře spolu ladí.

Jak ověřit, že agent zavolal správný nástroj?

Pro validaci volání nástrojů agentem zkontrolujte tři věci odděleně: výběr nástroje (vybral správný nástroj), správnost argumentů (předal správné parametry a hodnoty) a platnost exekuční cesty (zavolal tento nástroj ve správném kroku, ve správném pořadí). Správná finální odpověď se špatným voláním nástroje je bug, který se ještě neprojevil.

Toto je jediná evaluace specifická pro agenty a je to ta, kterou téměř nikdo nepokrývá do hloubky. Hodnocení využití nástrojů multi-agentem se rozkládá na tři otázky:

1. Výběr. Ze všech dostupných nástrojů vybral agent ten správný? Zavolání jakéhokoli nástroje není totéž jako zavolání správného.
2. Argumenty. Předal správné parametry? Správný nástroj se špatným slug nebo malformed datem je stále selhání.
3. Exekuční cesta. Zavolal tento nástroj ve správném kroku, ve správném pořadí? Vrácení peněz před ověřením objednávky jsou správné nástroje ve špatném pořadí.

Metrika správnosti nástroje od DeepEval řeší všechny tři: porovnává tools_called s expected_tools, může párovat podle vstupních parametrů a s should_consider_ordering=True hodnotí i sekvenci.

# Framework-agnostic: right tool, right args, right step
call = trace.steps[2].tool_call
assert call.name == "internal_link_lookup", f"wrong tool: {call.name}"
assert call.args == {"slug": "llm-evals-guide"}, f"wrong args: {call.args}"

# DeepEval: score tool selection + arguments, order-aware
from deepeval.test_case import LLMTestCase, ToolCall, ToolCallParams
from deepeval.metrics import ToolCorrectnessMetric

test_case = LLMTestCase(
    input="Add an internal link to the LLM evals guide",
    actual_output="...",
    tools_called=[ToolCall(name="sitemap_search")],
    expected_tools=[ToolCall(name="internal_link_lookup")],
)
metric = ToolCorrectnessMetric(
    evaluation_params=[ToolCallParams.INPUT_PARAMETERS],
    should_consider_ordering=True,
)
metric.measure(test_case)
print(metric.score, metric.reason)  # 0.0  "expected tool not called"

To 0.0 je přesné selhání, které jsme zachytili v naší vlastní pipeline: agent sáhl po sitemap_search, když očekávaným nástrojem bylo internal_link_lookup. Dokončený příspěvek stále prošel skóre výstupu. Metrika volání nástrojů byla jediná věc, která označila chybnou cestu.

Jak spouštět evaluace online, na živých produkčních trasách?

Online evaluace spouští vaše metriky proti živým produkčním trasám v reálném čase, nejen proti testovací sadě před nasazením. Je to třetí vrstva třívrstvého systému: offline testy na zlaté sadě, brána QA před nasazením a poté online evaluace na živém provozu, přičemž produkční trasy jsou kurátorsky vraceny do datasetů, aby se smyčka neustále zlepšovala.

Offline testy zachytí regresie před jejich nasazením. Ale agenti se v produkci setkávají se vstupy, které žádná zlatá sada neočekávala, takže stejné metriky musí běžet i po spuštění. Zde je celá smyčka, kterou mapuje diagram nahoře:

1. Offline. Spusťte své metriky na zlatém datasetu v CI. Při regresi zastavte build.
2. Brána QA před nasazením. Kontrolní bod vlastněný člověkem: splňuje toto laťku přesnosti a laťku bezpečnosti (sekce šest)?
3. Online. Bodujte živé produkční trasy v reálném čase pomocí stejných metrik.
4. Kurátorství. Automaticky sbírejte skutečné trasy (zejména selhání) zpět do vašich evaluačních datasetů.
5. Opakování. Vaše zlatá sada roste z reality, ne z 20 příkladů, které jste ručně napsali první den.

Zapojení online evaluace je stejná instrumentace jako tracing, plus sběr metrik. Confident AI spouští 50+ scorerů z DeepEval proti živým trasám a je kompatibilní s OpenTelemetry, takže LangGraph, CrewAI, OpenAI a Vercel AI SDK exportují bez vlastních adaptérů:

# Same metrics you ran in dev, now scoring live production traffic
from deepeval.tracing import observe, update_current_span
from deepeval.test_case import LLMTestCase

@observe(metric_collection="Production Agent Quality")
def support_agent(query: str) -> str:
    answer = run_agent(query)  # your live agent
    update_current_span(
        test_case=LLMTestCase(input=query, actual_output=answer)
    )
    return answer
# The collection's metrics now run on every trace, in real time.

Odměnou je krok kurátorství. Každé skutečné produkční selhání se stává trvalým regresním testem, takže vaše sada přestane být statickým snímkem a začne sledovat to, čemu váš agent skutečně čelí v divočině.

Podmiňte nasazení bezpečností, nejen přesností

Bezpečnostní brána blokuje nasazení kvůli zranitelnosti, nejen kvůli nízkému skóre přesnosti. Pro agenty to znamená adverzální a red-team evaluace zkoumající jailbreaky, zneužití nástrojů a únik PII, prováděné jak před nasazením, tak online. Jailbreak není nízké skóre, které průměrem vymažete. Je to blokér vydání.

Každý konkurent považuje bezpečnost za jednu z mnoha metrik. To je u agentů obráceně, kteří mohou být přemluveni k zavolání skutečného nástroje proti skutečnému systému. Oddělte tedy brány: brána přesnosti průměruje skóre; bezpečnostní brána je pass/fail na tom, zda nějaký adverzální průsond prošel. Začněte mapováním režimů selhání vašeho agenta na frameworky, které auditoři již uznávají:

Poté spusťte adverzální evaluace proti těmto kategoriím. OWASP Top 10 pro LLM aplikace, NIST AI Risk Management Framework a MITRE ATLAS vám dávají sdílenou slovní zásobu; red-teaming vám dává test. DeepTeam, open-source red-teaming framework od stejného týmu za DeepEval, dodává 120+ zranitelností napříč 8 kategoriemi a 20+ útočnými vektory, každý mapovaný na OWASP, NIST AI RMF a MITRE ATLAS.

Jedna upřímná nuance k nástrojům: DeepTeam OSS je zdarma a pokrývá sadu zranitelností; spravovaný modul red-teamingu v platformě Confident AI je funkcí Enterprise tieru, ne něčím, co balíček Starter za 9,99 $ obsahuje. Tak či onak, zapojte red-teaming jako prvotřídní bránu, ne jako dodatek, který spustíte jednou před spuštěním.

Co jsme zachytili při běhu tohoto systému na naší vlastní pipeline

Tento třívrstvý systém provozujeme na naší vlastní multi-agentní content pipeline: čtyři agenti (výzkumník, tvůrce briefu, spisovatel obsahu, validátor) předávají práci v řetězci. Zapojení DeepEval v4.0.5 do této pipeline během června a července 2026 proti našemu workspace Confident AI je způsob, jakým jsme zachytili selhání z úvodu. Výstup scoreru vypadal takto:

ToolCorrectnessMetric  score=0.00  threshold=0.50  FAILED
Reason: expected tool 'internal_link_lookup' was not called;
        'sitemap_search' was called on step 2 instead.

Příspěvek již prošel skóre kvality výstupu. Na dokončeném článku nic nevypadalo špatně. Pouze evaluace trajektorie viděla chybný krok, přesně ten typ bugu, který kontrola pouze výstupu propustí.

Pokud sledujete praktiky na r/LLMDevs, r/MachineLearning nebo r/LocalLLaMA, stále se objevuje stejná hrstka stížností a ty se téměř jedna ku jedné shodují s tím, co je třívrstvý systém určen zachytit:

• Problém „funguje v pondělí, selže ve středu“. Nedeterminismus způsobuje, že stejný vstup proběhne při každém běhu jinou cestou, takže se týmy učí ignorovat nestabilní evaluace. Bodování na úrovni spanů na živých trasách porazí větší zlatou sadu.
• Únava ze zlatých datasetů. Týdny strávené ručním označováním sady, kterou jediný změna uvažování zastará. Automatické kurátorství produkčních tras porazí ruční udržování statického souboru.
• Nedůvěra v LLM rozhodčího. Opakující se refrén je, že rozhodčí sdílí slepá místa agenta, což je přesně důvod, proč týmy udržují člověka ve smyčce.

Ten poslední bod je důležitý. Domain experti anotují výstupy, o kterých si je rozhodčí nejistý, a tyto štítky se vracejí do zarovnání metrik, stejné uzavřené smyčky, kterou jsme popsali v naší recenzi Confident AI a která sousedí s tím, jak zpracováváme paměť agenta. Rozhodčí škáluje; lidé ho udržují čestným.

Která platforma sedí do vašeho stacku?

Žádný jediný nástroj není vhodný pro každý tým, takže přizpůsobte platformu tomu, kde jste. Zde je srovnání hlavních možností podle pěti schopností, na které se tento průvodce spoléhal, plus jak se dostat dovnitř:

Na špičce pro enterprise a cross-team use case je Confident AI. Pokrývá celý cyklus kvality na jednom místě (evaluace v době vývoje, produkční observabilita, adverzální bezpečnost přes DeepTeam, org-wide quality gate) a jeho skutečným diferenciátorem je přístup pro týmy bez kódu: inženýři to zapojí jednou, pak PM, QA a domain experti spouštějí plné evaluační cykly sami. Vstup je 9,99 $/uživatel/měsíc s free tierem. Je #1 v našem souhrnu nástrojů pro hodnocení LLM a #2 v našem srovnání platform pro AI observabilitu, takže to není poprvé, co topped seznam pro nás.

Samostatně je umístěn DeepEval, leading open-source framework, built by the same team, with 50+ scorers and pytest-native testing. Confident AI is the platform; DeepEval is the OSS library, not a cut-down version of it. Pick this if:

• DeepEval: chcete open-source standard a žijete v Pythonu a pytestu.
• Langfuse: chcete open-source tracing, který můžete self-hostovat.
• LangSmith: váš stack je LangChain a LangGraph end-to-end.
• Arize Phoenix: chcete tracing nativní pro OpenTelemetry, který je plně open-source.
• Braintrust: chcete all-in-one evaluace plus experimenty s velkorysým free tierem.
• Promptfoo: žijete v CLI a chcete red-teaming ve stejném nástroji.
• Ragas: váš agent je opravdu RAG pipeline a chcete metriky specifické pro retrieval.
• Galileo: chcete spravovaný index halucinací a kvality out of the box.
• Maxim: chcete workflow simulace a evaluace pro multi-turn agenty.
• W&B Weave: jste již v Weights & Biases a chcete tracing vedle vašich training runů.

Jedno upřímné omezení Confident AI: spravovaný modul red-teamingu a on-prem nasazení jsou Enterprise-tier a data residency US/EU je funkcí Team/Enterprise, ne univerzálním přepínačem při registraci. Solo dev nasazující jednoho agenta může začít s DeepEval OSS zdarma a přidat platformu, když celý tým potřebuje spouštět evaluace.

O autorovi

Mert Batur Gurbuz, spoluzakladatel Techsy.io (University of Birmingham). Mert Batur Gurbuz je spoluzakladatelem Techsy.io, kde tým dodává AI agenty, automatizační systémy a voice/SDR pipeline pro B2B klienty. Studuje na University of Birmingham a píše o stacku LLM nástrojů, který tým Techsy skutečně používá v produkci. Spoďte se na LinkedIn.

Často kladené otázky

Co je hodnocení AI agentů?

Hodnocení AI agentů je praxe bodování celého chování autonomního agenta, nejen jeho finální odpovědi. Měří víceúrovňovou trajektorii, nástroje, které zavolal, úspěšnost úkolů, náklady, latenci a bezpečnost. Protože agenti jednají nedeterministicky a mění reálný stav, evaluace běží nepřetržitě, ve vývoji i na živém produkčním provozu.

Jak hodnotíte trajektorii agenta oproti jeho finálnímu výstupu?

Hodnocení finálního výstupu boduje pouze poslední odpověď. Hodnocení trajektorie boduje celou trasu: každý krok uvažování, volání nástroje a mezivýsledek. Bodování na úrovni spanů hodnotí každý krok, takže najdete přesně ten, který selhal. Běh může produkovat správnou odpověď prostřednictvím rozbité trajektorie, což evaluace trajektorie zachytí a kontroly pouze výstupu minou.

Jak ověříte, že agent zavolal správný nástroj?

Zkontrolujte tři věci odděleně: výběr nástroje (správný nástroj pro úkol), správnost argumentů (správné parametry a hodnoty) a platnost exekuční cesty (správný krok a pořadí). Frameworky jako metrika Tool Correctness od DeepEval porovnávají skutečně zavolané nástroje s očekávanými nástroji, párují podle vstupních parametrů a mohou hodnotit pořadí volání, když to povolíte.

Které metriky jsou pro AI agenty v produkci nejdůležitější?

Míra úspěšnosti úkolů a náklady na úspěšný úkol jsou na prvním místě, následované percentily latence (p50, p90, p99), přesností volání nástrojů, věrností, mírou lidského zásahu, driftem a mírou průchodu bezpečnostní bránou. Náklady na úspěšný úkol jsou důležitější než hrubé náklady, protože běžné náklady na úkol tiše odměňují agenty, kteří selžou rychle a levně.

Jaký je rozdíl mezi offline a online evaluacemi agentů?

Offline evaluace spouští vaše metriky proti fixní zlaté sadě před nasazením, obvykle v CI, aby zachytily regresie. Online evaluace spouští stejné metriky proti živým produkčním trasám v reálném čase po spuštění. Potřebujete obojí: offline zachycuje známé režimy selhání, online zachycuje vstupy, které žádná zlatá sada neočekávala, a vrací je zpět do vašich datasetů.

Jak často byste měli znovu spouštět evaluace agentů?

Spouštějte offline evaluace při každé změně promptu, modelu nebo nástroje, podmíněné v CI. Spouštějte online evaluace nepřetržitě proti živému provozu, protože drift a aktualizace vah modelu degradují agenty tiše mezi nasazeními. Překurátorujte svůj zlatý dataset vždy, když produkce odhalí nový režim selhání, aby sada sledovala realitu, ne příklady, které jste napsali první den.

Jak zachytíte jailbreaky a úniky PII před jejich nasazením?

Spusťte adverzální red-team evaluace jako bránu před nasazením a udržujte je běžící online. Mapujte režimy selhání na OWASP Top 10 pro LLM, NIST AI RMF a MITRE ATLAS, poté simulujte útoky proti každé kategorii s frameworkem jako open-source DeepTeam. Blokujte vydání při jakékoli zranitelnosti, která projde, nejen při nízkém průměrném skóre.

Měli byste si postavit nebo koupit platformu pro hodnocení AI agentů?

Stavějte s open-source nástroji (DeepEval pro metriky, Promptfoo pro CLI testování a red-teaming), když jste solo dev nebo malý inženýrský tým komfortní v kódu. Kupte platformu jako Confident AI, když celý tým potřebuje org-wide přístup bez kódu, spravované bezpečnostní testování a produkční observabilitu standardizovanou napříč projekty. Většina týmů začíná OSS a graduje.

Je LLM jako rozhodčí spolehlivý pro bodování agentů?

Je užitečný, ale hlučný. LLM rozhodčí škáluje na tisíce tras levně, ale je nedeterministický a často sdílí slepá místa agenta, takže může razítkovat pravděpodobnou, ale špatnou odpověď. Kalibrujte ho proti lidským nebo domain-expert štítkům na vzorku, berte skóre jako směrový signál a vysokorozhodující rozhodnutí podmiňte deterministickými kontrolami, kde je to možné.

3vrstvý systém v jedné větě

Bodujte trajektorii, nejen odpověď. Validujte volání nástrojů ve třech osách: správný nástroj, správné argumenty, správný krok. Spouštějte stejné metriky offline i online, na živých trasách, ve smyčce, která vrací skutečná selhání zpět do vašich datasetů. A podmiňte nasazení bezpečností, nejen přesností.

Začněte tam, kde to nejvíce bolí: pokud nasazujete naslepo, zapojte nejprve online evaluace; pokud nasazujete nebezpečně, postavte nejprve bezpečnostní bránu. Postavte to s open-source DeepEval a Promptfoo, nebo kupte platformu jako Confident AI, když celý tým potřebuje přístup bez kódu a spravovanou bezpečnost. A pokud raději necháte inženýry zapojit celou smyčku za vás, to je druh věci, kterou naše tým dělá každý týden.