Menu

llm

azure_openai_enterprise

Azure és OpenAI: fordulat az enterprise AI piacán?

, , , , , , , ,

| Olvasási idő: 5 perc |

Az előző cikkben megnéztük, hogy a Microsoft hogyan mozdul el a saját AI–modellek irányába, és miért csökkenti hosszú távon a függőségét az OpenAI-tól.

Most viszont beszélek a legfontosabb kérdésről: Mit jelent ez nekünk, akik Azure-t és OpenAI-modellt használunk?

Néhány fontos és mindenkiben felmerülő kérdést igyekszem megválaszolni.

Stabil marad az Azure OpenAI?

A rövid válasz: igen.

Az Microsoft és az OpenAI között több évre szóló megállapodás van érvényben. Az Azure OpenAI Service jelenleg működik, frissül, támogatott.

Ha ma:

  • chatbot-ot futtatsz Azure-on
  • RAG rendszert építesz
  • belső tudásbázist generatív AI-val egészítesz ki

akkor nincs ok azonnali aggodalomra.

Ez nem egy hirtelen váltás, sőt az is lehet, hogy hosszú távon sem fog ez Téged érinteni.

Mit csináljunk máshogy az AI-al?

Amit én sok cégnél látok: az LLM-et fix, központi komponensként kezelik. Konkrét modell névre és típusra építik a szolgáltatásokat.

Nagyon ritka, hogy valaki megfelelően, konfigurációs állományban definiálva használja a modelleket. És néhány esetben láttam már olyat is, hogy egy modellre specifikusan van írva a kód. Nincs fallback, nincs B terv.

Ez rövid távon működik, vagy prototípusok esetén kiválóan működik, de hosszú távon nagyon kockázatos.

Ha a Microsoft saját foundation modelleket (alapmodell) vezet be Azure-on belül, akkor valószínűleg még a jelenleginél is több modell közül választhatunk majd. Ez jó hír, hiszen még több lehetőségünk van megtalálni a megoldásunkhoz tökéletesen passzoló modellt.

Ez azonban csak akkor működőképes, ha az architektúránk erre fel van készítve. Ha tanácstalan vagy, hogyan tudod ezt megtenni, az alábbiak segíthetnek:

  • Service layer: Az LLM-hívás legyen egy központi backend szolgáltatásból megvalósítva, és ne a UI réteg (frontend) vagy minden mikroszolgáltatás saját, egyedi integrációja. Így ha később modellt kell cserélni, azt nem az egész kódbázisban kell átírni, hanem csak a backend-hez kell hozzányúlni.
  • Konfigurálható modellválasztás: A használt AI-modell ne legyen fixen beégetve a kódba, hanem konfigurációból lehessen meghatározni, hogy éppen melyik modellt és annak melyik verzióját használja a rendszer. Ez lehetővé teszi, hogy teszteléskor egy olcsóbb (akár helyi) modellt használjunk, éles környezetben pedig egy erősebbet, vagy hogy gyorsan váltsunk, ha változik az ár vagy a teljesítmény.
  • Monitoring token- és költségszinten: Az AI-hívások költsége token alapú, ezért nagy forgalomnál gyorsan elszállhat, ha nincs rálátásunk a használatra. A felhőszolgáltató ad alap költségfigyelést, de enterprise környezetben alkalmazás szinten is érdemes mérni, mely funkció mennyi AI-erőforrást fogyaszt. A token az AI világában ugyanaz, mint korábban a CPU-idő volt: ha nem mérjük, nem tudjuk kontrollálni.
  • Fallback modell logika: Érdemes úgy megtervezni a rendszert, hogy ha az elsődlegesen használt modell nem elérhető, túl lassú vagy túl drága, akkor a rendszer automatikusan át tudjon váltani egy alternatív modellre. Ez növeli az üzletmenet-folytonosságot és csökkenti a szolgáltatáskimaradás kockázatát.

Ezek nem felesleges lépések, hanem a hosszútávú stabilitást biztosító praktikák.

Ugyanúgy, ahogy nem kötjük egyetlen availability zone-hoz a rendszert, ne kössük egyetlen modellhez sem.

AI vendor lock-in kérdés

Az Azure használata önmagában nem feltétlenül probléma. Az viszont igen, ha az AI logika teljesen egy adott modell viselkedésére optimalizált, az már kockázat.

A piac abba az irányba megy, hogy a nagy cloud szolgáltatók (kivéve Azure) kínál saját modelleket. A Google (Gemini, Imagen, stb) és az AWS (Amazon Titan) is kínálnak saját modelleket.

Ha te Azure-on maradsz, az teljesen jogos döntés, de az AI-réteg legyen cserélhető.

Egy jól átgondolt architektúrában az alábbiakat követjük:

  • Platformfüggetlen: A rendszer ne egy konkrét cloud szolgáltató vagy modell sajátosságaira épüljön, hanem általános LLM-képességre.
  • API-absztrakció: Az LLM-hívásokat egy központi backend API kezelje, ne a frontend vagy több különálló komponens közvetlenül a modellt.
  • Tudatos modellválasztás: A modell kiválasztása use case, teljesítmény és költség alapján történjen, ne alapértelmezett döntésként.

Copilot jövője

A Microsoft 365 Copilot és a GitHub Copilot jelenleg jelentős részben OpenAI modellekre épülnek, de tudunk már egyéb modelleket is használni, például a Sonnet-et vagy a Opus-t.

Ha a Microsoft saját modelleket integrál, az nem feltétlenül jelent minőségromlást. Én úgy gondolom, inkább előrelépést hozhat, mert nem egy általános modellt kapunk majd, hanem specializált megoldásokat.

A Microsoft célja inkább a:

  • költségcsökkentés
  • adatkontroll
  • stratégiai függetlenség

Felhasználói oldalról nagyobb változás csak akkor várható, ha a modellváltás érezhetően befolyásolja a minőséget.

AI költségtudatosság

Ez az a pont, amit nem lehet megkerülni. Az AI nem olcsó és bármit is hoz a jövő a költség az egyik legfontosabb tényező marad.

Az AI-szolgáltatások token alapú számlázással működnek, vagyis minden elküldött és generált szöveg után fizetünk, és mivel a modellek komoly számítási kapacitást igényelnek, nagy forgalomnál a költség nagyon gyorsan meg tud nőni.

Ha a Microsoft saját modellekkel optimalizálni tudja a költségstruktúrát Azure-on belül, az enterprise ügyfeleknek előny lehet.

Ma még nem tudjuk, hogy az új modellstratégia pontosan milyen árszinten jelenik meg, ezért különösen fontos a használat folyamatos monitorozása és a költséglimitek beállítása. Érdemes a teszt- és éles környezetet szigorúan elkülöníteni, valamint kontroll alatt tartani a fejlesztői környezeteket is, hogy ne maradjanak feleslegesen futó, költséget termelő AI-folyamatok.

Igen, ez AI-nál is ugyanaz a jelenség, mint VM-eknél: ha nem figyelsz, elszáll a költség.

Karrier szempontból mit tanulj?

Ha Azure + OpenAI irányba haladsz, ne csak prompt engineeringet tanulj.

Tanuld meg az alapokat és az általános AI világ rejtelmeit:

  • hogyan működik egy RAG architektúra
  • miként mérünk modell teljesítményt
  • milyen módon optimalizálunk költséget
  • miért tervezzünk multi-model környezetet
  • stb.

A piac nem egy modell köré szerveződik. Hanem AI megoldások és technikák köré.

A lényeg

Nem kell kétségbe esni, a két cég nem szakít és nem vállnak azonnal ketté útjaik. Inkább járjunk nyitott szemmel és készüljünk fel a változásra.

  • Az Azure OpenAI ma stabil
  • A stratégia változik
  • A piac érik és fejlődik
  • Az architektúrának rugalmasnak kell lennie

Ha AI-rendszert építesz Azure-on, most van itt az ideje annak, hogy enterprise szinten gondolkodj: költség, biztonság, rugalmasság.

Érdekelnek a hasonló Cloud és AI tartalmak?

docling_xlsx_to_md_ai_1024

Docling: Így készíts tökéletes adatot bármilyen RAG-hez

, , , , , , , , , ,

| Olvasási idő: 5 perc |

Aki rendszeresen fejleszt vagy oktat AI megoldásokat – legyen szó Azure OpenAI-ról vagy bármilyen LLM integrációról –, az pontosan ismeri a problémát: a Retrieval-Augmented Generation (RAG) rendszerek lelke az adat, de az adataink többsége „halott” formátumokban csücsül. Itt jön képbe a Docling.

PDF-ek, Word dokumentumok, Excel táblák – Ezek emberi olvasásra kiválóak és látványosak, de a gépek számára gyakran emészthetetlenek.

Az Mentor Klubos Azure oktatásaim során rendszeresen bemutatom a klasszikus „Enterprise Chat” felépítést:

  1. Feltöltünk fájlokat egy Azure Storage Account-ra.
  2. Létrehozunk egy Azure AI Search indexet.
  3. Az OpenAI Foundry Studio-ban összekötjük a modellt az adatokkal.

A demó mindig látványos, de a valóságban sokszor hiányérzete van a z oktatáson résztvevőknek. Miért? Mert ha egy PDF tele van táblázatokkal, hasábokkal vagy lábjegyzetekkel, a beépített „chunking” (daraboló) algoritmusok szétesett, értelmezhetetlen szövegmasszát adnak át a keresőnek. Ugyanez a probléma az Excel táblázatokkal is.

Nincs olyan képzés, amikor nem teszik fel a kérdést: „Excel táblában is képes keresni az AI?„
Korábban az volt a válaszom, hogy nem és valójában közvetlenül nem is tud benne keresni, még RAG esetén sem.

Az eredmény: a használt LLM hiába zseniális, ha a kereső rossz kontextust ad neki. Garbage In, Garbage Out.

A megoldás: Strukturált Markdown

A tapasztalatom az, hogy az LLM-ek imádják a Markdown formátumot. A Markdown tisztán leírja, mi a főcím, mi az alcím, és ami a legfontosabb: megőrzi a táblázatok szerkezetét. Ezért a gyors és látványos bemutatóknál, már előkészített fájlokkal érkezem

De ki akar kézzel konvertálni több száz, vagy több ezer vállalati PDF-et? Senki. Ezért hoztam létre egy egyszerű, bárki által használható megoldást, aminek a lelke a Docling.

Mi az a Docling?

A Docling egy új generációs, nyílt forráskódú megoldás, ami nem csak kiolvassa a szöveget a fájlokból, hanem látja és érti is az oldalak szerkezetét (Layout Analysis).

Míg a hagyományos konverterek (pl. PyPDF) gyakran sorról sorra olvassák a szöveget (így a kéthasábos cikkek összekeverednek), a Docling felismeri a blokkokat. Képes komplex táblázatokat, fejléceket és lábjegyzeteket is helyreállítani, és mindezt egy tiszta, strukturált Markdown fájlba menti.

Mondhatjuk, hogy ez a RAG szempontjából aranyat ér. Ha a Docling által generált .md fájlt adod oda az Azure AI Search-nek (vagy bármilyen más vektorkeresőnek), a válaszok pontossága drasztikusan javulni fog. Ezzel pedig időt és pénzt takaríthatunk meg.

A kész eszköz: Docling RAG Converter

Ha szeretnéd kipróbálni, hogyan is teljesít és ne kelljen a nulláról kódolnod, készítettem egy Python alapú eszközt, amit a GitHub-on közzé is tettem. Ez az egyszerű projekt egy számomra kedvelt alapra épül: a Python mellett az uv csomagkezelőt használja, ami villámgyors és brutálisan egyszerű használni is.

A GitHub repo, ahol a megoldás van itt elérhető: https://github.com/cloudsteak/docling-rag-converter

Windows, Mac és Linux kompatibilis

Nem kell Python gurunak lenned. A célom az volt, hogy bárki, aki RAG rendszert épít, pillanatok alatt elő tudja készíteni az adatait.

1. Előkészületek

Szükséged lesz a git-re és az uv-re. Ha az uv még nincs fent, egy sorral telepítheted:

  • Windows (PowerShell): powershell -c "irm https://astral.sh/uv/install.ps1 | iex"
  • Mac/Linux: curl -LsSf https://astral.sh/uv/install.sh | sh

2. Töltsd le a kódot

Klónozd le a projektet a gépedre:

git clone https://github.com/cloudsteak/docling-rag-converter.git
cd docling-rag-converter

3. Futtasd a konvertert

Az uv zsenialitása, hogy nem kell manuálisan virtuális környezetet (venv) létrehoznod vagy pip-pel bajlódnod. A következő parancs mindent elintéz helyetted (letölti a Docling-ot, a függőségeket és a szükséges AI modelleket):

uv run docling-rag-converter.py

Hogyan működik?

  1. Az első futtatáskor a script létrehoz egy input és egy output mappát. (ha szükséges, de ez része a projektnek)
  2. Másold be a feldolgozni kívánt fájljaidat az input mappába (PDF, DOCX, XLSX, HTML, PPTX).
  3. Futtasd újra az uv run docling-rag-converter.py parancsot.
  4. Dőlj hátra. A script végigmegy a fájlokon, és az output mappába generálja a tökéletesen formázott .md fájlokat.

Miért jobb ez az Azure OpenAI-hoz?

Ha ezeket a generált Markdown fájlokat töltöd fel a Storage Account-ra a nyers PDF-ek vagy XLSX-ek helyett:

  1. Jobb Chunking: Az Azure AI Search a Markdown fejlécek (#, ##) mentén logikusan tudja darabolni a szöveget. Nem vág ketté mondatokat vagy gondolatmeneteket.
  2. Táblázat-értés: A nyelvi modell (pl. GPT-4o-mini) a Markdown táblázatokat kiválóan értelmezi. Ha megkérdezed, hogy „Mennyi volt a bevétel Q3-ban?”, a modell pontosan ki tudja olvasni a cellát, míg egy szétesett szövegből csak találgatna.
  3. Kevesebb Hallucináció: Mivel a forrásanyag tiszta és strukturált, az AI kevésbé hajlamos kitalálni dolgokat.

Eredeti XLSX:

Konvertált md fájl (előnézetben), AI által támogatott formában:

Összegzés

A Docling használatával a „fekete doboz” PDF-ekből és Excel fájlokból strukturált, szemantikus Markdown-t csináltunk. Amikor ezt feltöltöd a Storage Account-ra, és indexeled a Foundry-ban, a kereső pontosan tudni fogja, hol kezdődik egy táblázat, és melyik adat melyik oszlophoz tartozik.

Az eredmény? Egy RAG alapú dokumentum keresési megoldás, amellyel az AI pontosan válaszol.

Ez a kis extra lépés a pipeline elején választja el a „játék” demókat a valódi, production-ready vállalati megoldásoktól. Próbáld ki a megoldást, és kezd el Te is AI-al kezelni a céges dokumentumokat, bármilyen RAG megoldással!

Te hogyan oldod meg az adat-előkészítést? Írd meg a véleményed vagy a tapasztalataidat kommentben!

Ha pedig érdekelnek a hasonló Azure és AI tartalmak:

ai-models-2026-hero

Újdonságok: 2026 elején megjelent AI modellek és agentek

, , , , , ,

| Olvasási idő: 6 perc |

A mesterséges intelligencia világában folyamatos a pörgés és a változás. Rendszeresen jelennek meg az egyes nagy nyelvi modellek (LLM) újabb, frissített — de nem feltétlenül jobb — verziói. Most, hogy túl vagyunk januáron, érdemes egy pillanatra megállni, és megnézni: milyen AI modellek és agent-ek érkeztek meg 2026 elején, illetve mi az, ami már most körvonalazódik. És ami legalább ilyen fontos: vajon ezek a változások tényleg előre visznek minket, vagy csak tovább növelik a zajt?

A 2026 eleji kép egyértelműen azt mutatja, hogy a fókusz eltolódott. Nem „okosabb chatbotokat” építenek, hanem hosszabb ideig dolgozni képes, kontextust tartó, feladatokat elejétől a végéig elvégző modelleket és ügynököket. Ez nem látványos, de nagyon is hasznos irány, amikor egy komplex feladatot szeretnék az AI segítségével elvégezni.

GPT-5.3-Codex – amikor a kódolás már folyamat

A GPT-5.3-Codex február elején jelent meg, és egyértelműen hangsúlyozzák, hogy nem egyszeri promptokra optimalizálták. Az OpenAI itt már kifejezetten agentic codingról beszél: olyan fejlesztési munkáról, amely nem percekig, hanem órákig vagy akár napokig tart.

Ez a modell nem ott erős, hogy „írj egy függvényt”, hanem ott, hogy:

  • képes egy komplex kódbázison belül következetesen dolgozni,
  • visszatér korábbi döntésekhez,
  • és saját hibáit felismerve javítja azokat.

A sebességnövekedés önmagában nem izgalmas. Ami igazán számít: kevesebb beavatkozást igényel. Fejlesztői és DevOps szemmel ez azt jelenti, hogy egyre inkább partnerként viselkedik, nem pedig eszközként.

Ugyanakkor fontos korlát: ez sem váltja ki az architektúrát, a code review-t vagy a felelősségi köröket. Ahol ezt próbálják megspórolni, ott az AI nem segít, hanem megnöveli a hibák számát is.

Claude Opus 4.6 – gondolkodás nagy léptékben

A Claude Opus 4.6 szintén február elején jelent meg, de teljesen más problémára ad választ. Itt a hangsúly nem a kódoláson, hanem a tervezésen, elemzésen és hosszú kontextusok kezelésén van.

Ez a modell ott erős, ahol:

  • nagy dokumentumhalmazokat kell átlátni,
  • összetett üzleti, jogi vagy pénzügyi helyzeteket kell értelmezni,
  • vagy több, egymásra épülő döntést kell következetesen végiggondolni.

A hosszú kontextusablak nem öncélú technikai adat. A gyakorlatban azt jelenti, hogy nem kell feldarabolni a problémát csak azért, mert a modell „elfelejt” dolgokat. Ez enterprise környezetben óriási előny.

Cserébe ez nem egy „gyors” modell. Nem ideális real-time interakciókra vagy pipeline-ba illesztett automatikus futtatásra. Inkább döntéstámogató, elemző szerepben erős.

Ennek megfelelően használata drága, amire fel is hívja a figyelmet, amikor ezt a modellt használjuk.

Screenshot

Claude Cowork – amikor az AI tényleg dolgozik

A Claude Cowork nem új modell, hanem egy desktop agent, és emiatt sokkal érdekesebb, mint elsőre tűnik. Ez már nem csak válaszol, hanem:

  • fájlokat olvas és szerkeszt,
  • mappákban dolgozik,
  • böngészőt használ.

Ez az a pont, ahol az AI elkezd beleolvadni a napi munkavégzésbe. Nem külön eszköz, hanem „ott ül melletted”.

Itt viszont nagyon gyorsan előkerülnek a nem technikai kérdések: adatkezelés, jogosultságok, kontroll. Egy ilyen agent hatalmas hatékonyságnövelő lehet, de csak akkor, ha pontosan tudjuk, mit láthat és mit nem. Ez már governance kérdés, nem modellképesség.

A Cowork-nek vannak egyéb különlegességei is, erről majd egy későbbi videóban beszélek nektek.

Kimi K2.5 – nyílt AI modell, komoly ambícióval

A Moonshot AI Kimi K2.5 modellje sok benchmarkon jól szerepel, de a lényeg nem ez. Hanem az, hogy nyílt modellként próbál versenyezni a zárt rendszerekkel. Ez már önmagában is izgalmas és ígéretes. Kíváncsi leszek hová jutnak. Én drukkolok nekik.

Multimodális, és az agent-alapú működésre épít: több feladatot képes párhuzamosan kezelni, több „gondolkodási szálon”. Ez különösen érdekes ott, ahol:

  • szuverén AI-megoldásokban gondolkodnak,
  • on-prem vagy kontrollált környezetben kell futtatni a modellt.

Fontos viszont látni: a nyílt nem jelenti azt, hogy egyszerű. Az üzemeltetés, integráció és finomhangolás továbbra is komoly szakértelmet igényel. Cserébe viszont nagyobb kontrollt ad ,ami sokaknak fontosabb.

Gemma 3 – stabil alap, nem reflektorfényben

A Gemma 3 nem friss februári megjelenés, de 2026 elején is releváns. Ez a modellcsalád nem „mindent megoldó AI”, hanem megbízható építőkocka.

A Gemma ott jó választás, ahol:

  • célzott AI-funkciókra van szükség,
  • fontos a kiszámíthatóság,
  • és nem akarunk egy túl nagy, túl komplex modellt használni.

Sok projektben ez pont elég. Sőt, gyakran jobb, mint egy flagship modell, amit csak részben használunk ki.

Gemini Flash 3 – amikor a sebesség számít

A Gemini Flash 3 2025 decemberében jelent meg, de még bőven frissnek számít. A pozíciója nagyon egyértelmű: gyors, fürge, költséghatékony.

Ez nem a „legmélyebben gondolkodó” modell, hanem az, amelyik:

  • jól működik chat-alapú felületeken,
  • nagy forgalmat képes kiszolgálni,
  • és gyors válaszidőt ad.

A Gemma 3-hoz képest fontos különbség, hogy a Flash 3 inkább kész szolgáltatás, nem építőkocka. Kevesebb döntést igényel, gyorsabban lehet vele funkciót szállítani.

Cserébe nem erre bíznám komplex üzleti logikát vagy mély elemzést. Ott nem ez az erőssége.

Meta: Mango és Avocado – ami még csak irány

A Meta esetében a Mango és Avocado egyelőre belső kódnevek. Amit látni lehet: erős fókusz a multimodalitáson és a skálázhatóságon. Konkrét termékről még nem beszélhetünk, de irányról igen.

Ez tipikusan az a kategória, amit érdemes figyelni, de nem tervezni rá. A Meta eddigi tempóját ismerve lesz folytatás, csak még nem most.

Függetlenül az AI modellektől

A 2026 eleji helyzetkép a szokásos: nem egy „legjobb modell” van, hanem egyre több, jól körülhatárolt szerepre optimalizált megoldás. Ez jó hír, ha tudatosan választunk.

A rossz döntések nem abból születnek, hogy „rossz modellt választunk”, hanem abból, hogy nem tudjuk, mire szeretnénk használni. Ha ezt sikerül kiküszöbölnünk, akkor ezek a modellek és agent-ek valóban előre tudják mozdítani a munkát — technológiailag és üzletileg is.

Ha pedig érdekelnek a hasonló Azure és AI tartalmak:

kiemelt-kep-ai-kodol

Amikor az AI írja a kódot: mi marad az embernek?

, , , , , ,

| Olvasási idő: 3 perc |

Amikor pár éve az AI megjelent, sokan érezték úgy, hogy „elveszik a munkát”. Erről, sokat beszéltünk a képzéseimen is. Aztán kiderült, hogy nem elvette, hanem átalakította. Kevesebb manuális feladat, több kreatív dolog. Kevesebb tűzoltás, több tervezés. Már akkor is azt jósolták, hogy hamarosan az AI írja a programokat és alkalmazásokat.

Azóta is ugyanez történik újra, csak gyorsabban.

Az utóbbi hónapokban egyre gyakrabban látom azt, hogy fejlesztők nem azért írnak kevesebb kódot, mert lusták lennének, hanem mert nincs már értelme mindent kézzel megírni. Az AI nem „segít”, hanem konkrét munkarészeket vesz át. És ez most először nem elméleti vita, hanem napi gyakorlat.

Egy friss írásban a Anthropic vezérigazgatója, Dario Amodei egészen konkrét állítást fogalmazott meg:
szerinte 6–12 hónapon belül az AI képes lesz elvégezni a szoftverfejlesztők munkájának nagy részét, akár egészét is.

6 hónap múlva az AI írja a kódot

Ez a mondat önmagában félrevezető lenne. A részletek viszont sokkal érdekesebbek.

Amodei szerint az Anthropicnál már most dolgoznak olyan mérnökök, akik egyáltalán nem írnak kódot. Az AI generálja, ők pedig szerkesztik, ellenőrzik és döntéseket hoznak. Ez nem kísérlet, hanem működő munkamodell.

Az állítások szerint ehhez a Claude Opus 4.5 modellt használják, és az Anthropic egyik új terméke, a Cowork, szinte teljes egészében AI által generált kóddal készült el, nagyjából másfél hét alatt. A projekt mögött álló Boris Cherny pedig azt nyilatkozta, hogy az elmúlt hónapban a Cowork-höz való hozzájárulásainak 100%-át AI írta, ő pedig szerkesztett és irányított.

Ez fontos pont: nem arról van szó, hogy „a gép mindent megold”, hanem arról, hogy a fejlesztői munka súlypontja eltolódik.

És itt jön az a kérdés, amit szerintem érdemes feltenni. Nem az a kérdés, hogy eltűnnek-e a fejlesztők.
Hanem az, hogy mivé válik a fejlesztői munka, hol lesz az emberi hozzáadott érték, és mit jelent ez cloud, DevOps, architect és platform oldalról.

Amit ma az AI nagyon hatékonyan csinál, az a repetitív, szabályalapú munka. API-k váza, CRUD logika, config fájlok, pipeline-ok első verziói, Terraform sablonok. Ezek eddig is sok időt vittek el, és kevés valódi üzleti döntést igényeltek. Ha ezt átveszi egy eszköz, az nem veszteség, hanem felszabaduló kapacitás.

Viszont vannak határok, és ezt az eredeti cikk is hangsúlyozza.

Több, egymástól független szakember is kritikát fogalmazott meg. David Heinemeier Hansson, a Ruby on Rails megalkotója szerint az AI-alapú kódolási eszközök még nem érik el egy junior fejlesztő megbízhatóságát, különösen akkor, amikor valódi üzleti rendszerekről, nem pedig demókról van szó.

Hasonlóan óvatosan fogalmazott Matt Garman, az Amazon Web Services vezetője is. Szerinte a junior fejlesztők kiszorítása rövid távon hatékonynak tűnhet, de hosszú távon veszélyes, mert ők jelentik a jövő szakmai utánpótlását. Ha nincs tanulási út, nem lesz tapasztalt szakember sem.

Sok fejlesztő gyakorlati tapasztalata is ezt erősíti meg. Az AI gyakran jól működik izolált példákon, de valós rendszereknél rendszeresen hibázik – én is sokszor tapasztalok hasonlókat – , főleg igen speciális esetekben és biztonsági kérdéseknél. Ezeknél a hibáknál pedig nem hivatkozhatunk arra, hogy „ezt az AI írta”.

Cloud és DevOps szemmel nézve számomra egyértelmű a kép. Kevesebb lesz a kézzel írt kód, de nagyobb lesz a felelősség. Több architekturális döntés, több költség- és security kompromisszum, több platform-szintű gondolkodás. Nem az tűnik el, aki ért a rendszerekhez, hanem az a szerep, amely csak végrehajt.

Az eredeti cikk konklúziója szerint a szoftverfejlesztői szakma nem szűnik meg, de példátlan tempóban alakul át. A mérnökök egyre inkább olyan szerepbe kerülnek, amit talán legjobban úgy lehet leírni, hogy AI-t irányító és felügyelő szakemberek lesznek. Kevesebb aktív gépelés, több döntés, több kontroll.

Ha ebből egy dolgot érdemes hazavinni, az szerintem ez:

Nem az a kérdés, hogy az AI tud-e kódot írni. Hanem az, hogy te tudod-e, mit miért íratsz meg vele.

Ha ezek a kérdések benned is felmerülnek, érdemes róla beszélni. Írj nyugodtan, szívesen megosztom a saját tapasztalataimat.

ai-cloud-2026-featured-1024

AI + Cloud 2026: amikor a platform életre kel és gondolkodik

, , , , , , , , , ,

| Olvasási idő: 6 perc |

Az előző cikk végén ott hagytuk abba, hogy 2026-ban a cloud már nem cél, hanem eszköz. Egy gondolkodásmód, amire a legtöbb digitális rendszer épül. A következő lépés viszont már nem pusztán erről szól. Az igazi változás ott kezdődik, amikor az AI nem csak használja ezt az alapot, hanem formálni is kezdi a felhőt.

Ez a cikk erről a személetváltásról szól. Nem arról, hogy melyik modell jobb, és nem is technikai útmutató. Sokkal inkább arról, milyen szerepe lett és lesz az AI-nak a cloud működésében, és milyen következményei vannak ennek technológiai, gazdasági és döntési szinten.

Az AI szerepe a Cloud-ban megváltozott

Az AI ma már nem külön projektként jelenik meg a felhőben. Nem egy újabb doboz a sok közül, hanem platformszintű képesség. A cloud szolgáltatók nem egyszerűen futtatási környezetet adnak hozzá, hanem olyan rétegeket építenek köré, amelyek az AI-t beemelik a mindennapi működésbe. Mindehol ott a Co-Pilot jellegű működés, amely arra hivatott, hogy segítse a mindennapjainkat. Bár néha kifejezetten idegesítő.

Ez jól látszik abban, ahogyan a hyperscalerek pozicionálják az AI-t. Nem egyetlen „AI termékről” beszélnek, hanem olyan szolgáltatásokról, amelyek architektúra-tervezést, skálázást, költségoptimalizálást vagy incidensek értelmezését is támogatják. Fontos: Az AI nem helyettesít, hanem döntési teret alakít át.

Azure, AWS és GCP – „minden út Budára vezet”

A Microsoft Azure esetében az AI erősen az LLM-vonal köré szerveződik. Az Azure OpenAI Service és az erre épülő enterprise megoldások azt mutatják, hogy az AI szorosan integrálódik az üzleti folyamatokba. Nem önmagában érdekes, hanem azért, mert ott jelenik meg, ahol a felhasználók dolgoznak. Persze ez csak egy nagyon apró része annak az AI funkcionalitásnak és trendnek, amit ma ismerünk.

Az AWS más irányból érkezett. Régóta erős a machine learning területén, és ezt a tapasztalatot vitte tovább platformlogikába. A Bedrock a generatív AI-t teszi elérhetővé felügyelt módon, míg a SageMaker AI a klasszikus ML-életciklust fedi le. Az üzenet itt nem a modell, hanem az eszköztár és az irányíthatóság.

A Google Cloud Platform pedig azért érdekes, mert az AI nem új irány nála. A Google belső rendszerei évek óta AI-ra épülnek, és ez a szemlélet jelent meg a Vertex AI köré szervezett cloud kínálatban. Itt az adat és az AI szoros összekapcsolása kerül fókuszba.

A közös pont mindhárom esetben az, hogy az AI nem kiegészítő, hanem a platform működésének része lett.

Miért lett a cloud az AI természetes közege?

Sokan még mindig hardveroldalról közelítik meg az AI-t: milyen GPU kell hozzá, mennyi memória, elég-e egy erős otthoni gép. Ez a gondolkodás érthető, de egyre kevésbé írja le a valóságot.

A cloud egyik legnagyobb előnye az AI esetében nem pusztán a teljesítmény, hanem a skálázhatóság és az időbeliség. Olyan erőforrások érhetők el rövid időre is – több terabájt memória, több nagy teljesítményű GPU egy környezetben –, amelyek otthoni vagy kisebb on-prem környezetben nem reálisak.

A valódi szemléletváltás azonban ott történik, hogy az AI jellemzően felügyelt (managed) szolgáltatásként jelenik meg. Nem kell CPU-, RAM- vagy GPU-konfigurációval foglalkozni, nem kell drivereket, frameworköket karbantartani. Ezeket a problémákat a platform kezeli.

Személyes megjegyzésként idekívánkozik, hogy 2026-ban én is szert tettem egy aránylag erős helyi gépre, kifejezetten AI-val való kísérletezésre és fejlesztésre. Egy Ryzen 7 7800X3D, 64 GB RAM és egy RTX 3090 24GB körüli konfiguráció már alkalmas arra, hogy kis- és közepes modellekkel dolgozzak, tanuljak, prototípusokat építsek.

De ez a tapasztalat inkább megerősítette bennem: amit helyben lehet, az tanulás és kísérletezés. Amint skálázni, párhuzamosítani vagy üzemszerűen használni szeretnék, a cloud egyszerűen más ligában játszik.

És itt előtérbe kerül az árazás és az árazási modellek megértése a felhőben. Otthon az a kérdés, hogy elég-e a gép. A felhőben az, hogy mennyibe kerül, ha így használom. Ez az egyik oka annak, hogy az AI a cloud-ban nem hobbi-megoldásként, hanem üzemszerűen terjedt el.

Az AI hatása a hardverpiacra

Az AI és a cloud együtt nem csak szoftveres változást hozott. A hardverpiacon is érezhető a hatása. Az adatközponti AI igény nem csak GPU-kat szív fel, hanem memóriát is – különösen nagy sávszélességű és szerveroldali megoldásokat.

A piaci elemzések és üzleti hírek egyre gyakrabban kötik össze a memóriaárak alakulását az AI-adatközpontok növekvő igényével. A hangsúly eltolódott: a gyártók és beszállítók számára a hyperscalerek váltak a legfontosabb ügyfelekké.

A változás egyik leglátványosabb következménye az árakon látszik. Egyes GPU- és memóriaszegmensekben 2024–2025 során 1,5–3× közötti áremelkedés volt tapasztalható, különösen ott, ahol az adatközponti AI-igény közvetlenül megjelent. Ez nem egységes a teljes piacon, de jól mutatja az irányt: amikor a hyperscalerek és nagyvállalatok tömegesen vásárolnak, a fogyasztói és kisebb üzleti piac háttérbe szorul.

Ezt a folyamatot jól szemlélteti az NVIDIA bevételeit bemutató ábra. A sávok azt mutatják, hogyan vált a Data Center (DC) üzletág – vagyis a Cloud-os, AI-fókuszú infrastruktúra – a domináns bevételi forrássá, miközben a Gaming és az egyéb szegmensek aránya háttérbe szorult. A grafikon nem csak növekedést, hanem súlypont-eltolódást jelez: az AI ma már elsősorban adatközpontokban él.

Adatbiztonság és a félreértések

Az AI + Cloud kapcsán az egyik legtöbb bizonytalanságot az adatkezelés okozza. Sok félelem nem konkrét tapasztalatból, hanem feltételezésekből fakad. Gyakori gondolat, hogy a Cloud-os AI „biztos betanítja az adatokat”.

A valóság ennél árnyaltabb. A nagy cloud szolgáltatók dokumentációja különbséget tesz az alapértelmezett működés és az explicit engedélyezett tréning között. Enterprise környezetben az ügyféladatok jellemzően elkülönítve maradnak, és nem kerülnek más ügyfelekhez vagy alapmodell-tréningbe engedély nélkül.

Ugyanakkor fontos kimondani: a cloud nem varázslat. Az adatbiztonság nem automatikus. A shared responsibility modell itt is érvényes. A platform adja az alapokat, de a jogosultságkezelés, a hozzáférések és az adathasználat kontrollja továbbra is az ügyfél döntése.

A félelmek egy része abból fakad, hogy sokan a mai napig nem értik pontosan, hogyan működik egy AI. A modell, a tréning, az inference és az adatkezelés gyakran egyetlen „fekete dobozzá” mosódik össze a fejekben. Ha nem világos, mi történik egy kérdés elküldésekor, hol fut a feldolgozás, és mi marad meg belőle, akkor természetes reakció a bizalmatlanság. Ez a bizonytalanság nem rosszindulatból fakad, hanem információhiányból.

Ezért a zavar valószínűleg 2026-ban sem fog teljesen eltűnni. Nem azért, mert a szolgáltatók ne lennének egyre transzparensebbek, hanem mert az AI használata gyorsabban terjed, mint ahogy a szervezetek megtanulják helyesen értelmezni a működését.

Mit várhatunk 2026-ban az AI + Cloud területén?

Az AI és a Cloud együtt nem új trend, hanem új működési környezet. Kevesebb manuális döntés látszik, de több döntés történik a háttérben. Kevesebb technikai akadály, de nagyobb felelősség.

Azok járnak jól ebben a világban, akik nem csodát várnak az AI-tól, hanem értik, mire használják, és hajlandók felelősséget vállalni a döntéseikért.

2026-ban az AI nem egy kísérleti technológia lesz, hanem egy stratégiai alapvetés, amely a cloud működésének mindennapi részévé válik. A nagy technológiai szolgáltatók és elemzők szerint több irányban is érdemes felkészülni:

• Az AI szerepe tovább mélyül: A korábbi „AI mint eszköz” fázist teljesen felváltja az „AI mint partner” logika – az AI nem csak kérdésekre válaszol, hanem támogatja a döntéseket, együttműködik munkafolyamatokban és gyorsítja a kutatást. Ez nem csak technikai előny, hanem szervezeti és működési átalakulás is.

• Agentic AI és intelligens automatizálás erősödik: A vállalati környezetben 2026-ra szélesebb körben terjednek az olyan AI-agentek, amelyek nem csak input-output feladatokat végeznek, hanem autonómabban lépnek kölcsönhatásba rendszerekkel és döntési folyamatokkal.

• Adat és AI governance fókuszba kerül: A fogyasztók és szervezetek egyre nagyobb figyelmet fordítanak arra, hogyan használja az AI az adatokat, hogyan magyarázható és kontrollálható a működése. Ez nem csupán technikai kérdés, hanem a bizalom és jogi megfelelés alapja.

• Biztonság és infrastruktúra kiemelt téma: A növekvő AI-használat új támadási felületeket és identitás-vezérelt kihívásokat hoz, ezért a kiberbiztonság nem csak háttérfeladat, hanem stratégiai prioritás lesz az AI + Cloud környezetben.

Ezek az irányok nem csupán az én gondolataim, hanem a legfrissebb szakmai előrejelzésekkel egybevágó vélemény is.

Az AI nem külön dolog többé, hanem a Cloud működésének szerves, strukturális része lesz.

2026-ban már nem az a kérdés, használod-e az AI-t a Cloudban, hanem az, hogy jól használod-e. Ha ebben szeretnél biztosabb lenni, iratkozz fel az InfoPack hírlevélre vagy kövesd a cikkeimet.

chatgpt-5-2-kiemelt-kep

ChatGPT 5.2 – az eddigi legérettebb AI a gyakorlatban ma?

, , , , , , ,

| Olvasási idő: 4 perc |

Az elmúlt években látványosan felgyorsult a mesterséges intelligencia fejlődése. Ami pár éve még kísérleti játéknak tűnt, ma már napi szinten segít fejlesztésben, elemzésben, ügyféltámogatásban vagy akár tartalomkészítésben. Én is végigkövettem ezt az utat az első, még bizonytalan válaszokat adó modellektől egészen a mai, komplex rendszerekig. Ebbe a folyamatba illeszkedik bele a ChatGPT 5.2 megjelenése, ami egyértelműen nem csak egy apró frissítés, hanem egy fontos lépcsőfok lehet.

Ez egy új verziója az 5-ös modellnek, amitől én azt várom, hogy nem lesz olyan mogorva és merev. Habár meg kell jegyezni, hogy nemrég érkezett frissítés, hogy kiválasztható az 5.1-es modellhez a beszédstílusa, sokat javított az 5-ös okozta csalódáson. A 5.2 azonban már alapjaiban próbál reagálni ezekre az észrevételekre, nem csak felszíni finomhangolással.

Kezdjük azzal, hogy mit jelent a ChatGPT 5.2 a gyakorlatban. Ez jelenleg az OpenAI legfejlettebb, úgynevezett „frontier” modellje, amelyet kifejezetten valós feladatokra és agent jellegű működésre optimalizáltak. Ez utóbbi azt jelenti, hogy nem csak válaszol egy kérdésre, hanem képes hosszabb folyamatokban gondolkodni, eszközöket használni, és több lépésen keresztül eljutni egy eredményig.

A frontier modell kifejezés az aktuálisan elérhető legfejlettebb, technológiai élvonalat képviselő AI modelleket jelenti. Ezek a modellek mutatják meg, meddig jutott el adott pillanatban a mesterséges intelligencia képességekben, például gondolkodásban, kódolásban, képfeldolgozásban vagy komplex feladatok megoldásában. Jellemzően nem tömegfelhasználásra optimalizáltak, hanem új határokat feszegetnek, és irányt mutatnak a következő generációs, szélesebb körben elérhető modellek számára.

Kontextus kezelés

Az egyik legfontosabb előrelépés a hosszú kontextus kezelése. Egyszerűen fogalmazva: a modell sokkal jobban megérti a hosszú dokumentumokat, összetett leírásokat vagy „adatgazdag” anyagokat. Ha például egy több oldalas specifikációról, riportokról vagy vegyes, nem teljesen egyértelmű információkról van szó, a 5.2 lényegesen stabilabban tartja a fonalat – Állítja az OpenAI. Nem véletlen, hogy olyan cégek számoltak be erről pozitívan, mint a Notion, a Box vagy a Databricks.

AgenticAI

Szintén komoly előrelépés történt az eszközhívások terén. A ChatGPT 5.2 jobban tud külső rendszerekhez, API-khoz vagy belső funkciókhoz nyúlni, és ezek használatát megbízhatóbban illeszti bele egy hosszabb folyamatba. Ez azoknál a megoldásoknál különösen fontos, ahol az AI nem csak „beszélget”, hanem ténylegesen műveleteket végez, adatot kér le, majd az eredményt tovább dolgozza fel.

Vizuális képességek

A modell jelenleg az OpenAI legerősebb látásalapú megoldása. Diagramok, dashboard-ok, felhasználói felületek értelmezésében több mint 50 százalékkal csökkentek a hibák. Ez nekem azért különösen érdekes, mert egyre több üzleti alkalmazás és belső rendszer vizuális elemekre épül, ahol eddig az AI gyakran félreértelmezett összefüggéseket.

Kódírás

Fejlesztői szemmel a kódolási képességek erősödése sem elhanyagolható. A ChatGPT 5.2 átveheti a vezetést is a komplex programozási feladatokat mérő benchmark-okon. Nem csak új kód generálásában jobb, hanem hibakeresésben, refaktorálásban és meglévő rendszerek javításában is. Ez nem azt jelenti, hogy kivált egy fejlesztőt, de nagyon komoly gyorsító eszközzé válik a mindennapi munkában.

Túlgondolás?

Technikai szempontból fontos újdonság, hogy a modell a feladat bonyolultságához igazítja a gondolkodását – Hurrá! Ez az ahol az 5.1-es modell is megbukott. Jó hír, hogy az API-ban külön beállítható, mennyi „érvelési energiát” használjon: a legegyszerűbb válaszoktól egészen az extra magas szintű, mély elemzésekig. Ez nem csak minőségi, hanem költségszempontból is releváns, mert pontosabban lehet optimalizálni a felhasználást.

Drágább lett, de nem mindenkinek

Az árakról is érdemes őszintén beszélni. A ChatGPT 5.2 körülbelül 40 százalékkal drágább, mint az 5-ös és az 5.1-es verziók. Ugyanakkor a gyorsítótárazott bemenetekre jelentős kedvezmény jár, és elérhető különböző feldolgozási módokban, beleértve a batch feldolgozást is. Ez azt jelzi, hogy a modell elsősorban professzionális, üzleti és fejlesztői felhasználásra lett pozícionálva.

A remény

Összességében én úgy látom, hogy a ChatGPT 5.2 egy érettebb, kiegyensúlyozottabb lépés előre. Nem forradalmi abban az értelemben, hogy mindent újraírna, de nagyon határozottan a „használhatóbb AI” irányába mozdul. Ha az 5-ös modell kicsit hűvös és merev volt, a 5.2 már inkább egy jól képzett, megbízható munkatárs benyomását kelti. Kezdőknek pedig azért különösen érdekes, mert jól mutatja, merre tart az AI: kevesebb látványos ígéret, több valódi, mindennap használható fejlődés.

Remélem hosszútávon sikerül kellemesen csalódnom ebben a modellben, ugyanis, jelenleg szinte teljesen átálltam Claude Sonnet 4.5 és Claude Opus 4.5 modellek pro verzióinak használatára. Nem csupán a mindennapokban, hanem a kódolásban is.

featured_image

A Microsoft AI platform evolúciója: OpenAI és Foundry

, , , , , , , , , , , ,

| Olvasási idő: 4 perc |

Nem rég fejeztem be egy videós képzési anyagot a Mentor Klub részére, ahol a résztvevők megismerhették az Azure-on belül elérhető OpenAI megoldásokat. Ennek részeként bemutattam az Azure OpenAI Studio felületét is, ami valójában az Azure AI Foundry egyik funkcionális eleme. Mindkettőt elég gyakran használom, különböző projektekben és különböző célokra. Hogy éppen melyik a jobb egy adott feladathoz, azt többnyire az aktuális projekt igényei döntik el.

A Microsoft azonban az elmúlt hónapokban egy olyan változtatást indított el, amely alapjaiban alakítja át azt, ahogyan eddig AI-megoldásokat építettünk Azure-ban. A Foundry platform fokozatosan átveszi az Azure OpenAI Studio szerepét, kiszélesítve annak lehetőségeit és egységesítve az AI-fejlesztés teljes ökoszisztémáját.

Mi volt az Azure OpenAI Studio szerepe

A Microsoft az Azure OpenAI Studio felületet arra hozta létre, hogy egyszerű legyen kipróbálni és tesztelni az Azure által kínált OpenAI modelleket. A felület segítségével lehetett:

  • modelleket kipróbálni egy játszótérben
  • finomhangolt modelleket kezelni
  • API-végpontokat és kulcsokat elérni
  • kötegelt feldolgozást és tárolt befejezéseket használni
  • értékeléseket futtatni
  • és még sok hasznos AI programozást segítő funkciót.

Az Azure OpenAI Studio azonban alapvetően egy modelltípusra, az Azure által értékesített OpenAI modellekre épült. Ez a projektjeim során is érezhető volt: ha más modellgyártó megoldását szerettem volna használni, akkor azt külön kellett integrálni vagy külső szolgáltatásból kellett elérni.

Ez az a pont, ahol a Foundry teljesen más szemléletet hoz.

Mit kínál a Microsoft Foundry?

A Microsoft Foundry egy egységes AI-platform, amely több modellszolgáltatót, több szolgáltatást és teljes életciklus-kezelést egy felületre hoz. A Microsoft Learn dokumentum így fogalmaz: a Foundry egy nagyvállalati szintű platform, amely ügynököket, modelleket és fejlesztői eszközöket egy helyen kezel, kiegészítve beépített felügyeleti, monitorozási és értékelési képességekkel .

A legfontosabb különbségek a következők.

Széles modellkínálat

Az Azure OpenAI-val szemben a Foundry nem korlátozódik egyetlen gyártóra. Elérhetők többek között:

  • Azure OpenAI modellek
  • DeepSeek
  • Meta
  • Mistral
  • xAI
  • Black Forest Labs
  • Stability, Cohere és más közösségi modellek

És ez még csak a jéghegy csúcsa.

Ügynökszolgáltatás és többügynökös alkalmazások (AgenticAI)

A Foundry API kifejezetten ügynökalapú fejlesztéshez készült, ahol több modell és komponens együttműködésére van szükség.

Egységes API különböző modellekhez

A Foundry egységes API-t biztosít, így a fejlesztőnek nem kell minden gyártó logikáját külön megtanulnia.

Vállalati funkciók beépítve

A Foundry felületén eleve jelen vannak:

  • nyomkövetés
  • monitorozás
  • értékelések
  • integrált RBAC és szabályzatok
  • hálózati és biztonsági beállítások

Gyakorlatilag, minden ami a nagyvállalati és biztonságos működéshez elengedhetetlen.

Projektalapú működés

A Foundry projektek olyan elkülönített munkaterületek, amelyekhez külön hozzáférés, külön adatkészletek és külön tároló tartozik. Így egy projektben lehet modelleket, ügynököket, fájlokat és indexeket is kezelni anélkül, hogy más projektekhez keverednének.

Hogyan kapcsolódik össze a két világ

A Microsoft nem megszünteti az Azure OpenAI-t, hanem lehetővé teszi, hogy az adott erőforrás Foundry-erőforrássá alakuljon. A frissítési folyamat lényege:

  • a meglévő végpontok és kulcsok megmaradnak
  • a finomhangolt modellek és állapotok megmaradnak
  • a Foundry funkciói azonnal elérhetővé válnak
  • a fejlesztő továbbra is használhatja az Azure OpenAI API-t

Mindezt lépésről lépésre írja le a frissítési útmutató.

Egy példán keresztül…

Amikor még csak Azure OpenAI-val dolgoztam, előfordult, hogy egy ügyfél Meta vagy Mistral modellt szeretett volna kipróbálni összehasonlításként. Ezt külön rendszerben kellett megoldani.
A Foundry megjelenésével ugyanabban a projektben elérhetővé vált:

  • GPT-típusú modell
  • Mistral
  • Meta
  • DeepSeek
  • és még sok más

Egy projekten belül egyszerre lehet kísérletezni, mérni és értékelni különböző modellek viselkedését.

Mit jelent ez a felhőben dolgozó szakembereknek

A Foundry nem egyszerűen egy új kezelőfelület. A gyakorlati előnyei:

  • Egységes platform, kevesebb különálló eszköz
  • Könnyebb modellválasztás és modellváltás
  • Átláthatóbb üzemeltetés, biztonság és hálózatkezelés
  • Bővíthető modellkínálat
  • Konszolidált fejlesztői élmény és API

A dokumentáció többször hangsúlyozza, hogy a Foundry nemcsak kísérletezésre, hanem üzleti szintű, gyártásra kész alkalmazásokra is alkalmas. Ez a mindennapi munkában is érezhető.

Miért előnyös ez a vállalatoknak

A vállalatok számára a Foundry több szempontból stratégiai előrelépés:

  • Egységes biztonsági és megfelelőségi keretrendszer
  • Több modellgyártó támogatása egy platformon
  • Könnyebb üzemeltetési kontroll
  • Gyorsabb AI-bevezetési ciklus
  • Rugalmasabb fejlesztési irányok

A Foundry megjelenésével a cégek már nem csak egyetlen modellre vagy ökoszisztémára építenek, hanem több szolgáltató képességét is bevonhatják anélkül, hogy töredezett lenne a rendszer.

TulajdonságAzure OpenAIFoundry
Közvetlenül az Azure által értékesített modellekCsak Azure OpenAIAzure OpenAI, Black Forest Labs, DeepSeek, Meta, xAI, Mistral, Microsoft
Partner és Közösség modellek a Marketplace-en keresztül – Stability, Cohere stb.✅
Azure OpenAI API (köteg, tárolt befejezések, finomhangolás, értékelés stb.)✅✅
Ügynökszolgáltatás✅
Azure Foundry API✅
AI-szolgáltatások (beszéd, látás, nyelv, tartalomértés)✅

Összegzés

Az Azure OpenAI Studio jó kiindulási pont volt az Azure AI-képességeinek megismerésére és modellek kipróbálására.

A Microsoft Foundry azonban túlnő ezen a szerepen:
egységes platformot biztosít a teljes AI-fejlesztési életciklushoz, több modellgyártóval és kiterjesztett vállalati funkciókkal.

A Microsoft nem leváltja az Azure OpenAI-t, hanem beépíti egy nagyobb, átfogóbb rendszerbe. Ez a lépés hosszú távon kiszámíthatóbb, hatékonyabb és sokkal rugalmasabb AI-fejlesztést tesz lehetővé.

aws_claude37_deprecation

Claude 3.7 Sonnet kivezetése az AWS Bedrock platformról

, , , , , , , , , ,

| Olvasási idő: 2 perc |

Aki régóta dolgozik AWS-el, mint én is, jól ismeri azokat az értesítéseket, amelyekben a szolgáltató biztonsági vagy karbantartási okokból módosításokat kér az infrastruktúrán. Október végén ismét érkezett egy ilyen e-mail, ezúttal az Amazon Bedrock felhasználóinak címezve. A levélben az Anthropic Claude 3.7 Sonnet modell kivezetéséről (deprecation) értesítik az ügyfeleket.

A Claude 3.7 Sonnet modellt az AWS Bedrockon keresztül sok fejlesztő és szervezet használta az elmúlt hónapokban különféle természetes nyelvi feldolgozási (NLP) és generatív AI feladatokra. Az Anthropic most hivatalosan megkezdte ennek a modellnek a kivezetését, amely több lépcsőben történik.

A legfontosabb dátumok

  • 2026. január 27. – a modell az úgynevezett Extended Access állapotba kerül. Ez a szakasz már nem tartalmaz új kvótanöveléseket, és a támogatás is korlátozott lesz.
  • 2026. április 28. – a modell End-of-Life (EOL) státuszba kerül, vagyis végleg elérhetetlenné válik. Ezt követően minden, a Claude 3.7 Sonnet modell ID-jére küldött kérés automatikusan hibát fog adni.

Érintett régiók

A változás az összes fő Bedrock-régiót érinti, többek között az európai adatközpontokat is (pl. eu-central-1, eu-north-1, eu-west-1, eu-west-3).

  • US-EAST-1
  • US-EAST-2
  • US-WEST-2
  • AP-NORTHEAST-1
  • AP-NORTHEAST-2
  • AP-NORTHEAST-3
  • AP-SOUTH-1
  • AP-SOUTH-2
  • AP-SOUTHEAST-1
  • AP-SOUTHEAST-2
  • EU-CENTRAL-1
  • EU-NORTH-1
  • EU-WEST-1
  • EU-WEST-3

Mit kell tenni?

Az AWS azt javasolja, hogy a felhasználók mielőbb váltsanak az Anthropic Claude Sonnet 4.5 modellre. Ez az új verzió fejlettebb teljesítményt és jobb biztonsági támogatást kínál.

Frissítés lépései az AWS Bedrock konzolon:

  1. Lépj be az Amazon Bedrock konzolra.
  2. A bal oldali menüben válaszd a Model catalog menüpontot.
  3. Keresd meg a Claude 3.7 Sonnet modellt, és jegyezd fel a modellazonosítót (Model ID).
  4. Ezután válaszd ki az új Claude 4.5 Sonnet modellt a listából (Model ID).
  5. A fejlesztői környezetedben (például Python SDK-ban vagy API hívásban) cseréld le a régi modellazonosítót az újra.

A dokumentációkban pontos példák is találhatók, hogyan frissíthető a modell az API-hívásokban vagy SDK-ban. Ezek a Bedrock Model IDs és a Bedrock API Reference oldalon érhetők el.

Összefoglalva

A Claude 3.7 Sonnet kivezetése egy tervezett, fokozatos folyamat, amely 2026 tavaszára zárul le. Akik jelenleg is használják a modellt, érdemes minél előbb átállni a Claude Sonnet 4.5 verzióra, hogy az alkalmazások működése zavartalan maradjon.

gpt5_feature_image

GPT-5 – A gondolkodó mesterséges intelligencia új korszaka

, , , ,

| Olvasási idő: 3 perc |

Többször mutattam már be LLM-eket korábban. A mesterséges intelligencia világában azonban nagyon magas fordulaton pörögnek a dolgok. Ennek megfelelően várható volt, hogy újabb LLM fejlesztés érkezik ezen a nyáron. 2025. augusztus 7-én az OpenAI bemutatta GPT‑5-öt, a legújabb, legfejlettebb mesterséges intelligencia modelljét. Most a GPT‑5 működését, erősségeit, lehetőségeit és korlátait szeretném bemutatni.

Mi az a GPT-5?

A GPT-5 egy olyan mesterséges intelligencia, amely képes automatikusan eldönteni, hogy a gyors válaszokra optimalizált modellt vagy a részletesebb, alaposabb gondolkodást végző („thinking”) modellt használja. A választás valós időben történik, a kérdés bonyolultsága és a felhasználó célja alapján. A GPT-5 mindenki számára elérhető: a Plus és Pro előfizetők nagyobb használati kerettel dolgozhatnak, a Pro csomag előfizetői pedig hozzáférhetnek a fejlettebb „thinking-pro” változathoz is.

Erősségei

  • Széles körű szakértői teljesítmény: kiváló képességekkel rendelkezik kódolásban, matematikában, írásban, egészségügyben és bonyolult feladatokban is.
  • Hatékonyság és racionalitás: gyorsabb válaszokat ad, kevesebb téves információt (hallucinációt), és jobb strukturáltságot nyújt.
  • Fejlett kódolási képességek: a SWE‑bench Verified kódolási teszten 74,9%-os eredményt ért el, szemben az o3 elődjének 69,1%-ával, miközben kevesebb eszközhívást és tokenfogyasztást igényelt OpenAI.
  • Felhasználóbarát működés: az intelligens router rendszer automatikusan kiválasztja a feladatnak legjobban megfelelő modellt, megkönnyítve ezzel a használatot különösen kezdőknek.
  • Integrációk és személyre szabás (Ügynökökkel): Gmail és Google Naptár csatlakozással, valamint személyiségtónus‑beállításokkal bővül a felhasználói élmény.

Lehetőségei

  • Mindenki közelebb az intelligens asszisztenshez: olvasók, értékesítők, pénzügyi szakemberek mind profin kidolgozott tartalmakat generálhatnak, adatokat összefoglalhatnak vagy folyamatokat optimalizálhatnak akár extra előképzettség nélkül.
  • Fejlesztők hatékonyabb eszköze: komplex hibák felismerésére, több lépéses feladatok kezelése, teljes körű fejlesztési folyamatok támogatása.
  • Soknyelvű hozzáférés: nyelvi képességek fejlesztése, így globálisan is szélesebb körben alkalmazható. A magyar nyelvet is tovább csiszolták.

Korlátai

  • Nem általános mesterséges intelligencia (AGI): bár a GPT-5 teljesítménye sok területen egy PhD-szintű szakértőhöz mérhető, nem rendelkezik azzal a képességgel, hogy önállóan, folyamatosan tanuljon és bármilyen feladatot megoldjon, mint egy ember. Ez azt jelenti, hogy a GPT-5 egy rendkívül fejlett eszköz, de nem az a fajta univerzális mesterséges intelligencia, amely minden helyzetben képes emberi szintű gondolkodásra és döntéshozatalra.
  • Teljesítmény-ingadozás: eddigi tapasztalatok alapján az automatikus modellválasztás néha bizonytalan minőséget eredményez.
  • Régebbi modellek korlátozott elérhetősége: GPT‑4 és korábbi modellek már nem állnak a legtöbb felhasználó rendelkezésére, ami szerintem prolémás.
  • Használati korlátok inaktív felhasználóknak: ingyenes felhasználók díjmentes hozzáférést kapnak, de szigorúbb használati korlátokkal kell számolniuk.

Összegzés

A GPT-5 technológiailag kiemelkedően fejlett, mégis időnként meglepően korlátozottnak tűnik, mintha bizonyos helyzetekben gyengébben teljesítene, mint elődei. Tartalmazza a gyors reagálást, a mélyebb gondolkodást, támogat fejlesztőknek és üzleti felhasználóknak egyaránt, miközben a felhasználói élményt helyezi előtérbe. Ugyanakkor fontos szem előtt tartani a jelenlegi korlátokat, mint az AGI hiánya, teljesítmény-ingadozás vagy a régebbi modellek eltűnése.

Érthető az irány, de egyelőre további fejlesztésre szorul az általános mesterséges intelligencia irányába.

chatgpt-codex-highlight

Programozás újragondolva: ChatGPT Codex lépésről lépésre

, , , , , ,

| Olvasási idő: 5 perc |

Mióta megjelent az AI és berobbant a köztudatba, folyamatosan ezt hallani: „Elveszi a munkánkat! Jajj, mi lesz velünk? Nem kellenek programozók!”. Mivel én folyamatosan figyelemmel követem ezt a területet, úgy gondoltam, bármennyire is fejlődik az AI, ettől még nagyon messzire vagyunk.

Erre 2025. májusában bejelentette az OpenAI legújabb eszközét a ChatGPT Codex-et. Ekkor még csak külön hozzáféréssel tudtam tesztelni, azonban júniustól, már bárki számára elérhető.

Tehát az elmúlt időszakban volt alkalmam testközelből megszemlélni ezt a megoldást és azt kell mondjam, hogy hatalmas segítséget kaptak a kezdő programozók és DevOps szakemberek.

Ebben a cikkben megpróbálom átadni a ChatGPT Codex hozadékát és azt, hogy miért mérföldkő ez a programozás területén.

A programozás világába való belépés vagy új nyelvek felfedezése gyakran tűnhet bonyolultnak. Az OpenAI ChatGPT Codex megoldása ezt a belépési küszöböt csökkenti. A Codex egy olyan fejlesztés, amely lehetővé teszi, hogy természetes nyelvű utasításokból programkódot generáljunk, közvetlenül a böngészőben, telepítés nélkül.

Mostantól nem kell telepíteni semmilyen fejlesztőkörnyezetet ahhoz, hogy kipróbálj vagy létrehozz egy egyszerű szkriptet vagy progrmokat. Csak nyisd meg a chatgpt.com/codex oldalt, és kezdj el írni – a Codex pedig kódra fordítja az elképzelésedet.

Miért hasznos?

  • Természetes nyelv alapján is tud kódot írni.
  • Nem szükséges előzetes fejlesztői környezet vagy telepítés.
  • Egyetlen felület a kódolásra, futtatásra és hibakeresésre.
  • Ideális tanuláshoz, prototípusokhoz, kódvázlatokhoz.

Előnyei

  • Egyszerű elérés: csak egy böngésző és internetkapcsolat kell.
  • Multinyelvi támogatás: Python, JavaScript, HTML, CSS, SQL és sok más nyelv is működik.
  • Azonnali visszajelzés: a kódgenerálás és futtatás ugyanazon a felületen történik.
  • Magyarázatra is képes: nemcsak kódot ír, de el is tudja magyarázni, mit csinál az adott kódrészlet.

Hol használható?

A chatgpt.com/codex oldalon belül:

  • Tanulási célokra (pl. „Írj egy Python kódot, amely beolvas egy fáljt”)
  • Webes sablonok vagy HTML/CSS oldalak gyors összeállítására
  • Egyszerű adatbázis-lekérdezések vagy API-hívások kipróbálására
  • Kísérletezésre, új ötletek gyors ellenőrzésére

Miért nagy mérföldkő?

A Codex lehetővé teszi, hogy ne kelljen fejlesztői háttérrel rendelkezned ahhoz, hogy működőképes kódot hozz létre. A korábbi eszközökkel ellentétben itt egy interaktív, kétirányú felületen kommunikálhatsz a modellel: írsz egy szöveget, ő kódot ad – vagy elmagyarázza a meglévőt.

Ez különösen fontos kezdők számára, akik gyakran küzdenek a fejlesztői eszközök bonyolultságával.

Hogyan lehet beállítani?

Nem kell semmit telepítened.

  1. Látogasd meg: https://chatgpt.com/codex
  2. Jelentkezz be OpenAI fiókoddal (ingyenesen is használható).
  3. Válaszd ki a kívánt nyelvet vagy kérd meg, hogy javasoljon.
  4. Írj egy természetes nyelvű utasítást, pl. „Írj egy Python függvényt, ami megmondja, hogy egy szám prímszám-e.”
  5. A Codex automatikusan kódot javasol, amit módosíthatsz, lefuttathatsz, és kérhetsz magyarázatot is hozzá.

Mennyibe kerül?

  • Az alapfunkciók elérhetők a ChatGPT Plus előfizetés keretében.
  • A Codex jelenleg a GPT-4 modellek részeként működik.
  • A ChatGPT Plus előfizetés ára: 8900 Ft/hó
  • Nincs külön díj a Codex funkcióért – ha GPT-4-et használsz, automatikusan elérhető.

Mire alkalmas már most is, és mire nem?

Mire alkalmas:

  • Kód írása természetes nyelvű utasításból
  • Egyszerű szkriptek, algoritmusok generálása
  • Oktatás, példák kipróbálása, tanulás támogatása
  • HTML, CSS, SQL minták készítése

Mire nem ajánlott:

  • Nagy, komplex projektek önálló generálása
  • Biztonságkritikus, validált kód írása emberi átnézés nélkül
  • Teljes alkalmazások generálása tesztelés és kontroll nélkül

GitHub-integráció: automatikus kódmentés Pull Request formájában

És most jön a legjobb rész! A ChatGPT Codex nemcsak arra képes, hogy egy természetes nyelvű utasításból működő kódot hozzon létre – hanem a megírt kódot automatikusan el is tudja küldeni egy GitHub repóba. Ez különösen hasznos azoknak, akik már valamilyen projektet vezetnek, csapatban dolgoznak, vagy szeretnék elmenteni és verziókövetni saját kódgenerálásaikat. Sőt, kezdőknek kimondottan hasznos, hiszen nem csupán a programozást sajátíthatjék el könnyedén, hanem megérthetik, a modern szoftverfejlesztés folyamatait is.

Ehhez a funkcióhoz csak a következőkre van szükséged:

  1. Legyen egy GitHub-fiókod, és hozz létre egy repository-t (vagy használd a meglévőt).
  2. A chatgpt.com/codex felületen a beállításoknál engedélyezd a GitHub-integrációt.
  3. Válaszd ki a célrepo-t és a branchet.
  4. Írj egy természetes nyelvű, szöveges utasítást, például:
    „Készíts egy Python-függvényt, ami eldönti egy számról, hogy prímszám-e, és add hozzá a repository-hoz”
  5. A Codex megírja a kódot, commitol-ja, majd Pull Request-et (kód összefűzési kérést) hoz létre a megadott repository-ban.

Nézd meg a példát itt: https://github.com/cloudsteak/chatgpt-codex

GitHub-integrációs példa lépésekben

Látogasd meg a chatgpt.com/codex oldalt, és válaszd ki az Új környezet létrehozása lehetőséget, majd válaszd ki a repository-dat a listából.

Majd adjuk ki a chat mezőbe az utasítást: „Írj egy Python függvényt, ami megmondja, hogy egy szám prímszám-e.”
Ekkor elkezdődik a kód generálása és amikor kész, el is magyarázza mit csinl a kód.

A kódunk kész és akár ki is próbálhatjuk, vagy módosíthatjuk, kedvünk szerint.

Ha pedig elégedettek vagyunk a végeredménnyel, akkor jöhet a verziókezelt tárolás a GitHub repository-ban. Hogyan? Egyszerűen megkérjük a modelt, hogy: „Add hozzá a repository-hoz a fájlt”

Ugye, hogy semmi külön prompt engineering tudás nem kellett? Mégis ami következik, az szuper. Létrehoz egy új branch-et a módosításokkal, majd létrehoz hozzá egy Pull Request-et is, amit azonnal ellenőrizhetünk a GitHub-on.

Miután ellenőriztük a módosítások helyességét, máris elvégezhetjük a kódbázis összefűzését.

És még a dokumentációt is írathatunk erről a kódról, vagy tetszőlegesen módosíthatjuk a meglévő kódjainkat.

Ez persze csak egy nagyon egyszerű példa volt. A lehetőségeink elég széles spektrumon mozognak. Javaslom, hogy próbáld ki Te is.

Összefoglalás

A ChatGPT Codex új szintre emeli a programozást: szöveges utasításból kódot generál, lefuttatja, megmagyarázza, és ha szeretnéd, automatikusan GitHub repóba menti Pull Request formájában.

Kezdőknek és haladóknak egyaránt hasznos eszköz, akár tanulásra, akár gyors prototípusokra.

Ha még nem próbáltad, itt az ideje kipróbálni!

Látogasd meg a chatgpt.com/codex oldalt, és próbálj ki egy saját példát – vagy
keress meg engem, és szívesen megmutatom, hogyan működik ez a gyakorlatban is.

Load More

Verified by MonsterInsights