Подробный разбор · Около 5 мин чтения
Руководство Perplexity связывает оценку агентов с трассами и откалиброванными судьями
Официальное руководство из шести шагов объединяет реальные сбои, фиксированные данные и проверку судей экспертами: один правильный ответ не доказывает надёжность.
- Опубликовано здесь
- Дата источника
- Источник проверен
Материал Perplexity от 22 октября объясняет организацию оценивания агентов, а не представляет модель или новый результат бенчмарка. Пример закупки запчастей показывает: прежде чем толковать балл, нужно понимать действия, повторяемость и качество судейства.
Слушать новости
Прослушайте эту статью или включите новости подряд.
Подготовка чтения…
Голос устройства
Речь обрабатывает браузер или устройство. AISubHub не отправляет текст в аудио-API. Доступные голоса и работа при заблокированном экране зависят от устройства.
При продолжении короткая фраза может повториться.
Кратко
- Правдоподобный ответ может скрывать неразрешённые действия или утечку эталона; проверять нужно результат и путь к нему.
- Около 100 трасс — ориентир анализа ошибок, не обязательный порог. pass@k означает хотя бы один успех за указанное число k попыток.
- Повторное оценивание одного сохранённого запуска отделяет разброс судьи; регрессия, мониторинг и A/B решают разные задачи.
Что может скрывать правильный ответ?
Помощник по запасам способен предложить подходящую на вид деталь, обойдя правило согласования. В производственном примере Perplexity отсутствие разрешённой детали или устаревшие сведения поставщика требуют корректной реакции, а не необоснованной замены. Руководство предлагает определить и успешное выполнение, и недопустимые способы его достижения. Профильные специалисты должны проверить соответствие условий реальной работе. Гладкий текст не доказывает соблюдение полномочий.
Поэтому оцениваются также найденные сведения, обращения к инструментам и промежуточные решения. Успех задачи, корректность действий и качество ответа — разные свойства; надёжность относится к повторениям и пограничным входам. В стоимость успешной задачи входят время, token и вызовы инструментов. Наш анализ: решение о выпуске требует условий приёмки всего процесса, а не просто предпочтения хорошо написанного ответа.
Какие сбои превращать в тесты?
Руководство начинает с реальных трасс: входов, найденных свидетельств, действий и выходов. Эксперт отмечает первую существенную ошибку каждого запуска, затем сходные наблюдения объединяются в типы сбоев. LLM может предложить категории, но приоритет определяется частотой и тяжестью. Важные сбои становятся повторяемыми случаями с входом, исходными условиями, ожидаемым результатом и критериями оценки. Так сохраняется исправляемая проблема, а не подменяется удобной синтетической задачей.
Около 100 трасс — практический ориентир, не универсальный размер выборки и не статистическая гарантия. Можно остановиться раньше при теоретическом насыщении, когда новые трассы больше не выявляют содержательно новых ошибок. До запуска помогают синтетические примеры; затем следует учитывать реальные пользовательские данные. Стандартные бенчмарки дополняют собственные проверки, но неожиданные успехи и неудачи требуют проверки заданий и эталонных ответов.
Как поставить двум версиям одну и ту же задачу?
На схеме сохранённая заявка на обслуживание отделена от фиксированных данных о запасах и разрешённых деталях. maintenance_request_01.json содержит вход и ожидаемый результат; inventory_snapshot.json и approved_parts.json дают данные для сравнения. run_evals.py выполняет и проверяет процесс, а results хранит выходы, трассы и решения о прохождении. Это иллюстрация организации тестов, не производственная система или пакет, который мы запускали. Наш анализ: изменение запасов между сравнениями меняет и задачу, а не только агента.
Нужно сохранять поиск сведений и действия инструментов, а не один итоговый текст. Одинаковые входы могут давать разные результаты, поэтому число повторений зависит от риска, частоты и сложности исправления. pass@1 описывает успех за одну попытку, pass@k — хотя бы один успех за указанное число k попыток. Значение k необходимо назвать. Правильный ответ среди нескольких не гарантирует постоянный успех и не доказывает, что агент умеет выбирать верную попытку.
Кому поручить проверку каждого требования?
Для точных условий руководство предпочитает код: разрешена ли деталь, допустимы ли поля и аргументы инструментов, соответствует ли конечное состояние базы ожидаемому. Правило прозрачно, но не решает надёжно любой субъективный вопрос. Контекстные проверки, например достаточность объяснения отказа от замены, могут использовать LLM с явной рубрикой. В ней нужно определить допустимое поведение и основания для решения.
Для специальных и спорных случаев остаются необходимы эксперты. Разные проверки одного запуска могут сочетать разных судей; платформа не определяет, какие ошибки важны бизнесу. Наш анализ: разделение контроля полномочий и качества объяснения делает общий балл понятнее. Положительное мнение LLM о тексте не должно незаметно заменять точное сравнение со списком одобренных деталей. Измеренного прироста точности от такого разделения источник не приводит.
Как отделить ошибку агента от ошибки судьи?
Калибровка из пяти шагов собирает входы, выходы и трассы; получает независимые решения эксперта; запускает LLM-судью; сравнивает решения; исследует разногласия и исправляет рубрику перед проверкой новых примеров. Человеческое суждение служит ориентиром процесса, а не объявляется безошибочным. Калибровка оценивает оценщика, а не повторно запускает проверяемого агента.
Для проверки устойчивости судья несколько раз оценивает строго один и тот же сохранённый запуск и файлы без повторного исполнения агента. Иначе два источника разброса смешиваются. Матрица ошибок помогает рассмотреть обнаруженные и пропущенные ошибки, а также допустимые выходы, ошибочно признанные плохими. Люди находят и новые сбои, не известные текущим судьям. Руководство ссылается на исследования проблем бенчмарков; мы не читали их самостоятельно целиком и не воспроизводили результаты.
Когда исправление оправдывает выпуск?
Воспроизведите исходный сбой по сохранённому входу, точечно измените промпт, модель или процесс и подтвердите исправление случая. Затем запустите оставшийся набор, чтобы найти поломки ранее успешного поведения. Базовая и новая версии должны использовать одинаковые случаи и критерии. Утверждения в коде, тестовые фреймворки и CI/CD автоматизируют проверки и пороги выпуска, но не доказывают охват реальных рисков выбранными критериями.
После развёртывания откалиброванные судьи могут проверять выборку производственных трасс и отслеживать категории сбоев, а люди — необычные запросы и новые ошибки. Уместные A/B-тесты добавляют бизнес-свидетельства, например решение проблем и удовлетворённость, но не заменяют оценку и не объясняют все причины. Наш анализ: полезный цикл связывает наблюдаемый сбой, повторяемую проверку и регрессионное решение. Руководство не подтверждает новую доступность продукта или независимо измеренную надёжность.
Почему это важно
Команды могут сохранять сбой, его свидетельства и судью, сравнивать исправление со всем процессом и уточнять проверки по мере реального использования.
Ограничения и доступность
Это методические рекомендации Perplexity и пример закупки. Мы прочитали статью и схему тестов, но не внешние исследования, не проверяли производственного агента или права аккаунта. Точность, экономию и универсальный порог прохождения независимо не измеряли.
Источники и подтверждения
Дата источника: · Источник проверен:
Материалы подготовлены с помощью ИИ и сверены с указанными первоисточниками. Заявления поставщиков атрибутированы; публикация не означает рекомендацию.