Co v OpenAI znamená role inženýra nasazeného u zákazníka (FDE)
Co děláme, jak pracujeme a jak řešíme nejtěžší problémy firem, abychom přinášeli skutečné výsledky.
Autor: Colin Jarvis, vedoucí týmu inženýrů nasazených u zákazníka v OpenAI
Když byl spuštěn Codex, někdo z týmu se mě zeptal: „Co budeme dělat, až Codex na první dobrou zvládne případy použití, pro které jsme posledních pár měsíců vyvíjeli řešení?“
Tato otázka vystihuje podstatu role inženýra nasazeného u zákazníka v OpenAI. Pracujeme po boku zákazníků, abychom porozuměli jejich nejtěžším problémům a vytvořili řešení, na která se mohou spolehnout. Naše poznatky pomáhají utvářet produkty a dávají výzkumnému týmu konkrétní problémy k řešení.
To je pokrok. Pokud každých pár měsíců zařídíme, že už nejsme potřeba, dělá náš tým inženýrů nasazených u zákazníka svou práci dobře.
Tým jsem založil na začátku roku 2025, abychom překlenuli to, čemu říkáme „propast mezi možnostmi a nasazením“: rozdíl mezi tím, čeho jsou modely zřejmě klidně schopné, a tím, co lidé mohou spolehlivě využívat při práci.
Schopnosti modelů se rozvíjejí rychleji než systémy a procesy potřebné k jejich využití. Někdy chybí produkt. Jindy model dosahuje dobrých výsledků v benchmarku, ale v proměnlivých podmínkách a s omezeními reálného světa úkol nezvládne.
Zaměřujeme se na nejtěžší problémy zákazníků. Tam, kde naše modely úkol zvládnou už dnes, spolupracujeme s produktovým týmem a zákazníkem, aby bylo možné řešení opakovaně využívat. Tam, kde modely nestačí, se zákazníky a výzkumným týmem definujeme nedostatky a pracujeme na zlepšeních. Naším cílem je, aby každý projekt dal dalšímu zákazníkovi lepší výchozí pozici. Pokud základní úroveň řešení zvedneme natolik, že zákazníci příště u tohoto typu problému nebudou potřebovat inženýry nasazené u zákazníka, odvedli jsme dobrou práci.
Společnost John Deere, která působí v zemědělství už 200 let, řešila, jak poskytovat individuální poradenství většímu počtu zemědělců.
Jedním z příkladů je See & Spray, její technologie přesného hubení plevele. Pomocí kamer a strojového učení rozpoznává plevel a cíleně ho postřikuje místo ošetřování celých polí, čímž snižuje spotřebu chemických přípravků až o 70 %.
Aby však zemědělci těchto přínosů dosáhli, musí vědět, jak technologii nastavit, naplánovat sezónu a přizpůsobovat své postupy měnícím se podmínkám.
John Deere nasadil API od OpenAI, aby mohl tuto podporu poskytovat na míru a ve větším měřítku.
AI dokáže odpovídat na otázky zemědělců v přirozeném jazyce, poskytovat individuální pokyny a doporučení, jak produkt používat, rozpoznat, kdy zařízení zřejmě nevyužívá svůj plný potenciál, a informovat zemědělce, jaký užitek jim technologie přináší.
Možnosti přitom nekončí u jednotlivých interakcí. Jde o poskytování užitečných rad po celou dobu vztahu se zákazníkem, které zemědělcům pomáhají lépe využívat svá zařízení a zároveň zvyšovat efektivitu i udržitelnost.
Právě takové výzvy řeší inženýři OpenAI přímo u zákazníka (FDE): pomáhají organizacím proměňovat schopnosti AI v systémy, které přinášejí praktický užitek ve složitém reálném prostředí.
Problémy jsou ale často zcela otevřené, nemusí existovat ani ověřený správný výsledek a žádný osvědčený návod není k dispozici. Každý chce vytvořit něco, co tu ještě nebylo. Méně lidí je ochotných udělat vše, co je k tomu potřeba.
Hledat talentované inženýry pro nasazení u zákazníka a zároveň zvyšovat laťku toho, co je „natolik dobré, že to stačí“, vyžaduje neustálé experimentování a ověřování v praxi.
Na začátku každého setkání týmu inženýrů nasazených u zákazníka promítám snímek s jednou základní zásadou: „Začněte od cílového výsledku, udělejte vše potřebné pro úspěch a pak řešení naškálujte.“
Působivá ukázka může slavit úspěch dlouho předtím, než se někdo zeptá, jestli funguje i v reálném světě.
Naším úkolem je vyřešit zákazníkův problém v kvalitě, za kterou si dokážeme stát i v ostrém provozu.
V polovině roku 2025 pracovalo přibližně 15 našich inženýrů nasazených u zákazníka s velkým zákazníkem z polovodičového průmyslu na více než 10 případech použití. Cílem bylo postavit jeho proces verifikace od základu na AI, a to v těchto oblastech:
Generování cílených testů
Analýza prvotních příčin a ladění
Asistent pro návrh architektury
Verifikace může v tomto odvětví představovat přibližně 70 % práce na projektu. Potenciál byl obrovský a nabízelo se mnoho možností, kde začít.
Někteří inženýři nasazení u zákazníka nastoupili do OpenAI teprve před několika dny a s polovodiči nikdy nepracovali. Začlenili se do zákazníkova verifikačního týmu, ve volném čase studovali návrh čipů a společně s jeho inženýry vytvářeli hodnocení, která ověřovala, zda AI dokáže generovat užitečné testy a správně diagnostikovat selhání čipů.
Souběžně s tímto učením jsme pro jednotlivé případy použití vytvářeli harnessy na míru. Během prvních 3–6 měsíců se všechny dostaly do ostrého provozu a získaly první uživatele. Odměnou nám bylo, když jsme se podívali na metriky:
Přibližně 48% úspora času díky generování cílených testů pomocí AI.
Medián zlepšení výkonu díky optimalizaci kernelů dosáhl 22 %.
Ladění zkrácené z týdnů na hodiny
Když jsme všechny výsledky představili, ředitel hardwarového vývoje se zeptal: „Vy jste pracovali jako návrháři čipů, než jste přišli sem?“
Naši inženýři nasazení u zákazníka se nemusí vyznat v zákazníkově odvětví hned první den, ale mají za úkol se s ním seznámit.
S tím, jak programovací asistenti urychlují vývoj softwaru, nabývá porozumění činnosti zákazníka ještě více na důležitosti. Sestavujeme týmy jak z lidí se širokým záběrem, tak z odborníků na konkrétní oblasti.
Potřebujete dostatek znalostí pro správný úsudek a dostatek zvídavosti, abyste zpochybňovali zažité představy o tom, jak se věci dělají.
Například v biologických vědách pomáhají vědecké zkušenosti našim inženýrům nasazeným u zákazníka získat důvěru výzkumníků, kteří se věnují předklinickému výzkumu léčiv: ověřování a prioritizaci cílů léčiv, analýze genové exprese či rekonstrukci cest chemické syntézy. Díky této odbornosti dokážou kvalifikovaně posoudit, jak by se tyto pracovní postupy daly zlepšit.
Ukázali jsme, že tyto pracovní postupy mohou přinášet užitek. Jejich rozšíření do dalšího týmu ale stále vyžadovalo příliš mnoho integrace na míru. Další výzvou bylo zachovat tyto výsledky a zároveň usnadnit nasazování a údržbu softwaru.
Mezitím se schopnosti Codex rozšířily. Jeden inženýr nasazený u zákazníka zkusil přestavět jejich aplikaci na Codex. Poté s týmem převedl jednotlivé případy použití na společný harness, jehož jádrem byl Codex.
Z aplikací na míru se staly pluginy a dovednosti založené na společných základních prvcích Codexu. Codex se stal i uživatelským rozhraním, takže jsme mohli vyřadit samostatná terminálová rozhraní a rozhraní příkazového řádku, která jsme napsali pro jednotlivé případy použití.
Z každého projektu jsme mohli odstranit zhruba 90 % kódu napsaného na míru. To změnilo způsob, jakým jsme tyto pracovní postupy vytvářeli, udržovali a rozšiřovali:
Mohli jsme těžit z centrálních vylepšení Codexu, a omezit tak množství propojovacího kódu potřebného pro každý jednotlivý případ použití
Klíčové funkce jsme zabalili do skillů a pluginů, což usnadnilo jejich vzájemné sdílení i centrální správu centrem excelence AI. Rozšíření z jednoho týmu do dalšího tak mohlo být stejně jednoduché jako výměna konektorů či MCP serverů, vytvoření nových hodnocení (i na to jsme měli skill) a spuštění.
V jednom případě ze srpna 2026 trvalo počáteční nasazení dva měsíce. Rozšíření řešení do druhého týmu zabralo jeden den. S rozšiřováním řešení se další týmy zapojovaly rychleji. Tento trend pokračoval: u jednoho případu použití v srpnu 2026 zabralo nasazení ve druhém týmu 1 den, zatímco počáteční nasazení trvalo 2 měsíce.
To je jeden ze způsobů, jak zařídit, aby jsme už nebyli potřeba. Práce na zavedení do ostrého provozu ukázala, na čem záleží. Jak se základní produkt zlepšoval, byli jsme schopni velkou část vlastní implementace nahradit a přitom zachovat její přínos.
Právě proto záleží na pořadí. LLM nám umožňují rychle vyvíjet. Využijte tuto rychlost, abyste uživatelům dali do rukou něco užitečného, zjistili, co obstojí v praxi, a pak naškálovali to, co funguje.
Stejný princip platí pro všechny projekty komunikace se zákazníky.
OpenAI Presence, náš produkt pro podnikové hlasové a chatovací agenty, vznikl na základě reálných nasazení u zákazníků. Práce začala Swarmem(otevře se v novém okně) a postupně se vyvíjela přes Agents API. Dnes jeden zákazník vyřizuje více než polovinu svých hovorů pomocí umělé inteligence.
Zavádění těchto nasazení do produkčního prostředí nás naučilo, které problémy vyžadují vlastní řešení a které stavební bloky mohou použít ostatní týmy. Tyto stavební bloky jsme přenesli do Presence, což vývojářům usnadní automatizaci regulovaných pracovních postupů bez nutnosti přestavby základní infrastruktury. Každé nasazení pomohlo utvářet produkt a poskytlo dalšímu zákazníkovi lepší výchozí bod.
Pro firmu Thrive Holdings pracovali inženýři nasazení u zákazníka a výzkumníci z OpenAI spolu s jejich techniky a účetními na vývoji daňové umělé inteligence pro účetní firmy na Krétě. Během pilotního projektu zpracovala Tax AI 7000 daňových přiznání a zvýšila výkon přibližně o 50 %.
Jednou z nejtěžších výzev byla automatizace daňových přiznání z nemovitostí k pronájmu, která vyžadovala šest týdnů inženýrské a praktické kontroly k dosažení 90% přesnosti a spolehlivosti. Práce vytvořila opakovaně použitelné vzory, které usnadnily rozšíření daňové umělé inteligence na další složité typy daňových přiznání.
Týmy nyní uplatňují stejný přístup k účetnictví, auditu i IT podpoře – vytvářejí systémy, které se zlepšují díky zpětné vazbě od odborníků a reálnému využití.
Někdy nám lepší produkt umožní zjednodušit to, co jsme vytvořili. Jindy ale samotný model úkol zatím nezvládá.
Pokud budeme vytvářet jen to, co dnešní modely už umožňují, neodhalíme mezery v jejich schopnostech, které musí výzkumný tým vyřešit jako další. Mnoho našich důležitých projektů proto začíná právě na těchto hranicích. Zákazník, inženýři nasazení u zákazníka a výzkumný tým se zavazují, že je společně překonají.
S velkým zákazníkem z telekomunikačního odvětví jsme už měli vyvinutou platformu zákaznické podpory a zákazník ji chtěl rozšířit o hlasovou komunikaci.
Hlasová komunikace tvořila přibližně 90 % objemu jeho zákaznické podpory. Vyřizovat tyto požadavky bez předání operátorovi bylo nákladnější než u chatu. Navíc bylo nutné vyřešit řadu nových technických problémů, aby práce s přízvuky a tónem hlasu i latence a správnost dosáhly úrovně potřebné pro ostrý provoz. Úspěšné řešení by pro jeho podnikání znamenalo zásadní přínos.
Při vymezování projektu dosahoval náš model zhruba 60% úspěšnosti v klíčových hodnoceních, kterými jsme ověřovali, zda úkol zvládne v ostrém provozu. Narazili jsme na hranice jeho schopností. Bylo třeba zlepšit volání funkce a dodržování pokynů v situacích typických pro zákaznickou podporu.
Vysvětlili jsme to zákazníkovi a zapojili do práce výzkumný tým. Inženýři nasazení u zákazníka (FDE) s ním spolupracovali na tvorbě platformy a vymezení toho, co musí model zvládat. Výzkumný tým pracoval na doplnění chybějících schopností. Průběžné verze modelu nám umožňovaly ověřovat pokrok vzhledem k požadavkům zákazníka.
Během šesti měsíců vzrostla úspěšnost v klíčových hodnoceních z přibližně 60 % na 80 % a poté na více než 90 %, tedy na úroveň potřebnou pro ostrý provoz.
Výsledný hlasový model nyní funguje v nasazení u tohoto zákazníka, v dalších řešeních zákaznické podpory na míru i ve spravovaných nasazeních prostřednictvím Presence. Problém, na který jsme narazili u jednoho zákazníka, pomohl odhalit zlepšení využitelná pro mnoho dalších.
Každá část byla důležitá. Zákazník se zavázal pracovat na problému, který model zatím nedokázal vyřešit. Inženýři nasazení u zákazníka s ním byli v dostatečně úzkém kontaktu, aby mohli problém vymezit, vytvořit platformu a vést projekt od začátku do konce. Výzkumný tým zlepšil schopnosti samotného modelu.
To je druhý způsob, jak zařídit, aby nás už nebylo potřeba: pomoci proměnit problém, který dnešní modely neumějí vyřešit, ve schopnost, kterou budoucí modely nabídnou. Přínos naší práce sahá za hranice hodin strávených s jedním zákazníkem.
Do OpenAI jsem nastoupil, abych pomohl udělat z AI užitečného pomocníka pro každodenní práci lidí. Tím se náš tým řídí dodnes. Týmu často říkám, že při vývoji LLM většinou platí Occamova břitva: nejjednodušší řešení je nejlepší. Ve společnosti, kterou charakterizuje špičkový výzkum, a v odvětví poznamenaném přehnanými tvrzeními chceme vytvářet věci, které fungují spolehlivě a na které se lidé v praxi mohou spolehnout.
Cílem je, aby každý projekt zlepšil podmínky pro ten další: přinesl produkt, který se snáze nasazuje, model, který zvládne těžší úkol, nebo méně práce na míru pro dalšího zákazníka.
Pokud chcete vyřešit obtížný problém, rádi s vámi budeme spolupracovat. Pokud chcete s řešením takových problémů pomáhat, budeme rádi, když se k nám přidáte.
Co tedy uděláme, když Codex zvládne práci, pro kterou jsme měsíce vyvíjeli řešení?
Najdeme si těžší problém.
