> Forgatókönyv LLM-modellek cseréjéhez: elavulási határidők, szerződésjavítás, regressziós készlet, prompthangolás, árnyékforgalom és canary.
>
> Web page: https://balazscsorba.com/hu/blog/llm-model-migration-regression-testing · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/llm-model-migration-regression-testing.md) · [Deutsch](https://balazscsorba.com/de/blog/llm-model-migration-regression-testing.md)
> Author: Balázs Csorba · Published: 2026-10-16 · Keywords: LLM model migration, LLM regression testing, model deprecation OpenAI, Claude model deprecation, switch LLM model without breaking, LLM model upgrade checklist, prompt regression testing, shadow testing LLM, model retirement date, golden dataset LLM, LLM drift monitoring

[Blog](https://balazscsorba.com/hu/blog)/LLMOps és értékelés

# LLM-modellmigráció regresszió nélkül: elavulás, evalok, árnyékforgalom

Forgatókönyv LLM-modellek cseréjéhez: elavulási határidők, szerződésjavítás, regressziós készlet, prompthangolás, árnyékforgalom és canary.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 16.·10 perc olvasás

-   Model migration
-   Regression testing
-   Deprecations
-   LLM evals
-   Canary releases

![Öt migrációs szakasz a leltártól és a szerződésjavítástól az offline evalokon és az árnyékforgalmon át a visszaállítható canary bevezetésig.](https://balazscsorba.com/images/blog/llm-model-migration-regression-testing/cover.webp?v=c9ed0a1b06)

## A lényeg röviden

-   A szolgáltatók ütemezetten vezetik ki a modelleket: az OpenAI az általánosan elérhető modelleknél legalább hat hónapot ad, az Anthropic legalább 60 napot, a Gemini előzetes modelljeinél akár csak két hetet.
-   A modellcsere három dolgot változtat meg: az API-szerződést, a promptjaidon mutatott viselkedést, valamint a tokenszámot és a költséget; mindegyiket külön ellenőrizd.
-   Tesztelés előtt rögzíts pontos modellazonosítókat, kezeld őket központilag, és leltározd a tényleges használatot a szolgáltatói exportokból és a gateway-naplókból.
-   Futtasd egymás mellett a régi és az új modellt egy élesből épített arany adatkészleten, állíts kaput a sikerre, a parse-hibákra, az elutasításokra, a hosszra, a költségre és a késleltetésre, és olvass el minden vesztes esetet.
-   Árnyékforgalommal és kapcsoló mögötti canary kiadással vezesd be, a promptot és a modellt együtt verziózd, és utána is futtasd hetente a készletet.

Ezen az oldalon

1.  [Miért tör el valami modellcserénél](https://balazscsorba.com/#why-model-swaps-break)
2.  [Elavulási ütemtervek az OpenAI-nál, az Anthropicnál és a Google-nél](https://balazscsorba.com/#deprecation-timelines)
3.  [Rögzítsd a modellazonosítókat, és tudd, hol használod őket](https://balazscsorba.com/#pin-and-inventory)
4.  [A migrációs folyamat](https://balazscsorba.com/#migration-pipeline)
5.  [2\. szakasz: előbb a szerződést javítsd, aztán a viselkedést teszteld](https://balazscsorba.com/#contract-changes)
6.  [3\. szakasz: regressziós készlet a modellcseréhez](https://balazscsorba.com/#regression-suite)
7.  [Hangold újra a promptokat, az effortot és a régi kerülőmegoldásokat](https://balazscsorba.com/#retune-prompts)
8.  [4\. és 5. szakasz: árnyékforgalom és canary](https://balazscsorba.com/#shadow-and-canary)
9.  [A migráció után is futtasd a készletet](https://balazscsorba.com/#continuous-regression)
10.  [Migrációs ellenőrzőlista](https://balazscsorba.com/#checklist)
11.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

Minden LLM-funkciónak, amelyet kiadsz, van egy lejárati dátuma, amelyet nem te választottál. A szolgáltatók ütemezetten vezetik ki a modelleket, és az utód sosem egyszerű csere: a kérésparaméterek elutasításra kerülnek, a régi modellre hangolt promptok másképp viselkednek, és a tokenizáló is másképp számolhatja a bemenetet. Ha a Claude Sonnet 4.5 része a rendszerednek, az óra most is látványosan ketyeg: az Anthropic 2026. szeptember 30-án elavultnak jelölte, és 2026. november 30-án kivezeti, ajánlott utódja a Claude Sonnet 5.5.

Ez a cikk egy migrációs forgatókönyv: hogyan működnek az elavulási ütemtervek az OpenAI-nál, az Anthropicnál és a Google-nél, hogyan találod meg az összes hívási pontot, mit mérjen egy modellcseréhez készült regressziós készlet, és hogyan vezesd be az új modellt árnyékforgalommal (shadow traffic) és canary kiadással egy egyik napról a másikra történő váltás helyett.

## Miért tör el valami modellcserénél

Új modellre váltáskor három különböző dolog változik, és mindegyikhez külön ellenőrzés kell:

-   **Az API-szerződés.** A régi modellen működő paraméterek az újon 400-as hibát adnak. A Claude Opus 5.5 migrációs útmutatója többet is felsorol: a thinking kikapcsolását, a thinking-kereteket, a kényszerített eszközválasztást, a nem alapértelmezett mintavételi paramétereket és az előre kitöltött asszisztensválaszt mind elutasítja.
-   **Viselkedés.** Ugyanaz a prompt más kimenetet ad. Sclar és társai pusztán jelentésmegőrző formázási változtatásokkal akár 76 pontos pontosságkülönbséget mértek, és azt találták, hogy a legjobban működő formátum a modellek között csak gyengén korrelál. Az A modellre hangolt prompt nincs a B modellre hangolva.
-   **Költség és korlátok.** Az Anthropic útmutatója szerint az Opus 4.7-tel bevezetett tokenizáló ugyanarra a szövegre nagyjából 1-1,35-szer annyi tokent használhat, mint a korábbi modellek. A `max_tokens` értéked, a compaction küszöbök és a költségbecslések vele együtt mozdulnak.

Van egy negyedik eset is, amely egyáltalán nem migráció: ugyanaz a modellnév változtat viselkedést. Chen, Zaharia és Zou a GPT-4 2023 márciusi és júniusi verzióját hasonlította össze, és azt találta, hogy a prímszámok felismerésének pontossága 84%-ról 51%-ra esett, a generált kódban pedig több lett a formázási hiba. Következtetésük, hogy "ugyanannak" az LLM-szolgáltatásnak a viselkedése rövid idő alatt jelentősen változhat, amellett szól, hogy a regressziós készletet ütemezetten futtasd, ne csak váltáskor.

## Elavulási ütemtervek az OpenAI-nál, az Anthropicnál és a Google-nél

Az, hogy mennyi előzetes figyelmeztetést kapsz, a szolgáltatótól és a modell fajtájától függ. Az egyes szolgáltatók dokumentációja szerint:

Szolgáltató

Minimális előzetes értesítés a kivezetés előtt

Hogyan figyeld

tagchildren

Általánosan elérhető modelleknél legalább 6 hónap, specializált változatoknál (chat, Codex, deep research) 3 hónap, előzetes (preview) modelleknél akár csak 2 hét

A `GET /v1/models` modellenként opcionális `shutdown_date` mezőt ad vissza

tagchildren

Nyilvánosan kiadott modelleknél legalább 60 nap; az aktív telepítéssel rendelkező ügyfeleket értesítik

Elavulási oldal a várható kivezetési dátumokkal; a Console használati exportja API-kulcs és modell szerint

tagchildren

Az előzetes modelleket legalább 2 hetes értesítéssel vezetik ki; a -latest alias mögött cserélődik a modell, törő változásnál 2 hetes e-mailes értesítéssel

A stabil modellnevek "általában nem változnak"; elavulási oldal

Két gyakorlati következmény. Soha ne tegyél előzetes modellt vagy `-latest` aliast üzletkritikus funkció mögé: az OpenAI dokumentációja kifejezetten nem javasolja az előzetes modelleket ilyen terhelésre, hacsak nem tudsz rövid határidővel migrálni. És amikor bevezetsz egy modellt, aznap írd be a kivezetési dátumát egy naptárba. Az Anthropic a várható dátumokat jelenleg "nem korábban, mint" formában adja meg, ami alsó határ, nem ígéret.

## Rögzítsd a modellazonosítókat, és tudd, hol használod őket

Egy migrációt, amelynek nem ismered a hatókörét, nem tudsz befejezni. Bármilyen tesztelés előtt:

1.  **Élesben pontos modellazonosítót rögzíts.** Geminin stabil nevet, Claude-on és OpenAI-on pontos azonosítót. Az alias deploy nélkül mozdul el, vagyis a viselkedés commit nélkül is megváltozhat.
2.  **A modellazonosítót központilag, konfigurációban tárold,** felhasználási esetenként egy bejegyzéssel ("order-extraction", "support-triage"), ne hívási pontonként egy string literállal. Egy olyan gateway, mint a [LiteLLM](https://balazscsorba.com/hu/tools/litellm) vagy az [OpenRouter](https://balazscsorba.com/hu/tools/openrouter), ezt útválasztási szabállyá teszi.
3.  **Leltározd a tényleges használatot.** A kódkeresés megtalálja az ismert hívási pontokat. Az Anthropic Console használati exportja (CSV API-kulcs és modell szerint) és a gateway-naplóid megtalálják az elfelejtetteket: a cron jobot, a belső eszközt, a prototípust, amelyből éles rendszer lett.
4.  **Rögzítsd a kérésbeállításokat felhasználási esetenként:** max tokens, thinking- vagy effort-beállítás, eszközválasztás, a strukturált kimenet sémája, mintavételi paraméterek. Pontosan ezeket utasíthatja el az új modell.

## A migrációs folyamat

Minden modellcserét ugyanazon az öt szakaszon viszek végig. Minden szakasznak van kilépési feltétele, és bármilyen hiba egy lépéssel visszaküld, nem előre, egy éles javítással.

A modellcsere mint kiadási folyamat. Az 1. és 2. szakasz mechanikus; a 3-5. szakaszban derülnek ki a viselkedésbeli változások.

## 2\. szakasz: előbb a szerződést javítsd, aztán a viselkedést teszteld

A szerződésváltozások determinisztikusak, ezért ezeket kezeld először és külön. Olvasd el a szolgáltató migrációs útmutatóját a pontos forrás- és célmodelledre. Konkrét példaként néhány változás, amelyet a Claude Opus 5.5 útmutatója felsorol a korábbi modellekről érkező kódhoz:

Régi beállítás

Claude Opus 5.5 esetén

Javítás

`thinking: {type: "disabled"}` vagy `budget_tokens` keret

400-as hiba

Töröld a mezőt; válassz effort szintet (alapértelmezés: medium)

`tool_choice` any vagy egy megnevezett eszköz

400-as hiba

`auto` és utasítások, vagy strukturált kimenet

`temperature`, `top_p`, `top_k` nem alapértelmezett értékkel

400-as hiba

Hagyd el őket; a prompttal irányíts

Előre kitöltött asszisztensválasz formátum kikényszerítésére

400-as hiba

Strukturált kimenet vagy rendszerprompt-utasítás

`max_tokens` régebbi tokenizálóhoz méretezve

Ugyanarra a szövegre akár kb. 35%-kal több token, mint az Opus 4.7 előtti modelleknél

Mérd újra tokenszámlálással; hagyj tartalékot

Ennek a szakasznak a kilépési feltétele egyszerű: a leltárban rögzített összes kérésforma hiba nélkül lefut az új modellen. Az Anthropic a Claude Code-hoz egy `/claude-api migrate` skillt is kínál, amely egy kódbázisban végrehajtja a modellazonosító cseréjét és a törő paraméterváltozásokat, és kézzel ellenőrizendő pontokból álló listát készít. Az ilyen eszközök felgyorsítják a 2. szakaszt; a 3. szakaszt nem helyettesítik.

## 3\. szakasz: regressziós készlet a modellcseréhez

Az Anthropic eval útmutatója szerint a regressziós evaloknak 100% közelében kell lenniük, és a visszaesést kell kiszúrniuk. Modellcserénél ez a készlet mindkét modellt ugyanazokon a bemeneteken futtatja, és összehasonlít. Az élesből építsd, ne a képzeletből: vegyél mintát a valódi kérésekből felhasználási esetenként, add hozzá az összes korábbi incidenst, és mindegyik mellé tedd oda a várt eredményt vagy egy referenciaválaszt. Aztán ne csak a pontosságot mérd:

Metrika

Miért mozdul el modellcserénél

Példa kapu (az én alapértékeim)

Feladatsiker az arany adatkészleten

Viselkedésváltozás

Nincs a zajon túli esés; minden korábbi incidens továbbra is átmegy

Séma- és parse-hibák

A formázási szokások modellenként eltérnek

Nulla, bekapcsolt strukturált kimenettel

Elutasítási és tartózkodási arány

A modellek eltérően óvatosak

Néhány ponton belül a régi modellhez képest; minden új elutasítást olvass el

Kimenet hossza

A bőbeszédűség változása eltöri a felületeket és az SMS-korlátokat

A medián ±20%-on belül

Token és költség elvégzett feladatonként

Tokenizáló, bőbeszédűség, thinking

Bevezetés előtt ismert és elfogadott

Késleltetés p50 és p95

Thinking-alapértékek, modellméret

A funkció késleltetési keretén belül

A nyitott kimeneteket párosával pontozd: mutasd meg egy bírónak ugyanarra a bemenetre a régi és az új választ véletlenszerű sorrendben, és kérdezd meg, melyik felel meg jobban a rubrikának. A "van-e olyan jó, mint előtte" kérdésre a páros összehasonlítás stabilabb, mint az abszolút pontszám, és felszínre hozza az elolvasásra érdemes eseteket. Maga a harness kicsi:

```
import random, statistics

def compare(cases, old_model, new_model, run, judge, checks):
    """run(model, case) -> Result(text, tokens, ms, refused); judge(case, a, b) -> 'a'|'b'|'tie'"""
    rows = []
    for case in cases:
        old, new = run(old_model, case), run(new_model, case)
        flip = random.random() < 0.5                      # hide which answer is new
        verdict = judge(case, *( (new.text, old.text) if flip else (old.text, new.text) ))
        new_wins = (verdict == "a") == flip if verdict != "tie" else None
        rows.append({
            "id": case.id,
            "checks_failed": [c.name for c in checks if not c(case, new)],   # schema, refs, rules
            "new_wins": new_wins,
            "refused": (old.refused, new.refused),
            "len_ratio": len(new.text) / max(1, len(old.text)),
            "token_ratio": new.tokens / max(1, old.tokens),
            "ms": (old.ms, new.ms),
        })
    losses = [r for r in rows if r["new_wins"] is False or r["checks_failed"]]
    print("losses to read:", [r["id"] for r in losses])
    print("median length ratio:", statistics.median(r["len_ratio"] for r in rows))
    return rows
```

Ha a funkció ügynökalapú vagy mintavételezett, minden esetet többször futtass; modellenként egy futtatás elrejti a szórást. A vesztes esetek listája a szakasz valódi kimenete: a továbblépésről ezeknek az eseteknek az elolvasása alapján döntesz, nem egyetlen összesített pontszám alapján. A [Promptfoo](https://balazscsorba.com/hu/tools/promptfoo) és hasonló eszközök konfigurációból is lefuttatják ugyanezt az összehasonlítást, ha nem akarsz saját harnesst fenntartani; a módszert az [LLM evalok termékfunkciókhoz](https://balazscsorba.com/hu/blog/llm-evals-for-product-features) című cikk részletesebben bemutatja.

## Hangold újra a promptokat, az effortot és a régi kerülőmegoldásokat

Ha a készlet vesztes eseteket mutat, ne pakolj újabb utasításokat a régi promptra. A promptokban kerülőmegoldások gyűlnek össze az előző modell furcsaságaira ("soha ne használj felsorolásjelet", "a mezőt MINDIG add vissza, akkor is, ha üres"), és egy újabb modell ezeket túl szó szerint veheti. Ez egybevág Sclar és társai megállapításával, hogy a promptformátum-preferenciák rosszul vihetők át egyik modellről a másikra. Az én sorrendem:

1.  **Először a kerülőmegoldásokat töröld,** és futtass újra. Sok vesztes eset eltűnik.
2.  **Hangold újra az érvelési beállítást.** A Claude-nál az effort váltja a thinking-kereteket, és az alapértékek modellenként eltérnek (az Opus 5.5-nél medium). Próbáld ki a low, medium és high szintet a készleten, és felhasználási esetenként válassz.
3.  **A formátumra való rábeszélést cseréld strukturált kimenetre,** ahol a szolgáltató támogatja.
4.  **Csak ezután adj hozzá új utasításokat,** egyenként, mindegyiket egy elbukó esethez kötve.

**A promptot a modellel együtt verziózd**

Egy prompt egy adott modellre van hangolva, nem általánosan. A prompt verzióját és a modellazonosítót együtt tárold, együtt telepítsd és együtt állítsd vissza. Ha a modellt visszaállítod, de az új promptot megtartod, az egy harmadik konfiguráció, amelyet senki sem tesztelt.

## 4\. és 5. szakasz: árnyékforgalom és canary

Az offline készletek csak azokat az eseteket tartalmazzák, amelyekre gondoltál. Az **árnyékforgalom** az élő kérések másolatát elküldi az új modellnek, a válaszát a kiszolgált válasz mellé naplózza, és soha nem mutatja meg a felhasználóknak. Futtasd néhány napig, hogy lefedje a heti forgalmi mintát, majd az árnyékpárokon futtasd le ugyanazokat az ellenőrzéseket, mint a 3. szakaszban. Két figyelmeztetés: az árnyékhívások pénzbe kerülnek, ezért nagy forgalomnál vegyél mintát; és az árnyékág soha ne hajtson végre mellékhatást. Ügynököknél csak az olvasó részt tükrözd, vagy az eszközöket irányítsd sandboxba.

A **canary** ezután egy funkciókapcsoló mögött a forgalom kis részének szolgálja ki az új modellt, ugyanazokkal a dashboardokkal, mint a régi modellnél: hibaarány, elutasítási arány, felhasználói visszajelzés, feladatonkénti költség és késleltetés. Lépésenként bővíts (5%, 25%, 100%), lépésenként rögzített megfigyelési ablakkal, és a régi konfigurációt a kivezetési dátumig tartsd telepíthető állapotban, hogy a visszaállás egy kapcsoló átbillentése legyen, ne egy kiadás. Az [OpenTelemetry alapú tracing](https://balazscsorba.com/hu/blog/agent-observability-opentelemetry) a modellenkénti összehasonlítást egy lekérdezéssé teszi projekt helyett.

## A migráció után is futtasd a készletet

A regressziós készletet drága felépíteni, de olcsó fenntartani. Futtasd hetente az éles konfiguráció ellen, és minden prompt- vagy modellváltozáskor. Így kiszúrod a stabil név mögötti sodródást (Chen és társai esete), lesz alapvonalad, amikor megjön a következő elavulási értesítés, és a "váltsunk-e az új, olcsóbb modellre?" kérdésből mérés lesz. Ugyanez a készlet teszi biztonságossá a [költségalapú modellválasztást](https://balazscsorba.com/hu/blog/llm-cost-latency-prompt-caching-routing): egy olcsóbb modell csak akkor olcsóbb, ha átmegy.

A ranglisták segítenek jelölteket választani, ahogy az [Artificial Analysis jelenlegi rangsoráról](https://balazscsorba.com/hu/blog/artificial-analysis-leaderboard-claude-opus-5-5) írtam, de azt nem tudják megmondani, hogy a kinyerő promptod még mindig megtalálja-e a szállítási dátumot. Ezt csak a saját készleted tudja.

## Migrációs ellenőrzőlista

1.  Minden használt modell kivezetési dátumát írd be a naptárba; élesben kerüld az előzetes modelleket és a -latest aliasokat.
2.  Rögzíts pontos modellazonosítókat, kezeld őket központilag felhasználási esetenként, és leltározd a tényleges használatot a szolgáltatói exportokból és a gateway-naplókból.
3.  Olvasd el a migrációs útmutatót a pontos forrás- és célmodelledre; először minden elutasított paramétert javíts.
4.  Mérd újra a tokenszámokat, és igazítsd a max\_tokens értéket, a kereteket és a compaction küszöböket.
5.  Futtasd egymás mellett a régi és az új modellt egy élesből és korábbi incidensekből épített arany adatkészleten.
6.  Állíts kaput a sikerre, a parse-hibákra, az elutasításokra, a hosszra, a feladatonkénti költségre és a késleltetésre, és olvass el minden vesztes esetet.
7.  Új utasítások előtt töröld a régi prompt-kerülőmegoldásokat; hangold újra az effortot felhasználási esetenként.
8.  Tükrözd az élő forgalmat mellékhatások nélkül, majd canary kiadás egy kapcsoló mögött, visszaállási lehetőséggel a kivezetési dátumig.
9.  A migráció után is futtasd hetente a készletet.

Ha közeleg egy kivezetési dátum, és segítség kellene a migrációhoz, nézd meg az [AI engineering](https://balazscsorba.com/hu/expertise/ai-engineer) oldalt.

## Források

1.  [Claude API docs: Model deprecations](https://platform.claude.com/docs/en/about-claude/model-deprecations)
2.  [OpenAI API docs: Deprecations](https://platform.openai.com/docs/deprecations)
3.  [Gemini API docs: Models and version name patterns](https://ai.google.dev/gemini-api/docs/models)
4.  [Claude API docs: Claude Opus 5.5 migration guide](https://platform.claude.com/docs/en/models/opus-5-5/migration-guide)
5.  [Chen, Zaharia, Zou: How is ChatGPT's behavior changing over time? (2023)](https://arxiv.org/abs/2307.09009)
6.  [Sclar et al.: Quantifying Language Models' Sensitivity to Spurious Features in Prompt Design (2023)](https://arxiv.org/abs/2310.11324)
7.  [Anthropic: Demystifying evals for AI agents (Jan 2026)](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)

## Gyakori kérdések

Mennyi előzetes értesítést adnak az LLM-szolgáltatók egy modell kivezetése előtt?

Az OpenAI az általánosan elérhető modelleknél legalább hat hónapot, a specializált változatoknál három hónapot, az előzetes modelleknél akár két hetet dokumentál. Az Anthropic a nyilvánosan kiadott modelleknél legalább 60 napot ad. A Google a Gemini előzetes modelljeit legalább két hetes értesítéssel vezeti ki, és a -latest aliasok mögött lecseréli a modellt.

Elég egyszerűen kicserélni a modellazonosítót és újra telepíteni?

Ritkán. Az újabb modellek elutasíthatnak olyan paramétereket, amelyeket a régi elfogadott, például a kikapcsolt thinkinget, a kényszerített eszközválasztást vagy az előre kitöltött választ a Claude Opus 5.5-nél; az egyik modellre hangolt prompt a másikon másképp viselkedik, és a tokenszám is változhat. Előbb a szerződést javítsd, aztán bevezetés előtt futtass regressziós készletet.

Mit mérjen egy LLM-migráció regressziós tesztkészlete?

A feladatsikert egy éles forgalomból és korábbi incidensekből épített arany adatkészleten, a séma- és parse-hibákat, az elutasítási arányt, a kimenet hosszát, az elvégzett feladatonkénti tokent és költséget, valamint a késleltetést. Ugyanazokon a bemeneteken hasonlítsd össze a régi és az új modellt, és olvass el minden esetet, ahol az új modell veszít.

Mi az árnyéktesztelés (shadow testing) LLM-eknél?

Az árnyéktesztelés az élő kérések másolatát elküldi az új modellnek, és a válaszait a kiszolgáltak mellé naplózza anélkül, hogy a felhasználók látnák őket. Így olyan eseteket is találsz, amelyek kimaradtak az offline készletből. Gondoskodj róla, hogy az árnyékág ne válthasson ki mellékhatást, különösen író eszközökkel rendelkező ügynököknél.

Miért teljesítenek rosszabbul a promptjaim egy újabb, jobb modellen?

A promptokban kerülőmegoldások gyűlnek össze a régi modell furcsaságaira, és kutatások szerint a legjobb promptformátum a modellek között csak gyengén korrelál. Először töröld a régi kerülőmegoldásokat, hangold újra az érvelési vagy effort-beállítást, a formátumra való rábeszélés helyett használj strukturált kimenetet, és csak ezután adj hozzá elbukó esetekhez kötött új utasításokat.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [Strukturált kimenet JSON Schemával: mit fed le a garancia, és mit nem](https://balazscsorba.com/hu/blog/structured-outputs-json-schema-llm)
-   [MI-ügynökök értékelése: trajektóriák, eredmények és megbízhatóság pontozása](https://balazscsorba.com/hu/blog/evaluating-ai-agents-trajectories)
-   [Szemantikus gyorsítótár LLM-alkalmazásokhoz: mikor biztonságos újrahasznosítani a válaszokat, és mikor nem](https://balazscsorba.com/hu/blog/semantic-caching-llm-responses)
-   [Saját LLM-üzemeltetés a GDPR miatt: mikor kell és mibe kerül](https://balazscsorba.com/hu/blog/self-hosted-llm-gdpr-cost)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)