Néhány hete készítettem egy rövid videót azoknak, akik most ismerkednek a Google Cloud-ökoszisztémával vagy a Geminivel, mert azt tapasztalom, hogy sokan itt akadnak el már az első lépésnél. Pedig ennél egyszerűbb dolog nem is lehetne.
Az első lépések nem egyszerűek, de itt más a helyzet: az ember azt hiszi, hogy a Google AI-hoz és a Google Cloudhoz külön-külön fiókokat kell létrehoznia. Ez nem igaz. Egy meglévő Gmail-fiók pontosan elég ahhoz, hogy az egész ökoszisztémát bejárd.
Négy URL, egy fiók
A videóban négy belépési pontot mutatok meg, mindegyiket ugyanazzal az e-mail-címmel:
Ez a négy hely gyakorlatilag lefedi a Google AI és Cloud ökoszisztémájának egészét. Nincs itt semmi extra regisztráció, nincs elveszett jelszó egy külön fejlesztői fiókhoz, nincs felesleges adminisztráció.
Miért fontos ez?
Aki most vág bele a felhő vagy az AI világába, annak az első akadály gyakran nem technikai, hanem szervezési: hova is kattintsak, melyik fiókkal, melyik felületen. Ha ez az első lépés egyszerű, sokkal nagyobb eséllyel megy tovább valaki a következőre is. Ez pontosan az a simplicity-elv, amit enterprise környezetben is vallok: előbb működjön egyszerűen, utána lehet bővíteni.
Mielőtt megnézed
Ha eddig azt hitted, hogy a Google Cloud vagy a Gemini kipróbálásához külön fiókra vagy bonyolult regisztrációra van szükséged, a videó pontosan azt mutatja meg, hogy ez nem így van. Egy fiók, négy URL, és már úton is vagy a felhő és az AI világába.
Van abban valami különösen jó érzés, amikor az ember nemcsak tanul valamit, hanem közben érzi is, hogy a korábbi tudása elkezd jobban összeállni. Mint tudjátok, idén egy olyan kihívást adtam magamnak, hogy az év első felében minden hónapban leteszek egy felhős vagy AI-hoz kapcsolódó vizsgát. Nem azért, mert a tanúsítvány önmagában mindent megold, hanem azért, mert szerettem volna újra és újra megmérettetni magam a nagy felhőszolgáltatók világában. Ezzel is inspirálni azokat, akik évek óta tanulnak, hogy időnként mérettessék meg magukat.
Februárban a Google Generative AI Leader vizsgára esett a választás. Ez logikus lépés volt, mert az AI-val már több mint három éve foglalkozom mélyebben, természetesen a cloud mellett. Márciusban jött az Azure AI-900, amely szintén sikeres lett. Áprilisban pedig következett az AWS Certified AI Practitioner, vagyis az AIF-C01 vizsga. Ezt is sikeresen teljesítettem.
Őszintén bevallom, hogy a három közül ezt élveztem a legjobban.
Nem mély technikai vizsga, de nem is üres elmélet
Az AWS Certified AI Practitioner nem fejlesztői vagy mély machine learning vizsga. Nem kell modelleket kódolni, nem kell ML pipeline-t építeni, és nem kell matematikai részletekben elveszni. Ettől viszont még nem nevezném könnyűnek.
A vizsga hivatalos leírása szerint az AIF-C01 célja, hogy igazolja az AI, ML, generative AI fogalmak, az AWS AI eszközök, a felelős AI használat, valamint a security, compliance és governance alapvető ismeretét. Ez nekem nagyon szimpatikus irány, mert pontosan erre van szüksége sok cégnek is: nem mindenki akar modellt tréningezni, de egyre több embernek kell értenie, mire jó az AI, mikor hasznos, mikor kockázatos, és milyen szolgáltatásokkal lehet elindulni.
A vizsga szerintem azoknak különösen hasznos, akik cloud, data, governance, security vagy üzleti technológiai irányból közelítenek az AI felé. Kezdőknek is jó lehet, de csak akkor, ha nem csak vizsgakérdéseket magolnak, hanem tényleg megértik az alapfogalmakat.
Ami miatt az AWS AI világa különösen izgalmas
A felkészülés közben újra feltűnt, mennyire sokféle AI szolgáltatás létezik AWS-en belül. Nem csak az Amazon Bedrockról van szó, bár kétségtelenül ez az egyik legfontosabb szolgáltatás a generative AI alkalmazások építéséhez.
Érdemes ismerni például az Amazon SageMaker AI-t, ha valaki modellek építésével, tanításával vagy deploymenttel foglalkozna a gépi tanulás világában (ML). Ott van az Amazon Q Business és az Amazon Q Developer, amelyek már sokkal inkább a vállalati tudás, fejlesztői munka és produktivitás irányából érdekesek. Az Amazon Nova az AWS saját foundation model családja. Az Amazon BedrockAgentCore és a Strands Agents SDK pedig már az agentic AI világ felé mutat.
És akkor még nem beszéltünk az olyan érdekesebb irányokról, mint az AWS Health AI Hub, amely az egészségügyi AI megoldásokra koncentrál, vagy az AI Stylist demó, amely jól megmutatja, hogyan lehet generative AI-t kiskereskedelmi vállalkozások és személyre szabott ajánlások köré építeni. A PartyRock pedig egy nagyon jó játszótér azoknak, akik kódolás nélkül szeretnének generative AI app-okat kipróbálni.
Miért volt ez nekem ennyire hasznos?
A legnagyobb értéke számomra az volt, hogy rendszerezte a korábbi tudásomat. Az AI világában nagyon könnyű elveszni a modellek, agentek, RAG megoldások, embeddingek, governance kérdések és platformszolgáltatások között. Ez a vizsga segíthet mindenkinek újra átlátni, melyik építőkocka mire való.
A felkészüléshez YouTube-on is találhatók ingyenes tananyagok vagy az Udemy-n fizetős képzések, de én azt javaslom, hogy senki ne csak egy forrásból készüljön. Érdemes mellé megnézni a hivatalos AWS exam guide-ot, az AWS Skill Builder anyagokat, és közben kipróbálni legalább néhány szolgáltatást. Nem kell mindent mélyen konfigurálni. Első körben bőven elég megérteni, mire való az Amazon Bedrock, hogyan illeszkedik ide a SageMaker AI, és milyen problémákra adnak gyors választ a purpose-built AI szolgáltatások. Ez utóbbira van már képzésem is a Mentor Klubnál.
Én nagyon élveztem a felkészülést, és maga a vizsga is jó élmény volt. Ha jól emlékszem, hamar végeztem. Ez nem azt jelenti, hogy minden kérdés triviális volt, hanem azt, hogy az elmúlt évek tapasztalata és a felkészülés alatt sikerült annyira összerakni a képet, hogy magabiztosan tudtam haladni.
Mi jön ezután?
Megvan ez a vizsgám is, és ennek nagyon örülök. Most már mindegyik felhő-szolgáltatónál sikerrel megmérettettem magam.
Májusban egy Google tanúsítvány megújítása következik. Erről is írni fogok, utána viszont egy rövid szünetet tartok a vizsgák világában. Ennek nagyon jó oka van: felkérést kaptam hat (6) AI képzés elkészítésére a Mentor Klubnál, és most erre szeretnék fókuszálni.
Hogy az AI mely területét fedik le ezek a képzések, az legyen egyelőre titok. Annyit azonban szívesen elárulok, hogy mindegyik a Google Cloud és a Gemini világába segít elmélyedni.
Tehát a cloud-os képzéseim mellett már az Mesterséges Intelligencia világába is elkalauzollak, ha tagja vagy a Mentor Klubnak.
Ha te is most ismerkedsz az AI és a cloud világával, szerintem az AWS Certified AI Practitioner jó irány lehet. Nem azért, mert ettől valaki azonnal AI architect lesz, hanem azért, mert segít tisztábban látni. Márpedig ma ez óriási érték, mert hamar el lehet veszni a hatalmas zajban.
Ha érdekelnek a felhős és AI-os tanulási utak, érdemes követned a következő bejegyzéseket is, mert hamarosan jön a Google tanúsítvány megújításának története, utána pedig még több gyakorlati AI és Cloud téma. Ugye Te is várod már?
Még az év első felében hallhattad a videómban, hogy miért jó a Google Cloud. Ebben a videóban röviden összefoglaltam a legfontosabb dolgokat. Említettem, hogy a Google, mint AI-first cég, már nagyon régen használ mesterséges intelligenciát a mindennapi működése során. Ennek ellenére, még mindig csak a harmadik „nagy” felhő-szolgáltató az AWS és az Azure mögött.
Már akkor is azt mondtam, hogy náluk az AI lehet az a pont, ahol van lehetőségük a kiugrásra és a felzárkózásra. Úgy tűnik, ők is így gondolják és most tettek efelé egy lépést.
Nem feltétlenül forradalmi dologra kell gondolni, inkább amolyan „rájöttünk, hogy hogyan kell pozícionálnunk magunkat” lépésre.
Aki régóta dolgozik cloud platformokkal, az már megszokhatta, hogy a nagy szolgáltatók időnként újracímkéznek egy-egy terméket, finomhangolják a portfóliót, aztán megy tovább az élet. Ami viszont 2026. április 22-én a Google Cloud Next konferencián történt, az ennél kicsivel több: a Google Cloud egyszerre nevezte át az egyik legismertebb AI-platformját valamint több adat- és analitikai termékét is, és közben egy új gondolkodásmódot is bevezetett.
Mi változott a néven?
A legfontosabb bejelentés: a Vertex AI Platform beleolvad egy nagyobb ernyőbe, aminek a neve Gemini Enterprise Agent Platform. A hivatalos közlés szerint ez a Vertex AI evolúciója, és mostantól minden Vertex AI szolgáltatás és új fejlesztés ezen a platformon keresztül érhető el, önálló szolgáltatásként nem.
Emellett a Data Analytics oldalon több termék is beszédesebb nevet kapott. A Dataplex Universal Catalog mostantól Knowledge Catalog. A BigLake új neve Lakehouse. A Dataproc mostantól Managed Service for Apache Spark. A Composer új neve Managed Service for Apache Airflow. A Looker Studio pedig Data Studio néven fut tovább.
Ez elsőre soknak tűnhet, de van egy jó hír: a nevek logikája egyszerűbb lett. A „Managed Service for Apache Spark” önmagában elárulja, hogy egy felügyelt Spark szolgáltatásról van szó. Nem kell kitalálnod, mit takar a „Dataproc” márkanév. Ez különösen segít azoknak, akik most ismerkednek a GCP világával, és eddig a saját termékneveket kellett bemagolniuk.
Régi név
Új név
Mit takar?
Vertex AI Platform
Gemini Enterprise Agent Platform
A Google Cloud AI-platformja, mostantól agent-fókusszal: építés, skálázás, kormányzás, optimalizálás egy ernyő alatt
Dataplex Universal Catalog
Knowledge Catalog
Központi adatkatalógus és governance réteg, amely átláthatóvá teszi, hol milyen adat található és ki férhet hozzá
BigLake
Lakehouse
Egységes tárolási réteg a data lake és data warehouse világ között, nyílt formátumokkal
Dataproc
Managed Service for Apache Spark
Menedzselt Spark környezet nagy adatmennyiségek feldolgozásához, klaszterkezelés nélkül
Composer
Managed Service for Apache Airflow
Menedzselt Airflow szolgáltatás data pipeline-ok ütemezésére és orchestrálására
Looker Studio
Data Studio
Vizualizációs és riportkészítő eszköz dashboardokhoz és adatmegjelenítéshez
Ebből a táblázatból kiolvasható, az egy tudatos iránymutatás a Google részéről. Az AI-platform nevében megjelenik a Gemini és az Agent szó, ami egyértelműen kijelöli, merre megy a termékstratégia. A Data Analytics oldalon pedig a saját márkanevek helyett leíró, iparági szabvány szerinti elnevezések kerültek előtérbe: Spark, Airflow, Lakehouse. Ez sokak számára hasznos, mert ezek a fogalmak más cloudokban és on-premise világban is ugyanezt jelentik.
Mi marad változatlan?
A Google Cloud kommunikációja ebben a kérdésben egyértelmű: a projektjeid, a konfigurációk és az árazás nem változik. A számlázásod ugyanúgy fut tovább, és a meglévő elmentett linkek automatikus átirányítással működnek a konzolon belül. Az SKU megjelenítési nevek és leírások ugyan frissülnek a következő hónapokban, de a Data Analytics SKU-k nevei változatlanok maradnak.
Ez fontos üzenet: Egy enterprise ügyfél számára a legnagyobb kockázat nem egy új név, hanem ha egy átnevezés mögött rejtett árváltozás vagy kényszerű migráció áll. Itt most nem ez a helyzet. Mégis azt tanácsolom, hogy ha céges környezetben dolgozol, érdemes átfésülni a belső dokumentációt, runbook-okat és oktatási anyagokat, mert a kollégák fél év múlva már az új neveken fogják keresni ezeket a szolgáltatásokat.
Miért Agent Platform?
A Gemini Enterprise Agent Platform neve nem véletlen. A Google Cloud hivatalos bejelentése szerint a platform négy fő képességre épül: Build, Scale, Govern és Optimize. Olyan komponensek tartoznak ide, mint az Agent Studio a low-code építéshez, az Agent Development Kit a kódalapú fejlesztéshez, az Agent Runtime a futtatáshoz, a Memory Bank a hosszú távú kontextushoz, valamint az Agent Identity, Agent Registry és Agent Gateway a kormányzáshoz.
Mit is jelentenek ezek?
Build: az agentek felépítése, legyen szó low-code vizuális eszközről (Agent Studio) vagy kódalapú fejlesztésről (Agent Development Kit).
Scale: az agentek futtatása éles környezetben, stabil teljesítménnyel, hosszú távú kontextussal és memóriakezeléssel (Agent Runtime, Memory Bank).
Govern: az agentek felügyelete: minden agent saját azonosítót kap, központi regiszterbe kerül, és egységes biztonsági szabályok mentén működik (Agent Identity, Agent Registry, Agent Gateway).
Optimize: az agentek viselkedésének mérése és finomhangolása éles forgalom alapján, tesztekkel, megfigyelhetőséggel és automatikus javaslatokkal (Agent Simulation, Agent Evaluation, Agent Observability).
Hogy ez mit jelent a gyakorlatban, arra mondok egy egyszerű példát:
Képzelj el egy biztosítót, amelynél egy AI-agent fogadja az ügyféligényeket, lekérdezi a belső rendszereket, majd ha kell, átad egy másik agentnek, aki a kárrendezést indítja el. Eddig ehhez sok külön eszközt kellett összedrótozni. Az Agent Platform ígérete az, hogy ezek egy közös platformon, egységes identitással, auditálhatóan és biztonsági kontrollokkal futnak. Azt, hogy ez a gyakorlatban minden környezetben problémamentesen működik-e, még nem tudom biztosan, de a koncepció iránya egyértelmű: az egyedi AI-feladatoktól haladni egy kormányzott agent-ökoszisztéma felé.
Hogyan illeszkedik ez a többi cloudhoz?
Érdemes megnézni, mit csinálnak a nagy versenytársak. Az AWS-nél a Bedrock és az Amazon Q köré épül az agentek világa, az Azure-nál pedig az Azure AI Foundry és a Microsoft Copilot Studio vonal adja a hasonló irányt. Mindhárom szereplő ugyanabba az irányba megy: nem elég egy jó modell, szükség van futtatókörnyezetre, identitáskezelésre, megfigyelhetőségre és governance-re.
Ez karriertervezés szempontjából is fontos jelzés. Ha most lépsz be a cloud vagy AI világába, ne csak a modellekkel és a prompttal foglalkozz. Sokkal értékesebb tudás, ha érted, hogyan kell egy agentet biztonságosan integrálni egy vállalati környezetbe, hogyan figyeli a csapat a működését, és hogyan kontrollálja a költségeit.
Hasznos tippek a folytatáshoz
Ahogy a hagyományos cloud workloadok esetén, az AI-agenteknél is ugyanazok a hibák jönnek elő, amelyeket sok cégnél elrontanak. Az első klasszikus csapda a tervezés nélküli használat: valaki elindít egy agentet teszteléshez, aztán elfelejti leállítani, és hónapokig fut a háttérben. Ez ugyanaz a történet, mint amikor egy fejlesztői VM-et nem állítanak le éjszakára, és a hónap végén megérkezik a meglepetés a számlán.
A második ilyen a governance hiánya. Ha bárki szabadon hozhat létre agenteket, saját jogosultságokkal, saját eszközökkel, akkor hamar ott állsz egy átláthatatlan ökoszisztéma közepén. Pontosan ezért emeli ki a Google az Agent Identity és az Agent Registry szerepét: minden agentnek legyen azonosítója, és legyen egy központi hely, ahol látható, mi fut, milyen jogosultsággal.
A harmadik terület a biztonsági alapok kihagyása. A legtöbb startup jellegű projektben érthetően először az a cél, hogy egyáltalán működjön valami. Ez rendben is van, a simplicity elv szerint először legyen egy működő megoldás. De még mielőtt élesbe kerülne, érdemes átgondolni a legalapvetőbb kérdéseket: milyen adatokhoz fér hozzá az agent, ki láthatja a logokat, és mi történik hiba esetén.
Záró gondolatok
Három gondolatot szeretnék ezzel átadni neked. Az első: ne memorizálj szolgáltatásneveket, inkább értsd meg a mögöttes fogalmakat és összefüggéseket. Egy felügyelt Spark szolgáltatás az AWS-en EMR, a Google Cloud-on Managed Service for Apache Spark, és az Azure-on Synapse vagy Fabric környezetben találsz hasonlót. A fogalom ugyanaz, a csomagolás más. (Erről hamarosan majd közzé is teszek egy interaktív szótárat.)
A második: a költségtudatosság sosem megy ki a divatból. Minden új agent, minden új adatpipeline pénzbe kerül, és a leggyakoribb hiba, hogy ezt csak utólag vesszük észre. Váljon szokásoddá, hogy minden erőforráshoz hozzágondolod a kérdést: mit kapcsoljak ki, ha nem használom?
A harmadik: a jövőállóság nem jóslás, hanem kíváncsiság. Nem tudjuk pontosan, merre megy a piac öt év múlva, de azt látjuk, hogy az agent-alapú világ egyre több felületen jelenik meg. Aki most megérti a governance, az identity és az observability szerepét, az bármelyik platformon könnyen átül.
Habár a név megváltozott, de a tanulság a régi: a Cloud-ban és az AI-ban nem feltétlenül az nyer, aki a leggyorsabban vág bele, hanem aki tudatosan építkezik.
Korábban már beszéltem az Azure-ről és az AWS-ről, mint lehetséges felhőplatformról 2026-ban. Ebben a videóban a Google Cloud Platformot (GCP) mutatom be, ami egy AI-first szemléletű felhő.
Az AI-first stratégia lényege, hogy a Google a mesterséges intelligenciát tette minden terméke és szolgáltatása alapvető mozgatórugójává, így az már nem csak egy extra funkció, hanem az elsődleges fejlesztési szempont. Ez a szemléletmód a felhasználóhoz alkalmazkodó, segítőkész technológiát és saját, specifikus hardveres infrastruktúrát (például TPU-kat) állít a cég teljes működésének középpontjába.
A Google Cloud egyik legnagyobb erőssége, hogy itt az AI nem kiegészítő, hanem alapértelmezett része a platformnak. A videóban szó lesz a Gemini modellcsaládról, a Vertex AI-ról, az adatplatformok szerepéről, és arról is, hogy kinek lehet jó választás a GCP.
Azt is elmondom, mikor nem ideális a Google Cloud, például klasszikus enterprise lift-and-shift megközelítés esetén.
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 KlubosAzure oktatásaim során rendszeresen bemutatom a klasszikus „Enterprise Chat” felépítést:
Feltöltünk fájlokat egy Azure Storage Account-ra.
Létrehozunk egy Azure AI Search indexet.
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.
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?
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)
Másold be a feldolgozni kívánt fájljaidat az input mappába (PDF, DOCX, XLSX, HTML, PPTX).
Futtasd újra az uv run docling-rag-converter.py parancsot.
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:
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.
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.
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:
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.
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ág
Azure OpenAI
Foundry
Közvetlenül az Azure által értékesített modellek
Csak Azure OpenAI
Azure 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.)
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é.
Eddig is úgy gondoltam, hogy az Amazon S3 a világ legjobb felhő tárolási megoldása, hiszen olyan széleskörűen, egyszerűen és költséghatékonyan használható, hogy azzal magasan lekörözi versenytársait.
Teszi ezt úgy, hogy az AI megjelenésével továbbra is az egyik legszélesebb körben használható tárolási megoldás maradt. Az Amazon azonban nem elégedett meg ezzel, hanem tovább dolgozott és nemrég be is jelentették, hogy az Amazon S3 mostantól natívan támogatja a vektorokat.
Ez nem csupán egy egyszerű frissítés, hanem egy komoly lépés afelé, hogy az AI-alapú keresések és alkalmazások még gyorsabbak és hatékonyabbak legyenek, ráadásul közvetlenül ott, ahol az adatokat tároljuk: az S3-ban.
Mi is az az Amazon S3 Vector?
Az Amazon S3 Vector egy új lehetőség arra, hogy vektorokat – azaz gépi tanulási modellekből származó tömörített adatreprezentációkat – natívan tároljak és kereshetővé tegyek az S3-ban. Korábban, ha például képeket, szövegeket vagy videókat szerettem volna hasonlóság alapján keresni, az adataimat először külön vektor adatbázisba kellett töltenem (pl. Weaviate), ahol a hasonlóságkeresést elvégezhettem. Mostantól ez közvetlenül az S3-ban is elérhető.
Ez hatalmas előrelépés – nemcsak egyszerűsíti az architektúrát, hanem csökkenti a késleltetést, az összetettséget és a költségeket is.
Vector Store (vektortár) – Ebbe töltöm fel a vektorokat és a hozzájuk tartozó metainformációkat.
Ingest API – Ezen keresztül adhatom meg a vektorokat és az indexelendő adatokat.
Query API – Ezzel tudok hasonlóság alapján keresni (pl. „melyik képek hasonlítanak erre a képre?”)
Minden vektor egy rekord részeként kerül be, amely lehetővé teszi, hogy ne csak vektor alapján, hanem metaadatok szerint is tudjak szűrni, például dátum, fájltípus vagy címke alapján.
Példák a használatra
1. Dokumentumkeresés
Egy nagy mennyiségű belső dokumentumot tartalmazó gyűjteményben szerettem volna hasonló jelentésű dokumentumokat megtalálni. Ahelyett, hogy kulcsszavas keresést használtam volna, minden dokumentumhoz vektort generáltam egy nyelvi modell segítségével, és azokat töltöttem fel az S3 Vectorba.
Ezután egy új keresés során elég volt megadnom egy kérdést vagy egy rövid szövegrészletet – és az S3 azonnal visszaadta azokat a dokumentumokat, amelyek a legjobban illeszkedtek a jelentésük alapján.
2. Képalapú hasonlóságkeresés
Egy e-kereskedelmi oldalon képek alapján szerettem volna hasonló termékeket ajánlani. A termékfotókat vektorizáltam egy gépi látás modell segítségével, majd betöltöttem az S3 Vectorba. Így amikor egy vásárló feltöltött egy képet, a rendszer pillanatok alatt megtalálta a hozzá leginkább hasonlító termékeket – anélkül, hogy külön vektor-adatbázist kellett volna karbantartanom.
Miben más ez, mint a meglévő megoldások?
A legtöbb vektoros keresési rendszer eddig úgy működött, hogy külön adatbázist kellett használni (pl. Pinecone, Weaviate, FAISS, Qdrant). Ez viszont újabb infrastruktúrát, szinkronizációs feladatokat és összetettebb architektúrát igényelt. Az Amazon S3 Vector ezt az egészet leegyszerűsíti: egy helyen tárolom és keresem az adatokat.
Azt is kiemelném, hogy mivel az S3 Vector az Express One Zone megoldásra épül, ezért alacsony késleltetésű hozzáférést kapok – mindezt az S3 skálázhatóságával és megbízhatóságával együtt.
Korlátok és tudnivalók
Természetesen nem minden esetben ez a legjobb megoldás. A jelenlegi verzió:
csak az S3 Express One Zone-on keresztül működik,
maximum 250 kB méretű rekordokat támogat,
és előzetes (preview) státuszban van, így még nem éles környezetbe szánt végleges termék.
A vektorok betöltéséhez és a keresésekhez is REST API-t használhatok, de egyelőre nincs közvetlen AWS konzolos támogatás.
Mikor érdemes használni?
Én akkor fogom választani az S3 Vector-t, ha:
már eleve S3-ban tárolok adatokat (képeket, szövegeket),
AI-alapú hasonlóságkeresésre van szükségem,
és szeretném leegyszerűsíteni az architektúrát, elkerülve a külön vektor-adatbázisokat.
Összegzés
Az Amazon S3 Vector egy fontos mérföldkő a natív, felhőalapú AI-alkalmazások területén. Ha te is vektoros keresést építenél, és az adataid már most is S3-ban vannak, akkor ez egy kiváló lehetőség arra, hogy gyorsan és hatékonyan vezess be intelligens keresési képességeket – közvetlenül a tárhelyeden.
Ha szeretnél még többet megtudni, akkor becsatolom ide a hivatalos blog cikket.
Én biztosan tesztelek vele a következő AI-projektem során. Ha te is érdeklődsz a hasonló technológiák iránt, most érdemes elkezdeni a kísérletezést.
A generatív mesterséges intelligencia világában már nem csak az számít, milyen nagy egy modell vagy hány milliárd paramétere van. Az is legalább ennyire fontos, hogyan tudjuk kiegészíteni és finomítani a modell működését. Korábban írtam a Retrieval-Augmented Generation (RAG) működéséről és előnyeiről. Most egy viszonylag új, de egyre nagyobb figyelmet kapó megközelítésről írok: ez a Cache-Augmented Generation (CAG).
Ebben a cikkben bemutatom, mit jelent a CAG, hogyan működik, miben más, mint a RAG, és mikor érdemes egyik vagy másik módszert választani.
Hogyan jutottunk el a RAG-tól a CAG-ig?
Amikor a nagy nyelvi modellek (LLM-ek) elterjedtek, hamar kiderült, hogy zárt tudású modellekkel nem tudjuk tartani a lépést a világ gyorsan változó információival. Ez hívta életre a RAG koncepcióját, ahol a modell a válasz előtt külső forrásokból (pl. céges dokumentumtárból, tudásbázisból) keres információt, és ezt beemeli a generálásba.
A RAG tehát egyfajta „keresés + válasz” kombinációt jelentett.
Később azonban új kihívások merültek fel:
nőtt a felhasználói igény a valós idejű válaszadásra,
sok rendszerben ismétlődő kérdések jelentkeztek,
és a RAG-es lekérdezések nem mindig voltak költséghatékonyak.
Ez vezetett el a Cache-Augmented Generation (CAG) gondolatához: ha egyszer már válaszoltunk valamire, miért ne tárolnánk el?
Mi az a Cache-Augmented Generation (CAG)?
A CAG lényege, hogy a generatív modell működését nem külső dokumentumokkal támogatjuk meg (mint a RAG esetén), hanem egy belső gyorsítótárra (cache) építünk, amely korábbi válaszokat vagy tudáselemeket tárol. Ez a cache lehet előre feltöltött (pl. sablonos kérdésekre adott válaszokkal), vagy dinamikusan épülhet ki a felhasználók aktivitása alapján.
A CAG technikai alapjai – amit érdemes tudni
A modern CAG-rendszerek több trükköt is bevetnek a hatékonyság növeléséhez:
Előzetes betöltés (Preloading) a kontextusablakba – a modell „látóterébe” már előre bekerül a fontos tudásanyag.
KV-cache (Key-Value Cache) – a modell tárolja a korábban generált tokenekhez tartozó rejtett állapotokat, így újrahasznosíthatók.
Hasonlóság-alapú visszakeresés – a rendszer nemcsak azonos promptokra reagál, hanem felismeri a jelentésbeli hasonlóságokat is.
Hogyan különbözik a CAG a RAG-től?
A RAG működéséhez elengedhetetlen egy jól strukturált tudásbázis. A modell először lekérdezi a számára releváns dokumentumokat, majd ezek alapján alkot választ. Ezzel szemben a CAG nem keres semmit, hanem a saját „emlékezetére” támaszkodik.
Szempont
RAG
CAG
Tudásforrás
Külső (pl. dokumentumok, adatbázis)
Belső (cache, előre betöltött tudás)
Teljesítmény (sebesség)
Lassabb a keresés miatt
Nagyon gyors, különösen ismétlődő kérdésekre
Erőforrásigény
Magasabb
Alacsonyabb
Pontosság friss információnál
Magas (aktuális tudás elérhető)
Korlátozott (nincs frissítés automatikusan)
Ideális alkalmazás
Dokumentumkereső, intelligens asszisztens
Ügyfélszolgálat, chatbot, sablonos válaszok
Valós példák RAG és CAG alkalmazásra
RAG példa: Képzeld el, hogy van egy cég belső dokumentumtára, ahol a HR, pénzügy és IT leírások PDF-ben elérhetők. Ha egy dolgozó megkérdezi: „Hány nap szabadság jár 3 év munkaviszony után?”, a RAG-alapú asszisztens lekérdezi a vonatkozó HR-dokumentumot, beemeli a szövegbe, és ennek alapján ad választ.
CAG példa: Ugyanez a dolgozó hetente ötször kérdezi meg: „Hogyan tudom megváltoztatni a jelszavam?” – a rendszer ezt a kérdést egyszer már megválaszolta. A CAG gyorsítótára felismeri az ismétlődést, és azonnal visszaadja a korábbi választ, teljes generálás nélkül.
RAG + CAG együtt
Egy ideig úgy tekintettünk a RAG és a CAG módszerekre, mint egymással versengő megoldásokra. Én viszont azt tapasztalom, hogy nem kizárják, hanem épp kiegészítik egymást.
Egy modern AI rendszer például működhet így:
Első lépés: a rendszer megvizsgálja, van-e releváns találat a cache-ben (CAG).
Ha nincs megfelelő találat, akkor lekérdez egy külső tudásbázist (RAG) és generál egy új választ.
Ez az új válasz eltárolódik a cache-ben, így legközelebb már gyorsabban és olcsóbban elérhető.
Ez a lépcsőzetes logika optimalizálja az erőforrás-használatot, miközben nem mond le sem a sebességről, sem a pontosságról.
Én úgy látom, hogy a jövő generatív rendszerei ezt a kettős stratégiát fogják követni: a CAG biztosítja a gyorsaságot és kiszámíthatóságot, míg a RAG gondoskodik a mély, megalapozott válaszokról. A kettő együtt nemcsak hatékonyabbá teszi a rendszert, hanem javítja a felhasználói élményt is.
Mely AI modellek használják ezeket?
RAG-et használ:
OpenAI GPT + retrieveres példák (pl. ChatGPT Enterprise tudásbázis integráció)
Mistral nyílt forrású LLM-ek kontextusablakos gyors betöltéssel
GPT-4 Turbo – optimalizált KV-cache rendszerrel működik, nagy prompt ismétlések esetén gyorsabb válasz
Claude 3 (Anthropic) – cache-szerű belső rejtett állapotkezelést használ kontextuson belül
Egyes cégek saját implementációi (pl. HelpDesk-rendszerek belső cache-sel)
Összefoglalás
A CAG nem egy újabb buzzword – hanem egy valódi válasz a generatív AI rendszerek skálázhatósági és sebességbeli kihívásaira. A RAG továbbra is verhetetlen, ha friss, kontextusban gazdag válaszokra van szükség. A CAG viszont ott nyer, ahol gyorsaság, egyszerűség és alacsony költség a cél.
Én egyre gyakrabban építek be CAG-alapú logikát a prototípusaimba, főleg akkor, ha nagy felhasználószámra kell tervezni. Ha pedig RAG-re van szükség, már tudom, mikor és hogyan érdemes bevetni.
A jövő generatív rendszerei nem választanak egyet a kettő közül – hanem dinamikusan kombinálják őket.
Előző cikkemben bemutattam az RAG alapjait, koncepcióját és főbb összetevőit. Amint olvashattuk a Retrieval-Augmented Generation (RAG) egyedülálló ereje abban rejlik, hogy képes releváns dokumentumokból és adatforrásokból valós időben információt visszanyerni és azt integrálni generált válaszaiba.
Abban a cikkben is említettem, hogy a RAG célja az, hogy az AI modellek ne csak logikus és összefüggő válaszokat adjanak, hanem azokat a legfrissebb és legpontosabb információk alapján állítsák elő. Ez különösen hasznos olyan területeken, ahol az adatok gyorsan változnak, például jogi, pénzügyi vagy technológiai területeken. Emellett olyan esetekben előnyös, amikor fontos számunkra az adatok pontossága. (pl.: AI alapú keresés dokumentum tárakban)
Ez a cikk a RAG-hoz kapcsolódó dokumentumkezelési technológiákra fókuszál, amelyek kulcsszerepet játszanak a rendszer hatékonyságában és pontosságában. Úgy érzem, hogy ez az a terület, ahol jelenleg a legkevesebb zaj van az AI világán belül.
Vektor adatbázisok
A vektor adatbázisok (dokumentumtárak) a RAG alapvető elemei. Ezek olyan adatbázisok, amelyekben a dokumentumokat és az azokban lévő információkat numerikus vektorokként tárolják. Ez lehetővé teszi a gyors és pontos keresést a releváns tartalmak között, a következő módon:
Dokumentumok átalakítása (embedding): A dokumentumok tartalmát vektorrá (számmá) alakítjuk természetes nyelvi feldolgozó modellek, például BERT vagy más embedding modellek segítségével.
Keresés (search): Egy új kérdés esetén a rendszer szintén vektort generál, majd ezt összehasonlítja az adatbázisban lévő vektorokkal, hogy megtalálja a releváns dokumentumokat.
Ebből is látszik, hogy amikor ilyen keresést végzünk, akkor nem kulcsszavakra keresünk, hanem összehasonlítást végzünk, így a találatok pontossága is más jellegű lesz.
Az embedding technológiák a RAG rendszerek motorjai. Az embedding lépésben a szöveges adatokat numerikus vektorokká alakítják, amelyek tartalmazzák a szöveg jelentését és kontextusát. Ez kulcsfontosságú a hasonlósági kereséshez, amely a releváns információk megtalálásának egyik alapvető eszköze.
Példa: Egy orvosi dokumentumtárban a „szívritmuszavar” kifejezés numerikus vektora alapján a rendszer az összes releváns tanulmányt és cikket előkeresheti.
Modellek: Olyan nyílt forráskódú modellek, mint a Sentence-BERT vagy a Hugging Face embedding modelljei, széles körben használatosak a RAG rendszerekben.
Újrarangsorolás (Reranking)
A RAG rendszerek gyakran több releváns dokumentumot is visszakeresnek, amelyeket rangsorolni kell. Az újrarangsorolás célja, hogy a leginkább releváns dokumentumok kerüljenek at LLM elé. Ez különösen fontos nagy méretű dokumentumtárak esetén.
Példa: Egy ügyfélszolgálati alkalmazás esetén a rendszer kiemeli a legfrissebb dokumentumokat a relevancia növelése érdekében. Vagy az első körben összegyűjtött információhalmazt tovább finomítjuk, hogy valóban csak a legrelevánsabb találatokat adjuk vissza a felhasználónak.
A lekérdezés fordítási technikák olyan lépések sorozatát foglalják magukban, amelyek javítják a lekérdezés átalakítás (embedding) és a dokumentum átalakítás közötti relevancia valószínűségét. Ez a folyamat biztosítja, hogy a kérdések pontosabban illeszkedjenek a dokumentumokhoz, javítva ezzel a visszakeresés és a válaszgenerálás minőségét.
Néhány kapcsolódó technika:
Szemantikai illeszkedés javítása: A technikák közé tartozik a szemantikai keresés alkalmazása, amely figyelembe veszi a szavak jelentését és kontextusát, nem csupán a szintaktikai egyezéseket. Ez különösen fontos a természetes nyelvű lekérdezések esetében, ahol a felhasználók különböző módon fogalmazhatják meg ugyanazt a kérést.
Lekérdezés elemzése és finomítása: A felhasználói kérdések gyakran többértelműek lehetnek. Ezen technikák célja, hogy ezeket a lekérdezéseket pontosítsák, szinonimákat vagy kapcsolódó kifejezéseket azonosítsanak, és szükség esetén a lekérdezést újrafogalmazzák a relevancia növelése érdekében.
Átalakítás (embedding) optimalizálása: A lekérdezéseket és a dokumentumokat numerikus vektorokká alakítják, és a lekérdezés fordítás során a cél az, hogy a lekérdezés embedding minél közelebb kerüljön a releváns dokumentumok beágyazásaihoz a vektortérben, ezáltal növelve a releváns találatok valószínűségét.
Ezen kívül még vannak egyéb technikák is, amelyeket majd a konkrét példáknál ismertetek.
Miért fontosak ezek a technológiák?
A dokumentumkezelési technológiák integrálása kulcsfontosságú a RAG rendszerek sikeréhez. Ezek az eszközök biztosítják a pontos, releváns és gyors információ-visszakeresést, ami elengedhetetlen a magas színvonalú generált válaszokhoz. Az olyan területeken, mint az egészségügy, a pénzügyek és az oktatás, ezek a technológiák forradalmasíthatják az adatokhoz való hozzáférést.
A RAG rendszerek és a dokumentumkezelési technológiák folyamatos fejlődése lehetővé teszi, hogy az AI rendszerek egyre intelligensebbé és hatékonyabbá váljanak. Ahogy ezek az eszközök egyre jobban integrálódnak a mindennapi életbe, várhatóan tovább növelik a mesterséges intelligencia alkalmazási lehetőségeit.
A jobb érthetőség kedvéért, hamarosan konkrét megoldásokkal is jelentkezem ebben a témában. 🙂
Talán már unalmasan hangzik, de ezt a cikket is így kell kezdenem. A mesterséges intelligencia (AI) gyors fejlődése során egyre több olyan technológia és módszertan jelenik meg, amely segít az információk hatékonyabb feldolgozásában és a felhasználók igényeinek pontosabb kielégítésében. Az egyik ilyen technológia a Retrieval-Augmented Generation (röviden RAG), amely az AI világának egy izgalmas területe. Számomra is ez jelenleg az egyik legérdekesebb terület.
RAG Alapok: Mi is az a Retrieval-Augmented Generation?
A RAG technológia lehetővé teszi, hogy a mesterséges intelligencia rendszerek pontosabb, tényszerűbb és relevánsabb válaszokat adjanak különböző kérdésekre, mivel képesek valós időben külső forrásokból származó információkat integrálni a működésükbe. Ezzel minimalizálva az AI egyik sajátosságát a hallucinációt. Emelett egy AI-al erősített dokumentumkezelést valósíthatunk meg.
A generatív mesterséges intelligencia (Generative AI), mint például a GPT modellek, kiválóan alkalmasak a természetes nyelvű szövegek előállítására. Azonban ezek a modellek kizárólag az előzetes tanulás során betáplált adatok alapján dolgoznak, amelyek idővel elavulhatnak. Itt jön képbe a RAG, amely kiegészíti a generatív képességeket azáltal, hogy valós idejű információk kinyerését is lehetővé teszi. Ez különösen fontos az olyan helyzetekben, amikor az aktuális vagy változó információk elérése létfontosságú.
Mi a koncepció?
A Retrieval-Augmented Generation egy olyan technika, amely két különböző, de egymást kiegészítő AI-komponenst ötvöz: az információ-visszakeresést (retrieval) és a szövegalkotást (generation). Ez a megközelítés a következőképpen működik:
Kérdés: A felhasználó egy kérdést tesz fel vagy egy információs kérést küld a rendszernek. Ezt a prompt engineering technikájával valósítja meg.
Információ-visszakeresés: A RAG rendszer első lépésként külső adatforrásokban (pl.: adatbázisokban, dokumentumtárakban vagy weboldalakon) keres releváns adatokat a kérdés megválaszolásához.
Adatok integrálása: Az így összegyűjtött adatokat továbbítja a generatív modellhez (LLM), amely ezek alapján állítja elő a választ.
Válasz generálása: A generatív modell egy koherens, természetes nyelvű választ ad, amely tartalmazza a visszakeresett információkat.
A RAG célja tehát az, hogy az AI modellek ne csak logikus és összefüggő válaszokat adjanak, hanem azokat a legfrissebb és legpontosabb információk alapján állítsák elő. Ez különösen hasznos olyan területeken, ahol az adatok gyorsan változnak, például jogi, pénzügyi vagy technológiai területeken. Emellett olyan esetekben előnyös, amikor fontos számunkra az adatok pontossága. (pl.: AI alapú keresés dokumentum tárakban)
A RAG alapvető komponensei
Habár a RAG egyszerű szolgáltatásnak tűnik, szükséges a fontosabb komponensek ismerete, amely segít megérteni és helyesen használni azt.
Retrieval modul: Ez az a rész, amely az adatok kinyeréséért felelős. A modell egy külső forrásból, például egy vektoradatbázisból, dokumentumtárból vagy más adattárolóból keres ki releváns információkat.
Generációs modul: Ez a generatív nyelvi modell, amely a kinyert adatokat felhasználva állítja elő a választ. Példa lehet erre a GPT-4 vagy más LLM-ek.
Integrációs réteg: Ez köti össze a két modult, biztosítva, hogy a kinyert adatok megfelelő formátumban és kontextusban kerüljenek a generációs modell elé.
Fontos megjegyezni, hogy a generatív modulnál a nyelvi modell (LLM) nem feltétlenül egy nyilvános kell hogy legyen. Tehát nem kell olyan modellt használnunk, amely internet kapcsolattal rendelkezik. Ez azért fontos nekünk, mert így egy teljesen zárt, izolált és biztonságos dokumentum kezelést is megvalósíthatunk a cégünkön belül.
Hogyan kapcsolódik a RAG az AI világához?
Ez ez érdekes kérdés lehet, annak ellenére, hogy az AI-ról beszélve említjük ezt a technológiát. A RAG technológia közvetlenül megoldja az AI egyik legnagyobb problémáját: naprakész információk kezelésére. Míg a hagyományos nyelvi modellek (LLM-ek) az előzetes tanulásuk során szerzett ismeretekre támaszkodnak, a RAG lehetőséget ad a valós idejű információk integrálására. Ez kulcsfontosságú olyan területeken, mint:
Ügyfélszolgálat: Releváns és aktuális válaszok biztosítása a vállalati dokumentációk és szabályzatok alapján.
Orvosi kutatás: Legfrissebb tudományos eredmények integrálása a diagnózis támogatásába.
Oktatás: Pontos, hiteles válaszok nyújtása a tananyagok alapján az aktuális technológia területén.
Miért fontos a RAG?
A RAG technológia jelentősége abban rejlik, hogy egyesíti a generatív modellek kreativitását és a tényszerű adatok pontosságát. Ezáltal képes olyan megoldásokat nyújtani, amelyek nemcsak modernek, hanem hitelesek is. A jövőben a RAG szerepe várhatóan tovább növekszik, különösen az olyan iparágakban, ahol az információk megbízhatósága és aktualitása kulcsfontosságú.
A RAG valódi ereje a dokumentum kezelésben rejlik, amelyről a következő cikkben olvashattok majd.
