Perplexity Decider

Estamos lançando o Decider v1.3 e o Decider Flash v1.3, sucessores dos nossos modelos de decisão anteriores: v1, v1.1, v1.2 e Flash v1.2.

O Decider Flash v1.3 é um modelo menor destilado do Decider v1.3. Ambos os modelos estão disponíveis no Hugging Face sob a licença Apache, pelo OpenRouter e pela Perplexity Decisions API.

O Perplexity Decider é inspirado no Jev, o System One Model da TypeSafe AI. Ele oferece suporte a classificação binária e multiclasse com rótulos ordenados ou não ordenados, retornando probabilidades que os aplicativos podem usar para classificar, rotear, ranquear e avaliar entradas.

Ambos os modelos v1.3 melhoram o desempenho e a robustez em uma ampla gama de tarefas de texto e visão graças à atenção bidirecional, a dados de treinamento mais bem selecionados e a uma receita de treinamento aprimorada. Também apresentamos o locate, um novo recurso que destaca o conteúdo selecionado em tarefas de reconhecimento de entidades nomeadas, identificação de informações pessoais e resposta extrativa a perguntas.

Neste post, explicamos como treinamos e avaliamos o Decider e mostramos como o usamos internamente na Perplexity.

O que é um modelo de decisão?

Um modelo de decisão é um classificador de uso geral. Você fornece uma entrada e um conjunto de perguntas, cada uma com suas possíveis respostas. Para cada pergunta, ele retorna uma distribuição de probabilidade sobre as respostas. Ele oferece suporte a 3 tipos de pergunta:

• Sim / Não: decisões binárias.
• Múltipla escolha: rótulos multiclasse personalizados.
• Pontuação: níveis ordenados.

Os modelos de decisão oferecem suporte a uma ampla variedade de tarefas de classificação e pontuação:

• Avaliação de saídas: análise de fidelidade, qualidade e segurança.
• Roteamento: direcionamento de solicitações para modelos menores ou maiores com base na dificuldade.
• Moderação e segurança: detecção de conteúdo nocivo, phishing e injeção de prompt em saídas de ferramentas.
• Filtragem e marcação: organização de grandes coleções de conteúdo.
• Recuperação e reranqueamento: pontuação de resultados de busca por relevância.

Muitas dessas tarefas eram tratadas anteriormente por modelos generativos, como LLMs, embora não exijam geração de texto livre. Os modelos de decisão ficam entre os LLMs e os classificadores específicos de tarefas. Eles retornam probabilidades para várias perguntas sobre a mesma entrada em uma única passagem direta, evitando a geração de respostas token por token e compartilhando a computação entre as perguntas. Ao contrário dos classificadores específicos de tarefas, eles conseguem lidar com novas tarefas por meio de prompts em linguagem natural, uma flexibilidade aprendida com o treinamento em tarefas diversas em um formato compartilhado de perguntas e respostas.

Treinamento

Como transformar um LLM generativo em um modelo de decisão

Construímos o Decider adaptando backbones robustos de LLMs generativos. Para explicar a adaptação, primeiro descrevemos como uma solicitação é representada. Como ilustrado abaixo, uma solicitação consiste em um contexto compartilhado (o estado) e várias perguntas. O estado será reutilizado por todas as perguntas.

Por exemplo, dado um documento e seu resumo, uma única solicitação pode perguntar se o resumo representa fielmente o documento e se ele se destina a um especialista ou ao público geral. Após o estado, cada bloco de pergunta contém uma pergunta e suas possíveis respostas, cada uma associada a um token de rótulo predefinido, como A, B ou C. Um token especial <|marker|> indica onde ler a previsão do modelo. Nessa posição, uma camada de saída linear aprendida (uma cabeça de decisão) mapeia o estado oculto para pontuações das opções de resposta da pergunta, que são então convertidas em probabilidades.

Expandir

Inicializamos a camada de saída a partir do modelo base, que normalmente pontua o próximo token em todo o vocabulário, e mantemos apenas as linhas correspondentes aos tokens de opção predefinidos, como A, B ou C. Essa camada podada é então treinada para transformar o estado oculto de <|marker|> em pontuações de resposta. Essa abordagem abrange todas as perguntas de classificação, porque todas elas podem ser formuladas como múltipla escolha.

Para o treinamento, usamos centenas de conjuntos de dados públicos que abrangem tarefas diversas (sentimento, inferência em linguagem natural, detecção de intenção, correspondência de entidades, moderação, checagem de fatos, avaliações etc.) e convertemos cada exemplo no formato unificado descrito acima: um estado, uma ou mais perguntas, suas opções e um alvo. O alvo pode ser a única opção correta, se tivermos rótulos de referência, ou uma distribuição de probabilidade sobre as opções.

Na v1.3, apresentamos o locate, que extrai texto do estado em vez de selecionar entre opções predefinidas. Uma pergunta de locate descreve o que encontrar, usando um rótulo curto, como “localização”, ou uma instrução, como “Extraia o nome da cidade onde a vaga está localizada.” O modelo retorna o texto exato correspondente do estado, junto com as posições de caractere de início e fim. Se não identificar nenhuma correspondência, ele retorna uma lista vazia.

Expandir

Graças ao estado compartilhado, uma única solicitação pode combinar perguntas de locate, classificação e pontuação sobre a mesma entrada. Por exemplo, ela pode perguntar se uma vaga exige experiência de nível sênior e extrair as habilidades exigidas.

Atenção bidirecional: permitindo que o modelo leia nos dois sentidos

Nossos modelos partem de backbones generativos pré-treinados robustos, cuja atenção causal permite que cada token preste atenção apenas a si mesmo e aos tokens anteriores. Nossos estudos de ablação mostraram que tornar bidirecionais as camadas de atenção completa do backbone melhora o desempenho, por isso adotamos esse design para que cada token incorpore o contexto de toda a entrada.

A atenção bidirecional introduz outra escolha de design: como o estado e as perguntas devem interagir? Consideramos três padrões de atenção, com implicações diferentes para o desempenho, a estabilidade das respostas e a reutilização de cache:

• Tudo vê tudo (v1.2): O estado e todas as perguntas são processados juntos com atenção bidirecional completa. A computação sobre o estado é compartilhada, mas a resposta a uma pergunta pode mudar dependendo do que mais for perguntado.
• Perguntas isoladas (v1.3): O estado presta atenção a todas as perguntas, enquanto cada pergunta presta atenção apenas ao estado e aos seus próprios tokens. As perguntas ainda podem influenciar umas às outras indiretamente por meio do estado compartilhado, mas os resultados são mais estáveis.
• Totalmente armazenável em cache: o estado presta atenção apenas a si mesmo, enquanto cada pergunta presta atenção ao estado e aos seus próprios tokens. O estado é independente das perguntas e reutilizável entre solicitações, aproveitando o cache de prompts. Não usamos essa opção por padrão, porque permitir que o estado veja as perguntas é muito importante para várias tarefas, mas um pequeno ajuste fino pode adaptar um modelo a ela.

No fim, escolhemos as perguntas isoladas pelo seu ótimo desempenho e estabilidade.

Expandir

Receita de treinamento

O treinamento ocorre em três etapas para ambos os tamanhos de modelo. Primeiro, treinamos o modelo maior, baseado no Qwen3.8-27B, usando entropia cruzada em grandes conjuntos de dados e, depois, o destilamos no modelo menor Qwen3.5-4B.

A primeira etapa é o treinamento generalista, em que fazemos o ajuste fino completo do modelo em corpora de grande escala. Nessa etapa, aceitamos apenas dados que ajudam o modelo de forma geral e não são específicos de nenhum benchmark; por isso, excluímos quaisquer divisões de treinamento de benchmarks.

Depois que esse modelo generalista é treinado, executamos uma segunda etapa, mais granular, usando LoRA. Os dados usados nessa etapa são direcionados a domínios e tarefas específicos. Adicionamos dados na segunda etapa, e não na primeira, quando observamos ganhos restritos ou algumas regressões em outras tarefas. Usamos LoRA para evitar nos afastar demais do modelo generalista e correr o risco de perder desempenho ao nos ajustarmos a esses domínios específicos. O objetivo é melhorar o desempenho preservando o conhecimento geral do backbone. Também usamos um peso ao mesclar o LoRA de volta ao modelo base, para controlar o desvio com mais precisão e priorizar as métricas em dados reservados acima de quaisquer ganhos no domínio.

Por fim, adicionamos uma etapa específica de visão. Assim como na segunda etapa, a etapa de visão é tratada como mais uma etapa de especialização refinada, usando um adaptador LoRA que é mesclado de volta ao modelo base com um peso. Algumas capacidades de visão podem custar desempenho em texto. Como observamos um uso muito maior dos modelos em texto, priorizamos as métricas de texto em vez das métricas de visão.

Para ambas as etapas de texto, usamos a média dos pesos de três execuções, cada uma com uma semente aleatória diferente. Descobrimos que isso melhora o desempenho e a robustez do modelo agregado.

Depois de obtido o modelo grande final, aplicamos o mesmo procedimento de treinamento em três etapas ao modelo menor. Aqui, o modelo grande atua como professor: sua distribuição de saída prevista substitui os rótulos de referência (gold labels), e o modelo menor é treinado para minimizar a divergência KL entre suas previsões e as do professor. Esse objetivo de destilação supera a entropia cruzada nos mesmos dados de treinamento. Embora a entropia cruzada tenha melhor desempenho em benchmarks com dados de treinamento dedicados, ela generaliza pior para dados reservados. Nossa hipótese é que a destilação transfere melhor a distribuição de saída do professor, incluindo sua confiança em alternativas diferentes do rótulo de referência, enquanto a entropia cruzada favorece o sobreajuste à distribuição de treinamento específica do benchmark. Por isso, adotamos o objetivo de destilação baseado em KL.

Para mitigar a contaminação entre treino e teste, removemos todas as amostras de treinamento que possam se sobrepor a qualquer avaliação que usamos. Isso é importante porque alguns conjuntos de dados públicos de treinamento contêm grandes partes de certos conjuntos de dados de avaliação. Também realizamos auditorias abrangentes de vieses e os removemos para garantir que nossos ganhos sejam confiáveis e não apenas resultado de vieses aprendidos.

Adicionando a capacidade de extrair informações

O recurso locate extrai informações, como entidades nomeadas, de textos, sem alterar a forma como responde a solicitações comuns. Para isso, introduzimos uma etapa adicional de treinamento: adicionamos ao Decider um novo token especial, <|locate|>, uma cabeça de span e um adaptador LoRA.

Inicializamos o embedding de <|locate|> a partir do <|marker|> aprendido nas etapas de treinamento anteriores. Treinamos apenas esse novo embedding, a cabeça de span e os adaptadores LoRA, mantendo congelados os pesos originais do backbone e a cabeça de decisão. Cada campo solicitado recebe seu próprio token <|locate|>.

A cabeça de spans usa a representação de <|locate|> junto com as representações dos tokens de estado para pontuar onde os spans correspondentes começam e terminam e quais pares de início e fim pertencem um ao outro. Ela também usa a representação do token <|locate|> para prever limiares específicos de cada campo para essas pontuações. Os spans selecionados são retornados como posições de caracteres no texto original.

Treinamos a cabeça de spans com uma perda InfoNCE adaptada que eleva cada span de referência acima do limiar, e o limiar acima de todos os outros spans. A perda tem dois termos: o primeiro eleva as pontuações dos spans corretos acima do limiar e dos spans errados. O segundo termo eleva o limiar acima das pontuações dos spans errados. Campos sem resposta recebem apenas o segundo termo, o que ensina o modelo a retornar uma lista vazia.

Treinamos com uma combinação de tarefas de extração de spans, incluindo reconhecimento de entidades nomeadas, detecção de PII e resposta extrativa a perguntas. Variamos as descrições dos campos, de rótulos curtos a instruções detalhadas, para que o modelo aprenda a seguir a solicitação em vez de memorizar um conjunto fixo de rótulos.

O Locate ensina ao modelo uma tarefa estruturalmente diferente, e queremos adicioná-la sem perder o que o modelo já faz bem. Mesclar os adaptadores do locate ao backbone causa alguma regressão nas solicitações de decisão. Para limitar isso, estamos conduzindo investigações, como o uso de mais dados de replay das etapas anteriores e de objetivos auxiliares que mantêm as saídas do modelo em solicitações de decisão próximas às do modelo original. No entanto, constatamos que, por enquanto, a mesclagem ainda não é sem perdas, por isso mantemos os adaptadores sem mesclar e os ativamos apenas para solicitações de locate.

Avaliação

Avaliamos o Decider v1.3 e o Decider Flash v1.3 em benchmarks externos do Hugging Face Decision Index, do ClaimBench da Vals AI e do Artificial Analysis Decision Index.

Nessas avaliações, nossos modelos demonstram um desempenho sólido. Embora esses rankings incluam tarefas privadas, eles ainda podem ser manipulados por meio de envios repetidos e ajustes iterativos com base no feedback do ranking. Para complementar esses rankings, avaliamos os modelos em um conjunto interno que combina tarefas privadas de produção com avaliações reservadas extraídas de conjuntos de dados públicos que não são benchmarks. Essas avaliações oferecem uma verificação adicional da generalização além dos benchmarks públicos, ajudando-nos a distinguir melhorias mais amplas de ganhos específicos de conjuntos de avaliação conhecidos.

Internamente, criamos um conjunto de mais de 200 tarefas que abrangem diversos domínios e tipos de tarefa, como classificação, pontuação, reranqueamento e extração de entidades. Para avaliar com honestidade o desempenho do Decider no mundo real, todas as avaliações são feitas em zero-shot, sem ajuste fino específico para cada tarefa, o que nos dá um sinal claro de onde melhorar o modelo.

Classificação de consultas

Na Perplexity, usamos um sistema de classificação multicabeça para processar cada consulta do usuário. Cada consulta passa primeiro por um modelo de embedding que atua como extrator de características. O embedding resultante é então enviado a várias cabeças de classificação separadas, incluindo classificadores binários e multirrótulo. Por exemplo, uma cabeça determina se uma consulta do usuário deve acionar uma pesquisa na web.

Em 63 tarefas de classificação com referências rerrotuladas de forma independente por um LLM de fronteira, o Decider v1.3 atinge 91,6% de acurácia média, superando nossos classificadores de produção em 6,54 pontos percentuais. O Decider Flash v1.3 também supera a linha de base de produção, enquanto o Decider v1.3 supera o Jev 1.14.

Expandir

Classificação específica por domínio

Montamos um conjunto de avaliação específico por domínio a partir de conjuntos de dados públicos para avaliar o desempenho de classificação dos modelos de decisão em sete domínios: verificação de alegações (6 tarefas), saúde (7), cibersegurança (8), programação (16), governo (7), direito (9) e finanças (9).

Por exemplo, “avaliar a complexidade de tempo de um programa em Python” ou “usar um relatório financeiro anual para determinar se o caixa irrestrito de uma empresa cobre o principal da dívida com vencimento nos próximos doze meses”. O Decider v1.3 lidera em todos os sete domínios, superando o Jev 1.14 em até 12,9 pontos percentuais em finanças e 9,3 pontos em direito. O Decider Flash v1.3 fica atrás do Jev 1.14 em finanças, programação e direito, e tem desempenho semelhante nos demais domínios.

Expandir

Recuperação e reranqueamento

A busca está no centro da Perplexity. Mantemos um amplo conjunto de tarefas de recuperação para avaliar o desempenho de reranqueamento dos nossos modelos. Para cada tarefa, primeiro usamos um conjunto de modelos de embedding para recuperar os 50 principais documentos candidatos de cada corpus. Em seguida, reranqueamos esses candidatos com o Decider e comparamos seu desempenho com uma linha de base robusta de reranqueamento, o Qwen3-Reranker-8B.

Avaliamos o Decider em um cenário zero-shot e pointwise, usando o modelo para pontuar diretamente cada par consulta–documento de forma independente e ordenar os documentos por relevância. Em 72 tarefas de recuperação, o Decider v1.3 atinge um nDCG@10 médio de 83,99, superando o Qwen3-Reranker-8B em 1,81 ponto e o Jev 1.14 em 2,24 pontos.

No benchmark BEIR, os dois modelos superam o Qwen3-Reranker-8B em 8,78 e 7,05 pontos de nDCG@10, respectivamente. Em relação ao Jev 1.14, o Decider v1.3 fica 1,33 ponto acima, enquanto a versão Flash fica 0,4 ponto abaixo.

Expandir

Classificação multilíngue

Para avaliar modelos de decisão além do inglês, montamos um benchmark de classificação multilíngue composto por 19 tarefas específicas de idioma provenientes de 8 conjuntos de dados públicos, com 46.484 exemplos em oito idiomas: alemão, espanhol, francês, italiano, russo, japonês, coreano e chinês. O benchmark abrange detecção de intenção, classificação de temas, análise de sentimento, inferência em linguagem natural, detecção de paráfrases, detecção de linguagem ofensiva e aceitabilidade gramatical.

Reportamos a acurácia média entre as tarefas de cada idioma, atribuindo o mesmo peso a cada tarefa. O Decider v1.3 supera o Jev 1.14 em todos os oito idiomas, e o Decider Flash v1.3 o supera em seis, com acurácias médias por tarefa de 88,16% para o Decider v1.3 e 86,50% para o Decider Flash v1.3, em comparação com 85,41% do Jev 1.14.

Expandir

NER, PII e QA extrativo

Avaliamos o recurso locate em 17 tarefas fora do domínio que testam sua capacidade de extração em diversos domínios, formatos de entrada (texto, tabelas, documentos estruturados) e instruções (rótulos curtos, perguntas e descrições detalhadas). Os domínios vão da Wikipédia a artigos científicos, relatórios de ameaças cibernéticas, suporte técnico, políticas de privacidade, currículos e contratos jurídicos. As solicitações vão de nomes de rótulos curtos, como “pessoa” ou “endereço de e-mail”, passando por perguntas sobre uma tabela ou um chamado de suporte, até descrições detalhadas de campos para extração estruturada, como as partes de um acordo de confidencialidade (NDA) ou o total de uma fatura.

Avaliamos NER e PII usando F1 de span exato, que exige que os spans previstos correspondam exatamente aos limites de referência. O QA extrativo usa F1 em nível de caractere, que dá crédito parcial a trechos de resposta sobrepostos, enquanto a extração estruturada usa a acurácia por campo, ou seja, a proporção de campos extraídos corretamente. Para a análise de currículos, calculamos a média das pontuações de F1 de span exato de NER e PII.

Comparamos nossos modelos com modelos de extração de uso geral de diferentes tamanhos: GLiNER large v2.5 (0,5B), Liquid d1 (2B) e Clairic, da Cloudflare (tamanho não divulgado). O Decider v1.3 alcança uma pontuação média de 69,0 (usando a métrica principal de cada tarefa) e o Decider Flash v1.3 alcança 63,6, em comparação com 43,3 do Liquid d1, 41,5 do Clairic e 33,6 do GLiNER large v2.5. Ambos os modelos Decider lideram em todas as categorias.

Expandir

Classificação de imagens

O Decider oferece suporte nativo a tarefas de visão desde a v1. Para avaliar seu desempenho além do texto, montamos um conjunto de benchmarks com cinco tarefas, com foco especial em classificação de documentos, incluindo faturas, cartas e currículos. O conjunto também abrange classificação de imagens de satélite, classificação de texturas, classificação de raças de animais de estimação e contagem de animais.

O Decider v1.3 atinge uma acurácia média de 76,99% nas cinco tarefas visuais, superando o Jev 1.14 em 1,47 ponto percentual. O Decider Flash v1.3 atinge 72,77%, demonstrando capacidades de classificação visual em um modelo menor.

Expandir

Solicitações de decisão do mundo real

Amostramos um milhão de solicitações deduplicadas e com PII mascaradas enviadas à Perplexity Decision API durante seus primeiros 18 dias de disponibilidade. Como cada solicitação pode conter várias perguntas sobre o mesmo estado, a amostra reúne 2.318.887 perguntas individuais. Todas as solicitações foram incluídas com permissão explícita dos usuários para fins de pesquisa.

As solicitações de produção não vêm com rótulos de referência (ground truth), por isso usamos LLMs de fronteira como juízes para gerar respostas de referência e medir a concordância de cada modelo com elas. Também agrupamos as solicitações em 10 categorias de tarefas, incluindo extração de informações, classificação de domínio, análise de sentimento, intenção e roteamento, ranqueamento por relevância, moderação de conteúdo, revisão de qualidade e conformidade, correspondência de entidades, análise de negócios e uma categoria “Outros”. Esse detalhamento mostra como o desempenho varia entre casos de uso do mundo real.

A distribuição das tarefas é desigual: extração de informações responde por 425.402 perguntas, classificação de domínio por 409.564 e análise de sentimento por 344.158. Juntas, essas três categorias representam 50,8% das perguntas da amostra.

O Decider v1.3 alcança a maior concordância com os juízes, de 93,98%, em comparação com 93,68% do Decider v1.2 e 93,35% do Jev 1.14. O Decider v1.3 e o Jev 1.14 ficam muito próximos em classificação de domínio e análise de sentimento, com diferenças de 0,34 e 0,07 ponto percentual, respectivamente. O Jev lidera por 0,69 ponto em ranqueamento por relevância, enquanto o Decider v1.3 lidera por 0,93 ponto em extração de informações (a tarefa mais comum na amostra) e por 1,21 ponto em intenção e roteamento.

Expandir

O gráfico abaixo compara o custo informado de executar o mesmo milhão de solicitações de produção. Cada solicitação pode conter várias perguntas, então a unidade aqui são solicitações, não perguntas individuais.

Expandir

Robustez

Avaliamos a sensibilidade a rótulos em 372 perguntas de múltipla escolha, fazendo 4.788 solicitações por modelo. Reordenamos as opções, reatribuímos rótulos aos textos das respostas e renomeamos rótulos preservando o significado de cada pergunta e, em seguida, verificamos se a resposta semântica do modelo mudou. Taxas de inversão mais baixas indicam maior estabilidade.

O Decider v1.3 mudou sua resposta em apenas 0,27% das perguntas em cada transformação, em comparação com 2,69%–4,84% do Jev 1.14. Também repetimos entradas idênticas para medir a variabilidade da inferência: o Decider v1.3 não apresentou mudanças, enquanto o Jev 1.14 mudou em 1,88% das perguntas.

Expandir

Como usamos o Decider

O Decider foi criado para fluxos de trabalho que exigem decisões rápidas e estruturadas. Nesta seção, exploramos como aproveitá-lo para gerar um impacto significativo na forma como trabalhamos. Veja alguns usos que se destacaram.

Regras de segurança que se aprimoram sozinhas

Internamente, já estamos usando o Decider para aprimorar nossas políticas de segurança.

A atividade dos nossos agentes é registrada, e uma série de verificações baseadas em regras é executada para identificar qualquer comportamento problemático. Uma abordagem baseada em regras permite monitorar nossos agentes em tempo real com latência adicional insignificante. Offline, usamos o Decider para analisar amostras desses logs de agentes. Quando nenhum comportamento problemático é sinalizado, o Decider verifica se há algo que nosso conjunto de regras deixou passar; e, quando um alarme é disparado, o Decider verifica se foi um alarme falso. Todos os registros em que nosso conjunto de regras falha, em qualquer um dos casos, são enviados a um agente para triagem, e uma correção das regras é proposta para aprovação por um membro da nossa equipe de segurança.

Em um dia, o Decider leu 1 bilhão de tokens em 7.000 sessões de agentes e identificou falhas que levaram a 14 correções de regras, 6 das quais foram aprovadas e implantadas em até dois dias. Reaplicadas a uma semana de logs, as correções reduziram em 52% o volume da nossa regra mais acionada, e as regras ampliadas detectaram cerca de 40% mais ações legítimas a investigar.

Expandir

Monitoramento de rollouts de RL

Quando fazemos o pós-treinamento de modelos com aprendizado por reforço, métricas agregadas como uma recompensa terminal não explicam por que um rollout (uma tentativa individual de realizar uma tarefa) teve sucesso ou falhou. Ele pode perder recompensa injustamente porque um serviço de ferramenta ou o sandbox falhou, ou receber uma recompensa indevida se o avaliador deixar passar uma afirmação sem fundamento, como um valor inventado que nenhuma ferramenta retornou.

Usamos o Decider para monitorar rollouts nesses casos. Primeiro, um código identifica partes de um rollout que merecem uma inspeção mais detalhada: uma chamada de ferramenta que falhou e o raciocínio em torno dela, um código que foi executado sem erros ou a resposta final. Em seguida, o Decider responde a perguntas de múltipla escolha sobre cada parte, como o que falhou em uma etapa (um serviço de ferramenta, um site externo, o sandbox, o harness ou o próprio código do agente) e se o agente interpretou o resultado corretamente. Agrupamos todas as perguntas sobre uma determinada parte em uma única solicitação e armazenamos as probabilidades em vez de um veredito, para que possamos ajustar os limiares depois sem consultar o Decider novamente. O monitor apenas observa e diagnostica: ele nunca altera uma recompensa nem interrompe uma execução.

Expandir

Filtragem de qualidade de páginas

Ao rastrear páginas da web para indexá-las e disponibilizá-las aos usuários, muitas páginas têm qualidade baixa demais para serem úteis. Isso inclui barreiras antibot, CAPTCHAs e páginas de erro, além de páginas carregadas corretamente que simplesmente não contêm nenhuma informação útil, como spam, conteúdo de preenchimento para SEO ou páginas apenas de navegação. Essas páginas de baixa qualidade precisam ser identificadas e filtradas do nosso índice.

Com o Decider, podemos avaliar a qualidade das páginas à medida que as rastreamos. Na mesma passagem direta (forward pass), executamos um conjunto de outras tarefas de classificação, como identificar o domínio e o público-alvo do conteúdo e se ele contém informações nocivas, ilegais ou de identificação pessoal. Em comparação com o uso de um LLM como juiz, o Decider é consideravelmente mais rápido e barato.

Expandir

Além desses usos internos, o Decider também se encaixa em fluxos de trabalho como os seguintes.

QA visual

Como o Decider lê imagens, ele também funciona como verificador visual, revisando mudanças de estilo em páginas da web ou apps e identificando falhas. Ele pode revisar capturas de tela de páginas em busca de texto cortado, elementos sobrepostos e layouts quebrados antes que uma mudança seja lançada, ou sinalizar gráficos cujo design possa enganar o leitor ou violar um guia de marca.

Expandir

Navegação no navegador

Agentes podem usar o Decider para as pequenas decisões dentro de tarefas maiores. Um agente de navegador pode enviar uma captura de tela a cada etapa e receber informações detalhadas sobre o estado da página e o resultado esperado de cada ação possível.

Expandir

Planejamento de tarefas de pesquisa

As perguntas dos usuários podem variar muito em complexidade, assim como a profundidade da pesquisa necessária para encontrar uma resposta. O Decider consegue estimar isso antes do início da pesquisa, o que permite gastar menos recursos com perguntas simples.

Expandir

Primeiros passos

O Decider retorna probabilidades. O limiar de decisão adequado depende da aplicação. A frequência dos rótulos e os custos relativos de falsos positivos e falsos negativos variam conforme o caso de uso. Por isso, recomendamos que os usuários ajustem os limiares em um conjunto de desenvolvimento pequeno, representativo e rotulado, em vez de presumir que um ponto de corte fixo funcionará igualmente bem em todas as tarefas.

Recomendamos usar o Decider v1.3 para julgamentos com nuances, rubricas detalhadas e fluxos de trabalho em que erros são custosos. Escolha o Decider Flash v1.3 para roteamento, rotulagem e filtragem de alto volume, em que latência e custo são as principais restrições. Avalie ambos os modelos com exemplos representativos da sua carga de trabalho e, em seguida, escolha o modelo que atende aos seus requisitos de qualidade, latência e orçamento.

Ambos os modelos estão disponíveis como pesos para download no Hugging Face sob a licença Apache, pelo OpenRouter e pela Perplexity Decisions API.

Citação

@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}
}