AI-система для роботов-компаньонов (Social Robots)

Почему социальный робот срывается в шаблон на третьей реплике

Первые две-три реплики робот-компаньон держит уверенно, дальше разговор осыпается в заученные фразы. Пользователь замечает это раньше инженера: он уже дважды сказал, о чём речь, а робот снова здоровается и предлагает тему заново.

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

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

Задержка ответа ломает ритм сильнее, чем неточность: пауза в несколько секунд читается как поломка, и человек уходит. Помогают короткие реплики-подтверждения, пока собирается содержательный ответ, локальные ветки вроде таймера или погоды и разбиение длинной реплики на смысловые куски.

Деградация до заранее записанных фраз — не защита, а маскировка: вместо уточняющего вопроса робот повторяет скрипт, и разговор умирает окончательно. Правильное поведение при неуверенности — переспросить, честно сменить тему или признать, что не расслышал. Разбираем, как это закрывается на уровне хранения истории диалога, обработки звука и логики поведения робота-компаньона.

Что даёт управляемый диалог: эффект в измеримых показателях

Управляемый диалог оценивают не по красоте отдельных ответов, а по поведению на длинной серии однотипных сессий. Главный показатель — доля автономных ответов: какую часть реплик социальный робот закрывает сам, без перевода на оператора. На запусках у гостевых сценариев она выходит на плато 82–91% и дальше растёт не количеством прописанных фраз, а уточнением правил разбора непонятных формулировок.

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

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

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

Инженерная база здесь — ROS и внешние сервисы распознавания и синтеза речи, связанные единым слоем интеграции. Это позволяет менять отдельную модель, не переписывая логику поведения робота.

Где социальный робот работает автономно, а где нужен оператор

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

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

Сравнение режимов

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

Как мы внедряем AI-систему: этапы работ

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

1. Аудит сценариев и узких мест. Разбираем реальные записи разговоров и логи: где робот теряет контекст, где пауза перед ответом становится некомфортной, на какой фразе гость уходит из диалога. На выходе — карта проблемных мест с частотой повторения.
2. Проектирование логики диалога. Описываем дерево сценариев и правила переходов: ветки удержания внимания, реакция на перебивание, корректный выход из тупика, эскалация к оператору при неуверенном распознавании.
3. Настройка интеграций. Связываем речевые модули, базу знаний, внешние сервисы и само устройство — моторы, свет, звук. Проверяем, что команда синтеза корректно превращается в физическое действие без рассинхронизации.
4. Настройка на доменных данных. Собираем словарь имён, терминов и типовых формулировок площадки, чтобы робот уверенно понимал речь конкретной аудитории, а не только эталонные фразы.
5. Приёмочная проверка. Прогоняем систему на реальных сценариях: считаем долю успешно завершённых диалогов, время отклика, частоту повторных вопросов. Каждый проваленный прогон разбираем и правим до стабильного результата.
6. Передача в эксплуатацию. Отдаём регламенты обновления сценариев, панель контроля качества диалогов и понятную инструкцию для персонала площадки. Правки контента вносятся без остановки робота.

Что остаётся у вас после передачи проекта

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

• Конфигурации системы — сценарии реплик, пороги срабатывания, тайминги реакций и правила перехода между режимами вынесены в отдельные файлы. Поведение робота меняется правкой конфигурации, без пересборки логики.
• Схемы интеграции — карта потоков данных между голосовым контуром, диалоговым ядром и внешними сервисами, с точками отказа. Отдельно описано поведение при потере сети: робот уходит в базовый сценарий вместо зависания.
• Политики доступа к данным — разграничение ролей: кто видит записи диалогов, сколько они хранятся, как удаляются по запросу. Для сценариев с детьми и пожилыми это обязательная часть, а не опция.
• Регламенты работы операторов — когда диалог передаётся человеку, как разбирать спорные ответы, что делать при повторяющихся жалобах. Без этого отлаженная система деградирует за считанные недели.
• Документация — архитектура, схема развёртывания, журнал известных ограничений и порядок действий при типовых сбоях. Пишем под инженера, который откроет её через полгода после нас.
• Обучение команды — практические сессии на тестовом стенде: добавить сценарий, посмотреть метрики качества ответов, откатить неудачное изменение.
• Набор эталонных реплик — фиксированные примеры диалогов для регрессии. После любого изменения сценария вы за минуты видите, что не сломалось.

Приёмка идёт по чек-листу: ваши инженеры сами вносят изменение, прогоняют регрессию и откатывают версию. Если это получается без нашей подсказки — проект передан.

Кейс: музейный гид — от частых сбоев к устойчивому диалогу

В выставочном пространстве Музей городской истории работал социальный робот-гид: он вёл посетителя по маршруту и отвечал на вопросы об экспонатах. Логика была построена на жёстком сценарии — робот уверенно отвечал только на заранее вписанные формулировки. Стоило посетителю перебить его или спросить «а почему эта вещь стоит отдельно?», и диалог рассыпался: робот повторял последнюю реплику или уходил в перезапуск, а разговор подхватывал смотритель.

Что изменили

Мы переписали логику диалога: робот стал держать контекст всей сессии, а не одной реплики, задавать уточняющий вопрос вместо угадывания и явно признавать, когда ответа нет. Добавили сверку фактов с базой музея, чтобы гид не выдумывал даты и имена, и передачу диалога смотрителю с краткой выжимкой — человек продолжает с того места, где робот остановился. Отдельно настроили ночные прогоны записанных разговоров: правки проверяются на реальных диалогах до выхода в зал.

Устойчивость держится не на одной модели, а на контуре: если новая сборка логики на ночном прогоне отвечает хуже предыдущей, она откатывается, а в зале остаётся рабочая версия. Логи диалогов собираются в одном месте, поэтому причина сбоя находится по конкретной реплике, а не по жалобе посетителя.

Чем отличается сценарный каркас от генеративного ответа

Сценарный каркас — это дерево состояний: робот знает, какие реплики допустимы в текущем контексте, чем кончается каждая ветка и как реагировать на молчание. Поведение воспроизводимо: одна и та же ситуация даёт один и тот же ответ, один и тот же сценарий проходит проверки детерминированно. Цена — узкая воронка: уход от заготовки упирается в «не понял, повторите».

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

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

Чистый каркас упирается в потолок узнаваемости фраз — это наглядно показала история Jibo и других роботов-компаньонов. Обратная крайность не лучше: без каркаса система теряет предсказуемость и на сопровождении превращается в бесконечную подстройку под каждый новый диалог.

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

Технические сомнения, которые стоит снять до старта

До старта заказчик проверяет три вещи: где физически лежат данные диалогов, что произойдёт при потере связи и насколько дорого менять поведение робота после запуска. Ниже — ответы по этим пунктам и по стыковке с уже выбранной платформой робота.

Что будет при потере связи?

Базовые сценарии — приветствие, навигация, типовые реплики — зашиты в модуль и работают автономно. После восстановления связи накопленные сессии догружаются в общую аналитику. Это плавная деградация, а не отказ: робот продолжает обслуживать людей.

Модель обучается на наших материалах?

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

Как обновляются сценарии и подключается оборудование?

Реплики и ветки поведения держим отдельными конфигурациями: правку выкатываем на часть парка, смотрим метрики, откатываем без перепрошивки. Микрофоны, приводы и датчики остаются родными — работаем через штатные интерфейсы производителя.

Обсудим задачу и вернёмся с оценкой и планом

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

• Сценарий взаимодействия. Где социальный робот встречает человека — приёмная, зал, зона ожидания — и что он должен успеть сделать в первые минуты общения.
• Текущие возможности платформы. Какие датчики и каналы вывода уже доступны, есть ли манёвренность: от этого зависит, что настраивается, а что разрабатывается с нуля.
• Внешние данные. Системы, к которым робот должен обращаться за ответом: база знаний, расписание, внутренний сервис, учётная система.
• Ограничения площадки. Уровень шума, освещённость, ширина проходов, стабильность сети — они прямо влияют на выбор моделей распознавания речи и логики поведения.
• Кто принимает результат. Человек со стороны заказчика, который подтверждает «работает»; иначе пилотное внедрение растянется на согласования между отделами.
• Критерий успеха. Метрика, по которой судим результат: доля диалогов, доведённых до конца, число сбоев на сотню обращений, время до осмысленного ответа.

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