Пользователь закончил AI-диалог. Но чему он научился без подсказки?
Представим два одинаково завершённых диалога в языковом приложении. В первом человек сам сформулировал ответ. Во втором он прочитал предложенную реплику и нажал «Продолжить». В отчёте у обоих появился законченный урок. Для интерфейса это действительно одинаковый результат. Для оценки самостоятельной речи между ними остаётся важная разница.
У продуктовой команды возникает неудобный вопрос: если мы добавили более удобные подсказки и пользователи стали чаще доходить до конца, что именно улучшилось? Возможно, стало легче учиться. Возможно, стало легче завершать экран. По одной метрике завершения различить эти ситуации нельзя.
Ниже — проект небольшого эксперимента для AI-продукта языковой практики. Это не отчёт об уже проведённом исследовании KeelAI и не обещание образовательного эффекта. Все диалоги и карточки придуманы для объяснения метода. Схемы показывают предлагаемый процесс, а не существующую аналитику сервиса.
1. Разделите удобство прохождения и самостоятельность
Подсказка снимает конкретную трудность. Одному человеку не хватает слова, другому трудно начать предложение, третий не понимает, чего от него хочет собеседник. Полная реплика решает сразу несколько таких проблем, но скрывает, какая из них помешала ответить.
Поэтому первый шаг — не убрать помощь, а описать действие, которому она должна помогать. Например: сообщить коллеге срок, обозначить условие и не превратить предположение в обещание. Это уже проверяемая задача. Формулировка «повысить уверенность в английском» сама по себе не подсказывает, какой ответ считать успешным.
Возьмём вопрос: “Can you send the final version on Thursday?” Пользователь знает, что в четверг будет готов только черновик, а финальная версия требует проверки. Ответ “Yes, Thursday is fine” может звучать свободно и грамматически правильно. Но в рамках задания он меняет смысл договорённости. Длинный ответ не обязательно лучше короткого: “The draft, yes. The final version still needs a review” решает задачу точнее.
Разведите две оси: смог ли человек пройти сценарий и смог ли он передать нужный смысл самостоятельно. Обе важны для продукта. Просто одна не заменяет другую.
2. Опишите помощь как последовательность состояний
У кнопки «Подсказка» часто слишком мало информации для последующего анализа. Что именно увидел пользователь? Одно слово, начало предложения, перевод вопроса или весь ответ? Если всё записывается одним событием, различия исчезают ещё до построения отчёта.
Для эксперимента можно задать несколько уровней: полная реплика, начало фразы, ключевое слово, отсутствие речевой подсказки. Это не обязательная лестница для каждого пользователя и не шкала знания языка. Это описание объёма помощи в конкретной попытке. Человек может перескочить ступень или вернуться назад.
Отдельно нужно решить, что считается помощью. Повтор аудио вопроса не равен готовому ответу. Перевод задания не равен переводу собственной реплики. Если смешать эти действия, команда получит аккуратную цифру с неясным смыслом. Для первого запуска достаточно различать несколько действительно существующих элементов интерфейса, а не строить универсальную классификацию.
Готовая фраза могла быть показана, но не использована. Поэтому событие её открытия говорит об экспозиции подсказки, а не доказывает копирование. Эта оговорка важна: аналитика интерфейса не умеет читать мысли. В отчёте лучше писать «ответ после показа подсказки», а не «ответ скопирован».
Схема 1. Уровни помощи описывают условия попытки, а не уровень человека. Возврат к подсказке допустим.
3. Проверьте перенос, изменив одну существенную деталь
Сразу повторить тот же вопрос без подсказки полезно для практики, но как проверка такой шаг ограничен. Человек может помнить только что показанную формулировку. Чтобы проверить более самостоятельное решение, измените одну деталь, от которой зависит смысл ответа.
В первой ситуации нужно назвать дату черновика. Во второй собеседник принимает эту дату за срок окончательной версии. Теперь требуется не воспроизвести готовое предложение, а исправить недопонимание. В третьей ситуации дата пока неизвестна: нужно назвать следующий шаг, после которого её можно подтвердить. Это разные задачи внутри одной рабочей темы.
Не меняйте одновременно тему, сложность слов и длину вопроса. Если человек не справится, причина окажется неразличимой: новое слово, новая задача или недостаточная самостоятельность. Для начального эксперимента полезнее узкая проверка, которую можно объяснить без дополнительных предположений.
Условия последующей попытки тоже нужно фиксировать. Был ли открыт предыдущий диалог? Сколько времени прошло? Показали ли образец ещё до ответа? Попытка сразу после примера и попытка позже без истории — не взаимозаменяемые наблюдения. При этом одна успешная проверка ещё не доказывает устойчивое владение навыком в реальном разговоре.
Не превращайте проверку в ловушку. Пользователь должен понимать, что сейчас ему предлагают попробовать без готовой реплики. Возможность попросить помощь остаётся. Такой запрос не считается провалом обучения; он меняет категорию попытки.
4. Составьте карточку оценки до чтения ответов
Если сначала посмотреть ответы, а потом решить, какие считать хорошими, критерий легко подстроится под красивый результат. Лучше заранее описать минимальные требования к смыслу. В нашей ситуации это три вопроса: различил ли человек черновик и финальную версию, обозначил ли зависимость от проверки, не пообещал ли отправку раньше возможного срока?
Грамматику и беглость стоит оценивать отдельно. Они важны, но не должны незаметно перекрывать смысловую ошибку. И наоборот: небольшая языковая неточность не обязана превращать понятный и корректный по обязательствам ответ в неуспех. Команда должна заранее договориться, какую задачу оценивает в этом эксперименте.
Если первую оценку делает модель, попросите её указывать конкретный фрагмент реплики для каждого вывода. Отсутствие подтверждения — повод оставить неопределённость, а не сочинять объяснение за пользователя. На небольшой проверочной выборке оценки полезно сопоставить с ручным разбором. Пока такого сопоставления нет, нельзя называть автоматическую оценку проверенной.
Не стоит переносить учебный балл в кадровые решения. Предлагаемая карточка нужна для настройки упражнения и обратной связи самому учащемуся. Она не доказывает профессиональную пригодность человека и не заменяет оценку его реальной работы.
Схема 2. Карточка оценки смысла. Поля оставлены без результатов: реальные ответы здесь не анализировались.
5. Соберите минимальную аналитику без красивых ложных знаменателей
Для сравнения понадобятся версии сценария и подсказки, показанная помощь, факт отправки ответа и результат последующей самостоятельной попытки. Событие завершения сохраняется, но перестаёт быть единственным итогом. Изменения формулировок задания нужно версионировать: иначе два разных упражнения попадут в один ряд.
Особенно внимательно определите знаменатель. Доля успешных самостоятельных ответов среди тех, кто дошёл до проверки, может выглядеть высокой, если остальные ушли раньше. Поэтому рядом нужны как минимум число приглашённых в проверку, число начавших её и число завершивших. Отсутствующий ответ нельзя автоматически считать языковой ошибкой, но и исключать его из картины молча нельзя.
Мы разрабатываем KeelAI для языковой практики, и такой подход полезен как рамка продуктовой проверки. Он не требует объявлять каждый законченный разговор доказательством обучения. Применить тот же протокол можно и в другом тренажёре, и в упражнении с преподавателем.
Для аналитики интерфейса не обязательно хранить полный текст каждой реплики. Если для ручной проверки нужны примеры, отдельно определите цель, доступ и срок хранения. Не отправляйте в продуктовые события реальные клиентские имена или содержание рабочих переписок. Учебную ситуацию можно описать синтетически, не копируя конфиденциальную задачу команды.
Схема 3. Предлагаемый контур эксперимента. Незавершённые попытки учитываются отдельно, а не исчезают из отчёта.
6. Заранее решите, что вы измените по результату
У эксперимента должен быть выход в конкретное решение. Если прохождение стало проще, а самостоятельный ответ не изменился, подсказка всё ещё может быть полезна как элемент удобства. Но называть это улучшением навыка пока нельзя. Следующим шагом может стать другой момент показа помощи или промежуточная смысловая опора.
Если люди справляются без подсказки, но массово прекращают упражнение, стоит проверить его длину и понятность. Если ошибаются преимущественно в обязательствах, проблема может быть в формулировке задания или в обратной связи, которая поощряет гладкость вместо точности. Это гипотезы для проверки, а не готовые объяснения.
Для первого пилота достаточно одного рабочего сценария, зафиксированных вариантов помощи и заранее написанной карточки. Без случайного распределения и сопоставимых условий наблюдаемая разница не доказывает причинный эффект новой подсказки. Результат небольшого пилота может быть скромнее: команда поняла, какие данные нужны для следующего решения.
Хорошая подсказка помогает продолжить разговор. Хорошая проверка показывает, что человек может сделать после неё. Когда эти задачи разделены, продукту проще оставаться удобным и одновременно честно говорить о результатах обучения.