Perplexity Decider

Lanzamos Decider v1.3 y Decider Flash v1.3, los sucesores de nuestros modelos de decisión anteriores: v1, v1.1, v1.2 y Flash v1.2.

Decider Flash v1.3 es un modelo más pequeño destilado de Decider v1.3. Ambos modelos están disponibles en Hugging Face con licencia Apache, a través de OpenRouter y en la Perplexity Decisions API.

Perplexity Decider se inspira en Jev, el System One Model de TypeSafe AI. Admite clasificación binaria y multiclase con etiquetas ordenadas o no ordenadas, y devuelve probabilidades que las aplicaciones pueden usar para clasificar, enrutar, ordenar y evaluar entradas.

Ambos modelos v1.3 mejoran el rendimiento y la robustez en una amplia variedad de tareas de texto y visión gracias a la atención bidireccional, unos datos de entrenamiento mejor seleccionados y una receta de entrenamiento perfeccionada. También presentamos locate, una nueva función para resaltar el contenido seleccionado en tareas de reconocimiento de entidades nombradas, identificación de información personal y respuesta extractiva a preguntas.

En esta publicación, explicamos cómo entrenamos y evaluamos Decider y contamos cómo lo usamos internamente en Perplexity.

¿Qué es un modelo de decisión?

Un modelo de decisión es un clasificador de uso general. Le das una entrada y un conjunto de preguntas, cada una con sus posibles respuestas. Para cada pregunta, devuelve una distribución de probabilidad sobre las respuestas. Admite 3 tipos de preguntas:

• Sí / No: decisiones binarias.
• Opción múltiple: etiquetas multiclase personalizadas.
• Puntuación: niveles ordenados.

Los modelos de decisión admiten una amplia variedad de tareas de clasificación y puntuación:

• Evaluación de salidas: valorar la fidelidad, la calidad y la seguridad.
• Enrutamiento: dirigir las solicitudes a modelos más pequeños o más grandes según su dificultad.
• Moderación y seguridad: detectar contenido dañino, phishing e inyección de prompts en las salidas de herramientas.
• Filtrado y etiquetado: organización de grandes colecciones de contenido.
• Recuperación y reordenación: puntuar los resultados de búsqueda según su relevancia.

Muchas de estas tareas las gestionaban antes modelos generativos como los LLM, aunque no requieren generar texto libre. Los modelos de decisión se sitúan entre los LLM y los clasificadores específicos de tareas. Devuelven probabilidades para varias preguntas sobre la misma entrada en una única pasada hacia delante, lo que evita generar respuestas token a token y permite compartir el cómputo entre preguntas. A diferencia de los clasificadores específicos de tareas, pueden abordar tareas nuevas mediante prompts en lenguaje natural, una flexibilidad que adquieren al entrenarse con tareas diversas en un formato compartido de preguntas y respuestas.

Entrenamiento

Convertir un LLM generativo en un modelo de decisión

Creamos Decider adaptando potentes modelos troncales LLM generativos. Para explicar la adaptación, primero describimos cómo se representa una solicitud. Como se ilustra a continuación, una solicitud consta de un contexto compartido (el estado) y varias preguntas. Todas las preguntas reutilizarán el estado.

Por ejemplo, dados un documento y su resumen, una sola solicitud puede preguntar si el resumen representa fielmente el documento y si está dirigido a un público experto o general. Después del estado, cada bloque de pregunta contiene una pregunta y sus posibles respuestas, a cada una de las cuales se asigna un token de etiqueta predefinido, como A, B o C. Un token especial <|marker|> indica dónde leer la predicción del modelo. En esta posición, una capa de salida lineal aprendida (un cabezal de decisión) asigna el estado oculto a puntuaciones para las opciones de respuesta de la pregunta, que después se convierten en probabilidades.

Ampliar

Inicializamos la capa de salida a partir del modelo base, que normalmente puntúa el siguiente token sobre todo el vocabulario, y solo conservamos las filas correspondientes a los tokens de opción predefinidos, como A, B o C. Después, esta capa podada se entrena para convertir el estado oculto de <|marker|> en puntuaciones de respuesta. Este enfoque abarca todas las preguntas de clasificación, porque todas pueden formularse como preguntas de opción múltiple.

Para el entrenamiento, tomamos cientos de conjuntos de datos públicos que abarcan tareas diversas (sentimiento, inferencia en lenguaje natural, detección de intención, emparejamiento de entidades, moderación, verificación de hechos, valoraciones, etc.) y convertimos cada ejemplo al formato unificado descrito anteriormente: un estado, una o varias preguntas, sus opciones y un objetivo. El objetivo puede ser la única opción correcta si disponemos de etiquetas de referencia o una distribución de probabilidad sobre las opciones.

En la v1.3, presentamos locate, que extrae texto del estado en lugar de seleccionar entre opciones predefinidas. Una pregunta de locate describe qué hay que encontrar, mediante una etiqueta breve como «ubicación» o una instrucción como «Extrae el nombre de la ciudad donde se encuentra el empleo». El modelo devuelve el texto exacto que coincide en el estado, junto con sus posiciones de carácter inicial y final. Si no identifica ninguna coincidencia, devuelve una lista vacía.

Ampliar

Gracias al estado compartido, una sola solicitud puede combinar preguntas de locate, de clasificación y de puntuación sobre la misma entrada. Por ejemplo, puede preguntar si un empleo requiere experiencia de nivel sénior y extraer las competencias necesarias.

Atención bidireccional: dejar que el modelo lea en ambas direcciones

Nuestros modelos parten de sólidas redes troncales generativas preentrenadas, cuya atención causal hace que cada token solo atienda a sí mismo y a los tokens anteriores. Nuestros estudios de ablación mostraron que hacer bidireccionales las capas de atención completa de la red troncal mejora el rendimiento, por lo que adoptamos este diseño para que cada token incorpore contexto de toda la entrada.

La atención bidireccional plantea otra decisión de diseño: ¿cómo deben interactuar el estado y las preguntas? Consideramos tres patrones de atención, con distintas implicaciones para el rendimiento, la estabilidad de las respuestas y la reutilización de la caché:

• Todo ve todo (v1.2): el estado y todas las preguntas se procesan juntos con atención bidireccional completa. El cálculo sobre el estado se comparte, pero la respuesta a una pregunta puede cambiar en función de qué más se pregunte.
• Preguntas aisladas (v1.3): el estado atiende a todas las preguntas, mientras que cada pregunta solo atiende al estado y a sus propios tokens. Las preguntas aún pueden influirse entre sí indirectamente a través del estado compartido, pero los resultados son más estables.
• Totalmente almacenable en caché: el estado solo se atiende a sí mismo, mientras que cada pregunta atiende al estado y a sus propios tokens. El estado es independiente de las preguntas y reutilizable entre solicitudes para aprovechar el almacenamiento en caché de prompts. No lo usamos de forma predeterminada, porque permitir que el estado vea las preguntas es muy importante para varias tareas, pero basta un pequeño ajuste fino para que un modelo pase a usarlo.

Finalmente, elegimos las preguntas aisladas por su gran rendimiento y estabilidad.

Ampliar

Receta de entrenamiento

El entrenamiento se desarrolla en tres etapas para ambos tamaños de modelo. Primero entrenamos el modelo más grande, basado en Qwen3.8-27B, con entropía cruzada sobre grandes conjuntos de datos, y después lo destilamos en el modelo más pequeño, Qwen3.5-4B.

La primera etapa es el entrenamiento generalista, en el que hacemos un ajuste fino completo del modelo con corpus a gran escala. En esta etapa, solo aceptamos datos que ayuden al modelo en general y que no sean específicos de ningún banco de pruebas; por tanto, excluimos todas las particiones de entrenamiento de los bancos de pruebas.

Una vez entrenado este modelo generalista, ejecutamos una segunda etapa más detallada con LoRA. Los datos de esta etapa se orientan a dominios y tareas específicos. Añadimos datos en la segunda etapa en lugar de en la primera si observamos mejoras limitadas o algunas regresiones en otras tareas. Usamos LoRA para no alejarnos demasiado del modelo generalista y no arriesgarnos a perder rendimiento por ajustarnos a esos dominios específicos. El objetivo es mejorar el rendimiento sin perder el conocimiento general del modelo troncal. También aplicamos un peso al volver a fusionar el LoRA con el modelo base, para controlar la deriva con mayor precisión y priorizar las métricas con datos reservados por encima de cualquier mejora dentro del dominio.

Por último, añadimos un paso específico de visión. Al igual que en la segunda etapa, el paso de visión se trata como otro paso de especialización detallada, con un adaptador LoRA que se vuelve a fusionar con el modelo base con un peso. Algunas capacidades de visión pueden obtenerse a costa del rendimiento en texto. Como observamos un uso mucho mayor de los modelos en texto, priorizamos las métricas de texto sobre las de visión.

Para ambas etapas de texto, utilizamos la media de los pesos de tres ejecuciones, cada una con una semilla aleatoria distinta. Comprobamos que esto mejora el rendimiento y la robustez del modelo agregado.

Una vez obtenido el modelo grande final, aplicamos el mismo procedimiento de entrenamiento en tres etapas al modelo más pequeño. Aquí, el modelo grande actúa como profesor: su distribución de salida predicha sustituye a las etiquetas de referencia, y el modelo más pequeño se entrena para minimizar la divergencia KL entre sus predicciones y las del profesor. Este objetivo de destilación supera a la entropía cruzada con los mismos datos de entrenamiento. Aunque la entropía cruzada rinde mejor en benchmarks con datos de entrenamiento específicos, generaliza peor a datos reservados. Nuestra hipótesis es que la destilación transfiere mejor la distribución de salida del profesor, incluida su confianza en las alternativas que no son de referencia, mientras que la entropía cruzada favorece el sobreajuste a la distribución de entrenamiento específica de cada benchmark. Por ello, adoptamos el objetivo de destilación basado en KL.

Para mitigar la contaminación entre entrenamiento y prueba, eliminamos cualquier muestra de entrenamiento que pueda solaparse con alguna de las evaluaciones que utilizamos. Esto es importante porque algunos conjuntos de datos de entrenamiento públicos contienen gran parte de ciertos conjuntos de datos de evaluación. También realizamos exhaustivas auditorías y eliminación de sesgos para garantizar que nuestras mejoras sean fiables y no se deban simplemente a sesgos aprendidos.

Añadir la capacidad de extraer información

La función locate extrae información, como entidades nombradas, a partir de texto, sin cambiar la forma en que responde a las solicitudes habituales. Para ello, introducimos una etapa de entrenamiento adicional: añadimos a Decider un nuevo token especial, <|locate|>, un cabezal de spans y un adaptador LoRA.

Inicializamos el embedding de <|locate|> a partir del de <|marker|> aprendido en las etapas de entrenamiento anteriores. Solo entrenamos este nuevo embedding, el cabezal de spans y los adaptadores LoRA, mientras mantenemos congelados los pesos originales de la red troncal y el cabezal de decisión. Cada campo solicitado obtiene su propio token <|locate|>.

El cabezal de segmentos utiliza la representación de <|locate|> junto con las representaciones de los tokens de estado para puntuar dónde empiezan y terminan los segmentos coincidentes, y qué pares de inicio y fin van juntos. También utiliza la representación del token <|locate|> para predecir umbrales específicos de cada campo para estas puntuaciones. Los segmentos seleccionados se devuelven como posiciones de caracteres en el texto original.

Entrenamos el cabezal de segmentos con una pérdida InfoNCE adaptada que sitúa cada segmento de referencia por encima del umbral, y el umbral por encima de cualquier otro segmento. La pérdida tiene dos términos: el primero sitúa las puntuaciones de los segmentos correctos por encima del umbral y de los segmentos incorrectos. El segundo término sitúa el umbral por encima de las puntuaciones de los segmentos incorrectos. Los campos sin respuesta solo reciben el segundo término, lo que enseña al modelo a devolver una lista vacía.

Entrenamos con una combinación de tareas de extracción de fragmentos, como el reconocimiento de entidades nombradas, la detección de PII y la respuesta extractiva a preguntas. Variamos las descripciones de los campos, desde etiquetas breves hasta instrucciones detalladas, para que el modelo aprenda a seguir la solicitud en lugar de memorizar un conjunto fijo de etiquetas.

Locate enseña al modelo una tarea estructuralmente distinta, y queremos añadirla sin perder lo que el modelo ya hace bien. Fusionar los adaptadores de locate con el modelo troncal provoca cierta regresión en las solicitudes de decisión. Para limitarla, estamos investigando opciones como usar más datos de repetición de etapas anteriores y objetivos auxiliares que mantengan las salidas del modelo en las solicitudes de decisión cerca de las del modelo original. Sin embargo, comprobamos que, por ahora, la fusión sigue sin estar libre de pérdidas, así que mantenemos los adaptadores sin fusionar y solo los activamos en las solicitudes de locate.

Evaluación

Evaluamos Decider v1.3 y Decider Flash v1.3 en benchmarks externos del Hugging Face Decision Index, ClaimBench de Vals AI y el Artificial Analysis Decision Index.

En estas evaluaciones, nuestros modelos demuestran un gran rendimiento. Aunque estas clasificaciones incluyen tareas privadas, aún pueden manipularse mediante envíos repetidos y ajustes iterativos basados en los resultados de la clasificación. Para complementarlas, evaluamos los modelos con un conjunto interno que combina tareas privadas de producción con evaluaciones reservadas extraídas de conjuntos de datos públicos que no son benchmarks. Estas evaluaciones aportan una comprobación adicional de la generalización más allá de los benchmarks públicos, lo que nos ayuda a distinguir las mejoras generales de las ganancias específicas de conjuntos de evaluación conocidos.

Internamente, creamos un conjunto de más de 200 tareas que abarcan diversos dominios y tipos de tarea, como la clasificación, la puntuación, la reordenación y la extracción de entidades. Para evaluar con honestidad el rendimiento real de Decider, todas las evaluaciones se realizan en modalidad zero-shot, sin ajuste fino específico para cada tarea, lo que nos da una señal clara de dónde mejorar el modelo.

Clasificación de consultas

En Perplexity, utilizamos un sistema de clasificación multicabezal para procesar cada consulta de los usuarios. Cada consulta pasa primero por un modelo de embeddings que actúa como extractor de características. El embedding resultante se introduce después en varios cabezales de clasificación independientes, que incluyen clasificadores binarios y multietiqueta. Por ejemplo, un cabezal determina si una consulta del usuario debe activar una búsqueda web.

En 63 tareas de clasificación con referencias reetiquetadas de forma independiente por un LLM de vanguardia, Decider v1.3 alcanza una precisión media del 91,6 % y supera a nuestros clasificadores de producción en 6,54 puntos porcentuales. Decider Flash v1.3 también supera a la referencia de producción, mientras que Decider v1.3 supera a Jev 1.14.

Ampliar

Clasificación específica por dominio

Reunimos un conjunto de evaluación específico por dominio a partir de conjuntos de datos públicos para evaluar el rendimiento de clasificación de los modelos de decisión en siete dominios: verificación de afirmaciones (6 tareas), sanidad (7), ciberseguridad (8), programación (16), administración pública (7), derecho (9) y finanzas (9).

Por ejemplo, «juzgar la complejidad temporal de un programa en Python» o «usar un informe financiero anual para determinar si el efectivo no restringido de una empresa cubre el principal de la deuda que vence en los próximos doce meses». Decider v1.3 lidera en los siete dominios y supera a Jev 1.14 en hasta 12,9 puntos porcentuales en finanzas y 9,3 puntos en derecho. Decider Flash v1.3 queda por detrás de Jev 1.14 en finanzas, programación y derecho, y tiene un rendimiento similar en los demás dominios.

Ampliar

Recuperación y reordenación

La búsqueda es la base de Perplexity. Mantenemos un amplio conjunto de tareas de recuperación para evaluar el rendimiento de reordenación de nuestros modelos. Para cada tarea, primero usamos un conjunto de modelos de embeddings para recuperar los 50 documentos candidatos principales de cada corpus. Después, reordenamos estos candidatos con Decider y comparamos su rendimiento con el de un sólido reordenador de referencia, Qwen3-Reranker-8B.

Evaluamos Decider en un entorno zero-shot y por puntos (pointwise), usando el modelo para puntuar directamente cada par consulta-documento de forma independiente y ordenar los documentos por relevancia. En 72 tareas de recuperación, Decider v1.3 alcanza un nDCG@10 medio de 83,99 y supera a Qwen3-Reranker-8B en 1,81 puntos y a Jev 1.14 en 2,24 puntos.

En el banco de pruebas BEIR, ambos modelos superan a Qwen3-Reranker-8B en 8,78 y 7,05 puntos de nDCG@10, respectivamente. Frente a Jev 1.14, Decider v1.3 obtiene 1,33 puntos más, mientras que la versión Flash obtiene 0,4 menos.

Ampliar

Clasificación multilingüe

Para evaluar los modelos de decisión más allá del inglés, reunimos un banco de pruebas de clasificación multilingüe compuesto por 19 tareas específicas de cada idioma procedentes de 8 conjuntos de datos públicos, con 46.484 ejemplos en ocho idiomas: alemán, español, francés, italiano, ruso, japonés, coreano y chino. El banco de pruebas abarca detección de intención, clasificación por temas, análisis de sentimiento, inferencia en lenguaje natural, detección de paráfrasis, detección de lenguaje ofensivo y aceptabilidad gramatical.

Indicamos la precisión media de las tareas de cada idioma, ponderando cada tarea por igual. Decider v1.3 supera a Jev 1.14 en los ocho idiomas y Decider Flash v1.3 lo hace en seis, con precisiones medias por tarea del 88,16 % para Decider v1.3 y del 86,50 % para Decider Flash v1.3, frente al 85,41 % de Jev 1.14.

Ampliar

NER, PII y preguntas y respuestas extractivas

Evaluamos la función locate en 17 tareas fuera de dominio que ponen a prueba su capacidad de extracción en distintos dominios, formatos de entrada (texto, tablas, documentos estructurados) e instrucciones (etiquetas breves, preguntas y descripciones detalladas). Los dominios van desde Wikipedia hasta artículos científicos, informes de ciberamenazas, soporte técnico, políticas de privacidad, currículos y contratos legales. Las solicitudes van desde nombres de etiqueta breves como «persona» o «dirección de correo electrónico», pasando por preguntas sobre una tabla o un ticket de soporte, hasta descripciones detalladas de campos para extracción estructurada, como las partes de un acuerdo de confidencialidad o el total de una factura.

Evaluamos NER y PII mediante el F1 de segmento exacto, que exige que los segmentos predichos coincidan exactamente con los límites de referencia. La QA extractiva utiliza el F1 a nivel de carácter, que otorga crédito parcial por el texto de respuesta solapado, mientras que la extracción estructurada utiliza la precisión por campo, es decir, la proporción de campos extraídos correctamente. Para el análisis de CV, promediamos las puntuaciones F1 de segmento exacto de NER y PII.

Comparamos nuestros modelos con modelos de extracción de uso general de distintos tamaños: GLiNER large v2.5 (0,5B), Liquid d1 (2B) y Clairic de Cloudflare (tamaño no revelado). Decider v1.3 alcanza una puntuación media de 69,0 (con la métrica principal de cada tarea) y Decider Flash v1.3 llega a 63,6, frente a 43,3 de Liquid d1, 41,5 de Clairic y 33,6 de GLiNER large v2.5. Ambos modelos Decider lideran en todas las categorías.

Ampliar

Clasificación de imágenes

Decider admite de forma nativa tareas de visión desde la v1. Para evaluar su rendimiento más allá del texto, reunimos un banco de pruebas de cinco tareas con especial atención a la clasificación de documentos, como facturas, cartas y currículos. El conjunto también abarca la clasificación de imágenes de satélite, la clasificación de texturas, la clasificación de razas de mascotas y el conteo de animales.

Decider v1.3 alcanza una precisión media del 76,99 % en las cinco tareas visuales y supera a Jev 1.14 en 1,47 puntos porcentuales. Decider Flash v1.3 alcanza el 72,77 %, lo que demuestra capacidades de clasificación visual en un modelo más pequeño.

Ampliar

Solicitudes de decisión reales

Tomamos una muestra de un millón de solicitudes deduplicadas y con la PII enmascarada enviadas a la Perplexity Decision API durante sus primeros 18 días de disponibilidad. Como cada solicitud puede contener varias preguntas sobre el mismo estado, la muestra comprende 2.318.887 preguntas individuales. Todas las solicitudes se incluyeron con el permiso explícito de los usuarios para fines de investigación.

Las solicitudes de producción no incluyen etiquetas de referencia verificadas, por lo que usamos LLM de vanguardia como jueces para generar respuestas de referencia y medir la concordancia de cada modelo con ellas. También agrupamos las solicitudes en 10 categorías de tareas, entre ellas extracción de información, clasificación por dominio, análisis de sentimiento, intención y enrutamiento, ordenación por relevancia, moderación de contenido, revisión de calidad y cumplimiento, emparejamiento de entidades, análisis empresarial y una categoría «Otros». Este desglose muestra cómo varía el rendimiento en distintos casos de uso reales.

La distribución de tareas es desigual: la extracción de información representa 425.402 preguntas; la clasificación por dominio, 409.564, y el análisis de sentimiento, 344.158. En conjunto, estas tres categorías suponen el 50,8 % de las preguntas de la muestra.

Decider v1.3 logra la mayor concordancia con los jueces, con un 93,98 %, frente al 93,68 % de Decider v1.2 y el 93,35 % de Jev 1.14. Decider v1.3 y Jev 1.14 están muy igualados en clasificación por dominio y análisis de sentimiento, con diferencias de 0,34 y 0,07 puntos porcentuales, respectivamente. Jev lidera por 0,69 puntos en ordenación por relevancia, mientras que Decider v1.3 lidera por 0,93 puntos en extracción de información (la tarea más común de la muestra) y por 1,21 puntos en intención y enrutamiento.

Ampliar

El siguiente gráfico compara el coste declarado de ejecutar el mismo millón de solicitudes de producción. Cada solicitud puede contener varias preguntas, por lo que aquí la unidad son las solicitudes, no las preguntas individuales.

Ampliar

Robustez

Evaluamos la sensibilidad a las etiquetas en 372 preguntas de opción múltiple, con 4788 solicitudes por modelo. Reordenamos las opciones, reasignamos las etiquetas a los textos de respuesta y renombramos las etiquetas conservando el significado de cada pregunta; después, comprobamos si cambiaba la respuesta semántica del modelo. Unas tasas de cambio más bajas indican una mayor estabilidad.

Decider v1.3 cambió su respuesta en solo el 0,27 % de las preguntas con cada transformación, frente al 2,69-4,84 % de Jev 1.14. También repetimos entradas idénticas para medir la variabilidad del servicio: Decider v1.3 no mostró ningún cambio, mientras que Jev 1.14 cambió en el 1,88 % de las preguntas.

Ampliar

Cómo usamos Decider

Decider está diseñado para flujos de trabajo que necesitan decisiones rápidas y estructuradas. En esta sección, exploramos cómo aprovechar estos modelos para lograr un impacto significativo en nuestra forma de trabajar. Estos son algunos casos que destacan.

Reglas de seguridad que se mejoran a sí mismas

Internamente, ya utilizamos Decider para mejorar nuestras políticas de seguridad.

La actividad de nuestros agentes se registra y se realiza una serie de comprobaciones basadas en reglas para identificar cualquier comportamiento problemático. Un enfoque basado en reglas nos permite supervisar a nuestros agentes en tiempo real con una latencia añadida insignificante. Fuera de línea, usamos Decider para examinar muestras de estos registros de agentes. Si no se ha señalado ningún comportamiento problemático, Decider comprueba si hay algo que nuestro conjunto de reglas haya pasado por alto; y si se ha disparado una alarma, Decider comprueba si se trata de una falsa alarma. Todos los registros en los que nuestro conjunto de reglas falla en cualquiera de los dos casos se envían a un agente para su triaje, y se propone una corrección de las reglas, que debe aprobar un miembro de nuestro equipo de seguridad.

En un día, Decider leyó 1000 millones de tokens en 7000 sesiones de agentes e identificó fallos que dieron lugar a 14 correcciones de reglas, 6 de las cuales se aprobaron y se implementaron en dos días. Al reproducirlas sobre una semana de registros, las correcciones redujeron en un 52 % el volumen de nuestra regla más activa, y las reglas ampliadas detectaron aproximadamente un 40 % más de acciones legítimas que investigar.

Ampliar

Supervisión de rollouts de RL

Cuando posentrenamos modelos con aprendizaje por refuerzo, las métricas agregadas, como una recompensa terminal, no explican por qué un rollout (un intento individual de realizar una tarea) tuvo éxito o fracasó. Puede perder recompensa injustamente porque falló un servicio de herramientas o el entorno aislado, o recibir una recompensa inmerecida si el evaluador pasa por alto una afirmación sin fundamento, como un valor inventado que ninguna herramienta devolvió.

Usamos Decider para supervisar los rollouts en estos casos. Primero, el código identifica las partes de un rollout que merecen una inspección más detallada: una llamada a herramienta fallida y el razonamiento que la rodea, el código que se ejecutó sin errores o la respuesta final. Después, Decider responde a preguntas de opción múltiple sobre cada parte, como qué falló en un paso (un servicio de herramientas, un sitio externo, el entorno aislado, el harness o el propio código del agente) y si el agente interpretó correctamente el resultado. Agrupamos todas las preguntas sobre una parte determinada en una sola solicitud y almacenamos las probabilidades en lugar de un veredicto, para poder ajustar los umbrales más adelante sin volver a consultar a Decider. El monitor solo observa y diagnostica: nunca cambia una recompensa ni detiene una ejecución.

Ampliar

Filtrado por calidad de página

Al rastrear páginas web para indexarlas y ofrecerlas a los usuarios, muchas páginas tienen una calidad demasiado baja para resultar útiles. Esto incluye muros antibots, CAPTCHA y páginas de error, así como páginas web cargadas correctamente que simplemente no contienen información útil, como spam, relleno SEO o páginas solo de navegación. Estas páginas de baja calidad deben identificarse y filtrarse de nuestro índice.

Con Decider, podemos juzgar la calidad de las páginas a medida que las rastreamos. En la misma pasada hacia delante, realizamos un conjunto de otras tareas de clasificación, como identificar el dominio y el público objetivo del contenido, y si contiene información dañina, ilegal o de identificación personal. En comparación con usar un LLM como juez, Decider es considerablemente más rápido y barato.

Ampliar

Más allá de estos usos internos, Decider también encaja en flujos de trabajo como los siguientes.

Preguntas y respuestas visuales

Como Decider lee imágenes, también funciona como verificador visual: revisa cambios de estilo en páginas web o aplicaciones e identifica fallos. Puede revisar capturas de pantalla de páginas en busca de texto recortado, elementos superpuestos o diseños rotos antes de que se publique un cambio, o señalar gráficos cuyo diseño podría inducir a error al lector o incumplir una guía de marca.

Ampliar

Navegación con el navegador

Los agentes pueden usar Decider para las pequeñas decisiones dentro de tareas más grandes. Un agente de navegador puede enviar una captura de pantalla en cada paso y recibir información detallada sobre el estado de la página y el resultado esperado de cada acción posible.

Ampliar

Planificación de tareas de investigación

Las preguntas de los usuarios pueden variar mucho en complejidad, al igual que la profundidad de la búsqueda necesaria para encontrar una respuesta. Decider puede estimarlo antes de que empiece la búsqueda, lo que permite dedicar menos recursos a las preguntas sencillas.

Ampliar

Primeros pasos

Decider devuelve probabilidades. El umbral de decisión adecuado depende de la aplicación. Las frecuencias de las etiquetas y los costes relativos de los falsos positivos y los falsos negativos varían según el caso de uso. Por eso, recomendamos a los usuarios ajustar los umbrales con un conjunto de desarrollo etiquetado, pequeño y representativo, en lugar de suponer que un punto de corte fijo funcionará igual de bien en todas las tareas.

Recomendamos usar Decider v1.3 para juicios matizados, rúbricas detalladas y flujos de trabajo en los que los errores son costosos. Elige Decider Flash v1.3 para el enrutamiento, el etiquetado y el filtrado de gran volumen, donde la latencia y el coste son las principales restricciones. Evalúa ambos modelos con ejemplos representativos de tu carga de trabajo y, después, elige el que cumpla tus requisitos de calidad, latencia y presupuesto.

Ambos modelos están disponibles como pesos descargables en Hugging Face con licencia Apache, a través de OpenRouter y en la 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}
}