Помощник правильно ответил на десять простых вопросов, но пропустил условие повторного согласования в одиннадцатом. Средний балл может выглядеть хорошим, а сотрудник после такого ответа выполнит неверное действие. Я разбираю качество по причинам: найден ли нужный источник, верно ли поняты условия и не раскрыты ли недоступные сведения.
В статье есть карточка контрольного примера, разбор двух версий и матрица приёмки самой проверки. По ним можно подготовить небольшой набор вопросов вручную и решить, какие сценарии уже допустимы, а какие требуют исправления. Автоматическая оценка помогает разбирать выборку, но её заключение также нужно сверять с экспертным решением.
Как сравнивать новую и прежнюю версии
Рабочий сценарий
Проверка ИИ по причинам ошибок
Оценивать основание, содержание, права и действие раздельно
01
Последствие
Назвать действие пользователя после ответа.
02
Выборка
Обычные вопросы, исключения и отсутствие знаний.
03
Карточка
Контекст, основание и запрещённые утверждения.
04
Прогон
Сохранить версии, ответы и найденные материалы.
05
Разбор
Отделить поиск, актуальность и интерпретацию.
06
Решение
Ограничить запуск и повторить затронутые проверки.
Существенные критерии выполнены без регрессии?
Условие выполнено: Запустить проверенный класс вопросов.
Условие не выполнено: Исправить причину и сохранить ограничение.
Ответственный
Владелец процесса и проверяющий эксперт
Подтверждение
Карточки примеров, протокол прогона и решение по классам
Что измеряем
Ошибки по критичности и регрессии относительно прежней версии
Используйте один и тот же сохранённый набор, но добавьте новые вопросы, отражающие найденные проблемы. Отдельно покажите исправленные случаи и появившиеся регрессии. Средняя оценка может улучшиться, хотя один важный тип ответа стал опаснее. Поэтому критерии значимых ошибок рассматривают отдельно. Не пересобирайте эталон задним числом ради красивого сравнения. Если изменился сам регламент, обновление правильного ответа фиксируется как изменение источника. Тогда проверка показывает качество помощника относительно действующих правил, а не совпадение с устаревшим ожиданием.
Начните с решения, которое примет человек после ответа
Контрольный вопрос полезен, когда понятно последствие ошибки. Ответ про расположение кнопки и ответ про обязательность согласования выглядят одинаково в чате, но по-разному влияют на работу. Для каждого сценария назовите действие пользователя: заполнит форму, отправит документ, изменит реквизиты, примет условие или просто прочитает справку. Это позволяет оценивать помощника по рабочему результату, а не по сходству текста с образцом.
Не назначайте один универсальный порог качества всей системе. Для справочного поиска можно отдельно рассматривать полноту и удобство. В сценарии с доступами существенным условием становится отсутствие запрещённого раскрытия. Для подготовки действия — верные параметры и обязательное подтверждение. Приёмка определяется границами конкретного запуска; удачный результат на простых вопросах не компенсирует ошибку в критическом классе.
Карточка контрольного примера
Сохранённый вопрос без условий быстро превращается в спор между проверяющими. Если один эксперт думает о новом регламенте, а другой о старом, оценки не сопоставимы. Карточка фиксирует контекст и допускает несколько правильных формулировок. Её цель — воспроизводимость смысла. Не нужно принуждать модель повторять единственную фразу, если пользователь получает корректный и полный порядок действий.
| Поле карточки | Что записать | Какую ошибку это предотвращает |
|---|---|---|
| Сценарий и роль | Кто спрашивает и к каким материалам имеет доступ | Оценку ответа администратора как ответа сотруднику |
| Вопрос и контекст | Исходная формулировка, нужная часть истории диалога | Подмену сложного вопроса удобным сокращением |
| Действующее основание | Документ, версия, существенный раздел | Приёмку ответа по устаревшему правилу |
| Обязательные элементы | Условия, исключения, следующий шаг | Одобрение гладкого, но неполного текста |
| Запрещённые утверждения | Неподтверждённый срок, лишний доступ, обещание | Сокрытие значимой ошибки общим высоким баллом |
| Допустимая неопределённость | Когда требуется уточнение или передача человеку | Наказание за правильный отказ от догадки |
| Критичность и проверяющий | Последствие ошибки и уполномоченный эксперт | Случайное изменение критериев после прогона |
Пришлите несколько обезличенных вопросов и опишите, что сотрудник должен делать после ответа. Помогу составить критерии приёмки помощника и отделить проблемы поиска от ошибок ответа. Написать в Telegram · Написать в MAX.
Историю диалога включают осознанно. Вопрос «А если сумма изменится?» невозможно оценить без предыдущего обсуждения закупки. В то же время длинная история может содержать устаревшее условие, которое пользователь позже исправил. Такой пример полезно оставить отдельным классом: помощник должен учитывать последнее подтверждённое значение, а не механически выбирать первое число из контекста.
Рабочий процесс оценки от выборки до решения
Вход: описание разрешённого сценария, действующие источники, карточки примеров и версия помощника. Роли: владелец процесса задаёт смысловые критерии, специалист по данным формирует выборку, проверяющий оценивает результат, разработчик исследует технические причины. Выход: решение о запуске с конкретными ограничениями либо список исправлений. Проверка: сохранённый протокол позволяет повторить сравнение после изменения.
Сначала соберите классы вопросов. Возьмите обычный путь, исключения, отсутствие данных, конфликтующие материалы, ограниченные права и попытку выполнить запрещённое действие. Для каждого класса объясните, почему он попал в выборку. Набор из десятков перефразированных простых вопросов не становится репрезентативным только за счёт размера. Важнее покрыть разные причины возможного отказа.
Затем отделите материалы настройки от проверочных. На первых можно менять инструкции и структуру источников. Вторые помогают увидеть, переносится ли улучшение на незнакомые формулировки. После многократного использования проверочный набор перестаёт быть независимым в практическом смысле: команда уже подстраивает решение под его известные особенности. Добавляйте новые вопросы из работы, сохраняя старые для контроля регрессий.
Перед прогоном заморозьте условия. Запишите идентификаторы версии источников, инструкции, настроек поиска и модели, если они доступны в выбранном инструменте. Зафиксируйте и ограничения воспроизводимости: внешняя система может обновляться, а ответ вероятностной модели — различаться. Поэтому важные сценарии иногда требуют повторов, но число повторов и трактовку различий определяют заранее, а не после неудобного результата.
Проверяйте ответ по отдельным признакам. Сначала правильность основания, затем соответствие ответа этому основанию, полноту существенных условий, соблюдение прав и понятность действия. Если все признаки объединить в одну оценку, красивый стиль начнёт компенсировать неверный порядок. Комментарий эксперта должен указывать фрагмент проблемы и ожидаемое правило, чтобы разработчик получил предметную задачу.
После оценки проведите разбор расхождений между экспертами. Разница может говорить не о плохом помощнике, а о неясном регламенте. В таком случае владелец сначала уточняет правило, затем обновляется эталон и повторяется прогон. Нельзя молча считать один из противоречащих документов правильным только потому, что он удобнее для проверки. Источник истины должен быть установлен процессом компании.
Завершайте цикл решением по классам. Какие вопросы можно запускать? Какие требуют подтверждения? Какие темы временно исключены? Для исправления назначьте владельца и проверку возврата. Отчёт без такого решения оставляет команду с таблицей оценок, но не помогает управлять доступностью помощника и ожиданиями пользователей.
Таксономия ошибок для предметного исправления
| Класс ошибки | Наблюдаемый признак | Что исследовать первым | Что не считать достаточным исправлением |
|---|---|---|---|
| Извлечение | Нужного раздела нет среди найденного | Состав базы, разбиение, словарь и фильтры | Переписать тон ответа |
| Актуальность | Найдено правило другой версии | Статусы документов и обновление индекса | Добавить слово «актуальный» в вопрос |
| Интерпретация | Основание верное, условие потеряно | Переданный контекст и инструкцию ответа | Загрузить ещё один дубль документа |
| Выдуманное основание | Утверждение не подтверждено ссылкой | Правило работы при недостатке сведений | Сделать формулировку осторожнее без проверки |
| Авторизация | Ответ содержит чужие сведения | Отбор данных и проверку доступа на этапах | Спрятать ссылку при сохранении пересказа |
| Действие | Предлагаются неверные параметры операции | Контракт инструмента и подтверждение | Признать правильным общий смысл сообщения |
| Удобство | Пользователь не понимает следующий шаг | Структуру и терминологию ответа | Заменить рабочую проверку оценкой стиля |
Один ответ может иметь несколько ошибок. Например, помощник использовал старую инструкцию и ещё неверно её пересказал. Сохраняйте обе причины, но укажите первичную зависимость: после обновления источника формулировку всё равно нужно проверить снова. Иначе исправление первой проблемы создаёт ложное ощущение, что весь сценарий стал корректным.
Учебный пример сравнения двух версий
Пусть помощник объясняет порядок изменения уже согласованной заявки. В эталоне требуется повторное согласование при изменении существенных параметров. Первая версия правильно называет форму, но не упоминает повторную проверку. Команда добавляет правило в инструкцию помощника. На том же вопросе ответ улучшается. Этого ещё недостаточно для приёмки изменения.
В соседнем примере меняется только контактный комментарий, который не влияет на согласованные условия. Новая инструкция может начать требовать повторное согласование для любой правки. Такое поведение создаёт лишнюю работу и показывает чрезмерное обобщение. Контрольная выборка должна различать существенные параметры и поясняющую информацию, а не просто искать фразу «повторное согласование» во всех ответах.
Третий вопрос не содержит сведений о характере изменения. Правильный результат — уточнение или описание развилки. Если проверка требует немедленного однозначного ответа, она сама поощряет догадку. Поэтому хороший эталон описывает допустимую логику: когда ответить прямо, когда разделить варианты и когда запросить недостающий факт. Это точнее автоматического сравнения с одним образцовым абзацем.
Как использовать автоматическую оценку
Автоматический проверяющий удобен для формальных признаков: присутствует ли обязательная ссылка, соответствует ли формат, указаны ли требуемые поля. Модель в роли оценщика может помогать с содержательным сравнением, но тоже ошибается. Проверьте её на примерах с известным решением эксперта, особенно на уверенно написанных неправильных ответах и кратких корректных отказах.
Не давайте оценщику скрытое преимущество. Если ему доступен весь правильный регламент, а помощнику передали повреждённый фрагмент, нужно отдельно оценить качество поиска и текста. Иначе итоговая отметка не объяснит, где возник сбой. Сохраните входы обоих этапов и правило подсчёта, чтобы результат можно было разобрать без повторного доступа к живому пользовательскому диалогу.
Приёмка самого конвейера проверки
| Проверка конвейера | Ожидаемый результат | След в протоколе |
|---|---|---|
| Повтор на сохранённой версии | Сопоставимы причины различий | Версии, параметры и ограничения повторяемости |
| Неправильный, но убедительный ответ | Ошибка содержания не скрывается стилем | Отдельная отметка критического признака |
| Корректное уточнение | Не считается отсутствием ответа | Условие неопределённости в карточке |
| Разногласие экспертов | Есть процедура согласования | Решение владельца и версия эталона |
| Изменение источника | Эталон пересматривается явно | Причина и область изменения |
| Найденная регрессия | Запуск затронутого сценария ограничен | Решение по классу и ответственный |
После запуска пополняйте набор обезличенными типами реальных затруднений. Не переносите в него автоматически всю переписку: для проверки часто достаточно минимального воспроизводимого вопроса и разрешённого фрагмента. Содержательная оценка остаётся рабочим циклом улучшения. Она полезна, когда позволяет решить, какую причину исправить, как доказать результат и в каких границах помощнику уже можно доверить конкретную часть процесса.
Пример из разработки ИИ-сервиса: проверять отдельные возможности
В портфолио GlossCheck представлены чат, работа с файлами, OCR, история диалогов и настройки. Проверка точности ответов на рабочих вопросах — отдельный этап. Методика в этой статье предназначена для такой оценки.
Для нового помощника я разделю контрольные случаи: верно ли распознан текст, найден ли разрешённый фрагмент и правильно ли сформирован ответ. Если OCR пропустил число, правка стиля ответа не решит исходную причину. Это предлагаемый способ проверки распознавания, поиска и формирования ответа.
Вопросы по теме
Нужно ли покупать отдельный инструмент оценки для первого пилота?
Нет. Небольшую выборку можно разобрать вручную по заранее записанным критериям. Важно сохранить вход, ответ, основание и решение; название инструмента не заменяет качество примеров.
Можно принять версию, если средний балл вырос?
Только после разбора значимых ошибок и регрессий. Улучшение простых ответов не компенсирует раскрытие чужих данных или неверное действие в критичном сценарии.