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

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

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

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

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

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

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