Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Оценщик агентных ответов можно научить не считать ошибкой правильный ответ о другом заказе, аккаунте или обращении. В препринте Dell Technologies, который не прошёл рецензирование и содержит замеры самих авторов, CARGO снял все ложные штрафы за замену сущности, тогда как обычный оценщик браковал 100% таких ответов. Для рабочих систем это переносит эталон с уровня конкретных значений на уровень процедуры и требует проверять факты по текущему контексту.
Эталон описывает процедуру, а не текущий объект
Обычная модель-оценщик получает ответ агента и эталон, а затем ищет расхождения. Такой подход подходит для задачи, где эталон действительно содержит целевой результат, но ломается в системах с динамическими сущностями.
Например, два обращения в поддержку требуют одинаково проверить статус, гарантию и назначенного исполнителя. Номера обращений, даты и состояния при этом должны различаться. Если эталон подготовили для первого обращения, буквальное сравнение ошибочно накажет правильный ответ по второму.
Авторы называют это расхождением эталона и экземпляра. Проблема возникает не из-за неудачной формулировки инструкции: оценщик смешивает качество процедуры с совпадением значений. В эксперименте даже добавление фактов о текущем объекте не помогло, пока оценщику не изменили само правило сравнения.
CARGO предлагает читать найденный эталон как образец действий. Из него оценщик берёт обязательные проверки, политики, структуру ответа и ожидаемый маршрут агента. Идентификаторы, даты и статусы он сверяет не с эталоном, а с фактами из текущего запроса и трассировки.
Каждое утверждение получает статус, а ненадёжный поиск останавливает оценку
CARGO разбивает ответ на отдельные утверждения и присваивает им три статуса: подтверждено текущим контекстом, противоречит ему или не может быть проверено по доступным данным. Штраф получает только прямое противоречие. Непроверяемые сведения остаются нейтральными и отдельно показывают, какую часть ответа оценщик фактически смог проверить.
Это важно для агентов, которые во время работы обращаются к внутренним системам. Во входной трассировке может быть номер обращения, но не полный набор сведений из базы. Если считать любое отсутствующее значение ложным, оценщик снова начнёт штрафовать допустимые ответы.
Перед проверкой CARGO ищет похожий вопрос в эталонном наборе. Затем учитывает сходство лучшего результата и его отрыв от следующего кандидата. Если подходящий процедурный образец не найден достаточно уверенно, система воздерживается от оценки, а не выдаёт балл на основе нерелевантного эталона.
Так оценка превращается в выборочное предсказание: команда управляет долей автоматически проверенного потока, риском ошибочного вердикта и стоимостью вызовов модели. Воздержания можно направлять человеку и использовать как сигнал, что эталонный набор не покрывает определённый класс запросов.
Метод также сохраняет данные о маршрутизации, повторном планировании, типе ответа и задержках. Поэтому низкий балл можно связать не только с финальным текстом, но и с неправильным выбором специализированного агента или сбоем на отдельном шаге.
CARGO меняет оценочный контур, но не заменяет проверку процедуры
CARGO-Bench включает 246 диагностических примеров, созданных из десяти исходных сценариев технической поддержки. Его проверяли с двумя моделями-оценщиками на заменах сущности, внедрённых противоречиях, непроверяемых дополнениях, повреждениях процедуры и отвлекающих эталонах.
Индекс различения вырос до 0,58. Этот показатель вычитает долю ложных штрафов из доли найденных ошибок, поэтому простая снисходительность не позволяет получить высокий результат. CARGO перестал путать новые значения полей с ошибками и при этом находил почти все прямые противоречия текущему контексту.
Слабое место оказалось симметричным: CARGO обнаружил только 20% намеренно повреждённых процедур. Оценщик переносил правило «отсутствует в контексте — значит, непроверяемо» с полей сущности на обязательные шаги, хотя для шагов источником истины должен служить эталон. Дополнительная инструкция явно разделять эти случаи разрыв не закрыла.
Численные результаты относятся к синтетически изменённому CARGO-Bench и одному рабочему сценарию корпоративной поддержки. Проверку согласия с экспертами, работу порога поиска и соотношение риска, покрытия и стоимости на производственном потоке работа задаёт как следующий протокол, а не как завершённый эксперимент.
Для команд с динамическими сущностями работа меняет устройство оценки, но не выбор основной модели. Факты стоит сверять с текущим состоянием объекта, эталон использовать для проверки процедуры, а при сомнительном поиске не выставлять балл. При этом CARGO нельзя оставлять единственным судьёй: рядом нужен отдельный проход, который проверяет обязательные шаги и политики по процедурному эталону.
Если система решает статическую задачу и эталон действительно описывает целевой ответ, прежняя схема остаётся применимой. Изменение нужно там, где один процесс повторяется для множества обращений, активов, заказов или аккаунтов с разными значениями.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
