Mida tähendab kliendijuurutuse inseneri töö OpenAI-s
Mida me teeme, kuidas töötame ja kuidas lahendame ettevõtete keerulisimaid probleeme, et saavutada tegelik mõju.
Autor: Colin Jarvis, OpenAI kliendijuurutuse inseneritöö juht
Kui Codex välja tuli, küsis üks tiimiliige minult: „Mida me teeme siis, kui Codex suudab ühe katsega lahendada kasutusjuhtumid, mille kallal oleme viimased kuud töötanud?“
See küsimus tabab täpselt kliendijuurutuse inseneri töö olemust OpenAI-s. Töötame kõrvuti klientidega, et mõista nende kõige keerulisemaid probleeme ja luua lahendusi, millele nad saavad toetuda. Õpitu aitab kujundada meie tooteid ja annab teadustiimile konkreetseid probleeme, mida lahendada.
See ongi edasiminek. Kui muudame end iga paari kuu tagant tarbetuks, teeb meie kliendijuurutuse inseneride tiim oma tööd hästi.
Asutasin tiimi 2025. aasta alguses, et ületada see, mida nimetame „juurutuslõheks“: erinevus mudelite näilise võimekuse ja selle vahel, mida inimesed saavad oma töös usaldusväärselt kasutada.
Mudelite võimekus on arenenud kiiremini kui selle rakendamiseks vajalikud süsteemid ja protsessid. Mõnikord on puudu sobiv toode. Mõnikord saab mudel võrdlustestis hea tulemuse, kuid ei tule toime tegeliku elu muutujate ja piirangutega.
Keskendume klientide kõige keerulisematele probleemidele. Kui meie mudelid saavad ülesandega juba täna hakkama, töötame koos tootetiimi ja kliendiga selle nimel, et lahendus oleks korratav. Kui mudelite võimekusest jääb puudu, määratleme koos klientide ja teadustiimiga lünga ning teeme vajalikud täiustused. Meie eesmärk on, et iga koostööprojekt annaks järgmisele kliendile parema lähtepositsiooni. Kui tõstame baastaseme nii kõrgele, et kliendid ei vaja järgmisel korral sama tüüpi probleemi lahendamiseks kliendijuurutuse insenere, oleme oma tööd hästi teinud.
200-aastase põllumajandusettevõtte John Deere ees seisis küsimus, kuidas pakkuda põllumeestele personaalset nõu suuremas mahus.
Üks näide on nende umbrohu täppistõrjetehnoloogia See & Spray, mis kasutab kaameraid ja masinõpet umbrohu tuvastamiseks ning pritsimiseks kogu põllu töötlemise asemel, vähendades kemikaalide kasutust kuni 70%.
Sellest kasu saamiseks peavad põllumehed aga oskama tehnoloogiat seadistada, hooaega kavandada ja töövõtteid muutuvate oludega kohandada.
John Deere võttis kasutusele OpenAI API-d, et muuta selline tugi personaalseks ja skaleeritavaks.
Tehisintellekt saab vastata põllumeeste küsimustele loomulikus keeles, anda kohandatud seadistusjuhiseid ja soovitusi, tuvastada olukordi, kus seadmete potentsiaal võib jääda täielikult kasutamata, ning aidata põllumeestel mõista tehnoloogiast saadavat kasu.
Võimalused ei piirdu üksiku suhtluskorraga: asjakohast nõu saab pakkuda kogu klienditeekonna vältel, aidates põllumeestel seadmeid paremini kasutada ning suurendada tõhusust ja kestlikkust.
Just selliseid probleeme lahendavad OpenAI kliendijuurutuse insenerid: nad aitavad organisatsioonidel jõuda tehisintellekti võimalustest süsteemideni, mis loovad keerulistes päriskeskkondades praktilist väärtust.
Sageli on aga probleemidel palju võimalikke lahendusi, puududa võib kindel võrdlusalus ning valmis tegevusjuhist pole. Kõik tahavad luua midagi, mida pole varem olemas olnud. Vähem on neid, kes tahavad teha kõik selleks vajaliku.
Andekate kliendijuurutuse inseneride leidmine ja samal ajal „piisavalt hea“ taseme tõstmine on nõudnud pidevat katsetamist ning õpitu rakendamist.
Iga kliendijuurutuse inseneride tiimikohtumise alguses näitan slaidi ühe põhiväärtusega: „Lähtu tulemusest, tee edu saavutamiseks kõik vajalik ja seejärel laienda kasutust.“
Muljetavaldava demoga võib jõuda üsna kaugele, enne kui keegi küsib, kas see ka päriselus töötab.
Meie ülesanne on lahendada kliendi probleem tasemel, mille eest saame ka tootmiskeskkonnas vastutada.
2025. aasta keskel töötas umbes 15 meie kliendijuurutuse inseneri koos suure pooljuhtide tootjast kliendiga enam kui kümne kasutusjuhtumi kallal. Eesmärk oli kujundada nende verifitseerimisprotsess algusest peale tehisintellektile toetuvaks, hõlmates järgmist:
Suunatud testide genereerimine
Algpõhjuste analüüs ja silumine
Arhitektuuriassistent
Selles valdkonnas võib verifitseerimine moodustada ligikaudu 70% projekti töömahust. Võimalik kasu oli tohutu ja alustada võinuks paljudest kohtadest.
Mõned kliendijuurutuse insenerid olid OpenAI-ga liitunud vaid mõni päev varem ega olnud kunagi pooljuhtide valdkonnas töötanud. Nad asusid tööle kliendi verifitseerimistiimi koosseisus, õppisid vabal ajal kiipide projekteerimist ning koostasid koos inseneridega hindamisteste, et kontrollida, kas tehisintellekt suudab genereerida kasulikke teste ja õigesti diagnoosida kiipide rikkeid.
Õppimise kõrval ehitasime igale kasutusjuhtumile kohandatud täitmiskeskkonna. Esimese 3–6 kuuga jõudsid kõik lahendused tootmiskeskkonda ja esimeste kasutajateni. Töö tasus end ära, kui nägime mõõdikuid:
Ligikaudu 48% ajasäästu tänu tehisintellektipõhisele suunatud testide genereerimisele.
Jõudluse mediaanparanemine 22% tänu tuumade optimeerimisele.
Nädalatepikkune silumistöö sai tehtud tundidega
Kui me kõigest sellest ülevaate andsime, küsis riistvarajuht: „Kas te töötasite enne siia tulekut kiibidisaineritena?“
Meie kliendijuurutuse insenerid ei pea valdkonda tundma esimesest päevast, kuid nende kohustus on see endale selgeks teha.
Kuna programmeerimisassistendid kiirendavad tarkvara loomist, muutub kliendi äri mõistmine veelgi olulisemaks. Koostame tiimid nii laia profiiliga spetsialistidest kui ka valdkonnaekspertidest.
Vaja on piisavalt teadmisi, et teha põhjendatud otsuseid, ja piisavalt uudishimu, et seada kahtluse alla senise töökorralduse eeldused.
Näiteks bioteadustes aitab meie kliendijuurutuse inseneride teadustaust võita usaldust teadlaste seas, kes tegelevad prekliinilises ravimiarenduses sihtmärkide valideerimise ja prioriseerimise, geeniekspressiooni analüüsi ning keemiliste sünteesiradade rekonstrueerimisega. Need erialateadmised võimaldavad neil anda põhjendatud hinnanguid selle kohta, kuidas töövooge parandada.
Olime näidanud, et need töövood võivad luua väärtust, kuid igaühe kasutuse laiendamine teise tiimi nõudis endiselt liiga palju kohandatud integratsioonitööd. Järgmine ülesanne oli säilitada saavutatud tulemused, muutes samal ajal tarkvara juurutamise ja hooldamise lihtsamaks.
Selleks ajaks oli Codex muutunud võimekamaks. Üks kliendijuurutuse insener proovis oma rakendust selle ümber ehitada ning viis seejärel koos tiimiga kasutusjuhtumid ühisesse täitmiskeskkonda, mille keskmes oli Codex.
Eraldi kohandatud rakendustest said Codexi ühistele baaskomponentidele tuginevad pluginad ja oskused. Codexist sai ka kasutajaliides, mis võimaldas meil loobuda üksikute kasutusjuhtumite jaoks kirjutatud eraldi terminali- ja käsurealiidestest.
Saime igast projektist eemaldada ligikaudu 90% kohandatud koodist ning see muutis viisi, kuidas neid töövooge lõime, hooldasime ja nende kasutust laiendasime:
Saime kasu Codexi kesksetest täiustustest, vähendades iga kasutusjuhtumi jaoks vajaliku ühenduskoodi mahtu
Põhifunktsioonid koondati oskusteks ja pluginateks, mida oli lihtsam omavahel jagada ning tehisintellekti kompetentsikeskusest keskselt hallata. See tähendas, et lahenduse laiendamiseks ühest tiimist järgmisse võis piisata uute konnektorite või MCP-serverite kasutuselevõtust, uute hindamistestide loomisest (mille jaoks oli meil samuti oskus) ja käivitamisest.
Ühes 2026. aasta augusti näites võttis esmane juurutus aega kaks kuud. Lahenduse laiendamine teisele tiimile võttis ühe päeva. Kasutuse laienedes said järgmised tiimid kiiremini alustada. See suundumus on jätkunud: 2026. aasta augustis kulus ühe kasutusjuhtumi juurutamiseks teises tiimis üks päev, kuigi esmane juurutus oli võtnud kaks kuud.
See on üks viis, kuidas end tarbetuks muuta. Tootmiskeskkonda jõudmiseks tehtud töö näitas, mis on oluline. Alustoote paranedes saime suure osa oma kohandatud teostusest välja vahetada, säilitades selle loodud väärtuse.
Seepärast ongi järjekord oluline. LLM-id võimaldavad meil kiiresti arendada. Kasuta seda kiirust, et anda kasutajatele midagi väärtuslikku, õppida, mis praktikas toimib, ja seejärel toimiva lahenduse kasutust laiendada.
Sama põhimõte kehtib kõigis koostööprojektides.
OpenAI Presence, meie toode ettevõtete kõne- ja vestlusagentidele, kasvas välja reaalsete klientide juurutustest. Töö algas Swarmiga(avaneb uues aknas) ja arenes edasi Agents API kaudu ning tänaseks tegeleb üks klient enam kui poole oma kõnedest tehisintellekti abil.
Nende juurutuste tootmisse viimine õpetas meile, millised probleemid vajasid kohandatud lahendust ja milliseid ehitusplokke teised meeskonnad saaksid kasutada. Tõime need ehitusplokid Presence'i, muutes arendajatel reguleeritud töövoogude automatiseerimise lihtsamaks ilma alusinfrastruktuuri uuesti üles ehitamata. Iga juurutamine aitas toodet kujundada ja andis järgmisele kliendile parema lähtepunkti.
Koos Thrive Holdings , OpenAI FDE-d ja teadlased töötasid koos inseneride ja raamatupidajatega, et luua Crete’i raamatupidamisfirmadele Tax AI. Pilootprojekti ajal töötles Tax AI 7000 maksudeklaratsiooni ja suurendas läbilaskevõimet umbes 50%.
Üks raskemaid väljakutseid oli üürikinnisvara deklaratsioonide automatiseerimine. Et saavutada nii täpsuses kui ka saagises 90% tase, kulus kuus nädalat inseneritööd ja praktikute tehtud ülevaatusi. Töö tulemusena loodi korduvkasutatavad mustrid, mis hõlbustasid Tax AI kasutuse laiendamist teistele keerukatele maksudeklaratsiooni lisavormidele.
Meeskonnad rakendavad nüüd sama lähenemisviisi raamatupidamisele, auditeerimisele ja IT-toele – luues süsteeme, mis täiustuvad praktikute tagasiside ja reaalse kasutamise kaudu.
Mõnikord võimaldab parem toode meie loodut lihtsustada, kuid mõnikord ei suuda mudel ise veel ülesannet täita.
Kui ehitame ainult seda, mida tänased mudelid juba võimaldavad, ei avasta me võimekuslünki, mida teadustiim peab järgmisena kõrvaldama. Seetõttu saavad paljud meie olulised koostööprojektid alguse just neist piiridest ning klient, kliendijuurutuse insener ja teadustiim pühenduvad nende ühisele ületamisele.
Olime koos suure telekommunikatsiooniettevõttest kliendiga juba välja töötanud klienditeenindusplatvormi ning nad soovisid laiendada seda häälkõnedele.
Häälkõned moodustasid umbes 90% nende klienditeeninduse mahust. Nende pöördumiste lahendamine teenindajale suunamata oli kulukam kui vestluses ning tõi kaasa uusi tehnilisi raskusi: aktsentide mõistmine, hääletoon, viivitus ja täpsus tuli viia päriskasutuseks vajalikule tasemele. Õnnestumise korral oleks sellel nende ärile märkimisväärne mõju.
Töö ulatust määratledes saavutas meie mudel umbes 60% peamistes hindamistestides, millega kontrollisime selle sobivust päriskasutuseks. Olime jõudnud selle võimete piirini. Klienditeenindusolukordades tuli parandada funktsiooni kutsumist ja juhiste järgimist.
Selgitasime seda kliendile ja kaasasime töösse teadustiimi. Kliendijuurutuse insener töötas koos kliendiga platvormi välja ja määratles, mida mudel peab suutma teha. Teadustiim töötas võimekuslünkade kõrvaldamise nimel ning mudeli järjestikused versioonid võimaldasid meil kontrollida edusamme kliendi nõuete alusel.
Kuue kuuga paranesid peamiste hindamistestide tulemused umbes 60%-lt 80%-le ja seejärel üle 90%, jõudes päriskasutuseks vajalikule tasemele.
Nii loodud kõnemudel on nüüd aluseks selle kliendi lahendusele, teistele kohandatud klienditeeninduslahendustele ja Presence’i kaudu hallatavatele juurutustele. Ühe kliendi äritegevuses ilmnenud probleem aitas leida täiustusi, millest võivad kasu saada paljud teised.
Iga osa oli oluline. Klient pühendus probleemile, mida mudel ei suutnud veel lahendada. Kliendijuurutuse insener tegi kliendiga piisavalt tihedat koostööd, et probleem sõnastada, platvorm välja töötada ja projekti algusest lõpuni vedada. Teadustiim parandas aluseks oleva mudeli võimekust.
See on teine viis end tarbetuks muuta: aidata jõuda probleemist, mida tänased mudelid ei suuda lahendada, võimekuseni, mida tulevased mudelid pakuvad. Meie tööst saadav kasu ulatub kaugemale tundidest, mille veedame ühe kliendiga.
Liitusin OpenAI-ga, et aidata muuta tehisintellekt inimeste igapäevatöös kasulikuks. See eesmärk juhib tiimi endiselt. Ütlen tiimile sageli, et LLM-ide arenduses kehtib enamasti Ockhami habemenuga: kõige lihtsam lahendus on parim. Töötame ettevõttes, mida iseloomustab eesrindlik teadustöö, ja valdkonnas, mille mainet rikuvad liialdused. Meie tahame luua töökindlaid lahendusi, millele praktikud saavad toetuda.
Eesmärk on, et iga koostööprojekt muudaks järgneva paremaks: toodet oleks lihtsam juurutada, mudel saaks hakkama keerulisema ülesandega või järgmine klient vajaks vähem kohandustööd.
Kui sul on keeruline probleem, mida soovid lahendada, teeme sinuga hea meelega koostööd. Kui soovid aidata neid probleeme lahendada, ootame sind meiega liituma.
Mida me siis teeme, kui Codex saab hakkama tööga, mille jaoks me kuude kaupa lahendust ehitasime?
Leiame järgmise, keerulisema probleemi.
