Все слова понятны, задача нет: как оценивать уточняющие вопросы в AI-практике
«Сделайте версию полегче и пришлите завтра». В международной команде такая просьба может звучать на хорошем английском, а ответ на неё оказаться грамматически безупречным. При этом участники договорятся о разных вещах: один ждёт сокращённую презентацию утром, другой собирается уменьшить размер файла к вечеру. Языковая ошибка здесь не обязательна. Не хватает общего представления о результате.
Мы делаем KeelAI и рассматриваем языковую практику как продуктовую задачу. В этой статье предлагаем конструкцию упражнения, в котором оценивается не только форма ответа, но и способность выяснить недостающие условия. Это проектный разбор, а не отчёт об измеренном росте эффективности. Все реплики составлены для материала; реальные рабочие переписки и клиентские данные не использовались.
1. Разделить три причины одного «не понял»
Первый случай: человек не расслышал фрагмент. Собеседник назвал получателя, но связь оборвалась. Здесь уместно попросить повторить имя: “Sorry, who should I send it to?” Если тренажёр оценивает такой ответ, ему нужно знать, что именно было недоступно участнику. Иначе обычная просьба восстановить звук превращается в произвольную проверку вежливости.
Второй случай: слова услышаны, но значение не определено. В реплике “We need a lighter version” слово “lighter” может относиться к объёму содержания, размеру файла или оформлению. Вопрос “Do you mean fewer slides or a smaller file?” показывает две возможные интерпретации. При этом собеседнику нужно оставить возможность назвать третью, а не заставлять выбирать из неверных вариантов.
Третий случай: словарь понятен, но условий недостаточно. “Can you send it tomorrow?” не сообщает, нужен ли черновик или финальный документ и к какому времени. Повторение исходной фразы не устранит эту неопределённость. Упражнение должно вознаграждать уточнение результата или срока, а не только воспроизведение заранее выбранного выражения.
Для продукта это три разных задания, даже если на экране у всех одна кнопка «Ответить». Их нельзя смешивать в единую категорию ошибок понимания: причины неуспеха и полезная обратная связь будут различаться. Для команды это также способ отделить недостаток языка от недостаточно определённого поручения. Обучение не должно брать на себя ответственность за информацию, которой никто не сообщил.
2. Создать дефицит информации, а не загадку
Возьмём учебную просьбу: “Could you make a lighter version for tomorrow?” У автора сценария есть карточка собеседника: нужна презентация с меньшим количеством слайдов, для внутреннего обсуждения; достаточно черновика. Участник видит только просьбу. Его задача не угадать карточку, а задать вопрос, который изменит понимание следующего действия.
В карточке полезно разделить обязательное и необязательное. Для этого упражнения обязательны смысл слова “lighter” и допустимая готовность материала. Точное число слайдов может быть несущественно. Критерий успеха фиксируется до разговора. Иначе оценщик сможет после любого ответа придумать ещё одно условие, которое участник якобы обязан был выяснить.
Правила собеседника тоже нужны заранее. Он отвечает на заданный вопрос, не противоречит собственной карточке и не раскрывает все условия без запроса. Но он не должен намеренно уходить от ясного вопроса. Если участник спрашивает “What exactly should I change?”, допустим содержательный ответ, а не наказание за отсутствие «правильной» заученной формулы.
Такое упражнение можно сначала провести вручную. Один человек получает открытую часть карточки, второй скрытую. После разговора они сравнивают договорённость с условиями. Это позволяет заметить двусмысленности до интеграции модели: например, выяснить, что предложенный вопрос допускает несколько трактовок, а закрытый список «верных ответов» отвергает нормальную речь.
3. Оценивать свидетельства в диалоге
Оценщику недостаточно увидеть вопросительный знак. Реплика “Everything is okay, right?” формально является вопросом, но не обязательно раскрывает недостающее условие. Полезнее построить проверку вокруг последовательности: исходная неопределённость, уточняющий вопрос, полученный ответ, итоговая договорённость. Для каждого вывода должен существовать конкретный фрагмент диалога.
В нашем примере участник спрашивает: “Do you mean fewer slides?” Собеседник подтверждает. Теперь значение “lighter” выяснено. Затем участник говорит: “I'll send the final version tomorrow morning”. Эта фраза добавляет готовность и время, которых собеседник не требовал. Хороший английский не превращает добавленные обещания в согласованные условия.
Языковая форма и решение задачи должны оставаться отдельными результатами. В одном поле можно разобрать понятность и грамматику, в другом показать, какие условия выяснены. Третий результат относится к работе самого тренажёра: соблюдал ли AI роль собеседника. Если он выдал всю скрытую карточку в первой реплике, способность участника задавать вопросы в этой попытке не проверена.
При неоднозначности лучше сообщить «недостаточно данных», чем приписать точную оценку. Например, ответ собеседника “That should work” может не прояснять, относится ли согласие ко всему предложению. В интерфейсе стоит показать спорное место и объяснить, чего не хватило для вывода. Такой разбор полезнее уверенного балла без проверяемого основания.
4. Сделать обратную связь пригодной для следующей попытки
После диалога пользователю не нужен полный внутренний протокол оценивания. Ему нужно понять, какое действие удалось и что попробовать иначе. Вместо «улучшите коммуникацию» можно написать: «Вы выяснили, что нужно сократить содержание, но не уточнили, подойдёт ли черновик». Ниже показать реплику, на основании которой сделан вывод.
Затем предложить короткую повторную попытку. Важно не требовать дословно повторить образцовый вопрос. “Is a draft okay?” и “Do you need the finished version?” различаются, но могут раскрыть одно и то же условие. Образец должен объяснять функцию реплики, а не подменять её паролем для получения зачёта.
Для следующего сценария можно сохранить знакомые слова и заменить скрытое условие. Теперь собеседнику действительно нужна финальная версия, но позже. Участник, который просто повторяет предыдущий итоговый ответ, ошибётся; участник, который задаёт вопрос, получит нужную информацию. Это ещё не доказывает перенос навыка в рабочую среду, но позволяет отличить уточнение от запоминания конкретной договорённости.
В продукте также стоит предусмотреть оспаривание разбора: «Я это уточнил». Пользователь указывает свою реплику, оценка пересматривается или отправляется на проверку. Нельзя автоматически считать каждое возражение ошибкой модели, но нельзя и прятать спор за авторитетом AI. Отдельный список таких ситуаций помогает дорабатывать критерии без изменения уже показанных результатов задним числом.
5. Измерять упражнение, не обещая бизнес-эффект
Для пилота можно считать долю валидных попыток, в которых участник выяснил обязательные условия. Знаменатель здесь принципиален: попытки, где собеседник нарушил роль или случился технический сбой, нужно показывать отдельно. Если просто удалить их из отчёта, команда не увидит, сколько пользователей столкнулось с непригодным упражнением.
Другой показатель: доля попыток с неподтверждённым обещанием. Для его расчёта заранее определяется, что считается обещанием, и проверяется, есть ли согласование в диалоге. Время до завершения можно использовать как дополнительный сигнал, но не как самостоятельную цель: быстрый ответ с неверной договорённостью не становится хорошим из-за скорости.
Завершение диалога, освоение навыка и бизнес-результат не равны друг другу. Для вывода о навыке нужна проверка на новом задании; для вывода о работе команды нужны отдельные наблюдения и дизайн исследования. До этого корректно говорить о результатах конкретного упражнения. Процент улучшения из чужого кейса не заменит собственное измерение.
Мы обсуждаем эту конструкцию как команда KeelAI, развивающая языковую практику. Описанный здесь протокол не следует воспринимать как заявление, что все перечисленные проверки уже внедрены в сервис. Он применим и без приложения: карточки, запись учебного диалога и ручной разбор позволяют проверить логику до автоматизации.
6. Начать с ограниченного проверяемого пилота
Практический старт выглядит так: выбрать одну рабочую ситуацию без реальных данных, описать открытую просьбу, зафиксировать скрытые условия и составить критерии. Затем проиграть несколько разных ответов: точный вопрос, допустимую переформулировку, неверное предположение и отказ продолжать. Это не исследование эффективности, а проверка согласованности самого задания.
Отдельно нужен контрольный случай, где уточнять нечего. Если просьба уже содержит результат, срок и формат, тренажёр не должен требовать дополнительного вопроса исключительно ради учебного шаблона. Цель не в максимальном количестве уточнений, а в достаточности информации для действия. Иначе практика учит усложнять ясную коммуникацию.
После ручной проверки можно подключить AI-собеседника, сохранив те же карточки и ожидаемые признаки. Полезно версионировать условия, инструкцию модели и критерии, чтобы сравнение попыток не смешивало разные задания. Любое изменение сложности должно быть явным: новый словарь, дополнительное условие или устный формат, а не всё одновременно.
Итог такого пилота скромный, но проверяемый: понятно ли участнику задание, выдерживает ли собеседник роль, можно ли подтвердить оценку по диалогу. Только после этого имеет смысл обсуждать масштабирование. Для международной команды ценность уточняющего вопроса начинается не с красивой фразы, а с общего понимания того, что именно стороны собираются сделать.