Jak postavit vlastní LLM evaluační framework v n8n

Pokud jste někdy stavěli aplikaci poháněnou generativní AI, znáte ten pocit: jedna malá změna promptu, výměna modelu nebo drobná úprava nodu může proměnit perfektně fungující workflow v nepředvídatelný chaos. Na rozdíl od deterministického kódu vnášejí AI výstupy do hry prvek příjemného — ale frustrujícího — chaosu.

Přesně proto nemůžete při nasazování AI spoléhat na dohady. Potřebujete dedikovaný, opakovatelný testovací mechanismus: framework pro evaluaci LLM.

Proč potřebujete evaluační framework?

Evaluační framework posouvá váš vývojový proces od dohádávání ke konkrétním, měřitelným důkazům. Tady je důvod, proč na tom záleží:

• Nasazujte s jistotou — Zachyťte regrese a okrajové případy dřív, než na ně narazí vaši uživatelé.
• Validujte změny objektivně — Zjistěte, jestli úprava promptu skutečně zlepšila výsledky, nebo jen změnila styl psaní.
• Experimentujte rychleji — Testujte radikální změny v bezpečném sandboxu bez dopadu na produkci.
• Rozhodujte o modelech na základě dat — Rychle porovnejte nové modely z hlediska nákladů, rychlosti a přesnosti pro váš konkrétní úkol.

Proč používat n8n pro evaluaci LLM?

n8n přistupuje k evaluaci jako ke kontinuální, do workflow nativně zabudované praxi — ne jako k jednorázovému benchmarku. Klíčové výhody:

• Vizuální implementace na canvasu — Žádné vlastní Python skripty ani externí infrastruktura. Stačí přetáhnout a propojit nody.
• Dedikovaná evaluační cesta — Testovací logiku udržujte zcela oddělenou od produkčních triggerů.
• Přizpůsobitelné metriky — Měřte správnost výstupů, bezpečnost, přesnost volání nástrojů, počet tokenů, čas provádění a mnoho dalšího.

Klíčové metody evaluace, které můžete implementovat

1. LLM-as-a-Judge

Zlatý standard pro otevřené úkoly jako sumarizace nebo kreativní psaní. Výkonný model (např. Claude Sonnet nebo GPT-4) hodnotí výstupy menšího, levnějšího cílového modelu. V n8n to nakonfigurujete přímo v Evaluation nodu pomocí vestavěných metrik:

• Correctness (AI-based) — Skóre 1–5 podle toho, zda odpověď odpovídá vašemu referenčnímu výstupu.
• Helpfulness (AI-based) — Skóre 1–5 podle toho, zda odpověď adresuje dotaz.
• Custom Metrics — Definujte vlastní kritéria, např. „Použila AI formální tón?"

2. Evaluace RAG a agentních workflows

Pokud váš workflow využívá Retrieval-Augmented Generation nebo volání nástrojů, je potřeba hodnotit celý systém. Metrika Tools Used v n8n ověří, zda agent správně zavolal správný nástroj, zatímco Correctness (AI-based) může ověřit, zda načtený obsah odpovídá ground truth.

3. Kvantitativní / deterministické metriky

Poskytují jednoznačné datové body, které doplňují kvalitativní hodnocení:

• Token Count — Sledujte náklady v čase.
• Execution Time — Monitorujte dopad latence na uživatelský zážitek.
• Categorization — Vrací 1 pro správnou klasifikaci, 0 pro chybu. Ideální pro klasifikační úkoly.
• String Similarity — Zachytí drobné formátovací chyby, aniž by penalizovala sémanticky správné odpovědi.

4. Evaluace bezpečnosti a politik s Guardrails nodem

Guardrails node umožňuje validovat vstupy i výstupy v reálném čase — kontrolovat toxicitu, PII nebo vlastní obsahové politiky — a směrovat selhání na záložní agenty nebo lidskou kontrolu.

Krok za krokem: Evaluace analýzy sentimentu

Aby bylo vše konkrétní, tady je postup, jak postavit evaluační framework pro workflow analýzy sentimentu, který kategorizuje příchozí e-maily jako Pozitivní, Neutrální nebo Negativní.

Krok 1: Nastavte ground truths pomocí Data Tables

Použijte funkci Data Table v n8n k vytvoření testovacího datasetu. Zaměřte se na záludné okrajové případy:

• Frustrace z konkurence — Negativní jazyk, ale pozitivní záměr (chtějí přejít k vám).
• Sarkasmus — „Byl jsem nadšený, když mi projekt zamrzl na šest hodin."
• Smíšené signály — Malý kompliment skrytý uvnitř velké stížnosti.

Vaše tabulka by měla mít sloupec expected (ground truth) a sloupec result (vyplňovaný během evaluačních běhů).

Krok 2: Postavte evaluační workflow

Načtěte všechny záznamy z datové tabulky, projděte je v cyklu a každý předejte do nodu pro analýzu sentimentu. Použijte Check if Evaluating node k rozdělení workflow na dvě cesty:

• Evaluační cesta — Uložte výstupy zpět do datové tabulky, vypočítejte metriky.
• Produkční cesta — Směrujte e-maily do příslušného obchodního týmu jako obvykle.

Tím předejdete „test pollution" — například nechtěnému odeslání 50 testovacích případů vašemu obchodnímu týmu.

Krok 3: Vypočítejte metriky

Použijte možnost Set Metrics v Evaluation nodu a vyberte vestavěnou metriku Categorization. Vrací 1 pro správnou klasifikaci a 0 pro neshodu — přesně to, co potřebujete pro sledování přesnosti.

💡 Pomocí možnosti Custom Metrics můžete také vypočítat Precision, Recall a F1 Score.

Krok 4: Spusťte a porovnejte

Spouštějte evaluace přímo z canvasu nebo použijte záložku Evaluations pro vizuální graf metrik v čase. V reálném testu tří modelů Gemini na 10 záludných případech:

Model	Přesnost	Čas provádění
Gemini 3 Pro	100 %	~30 sekund
Gemini 2.5 Flash	100 %	~1,6 sekundy
Gemini 2.5 Flash Lite	100 %	~650 ms

Všechny tři prošly — ale Flash Lite byl 46× rychlejší než Pro. To je síla evaluačního frameworku: rozhodujete se na základě dat, ne domněnek.

Osvědčené postupy

• Vždy oddělujte evaluační logiku od produkce pomocí Check if Evaluating nodu.
• Budujte „Golden Dataset" z reálných okrajových případů a historických selhání.
• Měňte vždy jen jednu proměnnou — model nebo prompt, nikdy obojí najednou.
• Pravidelně auditujte svého LLM-as-a-Judge — není neomylný a jeho systémový prompt může vyžadovat doladění.
• Kombinujte kvalitativní a kvantitativní metriky — rychlost sama o sobě celý příběh nevypráví.

Závěr

Vybudováním evaluačního frameworku přímo v n8n přecházíte od dohádávání k jistotě. Zachytíte regrese dřív, než se dostanou do produkce, kvantifikujete dopad každé změny promptu a objektivně porovnáváte modely z hlediska nákladů a výkonu.

Začněte v malém, sestavte svůj první testovací dataset a šťastnou automatizaci!