Ko OpenAI nozīmē risinājumu ieviešanas inženieru darbs
Ko mēs darām, kā strādājam un kā risinām uzņēmumu grūtākās problēmas, lai panāktu reālus rezultātus.
Autors: Kolins Džārviss, OpenAI risinājumu ieviešanas inženierijas vadītājs
Kad parādījās Codex, kāds komandas biedrs man jautāja: „Ko mēs darīsim, kad Codex ar vienu mēģinājumu spēs atrisināt uzdevumus, kuru risinājumu izstrādei veltījām pēdējos mēnešus?“
Šis jautājums atklāj risinājumu ieviešanas inženieru darba būtību uzņēmumā OpenAI. Mēs strādājam plecu pie pleca ar klientiem, lai izprastu viņu sarežģītākās problēmas un veidotu risinājumus, uz kuriem viņi var paļauties. Iegūtās zināšanas palīdz veidot mūsu produktus un dod pētniecības komandai konkrētas risināmas problēmas.
Tas ir progress. Ja ik pēc pāris mēnešiem padarām savu turpmāko iesaisti nevajadzīgu, mūsu risinājumu ieviešanas inženieru komanda dara savu darbu.
Es izveidoju komandu 2025. gada sākumā, lai pārvarētu to, ko saucam par „ieviešanas plaisu“: atšķirību starp to, ko modeļi šķietami spēj, un to, ko cilvēki var uzticami izmantot savā darbā.
Modeļu spējas ir attīstījušās straujāk nekā sistēmas un procesi, kas vajadzīgi to izmantošanai. Dažkārt trūkstošais posms ir produkts. Dažkārt modelis uzrāda labus rezultātus etalontestā, bet netiek galā ar uzdevumu reālos, mainīgos apstākļos un ierobežojumos.
Mēs koncentrējamies uz klientu sarežģītākajām problēmām. Ja mūsu modeļi jau šodien spēj paveikt uzdevumu, mēs kopā ar produktu komandu un klientu strādājam, lai risinājumu varētu ieviest atkārtoti. Ja modeļu spēju nepietiek, mēs kopā ar klientiem un pētniecības komandu nosakām, kā trūkst, un veicam uzlabojumus. Mūsu mērķis ir panākt, lai katrs sadarbības projekts nodrošinātu nākamajam klientam labāku sākumpunktu. Ja paaugstinām bāzes līmeni tik tālu, ka nākamreiz šāda veida problēmas atrisināšanai klientiem vairs nevajag risinājumu ieviešanas inženierus, mēs savu darbu esam paveikuši labi.
Lauksaimniecības nozares uzņēmumam John Deere ar 200 gadu vēsturi bija jāatrod veids, kā sniegt personalizētus padomus arvien lielākam skaitam lauksaimnieku.
Viens piemērs ir uzņēmuma precīzās nezāļu apkarošanas tehnoloģija See & Spray. Tā izmanto kameras un mašīnmācīšanos, lai atpazītu un apsmidzinātu nezāles, nevis apstrādātu visu lauku, tādējādi samazinot ķimikāliju patēriņu līdz pat 70 %.
Taču šos ieguvumus var gūt tikai tad, ja lauksaimnieki zina, kā iestatīt tehnoloģiju, plānot sezonas darbus un pielāgot darba paņēmienus mainīgajiem apstākļiem.
John Deere ieviesa OpenAI API, lai palīdzētu šo atbalstu personalizēt un nodrošināt plašākam lietotāju lokam.
MI var atbildēt uz lauksaimnieku jautājumiem dabiskā valodā, sniegt pielāgotus iestatīšanas norādījumus un ieteikumus, noteikt, kad tehnika, iespējams, nedarbojas ar pilnu atdevi, un palīdzēt lauksaimniekiem izprast tehnoloģijas sniegtos ieguvumus.
Iespējas neaprobežojas ar atsevišķu sarunu: atbilstošus norādījumus var sniegt visā klienta sadarbības gaitā, palīdzot lauksaimniekiem labāk izmantot tehniku un vienlaikus uzlabot efektivitāti un ilgtspēju.
Tieši šādus uzdevumus risina OpenAI risinājumu ieviešanas inženieri: viņi palīdz organizācijām pāriet no MI iespējām uz sistēmām, kas sniedz praktisku vērtību sarežģītos reālās darbības apstākļos.
Taču problēmas bieži ir neskaidri definētas, var nebūt noteiktu pareizības kritēriju, un nav gatavas rīcības shēmas. Ikviens vēlas radīt kaut ko vēl nebijušu. Mazāk ir to, kuri gatavi darīt visu nepieciešamo, lai to sasniegtu.
Talantīgu risinājumu ieviešanas inženieru meklēšana, vienlaikus ceļot latiņu tam, ko uzskatām par „pietiekami labu“, ir prasījusi nemitīgu eksperimentēšanu un pārbaudi praksē.
Katras risinājumu ieviešanas inženieru komandas sanāksmes sākumā es parādu slaidu ar vienu pamatvērtību: „Sāciet ar sasniedzamo rezultātu, dariet visu nepieciešamo, lai gūtu panākumus, un pēc tam paplašiniet mērogu.“
Iespaidīga demonstrācija var aizvest tālu, pirms kāds pajautā, vai risinājums darbojas arī reālajā pasaulē.
Mūsu uzdevums ir atrisināt klienta problēmu tādā kvalitātē, par kuru varam uzņemties atbildību reālā ekspluatācijā.
2025. gada vidū aptuveni 15 mūsu risinājumu ieviešanas inženieri kopā ar lielu pusvadītāju nozares klientu strādāja pie vairāk nekā 10 lietojuma scenārijiem. Mērķis bija pārveidot uzņēmuma verifikācijas procesu tā, lai tā pamatā būtu mākslīgais intelekts (MI), aptverot:
Mērķētu testu ģenerēšanu
Pamatcēloņu analīzi un atkļūdošanu
Arhitektūras asistentu
Šajā nozarē verifikācija var veidot aptuveni 70 % no projekta darba apjoma. Potenciāls bija milzīgs, un bija daudz iespēju, ar ko sākt.
Daži risinājumu ieviešanas inženieri bija pievienojušies OpenAI tikai pirms dažām dienām un nekad nebija strādājuši pusvadītāju nozarē. Viņi iesaistījās klienta verifikācijas komandas ikdienas darbā, brīvajā laikā apguva mikroshēmu projektēšanu un kopā ar inženieriem veidoja novērtēšanas testus, lai pārbaudītu, vai MI spēj ģenerēt noderīgus testus un pareizi diagnosticēt mikroshēmu kļūmes.
Līdztekus šo zināšanu apguvei mēs veidojām pielāgotus izpildes ietvarus katram lietojuma scenārijam. Pirmajos 3–6 mēnešos visi risinājumi tika ieviesti ekspluatācijā, un tos sāka izmantot pirmie lietotāji. Ieguldītais darbs atspoguļojās rādītājos:
Aptuveni 48 % laika ietaupījums, ģenerējot mērķētus testus ar MI.
Veiktspējas uzlabojuma mediāna — 22 %, pateicoties kodolu optimizācijai.
Atkļūdošana, kas iepriekš prasīja nedēļas, tagad aizņēma stundas
Kad prezentējām šos rezultātus, aparatūras izstrādes direktors jautāja: „Vai jūs pirms ierašanās šeit strādājāt par mikroshēmu projektētājiem?“
Mūsu risinājumu ieviešanas inženieriem nav jāpārzina nozare jau pirmajā dienā, taču viņu pienākums ir to apgūt.
Programmēšanas asistenti ļauj izstrādāt programmatūru ātrāk, tāpēc izpratne par klienta uzņēmējdarbību kļūst vēl svarīgāka. Mēs veidojam komandas, kurās apvienoti plaša profila speciālisti un nozaru eksperti.
Ir vajadzīgs pietiekami daudz zināšanu, lai pieņemtu pamatotus lēmumus, un pietiekami liela zinātkāre, lai apšaubītu pieņēmumus par ierasto kārtību.
Piemēram, dzīvības zinātnēs mūsu risinājumu ieviešanas inženieru zinātniskā pieredze palīdz iegūt uzticību pētniekiem, kuri strādā pie preklīniskās zāļu atklāšanas uzdevumiem, piemēram, mērķu validēšanas un prioritizēšanas, gēnu ekspresijas analīzes un ķīmiskās sintēzes ceļu rekonstruēšanas. Šīs zināšanas ļauj viņiem sniegt pamatotu vērtējumu par to, kā šīs darbplūsmas varētu uzlabot.
Bijām pierādījuši, ka šīs darbplūsmas var sniegt vērtību, taču katras pielāgošanai citai komandai joprojām vajadzēja pārāk daudz individuāla integrācijas darba. Nākamais izaicinājums bija saglabāt šos rezultātus, vienlaikus atvieglojot programmatūras ieviešanu un uzturēšanu.
Pa to laiku Codex iespējas bija paplašinājušās. Viens risinājumu ieviešanas inženieris izmēģināja lietotnes pārbūvi uz Codex pamata un pēc tam kopā ar komandu pārcēla lietojuma scenārijus uz kopīgu izpildes ietvaru, kura centrā bija Codex.
Individuāli izstrādātās lietotnes kļuva par spraudņiem un prasmēm, kas veidotas no kopīgiem Codex pamatelementiem. Codex kļuva arī par saskarni, ļaujot atteikties no atsevišķām termināļa lietotāja saskarnēm un komandrindas saskarnēm, kuras bijām izstrādājuši katram lietojuma scenārijam.
No katra projekta varējām izņemt aptuveni 90 % individuāli rakstītā koda, un tas mainīja veidu, kā veidojām, uzturējām un paplašinājām šīs darbplūsmas:
Varējām izmantot centralizētus Codex uzlabojumus, samazinot katram lietojuma scenārijam vajadzīgā savienojošā koda apjomu
Galvenās funkcijas tika apvienotas prasmēs un spraudņos, lai ar tām būtu vieglāk dalīties starp komandām un MI izcilības centrs tās varētu centralizēti pārvaldīt. Tas nozīmēja, ka ieviešanai nākamajā komandā varēja pietikt ar savienotāju un MCP serveru nomaiņu, jaunu novērtēšanas testu izveidi (arī tam mums bija prasme) un darba sākšanu.
Vienā 2026. gada augusta piemērā sākotnējā ieviešana prasīja divus mēnešus. Risinājuma ieviešana otrajā komandā aizņēma vienu dienu. Paplašinot mērogu, katra nākamā komanda varēja sākt darbu ātrāk. Šī tendence turpinājās: vienā 2026. gada augusta lietojuma scenārijā ieviešana otrajā komandā aizņēma vienu dienu pēc tam, kad sākotnējā ieviešana bija prasījusi divus mēnešus.
Tas ir viens veids, kā padarām savu turpmāko iesaisti nevajadzīgu. Darbs, ko bijām paveikuši līdz ieviešanai ekspluatācijā, parādīja, kas ir būtisks. Pilnveidojoties pamatproduktam, varējām aizstāt lielu daļu individuāli izstrādātā risinājuma, saglabājot tā sniegto vērtību.
Tāpēc secībai ir nozīme. Lielie valodu modeļi ļauj mums izstrādāt ātri. Izmantojiet šo ātrumu, lai nodotu lietotāju rokās kaut ko vērtīgu, noskaidrotu, kas iztur pārbaudi praksē, un pēc tam paplašinātu to, kas darbojas.
Tas pats princips attiecas uz visiem sadarbības projektiem.
OpenAI Presence, mūsu produkts uzņēmumu balss un tērzēšanas aģentiem, radās no reālu klientu ieviešanas. Darbs sākās ar Swarm(atveras jaunā logā) un attīstījās cauri Aģentu API, un šodien viens klients tagad apstrādā vairāk nekā pusi savu zvanu, izmantojot mākslīgo intelektu.
Šo ieviešanas ieviešana ražošanā mums iemācīja, kurām problēmām nepieciešams pielāgots risinājums un kādus pamatelementus varētu izmantot citas komandas. Mēs šos pamatelementus ieviesām Presence platformā, atvieglojot izstrādātājiem regulēto darbplūsmu automatizāciju, neatjaunojot pamatā esošo infrastruktūru. Katra ieviešana palīdzēja veidot produktu un deva nākamajam klientam labāku sākumpunktu.
Ar "Thrive Holdings" , "OpenAI" finanšu departamentu vadītāji un pētnieki sadarbojās ar inženieriem un grāmatvežiem, lai izveidotu nodokļu mākslīgo intelektu Krētas grāmatvedības uzņēmumiem. Izmēģinājuma laikā Nodokļu mākslīgais intelekts apstrādāja 7000 nodokļu deklarāciju un palielināja caurlaidspēju par aptuveni 50 %.
Viens no sarežģītākajiem izaicinājumiem bija īres īpašumu deklarāciju automatizācija, kas prasīja sešas nedēļas ilga inženieru un praktiķu darba, lai sasniegtu 90% precizitāti un atpazīstamību. Darbs radīja atkārtoti izmantojamus modeļus, kas atviegloja nodokļu mākslīgā intelekta paplašināšanu uz citiem sarežģītiem nodokļu grafikiem.
Komandas tagad piemēro vienu un to pašu pieeju grāmatvedībai, auditam un IT atbalstam — veidojot sistēmas, kas uzlabojas, pateicoties praktiķu atsauksmēm un reālai lietošanai.
Dažkārt labāks produkts ļauj vienkāršot mūsu izveidoto risinājumu, bet citkārt pats modelis vēl nespēj paveikt uzdevumu.
Ja veidosim tikai to, ko jau ļauj pašreizējie modeļi, neatklāsim spēju trūkumus, kas pētniecības komandai jānovērš nākamie. Tāpēc daudzi mūsu nozīmīgākie sadarbības projekti sākas tieši pie šīm robežām, klientam, risinājumu ieviešanas inženieriem un pētniecības komandai apņemoties tās pārvarēt kopā.
Kopā ar lielu telekomunikāciju uzņēmumu jau bijām izstrādājuši klientu apkalpošanas platformu, un šis klients vēlējās to papildināt ar balss saziņu.
Balss saziņa veidoja aptuveni 90 % no uzņēmuma klientu apkalpošanas apjoma. Šo pieprasījumu automatizēta apstrāde bija dārgāka nekā tērzēšanā, un tā radīja virkni jaunu tehnisku izaicinājumu: akcentu atpazīšanai, balss tonim, aizturei un precizitātei bija jāsasniedz reālai ekspluatācijai nepieciešamais līmenis. Veiksmīgs risinājums būtiski ietekmētu uzņēmuma darbību.
Nosakot projekta tvērumu, mūsu modelis galvenajos novērtēšanas testos, ar kuriem pārbaudījām tā gatavību reālai ekspluatācijai, sasniedza aptuveni 60 % rezultātu. Bijām sasnieguši tā spēju robežas. Klientu apkalpošanas scenārijos bija jāuzlabo funkcijas izsaukšana un norādījumu ievērošana.
Mēs to izskaidrojām klientam un iesaistījām darbā pētniecības komandu. Risinājumu ieviešanas inženieri kopā ar klientu veidoja platformu un noteica, kas modelim jāspēj paveikt. Pētniecības komanda strādāja pie trūkstošo spēju attīstīšanas, un secīgas modeļa starpversijas ļāva mums pārbaudīt progresu atbilstoši klienta prasībām.
Sešu mēnešu laikā rezultāti galvenajos novērtēšanas testos pieauga no aptuveni 60 % līdz 80 % un pēc tam pārsniedza 90 %, sasniedzot reālai ekspluatācijai vajadzīgo līmeni.
Izstrādātais balss modelis tagad nodrošina gan šī klienta risinājuma darbību, gan citus pielāgotus klientu apkalpošanas risinājumus un pārvaldītus risinājumus platformā Presence. Viena klienta darbībā atklāta problēma palīdzēja noteikt uzlabojumus, kas varētu noderēt daudziem citiem.
Katrai daļai bija nozīme. Klients apņēmās strādāt pie problēmas, kuru modelis vēl nespēja atrisināt. Risinājumu ieviešanas inženieri cieši sadarbojās ar klientu, lai formulētu problēmu, izveidotu platformu un virzītu sadarbību no sākuma līdz beigām. Pētniecības komanda uzlaboja pamatā esošā modeļa spējas.
Tas ir otrs veids, kā padarām savu turpmāko iesaisti nevajadzīgu: palīdzam panākt, lai problēmu, ko pašreizējie modeļi nespēj atrisināt, nākotnes modeļi jau prastu risināt. Mūsu darba atdeve sniedzas tālāk par stundām, ko pavadām ar katru atsevišķo klientu.
Es pievienojos OpenAI, lai palīdzētu padarīt MI noderīgu cilvēku ikdienas darbā. Tas joprojām ir komandas darba vadmotīvs. Es komandai bieži saku, ka lielo valodu modeļu izstrādē vairumā gadījumu darbojas Okama bārdasnaža princips — vienkāršākais risinājums ir labākais. Strādājot uzņēmumā, kura būtība ir progresīva pētniecība, un nozarē, kuras reputāciju grauj pārspīlējumi, mēs vēlamies veidot risinājumus, kas darbojas uzticami un uz kuriem cilvēki var paļauties praksē.
Mērķis ir panākt, lai katrs sadarbības projekts uzlabotu nākamo: radītu vieglāk ieviešamu produktu, modeli, kas tiek galā ar grūtāku uzdevumu, vai samazinātu individuāli pielāgota darba apjomu nākamajam klientam.
Ja jums ir sarežģīta problēma, ko vēlaties atrisināt, mēs labprāt ar jums sadarbotos. Ja vēlaties palīdzēt risināt šādas problēmas, mēs priecātos, ja pievienotos mums.
Ko tad mēs darām, kad Codex spēj paveikt darbu, kura risinājuma izstrādei veltījām mēnešus?
Meklējam grūtāku problēmu.
