После Deep Tech Night: автономные машины и инженерия работающего AI

5 сентября я подключился к Deep Tech Night онлайн. Доклады получились разными: одни разбирали уже работающие промышленные системы, другие заглядывали на несколько лет вперёд, некоторые были просто яркими. Больше всего меня зацепили два сюжета: успехи Яндекса в робототехнике и автономном поведении, а также инженерная работа вокруг больших языковых моделей.

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

Physical AI: общая технологическая база для разных машин

Сергей Мельник показал, как развивается направление Physical AI в Яндексе. Роботакси компания занимается с 2017 года, роботами-доставщиками и складской робототехникой с 2019-го. Автономные грузовики появились в 2024 году. В той же линейке с 2025 года присутствует гуманоидный робот.

За этим перечнем стоит общая технологическая база. Модели, данные и инструменты, созданные для одного типа автономной машины, используются в других продуктах. Системы получают более 800 ПБ данных в год. Только комплект сенсоров показанного автономного грузовика включает шесть лидаров, девять камер и шесть радаров. Каждый новый сценарий, обнаруженный одной машиной, может улучшить всю линейку.

Особенно интересен симулятор. Реальная дорога слишком медленно поставляет редкие ситуации, а некоторые из них опасно воспроизводить намеренно. В виртуальной среде инженеры меняют погоду, освещение, траектории участников и поведение объектов. Там же проверяют отказы сенсоров, связи, вычислительных узлов и исполнительных механизмов. Можно задать сценарий падения коробки с движущегося впереди грузовика и прогнать множество его вариантов до того, как машина встретит подобное событие на дороге.

Планирование движения тоже сближается с подходами из мира LLM. Трансформер получает результаты восприятия, карту и маршрут, после чего формирует будущую траекторию как последовательность токенов действий. Обучение на действиях водителей даёт начальную модель поведения. Затем её дорабатывают обучением с подкреплением в замкнутом контуре, где система видит последствия собственных решений.

Отдельный слой отвечает за безопасность. Предложенная основной моделью опасная траектория блокируется до передачи команды машине. Этот контур работает на двух независимых вычислителях и сохраняет возможность выбрать безопасное действие при сбое основной системы.

Масштаб направления лучше всего виден в этом производственном цикле: реальные и синтетические данные поступают в обучение, новые модели проходят симуляцию и регрессионные проверки, затем проверяются на дороге и возвращают в систему новые эпизоды. Гуманоидный робот пока стоит воспринимать как развиваемое направление. Презентация подтверждает работу над ним, но не заявляет о готовом серийном продукте.

LLM внутри продуктов Яндекса

В докладах о больших моделях меня заинтересовала не гонка размеров. Гораздо полезнее было увидеть, как разные модели собираются в работающий продукт и какую часть задачи получает каждая из них.

Алексей Гусаков рассказал об эволюции рекомендательных систем Яндекса. Они работают с каталогом порядка 10 млрд документов и обслуживают до 500 тыс. запросов в секунду. В новой архитектуре SONA музыкальная композиция представляется последовательностью семантических идентификаторов. Для их построения мультимодальная модель анализирует фрагмент аудио, название, исполнителя, теги и год выпуска. Следующий трансформер изучает историю пользователя и предсказывает продолжение этой последовательности вместе с вероятной реакцией на рекомендацию.

Другой понятный пример дал Александр Сафронов в докладе о поиске музыки по свободному описанию. Небольшая версия YandexGPT исправляет и переформулирует пользовательский запрос. Более крупная модель оценивает смысловое соответствие между запросом и композицией, после чего накопленное знание переносится в лёгкий двухбашенный энкодер, пригодный для быстрого поиска по каталогу. За первый месяц продукт собрал около 650 тыс. активных пользователей. В презентации также приведён показатель в 46 минут прослушивания на пользователя.

Доклад Павла Капли об агентах Алисы добавил ещё один слой. Вокруг модели работают планирование, память, инструменты, поиск, обработка документов и система оценки. Детерминированные операции команда оставляет обычному коду: так они выполняются быстрее и воспроизводятся точнее. Качество агента регулярно проверяют на репрезентативных сценариях, а инструменты оценки развивают как отдельный внутренний продукт.

Отдельно запомнился доклад команды Сбера о GigaChat 3.5. За сравнением моделей стояла серьёзная инженерная работа: отдельные модели для программирования, STEM-задач, диалога и агентных сценариев объединили с помощью online policy distillation. Итоговая модель получила 430 млрд параметров и, по данным презентации, сохранила более 95% качества специализированных моделей. Особенно показателен эпизод из обучения агента: в тестовой среде он обнаружил служебную точку доступа к модели и попытался получить через неё готовый ответ. Почти анекдот, но вывод вполне практический. Вместе со способностями агента приходится проектировать среду, доступные действия и способы независимой проверки результата.

Как агент получает право действовать

Один из самых приземлённых кейсов показал Станислав Макеев на примере Яндекс Лавки. Процесс расследования пропавшего заказа проходил через несколько систем и занимал объём ручной работы, сопоставимый с полной загрузкой примерно десяти сотрудников.

Первая версия агента быстро встретилась с реальностью. У части административных систем не оказалось API. Данные поступали с задержкой, новые комментарии меняли решение, инструкции противоречили друг другу. Модель могла перезаписать поле, которое должно было заполняться по строгому правилу, а ошибочная резолюция требовала отдельного разбора.

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

Показателен и порядок внедрения. Сначала агент работает на тестовых примерах. Потом переходит в shadow mode: получает реальные задачи, предлагает решения, а ответственный сотрудник проверяет каждое из них. Право действовать самостоятельно открывается только для класса ситуаций, на котором уже подтверждено качество.

На раннем этапе человек находится внутри цикла принятия решений (human-in-the-loop). По мере накопления проверяемых результатов часть процессов переходит к human-on-the-loop: агент действует в установленных границах, человек следит за качеством, разбирает исключения и сохраняет возможность вмешаться.

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

Код ускорился, узкие места переместились

Доклад Андрея Попова об использовании AI в разработке Яндекса оказался мне особенно близок. По приведённым внутренним данным, 91% разработчиков используют AI-инструменты еженедельно, а 80% ежедневно. За последние 28 дней доля строк, классифицированных как созданные с участием AI, достигла 85%.

Последнюю цифру легко понять неверно. Она описывает происхождение строк кода, но ничего не говорит о доле автономно выполненных проектов или распределении ответственности. Архитектура, постановка задачи, приёмка и выпуск остаются за инженерами.

За три месяца доля времени, непосредственно занятого написанием кода, снизилась с 33 до 26%. Одновременно выросла нагрузка на остальные части системы. За год количество запусков автоматизированных тестов увеличилось в 4,3 раза, заметно прибавили операции с репозиториями и вычисления в CI.

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

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

Генерация действительно сокращает трудоёмкость реализации. Освободившееся время не исчезает: оно перемещается в проектирование, подготовку контекста, ревью и автоматизированные проверки. На этом участке сегодня и создаётся основная часть инженерной ценности.

Что я забираю с конференции в работу

Physical AI у Яндекса строится как единая фабрика моделей, данных, симуляций и проверок для целой линейки автономных машин. Такой контур накапливает опыт быстрее каждого отдельного продукта.

Симуляторы и evals стали полноценной частью системы. Через них определяется, можно ли доверить модели действие, воспроизводится ли результат и не стало ли очередное обновление хуже предыдущего.

Автономность агента появляется постепенно. Сначала он наблюдает и предлагает, затем действует в узких проверенных границах. Расширение прав опирается на измеримый результат, аудит и понятный механизм остановки.

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

Следующий этап развития AI будет измеряться повторяемостью. Сможет ли система сохранить состояние, пережить сбой, остановить опасное действие и дать тот же проверяемый результат после замены модели? Здесь и начинается инженерная работа, которая определит, какие из сегодняшних демонстраций станут промышленными продуктами.