Я не жду от хорошего инженера, что он обучит модель. Это само собой разумеется. Разработка моделей стала практически комодити: есть тонна готовых LLM, которые надо только запромптить, а если нужна своя — есть гора готовых решений и туториалов, как её дообучить. Скоро Claude Code будет делать это не хуже нас.
Ценность инженера в том, что он берёт ответственность за успех проекта целиком. От формулировки гипотезы до деплоя и мониторинга качества в проде. Он — главный технический менеджер проекта, а не просто производитель абстрактных моделей.
И в AI это особенно важно. LLM-разработка — это жёсткий R&D, где заранее не понятно ничего. Здесь на первый план выходят не те, кто красиво обучает модели, а те, кто умеет вести сложный непонятный проект: быстро проверять гипотезы и гибко приоритизировать на ходу. Именно эту роль должен взять на себя AI-инженер.
Дальше — по пунктам, что отличает хорошего от плохого (за саму идею такого списка спасибо Бену Хоровицу)
Ответственность. Хороший инженер отвечает за итоговый результат всего проекта. Плохой отвечает за то, что модель обучена и лежит в репозитории. Хороший оценивает свой результат зеленым цветом в AB-эксперименте; плохой — современностью архитектуры трансформера и красотой его графика на валидации. Хороший берёт неопределённость R&D как условие задачи и всё равно верстает план. Плохой полгода объясняет, почему задача очень сложное и заранее проверить нельзя.
Бизнес-метрики. Хороший мыслит бизнес-метриками. Он сам чувствует, качнёт ли спроектированное решение то, что нужно бизнесу, и если интуиция говорит «нет» — спорит с постановкой, а не молча делает. Плохой слепо доверяется продакту: что сказали сделать — то и делаю, а сработает или нет — не моя зона. Хороший держит в голове связь между технической метрикой и деньгами; плохой гонится за лишними процентами accuracy, которые на бизнес не влияют никак.
Фокус. Хороший держит фокус. Он не строит сразу монстр-план, которого начитался в посте на Хабре, и не пытается сделать всё и сразу — он работает над локальной задачей, которая приближает к цели. Плохой проектирует космолёт на полгода вперёд и 95% этой работы потом выбрасывает. Хороший готов выкинуть собственное решение, если оно не приближает к цели; плохой влюблён в архитектуру, которую рисовал три недели, и тащит её до конца из принципа.
Гипотезы. Хороший мыслит через гипотезы. Он бьёт задачу на подзадачи и проверяет их по одной, шаг за шагом, не теряя фокус. Плохой крутит десять ручек одновременно и потом не понимает, какая из них дала эффект. Хороший после каждой проверки знает, подтвердилась гипотеза или нет, и что делать дальше; плохой накручивает изменения слоями и теряет нить, что вообще происходит с качеством.
Метрики качества. Хороший дизайнит офлайн-метрику под каждую гипотезу, чтобы проверить её быстро и честно, ещё до того, как ждать пользовательских данных. Плохой смотрит на пару примеров и решает на глаз, что «вроде стало лучше». Хороший понимает процесс согласования разметок качества и может сам настроить процесс разметки данных. Плохой сваливает все на анлитиков, ожидая от них готовых чистых датасетов.
Инструмент под задачу. Хороший подбирает инструмент под задачу. Не забивает гвозди микроскопом: если на промпте уже работает на 80%, он не уходит в RLHF и дообучение ради процентов, которые никому не нужны. Плохой тащит самую тяжёлую технику просто потому, что она звучит солидно и хорошо смотрится в резюме. Хороший начинает с самого дешёвого и простого решения и усложняет, только когда упёрся; плохой стартует со сложного и потом не может объяснить, зачем оно.
Поддержка. Хороший думает про поддержку решения наперёд. Он понимает, что при дрейфе входных данных промпт сможет поправить любой бизнес-эксперт, и выбирает это вместо сложного MLOps-пайплайна с переобучением моделей. Плохой строит хрупкую конструкцию, которую кроме него самого никто не может сопровождать. Хороший ставит мониторинг сразу — дашборды с техническими и продуктовыми метриками, чтобы поломку было видно в момент, а не из жалоб пользователей; плохой узнаёт, что качество просело, когда приходит разгневанный продакт. Хороший проектирует так, чтобы команда жила с этим решением годами; плохой думает только том, чтобы работало у него одного.
Лидерство. Хороший — это технический лидер проекта, и он умеет работать со смежными командами. Он убеждает всех, что мы идём правильным путём, даже когда сам до конца не уверен, — потому что в R&D заранее не уверен никто. Плохой отмалчивается и кивает на то, что «прогноз дать невозможно, и он сам ничего не знает». Хороший фиксирует важные решения письменно и доносит их так, что все коллеги все понимают, что и зачем делается; плохой держит всё на словах и в себе и потом удивляется, что его поняли не так.
Инфраструктура. Хороший отвечает за работопособность своего сервиса. Он думает про нагрузку и сложность внедрения своего решения, заранее считает GPU-ресурсы и делает так, чтобы его систему было легко встроить в продакшен. Плохой кидает модель «через забор» и вспоминает про ресурсы, когда его случайно спросил продакт. Хороший с первого дня держит в голове latency и стоимость запроса и как это связано с экномикой проекта; плохой оптимизирует это в последний момент, когда переделывать уже дорого.
Аналитика. Хороший инженер точно знает, как считается каждая метрика и как оценивается решение, и сам подсказывает, какие аспекты стоит ещё проверить. Плохой не знает, откуда берутся цифры, по которым его судят. Хороший доверяет замеру, потому что разобрался в методике; плохой спорит с результатами A/B-теста, не понимая, как тот работает.
Вовлеченность во все. Хорошего инженера можно в любую секунду спросить, что конкретно сейчас разрабатывается в проекте, а что будет завтра — и он ответит, что именно, и почему именно в таком порядке. Плохой на это скажет «разрабатываю модель, качаю метрики».
Собрать модель скоро сможет почти кто угодно. Взять ответственность за результат, разложить все на кусочки, задрайвить команду и дойти до цели в срок — только хороший AI-инженер.