# 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.
```
A mi esetünkben: szintetikus podcast-összefoglalók, transcript-ek, subagent kimenetek — használhatók assertion-ökhöz.

**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)

1. **Távolíts el MINDEN friction-t az adatnézésből** — a trace-ek megjelenítése a legfontosabb UX-döntés
2. **Tartsd egyszerűen** — ne vegyél fancy LLM tool-okat, használd ami van
3. **Ha nem nézel sok adatot, rosszul csinálod** — ez a "you are doing it wrong" item
4. **Ne használj generic eval framework-öket** — domain-specifikus eval rendszert építs
5. **Írj sok unit tesztet és frissítsd gyakran**
6. **LLM-ek használata az eval rendszer építésének felgyorsítására** (test case generálás, assertion ötletelés, kritika)
7. **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.