Ką „OpenAI“ reiškia tiesioginio diegimo inžinierių darbas
Ką darome, kaip dirbame ir kaip sprendžiame sunkiausias įmonių problemas, kad pasiektume apčiuopiamų rezultatų.
Autorius: Colin Jarvis, „OpenAI“ tiesioginio diegimo inžinerijos vadovas
Kai pasirodė „Codex“, vienas komandos narys manęs paklausė: „Ką darysime, kai „Codex“ vienu bandymu galės įgyvendinti tai, ką kūrėme pastaruosius kelis mėnesius?“
Šis klausimas atskleidžia pačią tiesioginio diegimo inžinierių darbo „OpenAI“ esmę. Dirbame kartu su klientais, kad suprastume sunkiausias jų problemas ir sukurtume sprendimus, kuriais jie galėtų pasikliauti. Įgytos žinios padeda formuoti mūsų produktus ir suteikia tyrimų komandai konkrečių spręstinų problemų.
Tai ir yra pažanga. Jei kas porą mėnesių pasiekiame, kad mūsų ankstesnės pagalbos nebereikėtų, vadinasi, mūsų tiesioginio diegimo inžinierių komanda atlieka savo darbą.
Komandą subūriau 2025 m. pradžioje, kad įveiktume tai, ką vadiname „diegimo atotrūkiu“: skirtumą tarp to, ką modeliai, regis, geba, ir to, kuo žmonės gali patikimai naudotis savo darbe.
Modelių galimybės plėtėsi greičiau nei sistemos ir procesai, reikalingi joms panaudoti. Kartais trūkstama grandis yra produktas. Kartais modelis gerai pasirodo lyginamajame teste, tačiau nesugeba atlikti darbo susidūręs su realiomis kintančiomis sąlygomis ir apribojimais.
Daugiausia dėmesio skiriame sunkiausioms klientų problemoms. Kai mūsų modeliai jau gali atlikti užduotį, kartu su produktų komanda ir klientu siekiame, kad sprendimą būtų galima pritaikyti pakartotinai. Kai modelių galimybių nepakanka, kartu su klientais ir tyrimų komanda apibrėžiame spragą ir ieškome patobulinimų. Siekiame, kad kiekvienas projektas suteiktų kitam klientui geresnį atspirties tašką. Jei bazinį lygį pakeliame tiek, kad kitą kartą tokiai problemai išspręsti klientams nebereikia tiesioginio diegimo inžinierių, savo darbą atlikome gerai.
200 metų veikianti žemės ūkio sektoriaus įmonė „John Deere“ susidūrė su iššūkiu: kaip teikti individualizuotas konsultacijas vis daugiau ūkininkų.
Vienas pavyzdžių – tiksliosios piktžolių kontrolės technologija „See & Spray“. Pasitelkdama kameras ir mašininį mokymąsi, ji atpažįsta bei purškia piktžoles, o ne visą lauką, todėl cheminių medžiagų naudojimą galima sumažinti iki 70 %.
Tačiau norėdami pasinaudoti šiais pranašumais, ūkininkai turi žinoti, kaip sukonfigūruoti technologiją, suplanuoti sezoną ir pritaikyti darbo metodus keičiantis sąlygoms.
„John Deere“ įdiegė „OpenAI“ API, kad šią pagalbą būtų galima individualizuoti ir teikti didesniu mastu.
DI gali atsakyti į ūkininkų klausimus natūralia kalba, teikti individualias konfigūravimo instrukcijas ir rekomendacijas, nustatyti, kada išnaudojamos ne visos įrangos galimybės, ir padėti ūkininkams suprasti technologijos teikiamą vertę.
Galimybės neapsiriboja pavienėmis konsultacijomis: aktualias rekomendacijas galima teikti visais bendradarbiavimo su klientu etapais, padedant ūkininkams geriau išnaudoti įrangą, didinti efektyvumą ir ūkininkauti tvariau.
Būtent tokius iššūkius sprendžia „OpenAI“ tiesioginio diegimo inžinieriai: padeda organizacijoms DI galimybes paversti sistemomis, kurios teikia praktinę vertę sudėtingomis realiomis sąlygomis.
Tačiau problemos dažnai būna menkai apibrėžtos, gali nebūti patvirtintų atskaitos duomenų ar patikrintos veiksmų sekos. Visi nori sukurti tai, ko dar niekada nebuvo. Mažiau kas nori padaryti viską, ko tam reikia.
Ieškant talentingų tiesioginio diegimo inžinierių ir kartu keliant „pakankamai gero“ rezultato kartelę, tenka nuolat eksperimentuoti ir išbandyti idėjas praktiškai.
Kiekvieno tiesioginio diegimo inžinierių komandos susitikimo pradžioje parodau skaidrę su vienu pagrindiniu principu: „Pradėkite nuo siekiamo rezultato, darykite tai, ko reikia sėkmei, ir tada plėskite mastą“.
Įspūdinga demonstracija gali sulaukti daug dėmesio, kol kas nors paklaus, ar sprendimas veikia realiomis sąlygomis.
Mūsų darbas – išspręsti kliento problemą taip, kad galėtume užtikrintai atsakyti už sprendimo veikimą realioje aplinkoje.
2025 m. viduryje apie 15 mūsų tiesioginio diegimo inžinierių kartu su stambiu puslaidininkių sektoriaus klientu dirbo prie daugiau nei 10 taikymo atvejų. Siekėme, kad DI taptų jo verifikavimo proceso pagrindu, apimančiu:
Tikslinių testų generavimą
Pagrindinių priežasčių analizę ir klaidų šalinimą
Architektūros asistentą
Šiame sektoriuje verifikavimas gali sudaryti apie 70 % visų projekto darbo sąnaudų. Potencialas buvo milžiniškas, o pradėti buvo galima nuo daugybės sričių.
Kai kurie tiesioginio diegimo inžinieriai prie „OpenAI“ buvo prisijungę vos prieš kelias dienas ir niekada nebuvo dirbę puslaidininkių sektoriuje. Jie įsiliejo į kliento verifikavimo komandą, laisvalaikiu mokėsi lustų projektavimo ir kartu su inžinieriais kūrė vertinimo testus, kad patikrintų, ar DI gali generuoti naudingus testus ir teisingai diagnozuoti lustų gedimus.
Kartu su šiuo mokymosi procesu kūrėme atskiriems taikymo atvejams pritaikytą infrastruktūrą. Per pirmuosius 3–6 mėnesius visi šie sprendimai buvo įdiegti realioje aplinkoje ir sulaukė pirmųjų naudotojų. Darbo naudą atskleidė rodikliai:
DI pagrįstas tikslinių testų generavimas sutaupė apie 48 % laiko.
Optimizavus branduolius, našumo pagerėjimo mediana siekė 22 %.
Klaidų šalinimas, trukęs savaites, sutrumpėjo iki valandų
Kai pristatėme visus rezultatus, už aparatinę įrangą atsakingas vadovas paklausė: „Ar prieš atvykdami čia dirbote lustų projektuotojais?“
Mūsų tiesioginio diegimo inžinieriai neprivalo išmanyti sektoriaus nuo pirmos dienos, tačiau privalo jį perprasti.
Programavimo asistentams spartinant programinės įrangos kūrimą, suprasti kliento verslą tampa dar svarbiau. Komandas sudarome iš plataus profilio specialistų ir konkrečių sričių ekspertų.
Reikia pakankamai žinių pagrįstiems sprendimams priimti ir pakankamai smalsumo, kad suabejotumėte įprastą tvarką palaikančiomis prielaidomis.
Pavyzdžiui, gyvybės mokslų srityje mūsų tiesioginio diegimo inžinierių mokslinis pasirengimas padeda pelnyti tyrėjų pasitikėjimą. Šie tyrėjai atlieka ikiklinikinės vaistų paieškos užduotis: patvirtina taikinius ir nustato jų prioritetus, analizuoja genų raišką bei rekonstruoja cheminės sintezės kelius. Šios žinios leidžia inžinieriams pagrįstai siūlyti, kaip pagerinti tokius darbo procesus.
Jau buvome įrodę, kad šie darbo procesai gali teikti vertę, tačiau norint bet kurį iš jų pritaikyti kitai komandai vis dar reikėjo pernelyg daug individualaus integravimo darbo. Kitas iššūkis buvo išlaikyti pasiektus rezultatus ir kartu palengvinti programinės įrangos diegimą bei priežiūrą.
Tuo metu „Codex“ galimybės jau buvo išaugusios. Vienas tiesioginio diegimo inžinierius išbandė, kaip būtų galima perkurti programą „Codex“ pagrindu, o tada kartu su komanda perkėlė taikymo atvejus į bendrą infrastruktūrą, kurios pagrindas – „Codex“.
Individualios programos tapo įskiepiais ir įgūdžiais, sukurtais naudojant bendrus bazinius „Codex“ komponentus. „Codex“ taip pat tapo sąsaja, todėl galėjome atsisakyti atskirų terminalo naudotojo sąsajų ir komandų eilutės sąsajų, kurias buvome sukūrę konkretiems taikymo atvejams.
Iš kiekvieno projekto galėjome pašalinti apie 90 % individualiai parašyto kodo. Tai pakeitė šių darbo procesų kūrimą, priežiūrą ir plėtrą:
Galėjome naudotis centralizuotais „Codex“ patobulinimais, todėl kiekvienam taikymo atvejui reikėjo mažiau komponentus jungiančio kodo
Pagrindinės funkcijos buvo sujungtos į įgūdžius ir įskiepius, todėl komandoms tapo lengviau jais dalytis, o DI kompetencijų centrui – juos centralizuotai valdyti. Taigi norint sprendimą pritaikyti kitai komandai galėjo pakakti pakeisti jungtis ar MCP serverius, sukurti naujus vertinimo testus (tam irgi turėjome įgūdį) ir pradėti darbą.
Vienu 2026 m. rugpjūčio mėnesio atveju pradinis diegimas užtruko du mėnesius. Sprendimo pritaikymas antrajai komandai užtruko vieną dieną. Plečiant mastą, kitos komandos pradėdavo naudotis sprendimu vis greičiau. Ši tendencija tęsėsi: vienu 2026 m. rugpjūčio mėnesio taikymo atveju antrajai komandai pakako 1 dienos, nors pradinis diegimas buvo užtrukęs 2 mėnesius.
Tai vienas būdų pasiekti, kad mūsų pagalbos nebereikėtų. Ruošdami sprendimą realiam naudojimui išsiaiškinome, kas svarbiausia. Tobulėjant baziniam produktui, galėjome pakeisti didelę dalį savo individualaus sprendimo ir išlaikyti jo teikiamą vertę.
Štai kodėl svarbi veiksmų seka. LLM leidžia kurti greitai. Pasinaudokite tuo greičiu, kad naudotojai gautų ką nors vertingo, išsiaiškinkite, kas pasiteisina praktikoje, o tada plėskite tai, kas veikia.
Tas pats principas galioja visiems bendriems projektams.
„OpenAI Presence“, mūsų produktas įmonių balso ir pokalbių agentams, išaugo iš realių klientų diegimų. Darbas prasidėjo su „Swarm“(atsidaro naujame lange) ir vystėsi per Agentų API, ir šiandien vienas klientas daugiau nei pusę savo skambučių tvarko naudodamas dirbtinį intelektą.
Šių diegimų įdiegimas gamyboje parodė, kurioms problemoms reikia individualaus sprendimo ir kokius konstrukcinius elementus galėtų panaudoti kitos komandos. Šiuos pagrindinius elementus įtraukėme į „Presence“, kad kūrėjams būtų lengviau automatizuoti reguliuojamus darbo eigą neperkuriant pagrindinės infrastruktūros. Kiekvienas diegimas padėjo formuoti produktą ir suteikė geresnį atspirties tašką kitam klientui.
Su „Thrive Holdings“ , „OpenAI“ FDE ir tyrėjai kartu su inžinieriais ir buhalteriais sukūrė mokesčių dirbtinį intelektą Kretos apskaitos įmonėms. Bandomojo projekto metu „Tax AI“ apdorojo 7000 mokesčių deklaracijų ir padidino pralaidumą apie 50 %.
Vienas sunkiausių iššūkių buvo nuomojamo turto deklaracijų automatizavimas, kuriam prireikė šešių savaičių inžinierių ir specialistų peržiūros, kad būtų pasiektas 90 % tikslumas ir atkūrimo rodiklis. Darbas sukūrė daugkartinio naudojimo modelius, kurie palengvino mokesčių dirbtinio intelekto išplėtimą į kitus sudėtingus mokesčių tarifus.
Komandos dabar taiko tą patį metodą buhalterinei apskaitai, auditui ir IT palaikymui – kuria sistemas, kurios tobulėja remiantis specialistų atsiliepimais ir praktiniu pritaikymu.
Kartais geresnis produktas leidžia supaprastinti tai, ką sukūrėme, tačiau kartais pats modelis dar nepajėgia atlikti užduoties.
Jei kursime tik tai, ką jau leidžia dabartiniai modeliai, neatskleisime gebėjimų spragų, kurias tyrimų komanda turėtų šalinti toliau. Todėl daug svarbių mūsų projektų prasideda ties šiomis ribomis, klientui, tiesioginio diegimo inžinieriams ir tyrimų komandai įsipareigojus jas įveikti kartu.
Kartu su stambiu telekomunikacijų klientu jau buvome sukūrę klientų aptarnavimo platformą, o dabar jis norėjo ją pritaikyti ir pokalbiams balsu.
Pokalbiai balsu sudarė apie 90 % visos jo klientų aptarnavimo apimties. Tokias užklausas išspręsti be darbuotojų pagalbos kainavo daugiau nei tekstiniuose pokalbiuose. Be to, kilo naujų techninių iššūkių: reikėjo užtikrinti, kad akcentų atpažinimas, tonas, delsa ir tikslumas atitiktų realaus naudojimo reikalavimus. Sėkmingas sprendimas būtų turėjęs didelę reikšmę kliento verslui.
Apibrėžiant projekto apimtį, mūsų modelio rezultatas pagrindiniuose vertinimo testuose, kuriais tikrinome jo tinkamumą realiam naudojimui, siekė apie 60 %. Buvome pasiekę jo galimybių ribas. Reikėjo pagerinti funkcijų kvietimą ir instrukcijų laikymąsi klientų aptarnavimo situacijose.
Tai paaiškinome klientui ir į darbą įtraukėme tyrimų komandą. Tiesioginio diegimo inžinieriai kartu su klientu kūrė platformą ir apibrėžė, ką modelis turi gebėti atlikti. Tyrimų komanda šalino modelio gebėjimų spragas, o su kiekviena nauja jo versija galėjome patikrinti pažangą pagal kliento reikalavimus.
Per šešis mėnesius pagrindinių vertinimo testų rezultatai pakilo nuo maždaug 60 % iki 80 %, o vėliau viršijo 90 % ir pasiekė realiam naudojimui reikalingą lygį.
Taip sukurtas balso modelis dabar naudojamas tiek šio kliento sprendime, tiek kituose individualiuose klientų aptarnavimo sprendimuose ir per „Presence“ valdomuose diegimuose. Vieno kliento versle iškilusi problema padėjo nustatyti patobulinimus, kurie gali būti naudingi daugeliui kitų.
Kiekvieno indėlis buvo svarbus. Klientas įsipareigojo kartu spręsti problemą, kurios modelis dar nepajėgė įveikti. Tiesioginio diegimo inžinieriai glaudžiai bendradarbiavo su klientu, kad apibrėžtų problemą, sukurtų platformą ir vestų projektą nuo pradžios iki pabaigos. Tyrimų komanda tobulino bazinius modelio gebėjimus.
Tai kitas būdas pasiekti, kad mūsų pagalbos nebereikėtų: padėti problemą, kurios šiandieniniai modeliai negali išspręsti, paversti užduotimi, kurią ateities modeliai gebės atlikti. Mūsų darbo grąža neapsiriboja valandomis, kurias praleidžiame su vienu klientu.
Prisijungiau prie „OpenAI“, kad padėčiau DI paversti naudingu kasdieniame žmonių darbe. Šis tikslas ir toliau rodo komandai kryptį. Komandai dažnai sakau, kad kuriant LLM dažniausiai galioja Okamo skustuvo principas – paprasčiausias sprendimas yra geriausias. Dirbdami įmonėje, kurios išskirtinumas – pažangiausi tyrimai, ir sektoriuje, kurio reputacijai kenkia perdėti pažadai, norime kurti patikimai veikiančius sprendimus, kuriais praktikai galėtų pasikliauti.
Siekiame, kad kiekvienas projektas pagerintų sąlygas kitam: produktą būtų lengviau įdiegti, modelis gebėtų atlikti sunkesnę užduotį arba kitam klientui reikėtų mažiau individualaus kūrimo darbų.
Jei turite sudėtingą problemą, kurią norite išspręsti, mielai dirbtume kartu. Jei norite padėti spręsti tokias problemas, kviečiame prisijungti prie mūsų.
Tad ką darome, kai „Codex“ jau gali atlikti darbą, kuriam skirtą sprendimą kūrėme ištisus mėnesius?
Ieškome sunkesnės problemos.
