Подсказка помогла или ответила за пользователя: где AI-репетитору остановиться
Удобный AI-сервис способен незаметно выполнить за человека именно ту работу, ради которой человек пришёл учиться. Пользователь открывает перевод, копирует удачную фразу, завершает задание. Интерфейс фиксирует успех. Но сможет ли он ответить без этой опоры в следующем разговоре? По одному завершённому упражнению этого не узнать.
Для продукта на стыке языкового обучения и AI это не спор о том, нужны ли подсказки. Они нужны. Вопрос практический: как отличить поддержку от подмены действия и не начать оптимизировать красивую статистику вместо самостоятельности пользователя.
Мы развиваем KeelAI и разбираем эту границу на собственных продуктовых экранах. Ниже не отчёт о якобы успешном A/B-тесте: его результатов здесь нет. Это рабочая схема проверки, которую можно применить к языковому тренажёру, обучению сотрудников или AI-помощнику внутри корпоративного продукта.
1. Сначала определить, что человек должен сделать сам
Представим учебный сценарий: время встречи изменилось, нужно уточнить новый срок и подтвердить участие на изучаемом языке. Это пример задания, а не история реального клиента. Его результатом должна быть понятная собеседнику реплика, а не совпадение с единственной заранее записанной фразой.
Здесь легко смешать несколько разных достижений. Человек мог понять входящее сообщение. Мог узнать знакомые слова. Мог собрать ответ из предложенных фрагментов. Наконец, мог самостоятельно сформулировать подходящий ответ. Все эти действия полезны, но они не взаимозаменяемы. Если в аналитике у них одна отметка «успех», команда перестаёт видеть, чему именно помогает интерфейс.
До проектирования подсказки стоит записать минимальный самостоятельный результат. Для нашего примера: пользователь уточнил время, не потерял смысл и выразил своё намерение. Грамматические огрехи можно оценивать отдельно. Иначе продукт начнёт исправлять форму там, где задача уже решена, или засчитает безупречную скопированную фразу как освоенное умение.
Важна и честная граница обещания. Успех в учебном сценарии ещё не доказывает перенос навыка на рабочую встречу. Но это наблюдаемый шаг, который можно проверить повторно. Для команды он полезнее расплывчатого обещания «пользователь стал увереннее», если уверенность никто не измерял и с самостоятельным действием не сопоставлял.
2. Сделать помощь лестницей, а не единственной кнопкой ответа
Помощь бывает разной глубины. Напомнить цель разговора, дать ключевое слово, открыть исходный текст, показать перевод, предложить готовую реплику: каждое действие снимает свою часть нагрузки. Поэтому факт нажатия на подсказку недостаточен. Нужно знать, какая часть задачи после этого осталась за человеком.
В аудиодиалоге KeelAI на продуктовом экране ниже видны отдельные опоры «Текст» и «Перевод». Это конкретный элемент интерфейса, а не доказательство эффективности обучения. Он позволяет сформулировать проверяемый вопрос: после открытия текста пользователь продолжает работать с изучаемым языком или сразу переходит к полному переводу?
Разумная гипотеза для проверки: сначала предложить небольшую опору, а более полную оставить доступной следующим шагом. Это гипотеза, не универсальный рецепт. Человеку с неподходящим уровнем задания, особенностями восприятия или технической проблемой может сразу понадобиться полный текст. Прятать его ради «правильной» метрики было бы плохим решением.
Поэтому лестница помощи не должна превращаться в полосу препятствий. Нужны понятные названия, возможность вернуться к исходному материалу и отсутствие наказания за обращение к опоре. Исследовать следует не «кто оказался слабее», а «при каких условиях конкретная помощь позволила сделать следующий шаг». Так результаты остаются полезными и для обучения, и для улучшения интерфейса.
3. Не записывать проблему интерфейса в проблему ученика
Допустим, человек несколько раз открывает перевод или покидает упражнение. Соблазнительно решить, что материал сложный. Но пользователь мог не расслышать запись, не понять подпись кнопки или не найти нужное слово из-за режима поиска. До выводов об обучении нужно исключить такие объяснения.
На следующем скриншоте показан казахский словарь KeelAI с английским интерфейсом. Видны пример ввода и пояснение поиска. Этот экран полезен для другого вопроса: понимает ли человек, что именно можно искать и что означает отсутствие результата? Пустой ответ словаря сам по себе ничего не говорит о знании языка.
В короткой проверке интерфейса можно попросить человека найти слово и объяснить, что он ожидает после ввода. Затем посмотреть, совпало ли ожидание с результатом. Это не экзамен для пользователя. Если несколько трактовок подписи выглядят разумными, перед командой задача ясности интерфейса.
В событиях аналитики полезно различать технический сбой, отсутствие контента и обычную учебную ошибку. Не нужно для этого автоматически сохранять все личные фразы. Часто достаточно типа экрана, состояния загрузки и категории действия. Чем меньше лишних данных собирается, тем проще объяснить смысл измерения и не превращать исследование обучения в незаметный сбор чувствительной переписки.
4. Проверять следующую попытку, а не только текущую
После подсказки текущий ответ почти неизбежно становится проще. Поэтому главный проверочный эпизод находится дальше: новое задание с похожей коммуникативной целью, но другим содержанием. Если повторить ту же фразу, мы смешаем самостоятельность с запоминанием конкретного ответа.
Для примера со встречей можно изменить время, участника и причину переноса. Важно сохранить сопоставимую сложность: иначе ухудшение результата будет объясняться новой задачей, а не подсказкой в предыдущей. При этом принимать стоит несколько корректных формулировок. Критерий должен проверять смысл действия, а не послушание образцу.
В библиотеке KeelAI видны тексты, уровни и продолжение чтения. Такой выбор материала помогает поставить продуктовый вопрос: что считать следующим шагом после знакомства с текстом? Завершённое чтение и самостоятельный ответ по новой ситуации следует учитывать отдельно. Сам экран библиотеки ещё не подтверждает, что перенос навыка состоялся.
Обращение к помощи в следующем задании не следует запрещать. Лучше зафиксировать, был ли самостоятельный ответ до открытия опоры, а затем дать продолжить обучение. Иначе исследование начнёт портить продукт ради чистоты наблюдения. Проверка с задержкой также полезна, но её нельзя смешивать с немедленной попыткой: это разные условия и разные выводы.
5. Собрать эксперимент, который не наградит выдачу готового ответа
Практический протокол начинается с одной гипотезы: например, небольшая опора перед полным ответом увеличивает долю самостоятельных следующих попыток, не делая обучение заметно тяжелее. Это план измерения, а не заявленный результат KeelAI. Условия успеха и остановки стоит определить до сбора данных.
Сравниваемые варианты должны отличаться именно устройством помощи. Если одновременно изменить тексты, уровень сложности, голос и порядок упражнений, объяснить эффект будет трудно. Нужно также заранее определить, что считается первым столкновением с заданием, как учитываются повторные прохождения и что делать с незавершёнными попытками.
Основной показатель: доля самостоятельных успешных ответов в следующем сопоставимом задании. Знаменатель здесь принципиален: нельзя оставлять только тех, кто дошёл до конца. Отдельно следует показать, сколько участников вообще получили возможность следующей попытки, сколько приступили и сколько завершили её. Иначе уход пользователей сделает оставшуюся группу искусственно успешной.
Рядом нужны защитные показатели: отказы от задания, время до содержательного действия, частота запросов полной помощи и сообщения о непонятном интерфейсе. Время само по себе неоднозначно: быстрый ответ может быть копированием, долгий может означать полезное размышление. Его нужно читать вместе с качеством и самостоятельностью ответа, а не превращать в гонку.
Посмотреть контекст этих экранов можно в KeelAI. Для собственной проверки не обязательно строить большой аналитический контур: начать можно с размеченных сценариев и наблюдения за прохождением. Важно заранее согласовать критерии, проверить их на примерах и не объявлять победу по первым удобным наблюдениям.
6. Принять решение на языке продукта и бизнеса
Если люди чаще заканчивают упражнения, но следующую реплику всё ещё получают готовой, улучшилась проходимость сценария. Это может быть полезно, но называть такой результат ростом самостоятельного навыка нельзя. Если самостоятельных ответов стало больше, а число отказов резко выросло, тоже рано праздновать: интерфейс мог отсеять тех, кому поддержка нужна сильнее.
Для международной команды цель стоит формулировать через конкретное действие: уточнить срок, объяснить проблему, проверить понимание договорённости. Не через абстрактное количество сообщений с AI. При этом оценка учебного продукта не должна автоматически становиться рейтингом сотрудников. Человек должен понимать, что собирается и кто увидит результаты.
Перед выпуском изменённой помощи полезно пройти короткий чек-лист:
- Цель: записано действие, которое пользователь должен выполнить сам.
- Опоры: различаются их глубина и причина обращения.
- Проверка: есть следующая сопоставимая, но не идентичная задача.
- Данные: видны незавершённые попытки и ограничения измерения.
- Доступность: полная помощь остаётся доступной без наказания.
Хорошая подсказка не обязана быть маленькой. Она обязана быть уместной. Граница проходит не по длине текста AI, а по тому, остаётся ли у человека содержательная работа и появляется ли возможность сделать её самостоятельно позже. Именно эту границу стоит обсуждать на продуктовом разборе раньше, чем рост числа завершённых упражнений.