Что значит быть инженером по внедрению (FDE) в OpenAI
Чем мы занимаемся, как работаем и как решаем сложнейшие задачи бизнеса, добиваясь реальных результатов.
Автор: Колин Джарвис, руководитель направления инженерии внедрения в OpenAI
Когда вышел Codex, кто-то из команды спросил меня: «Что нам делать, когда Codex сможет за один раз решать задачи, над которыми мы работали последние несколько месяцев?»
Этот вопрос раскрывает саму суть работы инженера по внедрению (FDE) в OpenAI. Мы работаем бок о бок с заказчиками, чтобы понять их самые сложные задачи и создать решения, на которые они могут положиться. Полученный опыт помогает развивать наши продукты и даёт исследователям конкретные задачи.
В этом и заключается прогресс. Если каждые пару месяцев мы делаем так, что в нашей помощи больше не нуждаются, значит, команда инженеров по внедрению (FDE) выполняет свою задачу.
Я создал команду в начале 2025 года, чтобы устранить то, что мы называем «разрывом внедрения»: разницу между кажущимися возможностями моделей и тем, на что люди могут надёжно опираться в работе.
Возможности моделей развивались быстрее, чем системы и процессы, необходимые для их применения. Иногда недостающий элемент — это продукт. Иногда модель показывает хорошие результаты в бенчмарке, но не справляется с задачей в реальных условиях с их переменными факторами и ограничениями.
Мы сосредоточены на самых сложных задачах заказчиков. Там, где наши модели уже справляются, мы вместе с продуктовой командой и заказчиком делаем решение пригодным для повторного применения. А там, где возможностей не хватает, вместе с заказчиками и исследователями определяем пробелы и устраняем их. Наша цель — чтобы каждый проект давал следующему заказчику более прочную основу. Если мы поднимем базовый уровень настолько, что в следующий раз для решения задач этого класса заказчикам уже не понадобятся инженеры по внедрению (FDE), значит, мы хорошо сделали свою работу.
Перед John Deere, компанией с 200-летней историей в сельском хозяйстве, стояла задача: сделать персональные рекомендации доступными большему числу фермеров.
Один из примеров — See & Spray, технология точечной борьбы с сорняками. С помощью камер и машинного обучения она распознаёт и опрыскивает сорняки вместо обработки всего поля, что позволяет сократить расход химикатов до 70%.
Но для получения этих преимуществ фермеры должны знать, как настроить технологию, спланировать сезон и корректировать методы работы при изменении условий.
John Deere внедрила API OpenAI, чтобы сделать такую поддержку персонализированной и масштабируемой.
ИИ может отвечать на вопросы фермеров на естественном языке, давать индивидуальные рекомендации по настройке и работе, выявлять случаи, когда техника используется не в полную силу, и помогать фермерам понимать, какую пользу приносит технология.
Возможности не ограничиваются отдельной консультацией: актуальные рекомендации на всех этапах взаимодействия с клиентом помогают фермерам лучше использовать технику, повышая эффективность и снижая воздействие на окружающую среду.
Именно такие задачи решают инженеры по внедрению (FDE) OpenAI: помогают организациям превращать возможности ИИ в системы, которые приносят практическую пользу в сложных реальных условиях.
Но у задач часто нет чётких границ, может не быть общепринятого эталона правильного ответа, а готового плана действий нет вовсе. Все хотят создать то, чего ещё не существовало. Но немногие готовы сделать всё, что для этого нужно.
Чтобы находить талантливых инженеров по внедрению (FDE) и одновременно поднимать планку «достаточно хорошо», нам приходится постоянно экспериментировать и проверять идеи на практике.
В начале каждой встречи команды инженеров по внедрению (FDE) я показываю слайд с одним ключевым принципом: «Начните с результата, сделайте всё необходимое для успеха, а затем масштабируйте».
Впечатляющая демонстрация может долго обеспечивать успех, прежде чем кто-нибудь спросит, работает ли решение в реальных условиях.
Наша задача — решить проблему заказчика с таким качеством, за которое мы готовы отвечать в промышленной эксплуатации.
В середине 2025 года около 15 наших инженеров по внедрению (FDE) работали с крупной компанией полупроводниковой отрасли над более чем 10 сценариями применения. Мы стремились перестроить процесс верификации так, чтобы ИИ стал его основой. Работа охватывала:
Генерацию направленных тестов
Анализ первопричин и отладку
Создание помощника по архитектуре
В этой отрасли на верификацию может приходиться около 70% трудозатрат проекта. Потенциал был огромным, и начать можно было со множества задач.
Некоторые инженеры по внедрению (FDE) пришли в OpenAI всего за несколько дней до этого и никогда не работали с полупроводниками. Они стали частью команды верификации заказчика, в свободное время изучали проектирование микросхем и вместе с инженерами создавали тесты, чтобы проверить, способен ли ИИ генерировать полезные проверки и правильно диагностировать сбои микросхем.
Параллельно с изучением отрасли мы создавали специализированные обвязки для отдельных сценариев применения. За первые 3–6 месяцев все решения были введены в промышленную эксплуатацию, и ими начали пользоваться. Результатом стала наглядность показателей:
Экономия около 48% времени благодаря генерации направленных тестов с помощью ИИ.
Медианный прирост производительности на 22% благодаря оптимизации вычислительных ядер.
Отладка за часы вместо недель
Когда мы представили итоги, директор по аппаратным разработкам спросил: «Вы что, до прихода сюда работали проектировщиками микросхем?»
Наши инженеры по внедрению (FDE) не обязаны разбираться в отрасли с первого дня, но обязаны её изучить.
По мере того как помощники по программированию ускоряют разработку ПО, понимание бизнеса заказчика становится ещё важнее. В наших командах есть и специалисты широкого профиля, и отраслевые эксперты.
Нужно достаточно знаний для взвешенных решений и достаточно любознательности, чтобы ставить под сомнение привычный порядок вещей.
Например, в науках о жизни научная подготовка наших инженеров по внедрению (FDE) помогает им завоевать доверие исследователей, занимающихся доклинической разработкой лекарств: валидацией и приоритизацией мишеней, анализом экспрессии генов и реконструкцией путей химического синтеза. Эти знания позволяют им обоснованно предлагать улучшения рабочих процессов.
Мы показали, что эти рабочие процессы приносят пользу, но для переноса каждого из них в другую команду всё ещё требовалось слишком много индивидуальной работы по интеграции. Следующей задачей было сохранить результаты, упростив развёртывание и сопровождение ПО.
К тому времени возможности Codex выросли. Один инженер по внедрению (FDE) попробовал перестроить своё приложение на его основе, а затем вместе с командой перенёс сценарии применения на общую обвязку с Codex в основе.
Специализированные приложения превратились в плагины и навыки, построенные на общих базовых компонентах Codex. Codex стал и интерфейсом, что позволило отказаться от отдельных терминальных интерфейсов и интерфейсов командной строки, которые мы создавали для конкретных сценариев.
Мы смогли удалить примерно 90% специализированного кода из каждого проекта. Это изменило наш подход к созданию, сопровождению и масштабированию рабочих процессов:
Мы могли использовать централизованные улучшения Codex, сокращая объём связующего кода для каждого отдельного сценария
Основные функции были оформлены как навыки и плагины: ими стало проще обмениваться, а центр компетенций по ИИ получил возможность централизованно ими управлять. Теперь для переноса решения из одной команды в другую могло быть достаточно подключить новые коннекторы или MCP-серверы, создать новые оценочные тесты — для этого у нас тоже был навык — и начать работу.
В одном из проектов в августе 2026 года первоначальное внедрение заняло два месяца. А внедрение решения во второй команде — один день. По мере масштабирования следующие команды подключались всё быстрее. Эта тенденция сохранилась: в одном из проектов в августе 2026 года подключение второй команды заняло 1 день, тогда как первоначальное внедрение — 2 месяца.
Это один из способов сделать так, чтобы в нас больше не нуждались. Работа по подготовке к промышленной эксплуатации помогла определить, что действительно важно. По мере совершенствования базового продукта мы могли заменять значительную часть собственной реализации, сохраняя её пользу.
Вот почему важен порядок действий. LLM позволяют нам быстро создавать решения. Используйте эту скорость, чтобы дать пользователям что-то полезное, выяснить, что выдерживает проверку практикой, а затем масштабировать то, что работает.
Тот же принцип действует во всех проектах с заказчиками.
Наш продукт OpenAI Presence для корпоративных голосовых и чат-агентов появился благодаря реальному опыту внедрения у клиентов. Работа началась со Swarm(открывается в новом окне) и развивалась на протяжении всего процесса.API для агентов, и сегодня один из клиентов обрабатывает более половины своих звонков с помощью ИИ.
Внедрение этих решений в рабочую среду позволило нам понять, какие проблемы требуют индивидуального подхода, а какие компоненты могут использовать другие команды. Мы интегрировали эти компоненты в Presence, что упростило разработчикам автоматизацию регулируемых рабочих процессов без перестройки базовой инфраструктуры. Каждое внедрение помогало формировать продукт и предоставляло следующему клиенту более удобную отправную точку.
С компанией Thrive Holdings инженеры по внедрению решений и исследователи OpenAI работали над созданием Tax AI для бухгалтерских фирм сети Crete совместно с инженерами и бухгалтерами. В ходе пилотного проекта система Tax AI обработала 7000 налоговых деклараций и позволила увеличить объём обработки примерно на 50%.
Одной из самых сложных задач была автоматизация обработки данных по сдаваемой в аренду недвижимости, для достижения 90% точности и полноты потребовалось шесть недель инженерной работы и проверки специалистами. В результате работы были созданы многократно используемые шаблоны, которые упростили расширение применения Tax AI к другим сложным налоговым формам.
Теперь команды применяют тот же подход к ведению бухгалтерского учета, аудиту и ИТ-поддержке — создавая системы, которые совершенствуются благодаря отзывам специалистов и реальному использованию.
Иногда улучшение продукта позволяет упростить созданное нами решение, а иногда сама модель пока не справляется с задачей.
Если мы будем создавать только то, что уже позволяют нынешние модели, то не выявим пробелы в их возможностях, которые исследователям предстоит устранить. Поэтому многие наши важные проекты начинаются именно на границе этих возможностей: заказчик, инженеры по внедрению (FDE) и исследователи берутся вместе преодолеть ограничения.
Мы уже разработали платформу клиентского обслуживания вместе с крупной телекоммуникационной компанией, и она хотела добавить поддержку голосовых обращений.
На голосовые обращения приходилось около 90% всей нагрузки на службу поддержки. Обрабатывать такие обращения без участия оператора было дороже, чем сообщения в чате. Возник и ряд новых технических задач: нужно было довести распознавание акцентов, тон общения, задержку и точность до уровня, необходимого для промышленной эксплуатации. Успешное решение могло существенно повлиять на бизнес компании.
На этапе проработки проекта наша модель набирала около 60% в ключевых тестах, которыми мы оценивали её готовность к работе в реальных условиях. Мы достигли предела её возможностей. Нужно было улучшить вызов функций и следование инструкциям в сценариях клиентского обслуживания.
Мы объяснили это заказчику и подключили к работе исследовательскую команду. Инженеры по внедрению (FDE) вместе с заказчиком создавали платформу и определяли, что должна уметь модель. Исследователи работали над недостающими возможностями, а последовательные версии модели позволяли нам оценивать прогресс с учётом требований заказчика.
За шесть месяцев результаты в ключевых тестах выросли примерно с 60% до 80%, а затем превысили 90% — модель достигла уровня, необходимого для промышленной эксплуатации.
Созданная голосовая модель теперь используется в решении этого заказчика, в других специализированных решениях для клиентского обслуживания и в управляемых развёртываниях через Presence. Проблема, с которой столкнулся один заказчик, помогла определить улучшения, полезные для многих других.
Каждый участник сыграл важную роль. Заказчик взялся вместе с нами работать над задачей, которую модель пока не могла решить. Инженеры по внедрению (FDE) работали в тесном контакте с заказчиком, чтобы сформулировать задачу, создать платформу и довести проект от начала до конца. Исследователи улучшили базовые возможности модели.
Это другой способ сделать так, чтобы в нас больше не нуждались: помочь превратить задачу, непосильную нынешним моделям, в возможность, доступную будущим. Отдача от нашей работы выходит далеко за рамки часов, проведённых с отдельным заказчиком.
Я пришёл в OpenAI, чтобы помочь сделать ИИ полезным в повседневной работе людей. Эта цель по-прежнему направляет нашу команду. Я часто говорю команде, что при разработке с LLM в большинстве случаев действует бритва Оккама: самое простое решение — лучшее. Мы работаем в компании, основу которой составляют передовые исследования, и в отрасли, чью репутацию портят преувеличения. Поэтому мы хотим создавать надёжные решения, на которые специалисты могут положиться в реальной работе.
Наша цель — чтобы каждый проект улучшал то, что будет дальше: упрощал внедрение продукта, помогал модели справляться с более сложной задачей или сокращал объём индивидуальной разработки для следующего заказчика.
Если у вас есть сложная задача, которую вы хотите решить, мы будем рады поработать с вами. Если вы хотите помогать решать такие задачи, присоединяйтесь к нам.
Так что же нам делать, когда Codex справляется с работой, на создание решения для которой мы потратили месяцы?
Искать задачу сложнее.
