Mit jelent kihelyezett mérnöknek lenni az OpenAI-nál?
Mit csinálunk, hogyan dolgozunk, és hogyan oldjuk meg a vállalatok legnehezebb problémáit, hogy valódi eredményt érjünk el.
Szerző: Colin Jarvis, az OpenAI kihelyezett mérnöki csapatának vezetője
Amikor megjelent a Codex, valaki a csapatból megkérdezte tőlem: „Mit teszünk, ha a Codex egyetlen lépésben megoldja azokat a felhasználási eseteket, amelyeken az elmúlt hónapokban dolgoztunk?”
Ez a kérdés rátapint arra, mit jelent kihelyezett mérnöknek lenni az OpenAI-nál. Az ügyfelekkel szorosan együttműködve megértjük a legnehezebb problémáikat, és olyan megoldásokat építünk, amelyekre támaszkodhatnak. Tapasztalataink formálják a termékeinket, és konkrét megoldandó problémákat adnak a kutatócsapatnak.
Ez jelenti az előrelépést. Ha néhány havonta feleslegessé tesszük saját magunkat, akkor a kihelyezett mérnöki csapatunk jól végzi a dolgát.
2025 elején alapítottam a csapatot, hogy áthidaljuk az úgynevezett „bevezetési szakadékot”: a különbséget aközött, amire a modellek látszólag képesek, és amit az emberek megbízhatóan használhatnak a munkájukhoz.
A modellek képességei gyorsabban fejlődtek, mint az alkalmazásukhoz szükséges rendszerek és folyamatok. Néha egy termék a hiányzó láncszem. Máskor a modell jól teljesít egy összehasonlító teszten, de a valós élet változó körülményei és korlátai között nem tudja elvégezni a feladatot.
Az ügyfelek legnehezebb problémáira összpontosítunk. Ahol modelljeink ma is képesek elvégezni a feladatot, ott a termékcsapattal és az ügyféllel együtt dolgozunk a megoldás újraalkalmazhatóságán. Ahol pedig hiányosságok vannak, az ügyfelekkel és a kutatócsapattal közösen tárjuk fel és orvosoljuk őket. Célunk, hogy minden projekt jobb kiindulópontot teremtsen a következő ügyfélnek. Ha annyira megemeljük az alapszintet, hogy legközelebb az ilyen típusú problémák megoldásához ügyfeleinknek már ne legyen szükségük kihelyezett mérnökökre, akkor jól végeztük a munkánkat.
A 200 éves mezőgazdasági vállalat, a John Deere számára az jelentette a kihívást, hogyan tehetné széles körben elérhetővé a gazdálkodóknak nyújtott személyre szabott tanácsadást.
Jó példa erre a See & Spray precíziós gyomirtási technológiájuk, amely kamerák és gépi tanulás segítségével azonosítja és permetezi a gyomokat a teljes szántóföld kezelése helyett, így akár 70%-kal csökkentheti a vegyszerfelhasználást.
Ezek az előnyök azonban csak akkor érvényesülnek, ha a gazdálkodók tudják, hogyan állítsák be a technológiát, tervezzék meg az idényt, és igazítsák módszereiket a változó körülményekhez.
A John Deere az OpenAI API-jait vezette be, hogy személyre szabottan és széles körben tudja biztosítani ezt a támogatást.
Az AI természetes nyelven válaszolhat a gazdálkodók kérdéseire, személyre szabott beállítási útmutatást és ajánlásokat adhat, felismerheti, ha a berendezések nem nyújtják a lehető legjobb teljesítményt, és segíthet megérteni a technológia használatából származó értéket.
A lehetőség túlmutat az egyes beszélgetéseken: a teljes ügyfélút során releváns útmutatást nyújthatunk, hogy a gazdálkodók jobban kihasználhassák berendezéseiket, és hatékonyabban, fenntarthatóbban dolgozhassanak.
Az OpenAI kihelyezett mérnökei ilyen kihívások megoldásán dolgoznak: segítenek a szervezeteknek az AI képességeire olyan rendszereket építeni, amelyek összetett, valós környezetben is gyakorlati értéket teremtenek.
A problémák azonban gyakran teljesen feltáratlanok, előfordulhat, hogy nincs elfogadott viszonyítási alap, és nincs bevált recept sem. Mindenki olyasmit szeretne építeni, ami még sosem létezett. Kevesebben hajlandók megtenni azt, ami ehhez szükséges.
Tehetséges kihelyezett mérnököket találni, miközben folyamatosan emeljük az „elég jó” mércéjét: ez állandó kísérletezést és gyakorlati munkát kívánt.
A kihelyezett mérnöki csapat minden megbeszélésének elején kivetítek egy diát az egyik alapelvünkkel: „Az elérni kívánt eredményből indulj ki, tedd meg, ami a sikerhez kell, majd terjeszd ki a megoldást.”
Egy látványos demóval messzire lehet jutni, mielőtt bárki megkérdezné, hogy a valóságban is működik-e.
A mi feladatunk az ügyfél problémáját olyan színvonalon megoldani, amelyért éles üzemben is vállaljuk a felelősséget.
2025 közepén mintegy 15 kihelyezett mérnökünk dolgozott egy nagy félvezetőipari ügyféllel több mint 10 felhasználási eseten. A cél az volt, hogy ellenőrzési folyamatukat alapjaiban az AI-ra építsék, az alábbi területeken:
Célzott tesztgenerálás
Gyökérok-elemzés és hibakeresés
Architektúratervezési asszisztens
Ebben az iparágban az ellenőrzés a projektre fordított munka mintegy 70%-át is kiteheti. Óriási lehetőség állt előttünk, és sokféle ponton kezdhettük el a munkát.
Néhány kihelyezett mérnök mindössze pár nappal korábban csatlakozott az OpenAI-hoz, és még sosem dolgozott a félvezetőiparban. Beépültek az ügyfél ellenőrzési csapatába, szabadidejükben chiptervezést tanultak, és a mérnökökkel közösen értékelőteszteket készítettek annak vizsgálatára, hogy az AI képes-e hasznos teszteket generálni és helyesen diagnosztizálni a chipek hibáit.
A tanulással párhuzamosan egyedi végrehajtási környezeteket építettünk az egyes felhasználási esetekhez. Az első 3–6 hónapban mindegyik éles üzembe került, és megjelentek az első felhasználóik. Az eredményeket a számok igazolták:
Mintegy 48%-os időmegtakarítás az AI-alapú célzott tesztgenerálással.
22%-os medián teljesítményjavulás a kernelek optimalizálásával.
Hetekig tartó hibakeresés helyett néhány óra
Amikor mindezt bemutattuk, a hardverfejlesztés vezetője megkérdezte: „Mielőtt idejöttetek, chiptervezőként dolgoztatok?”
Kihelyezett mérnökeinknek nem kell már az első napon ismerniük az iparágat, de a megismerése az ő felelősségük.
Ahogy a programozási asszisztensek felgyorsítják a szoftverfejlesztést, úgy válik még fontosabbá az ügyfél üzleti működésének megértése. Csapatainkban széles körű tudású szakemberek és szakterületi specialisták egyaránt helyet kapnak.
Kellő tudásra van szükség a megalapozott döntésekhez, és kellő kíváncsiságra a fennálló helyzettel kapcsolatos feltételezések megkérdőjelezéséhez.
Az élettudományokban például kihelyezett mérnökeink tudományos háttere segít elnyerni azoknak a kutatóknak a bizalmát, akik a preklinikai gyógyszerkutatásban olyan feladatokon dolgoznak, mint a célpontok validálása és rangsorolása, a génexpresszió elemzése vagy a kémiai szintézisutak rekonstruálása. Ez a szakértelem teszi lehetővé, hogy megalapozott javaslatokkal járuljanak hozzá e munkafolyamatok fejlesztéséhez.
Megmutattuk, hogy ezek a munkafolyamatok értéket teremthetnek, de még mindegyik túl sok egyedi integrációt igényelt ahhoz, hogy egy másik csapatnál is alkalmazni lehessen. A következő kihívás az eredmények megőrzése volt, miközben egyszerűbbé tettük a szoftver bevezetését és karbantartását.
Addigra a Codex képességei is bővültek. Az egyik kihelyezett mérnök kipróbálta, hogyan építhetné újra az alkalmazását a Codexre alapozva, majd a csapattal közösen egy Codex-központú, közös végrehajtási környezetbe helyezte át a felhasználási eseteket.
Az egyedi alkalmazások közös Codex-alapelemekre épülő bővítményekké és készségekké váltak. A kezelőfelület szerepét is a Codex vette át, így kivezethettük az egyes felhasználási esetekhez írt külön terminálos és parancssori felületeket.
Minden projektből eltávolíthattuk az egyedi kód nagyjából 90%-át, ami megváltoztatta e munkafolyamatok fejlesztését, karbantartását és kiterjesztését:
Kihasználhattuk a Codex központi fejlesztéseit, így az egyes felhasználási esetekhez kevesebb összekötő kódra volt szükség
A kulcsfunkciókat készségekbe és bővítményekbe csomagoltuk, így könnyebben megoszthattuk őket egymással, az AI-kiválósági központ pedig központilag felügyelhette őket. Így az egyik csapat megoldásának átvétele egy másiknál akár olyan egyszerű is lehetett, mint új csatlakozók vagy MCP-szerverek bekötése, új értékelőtesztek készítése – amire szintén volt készségünk –, majd a rendszer elindítása.
Egy 2026. augusztusi példában az első bevezetés két hónapot vett igénybe. A megoldás kiterjesztése egy második csapatra egy napig tartott. A bővüléssel az újabb csapatok egyre gyorsabban csatlakoztak. Ez azóta is így van: egy 2026. augusztusi felhasználási esetnél az első bevezetés két hónapja után a második csapatnak már egy nap is elég volt.
Ez az egyik módja annak, hogy feleslegessé tegyük saját magunkat. Az éles üzemig vezető munka megmutatta, mi számít igazán. Ahogy az alapul szolgáló termék fejlődött, egyedi megvalósításunk jelentős részét kiválthattuk, miközben megőriztük az általa teremtett értéket.
Ezért számít a sorrend. Az LLM-ekkel gyorsan fejleszthetünk. Ezt a sebességet arra használd, hogy valami értékeset adj a felhasználók kezébe, megtudd, mi állja meg a helyét a gyakorlatban, majd kiterjeszd azt, ami működik.
Ugyanez az elv érvényes minden ügyfélprojektre.
Az OpenAI Presence, a vállalati hang- és chatügynököknek szánt termékünk, valós ügyfelek általi telepítésekből nőtte ki magát. A munka a Swarmmal(új ablakban nyílik meg) kezdődött, és az Agents API segítségével fejlődött ki, és ma egy ügyfél a hívásainak több mint felét mesterséges intelligenciával kezeli.
Az éles környezetben történő megvalósítás során megtanultuk, hogy mely problémák igényelnek egyedi megoldást, és mely építőelemeket használhatják fel más csapatok. Ezeket az építőelemeket beépítettük a Presence-be, megkönnyítve a fejlesztők számára a szabályozott munkafolyamatok automatizálását anélkül, hogy az alapul szolgáló infrastruktúrát újra kellene építeni. Minden egyes bevezetés segített a termék formálásában, és jobb kiindulópontot adott a következő ügyfélnek.
A Thrive Holdings társasággal, az OpenAI FDE-i és kutatói mérnökökkel és könyvelőkkel együttműködve adózási mesterséges intelligenciát fejlesztettek ki a krétai könyvelőcégek számára. A kísérleti program során a Tax AI 7000 adóbevallást dolgozott fel, és körülbelül 50%-kal növelte az áteresztőképességet.
Az egyik legnehezebb kihívás a bérbe adott ingatlanok bevallásának automatizálása volt, amely hat hét mérnöki és szakmai felülvizsgálatot igényelt a 90%-os pontosság és visszakereshetőség eléréséhez. A munka olyan újrafelhasználható mintákat hozott létre, amelyek megkönnyítették a Tax AI kiterjesztését más összetett adótáblázatokra.
A csapatok most ugyanazt a megközelítést alkalmazzák a könyvelésben, az auditban és az informatikai támogatásban – olyan rendszereket építenek, amelyek a szakemberek visszajelzései és a valós használat révén fejlődnek.
Néha egy jobb termék lehetővé teszi, hogy egyszerűsítsük, amit felépítettünk, máskor viszont maga a modell sem képes még elvégezni a feladatot.
Ha csak azt építjük meg, amit a mai modellek már lehetővé tesznek, nem tárjuk fel azokat a képességbeli hiányosságokat, amelyeket a kutatócsapatnak a következőkben meg kell szüntetnie. Ezért számos fontos ügyfélprojektünk éppen ezeknél a korlátoknál kezdődik, és az ügyfél, a kihelyezett mérnökök és a kutatócsapat közösen kötelezi el magát a leküzdésük mellett.
Egy nagy távközlési ügyfelünkkel már kifejlesztettünk egy ügyfélszolgálati platformot, amelyet hangalapú ügyintézésre is ki szerettek volna terjeszteni.
Ügyfélszolgálati forgalmuk mintegy 90%-a hangalapú volt. Ezeket az eseteket költségesebb volt emberi beavatkozás nélkül kezelni, mint a chates megkereséseket. Emellett számos új műszaki kihívást jelentett az akcentusok és a hangnem kezelése, valamint az éles használathoz szükséges válaszidő és pontosság elérése. A sikeres megoldás jelentős üzleti előnyt ígért.
A projekt kereteinek meghatározásakor modellünk körülbelül 60%-ot ért el azokon a kulcsfontosságú értékeléseken, amelyekkel az éles használatra való alkalmasságát mértük. Elértük a képességei határát. Az ügyfélszolgálati helyzetekben javítani kellett a funkcióhívást és az utasításkövetést.
Ezt elmagyaráztuk az ügyfélnek, és bevontuk a kutatócsapatot a munkába. A kihelyezett mérnökök az ügyféllel közösen építették fel a platformot, és határozták meg a modell feladatait. A kutatócsapat a képességbeli hiányosságok megszüntetésén dolgozott; az egymást követő modellverziókkal pedig az ügyfél elvárásaihoz mérhettük a haladást.
Hat hónap alatt a kulcsfontosságú értékeléseken elért eredmény körülbelül 60%-ról 80%-ra, majd 90% fölé emelkedett, elérve az éles használathoz szükséges szintet.
Az így létrejött hangalapú modell ma már ennek az ügyfélnek a rendszerét, más egyedi ügyfélszolgálati rendszereket, valamint a Presence keretében menedzselt rendszereket is támogatja. Az egyik ügyfél működésében felmerült probléma olyan fejlesztési lehetőségekre világított rá, amelyek sok más ügyfélnek is hasznára válhatnak.
Minden hozzájárulás számított. Az ügyfél elkötelezte magát egy olyan probléma megoldása mellett, amelyre a modell még nem volt képes. A kihelyezett mérnökök elég szorosan együttműködtek az ügyféllel ahhoz, hogy pontosan meghatározzák a problémát, felépítsék a platformot, és elejétől a végéig végigvigyék a projektet. A kutatócsapat továbbfejlesztette az alapul szolgáló modell képességeit.
Ez a másik módja annak, hogy feleslegessé tegyük magunkat: segítünk elérni, hogy amit a mai modellek még nem tudnak megoldani, arra a jövő modelljei már képesek legyenek. Munkánk hozadéka túlmutat az egy-egy ügyféllel töltött órákon.
Azért csatlakoztam az OpenAI-hoz, hogy segítsek hasznossá tenni az AI-t az emberek mindennapi munkájában. Ma is ez vezérli a csapatot. Gyakran mondom a csapatnak, hogy az LLM-fejlesztésben többnyire érvényesül Occam borotvájának elve: a legegyszerűbb megoldás a legjobb. Egy élvonalbeli kutatásairól ismert vállalatnál, egy túlzó állításokkal terhelt iparágban mi olyan dolgokat akarunk építeni, amelyek megbízhatóan működnek, és amelyekre a gyakorlati szakemberek támaszkodhatnak.
A cél az, hogy minden projekt jobbá tegye azt, ami utána következik: könnyebben bevezethető terméket, nehezebb feladatokra képes modellt vagy kevesebb egyedi fejlesztést a következő ügyfél számára.
Ha van egy nehéz problémád, amelyet szeretnél megoldani, örömmel dolgozunk veled. Ha szívesen segítenél ilyen problémák megoldásában, örömmel látunk a csapatban.
Mit teszünk tehát, amikor a Codex már el tudja végezni azt a munkát, amelynek megoldásán hónapokig dolgoztunk?
Keresünk egy nehezebb problémát.
