На этой странице
Ответ о возвращённом заказе кажется готовым к отправке: грамматически правильный, вежливый и короткий. В условном примере автоматическая оценка даёт ему максимум. Но помощник сообщает клиенту, что возврат денег уже выполнен, хотя платёжную систему никто не проверил.
Ошибка не в плохом предложении. Она в плохом определении хорошего.
В сохранённой демонстрации оценки команда строит показатели для агента, пишущего документацию. Важный момент наступает, когда человек, знающий работу, определяет качество, а инструмент превращает его описание в критерии. Позже низкий балл вызывает нужное сомнение: возможно, исправлять надо агента, а возможно оценку.
Критерии являются теорией задачи. Проверяйте эту теорию.
Начните с ошибки, обесценивающей результат
Команды часто начинают с легко оцениваемого: ясности, тона, структуры и полноты. Это полезно, но редко достаточно.
Для условного ответа о возврате «не заявлять о выполненном возврате без платёжного подтверждения» важнее качества прозы. Для синхронизации «не сопоставлять платёжный email с email владельца аккаунта» важнее красоты объяснения полей.
Попросите специалиста три вида случаев: очевидно хороший, очевидно неправильный и спорный среди осведомлённых людей. Сохраните исходные записи и причины суждений. Если случай зависит от меняющегося правила, сохраните версию правила вместе с меткой.
Первый набор может быть маленьким. Расплывчатым он быть не должен.
- Владелец задачи
хорошие, плохие и спорные случаи
- Точные проверки идентичность · разрешение · назначение
код обеспечивает факты
- Смысловые критерии
оценивать лишь требующее толкования
- Разбор разногласий
исправить метки и критерии
| Проверка | Лучший ответственный | Почему |
|---|---|---|
| Обязательное разрешение существует | Код и достоверные записи | Факт точен и имеет последствия |
| ID назначения совпадает с исходной идентичностью | Код и тестовая запись | Модель не должна угадывать идентификатор |
| Ответ решает вопрос клиента | Критерии с человеческой проверкой, возможно модель | Требуется понимание смысла |
| Тон подходит ситуации | Критерии с человеческой проверкой, возможно модель | Допустимо больше одного варианта |
Наше руководство по внедрению AI в существующие процессы также различает суждение и исполнение: уверенность модели не становится разрешением.
Балл наследует слепые места критериев
Возражение понятно: «Человек не проверит каждый запуск агента. Нам нужен масштабируемый оценщик». Да. Вопрос в том, что именно он масштабирует.
Если критерии награждают гладкий ответ, но не проверяют действительный возврат денег, автоматизация размножит пропуск. Число с двумя знаками после запятой выглядит точным, но может измерять не то.
Документация Google Cloud по проверке оценщика описывает практический тест: подготовить случаи с человеческими оценками, запустить модельную метрику и сравнить. Смысл не в непогрешимости одного человека. До доверия баллу модели требуется внешний ориентир.
Изучайте расхождения, не только среднее совпадение. Если оценщик пропускает ответ, отклонённый руководителем поддержки, ищите отсутствующее условие. Если расходятся два эксперта, сохраните оба мнения и разберите правило, которое они поняли по-разному. Не растворяйте спор в среднем.
Выбор случаев столь же важен, как формулировка условия. Коллекция обычных удач делает оценщика надёжным на вид, не затрагивая сложного. Включайте неполные записи, конфликтующие инструкции и случаи, где правильный ответ означает остановиться и спросить. Сохраняйте отдельные случаи, на которых авторы критериев не настраивались: улучшение знакомых примеров должно работать и на иных. При смене бизнес-правила обновляйте метки и ожидаемые итоги, иначе застывший набор вознаградит прошлую политику.
Связывайте оценку с итогом
Критерии агента синхронизации должны доходить до результата клиента. Изменился ли правильный контакт? Соблюдено ли согласие? Можно ли повторить неудачную запись, не повторив действие с последствиями?
Руководство по коннектору Brevo объясняет, почему успешный вызов API совместим с отсутствующим атрибутом. Оценка только вызова упустит итог. Оценка только назначения может упустить запрещённый путь, случайно давший правильное значение. Если путь несёт риск, важны оба.
Начните с узкой задачи и нескольких способов ошибиться. Размечайте случаи с владельцем задачи. Поместите точные проверки в код, а модель используйте там, где необходимы язык или суждение. Повторяйте случаи после смены промпта, модели или инструмента. Записывайте, что дальнейшие ошибки раскрыли о критериях.
Цена в экспертном времени заранее. Выгода в том, что каждый следующий балл имеет защищаемое значение.
Панель может показать число. Лишь критерии говорят, что именно сосчитано.
Часто Задаваемые Вопросы
Кто должен определять критерии оценки агента AI?
Люди, знающие задачу и её последствия, определяют допустимые результаты и исключающие ошибки. Разработчики превращают их суждения в повторяемые проверки и сравнивают оценки модели с человеческими.
Доказывает ли высокий балл работоспособность агента?
Нет. Балл показывает соответствие критериям на проверенных случаях. Слабые критерии, нерепрезентативные примеры или плохо настроенный оценщик могут дать высокий балл вредному результату.
Что проверять кодом, а не моделью?
Точные разрешения, идентификаторы записей, обязательные вызовы и состояние назначения проверяйте кодом при возможности. Модель полезна для смысловых качеств, не решаемых строгим правилом.