Perplexity Decider

Presentamos Decider v1.3 e Decider Flash v1.3, os sucesores dos nosos modelos de decisión anteriores: v1, v1.1, v1.2 e Flash v1.2.

Decider Flash v1.3 é un modelo máis pequeno destilado de Decider v1.3. Ambos os modelos están dispoñibles en Hugging Face baixo licenza Apache, a través de OpenRouter e na Perplexity Decisions API.

Perplexity Decider inspírase en Jev, o System One Model de TypeSafe AI. Admite clasificación binaria e multiclase con etiquetas ordenadas ou non ordenadas, e devolve probabilidades que as aplicacións poden usar para clasificar, enrutar, ordenar e avaliar entradas.

Ambos os modelos v1.3 melloran o rendemento e a robustez nunha ampla gama de tarefas de texto e visión grazas á atención bidireccional, a uns datos de adestramento mellor seleccionados e a unha receita de adestramento mellorada. Tamén presentamos locate, unha nova funcionalidade para resaltar o contido seleccionado en tarefas de recoñecemento de entidades nomeadas, identificación de información persoal e resposta extractiva a preguntas.

Nesta publicación, explicamos como adestramos e avaliamos Decider e contamos como o usamos internamente en Perplexity.

Que é un modelo de decisión?

Un modelo de decisión é un clasificador de propósito xeral. Proporciónaslle unha entrada e un conxunto de preguntas, cada unha coas súas posibles respostas. Para cada pregunta, devolve unha distribución de probabilidade sobre as respostas. Admite 3 tipos de preguntas:

• Si / Non: decisións binarias.
• Opción múltiple: etiquetas multiclase personalizadas.
• Puntuación: niveis ordenados.

Os modelos de decisión admiten unha ampla variedade de tarefas de clasificación e puntuación:

• Avaliación de saídas: valorar a fidelidade, a calidade e a seguridade.
• Enrutamento: dirixir as solicitudes a modelos máis pequenos ou máis grandes segundo a súa dificultade.
• Moderación e seguridade: detectar contido nocivo, phishing e inxección de prompts nas saídas das ferramentas.
• Filtraxe e etiquetaxe: organización de grandes coleccións de contido.
• Recuperación e reordenación: puntuar os resultados de busca segundo a súa relevancia.

Moitas destas tarefas xestionábanas antes modelos xerativos como os LLM, aínda que non requiren xeración de texto libre. Os modelos de decisión sitúanse entre os LLM e os clasificadores específicos de tarefas. Devolven probabilidades para varias preguntas sobre a mesma entrada nun único paso cara adiante, o que evita xerar a resposta token a token e permite compartir o cálculo entre preguntas. A diferenza dos clasificadores específicos de tarefas, poden abordar tarefas novas mediante prompts en linguaxe natural, unha flexibilidade aprendida ao adestrarse con tarefas diversas nun formato común de preguntas e respostas.

Adestramento

Como converter un LLM xerativo nun modelo de decisión

Construímos Decider adaptando potentes LLM xerativos como modelo troncal. Para explicar a adaptación, primeiro describimos como se representa unha solicitude. Como se ilustra a continuación, unha solicitude consta dun contexto compartido (o estado) e dunha serie de preguntas. O estado reutilizarano todas as preguntas.

Por exemplo, dado un documento e o seu resumo, unha única solicitude pode preguntar se o resumo representa fielmente o documento e se está destinado a un público experto ou xeral. Despois do estado, cada bloque de pregunta contén unha pregunta e as súas posibles respostas, cada unha asignada a un token de etiqueta predefinido como A, B ou C. Un token especial <|marker|> indica onde ler a predición do modelo. Nesta posición, unha capa de saída lineal aprendida (unha cabeza de decisión) transforma o estado oculto en puntuacións para as opcións de resposta da pregunta, que despois se converten en probabilidades.

Ampliar

Inicializamos a capa de saída a partir do modelo base, que normalmente puntúa o seguinte token sobre todo o vocabulario, e só conservamos as filas correspondentes aos tokens de opción predefinidos, como A, B ou C. Despois adestramos esta capa podada para transformar o estado oculto de <|marker|> en puntuacións de resposta. Este enfoque abrangue todas as preguntas de clasificación, porque todas se poden formular como unha pregunta de opción múltiple.

Para o adestramento, tomamos centos de conxuntos de datos públicos que abranguen tarefas diversas (sentimento, inferencia en linguaxe natural, detección de intencións, correspondencia de entidades, moderación, verificación de feitos, valoracións, etc.) e convertemos cada exemplo ao formato unificado descrito anteriormente: un estado, unha ou máis preguntas, as súas opcións e un obxectivo. O obxectivo pode ser a única opción correcta, se dispoñemos de etiquetas de referencia, ou unha distribución de probabilidade sobre as opcións.

Na v1.3, presentamos locate, que extrae texto do estado en lugar de seleccionar entre opcións predefinidas. Unha pregunta de locate describe que hai que atopar, mediante unha etiqueta curta como “localización” ou unha instrución como “Extrae o nome da cidade onde se sitúa o emprego.” O modelo devolve o texto exacto coincidente do estado, xunto coas súas posicións de carácter inicial e final. Se non identifica ningunha coincidencia, devolve unha lista baleira.

Ampliar

Grazas ao estado compartido, unha única solicitude pode combinar preguntas de locate, clasificación e puntuación sobre a mesma entrada. Por exemplo, pode preguntar se un emprego require experiencia de nivel sénior e extraer as competencias requiridas.

Atención bidireccional: permitir que o modelo lea en ambas as direccións

Os nosos modelos parten de sólidas arquitecturas base xerativas preadestradas, cuxa atención causal permite que cada token atenda só a si mesmo e aos tokens anteriores. Os nosos estudos de ablación demostraron que facer bidireccionais as capas de atención completa da arquitectura base mellora o rendemento, polo que adoptamos este deseño para que cada token poida incorporar contexto de toda a entrada.

A atención bidireccional introduce outra decisión de deseño: como deben interactuar o estado e as preguntas? Consideramos tres patróns de atención, con distintas implicacións para o rendemento, a estabilidade das respostas e a reutilización da caché:

• Todo ve todo (v1.2): O estado e todas as preguntas procésanse xuntos con atención bidireccional completa. O cálculo sobre o estado compártese, pero a resposta a unha pregunta pode cambiar segundo o que máis se pregunte.
• Preguntas illadas (v1.3): O estado atende a todas as preguntas, mentres que cada pregunta atende só ao estado e aos seus propios tokens. As preguntas aínda poden influírse mutuamente de forma indirecta a través do estado compartido, pero os resultados son máis estables.
• Totalmente almacenable en caché: o estado só atende a si mesmo, mentres que cada pregunta atende ao estado e aos seus propios tokens. O estado é independente das preguntas e reutilizable entre solicitudes para aproveitar o almacenamento en caché de prompts. Non o usamos por defecto, porque permitir que o estado vexa as preguntas importa moito en varias tarefas, pero un pequeno axuste fino pode facer que un modelo pase a usalo.

Finalmente, escollemos as preguntas illadas polo seu bo rendemento e a súa estabilidade.

Ampliar

Receita de adestramento

O adestramento desenvólvese en tres etapas para ambos os tamaños de modelo. Primeiro adestramos o modelo máis grande, baseado en Qwen3.8-27B, usando entropía cruzada sobre grandes conxuntos de datos, e despois destilámolo no modelo máis pequeno, Qwen3.5-4B.

A primeira etapa é o adestramento xeneralista, no que axustamos completamente o modelo con corpus a grande escala. Nesta etapa, só aceptamos datos que axuden ao modelo de forma xeral e que non sexan específicos de ningún banco de probas; por iso, excluímos calquera partición de adestramento dos bancos de probas.

Unha vez adestrado este modelo xeneralista, executamos unha segunda etapa, máis detallada, usando LoRA. Os datos empregados nesta etapa están orientados a dominios e tarefas específicos. Engadimos datos na segunda etapa en lugar de na primeira se observamos melloras limitadas ou algunhas regresións noutras tarefas. Usamos LoRA para evitar afastarnos demasiado do modelo xeneralista e arriscarnos a perder rendemento por axustarnos a eses dominios específicos. O obxectivo é mellorar o rendemento conservando o coñecemento xeral do modelo troncal. Tamén aplicamos un peso ao fusionar o LoRA de novo no modelo base, para controlar a deriva con máis precisión e priorizar as métricas sobre datos reservados por riba de calquera mellora dentro do dominio.

Por último, engadimos un paso específico de visión. Do mesmo xeito que na segunda etapa, o paso de visión trátase como outro paso de especialización detallada, cun adaptador LoRA que se fusiona de novo co modelo base cun peso. Algunhas capacidades de visión poden obterse a costa do rendemento en texto. Como observamos un uso moito maior dos modelos en texto, priorizamos as métricas de texto sobre as de visión.

Para ambas as etapas de texto, empregamos a media dos pesos de tres execucións, cada unha cunha semente aleatoria diferente. Comprobamos que isto mellora o rendemento e a robustez do modelo agregado.

Unha vez obtido o modelo grande final, aplicamos o mesmo procedemento de adestramento en tres etapas ao modelo máis pequeno. Aquí, o modelo grande actúa como mestre: a súa distribución de saída predita substitúe as etiquetas de referencia, e o modelo máis pequeno adéstrase para minimizar a diverxencia KL entre as súas predicións e as do mestre. Este obxectivo de destilación supera a entropía cruzada cos mesmos datos de adestramento. Aínda que a entropía cruzada ten mellor rendemento nas probas de referencia con datos de adestramento específicos, xeneraliza peor a datos reservados. A nosa hipótese é que a destilación transfire mellor a distribución de saída do mestre, incluída a súa confianza nas alternativas distintas da de referencia, mentres que a entropía cruzada fomenta o sobreaxuste á distribución de adestramento específica de cada proba de referencia. Por iso, adoptamos o obxectivo de destilación baseado en KL.

Para mitigar a contaminación entre os datos de adestramento e os de proba, eliminamos calquera mostra de adestramento que poida solaparse con calquera das avaliacións que usamos. Isto é importante porque algúns conxuntos de datos públicos de adestramento conteñen grandes partes dalgúns conxuntos de datos de avaliación. Tamén realizamos auditorías exhaustivas de nesgos e eliminámolos para garantir que as nosas melloras sexan fiables e non se deban simplemente a nesgos aprendidos.

Engadir a capacidade de extraer información

A funcionalidade locate extrae información, como entidades nomeadas, a partir do texto, sen cambiar a forma en que responde ás solicitudes habituais. Para iso, introducimos unha etapa de adestramento adicional: engadimos un novo token especial, <|locate|>, unha cabeza de span e un adaptador LoRA a Decider.

Inicializamos o embedding de <|locate|> a partir do de <|marker|> aprendido nas etapas de adestramento anteriores. Adestramos só este novo embedding, a cabeza de span e os adaptadores LoRA, mantendo conxelados os pesos orixinais da arquitectura base e a cabeza de decisión. Cada campo solicitado ten o seu propio token <|locate|>.

A cabeza de segmentos usa a representación de <|locate|> xunto coas representacións dos tokens de estado para puntuar onde comezan e rematan os segmentos coincidentes, e que pares de inicio e fin van xuntos. Tamén usa a representación do token <|locate|> para predicir limiares específicos de cada campo para estas puntuacións. Os segmentos seleccionados devólvense como posicións de caracteres no texto orixinal.

Adestramos a cabeza de segmentos cunha función de perda InfoNCE adaptada que sitúa cada segmento de referencia por riba do limiar, e o limiar por riba de calquera outro segmento. A perda ten dous termos: o primeiro sitúa as puntuacións dos segmentos correctos por riba do limiar e dos segmentos incorrectos. O segundo termo sitúa o limiar por riba das puntuacións dos segmentos incorrectos. Os campos sen resposta só reciben o segundo termo, o que lle ensina ao modelo a devolver unha lista baleira.

Adestramos cunha combinación de tarefas de extracción de fragmentos, que inclúen recoñecemento de entidades nomeadas, detección de PII e resposta extractiva a preguntas. Variamos as descricións dos campos desde etiquetas curtas ata instrucións detalladas, para que o modelo aprenda a seguir a solicitude en lugar de memorizar un conxunto fixo de etiquetas.

Locate ensínalle ao modelo unha tarefa estruturalmente distinta, e queremos engadila sen perder o que o modelo xa fai ben. Fusionar os adaptadores de locate no modelo troncal provoca certa regresión nas solicitudes de decisión. Para limitalo, estamos a realizar investigacións como usar máis datos de repetición das etapas anteriores e obxectivos auxiliares que manteñan as saídas do modelo nas solicitudes de decisión próximas ás do modelo orixinal. Con todo, comprobamos que a fusión aínda produce perdas, polo que mantemos os adaptadores sen fusionar e activámolos só para as solicitudes de locate.

Avaliación

Avaliamos Decider v1.3 e Decider Flash v1.3 con probas de referencia externas do Hugging Face Decision Index, o ClaimBench de Vals AI e o Artificial Analysis Decision Index.

En todas estas avaliacións, os nosos modelos demostran un bo rendemento. Aínda que estas clasificacións inclúen tarefas privadas, poden manipularse igualmente mediante envíos repetidos e axustes iterativos baseados nos resultados da clasificación. Para complementar estas clasificacións, avaliamos os modelos nun conxunto interno que combina tarefas privadas de produción con avaliacións reservadas extraídas de conxuntos de datos públicos que non son probas de referencia. Estas avaliacións proporcionan unha comprobación adicional da xeneralización máis alá das probas de referencia públicas, o que nos axuda a distinguir as melloras máis amplas das ganancias específicas de conxuntos de avaliación coñecidos.

Internamente, construímos un conxunto de máis de 200 tarefas que abranguen diversos dominios e tarefas como a clasificación, a puntuación, a reordenación e a extracción de entidades. Para avaliar honestamente o rendemento de Decider no mundo real, todas as avaliacións realízanse en modo zero-shot, sen axuste fino específico para cada tarefa, o que nos dá unha indicación clara de onde mellorar o modelo.

Clasificación de consultas

En Perplexity, empregamos un sistema de clasificación multicabeza para procesar cada consulta dos usuarios. Cada consulta pasa primeiro por un modelo de embeddings que actúa como extractor de características. O embedding resultante introdúcese despois en varias cabezas de clasificación independentes, que inclúen tanto clasificadores binarios como multietiqueta. Por exemplo, unha cabeza determina se unha consulta do usuario debe activar unha busca na web.

En 63 tarefas de clasificación con referencias reetiquetadas de forma independente por un LLM de vangarda, Decider v1.3 acada unha precisión media do 91,6 % e supera os nosos clasificadores de produción en 6,54 puntos porcentuais. Decider Flash v1.3 tamén supera a referencia de produción, mentres que Decider v1.3 supera a Jev 1.14.

Ampliar

Clasificación específica de dominio

Compilamos un conxunto de avaliación específico de dominio a partir de conxuntos de datos públicos para avaliar o rendemento de clasificación dos modelos de decisión en sete dominios: verificación de afirmacións (6 tarefas), sanidade (7), ciberseguridade (8), programación (16), administración pública (7), dereito (9) e finanzas (9).

Por exemplo, “xulgar a complexidade temporal dun programa en Python” ou “usar un informe financeiro anual para determinar se o efectivo sen restricións dunha empresa cobre o principal da débeda que vence nos próximos doce meses”. Decider v1.3 lidera nos sete dominios e supera a Jev 1.14 en ata 12,9 puntos porcentuais en finanzas e 9,3 puntos en dereito. Decider Flash v1.3 queda por detrás de Jev 1.14 en finanzas, programación e dereito, e ten un rendemento semellante nos demais dominios.

Ampliar

Recuperación e reordenación

A busca é o núcleo de Perplexity. Mantemos un amplo conxunto de tarefas de recuperación para avaliar o rendemento de reordenación dos nosos modelos. Para cada tarefa, primeiro usamos un conxunto de modelos de embeddings para recuperar os 50 documentos candidatos principais de cada corpus. Despois reordenamos estes candidatos con Decider e comparamos o seu rendemento co dunha sólida referencia de reordenación, Qwen3-Reranker-8B.

Avaliamos Decider nunha configuración zero-shot e por puntos (pointwise), usando o modelo para puntuar directamente e de forma independente cada par consulta–documento e ordenar os documentos por relevancia. En 72 tarefas de recuperación, Decider v1.3 acada un nDCG@10 medio de 83,99 e supera a Qwen3-Reranker-8B en 1,81 puntos e a Jev 1.14 en 2,24 puntos.

No banco de probas BEIR, ambos os modelos superan a Qwen3-Reranker-8B en 8,78 e 7,05 puntos de nDCG@10, respectivamente. Fronte a Jev 1.14, Decider v1.3 obtén 1,33 puntos máis, mentres que a versión Flash obtén 0,4 menos.

Ampliar

Clasificación multilingüe

Para avaliar os modelos de decisión máis alá do inglés, compilamos un banco de probas de clasificación multilingüe composto por 19 tarefas específicas de cada idioma procedentes de 8 conxuntos de datos públicos, con 46 484 exemplos en oito idiomas: alemán, español, francés, italiano, ruso, xaponés, coreano e chinés. O banco de probas abrangue detección de intencións, clasificación temática, análise de sentimento, inferencia en linguaxe natural, detección de paráfrases, detección de linguaxe ofensiva e aceptabilidade gramatical.

Indicamos a precisión media entre as tarefas de cada idioma, ponderando cada tarefa por igual. Decider v1.3 supera a Jev 1.14 nos oito idiomas e Decider Flash v1.3 faino en seis, cunhas precisións medias por tarefa do 88,16 % para Decider v1.3 e do 86,50 % para Decider Flash v1.3, fronte ao 85,41 % de Jev 1.14.

Ampliar

NER, PII e preguntas e respostas extractivas

Avaliamos a funcionalidade locate en 17 tarefas fóra de dominio que poñen a proba a súa capacidade de extracción en diversos dominios, formatos de entrada (texto, táboas, documentos estruturados) e instrucións (etiquetas curtas, preguntas e descricións detalladas). Os dominios van desde a Wikipedia ata artigos científicos, informes de ciberameazas, asistencia técnica, políticas de privacidade, currículos e contratos legais. As solicitudes van desde nomes de etiqueta curtos como “persoa” ou “enderezo de correo electrónico”, pasando por preguntas sobre unha táboa ou unha incidencia de asistencia, ata descricións detalladas de campos para a extracción estruturada, como as partes dun acordo de confidencialidade ou o total dunha factura.

Avaliamos NER e PII mediante o F1 de segmento exacto, que require que os segmentos preditos coincidan exactamente cos límites de referencia. A QA extractiva usa F1 a nivel de carácter, que outorga crédito parcial ao texto de resposta superposto, mentres que a extracción estruturada usa a precisión por campo, é dicir, a proporción de campos extraídos correctamente. Para a análise de CV, facemos a media das puntuacións F1 de segmento exacto de NER e PII.

Comparamos os nosos modelos con modelos de extracción de propósito xeral de distintos tamaños: GLiNER large v2.5 (0,5B), Liquid d1 (2B) e Clairic de Cloudflare (tamaño non divulgado). Decider v1.3 alcanza unha puntuación media de 69,0 (usando a métrica principal de cada tarefa) e Decider Flash v1.3 alcanza 63,6, fronte a 43,3 de Liquid d1, 41,5 de Clairic e 33,6 de GLiNER large v2.5. Ambos os modelos Decider lideran en todas as categorías.

Ampliar

Clasificación de imaxes

Decider admite de forma nativa tarefas de visión desde a v1. Para avaliar o seu rendemento máis alá do texto, compilamos un banco de probas de cinco tarefas centrado especialmente na clasificación de documentos, incluídas facturas, cartas e currículos. O conxunto tamén abrangue a clasificación de imaxes de satélite, a clasificación de texturas, a clasificación de razas de mascotas e o reconto de animais.

Decider v1.3 acada unha precisión media do 76,99 % nas cinco tarefas visuais e supera a Jev 1.14 en 1,47 puntos porcentuais. Decider Flash v1.3 acada o 72,77 %, o que demostra capacidades de clasificación visual nun modelo máis pequeno.

Ampliar

Solicitudes de decisión do mundo real

Tomamos unha mostra dun millón de solicitudes deduplicadas e con PII enmascarada enviadas á Perplexity Decision API durante os seus primeiros 18 días de dispoñibilidade. Como cada solicitude pode conter varias preguntas sobre o mesmo estado, a mostra comprende 2 318 887 preguntas individuais. Todas as solicitudes incluíronse co permiso explícito dos usuarios para fins de investigación.

As solicitudes de produción non inclúen etiquetas de referencia verificadas, polo que empregamos LLM de vangarda como xuíces para xerar respostas de referencia e medir a concordancia de cada modelo con elas. Tamén agrupamos as solicitudes en 10 categorías de tarefas: extracción de información, clasificación por dominio, análise de sentimento, intención e enrutamento, clasificación por relevancia, moderación de contido, revisión de calidade e cumprimento normativo, correspondencia de entidades, análise empresarial e unha categoría “Outros”. Este desglose mostra como varía o rendemento segundo os casos de uso reais.

A combinación de tarefas é desigual: a extracción de información supón 425 402 preguntas; a clasificación por dominio, 409 564; e a análise de sentimento, 344 158. En conxunto, estas tres categorías representan o 50,8 % das preguntas da mostra.

Decider v1.3 acada a maior concordancia cos xuíces, cun 93,98 %, fronte ao 93,68 % de Decider v1.2 e ao 93,35 % de Jev 1.14. Decider v1.3 e Jev 1.14 están moi igualados en clasificación por dominio e análise de sentimento, con diferenzas de 0,34 e 0,07 puntos porcentuais, respectivamente. Jev lidera por 0,69 puntos en clasificación por relevancia, mentres que Decider v1.3 lidera por 0,93 puntos en extracción de información (a tarefa máis común da mostra) e por 1,21 puntos en intención e enrutamento.

Ampliar

O gráfico seguinte compara o custo indicado de executar o mesmo millón de solicitudes de produción. Cada solicitude pode conter varias preguntas, polo que a unidade aquí son as solicitudes, non as preguntas individuais.

Ampliar

Robustez

Avaliamos a sensibilidade ás etiquetas en 372 preguntas de opción múltiple, con 4788 solicitudes por modelo. Reordenamos as opcións, reasignamos as etiquetas aos textos das respostas e renomeamos as etiquetas mantendo o significado de cada pregunta, e despois comprobamos se cambiaba a resposta semántica do modelo. Unhas taxas de cambio máis baixas indican unha maior estabilidade.

Decider v1.3 cambiou a súa resposta en só o 0,27 % das preguntas con cada transformación, fronte ao 2,69–4,84 % de Jev 1.14. Tamén repetimos entradas idénticas para medir a variabilidade no servizo: Decider v1.3 non mostrou ningún cambio, mentres que Jev 1.14 cambiou no 1,88 % das preguntas.

Ampliar

Como usamos Decider

Decider está deseñado para fluxos de traballo que necesitan decisións rápidas e estruturadas. Nesta sección exploramos como aproveitalos para xerar un impacto significativo na nosa forma de traballar. Velaquí algúns que destacaron.

Regras de seguridade que melloran por si mesmas

Internamente, xa estamos a usar Decider para mellorar as nosas políticas de seguridade.

A actividade dos nosos axentes rexístrase e realízase unha serie de comprobacións baseadas en regras para identificar calquera comportamento problemático. Un enfoque baseado en regras permítenos supervisar os nosos axentes en tempo real cunha latencia engadida insignificante. Fóra de liña, usamos Decider para examinar mostras destes rexistros de axentes. Se non se sinalou ningún comportamento problemático, Decider comproba se hai algo que o noso conxunto de regras pasou por alto; e se saltou unha alarma, Decider comproba se se trataba dunha falsa alarma. Calquera rexistro no que o noso conxunto de regras falle en calquera dos dous casos envíase a un axente para a súa triaxe e proponse unha corrección das regras, que debe aprobar un membro do noso equipo de seguridade.

Nun día, Decider leu 1000 millóns de tokens en 7000 sesións de axentes e identificou defectos que levaron a 14 correccións de regras, 6 das cales se aprobaron e implantaron en dous días. Ao reproducilas sobre os rexistros dunha semana, as correccións reduciron un 52 % o volume da nosa regra máis activa, e as regras ampliadas detectaron aproximadamente un 40 % máis de accións lexítimas que investigar.

Ampliar

Supervisión de rollouts de RL

Cando pos-adestramos modelos con aprendizaxe por reforzo, as métricas agregadas, como unha recompensa terminal, non explican por que un rollout (un intento individual dunha tarefa) tivo éxito ou fracasou. Pode perder recompensa inxustamente porque fallou un servizo de ferramentas ou o contorno illado, ou recibir unha recompensa inmerecida se o avaliador pasa por alto unha afirmación sen fundamento, como un valor inventado que ningunha ferramenta devolveu.

Usamos Decider para supervisar os rollouts nestes casos. Primeiro, o código identifica as partes dun rollout que merecen unha inspección máis detida: unha chamada a unha ferramenta fallida e o razoamento que a rodea, código que se executou sen erros ou a resposta final. Despois, Decider responde preguntas de opción múltiple sobre cada parte, como que fallou nun paso (un servizo de ferramentas, un sitio externo, o contorno illado, o harness ou o propio código do axente) e se o axente interpretou correctamente o resultado. Agrupamos todas as preguntas sobre unha parte determinada nunha única solicitude e almacenamos as probabilidades en lugar dun veredicto, para poder axustar os limiares máis adiante sen volver consultar a Decider. O monitor só observa e diagnostica: nunca cambia unha recompensa nin detén unha execución.

Ampliar

Filtrado da calidade das páxinas

Ao rastrexar páxinas web para indexalas e servilas aos usuarios, moitas páxinas teñen unha calidade demasiado baixa para resultar de utilidade. Isto inclúe muros antibots, CAPTCHA e páxinas de erro, así como páxinas web cargadas correctamente que simplemente non conteñen ningunha información útil, como spam, recheo para SEO ou páxinas só de navegación. Estas páxinas de baixa calidade deben identificarse e filtrarse do noso índice.

Con Decider, podemos xulgar a calidade das páxinas mentres as rastrexamos. No mesmo paso cara adiante, realizamos un conxunto doutras tarefas de clasificación, como identificar o dominio e o público obxectivo do contido e se contén información prexudicial, ilegal ou de identificación persoal. En comparación con usar un LLM como xuíz, Decider é considerablemente máis rápido e barato.

Ampliar

Ademais destes usos internos, Decider tamén se adapta a fluxos de traballo como os seguintes.

Control de calidade visual

Como Decider le imaxes, tamén funciona como verificador visual: revisa os cambios de estilo en páxinas web ou aplicacións e identifica defectos. Pode revisar capturas de pantalla de páxinas para detectar texto cortado, elementos superpostos ou deseños rotos antes de que se publique un cambio, ou sinalar gráficos cuxo deseño poida inducir a erro ao lector ou incumprir unha guía de marca.

Ampliar

Navegación web

Os axentes poden usar Decider para as pequenas decisións dentro de tarefas máis grandes. Un axente de navegador pode enviar unha captura de pantalla en cada paso e recibir información detallada sobre o estado da páxina e o resultado esperado de cada acción posible.

Ampliar

Planificación de tarefas de investigación

As preguntas dos usuarios poden variar moito en complexidade, igual que a profundidade da busca necesaria para atopar unha resposta. Decider pode estimalo antes de que comece a busca, o que permite dedicar menos recursos ás preguntas sinxelas.

Ampliar

Primeiros pasos

Decider devolve probabilidades. O limiar de decisión axeitado depende da aplicación. As frecuencias das etiquetas e os custos relativos dos falsos positivos e dos falsos negativos varían segundo o caso de uso. Por iso, animamos os usuarios a axustar os limiares nun conxunto de desenvolvemento etiquetado pequeno e representativo, en lugar de supoñer que un punto de corte fixo funcionará igual de ben en todas as tarefas.

Recomendamos usar Decider v1.3 para xuízos matizados, rúbricas detalladas e fluxos de traballo nos que os erros saen caros. Escolle Decider Flash v1.3 para enrutamento, etiquetaxe e filtraxe de gran volume nos que a latencia e o custo son as principais restricións. Avalía ambos os modelos con exemplos representativos da túa carga de traballo e despois escolle o modelo que cumpra os teus requisitos de calidade, latencia e orzamento.

Ambos os modelos están dispoñibles como pesos descargables en Hugging Face baixo licenza Apache, a través de OpenRouter e na Perplexity Decisions API.

Cita

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