Що означає бути інженером із впровадження в OpenAI
Що ми робимо, як працюємо й розв’язуємо найскладніші проблеми підприємств, щоб досягати реальних результатів.
Автор: Колін Джарвіс, керівник напряму інженерії впровадження в OpenAI
Коли вийшов Codex, хтось із команди запитав мене: «Що нам робити, коли Codex зможе за один раз реалізувати сценарії, над якими ми працювали останні кілька місяців?»
Це запитання влучно передає суть роботи інженерів із впровадження в OpenAI. Ми працюємо пліч-о-пліч із замовниками, щоб зрозуміти їхні найскладніші проблеми та створити рішення, на які вони можуть покластися. Здобутий досвід допомагає формувати наші продукти й дає дослідницькій команді конкретні завдання.
У цьому й полягає прогрес. Якщо кожні кілька місяців ми робимо свою участь непотрібною, наша команда інженерів із впровадження виконує свою роботу.
Я заснував команду на початку 2025 року, щоб усунути те, що ми називаємо «розривом у впровадженні»: відстань між позірними можливостями моделей і тим, що люди можуть надійно використовувати у своїй роботі.
Можливості моделей розвиваються швидше, ніж системи й процеси, потрібні для їх застосування. Іноді бракує саме продукту. Іноді модель добре проходить контрольний тест, але не справляється із завданням за реальних умов та обмежень.
Ми зосереджуємося на найскладніших проблемах замовників. Там, де наші моделі вже здатні виконати завдання, ми разом із продуктовою командою та замовником робимо рішення придатним для повторного використання. А там, де їхніх можливостей бракує, працюємо із замовниками й дослідницькою командою, щоб визначити прогалини та усунути їх. Наша мета — щоб кожен проєкт давав наступному замовнику кращу стартову позицію. Якщо ми піднімемо базовий рівень настільки, що наступного разу для розв’язання такого класу проблем замовникам не знадобляться інженери із впровадження, ми добре виконали свою роботу.
Перед John Deere, компанією з 200-річною історією в аграрній галузі, стояло завдання масштабувати персоналізовані консультації для фермерів.
Один із прикладів — See & Spray, технологія точкової боротьби з бур’янами. Вона використовує камери й машинне навчання, щоб виявляти та обприскувати бур’яни, а не обробляти цілі поля, зменшуючи використання хімікатів до 70%.
Проте ці переваги залежать від того, чи знають фермери, як налаштувати технологію, спланувати сезон і скоригувати свої методи роботи зі зміною умов.
John Deere впровадила API OpenAI, щоб зробити таку підтримку персоналізованою та масштабованою.
ШІ може відповідати на запитання фермерів природною мовою, надавати індивідуальні інструкції з налаштування й рекомендації, виявляти, коли техніка працює не на повну потужність, і допомагати фермерам зрозуміти, яку користь вони отримують від технології.
Можливості виходять за межі окремої взаємодії: доречні поради на всіх етапах роботи з клієнтом допомагають фермерам краще використовувати техніку, підвищувати ефективність і зменшувати вплив на довкілля.
Саме такі завдання розв’язують інженери із впровадження OpenAI: допомагають організаціям перейти від можливостей ШІ до систем, які приносять практичну користь у складних реальних умовах.
Але проблеми часто не мають чітких меж, еталонної відповіді може не бути, як і готового плану дій. Усі хочуть створити щось, чого раніше не існувало. Значно менше людей готові зробити все необхідне для цього.
Пошук талановитих інженерів із впровадження та одночасне підвищення планки «достатньо добре» потребували постійних експериментів і перевірки на практиці.
На початку кожної зустрічі команди інженерів із впровадження я показую слайд з одним ключовим принципом: «Починайте з результату, робіть усе необхідне для успіху, а потім масштабуйте».
Вражаюча демонстрація може зайти далеко, перш ніж хтось запитає, чи працює це в реальному світі.
Наше завдання — розв’язати проблему замовника з такою якістю, за яку ми можемо відповідати в умовах промислової експлуатації.
У середині 2025 року близько 15 наших інженерів із впровадження працювали з великим замовником із напівпровідникової галузі над понад 10 сценаріями використання. Мета полягала в тому, щоб побудувати процес верифікації на основі ШІ, охопивши такі напрями:
Генерування цільових тестів
Аналіз першопричин і налагодження
Асистент із проєктування архітектури
У цій галузі на верифікацію може припадати близько 70% трудовитрат проєкту. Потенціал був величезним, і почати можна було з багатьох напрямів.
Деякі інженери із впровадження приєдналися до OpenAI лише кілька днів тому й ніколи не працювали в напівпровідниковій галузі. Вони долучилися до команди верифікації замовника, у вільний час вивчали проєктування мікросхем і разом з інженерами створювали оцінювальні тести, щоб перевірити, чи здатен ШІ генерувати корисні тести й правильно діагностувати збої мікросхем.
Паралельно з навчанням ми створювали спеціальні системи harness для окремих сценаріїв використання. За перші 3–6 місяців усі вони вийшли в промислову експлуатацію та здобули перших користувачів. Результат став очевидним у показниках:
Близько 48% економії часу завдяки генеруванню цільових тестів за допомогою ШІ.
Медіанне підвищення продуктивності на 22% завдяки оптимізації ядер.
Тижні налагодження скоротилися до годин
Коли ми представили всі ці результати, директор з апаратного забезпечення запитав: «Ви що, працювали розробниками мікросхем, перш ніж прийти сюди?»
Наші інженери із впровадження не мусять знати галузь із першого дня, але зобов’язані її вивчити.
Оскільки асистенти з програмування прискорюють розробку ПЗ, розуміння бізнесу замовника стає ще важливішим. Ми формуємо команди, поєднуючи фахівців широкого профілю та галузевих експертів.
Потрібно достатньо знань, щоб ухвалювати зважені рішення, і достатньо допитливості, щоб ставити під сумнів усталені уявлення.
Наприклад, у науках про життя наукова підготовка наших інженерів із впровадження допомагає їм здобувати довіру дослідників, які працюють над доклінічними етапами пошуку ліків: валідацією та пріоритизацією мішеней, аналізом експресії генів і відновленням маршрутів хімічного синтезу. Ці знання дають їм змогу обґрунтовано пропонувати вдосконалення таких робочих процесів.
Ми показали, що ці робочі процеси можуть приносити користь, але для перенесення до іншої команди кожен із них усе ще потребував забагато індивідуальної роботи з інтеграції. Наступним завданням було зберегти ці результати, водночас спростивши розгортання й супровід програмного забезпечення.
На той час можливості Codex розширилися. Один інженер із впровадження спробував перебудувати застосунок на його основі, а потім разом із командою переніс сценарії використання на спільну систему harness із Codex у центрі.
Спеціально розроблені застосунки стали плагінами й навичками, побудованими на спільних базових компонентах Codex. Codex також став інтерфейсом, що дало змогу відмовитися від окремих термінальних інтерфейсів і CLI, які ми написали для індивідуальних сценаріїв використання.
Ми змогли прибрати приблизно 90% спеціально написаного коду з кожного проєкту, і це змінило наш підхід до створення, супроводу й масштабування цих робочих процесів:
Ми могли користуватися централізованими вдосконаленнями Codex, зменшуючи обсяг інтеграційного коду для кожного окремого сценарію використання
Ключові функції було оформлено як навички й плагіни, якими стало простіше обмінюватися та централізовано керувати через центр компетенцій із ШІ. Це означало, що для перенесення рішення з однієї команди до іншої могло бути достатньо замінити конектори чи MCP-сервери, створити нові оцінювальні тести (для цього ми теж мали навичку) і почати роботу.
В одному з випадків у серпні 2026 року початкове впровадження тривало два місяці. Поширення рішення на другу команду зайняло один день. У міру масштабування наступні команди долучалися швидше. Ця тенденція збереглася: у серпні 2026 року впровадження одного сценарію використання для другої команди зайняло 1 день, тоді як початкове впровадження тривало 2 місяці.
Це один зі способів зробити нашу участь непотрібною. Робота над виходом у промислову експлуатацію показала, що справді важливо. З удосконаленням базового продукту ми змогли замінити значну частину нашої індивідуальної реалізації, зберігши її користь.
Саме тому послідовність важлива. LLM дають змогу швидко розробляти рішення. Використовуйте цю швидкість, щоб дати користувачам щось цінне, з’ясувати, що витримує перевірку практикою, а потім масштабувати те, що працює.
Той самий принцип діє в усіх проєктах із замовниками.
OpenAI Presence, наш продукт для корпоративних голосових та чат-агентів, виник із реальних розгортань клієнтів. Робота почалася зі Swarm(відкривається у новому вікні) і розвивалася протягом Агенти API, і сьогодні один клієнт обробляє більше половини своїх дзвінків за допомогою ШІ.
Введення цих розгортань у продакшн навчило нас, які проблеми потребують індивідуального рішення, а які будівельні блоки можуть використовувати інші команди. Ми внесли ці будівельні блоки в Presence, що полегшило розробникам автоматизувати регульовані робочі процеси без перебудови базової інфраструктури. Кожне впровадження допомагало формувати продукт і давало наступному клієнту кращу відправну точку.
З Thrive Holdings,OpenAI FDE та дослідники працювали разом з інженерами та бухгалтерами над створенням податкового ШІ для бухгалтерських фірм Криту. Під час пілотного проекту Tax AI обробив 7 000 податкових декларацій і збільшив пропускну здатність приблизно на 50%.
Одним із найскладніших викликів була автоматизація повернень за орендовану нерухомість, що вимагало шести тижнів інженерного та експертного огляду для досягнення 90% точності та відклику. Ця робота створила повторно використовувані шаблони, які полегшили розширення податкового ШІ на інші складні податкові графіки.
Тепер команди застосовують той самий підхід до ведення бухгалтерії, аудиту та ІТ-підтримки — створюючи системи, які покращуються завдяки зворотному зв'язку від практиків і реальному використанню.
Іноді вдосконалення продукту дає змогу спростити створене нами рішення, але іноді сама модель ще не здатна виконати завдання.
Якщо ми створюватимемо лише те, що вже дозволяють сучасні моделі, то не виявимо прогалин у можливостях ШІ, які дослідницькій команді потрібно усунути наступними. Тому багато наших важливих проєктів починаються саме на межі цих можливостей, а замовник, інженери із впровадження та дослідницька команда беруться разом долати обмеження.
Ми вже розробили платформу обслуговування клієнтів разом із великою телекомунікаційною компанією, і вона хотіла додати до неї голосовий канал.
На голосові звернення припадало близько 90% навантаження на її службу підтримки. Автоматична обробка таких звернень коштувала дорожче, ніж у чаті, і створювала низку нових технічних викликів: роботу з акцентами, тон мовлення, затримку й точність потрібно було довести до рівня, придатного для промислової експлуатації. Успішне рішення могло суттєво вплинути на бізнес компанії.
На етапі визначення обсягу робіт наша модель набирала близько 60% у ключових оцінювальних тестах, за якими ми визначали її готовність до промислової експлуатації. Ми досягли межі її можливостей. Потрібно було поліпшити виклик функцій і дотримання інструкцій у сценаріях обслуговування клієнтів.
Ми пояснили це замовнику й залучили до роботи дослідницьку команду. Інженери із впровадження працювали із замовником над створенням платформи та визначенням того, що має робити модель. Дослідницька команда усувала прогалини в можливостях моделі, а її послідовні версії давали змогу перевіряти поступ відповідно до вимог замовника.
За шість місяців результати ключових оцінювальних тестів зросли приблизно з 60% до 80%, а потім перевищили 90%, досягнувши рівня, потрібного для промислової експлуатації.
Створена голосова модель тепер працює в рішенні цього замовника, в інших індивідуальних рішеннях для обслуговування клієнтів і в керованих розгортаннях через Presence. Проблема в бізнесі одного замовника допомогла визначити вдосконалення, корисні для багатьох інших.
Важливим був кожен складник. Замовник погодився працювати над проблемою, яку модель ще не могла розв’язати. Інженери із впровадження були достатньо залучені, щоб чітко сформулювати проблему, створити платформу й вести проєкт від початку до кінця. Дослідницька команда вдосконалила базові можливості моделі.
Це ще один спосіб зробити нашу участь непотрібною: допомогти перетворити проблему, яку сучасні моделі не можуть розв’язати, на можливість, яку матимуть майбутні моделі. Віддача від нашої роботи виходить за межі годин, проведених із будь-яким окремим замовником.
Я приєднався до OpenAI, щоб допомогти зробити ШІ корисним у повсякденній роботі людей. Це й досі визначає напрям роботи команди. Я часто кажу команді, що в розробці LLM здебільшого діє принцип бритви Оккама: найпростіше рішення — найкраще. У компанії, яку визначають передові дослідження, і в галузі, репутацію якої псують гучні перебільшення, ми хочемо створювати надійні рішення, на які можуть покластися фахівці-практики.
Мета — щоб кожен проєкт покращував наступний: робив продукт простішим у впровадженні, модель — здатною виконувати складніші завдання, а обсяг індивідуальних доопрацювань для наступного замовника — меншим.
Якщо у вас є складна проблема, яку ви хочете розв’язати, ми будемо раді співпраці. Якщо ви хочете допомагати розв’язувати такі проблеми, будемо раді бачити вас у нашій команді.
То що ми робимо, коли Codex уже може виконувати завдання, над рішенням для яких ми працювали місяцями?
Шукаємо складнішу проблему.
