Предисловие и вводная глава

В классическом ML команда сначала собирала и размечала данные, выбирала архитектуру, обучала модель и только затем встраивала её в продукт. Foundation models уже несут знания из масштабного pre-training и доступны через API, поэтому AI-инженер может начать с пользовательского сценария. Текст, изображение и звук представляются токенами; модель предсказывает продолжение по контексту, а self-supervised learning позволяет учиться на самом корпусе без отдельной разметки каждого примера. Это снижает порог входа, но не отменяет зависимости качества от языков и доменов, представленных в обучающих данных.

Такая коммодитизация расширила набор экономически возможных задач. В разговоре появляются генерация и проверка медицинского контента, модерация, sentiment analysis, анализ кода и архитектурных документов, перевод и создание интерфейсов по макету. Мультимодальная модель может превратить скриншот Figma в описание внутреннего DSL или подобрать визуал к тексту; один универсальный LLM-блок способен заменить цепочку узких классификаторов. Однако доступность прототипа не означает готовность к эксплуатации: качество, безопасность, приватность и специфический контекст всё равно приходится проектировать вокруг модели.

Участники противопоставляют внешний хайп практическому внедрению. Бизнес ждёт магического ускорения и просит добавить AI почти в любой процесс, но устойчивый эффект появляется, когда возможность модели встроена в конкретную работу. Евгений описывает помощника, подключённого через инструменты к Google Drive, Confluence и инженерным метрикам: он помогает находить ADR, выявлять противоречия и увеличивает объём ревью. Александр связывает это с platform engineering: сначала платформа ассистирует сотруднику внутри знакомого сценария, а затем отдельные операции можно передавать агентам.

Внутренние приложения часто становятся безопасным первым полигоном. Компания знает пользователей, быстрее получает обратную связь и может измерить время работы, не подвергая клиента ответу, который ещё трудно гарантировать. В медицине, финансах и других регулируемых областях цена ошибки и требования к данным выше, поэтому нужны договорённости с провайдерами или модели внутри контура. Команда должна сочетать вычислимые сигналы с LLM-оценкой, декомпозировать сложную проверку и сохранять человека там, где модель не может надёжно подтвердить вывод.

Стоимость интеллектуальной работы моделей падает, а качество следования инструкциям растёт. Поэтому сценарий, который сегодня едва окупается, через несколько месяцев может стать жизнеспособным. При этом не всякой операции нужна самая сильная модель: простые запросы можно направлять в дешёвую или локальную модель, а сложные — в облачную, используя более мощную модель как критика. Eval-driven разработка превращает выбор в инженерный компромисс между качеством, стоимостью и задержкой; вероятностные результаты требуют диапазонов и повторяемых проверок, а не ожидания одного точного значения.

Стек постепенно разделяется на разработку моделей, инфраструктуру, платформенные сервисы и прикладные AI-продукты. Большинство инженеров будет работать на верхнем слое, не зная всех деталей обучения, как пользователи Kubernetes не обязаны знать его внутренности. Быстрое прототипирование демократизирует проверку гипотез, но переход в production остаётся дорогим: нужны собственные evals, ограничения и данные. Публичные бенчмарки лишь отсеивают явно неподходящие модели, потому что результаты зависят от методологии; окончательный выбор должен проверяться на сценариях конкретного продукта.