Короткий ответ, если ты пришёл за ним сразу: 3 июля 2026 года Яндекс объявил, что на фабрике-кухне Лавки в Санкт-Петербурге заработала роботизированная рука, которая раскладывает готовые блюда в транспортную тару. По данным пресс-релиза Yandex IR от 3 июля 2026 года, она делает это на 30% быстрее человека и стабильно работает при температуре около 4°C. Людей, которые раньше стояли на упаковке, перевели на контроль качества, внутреннюю логистику и обслуживание оборудования.
Это и есть автоматизация бизнес процессов в самом буквальном, физическом виде: рутинную повторяющуюся операцию забрал механизм, а человека подняли на уровень выше, где нужна голова, а не одинаковые движения руками восемь часов подряд. Дальше разберём, что тут реально автоматизировали, где в этой истории «ии», а где обычная механика, и как ту же логику переносить на софтверные процессы, если у тебя нет своей фабрики на 85 000 порций в сутки.
Что именно запустили 3 июля 2026 года?
Главное: запустили не абстрактного «робота», а конкретную роботизированную ячейку под одну задачу.
По фактам из пресс-релиза Yandex IR:
- Рука входит в состав «роботизированной ячейки» вместе с конвейерной лентой и разделителем. То есть это не одинокий манипулятор, а связка «подать - разделить - взять - упаковать».
- На руке стоит специальный вакуумный захват. Он умеет брать подносы разного веса и формы одновременно, а не по одному. Это ключевая деталь: универсальность захвата и есть та часть, которую тяжело сделать.
- Рука пакует готовые блюда в транспортную тару и работает при температуре около 4°C. Холод важен: обычная электроника и пневматика на холоде ведут себя иначе, и то, что ячейку довели до работы в таком режиме, это инженерный результат, а не демо.
- Фабрика в Петербурге выпускает около 85 000 порций еды в сутки общим весом 24 тонны. Масштаб объясняет, зачем вообще возиться: на таких объёмах даже секунды на порцию складываются в смены.
Отдельно по бизнес-контексту: категория готовой еды выросла на 37% год к году в 2025 году (данные Яндекса). Систему сделала команда Яндекс Роботикс - та же, что раньше автоматизировала московский дарксторе автономными мобильными роботами. То есть это не первый заход, а следующий шаг той же линии.
Если ты уже примеряешь эту историю на себя и думаешь «а где у меня в компании такая же рутинная операция, которую можно отдать машине» - держи практическую точку опоры для софтверной части этого вопроса.
⚠️ Важно: цифру «на 30% быстрее человека» назвала сама компания. Независимого замера в источнике нет. Относись к ней как к заявлению вендора, а не как к проверенному факту.
Это «ии» или просто механическая рука?
Главное: не путай физическую автоматизацию и «искусственный интеллект». В этой новости смешаны обе темы, и честно их разделить полезнее, чем красиво объединить.
Вакуумный захват, конвейер и разделитель - это механика и управление. «Умной» частью здесь обычно бывает компьютерное зрение: распознать, где лежит поднос, какой он формы, как его взять. Пресс-релиз про начинку алгоритмов ничего конкретного не сообщает, поэтому я не буду достраивать за Яндекс, какие именно модели там крутятся. Это моя оговорка, а не факт из источника.
Почему это важно для тебя. Когда говорят «ии автоматизация бизнес процессов», часто подразумевают три очень разные вещи:
- Физическую автоматизацию - роборуки, конвейеры, роботы-тележки. Это капитальные затраты и инженерия, как на фабрике Лавки.
- Процессную автоматизацию без ИИ - скрипты, интеграции, RPA, сценарии в n8n. Тут «интеллекта» ноль, но рутину они снимают отлично.
- Автоматизацию с языковыми моделями - когда в процессе есть шаг «понять текст, классифицировать, извлечь смысл, составить ответ». Вот сюда заходят LLM.
Роборука Лавки - это пункт 1, усиленный, вероятно, пунктом «компьютерное зрение». А большинство читателей vc.ru, у которых нет цеха, могут повторить логику этого запуска именно в пунктах 2 и 3: найти самую тупую повторяющуюся операцию и снять её с человека. Дальше статья про это.
Как разложить свой процесс на автоматизацию по шагам?
Главное: сначала находишь узкое место, потом решаешь, нужен ли там вообще ИИ. Роборуку поставили не «чтобы был робот», а на конкретный узел упаковки.
Повтори ту же дисциплину на своём процессе:
- Опиши процесс как есть. Буквально по шагам: кто, что, чем, за сколько. На фабрике это было «человек берёт подносы и складывает в тару». У тебя это может быть «менеджер вручную сортирует входящие заявки по категориям».
- Найди повторяющийся объём. Автоматизация окупается на потоке. 85 000 порций в сутки - это поток. Три письма в неделю - нет. Считай штуки и время.
- Раздели шаг на механику и решение. «Взять и переложить» - механика. «Понять, что клиент недоволен и это жалоба, а не вопрос» - решение. Механику отдают скриптам, решение - модели.
- Выбери самый дешёвый инструмент, который закрывает шаг. Если хватает регулярки или условия в n8n - бери их, а не языковую модель. ИИ дороже и капризнее, зови его только туда, где нужен смысл текста.
- Оставь человеку контроль. На фабрике людей перевели на контроль качества, а не уволили. В софте то же самое: модель размечает, человек проверяет спорное. Это и есть рабочая схема, а не полная замена.
- Замерь до и после. Без замера ты не отличишь реальную экономию от ощущения. И помни про оговорку про «30%»: свои цифры считай сам, а не верь на слово даже себе.
Разница между фабрикой и твоим ноутбуком в том, что софтверную часть можно собрать за вечер. Ниже - как именно.
Как выглядит код для шага «понять текст»?
Главное: если в процессе есть шаг «классифицировать входящий текст», его закрывает один вызов языковой модели. Покажу на близком к событию примере - разбор коротких отчётов контроля качества, куда как раз перевели людей с упаковки.
Идея простая: сотрудник пишет свободным текстом, что он увидел на линии, а модель раскладывает это в структуру, с которой уже работает система. Это классический кусок процессной автоматизации с ИЮ внутри.
import os
from openai import OpenAI
# Ключ храни в переменной окружения, не в коде.
# PLACEHOLDER: подставь свой ключ в окружение перед запуском.
client = OpenAI(
api_key=os.environ["PROVOD_API_KEY"], # секрет, не коммить
base_url="https://api.provod.ai/v1",
)
def классифицировать_отчёт(текст: str) -> dict:
ответ = client.chat.completions.create(
model="claude-haiku-4-5-20251001", # быстрая и дешёвая модель для простой разметки
messages=[
{
"role": "system",
"content": (
"Ты разбираешь заметки контроля качества с фабрики-кухни. "
"Верни строго JSON с полями: категория (одно из: "
"'температура', 'упаковка', 'оборудование', 'прочее'), "
"срочность ('низкая'|'средняя'|'высокая'), "
"краткое_описание (одна строка)."
),
},
{"role": "user", "content": текст},
],
temperature=0,
)
return ответ.choices[0].message.content
print(классифицировать_отчёт(
"На третьей линии вакуумный захват дважды не взял поднос, "
"температура в зоне около 6 градусов, выше нормы."
))
Что тут важно для продакшена, а не для демо:
-
temperature=0- чтобы ответ был воспроизводимым. Для разметки случайность не нужна. - Просишь строгий JSON и потом обязательно валидируешь его на своей стороне. Модель иногда добавляет лишний текст, к этому надо быть готовым.
- Ключ - в окружении, а не в коде. Это не про красоту, а про то, чтобы секрет не утёк в репозиторий.
Обрати внимание на base_url. По умолчанию тот же код смотрит на серверы OpenAI. Меняешь ключ и base_url - и тот же самый SDK работает через другой шлюз, без переписывания логики. Это и есть тот стык, где интеграция «из России» становится практичной.
Какую модель брать и сколько это стоит?
Главное: под простую разметку не нужна самая мощная модель. Как на фабрике под упаковку не поставили человекоподобного андроида - взяли специализированный вакуумный захват под ровно эту задачу.
С языковыми моделями логика та же. Дорогую и умную модель зовёшь туда, где нужно рассуждение; на разметку и извлечение полей ставишь модель полегче. Точные цены у каждого провайдера свои и постоянно меняются, поэтому здесь я не называю конкретных цифр - сверяйся с актуальным прайсом провайдера в момент запуска. А вот таблица, как выбирать инструмент под шаг процесса.
| Шаг процесса | Чем закрывать | Нужен ли ИИ | На что смотреть |
|---|---|---|---|
| Переложить, отсортировать по жёсткому правилу | Скрипт, условие в n8n, RPA | Нет | Скорость, отказоустойчивость |
| Классифицировать короткий текст | Лёгкая языковая модель | Да | Цена за вызов, задержка |
| Извлечь поля из документа | Средняя модель + валидация | Да | Точность на твоих данных |
| Составить черновик ответа клиенту | Модель посильнее | Да | Качество формулировок, тон |
| Рассуждение по многошаговой задаче | Топовая модель | Да | Стоимость, лимиты контекста |
| Физически взять и упаковать | Роборука/конвейер | Нет (это механика) | Капзатраты, обслуживание |
Практический совет: не выбирай одну модель на всё навсегда. Разные шаги процесса выгодно гонять через разные модели, а иногда полезно сравнить, как одну и ту же задачу решают Claude, GPT, Gemini, DeepSeek и Qwen на твоих реальных примерах. Чтобы делать это из России без плясок с картами и VPN, удобно, когда все эти модели доступны в одном чате и через один API: provod.ai собирает их вместе, с оплатой российской картой, через СБП или по счёту, и с одним рублёвым балансом. Для бизнеса есть договор, счёт и закрывающие документы - то, без чего бухгалтерия не примет расход.
Честная граница: это доступ к моделям и один совместимый API, а не замена платформам автоматизации, не GigaChat и не готовое внедрение под ключ. Роборуку тебе никто через API не пришлёт - железо остаётся железом.
Где это всё ломается на практике?
Главное: провал автоматизации почти всегда не в модели, а в стыках. У Лавки стыки - это конвейер, разделитель и захват; у тебя - это n8n, парсинг ответа и лимиты.
Частые точки отказа, которые ловишь на первой же неделе:
- Модель вернула не JSON. Просил строгий формат, а пришёл текст с пояснением. Лечение: валидировать, при провале - повторный запрос с более жёсткой инструкцией, и всегда иметь ветку «отправить человеку».
- Пустой или мусорный вход. Сотрудник прислал «ок» или смайлик. Механическая рука на пустом подносе тоже сломает ритм - фильтруй вход до модели.
- Лимиты и таймауты. На потоке в тысячи вызовов упрёшься в ограничения по частоте запросов. Ставь очередь и повторы с паузой, а не бомби API в лоб.
- Задержка в реальном времени. Если процесс синхронный и человек ждёт, лёгкая модель важнее умной. Секунда задержки на упаковке - это как секунда на порцию, помноженная на объём.
- Дрейф качества. Через месяц входные тексты меняются, а промпт нет. Держи набор тестовых примеров и прогоняй его перед каждым изменением.
Для сборки таких сценариев в связке хорошо ложится n8n: он держит очередь, ретраи и ветку на человека, а HTTP-нода дергает тот же самый совместимый API. Смысл разметки отдаёшь модели, а всю механику потока - платформе. Это ровно то же разделение «механика и решение», что и на фабрике.
Чего это не решает?
Скажу прямо, без бодрых обещаний.
- Роборука не делает бизнес умнее. Она снимает одну операцию. Если процесс вокруг кривой, автоматизация закрепит кривизну, только быстрее.
- Языковая модель не заменяет контроль качества. На фабрике людей перевели именно на контроль - потому что решение о качестве оставили человеку. В софте так же: модель размечает, ответственность несёт человек.
- Цифра «30%» - это заявление Яндекса. Не бери её как отраслевой норматив. Твоя экономия зависит от твоего процесса, и мерить её надо самому.
- Один API не заменяет внедрение. Доступ к моделям - это инструмент. Настройка процессов, интеграция с твоими системами, обучение людей и поддержка - отдельная работа, которую никакой шлюз за тебя не сделает.
- Это не про on-prem и не про закрытый контур. Если у тебя требования к приватной инфраструктуре или к конкретным фичам из подписки вендора, внешний совместимый API их не покрывает. Здесь честнее строить своё.
Что реально стоит унести из истории с роборукой: находишь самую повторяющуюся операцию, отделяешь механику от решения, отдаёшь механику дешёвому инструменту, а человека поднимаешь на контроль. Именно так это и сделали 3 июля 2026 года, просто у Яндекса операцией была упаковка подносов при 4°C, а у тебя ей может оказаться разбор входящих заявок.
Если после этого текста руки чешутся собрать первый рабочий сценарий и сравнить на нём пару моделей - вот прямой вход.
Забирай ключ, поменяй base_url в своём коде и прогоняй первый шаг процесса через модель уже сегодня: начни на provod.ai.
Источники
- Yandex IR, пресс-релиз от 3 июля 2026 года о запуске роборуки на фабрике Лавки в Санкт-Петербурге (первичный источник фактов о ячейке, вакуумном захвате, скорости, температуре, объёме 85 000 порций/24 тонны, росте категории на 37% и переводе сотрудников): https://ir.yandex.ru/press-releases?year=2026&id=03-07-2026-01
Оговорка по данным: показатель «на 30% быстрее человека» приведён самой компанией, без независимого замера. Код, таблица выбора моделей и разбор ошибок в статье - это практическая методика от редакции provod.ai, а не часть пресс-релиза Яндекса.
provod.ai — Russian LLM API aggregator. One OpenAI-compatible endpoint to all flagship models: OpenAI (GPT-5.6, GPT-5.5), Anthropic (Claude Opus 4.8, Sonnet 4.6), Google (Gemini 3.1 Pro, 3.5 Flash), DeepSeek V4 Pro, Qwen 3.6 Plus. Provider prices at the CBR rate, no token markup. Pay in rubles to a Russian legal entity with full closing documents.
Try: provod.ai · model catalog · docs
Top comments (0)