Perplexity Decider

Apresentamos o Decider v1.3 e o Decider Flash v1.3, os sucessores dos nossos modelos de decisão anteriores: v1, v1.1, v1.2 e Flash v1.2.

O Decider Flash v1.3 é um modelo mais pequeno destilado a partir do Decider v1.3. Ambos os modelos estão disponíveis no Hugging Face, sob licença Apache, através do OpenRouter e da Perplexity Decisions API.

O Perplexity Decider inspira-se no Jev, o System One Model da TypeSafe AI. Suporta classificação binária e multiclasse com rótulos ordenados ou não ordenados, devolvendo probabilidades que as aplicações podem usar para classificar, encaminhar, ordenar e avaliar entradas.

Ambos os modelos v1.3 melhoram o desempenho e a robustez numa vasta gama de tarefas de texto e visão, graças à atenção bidirecional, a dados de treino mais bem selecionados e a uma receita de treino aperfeiçoada. Apresentamos também o locate, uma nova funcionalidade que destaca o conteúdo selecionado em tarefas de reconhecimento de entidades nomeadas, identificação de informações pessoais e resposta extrativa a perguntas.

Nesta publicação, explicamos como treinamos e avaliamos o Decider e partilhamos como o utilizamos internamente na Perplexity.

O que é um modelo de decisão?

Um modelo de decisão é um classificador de uso geral. O modelo recebe uma entrada e um conjunto de perguntas, cada uma com as respetivas respostas possíveis. Para cada pergunta, devolve uma distribuição de probabilidade sobre as respostas. Suporta 3 tipos de pergunta:

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

Os modelos de decisão suportam uma vasta gama de tarefas de classificação e pontuação:

• Avaliação de resultados: aferição da fidelidade, da qualidade e da segurança.
• Encaminhamento: direcionar pedidos para modelos mais pequenos ou maiores consoante a dificuldade.
• Moderação e segurança: deteção de conteúdo nocivo, phishing e injeção de prompts nas saídas de ferramentas.
• Filtragem e etiquetagem: organização de grandes coleções de conteúdo.
• Recuperação e reordenação: pontuação de resultados de pesquisa por relevância.

Muitas destas tarefas eram anteriormente realizadas por modelos generativos, como os LLM, embora não exijam geração de texto livre. Os modelos de decisão situam-se entre os LLM e os classificadores específicos de tarefas. Devolvem probabilidades para várias perguntas sobre a mesma entrada numa única passagem direta, evitando a geração de respostas token a token e partilhando a computação entre perguntas. Ao contrário dos classificadores específicos de tarefas, conseguem lidar com novas tarefas através de prompts em linguagem natural, uma flexibilidade aprendida com o treino em diversas tarefas num formato partilhado de pergunta-resposta.

Treino

Transformar um LLM generativo num modelo de decisão

Construímos o Decider adaptando backbones de LLM generativos robustos. Para explicar a adaptação, descrevemos primeiro como um pedido é representado. Como se ilustra abaixo, um pedido consiste num contexto partilhado (o estado) e num determinado número de perguntas. O estado será reutilizado por todas as perguntas.

Por exemplo, dado um documento e o respetivo resumo, um único pedido pode perguntar se o resumo representa fielmente o documento e se se destina a um especialista ou a um público geral. Depois do estado, cada bloco de pergunta contém uma pergunta e as respetivas respostas possíveis, 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 depois convertidas em probabilidades.

Expandir

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

Para o treino, utilizamos centenas de conjuntos de dados públicos que abrangem tarefas diversas (sentimento, inferência em linguagem natural, deteção de intenção, correspondência de entidades, moderação, verificação de factos, classificações, etc.) e convertemos cada exemplo no formato unificado descrito acima: um estado, uma ou mais perguntas, as respetivas 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 locate descreve o que procurar, usando um rótulo curto como «localização» ou uma instrução como «Extrai o nome da cidade onde se situa o emprego.» O modelo devolve o texto exato correspondente do estado, juntamente com as posições de carácter inicial e final. Se não identificar correspondências, devolve uma lista vazia.

Expandir

Graças ao estado partilhado, um único pedido pode combinar perguntas de locate, classificação e pontuação sobre a mesma entrada. Por exemplo, pode perguntar se um emprego exige experiência de nível sénior e extrair as competências necessárias.

Atenção bidirecional: permitir que o modelo leia em ambos os sentidos

Os nossos modelos partem de backbones generativos pré-treinados robustos, cuja atenção causal permite que cada token atenda apenas a si próprio e aos tokens anteriores. Os nossos estudos de ablação mostraram que tornar bidirecionais as camadas de atenção completa do backbone melhora o desempenho, pelo que adotamos este design para permitir que cada token incorpore contexto de toda a entrada.

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

• Tudo vê tudo (v1.2): O estado e todas as perguntas são processados em conjunto com atenção bidirecional completa. O cálculo sobre o estado é partilhado, mas a resposta a uma pergunta pode mudar consoante as restantes perguntas feitas.
• Perguntas isoladas (v1.3): O estado atende a todas as perguntas, enquanto cada pergunta atende apenas ao estado e aos seus próprios tokens. As perguntas podem continuar a influenciar-se indiretamente através do estado partilhado, mas os resultados são mais estáveis.
• Totalmente armazenável em cache: o estado apenas presta atenção a si próprio, enquanto cada pergunta presta atenção ao estado e aos seus próprios tokens. O estado é independente das perguntas e reutilizável entre pedidos, permitindo tirar partido da cache de prompts. Não o utilizamos por predefinição, porque permitir que o estado veja as perguntas é muito importante para várias tarefas, mas um pequeno ajuste fino pode fazer um modelo passar a utilizá-lo.

Acabámos por escolher as perguntas isoladas pelo seu forte desempenho e estabilidade.

Expandir

Receita de treino

O treino decorre em três fases para ambos os tamanhos de modelo. Primeiro, treinamos o modelo maior, baseado no Qwen3.8-27B, utilizando entropia cruzada em grandes conjuntos de dados, e depois destilamo-lo no modelo mais pequeno Qwen3.5-4B.

A primeira fase é o treino generalista, em que fazemos o ajuste fino completo do modelo em corpora de grande escala. Nesta fase, só aceitamos dados que ajudem o modelo de forma transversal e que não sejam específicos de nenhum benchmark; por isso, excluímos quaisquer partições de treino de benchmarks.

Depois de treinado este modelo generalista, executamos uma segunda fase, mais detalhada, utilizando LoRA. Os dados utilizados nesta fase destinam-se a domínios e tarefas específicos. Adicionamos dados na segunda fase em vez da primeira se observarmos ganhos limitados ou algumas regressões noutras tarefas. Utilizamos LoRA para evitar desviar-nos demasiado do modelo generalista e arriscar perder desempenho para nos ajustarmos a esses domínios específicos. O objetivo é melhorar o desempenho, mantendo o conhecimento geral do backbone. Também utilizamos um peso ao fundir o LoRA de volta no modelo base, para controlar o desvio com mais precisão e privilegiar as métricas em dados reservados em detrimento de quaisquer ganhos no domínio.

Por fim, acrescentamos um passo específico de visão. À semelhança da segunda fase, o passo de visão é tratado como mais um passo de especialização detalhada, usando um adaptador LoRA que é novamente incorporado no modelo base com um peso. Algumas capacidades de visão podem ter um custo no desempenho em texto. Como observamos uma utilização muito maior dos modelos em texto, damos prioridade às métricas de texto em detrimento das métricas de visão.

Em ambas as fases de texto, utilizamos a média dos pesos de três execuções, cada uma com uma semente aleatória diferente. Verificámos que isto melhora o desempenho e a robustez do modelo agregado.

Depois de obtido o modelo grande final, aplicamos o mesmo procedimento de treino em três fases ao modelo mais pequeno. Aqui, o modelo grande atua como professor: a distribuição de saída que prevê substitui as etiquetas de referência, e o modelo mais pequeno é treinado para minimizar a divergência KL entre as suas previsões e as do professor. Este objetivo de destilação supera a entropia cruzada com os mesmos dados de treino. Embora a entropia cruzada tenha melhor desempenho em benchmarks com dados de treino dedicados, generaliza pior para dados reservados. A nossa hipótese é que a destilação transfere melhor a distribuição de saída do professor, incluindo a sua confiança em alternativas que não são a de referência, ao passo que a entropia cruzada favorece o sobreajuste à distribuição de treino 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 treino que possam sobrepor-se a qualquer avaliação que utilizamos. Isto é importante porque alguns conjuntos de dados de treino públicos contêm grandes partes de alguns conjuntos de dados de avaliação. Realizamos também auditorias extensivas de enviesamentos e a respetiva remoção, para garantir que os nossos ganhos são fiáveis e não resultam apenas de enviesamentos aprendidos.

Adicionar a capacidade de extrair informação

A funcionalidade locate extrai informações, como entidades nomeadas, de um texto, sem alterar a forma como responde a pedidos comuns. Para isso, introduzimos uma fase de treino adicional: acrescentamos ao Decider um novo token especial, <|locate|>, uma cabeça de span e um adaptador LoRA.

Inicializamos o embedding de <|locate|> a partir de <|marker|>, aprendido nas fases de treino anteriores. Treinamos apenas este 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 pedido recebe o seu próprio token <|locate|>.

A cabeça de segmentos utiliza a representação de <|locate|> juntamente com as representações dos tokens de estado para pontuar onde começam e terminam os segmentos correspondentes e que pares início-fim pertencem um ao outro. Utiliza também a representação do token <|locate|> para prever limiares específicos de cada campo para estas pontuações. Os segmentos selecionados são devolvidos como posições de caracteres no texto original.

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

Treinamos com uma combinação de tarefas de extração de spans, incluindo reconhecimento de entidades nomeadas, deteçã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 o pedido 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 aquilo que o modelo já faz bem. Fundir os adaptadores de locate no backbone causa alguma regressão nos pedidos de decisão. Para o limitar, estamos a realizar investigações, como mais dados de replay de fases anteriores e objetivos auxiliares que mantêm as saídas do modelo em pedidos de decisão próximas das do modelo original. No entanto, verificamos que a fusão ainda não é isenta de perdas, pelo que mantemos os adaptadores por fundir e ativamo-los apenas para pedidos 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.

Nestas avaliações, os nossos modelos demonstram um forte desempenho. Embora estas tabelas de classificação incluam tarefas privadas, podem ainda assim ser manipuladas através de submissões repetidas e de ajustes iterativos com base no feedback das tabelas de classificação. Para complementar estas tabelas de classificação, avaliamos os modelos num conjunto interno que combina tarefas de produção privadas com avaliações reservadas, extraídas de conjuntos de dados públicos que não são benchmarks. Estas avaliações proporcionam uma verificação adicional da generalização para além dos benchmarks públicos, ajudando-nos a distinguir melhorias mais amplas de ganhos específicos de conjuntos de avaliação conhecidos.

Internamente, criámos um conjunto de mais de 200 tarefas que abrangem vários domínios e tipos de tarefa, como classificação, pontuação, reordenação e extração de entidades. Para avaliar com rigor o desempenho do Decider em condições reais, todas as avaliações são realizadas em modo zero-shot, sem ajuste fino específico para cada tarefa, o que nos dá uma indicação clara de onde melhorar o modelo.

Classificação de consultas

Na Perplexity, utilizamos um sistema de classificação multi-cabeça para processar cada consulta dos utilizadores. Cada consulta passa primeiro por um modelo de embedding que funciona como extrator de características. O embedding resultante é depois enviado para várias cabeças de classificação separadas, incluindo classificadores binários e multirrótulo. Por exemplo, uma das cabeças determina se uma consulta do utilizador deve acionar uma pesquisa na web.

Em 63 tarefas de classificação com referências novamente rotuladas de forma independente por um LLM de fronteira, o Decider v1.3 alcança uma exatidão média de 91,6%, superando os nossos classificadores de produção em 6,54 pontos percentuais. O Decider Flash v1.3 também supera a referência de produção, enquanto o Decider v1.3 supera o Jev 1.14.

Expandir

Classificação específica de domínio

Reunimos um conjunto de avaliação específico de 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 afirmações (6 tarefas), saúde (7), cibersegurança (8), programação (16), administração pública (7), direito (9) e finanças (9).

Por exemplo, «avaliar a complexidade temporal de um programa em Python» ou «usar um relatório financeiro anual para determinar se o dinheiro disponível sem restrições de uma empresa cobre o capital da dívida que vence nos próximos doze meses». O Decider v1.3 lidera nos 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 um desempenho semelhante nos restantes domínios.

Expandir

Recuperação e reordenação

A pesquisa está no centro da Perplexity. Mantemos um vasto conjunto de tarefas de recuperação para avaliar o desempenho de reordenação dos nossos modelos. Para cada tarefa, utilizamos primeiro um conjunto de modelos de embedding para recuperar os 50 principais documentos candidatos de cada corpus. Depois, reordenamos estes candidatos com o Decider e comparamos o seu desempenho com uma referência de reordenação robusta, o Qwen3-Reranker-8B.

Avaliamos o Decider num 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 alcança um nDCG@10 médio de 83,99, superando o Qwen3-Reranker-8B em 1,81 pontos e o Jev 1.14 em 2,24 pontos.

No benchmark BEIR, ambos os modelos superam o Qwen3-Reranker-8B em 8,78 e 7,05 pontos de nDCG@10, respetivamente. Face ao Jev 1.14, o Decider v1.3 obtém mais 1,33 pontos, enquanto a versão Flash obtém menos 0,4.

Expandir

Classificação multilingue

Para avaliar os modelos de decisão para além do inglês, reunimos um benchmark de classificação multilingue com 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 deteção de intenção, classificação de tópicos, análise de sentimento, inferência em linguagem natural, deteção de paráfrases, deteção de linguagem ofensiva e aceitabilidade gramatical.

Apresentamos a exatidão média das tarefas em cada idioma, atribuindo o mesmo peso a cada tarefa. O Decider v1.3 supera o Jev 1.14 nos oito idiomas e o Decider Flash v1.3 fá-lo em seis, com exatidões médias por tarefa de 88,16% para o Decider v1.3 e 86,50% para o Decider Flash v1.3, face a 85,41% para o Jev 1.14.

Expandir

NER, PII e QA extrativo

Avaliamos a funcionalidade locate em 17 tarefas fora do domínio que testam a sua capacidade de extração em vários 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 Wikipedia a artigos científicos, relatórios de ciberameaças, suporte técnico, políticas de privacidade, currículos e contratos jurídicos. Os pedidos vão de nomes de rótulos curtos, como «pessoa» ou «endereço de email», passando por perguntas sobre uma tabela ou um pedido de suporte, até descrições detalhadas de campos para extração estruturada, como as partes de um NDA ou o total de uma fatura.

Avaliamos NER e PII utilizando o F1 de segmento exato, que exige que os segmentos previstos correspondam exatamente aos limites de referência. O QA extrativo utiliza o F1 ao nível dos caracteres, atribuindo crédito parcial a texto de resposta sobreposto, enquanto a extração estruturada utiliza a exatidão por campo, ou seja, a proporção de campos extraídos corretamente. Para a análise de CV, calculamos a média das pontuações F1 de segmento exato de NER e PII.

Comparamos os nossos modelos com modelos de extração de uso geral de diferentes dimensões: GLiNER large v2.5 (0,5B), Liquid d1 (2B) e Clairic da Cloudflare (dimensão não divulgada). O Decider v1.3 atinge uma pontuação média de 69,0 (usando a métrica principal de cada tarefa) e o Decider Flash v1.3 atinge 63,6, face a 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 suporta nativamente tarefas de visão desde a v1. Para avaliar o seu desempenho para além do texto, reunimos um conjunto de benchmarks com cinco tarefas, com especial foco na classificação de documentos, incluindo faturas, cartas e currículos. O conjunto abrange também a classificação de imagens de satélite, a classificação de texturas, a classificação de raças de animais de estimação e a contagem de animais.

O Decider v1.3 alcança uma exatidão média de 76,99% nas cinco tarefas visuais, superando o Jev 1.14 em 1,47 pontos percentuais. O Decider Flash v1.3 alcança 72,77%, demonstrando capacidades de classificação visual num modelo mais pequeno.

Expandir

Pedidos de decisão reais

Recolhemos uma amostra de um milhão de pedidos desduplicados e com PII mascaradas, enviados à Perplexity Decision API durante os seus primeiros 18 dias de disponibilidade. Como cada pedido pode conter várias perguntas sobre o mesmo estado, a amostra abrange 2 318 887 perguntas individuais. Todos os pedidos foram incluídos com autorização explícita dos utilizadores para fins de investigação.

Os pedidos em produção não incluem rótulos de referência, pelo que utilizamos LLM de fronteira como juízes para gerar respostas de referência e medir a concordância de cada modelo com elas. Agrupamos também os pedidos em 10 categorias de tarefas, incluindo extração de informação, classificação de domínio, análise de sentimento, intenção e encaminhamento, ordenação por relevância, moderação de conteúdos, revisão de qualidade e conformidade, correspondência de entidades, análise de negócio e uma categoria «Outros». Esta divisão mostra como o desempenho varia entre casos de utilização reais.

A distribuição das tarefas é desigual: a extração de informação representa 425 402 perguntas, a classificação de domínio 409 564 e a análise de sentimento 344 158. Em conjunto, estas três categorias representam 50,8% das perguntas da amostra.

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

Expandir

O gráfico abaixo compara o custo reportado da execução do mesmo milhão de pedidos de produção. Cada pedido pode conter várias perguntas, pelo que a unidade aqui são pedidos, e não perguntas individuais.

Expandir

Robustez

Avaliámos a sensibilidade aos rótulos em 372 perguntas de escolha múltipla, com 4788 pedidos por modelo. Reordenámos opções, reatribuímos rótulos aos textos das respostas e mudámos o nome dos rótulos, preservando o significado de cada pergunta, e verificámos depois se a resposta semântica do modelo se alterava. Taxas de inversão mais baixas indicam maior estabilidade.

O Decider v1.3 alterou a resposta em apenas 0,27% das perguntas em cada transformação, face a 2,69–4,84% no Jev 1.14. Também repetimos entradas idênticas para medir a variabilidade do serviço: o Decider v1.3 não apresentou alterações, enquanto o Jev 1.14 mudou em 1,88% das perguntas.

Expandir

Como utilizamos o Decider

O Decider foi criado para fluxos de trabalho que precisam de decisões rápidas e estruturadas. Nesta secção, exploramos como tirar partido destes modelos para gerar um impacto significativo na forma como trabalhamos. Eis alguns casos que se destacaram.

Regras de segurança que se aperfeiçoam automaticamente

Internamente, já utilizamos o Decider para melhorar as nossas políticas de segurança.

A atividade dos nossos agentes é registada e é realizada uma série de verificações baseadas em regras para identificar qualquer comportamento problemático. Uma abordagem baseada em regras permite-nos monitorizar os nossos agentes em tempo real com uma latência adicional insignificante. Offline, utilizamos o Decider para analisar amostras destes registos de agentes. Quando nenhum comportamento problemático foi sinalizado, o Decider verifica se houve algo que o nosso conjunto de regras não detetou; quando foi emitido um alerta, o Decider verifica se se tratou de um falso alarme. Todos os registos em que o nosso conjunto de regras falha, em qualquer um dos casos, são enviados a um agente para triagem, que propõe uma correção às regras, a aprovar por um membro da nossa equipa de segurança.

Num único dia, o Decider leu mil milhões de tokens em 7000 sessões de agentes e identificou falhas que levaram a 14 correções de regras, 6 das quais foram aprovadas e implementadas no prazo de dois dias. Reproduzidas sobre uma semana de registos, as correções reduziram em 52% o volume da nossa regra mais ativa, e as regras alargadas detetaram cerca de mais 40% de ações legítimas a investigar.

Expandir

Monitorização de rollouts de RL

Quando fazemos o pós-treino de modelos com aprendizagem por reforço, métricas agregadas como uma recompensa terminal não explicam por que razão um rollout (uma tentativa individual de realizar uma tarefa) teve êxito ou falhou. Um rollout pode perder recompensa injustamente porque um serviço de ferramentas ou a sandbox falhou, ou receber uma recompensa imerecida se o avaliador não detetar uma afirmação sem fundamento, como um valor inventado que nenhuma ferramenta devolveu.

Utilizamos o Decider para monitorizar rollouts nestes casos. Primeiro, o código identifica as partes de um rollout que justificam uma inspeção mais atenta: uma chamada de ferramenta falhada e o raciocínio envolvente, código que foi executado sem erros ou a resposta final. Em seguida, o Decider responde a perguntas de escolha múltipla sobre cada parte, como o que falhou num passo (um serviço de ferramentas, um site externo, a sandbox, o harness ou o próprio código do agente) e se o agente interpretou corretamente o resultado. Agrupamos todas as perguntas sobre uma determinada parte num único pedido e guardamos as probabilidades em vez de um veredicto, para podermos ajustar os limiares mais tarde sem voltar a consultar o Decider. O monitor apenas observa e diagnostica: nunca altera uma recompensa nem interrompe uma execução.

Expandir

Filtragem da qualidade de páginas

Ao rastrear páginas web para as indexar e disponibilizar aos utilizadores, muitas páginas têm uma qualidade demasiado baixa para terem qualquer utilidade. Isto inclui barreiras anti-bot, CAPTCHAs e páginas de erro, bem como páginas web carregadas corretamente que simplesmente não contêm informação útil, como spam, conteúdo de enchimento para SEO ou páginas apenas de navegação. Estas páginas de baixa qualidade têm de 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), realizamos um conjunto de outras tarefas de classificação, como identificar o domínio e o público-alvo do conteúdo e se este contém informação nociva, ilegal ou de identificação pessoal. Em comparação com a utilização de um LLM como avaliador, o Decider é consideravelmente mais rápido e mais barato.

Expandir

Para além destas utilizações internas, o Decider também se adequa a fluxos de trabalho como os seguintes.

QA visual

Como o Decider lê imagens, também funciona como verificador visual, revendo alterações de estilo em páginas web ou aplicações e identificando defeitos. Pode rever capturas de ecrã de páginas em busca de texto cortado, elementos sobrepostos ou layouts danificados antes de uma alteração ser publicada, ou sinalizar gráficos cujo design possa induzir o leitor em erro ou violar um guia de marca.

Expandir

Navegação no browser

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

Expandir

Planeamento de tarefas de pesquisa

As perguntas dos utilizadores podem variar muito em complexidade, tal como a profundidade da pesquisa necessária para encontrar uma resposta. O Decider consegue estimar isto antes de a pesquisa começar, permitindo gastar menos recursos em perguntas simples.

Expandir

Primeiros passos

O Decider devolve probabilidades. O limiar de decisão adequado depende da aplicação. As frequências dos rótulos e os custos relativos de falsos positivos e falsos negativos variam consoante o caso de utilização. Por isso, recomendamos que os utilizadores ajustem os limiares num pequeno conjunto de desenvolvimento rotulado e representativo, em vez de partirem do princípio de que um limite fixo funcionará igualmente bem em todas as tarefas.

Recomendamos o Decider v1.3 para avaliações com nuances, rubricas detalhadas e fluxos de trabalho em que os erros são dispendiosos. Escolha o Decider Flash v1.3 para encaminhamento, etiquetagem e filtragem de grande volume, em que a latência e o 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 cumpre os seus requisitos de qualidade, latência e orçamento.

Ambos os modelos estão disponíveis como pesos descarregáveis no Hugging Face, sob licença Apache, através do OpenRouter e da 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}
}