Как научить пятилетнего ребёнка за секунду: архитектура ИИ-репетитора Ello
Компания Ello (ello.com) опубликовала инженерный разбор того, как устроен её голосовой ИИ-репетитор, обучающий детей 4, 9 лет математике и чтению. Главный вывод команды: чтобы репетитор реально учил, а не просто быстро отвечал, педагогику пришлось закладывать прямо в архитектуру системы, а не добавлять поверх готового чат-бота.
Ключевое ограничение, ответ быстрее секунды на каждую реплику. Двухсекундная пауза, незаметная взрослому в разговоре по телефону с автоответчиком, для ребёнка означает потерю внимания и остановку обучения. На плейтестах команда увидела это вживую: шестилетний мальчик, не дождавшись ответа, сам спросил у агента, думает ли тот; а одна девочка обнаружила, что можно слушать вполуха и всё равно успевать за репетитором, и именно в этот момент, по словам разработчиков, она перестала учиться.
Из-за этого Ello отказалась от стандартного для ИИ-агентов паттерна «цикл с инструментами»: модель вызывает инструмент, ждёт его выполнения, смотрит на результат и решает, что делать дальше. Топовые модели тратят 2, 3 секунды на первый токен и выдают дальше около 30 токенов в секунду; с учётом сетевых задержек и воспроизведения аудио это превращается в 3, 4 секунды тишины между репликами репетитора, неприемлемо для ребёнка. Простое решение «взять модель поменьше и побыстрее» тоже не сработало: у компактных моделей репетитор из первых версий переставал следовать сложным инструкциям и просто выдавал ребёнку готовый ответ вместо наводящего вопроса или подсказки, то есть терял смысл всей педагогики.
Вместо этого команда написала собственный «харнесс» (обвязку) вокруг модели: она стримит сразу несколько действий в одном ответе, а отдельный интерпретатор разбирает и исполняет каждое действие, пока модель ещё генерирует следующие. Ребёнок ждёт только первые примерно 30 токенов, а не весь ответ целиком. Разделение генерации и исполнения дало и другие возможности: набор доступных действий можно менять по ситуации (например, пока на экране висит вопрос, агенту доступны только подсказки и наводящие шаги, а не прямой ответ), а каждое действие можно валидировать без потери скорости, модель прерывают и просят сгенерировать заново, только если действие оказалось некорректным. У подхода есть цена: пришлось строить свою систему логирования и трассировки вместо готовых фреймворков, и команда идёт против течения индустрии, где топовые модели всё сильнее заточены именно под цикл с инструментами; харнесс задуман так, чтобы его можно было выбросить, как только модели станут достаточно быстрыми для обычного цикла.
Второе архитектурное решение, разделение на двух агентов. «Собеседник» (converser) ведёт диалог с ребёнком здесь и сейчас, а «планировщик» (planner) отдельно сверяет разговор с целями урока и управляет контекстом собеседника. Синхронный вызов планировщика оказался слишком медленным, а план с фиксированным сроком жизни, ненадёжным; в итоге планировщик работает асинхронно, размышляя, пока ребёнок думает или говорит, так же, как учитель обдумывает следующий шаг в паузах разговора. Оба агента читают и пишут общее состояние без прямой координации друг с другом: каждая реплика, касание экрана и обновление интерфейса пишется в единый неизменяемый лог событий. Этот же формат лога позволяет предугадывать ответы: когда собеседник задаёт вопрос закрытого типа (заполнить пропуск, сыграть в «Я вижу», закончить пример), система заранее генерирует ответы репетитора на вероятные варианты ответа ребёнка на отдельных «ветках» диалога; когда ребёнок отвечает, его ответ сопоставляют с подходящей веткой и проигрывают готовую реакцию без нового обращения к модели. Плата за это, стоимость (планировщик работает на более дорогой и мощной модели и вызывается на каждом ходу) и редкие промахи: иногда ребёнку, готовому к более сложному вызову, вместо этого достаётся лёгкая победа, а отличить ошибку собеседника от ошибки плана пока трудно.
Отдельная проблема, безопасность реплик в реальном времени. Классификатор безопасности, это отдельная LLM, которой требуется 500, 1000 мс на проверку; ждать её перед тем, как собеседник начнёт отвечать, означало добавлять до секунды задержки к каждому ходу. Решение: как только ребёнок закончил говорить, параллельно запускаются классификатор безопасности и маленькая модель, которая мгновенно генерирует «реактивную» реплику-подтверждение вроде «ты любишь динозавров! Я тоже!». К моменту, когда эта реплика сгенерирована, классификатор обычно уже успевает вернуть вердикт «безопасно», и это разблокирует полноценную генерацию у собеседника, пока реактивная реплика проигрывается ребёнку, то есть ребёнок слышит один непрерывный ответ, хотя за кулисами отработало несколько вызовов моделей. От чисто правил-based фильтра команда отказалась: он не выдерживает того, как реально говорят пятилетние дети, каждая новая категория правил требует токенов и переналадки, а ошибки распознавания речи иногда пугают классификатор ложными срабатываниями (эти случаи разбирают отдельно, чтобы улучшать понимание речи ребёнка агентом). Показательный кейс: если ребёнок посреди урока говорит, что одноклассник обозвал его плохим словом, «зеркалящая» реактивная реплика повторила бы это слово вслух, поэтому при срабатывании классификатора реактивную реплику отбрасывают целиком, а собеседник получает другую инструкцию: не повторять слово, признать, что это могло быть обидно, и предложить ребёнку рассказать об этом взрослому. Ello отмечает, что политики безопасности разрабатывались вместе с экспертами по детскому развитию, и обещает отдельную статью на эту тему. В конце поста компания говорит, что нанимает специалистов на эти задачи.
Ключевые факты
- Ello построила голосового ИИ-репетитора для детей 4, 9 лет с жёстким требованием: ответ быстрее секунды на каждую реплику, иначе ребёнок теряет внимание и перестаёт учиться
- Компания отказалась от стандартного цикла «ИИ-агент вызывает инструмент и ждёт результата», топовые модели дают 3, 4 секунды тишины между репликами, а модели поменьше не удерживали сложную педагогическую логику и просто выдавали готовые ответы
- Решение, собственный харнесс: модель стримит несколько действий подряд, интерпретатор исполняет их по мере генерации, ребёнок ждёт только первые ~30 токенов
- Систему разделили на два агента: «собеседник» ведёт диалог в реальном времени, «планировщик» асинхронно сверяет разговор с целями урока и заранее генерирует ответы на вероятные реплики ребёнка
- Проверка безопасности (LLM-классификатор, 500, 1000 мс) запускается параллельно с быстрой «реактивной» репликой-заглушкой, чтобы не тормозить ответ; при срабатывании классификатора заглушку отбрасывают и подставляют другую, безопасную реакцию
Почему это важно
Пост показывает редкий для индустрии случай, когда требование к латентности не техническая деталь, а прямое следствие того, кому и зачем нужен продукт: ребёнок физически не может ждать модель дольше пары секунд без потери внимания и обучения. Это заставило Ello полностью отказаться от общепринятого паттерна ИИ-агентов (цикл вызова инструментов) и построить собственную обвязку вокруг модели, редкий и хорошо задокументированный пример, когда архитектурное решение продиктовано не удобством разработки, а конкретным ограничением аудитории.
Кому это важно
В первую очередь, командам, строящим голосовых и реал-тайм ИИ-агентов (не только для детей): call-центры, голосовые ассистенты, интерактивные тренажёры, где задержка в секунды разрушает опыт. Также полезно EdTech-командам и всем, кто проектирует мультиагентные системы с разделением на «быстрого исполнителя» и «медленного планировщика», и командам безопасности, которым нужно проверять контент в реальном времени без задержки ответа.
Как это применить
Из статьи можно взять несколько переиспользуемых паттернов: (1) разделять генерацию и исполнение, стримить действия модели и исполнять их интерпретатором по мере поступления, а не ждать полного ответа; (2) ограничивать пространство действий агента по контексту момента, а не давать ему сразу весь набор инструментов; (3) разносить систему на быстрого «реактивного» агента и медленного «планировщика», работающего асинхронно, пока пользователь думает или говорит, координируясь через общий неизменяемый лог событий вместо прямого обмена сообщениями; (4) для предсказуемых закрытых вопросов заранее генерировать ответы на вероятные варианты, чтобы не делать новый вызов модели в момент ответа пользователя; (5) гейтить исполнение (а не генерацию) проверкой безопасности, запускать LLM-классификатор параллельно с генерацией и подставлять готовую заглушку, если и когда классификатор не успел ответить.
Можно ли доверять
Это инженерный пост самой компании Ello на собственном блоге, самопрезентация, а не независимый аудит: конкретные метрики обучения (насколько дети действительно лучше учатся) и данные о реальном использовании продукта в тексте не приведены, речь идёт только об архитектурных решениях и качественных наблюдениях с плейтестов. Технические детали (задержки моделей, разделение генерации/исполнения, асинхронные планировщики) звучат правдоподобно и совпадают с известными проблемами голосовых ИИ-агентов, обсуждение на Hacker News собрало заметный отклик (65 баллов, 100 комментариев), но независимой проверки заявлений в самом посте нет.
Риски и подводные камни
Собственный харнесс вместо стандартного цикла инструментов, это дополнительная сложность и стоимость поддержки (свои логирование, трассировка, отладка), и он может морально устареть, как только модели станут быстрее отвечать в обычном режиме. Асинхронная связка «собеседник + планировщик» усложняет диагностику: непонятно, была ли ошибка на стороне собеседника или следствием неверного плана. Предсказание ответов ребёнка на ветках диалога, это ставка: иногда ребёнку, готовому к более сложному вызову, достаётся заготовленный лёгкий вариант вместо настоящего вызова. Наконец, безопасность держится на LLM-классификаторе, который может ошибаться из-за неточностей распознавания речи, а аудитория продукта (маленькие дети) не может «отменить» услышанное, если система всё же даст сбой.
«Задержка научила её отключаться от репетитора. И именно в этот момент она перестала учиться.»
— инженерная команда Ello, из блога компании