Your AI Product Needs Evals — Hamel Husain (2024. március 29.)¶
Szerző: Hamel Husain (független AI tanácsadó, korábban GitHub CoPilot / CodeSearchNet)
Forrás: https://hamel.dev/blog/posts/evals/
Megjelenés: 2024. március 29.
Formátum: Technikai blog poszt (kb. 4000 szó)
Wiki raw: raw/articles/2026-07-14_hamel_ai_product_evals.md
Kulcsmondatok és alkalmazható tudás a rendszerünkre¶
Ez a poszt az LLM-alapú termékek eval-rendszereinek építéséről szól, és szinte 1:1 alkalmazható a Hermes Agent és más LLM-termékeink fejlesztésére. A legfontosabb üzenet: "ha nincs eval-rendszered, nem tudsz iterálni; ha nem tudsz iterálni, a terméked elakad a demó szinten."
A kiindulópont: Iterating Quickly == Success¶
A siker három tevékenységen múlik, és ezek együttesen "virtuous cycle"-t alkotnak: 1. Quality evaluation (tesztek, assertion-ök) 2. Debugging (trace-ek, adat-ellenőrzés) 3. Behavior change (prompt eng, fine-tuning, kód)
A poszt szerint sikertelen LLM-termékek szinte mindig ugyanazt a hibát követik el: nem építenek robusztus eval-rendszert. Az eval a "legkritikusabb komponens" — a ciklus központi eleme.
Három eval-szint — költség és gyakoriság szerinti sorrendben¶
| Szint | Módszer | Költség | Gyakoriság |
|---|---|---|---|
| Level 1 | Unit tesztek (assertion-ök, mint pytest) | Alacsony | Minden code change-nél |
| Level 2 | Human + Model eval (trace-ek, kritika) | Közepes | Rendszeres, ütemezett |
| Level 3 | A/B testing | Magas | Csak jelentős termékváltozás után |
Fontos szabály: A Level 1 unit teszteket jól ki kell építeni mielőtt a Level 2 model-alapú eval-ba lépnél — utóbbiak lassabbak és több munkát igényelnek.
Level 1: Unit tesztek — a leggyorsabb visszacsatolás¶
Assertion-ök, mint a szoftverfejlesztésben (pl. pytest), de az LLM-ekhez specializálva:
- expect(matches.length).to.equal(0, 'Exposed UUIDs found') — konkrét regex alapú ellenőrzés
- A unit tesztek scoped-ak legyenek: feature × scenario mátrix
- Példa Rechat/Lucy esetén: "Listing Finder" feature → 3 scenario (1 találat, több találat, 0 találat) → 3 assertion
- Generic tesztek is kell: UUID-k nem szivárognak ki, dátum formátum helyes, stb.
Saját rendszerünkre alkalmazható: A Hermes Agent skill-ek, subagent-ek, tool hívások mind tesztelhetők unit tesztekkel:
- API válasz formátum (pl. JSON struktúra)
- A skill-ek output-jainak invariánsai
- A transcript-source-detection.md típusú döntési logika assertion-ökkel
- A delegate_task subagent-ek output-formátumának ellenőrzése (pl. "a summary-ban legyen ## Összegzés szekció")
Szintetikus teszt adatok generálása LLM-mel — ez egy erőteljes minta a cikkből:
Write 50 different instructions that a real estate agent can give to his assistant
to create contacts on his CRM. The contact details can include name, phone, email...
For each of the instructions, you need to generate a second instruction which can
be used to look up the created contact.
Fontos figyelmeztetés: A unit teszteknél nem kell 100%-os pass rate — ez egy product decision, a tolerált failure mode-októl függ.
Level 2: Human & Model eval — ahol a valódi tanulás történik¶
Trace-ek logolása — elengedhetetlen: - LLM trace = user message → AI response → user message → AI response... - Megoldások: LangSmith, saját logger, lightweight framework-ök - Trace-ek domain-specifikus megjelenítése: Saját data viewer tool építése, Gradio/Streamlit/Panel/Shiny Python-ban, akár 1 nap alatt - Rechat példája: a trace-eket az adott domain (CRM, valós adatok) kontextusában mutatja — final output szerkeszthető (data curation fine-tuning-hoz)
Saját rendszerünkre alkalmazható:
- A -ben lévő session-ök és subagent kimenetek "trace"-ként funkcionálnak
- A session_search eszköz a trace-ek közötti kereséshez használható
- A wiki topic frissítések (mint ez a mostani) emberi eval-ként működnek — minden bejegyzést átnézünk, mielőtt a topic-ba kerül
Model-alapú eval kritikával: - A legerősebb elérhető modell használata a kritika-íráshoz - A kritika-modell prompt-ját iteratívan hangoljuk az emberi eval-hoz - FONTOS: az agreement metric önmagában félrevezető lehet (különösen kiegyensúlyozatlan dataset-eknél) — precision és recall külön mérendő
model response | model critique | model outcome
phillip critique | phillip outcome | phillip desired response
Saját rendszerünkre alkalmazható: A jelenlegi subagent-ek kimeneteit egy "critique agent"-tel lehetne ellenőrizni — pl. "ellenőrizd, hogy a summary tartalmazza-e az összes rész témát, hivatkozik-e a forrásra, és a magyar helyesírás megfelelő-e."
Level 3: A/B testing — utolsó lépés, érett termékeknél¶
- Csak akkor, ha a termék már elég érett a valódi felhasználók számára
- Az LLM-eknél nem különbözik a hagyományos A/B teszteléstől
- Eppo blog (Hamel korábbi kollégái) — referenciaként ajánlva
Eval rendszerek = "unlock superpowers for free"¶
Fine-tuning: Ha van eval-rendszered, a fine-tuning data curation majdnem ingyen van: - 99% of fine-tuning work = high-quality data assembling - A synthetic data generation ugyanaz, mint a Level 1 unit tesztek generálása - A critique model kimenete = high-quality labeled data - A human-eval tool = emberi adatkuratálás
Debugging: Az eval infra és a debugging infra 90%-ban átfedésben van: - Trace-ek adatbázisa → search & filter - Assertion-ök, tesztek → error flagging - Log search & navigation - Change → test → iterate ciklus
Saját rendszerünkre alkalmazható: A mostani podcast-processing pipeline-unk minden eleme alkalmas erre:
- A podhome-transcript-parser.py unit tesztekkel ellenőrizhető
- A chunk-summary subagent-ek kimenete human eval-hoz hasonlítható
- A wiki topic frissítések adat-curationként szolgálnak
A poszt legfontosabb tanulságai (saját szűrőnkön átszűrve)¶
- Távolíts el MINDEN friction-t az adatnézésből — a trace-ek megjelenítése a legfontosabb UX-döntés
- Tartsd egyszerűen — ne vegyél fancy LLM tool-okat, használd ami van
- Ha nem nézel sok adatot, rosszul csinálod — ez a "you are doing it wrong" item
- Ne használj generic eval framework-öket — domain-specifikus eval rendszert építs
- Írj sok unit tesztet és frissítsd gyakran
- LLM-ek használata az eval rendszer építésének felgyorsítására (test case generálás, assertion ötletelés, kritika)
- Az eval infrastruktúra újrafelhasználása debugging-ra és fine-tuning-ra
A mi rendszerünkre való konkrét alkalmazás¶
| Javasolt fejlesztés | Miért |
|---|---|
| Unit tesztek a chunkoló scriptekre | podhome-transcript-parser.py most nincs tesztelve — minden futtatásnál manuálisan ellenőrizzük |
| Trace-ek strukturált logolása a subagent-ekről | A mostani pipeline-ban a subagent-ek "completion" üzeneteit használjuk, de a belső gondolkodásukat nem rögzítjük |
| Model-alapú eval a magyar summary-kra | A subagent-ek kimeneteit egy critique agent-tel lehetne ellenőrizni (magyar helyesírás, formátum, tartalom lefedettség) |
| Synthetic test data generálás | Pl. "generálj 10 szintetikus podcast transcript-et, ami a topic-mappák mindegyikébe tartozik legalább 1 rész-ot" |
| Rechat-stílusú data viewer | Saját Gradio/Streamlit app a transcript-ek és summary-k review-zásához, emberi adatkuratálás fine-tuning-hoz |
| "Pass rate" dashboard | A mostani rebuild_indexes.py mintájára egy eval-metrics dashboard |
Forrás¶
- Eredeti URL: https://hamel.dev/blog/posts/evals/
- Szerző: Hamel Husain
- Dátum: 2024. március 29.
- Letöltve: 2026. július 14.
- Word count: kb. 4000 szó
Hivatkozások a posztból (ajánlott olvasmányok)¶
- CodeSearchNet — Hamel korábbi projectje, a GitHub CoPilot elődje
- LangSmith — trace logging megoldás, nem követeli meg a LangChain használatát
- Lilac — AI-alapú semantic search a trace-ekben
- Jason Liu posztja a RAG eval-ról — https://www.jasonliu.xyz/
- Eppo blog — A/B testing referencia (Hamel korábbi kollégáitól)
- LangChain — automatikus trace logging LangSmith-ba
- Shiny for Python — a Rechat data viewer mögött
- Gradio / Streamlit / Panel — lightweight data viewer alternatívák
Alkalmazhatóság a Hermes rendszerünkre: MAGAS¶
Ez a poszt a Hermes Agent fejlesztésének egyik legfontosabb referenciája. Jelenleg a rendszerünk "manuális eval" módban működik (minden feldolgozás után Henky manuálisan ellenőrzi a summary-t és a topic frissítést). A poszt módszertana alapján több automatizálási lehetőség is van — különösen a model-alapú eval és a unit tesztek terén.