Perplexity Decider

Как мы его обучаем, оцениваем и используем.

АвторыPerplexity Research

Мы выпускаем Decider v1.3 и Decider Flash v1.3 — преемников наших предыдущих моделей принятия решений: v1, v1.1, v1.2 и Flash v1.2.

Decider Flash v1.3 — модель меньшего размера, дистиллированная из Decider v1.3. Обе модели доступны на Hugging Face по лицензии Apache, через OpenRouter и в Perplexity Decisions API.

Perplexity Decider создан под влиянием Jev — System One Model от TypeSafe AI. Он поддерживает бинарную и многоклассовую классификацию с упорядоченными или неупорядоченными метками и возвращает вероятности, которые приложения могут использовать для классификации, маршрутизации, ранжирования и оценки входных данных.

Обе модели v1.3 повышают качество и устойчивость в широком спектре текстовых и визуальных задач благодаря двунаправленному вниманию, более тщательно отобранным обучающим данным и усовершенствованному рецепту обучения. Мы также представляем locate — новую функцию, которая выделяет нужный фрагмент контента в задачах распознавания именованных сущностей, выявления персональных данных и экстрактивных ответов на вопросы.

В этой статье мы расскажем, как обучаем и оцениваем Decider, а также как используем его внутри Perplexity.

Что такое модель принятия решений?

Модель принятия решений — это классификатор общего назначения. Вы передаёте ей входные данные и набор вопросов, у каждого из которых есть возможные ответы. Для каждого вопроса модель возвращает распределение вероятностей по ответам. Поддерживаются 3 типа вопросов:

  • Да / Нет: бинарные решения.
  • Несколько вариантов: пользовательские многоклассовые метки.
  • Оценка: упорядоченные уровни.

Модели принятия решений поддерживают широкий спектр задач классификации и оценки:

  • Оценка выходных данных: проверка достоверности, качества и безопасности.
  • Маршрутизация: направление запросов в меньшие или более крупные модели в зависимости от сложности.
  • Модерация и безопасность: обнаружение вредоносного контента, фишинга и промпт-инъекций в выходных данных инструментов.
  • Фильтрация и тегирование: упорядочивание больших коллекций контента.
  • Поиск и переранжирование: оценка релевантности результатов поиска.

Многие из этих задач раньше решались генеративными моделями, такими как LLM, хотя они не требуют генерации текста в свободной форме. Модели принятия решений занимают промежуточное положение между LLM и классификаторами для конкретных задач. Они возвращают вероятности для нескольких вопросов об одних и тех же входных данных за один прямой проход, избегая генерации ответа токен за токеном и разделяя вычисления между вопросами. В отличие от классификаторов для конкретных задач, они могут решать новые задачи с помощью промптов на естественном языке — эту гибкость они приобретают благодаря обучению на разнообразных задачах в едином формате «вопрос — ответ».

Обучение

Как превратить генеративную LLM в модель принятия решений

Мы создаём Decider, адаптируя мощные генеративные LLM в качестве базовых моделей. Чтобы объяснить эту адаптацию, сначала опишем, как представлен запрос. Как показано ниже, запрос состоит из общего контекста (состояния) и нескольких вопросов. Состояние повторно используется всеми вопросами.

Например, имея документ и его краткое содержание, в одном запросе можно спросить, точно ли краткое содержание передаёт документ и рассчитано ли оно на эксперта или на широкую аудиторию. После состояния каждый блок вопроса содержит вопрос и возможные ответы, каждому из которых назначен заранее определённый токен-метка, например A, B или C. Специальный токен <|marker|> указывает, где считывать предсказание модели. В этой позиции обученный линейный выходной слой (голова принятия решений) отображает скрытое состояние в оценки для вариантов ответа на вопрос, которые затем преобразуются в вероятности.

Мы инициализируем выходной слой из базовой модели, который обычно оценивает следующий токен по всему словарю, и оставляем только строки, соответствующие заранее определённым токенам вариантов, например A, B или C. Затем этот усечённый слой обучается преобразовывать скрытое состояние <|marker|> в оценки ответов. Такой подход охватывает все вопросы классификации, поскольку любой из них можно сформулировать как вопрос с несколькими вариантами ответа.

Для обучения мы берём сотни общедоступных датасетов с разнообразными задачами (анализ тональности, логический вывод на естественном языке, определение намерений, сопоставление сущностей, модерация, проверка фактов, рейтинги и т. д.) и преобразуем каждый пример в описанный выше единый формат: состояние, один или несколько вопросов, их варианты ответа и целевое значение. Целевым значением может быть единственный правильный вариант, если у нас есть эталонные (gold) метки, или распределение вероятностей по вариантам.

В v1.3 мы представляем locate — функцию, которая извлекает текст из состояния, а не выбирает из заранее заданных вариантов. Вопрос locate описывает, что нужно найти, — с помощью короткой метки, например «местоположение», или инструкции, например «Извлеки название города, в котором находится вакансия». Модель возвращает точно совпадающий текст из состояния вместе с позициями его начального и конечного символов. Если совпадений не найдено, она возвращает пустой список.

Благодаря общему состоянию один запрос может объединять вопросы locate, классификации и оценки, относящиеся к одним и тем же входным данным. Например, можно спросить, требует ли вакансия опыта на уровне старшего специалиста, и извлечь необходимые навыки.

Двунаправленное внимание: модель читает в обоих направлениях

Наши модели строятся на мощных предобученных генеративных базовых моделях (backbone), каузальное внимание которых позволяет каждому токену учитывать только себя и предшествующие токены. Абляционные исследования показали, что если сделать слои полного внимания базовой модели двунаправленными, качество повышается, поэтому мы используем такую архитектуру, чтобы каждый токен мог учитывать контекст всего входа.

Двунаправленное внимание ставит ещё один архитектурный вопрос: как должны взаимодействовать состояние и вопросы? Мы рассмотрели три схемы внимания, по-разному влияющие на качество, стабильность ответов и повторное использование кэша:

  • Всё видит всё (v1.2): состояние и все вопросы обрабатываются вместе с полным двунаправленным вниманием. Вычисления по состоянию выполняются совместно, но ответ на один вопрос может меняться в зависимости от того, какие ещё вопросы заданы.
  • Изолированные вопросы (v1.3): состояние обращает внимание на все вопросы, а каждый вопрос — только на состояние и собственные токены. Вопросы по-прежнему могут косвенно влиять друг на друга через общее состояние, но результаты становятся стабильнее.
  • Полностью кэшируемый вариант: состояние применяет внимание только к самому себе, а каждый вопрос — к состоянию и к собственным токенам. Состояние не зависит от вопросов и может повторно использоваться в разных запросах, что позволяет задействовать кэширование промптов. По умолчанию мы этот вариант не используем, поскольку для ряда задач очень важно, чтобы состояние видело вопросы, однако небольшое дообучение позволяет переключить модель на него.

В итоге мы выбрали изолированные вопросы за их высокое качество и стабильность.

Рецепт обучения

Для обеих моделей обучение проходит в три этапа. Сначала мы обучаем более крупную модель на базе Qwen3.8-27B с функцией потерь на основе перекрёстной энтропии на больших наборах данных, а затем дистиллируем её в меньшую модель Qwen3.5-4B.

Первый этап — универсальное обучение, на котором мы полностью дообучаем модель на крупномасштабных корпусах. На этом этапе мы принимаем только данные, которые улучшают модель в целом и не привязаны к какому-либо бенчмарку; поэтому мы исключаем любые обучающие выборки бенчмарков.

После обучения этой универсальной модели мы проводим второй, более детальный этап с использованием LoRA. Данные на этом этапе ориентированы на конкретные домены и задачи. Мы добавляем данные на втором этапе, а не на первом, если наблюдаем лишь узкий прирост или регрессию на других задачах. LoRA позволяет не слишком отдаляться от универсальной модели и не терять производительность ради подгонки под эти конкретные домены. Цель — улучшить производительность, сохранив общие знания базовой модели. Кроме того, при слиянии LoRA с базовой моделью мы используем вес, чтобы точнее контролировать дрейф и отдавать приоритет метрикам на отложенных данных, а не приросту внутри домена.

Наконец, мы добавляем этап, специфичный для зрения. Как и второй этап, он рассматривается как ещё одна тонкая специализация: используется адаптер LoRA, который затем объединяется с базовой моделью с определённым весом. Некоторые визуальные возможности могут достигаться ценой качества на тексте. Поскольку модели гораздо чаще используются для текста, мы ставим текстовые метрики выше визуальных.

На обоих текстовых этапах мы используем усреднённые веса трёх запусков, каждый из которых выполнялся с отдельным случайным начальным значением (seed). Мы обнаружили, что это повышает качество и устойчивость агрегированной модели.

Получив итоговую большую модель, мы применяем ту же трёхэтапную процедуру обучения к меньшей модели. Здесь большая модель выступает в роли учителя: её предсказанное распределение выходов заменяет эталонные метки, а меньшая модель обучается минимизировать KL-дивергенцию между своими предсказаниями и предсказаниями учителя. Такая цель дистилляции превосходит перекрёстную энтропию на тех же обучающих данных. Хотя перекрёстная энтропия показывает лучшие результаты на бенчмарках с выделенными обучающими данными, она хуже обобщается на отложенные данные. Мы предполагаем, что дистилляция лучше передаёт распределение выходов учителя, включая его уверенность в неэталонных альтернативах, тогда как перекрёстная энтропия способствует переобучению под распределение обучающих данных конкретного бенчмарка. Поэтому мы используем цель дистилляции на основе KL-дивергенции.

Чтобы избежать загрязнения обучающих данных тестовыми, мы удаляем все обучающие примеры, которые могут пересекаться с любой из используемых нами оценок. Это важно, поскольку некоторые общедоступные обучающие наборы данных содержат значительную часть ряда оценочных наборов. Мы также проводим масштабные аудиты на предвзятость и устраняем её, чтобы наш прирост был надёжным, а не объяснялся лишь выученными смещениями.

Добавление возможности извлекать информацию

Функция locate извлекает из текста информацию, например именованные сущности, не меняя того, как модель отвечает на обычные запросы. Для этого мы вводим дополнительный этап обучения: добавляем в Decider новый специальный токен <|locate|>, span-голову и адаптер LoRA.

Мы инициализируем эмбеддинг <|locate|> на основе <|marker|>, обученного на предыдущих этапах. Мы обучаем только этот новый эмбеддинг, span-голову и адаптеры LoRA, оставляя исходные веса базовой модели и голову принятия решений замороженными. Каждое запрошенное поле получает собственный токен <|locate|>.

Голова выделения фрагментов (span head) использует представление <|locate|> вместе с представлениями токенов состояния, чтобы оценивать, где начинаются и заканчиваются подходящие фрагменты и какие пары начала и конца относятся друг к другу. Кроме того, она использует представление токена <|locate|> для предсказания порогов этих оценок для каждого поля. Выбранные фрагменты возвращаются в виде позиций символов в исходном тексте.

Мы обучаем голову выделения фрагментов с помощью адаптированной функции потерь InfoNCE, которая поднимает оценку каждого эталонного фрагмента выше порога, а порог — выше оценки любого другого фрагмента. Функция потерь состоит из двух слагаемых: первое поднимает оценки правильных фрагментов выше порога и неправильных фрагментов. Второе слагаемое поднимает порог выше оценок неправильных фрагментов. Для полей без ответа используется только второе слагаемое, благодаря чему модель учится возвращать пустой список.

Мы обучаем модель на наборе задач извлечения фрагментов текста, включая распознавание именованных сущностей, обнаружение PII и экстрактивные ответы на вопросы. Мы варьируем описания полей от коротких меток до подробных инструкций, чтобы модель училась следовать запросу, а не запоминать фиксированный набор меток.

Locate обучает модель структурно иной задаче, и мы хотим добавить её, не теряя того, что модель уже умеет хорошо. Слияние адаптеров locate с базовой моделью приводит к некоторой регрессии на запросах принятия решений. Чтобы ограничить её, мы проводим исследования, например используем больше данных для повторного воспроизведения (replay) с предыдущих этапов и вспомогательные цели, которые удерживают выходы модели на запросах принятия решений близкими к выходам исходной модели. Однако мы видим, что слияние пока не обходится без потерь, поэтому мы не сливаем адаптеры с моделью и активируем их только для запросов locate.

Оценка

Мы оцениваем Decider v1.3 и Decider Flash v1.3 на внешних бенчмарках: Hugging Face Decision Index, ClaimBench от Vals AI и Artificial Analysis Decision Index.

По итогам этих оценок наши модели демонстрируют высокую производительность. Хотя эти рейтинги включают закрытые задачи, их всё равно можно накрутить за счёт повторных отправок и итеративной настройки на основе обратной связи от рейтинга. В дополнение к ним мы оцениваем модели на внутреннем наборе, сочетающем закрытые производственные задачи с отложенными оценками на основе общедоступных наборов данных, не являющихся бенчмарками. Эти оценки служат дополнительной проверкой обобщающей способности за пределами общедоступных бенчмарков и помогают нам отличать более широкие улучшения от прироста, характерного лишь для знакомых наборов оценок.

Для внутреннего использования мы создали набор из более чем 200 задач из разных областей, включая классификацию, оценку, переранжирование и извлечение сущностей. Чтобы честно оценить реальную эффективность Decider, все оценки проводятся в режиме zero-shot, без дообучения под конкретные задачи, — это даёт нам чёткое понимание того, что в модели нужно улучшить.

Классификация запросов

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

На 63 задачах классификации с эталонами, независимо переразмеченными передовой LLM, Decider v1.3 достигает средней точности 91,6%, превосходя наши производственные классификаторы на 6,54 процентного пункта. Decider Flash v1.3 также опережает производственный базовый уровень, а Decider v1.3 превосходит Jev 1.14.

Предметно-ориентированная классификация

Мы собрали из общедоступных датасетов набор предметно-ориентированных тестов, чтобы оценить качество классификации моделей принятия решений в семи областях: проверка утверждений (6 задач), здравоохранение (7), кибербезопасность (8), программирование (16), государственное управление (7), право (9) и финансы (9).

Например, «оценить временную сложность программы на Python» или «по годовому финансовому отчёту определить, покрывают ли денежные средства компании без ограничений на использование основную сумму долга, подлежащую погашению в ближайшие двенадцать месяцев». Decider v1.3 лидирует во всех семи областях, опережая Jev 1.14 на величину до 12,9 процентного пункта в финансах и на 9,3 пункта в праве. Decider Flash v1.3 уступает Jev 1.14 в финансах, программировании и праве, а в остальных областях показывает сопоставимые результаты.

Поиск и переранжирование

Поиск лежит в основе Perplexity. Мы поддерживаем обширный набор задач поиска для оценки качества переранжирования наших моделей. Для каждой задачи мы сначала с помощью набора моделей эмбеддингов извлекаем из каждого корпуса 50 наиболее подходящих документов-кандидатов. Затем мы переранжируем этих кандидатов с помощью Decider и сравниваем его результаты с сильным базовым реранкером Qwen3-Reranker-8B.

Мы оцениваем Decider в поточечной (pointwise) постановке zero-shot: модель напрямую и независимо оценивает каждую пару «запрос–документ» и ранжирует документы по релевантности. На 72 задачах поиска Decider v1.3 достигает среднего nDCG@10, равного 83,99, опережая Qwen3-Reranker-8B на 1,81 пункта и Jev 1.14 на 2,24 пункта.

На бенчмарке BEIR обе модели опережают Qwen3-Reranker-8B на 8,78 и 7,05 nDCG@10 соответственно. По сравнению с Jev 1.14 Decider v1.3 набирает на 1,33 пункта больше, а версия Flash — на 0,4 пункта меньше.

Многоязычная классификация

Чтобы оценить модели принятия решений за пределами английского языка, мы собрали многоязычный бенчмарк классификации, включающий 19 задач для отдельных языков из 8 общедоступных датасетов, — 46 484 примера на восьми языках: немецком, испанском, французском, итальянском, русском, японском, корейском и китайском. Бенчмарк охватывает определение намерений, тематическую классификацию, анализ тональности, логический вывод на естественном языке (NLI), выявление перефразирования, обнаружение оскорбительной лексики и оценку грамматической приемлемости.

Мы приводим среднюю точность по задачам для каждого языка, придавая каждой задаче одинаковый вес. Decider v1.3 превосходит Jev 1.14 на всех восьми языках, а Decider Flash v1.3 — на шести; средняя точность по задачам составляет 88,16% у Decider v1.3 и 86,50% у Decider Flash v1.3 против 85,41% у Jev 1.14.

NER, PII и экстрактивные ответы на вопросы

Мы оцениваем функцию locate на 17 задачах вне обучающей области (out-of-domain), которые проверяют извлечение в разных областях, форматах входных данных (текст, таблицы, структурированные документы) и типах инструкций (короткие метки, вопросы и подробные описания). Области варьируются от Википедии до научных статей, отчётов о киберугрозах, технической поддержки, политик конфиденциальности, резюме и юридических договоров. Запросы варьируются от коротких названий меток, таких как «человек» или «адрес электронной почты», через вопросы о таблице или обращении в службу поддержки, до подробных описаний полей для структурированного извлечения, например сторон соглашения о неразглашении (NDA) или итоговой суммы в счёте.

Для оценки NER и PII мы используем F1 по точному совпадению фрагментов: предсказанные фрагменты должны в точности совпадать с границами эталонных. Для экстрактивных вопросов и ответов (QA) применяется F1 на уровне символов, который частично засчитывает перекрывающийся текст ответа, а для структурированного извлечения — точность по полям, то есть доля правильно извлечённых полей. Для разбора резюме мы усредняем показатели F1 по точному совпадению фрагментов для NER и PII.

Мы сравниваем наши модели с универсальными моделями извлечения разного размера: GLiNER large v2.5 (0,5 млрд параметров), Liquid d1 (2 млрд) и Clairic от Cloudflare (размер не раскрывается). Decider v1.3 достигает среднего балла 69,0 (по основной метрике каждой задачи), а Decider Flash v1.3 — 63,6, тогда как у Liquid d1 — 43,3, у Clairic — 41,5, а у GLiNER large v2.5 — 33,6. Обе модели Decider лидируют во всех категориях.

Классификация изображений

Decider изначально поддерживает задачи компьютерного зрения, начиная с v1. Чтобы оценить его возможности за пределами текста, мы собрали набор из пяти бенчмарков с особым акцентом на классификацию документов, включая счета, письма и резюме. Набор также охватывает классификацию спутниковых снимков, классификацию текстур, определение породы домашних животных и подсчёт животных.

Decider v1.3 достигает средней точности 76,99% на пяти визуальных задачах, опережая Jev 1.14 на 1,47 процентного пункта. Decider Flash v1.3 достигает 72,77%, демонстрируя возможности визуальной классификации в модели меньшего размера.

Реальные запросы на принятие решений

Мы отобрали один миллион дедуплицированных запросов с замаскированными PII, отправленных в Perplexity Decision API за первые 18 дней его доступности. Поскольку каждый запрос может содержать несколько вопросов об одном и том же состоянии, выборка включает 2 318 887 отдельных вопросов. Все запросы были включены в выборку с явного разрешения пользователей на использование в исследованиях.

Производственные запросы не сопровождаются эталонными метками, поэтому мы используем передовые LLM в роли судей для генерации эталонных ответов и измеряем, насколько каждая модель с ними согласуется. Мы также разделяем запросы на 10 категорий задач: извлечение информации, классификация по предметной области, анализ тональности, намерения и маршрутизация, ранжирование по релевантности, модерация контента, проверка качества и соответствия требованиям, сопоставление сущностей, бизнес-анализ и категория «Другое». Такая разбивка показывает, как меняется качество в различных реальных сценариях.

Задачи распределены неравномерно: на извлечение информации приходится 425 402 вопроса, на классификацию по предметной области — 409 564, на анализ тональности — 344 158. Вместе эти три категории составляют 50,8% вопросов в выборке.

Decider v1.3 демонстрирует наивысшую согласованность с судьями — 93,98% против 93,68% у Decider v1.2 и 93,35% у Jev 1.14. В классификации по предметной области и анализе тональности Decider v1.3 и Jev 1.14 идут почти вровень: разница составляет 0,34 и 0,07 процентного пункта соответственно. Jev лидирует с отрывом 0,69 пункта в ранжировании по релевантности, а Decider v1.3 опережает на 0,93 пункта в извлечении информации (самой распространённой задаче в выборке) и на 1,21 пункта в задачах намерений и маршрутизации.

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

Decider работал локально; GLM и DeepSeek использовали llm-api; Jev — OpenRouter. Указанные затраты зависят от конкретной рабочей нагрузки; способ учёта стоимости локального оборудования не уточняется, а сравнение при сопоставимой задержке не проводилось.

Устойчивость

Мы оценили чувствительность к меткам на 372 вопросах с несколькими вариантами ответа, отправив по 4788 запросов на каждую модель. Мы меняли порядок вариантов, переназначали метки текстам ответов и переименовывали метки, сохраняя смысл каждого вопроса, а затем проверяли, изменился ли смысловой ответ модели. Чем ниже доля смены ответов, тем выше стабильность.

При каждом преобразовании Decider v1.3 менял ответ лишь на 0,27% вопросов, тогда как у Jev 1.14 этот показатель составил 2,69–4,84%. Мы также повторяли одинаковые входные данные, чтобы измерить вариативность на этапе инференса: у Decider v1.3 изменений не было, а Jev 1.14 изменил ответ на 1,88% вопросов.

Как мы используем Decider

Decider создан для рабочих процессов, которым нужны быстрые и структурированные решения. В этом разделе мы рассмотрим, как использовать его, чтобы ощутимо изменить то, как мы работаем. Вот наиболее показательные примеры.

Самосовершенствующиеся правила безопасности

Внутри компании мы уже используем Decider для совершенствования наших политик безопасности.

Действия наших агентов записываются, и к ним применяется ряд проверок на основе правил для выявления любого проблемного поведения. Подход на основе правил позволяет отслеживать агентов в реальном времени, практически не увеличивая задержку. В офлайн-режиме мы используем Decider для анализа выборок из этих записанных журналов агентов. Если проблемное поведение не было отмечено, Decider проверяет, не упустили ли что-то наши правила; если же сработало оповещение, Decider проверяет, не было ли оно ложным. Все записи, на которых наш набор правил ошибается в любом из этих случаев, передаются агенту для разбора, и он предлагает исправление правил, которое должен утвердить сотрудник нашей команды безопасности.

За один день Decider прочитал 1 млрд токенов в 7000 сеансах агентов и выявил недочёты, которые привели к 14 исправлениям правил; 6 из них были одобрены и внедрены в течение двух дней. При воспроизведении на журналах за неделю эти исправления сократили объём срабатываний нашего самого нагруженного правила на 52%, а расширенные правила выявили примерно на 40% больше легитимных действий, требующих проверки.

Мониторинг RL-роллаутов

Когда мы проводим постобучение моделей с помощью обучения с подкреплением, агрегированные метрики, такие как итоговое вознаграждение, не объясняют, почему роллаут (отдельная попытка выполнить задачу) завершился успехом или неудачей. Роллаут может несправедливо лишиться вознаграждения из-за сбоя сервиса инструмента или песочницы либо получить незаслуженное вознаграждение, если оценщик пропустит неподтверждённое утверждение, например выдуманное значение, которое не вернул ни один инструмент.

Мы используем Decider для мониторинга роллаутов в таких случаях. Сначала код определяет части роллаута, требующие более пристального изучения: неудачный вызов инструмента и связанные с ним рассуждения, код, выполненный без ошибок, или итоговый ответ. Затем Decider отвечает на вопросы с несколькими вариантами ответа о каждой части — например, что именно дало сбой на шаге (сервис инструмента, внешний сайт, песочница, harness или собственный код агента) и правильно ли агент интерпретировал результат. Мы объединяем все вопросы о конкретной части в один запрос и сохраняем вероятности, а не вердикт, чтобы позже можно было скорректировать пороги без повторных запросов к Decider. Монитор только наблюдает и диагностирует: он никогда не меняет вознаграждение и не останавливает прогон.

Фильтрация страниц по качеству

При обходе веб-страниц для индексации и выдачи пользователям многие страницы оказываются слишком низкого качества, чтобы приносить хоть какую-то пользу. Это заглушки антибот-защиты, CAPTCHA и страницы ошибок, а также корректно загруженные страницы, которые просто не содержат полезной информации, например спам, SEO-наполнитель или страницы, состоящие только из навигации. Такие низкокачественные страницы нужно выявлять и исключать из нашего индекса.

С помощью Decider мы можем оценивать качество страниц прямо во время их обхода. За тот же прямой проход мы выполняем ряд других задач классификации, например определяем тематическую область и целевую аудиторию контента, а также наличие в нём вредной, незаконной или позволяющей установить личность информации. По сравнению с использованием LLM в роли судьи Decider работает значительно быстрее и дешевле.

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

Помимо этих внутренних сценариев, Decider подходит и для таких рабочих процессов, как описанные ниже.

Визуальные вопросы и ответы

Поскольку Decider умеет читать изображения, он также служит визуальным контролёром: проверяет изменения стилей веб-страниц или приложений и выявляет дефекты. Ещё до выпуска изменения он может проверять скриншоты страниц на обрезанный текст, перекрывающиеся элементы и сломанную вёрстку, а также отмечать диаграммы, дизайн которых может ввести читателя в заблуждение или нарушить брендбук.

Навигация в браузере

Агенты могут использовать Decider для небольших решений внутри более крупных задач. Браузерный агент может отправлять скриншот на каждом шаге и получать подробную информацию о состоянии страницы и ожидаемом результате каждого возможного действия.

Планирование исследовательских задач

Вопросы пользователей могут сильно различаться по сложности, как и глубина поиска, необходимая для нахождения ответа. Decider может оценить это ещё до начала поиска, что позволяет тратить меньше ресурсов на простые вопросы.

Начало работы

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

Мы рекомендуем использовать Decider v1.3 для тонких суждений, подробных критериев оценки и рабочих процессов, в которых ошибки обходятся дорого. Выбирайте Decider Flash v1.3 для маршрутизации, разметки и фильтрации больших объёмов данных, когда главными ограничениями являются задержка и стоимость. Оцените обе модели на репрезентативных примерах из вашей рабочей нагрузки, а затем выберите ту, которая соответствует вашим требованиям к качеству, задержке и бюджету.

Обе модели доступны в виде загружаемых весов на Hugging Face по лицензии Apache, через OpenRouter и в Perplexity Decisions API.

Цитирование

BibTeX
@online{perplexity2026PerplexityDecider,
  author = {{Perplexity} and Antoine Chaffin and Jonas Golde and Louis Milliken and Sarah Eslami and Markus Krimmel and Nandor Licker and Aleksandr Nikolenko and Ron Heichman and Bo Wang and Jarrod Bryan and Jeremy Yang and Denis Yarats},
  title = {{Perplexity Decider}},
  date = {2026-11-12},
  url = {https://www.perplexity.ai/hub/blog/perplexity-decider}
}