AI
Оценка ИИ: ТЗ на тестовый набор, метрики и решение о выпуске
Какие требования нужны для оценки ИИ-системы: независимые примеры, рубрика, критичные ошибки, повторяемость, инструменты и отчёт с ограничениями.
Определите решение, ради которого проводится оценка
ТЗ на оценку качества AI-системы должно начинаться с решения: запускать ли продукт, менять ли модель, расширять ли автоматизацию или принимать ли работу подрядчика. Общая просьба «проверить интеллект» не задаёт критериев. Система может хорошо писать текст и ошибаться в выборе действия, правильно находить документ и раскрывать его неподходящему пользователю. Поэтому объектом оценки становится конкретный процесс с входами, доступными данными, полномочиями и ожидаемым результатом. Без этих границ красивый средний балл мало помогает владельцу продукта.
Опишите единицу проверки. Для классификатора это может быть одно обращение, для поиска — вопрос и найденные документы, для помощника — полный диалог с действиями. Если система использует инструменты, оценивайте не только финальную реплику, но и запросы, изменения состояния и последствия. Учебный пример: ответ клиенту звучит корректно, однако создана вторая заявка вместо обновления существующей. Текстовая оценка такой ошибки не заметит, хотя именно она определяет пригодность системы для реальной работы.
В NIST AI RMF измерение рассматривается вместе с контекстом, управлением рисками и последующим контролем. Практический вывод для ТЗ: заранее согласуйте, какие ошибки допустимы, какие требуют человека и какие блокируют запуск. Это не универсальный нормативный порог, одинаковый для всех проектов. Рекомендации и инструменты помогают организовать проверку, но окончательное решение зависит от задачи и последствий ошибки. Зафиксируйте владельца этого решения и данные, на основании которых он будет принимать результат оценки.
Соберите репрезентативный набор задач
Используйте реальные типы запросов, очищенные от лишних личных данных, и дополните их контролируемыми учебными сценариями. Набор должен отражать частые случаи, важные редкие ситуации и границы области применения. Список удобных демонстрационных вопросов не является представительной выборкой. Сохраните происхождение каждого примера, дату, категорию и причину включения. Если часть задач придумана редакцией или аналитиком, обозначьте это явно и не выдавайте её распределение за статистику реальных обращений пользователей системы.
Разделите наборы для разработки и итоговой проверки. Если команда много раз меняла промпт на одних и тех же примерах, результат может отражать подстройку под известные формулировки. Для приёмки нужен закрытый или отдельно контролируемый набор, который не используется для обычной настройки. Укажите, кто имеет к нему доступ, как добавляются новые случаи и когда он обновляется. При этом не теряйте старые регрессионные примеры: исправленная ошибка должна оставаться проверяемой при следующих изменениях продукта.
Разбейте задачи на смысловые группы: короткие и длинные запросы, неполные данные, противоречия, новые темы, вложения, несколько языков и ограничения доступа, если они актуальны. Для каждой группы укажите ожидаемое поведение. Редкая критическая ситуация не должна исчезать в большом массиве простых вопросов. Отдельно отмечайте сценарии, где правильный результат — отказ от действия или передача человеку. Иначе система, которая уверенно отвечает всегда, может получить высокий балл за активность при неприемлемом качестве решений.
Создайте эталон и правила разметки
Эталон не всегда является единственной точной фразой. Для свободного ответа полезно перечислить обязательные факты, допустимые варианты, запрещённые утверждения и нужное действие. Например, система должна использовать известную площадь, не повторять вопрос и не придумывать цену. Несколько разных формулировок могут удовлетворять этим требованиям. В ТЗ укажите, что сравнивается буквально, что проверяется по смыслу и где требуется эксперт. Это снижает риск наказывать полезный ответ только за отличие от заранее написанного образца.
Подготовьте инструкцию разметчикам с примерами пограничных случаев. «Полезно», «точно» и «безопасно» слишком неопределённы без объяснения. Для каждой оценки нужны признаки и правило при недостатке информации. Проведите небольшой совместный разбор, затем независимую разметку части набора. Расхождения показывают не только качество системы, но и неоднозначность требований. Зафиксируйте порядок разрешения споров и версию инструкции. Если эталон изменился, старые результаты нельзя напрямую сравнивать с новыми без пересчёта или явной оговорки.
Не делайте модель единственным судьёй критических решений без проверки её оценок. Автоматический оценщик может быть полезен для предварительной сортировки, но тоже ошибается и зависит от формулировки задания. Сопоставьте его решения с человеческой разметкой на выбранной выборке и исследуйте расхождения. Укажите, какие категории он может оценивать самостоятельно, а какие требуют специалиста. Для действий с существенными последствиями сохраняйте проверяемые факты и состояние системы, а не только субъективный балл другой языковой модели.
Выберите метрики под задачу и цену ошибки
Для классификации разделите пропуски нужного класса и ложные срабатывания. Их последствия могут различаться: лишняя передача оператору увеличивает нагрузку, а пропущенная жалоба оставляет клиента без помощи. Общая точность не показывает этот обмен. В библиотеке Hugging Face Evaluate метрики, сравнения моделей и измерения свойств данных выделены как разные типы инструментов. Это полезное напоминание: оценка результата модели и проверка самого набора данных отвечают на разные вопросы и должны быть описаны отдельно.
Для ответов по базе знаний измеряйте наличие нужного источника, соответствие ответа найденным данным и отсутствие неподтверждённых добавлений. Для действий проверяйте правильный инструмент, аргументы, ограничения и итоговое состояние. Для диалога добавьте сохранение контекста, отсутствие повторных вопросов и корректную передачу человеку. Не объединяйте всё в один показатель без возможности увидеть составляющие. Хороший ответ по стилю не должен компенсировать раскрытие чужих данных или выполнение действия, на которое пользователь не давал разрешения.
Согласуйте пороги до просмотра итогового результата. Порог зависит от задачи, объёма выборки и допустимого риска; число без обоснования не является универсальным стандартом качества. Показывайте размер каждой группы и неопределённость оценки. Учебный набор из нескольких десятков примеров не позволяет уверенно заявить очень редкую частоту ошибки. Если критические случаи проверялись отдельно, так и укажите. Нулевое число обнаруженных проблем в ограниченной выборке не доказывает, что вероятность ошибки в эксплуатации равна нулю.
Зафиксируйте воспроизводимые условия запуска
Сохраните версию модели, промптов, инструментов, базы знаний и настроек генерации. Для внешнего сервиса укажите доступный идентификатор версии и дату проверки. Если провайдер изменяет поведение без фиксируемой версии, это ограничение должно быть отражено в отчёте. Результат зависит не только от модели: другое извлечение документов, новый каталог услуг или изменённые права могут полностью поменять поведение. Без описания окружения повторная проверка превращается в сравнение разных систем под одним и тем же названием.
Для недетерминированных ответов определите число повторов и способ агрегирования. Один удачный ответ не подтверждает устойчивое поведение. При этом многократный запуск одинакового случая не заменяет разнообразие задач. Сочетайте повторные испытания выбранных пограничных ситуаций с широким набором реальных формулировок. Сохраняйте фактические ответы и действия, включая неудачные попытки. Нельзя выбирать лучший результат из нескольких запусков и представлять его как обычное поведение системы без объяснения процедуры отбора и полного распределения результатов.
Изолируйте внешние последствия. Проверка агента, который умеет отправлять сообщения или менять записи, должна использовать тестовые данные и контролируемый транспорт. Разделите проверку выбора действия и подтверждение реального выполнения. Если инструмент заменён имитацией, это ограничивает вывод об интеграции, но позволяет безопасно проверить логику. В отчёте укажите, какие сценарии проходили через штатную очередь, какие использовали заглушку и какие подтверждены фактическим ответом внешнего сервиса. Эти уровни нельзя называть одинаково.
Проверьте границы и поведение при неопределённости
Добавьте случаи с неполными, устаревшими и противоречивыми данными. Система должна уметь уточнять вопрос, обозначать неизвестное или передавать задачу человеку. Не требуйте уверенного ответа там, где источник отсутствует. Учебный пример: клиент сообщает о заказе, которого нет в CRM. Корректная реакция — сохранить сообщение как слова клиента и уточнить статус, а не отрицать заказ или автоматически отмечать оплату. Такой сценарий проверяет границу знания, а не только способность распознать ключевые слова.
Проверьте соблюдение инструкций при наличии недоверенного содержания в документах и сообщениях. Текст источника не должен сам по себе давать системе новые полномочия или отменять правила доступа. Используйте безопасные контрольные примеры, описывающие попытку изменить заданную роль, раскрыть недоступные сведения или выполнить постороннее действие. Приёмка должна показывать фактическое поведение инструментов и ответа. Общая фраза «защита от инъекций включена» не является доказательством устойчивости всех путей обработки внешнего содержания.
Отдельно рассмотрите изменение состояния между планированием и выполнением. Пока агент готовил действие, сотрудник мог взять задачу вручную, пользователь — отозвать просьбу, а запись — изменить владельца. Проверяйте условия непосредственно перед необратимым действием. Повтор события и перезапуск не должны создавать дубль. В наборе нужны ситуации неизвестного результата внешней попытки: безопасное поведение отличается от простого безусловного повтора. Эти проверки особенно важны для систем, которые переходят от подсказок к самостоятельным действиям.
Подготовьте отчёт, по которому можно принять работу
Отчёт должен включать описание системы, наборов, методики, метрик и ограничений. Для каждой категории покажите объём, результат и характерные ошибки. Приложите фактические ответы и ожидаемое поведение, очищенные от лишних персональных данных. При сравнении версий используйте одинаковые условия либо объясните различия. Средний балл без примеров не позволяет понять, стало ли лучше для пользователя или система просто научилась избегать сложных вопросов, передавая почти всё сотруднику.
Разделите дефекты продукта, ошибки эталона и пробелы требований. Если эксперты не согласны, какую цену можно сообщать, это не обязательно проблема модели. Если правильный документ не попал в поиск, изменение стиля ответа не исправит причину. Для каждой ошибки укажите предполагаемый слой, владельца и проверку после исправления. Не превращайте предположение о причине в установленный факт. Сначала воспроизведите случай, затем изменяйте конкретный компонент и сравнивайте результат с прежней версией на согласованном наборе.
Сформируйте решение о выпуске: принято, принято с ограничениями или требуется доработка. Ограничения должны быть исполнимыми: только подсказки, отдельные категории, обязательное подтверждение действия или ручной разбор определённых случаев. Общая пометка «использовать осторожно» не управляет риском. Назначьте ответственного за контроль и условия расширения. Если проверка выявила критический дефект, высокий результат на остальных задачах не должен автоматически перевешивать его. Решение должно учитывать последствия, а не только итоговое среднее значение.
Сделайте оценку частью сопровождения
После запуска собирайте новые ошибки в контролируемый регрессионный набор. Сохраняйте контекст, версию и подтверждённое ожидаемое поведение. Не добавляйте каждую пользовательскую правку как новый эталон без проверки: сотрудник тоже может ошибиться или использовать исключение, которое нельзя обобщать. Для данных эксплуатации нужны согласованные доступ, обезличивание и сроки хранения. Улучшение качества должно опираться на управляемый процесс, а не на бесконтрольное накопление всей переписки в общей папке для будущего обучения.
Определите поводы для повторной приёмки: смена модели, новый промпт, расширение каталога, изменение инструментов или полномочий. Небольшое изменение может затронуть важную границу поведения, поэтому выбирайте проверки по влиянию, а не только по размеру правки. Следите за задержкой, стоимостью и долей ручной помощи вместе с качеством. Более точная система может стать слишком медленной для рабочего процесса; более дешёвая — чаще передавать задачи людям. Эти последствия нужно измерять на одинаковой основе.
Заполняемый бриф в источниках помогает согласовать объект оценки, данные, эталон, метрики и решение о выпуске. Начните с задач и последствий ошибки, затем выбирайте инструменты. Хорошая оценка не обещает доказать безошибочность AI-системы во всех возможных разговорах. Она показывает, что проверено, какие ограничения известны и почему выбранный режим работы допустим. Благодаря этому команда может улучшать продукт последовательно, сохраняя проверяемую связь между изменением системы и фактическим поведением в важных для бизнеса ситуациях.
Источники
- AI RMF Core
NIST AI Resource Center / доступ 2026-10-18
Первичный источник для соответствующих принципов и технических свойств. Структура требований и учебные примеры подготовлены редакцией; конкретная конфигурация проверяется отдельно.
- Evaluate: A quick tour
Hugging Face Documentation / доступ 2026-10-18
Первичный источник для соответствующих принципов и технических свойств. Структура требований и учебные примеры подготовлены редакцией; конкретная конфигурация проверяется отдельно.
- Скачать заполняемый бриф / ТЗ (.txt)
Малевич — практическое приложение / доступ 2026-10-18
Сохраните файл и заполните данные проекта, открытые решения и критерии приёмки.
FAQ
Можно ли оценить ассистента только на нескольких удачных диалогах?
Нет. Такие примеры показывают отдельные возможности, но не качество на рабочем потоке. Нужен заранее определённый набор обычных, сложных и критичных случаев с понятным происхождением.
Почему общий средний балл не определяет готовность ИИ?
Высокое среднее может скрывать редкие, но недопустимые ошибки. Критичные нарушения, качество отдельных сценариев, задержку и стоимость нужно оценивать раздельно по согласованным порогам.
Можно ли считать имитацию инструмента реальным выполнением действия?
Нет. Тест с имитатором проверяет поведение системы в заданных условиях. Реальное действие подтверждается отдельно фактическим результатом внешнего сервиса, а границы проверки указываются в отчёте.
