Проверки

Проверка — это критерий, по которому платформа оценивает ответ агента. Вопросы и правильные ответы вы задаете в датасете, а проверки выбираете, когда создаете тест.

Проверки бывают двух видов:

• LLM-проверки выполняет модель-судья. Она ставит ответу балл от 0 до 10 и коротко объясняет его.
• Проверки-правила платформа выполняет сама, без судьи: сверяет ответ с JSON-схемой кейса или вызовы функций со списком из кейса.

Если результат достигает порога, ответ проходит проверку.

Описание каждой проверки есть и на вкладке Проверки: в карточке указано, что проверка оценивает, какие поля кейса ей нужны, а у LLM-проверок — какие модели платформа рекомендует на роль судьи:

Доступные проверки

Проверка	Что оценивает	Эталон
Релевантность ответа	Отвечает ли агент на заданный вопрос. Стиль, вежливость и длина ответа на балл не влияют.	Не нужен. Если эталон задан, судья поймет из него, чего ждет вопрос, но не требует, чтобы ответ совпадал с эталоном по формулировке.
Достоверность ответа	Отсутствие выдуманных фактов. Утверждения агента должны опираться на вопрос, эталон или общеизвестные сведения. Если агент честно отвечает, что не знает, судья считает ответ достоверным.	Не нужен. Если эталон задан, судья сверит с ним факты в ответе: ответ, который противоречит эталону, получит низкий балл.
Выполнение задачи	Делает ли агент то, что описано в эталоне. Повторять эталон дословно не нужно: если агент пришел к тому же результату другими словами, задача выполнена. Если эталон — это инструкция, судья проверяет каждый ее пункт.	Обязателен: Эталонный ответ или Инструкция судье. Кейсы без эталона по ней не оцениваются.
Соответствие JSON Schema	Проверка-правило. Соответствует ли ответ агента JSON-схеме кейса. Результат — прошло или не прошло. Ответ должен состоять только из JSON в одном из двух видов: JSON без оформления, например {"topic": "delivery", "urgent": true}; JSON в блоке кода Markdown — между строками ```json и ```, как его часто оформляют LLM. Подойдет и блок без пометки json или с другой пометкой языка. Если до или после JSON есть текст, например Вот данные обращения: {"topic": "delivery", "urgent": true}, результат — не прошло, даже если сам JSON верный.	Не нужен. Обязательно поле JSON-схема ответа. Кейсы без схемы по ней не оцениваются.
Вызов инструментов	Проверка-правило. Какую долю функций из кейса вызвал агент, например 2 из 3. Учитываются только функции, которые агент вызвал как инструменты, поэтому процессу без блока Агент эта проверка не подходит. Вызов засчитывается, даже если функция завершилась с ошибкой. Порядок вызовов и аргументы не учитываются.	Не нужен. Обязательно поле Ожидаемые вызовы туллов. Кейсы без этого поля по ней не оцениваются.

Проверки можно сочетать: платформа оценит ответ по каждой проверке теста, для которой в кейсе есть нужные поля. Например, к Вызову инструментов стоит добавить Релевантность ответа: она проверит, что агент не только вызвал функцию, но и ответил клиенту по существу. Сочетания проверок для трех частых задач смотрите в разделе Примеры тестов.

Каждая проверка добавляет оценки в запуск, а в одном запуске их может быть не больше 2 000. Как посчитать число оценок, читайте в разделе Лимиты прогонов и оценок в запуске.

Пример: агент ответил не на тот вопрос

На вопрос «Сколько стоит доставка?» агент интернет-магазина рассказал о правилах возврата. По проверке Релевантность ответа судья поставит низкий балл, потому что агент ответил не на тот вопрос. По проверке Выполнение задачи судья сравнит ответ с эталоном «Доставка по Казани стоит 300 рублей» и тоже поставит низкий балл.

Модель-судья

Модель-судья — это LLM, которая оценивает ответы агента по LLM-проверкам. Проверкам-правилам судья не нужен.

Судью выбирают отдельно для каждой LLM-проверки, когда создают тест. Судьей может быть любая LLM из интеграций проекта. Выбирать судью стоит сразу: после первого запуска его в тесте изменить нельзя. Так все запуски теста оценивает одна и та же модель, и их баллы можно сравнивать между собой.

Если не знаете, какую модель взять, возьмите рекомендуемую: модели, которые платформа советует на роль судьи, перечислены в карточке LLM-проверки в блоке Рекомендуемые модели. Если рекомендуемая модель подключена к проекту, при создании теста платформа сама выберет ее судьей, а если нет — предложит первую модель в списке Модель-судья. Чтобы подключить рекомендуемую модель, нажмите в карточке проверки и выберите Добавить интеграцию. Добавить интеграцию может пользователь с ролью AP_ADMIN.

Чтобы проверить, как те же ответы оценит другая модель, поставьте прогонам дополнительную оценку. Чтобы другая модель оценивала следующие запуски, скопируйте тест с другим судьей. Запуск копии заново задаст агенту вопросы, и судья оценит уже новые ответы.

Если судья не смог поставить оценку, например из-за сбоя у провайдера модели, вместо нее будет ошибка судьи. Pass rate и среднее считаются без таких оценок: ошибка их не снижает, но запуск оценен не полностью.

Порог

Порог — это минимальный результат, при котором ответ проходит проверку. Что считается результатом и какой порог стоит по умолчанию, зависит от проверки:

• LLM-проверки — балл судьи, по умолчанию 7 из 10;
• Вызов инструментов — доля вызванных функций, по умолчанию 100%: ответ проходит проверку, только если агент вызвал все функции из кейса;
• Соответствие JSON Schema — порога нет: ответ либо соответствует схеме, либо нет.

От порога зависит Pass rate запуска — процент оценок, которые прошли проверку.

Как выбрать порог

LLM-проверки

Судья ставит балл по одной шкале во всех LLM-проверках:

• 9–10 — ответ без недочетов;
• 7–8 — мелкие недочеты, которые не меняют сути: упущена деталь, есть лишние подробности или неподтвержденная мелочь;
• 4–6 — ответ верен частично: упущена существенная часть вопроса или задачи либо верные сведения смешаны с выдуманными;
• 1–3 — агент затронул тему, но не ответил на вопрос, не выполнил задачу или выдумал большую часть ответа;
• 0 — ответ не по теме, полностью выдуман или его нет.

С порогом 7 проверку проходят ответы с мелкими недочетами, а частично верные — нет. Если вам важна точность, например в ответах о ценах, сроках или условиях возврата, поднимите порог до 9: проверку пройдут только ответы без недочетов.

Пример: порог 7 и порог 9

По проверке Выполнение задачи судья поставил десяти ответам баллы 10, 9, 9, 8, 8, 7, 7, 6, 4 и 2. С порогом 7 проверку прошли 7 ответов из 10, с порогом 9 — только 3. Если это единственная проверка в тесте, Pass rate запуска будет 70% и 30% соответственно.

Порог удобно подобрать после первых запусков: посмотрите баллы и обоснования судьи. Если проверку проходят ответы, которые вас не устраивают, поднимите порог. Если не проходят приемлемые ответы — опустите.

Вызов инструментов

Порог стоит опустить, если агенту не обязательно вызывать все функции из кейса. Например, в кейсе указаны orders.getStatus и returns.create, но для правильного ответа агенту достаточно любой из них. С порогом 50% ответ пройдет проверку, если агент вызвал хотя бы одну.

Как изменить порог

Порог задается для проверки в проекте. Когда вы создаете тест, платформа копирует в него текущий порог каждой проверки, и дальше тест оценивает ответы с этим порогом.

1. На вкладке Проверки нажмите в карточке проверки.

2. Выберите Изменить порог.

3. Укажите значение и нажмите Сохранить. В карточке проверки появится метка переопределен.

   LLM-проверки

   Порог LLM-проверки — балл от 1 до 10. Чтобы вернуть порог по умолчанию, нажмите Сбросить к 7 и Сохранить.

   

   Вызов инструментов

   Порог проверки Вызов инструментов — доля вызванных функций от 1 до 100%. Чтобы вернуть порог по умолчанию, нажмите Сбросить к 100% и Сохранить.

   

Новый порог действует на тесты, которые вы создадите позже, на дополнительные оценки и на перепрогон с выбранными проверками. Уже созданные тесты оценивают ответы с прежним порогом: так все запуски теста идут с одним порогом, и их Pass rate можно сравнивать. Прошлые оценки платформа не пересчитывает.