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 está inspirado 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 gama de tareas de texto y visión gracias a la atención bidireccional, datos de entrenamiento mejor seleccionados y una receta de entrenamiento refinada. 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 compartimos 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 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 reordenamiento: puntuar resultados de búsqueda según su relevancia.

Muchas de estas tareas se resolvían antes con modelos generativos como los LLM, aunque no requieren generar texto libre. Los modelos de decisión se ubican entre los LLM y los clasificadores específicos de tareas. Devuelven probabilidades para varias preguntas sobre la misma entrada en una sola pasada hacia adelante, lo que evita generar respuestas token por 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 aprenden al entrenarse con tareas diversas en un formato compartido de preguntas y respuestas.

Entrenamiento

Cómo convertir un LLM generativo en un modelo de decisión

Construimos Decider adaptando sólidos backbones de 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, dado 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, cada una con 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 (una cabeza de decisión) asigna el estado oculto a puntuaciones para las opciones de respuesta de la pregunta, que luego se convierten en probabilidades.

Ampliar

Inicializamos la capa de salida a partir del modelo base, que normalmente puntúa el siguiente token en todo el vocabulario, y conservamos solo las filas correspondientes a los tokens de opción predefinidos, como A, B o C. Luego, esta capa podada se entrena para convertir el estado oculto de <|marker|> en puntuaciones de respuesta. Este enfoque cubre todas las preguntas de clasificación, ya que 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, coincidencia de entidades, moderación, verificación de hechos, calificaciones, etc.) y convertimos cada ejemplo al formato unificado descrito arriba: un estado, una o más preguntas, sus opciones y un objetivo. El objetivo puede ser la única opción correcta, si tenemos etiquetas de referencia (gold labels), o una distribución de probabilidad sobre las opciones.

En v1.3, presentamos locate, que extrae texto del estado en lugar de elegir entre opciones predefinidas. Una pregunta de locate describe qué buscar, ya sea con una etiqueta breve como “ubicación” o con 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 coincidencias, devuelve una lista vacía.

Ampliar

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

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

Nuestros modelos parten de sólidas arquitecturas base generativas preentrenadas, cuya atención causal permite que cada token atienda solo 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 arquitectura base mejora el rendimiento, por lo que adoptamos este diseño para que cada token incorpore el contexto de toda la entrada.

La atención bidireccional plantea otra decisión de diseño: ¿cómo deberían 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ómputo sobre el estado se comparte, pero la respuesta a una pregunta puede cambiar según qué más se pregunte.
• Preguntas aisladas (v1.3): El estado atiende a todas las preguntas, mientras que cada pregunta atiende solo 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 aplica atención sobre sí mismo, mientras que cada pregunta aplica atención sobre el estado y 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 un pequeño ajuste fino puede hacer que un modelo cambie a este modo.

En última instancia, elegimos las preguntas aisladas por su buen rendimiento y estabilidad.

Ampliar

Receta de entrenamiento

El entrenamiento se realiza 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 luego lo destilamos en el modelo más pequeño, Qwen3.5-4B.

La primera etapa es el entrenamiento generalista, en la que hacemos un ajuste fino completo del modelo con corpus a gran escala. En esta etapa, solo aceptamos datos que ayuden al modelo de forma general y que no sean específicos de ningún benchmark; por ello, excluimos cualquier partición de entrenamiento de benchmarks.

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

Por último, agregamos un paso específico para visión. Al igual que 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 afectar el rendimiento con texto. Como observamos un uso mucho mayor de los modelos con texto, priorizamos las métricas de texto sobre las de visión.

Para ambas etapas de texto, usamos el promedio de los pesos de tres ejecuciones, cada una con una semilla aleatoria distinta. Descubrimos 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 maestro: su distribución de salida predicha reemplaza 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 maestro. 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 dedicados, generaliza peor a datos reservados. Nuestra hipótesis es que la destilación transfiere mejor la distribución de salida del maestro, incluida su confianza en alternativas distintas de la etiqueta de referencia, mientras que la entropía cruzada fomenta el sobreajuste a la distribución de entrenamiento específica del benchmark. Por lo tanto, adoptamos el objetivo de destilación basado en KL.

Para mitigar la contaminación entre entrenamiento y prueba, eliminamos cualquier muestra de entrenamiento que pudiera superponerse con alguna de las evaluaciones que usamos. Esto es importante porque algunos conjuntos de datos públicos de entrenamiento contienen gran parte de algunos conjuntos de datos de evaluación. También realizamos auditorías exhaustivas para detectar y eliminar sesgos, y así asegurarnos de que nuestras mejoras sean confiables y no se deban solo a sesgos aprendidos.

Agregar la capacidad de extraer información

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

Inicializamos el embedding de <|locate|> a partir de <|marker|>, aprendido en las etapas de entrenamiento anteriores. Entrenamos solo este nuevo embedding, la cabeza de span y los adaptadores LoRA, y mantenemos congelados los pesos originales de la arquitectura base y la cabeza de decisión. Cada campo solicitado recibe su propio token <|locate|>.

La cabeza de segmentos usa 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 usa 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 la cabeza de segmentos con una pérdida InfoNCE adaptada que empuja cada segmento de referencia por encima del umbral, y el umbral por encima de todos los demás segmentos. La pérdida tiene dos términos: el primero empuja las puntuaciones de los segmentos correctos por encima del umbral y de los segmentos incorrectos. El segundo término empuja el umbral por encima de las puntuaciones de los segmentos incorrectos. Los campos sin respuesta solo reciben el segundo término, lo que le enseña al modelo a devolver una lista vacía.

Entrenamos con una combinación de tareas de extracción de spans, como reconocimiento de entidades nombradas, detección de PII y 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 le enseña al modelo una tarea estructuralmente distinta, y queremos agregarla sin perder lo que el modelo ya hace bien. Fusionar los adaptadores de locate en el backbone 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 solicitudes de decisión cerca de las del modelo original. Sin embargo, observamos que, por ahora, la fusión todavía no es sin pérdidas, así que mantenemos los adaptadores sin fusionar y los activamos solo para 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 muestran un rendimiento sólido. Aunque estas tablas de clasificación incluyen tareas privadas, aún pueden manipularse mediante envíos repetidos y ajustes iterativos basados en la retroalimentación de la tabla. 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 ofrecen una verificació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 clasificación, puntuación, reordenamiento y extracción de entidades. Para evaluar con honestidad el rendimiento de Decider en el mundo real, 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, usamos un sistema de clasificación con múltiples cabezas para procesar cada consulta de usuario. Primero, cada consulta pasa por un modelo de embeddings que actúa como extractor de características. Luego, el embedding resultante se envía a varias cabezas de clasificación independientes, que incluyen clasificadores binarios y multietiqueta. Por ejemplo, una cabeza determina si la consulta de un usuario debe activar una búsqueda web.

En 63 tareas de clasificación con referencias reetiquetadas de forma independiente por un LLM de frontera, Decider v1.3 alcanza una exactitud media del 91.6% y supera a nuestros clasificadores de producción por 6.54 puntos porcentuales. Decider Flash v1.3 también supera al modelo de 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), salud (7), ciberseguridad (8), programación (16), gobierno (7), derecho (9) y finanzas (9).

Por ejemplo, “evalúa la complejidad temporal de un programa en Python” o “usa un informe financiero anual para determinar si el efectivo no restringido de una empresa cubre el principal de la deuda con vencimiento en los próximos doce meses”. Decider v1.3 lidera en los siete dominios y supera a Jev 1.14 por 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 reordenamiento

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

Evaluamos Decider en un entorno zero-shot y puntual (pointwise): usamos 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 por 1.81 puntos y a Jev 1.14 por 2.24 puntos.

En el benchmark BEIR, ambos modelos superan a Qwen3-Reranker-8B por 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 puntos menos.

Ampliar

Clasificación multilingüe

Para evaluar los modelos de decisión más allá del inglés, reunimos un benchmark de clasificación multilingüe compuesto por 19 tareas específicas por idioma 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 benchmark abarca detección de intención, clasificación por tema, análisis de sentimiento, inferencia en lenguaje natural, detección de paráfrasis, detección de lenguaje ofensivo y aceptabilidad gramatical.

Reportamos la exactitud media de las tareas dentro de cada idioma, con la misma ponderación para cada tarea. Decider v1.3 supera a Jev 1.14 en los ocho idiomas y Decider Flash v1.3 lo hace en seis, con exactitudes 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 respuesta extractiva a preguntas

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ículums 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 (NDA) o el total de una factura.

Evaluamos NER y PII con F1 de segmentos exactos, que exige que los segmentos predichos coincidan exactamente con los límites de referencia. La QA extractiva usa F1 a nivel de caracteres, que otorga crédito parcial por el texto de respuesta superpuesto, mientras que la extracción estructurada usa 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 segmentos exactos 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 promedio de 69.0 (con la métrica principal de cada tarea) y Decider Flash v1.3 alcanza 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 v1. Para evaluar su rendimiento más allá del texto, reunimos un conjunto de benchmarks de cinco tareas con especial énfasis en la clasificación de documentos, como facturas, cartas y currículums. El conjunto también abarca clasificación de imágenes satelitales, clasificación de texturas, clasificación de razas de mascotas y conteo de animales.

Decider v1.3 alcanza una exactitud media del 76.99% en las cinco tareas visuales y supera a Jev 1.14 por 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 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 permiso explícito de los usuarios para fines de investigación.

Las solicitudes de producción no incluyen etiquetas de referencia (ground truth), por lo que usamos LLM de frontera 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, que incluyen extracción de información, clasificación por dominio, análisis de sentimiento, intención y enrutamiento, ordenamiento por relevancia, moderación de contenido, revisión de calidad y cumplimiento, coincidencia de entidades, análisis de negocio y una categoría “Otros”. Este desglose muestra cómo varía el rendimiento según los casos de uso reales.

La combinació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 suman 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 parejos en clasificación por dominio y análisis de sentimiento, con diferencias de 0.34 y 0.07 puntos porcentuales, respectivamente. Jev lleva la delantera por 0.69 puntos en ordenamiento 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 costo reportado 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 4,788 solicitudes por modelo. Reordenamos las opciones, reasignamos las etiquetas a los textos de respuesta y renombramos las etiquetas sin alterar el significado de cada pregunta; luego comprobamos si la respuesta semántica del modelo cambiaba. Las tasas de cambio más bajas indican mayor estabilidad.

Decider v1.3 cambió su respuesta en solo el 0.27% de las preguntas con cada transformación, frente a entre el 2.69% y el 4.84% de Jev 1.14. También repetimos entradas idénticas para medir la variabilidad del servicio: Decider v1.3 no mostró cambios, 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 aprovecharlas para lograr un impacto significativo en nuestra forma de trabajar. Estos son algunos de los casos que más destacaron.

Reglas de seguridad que se mejoran a sí mismas

Internamente, ya usamos 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 monitorear a nuestros agentes en tiempo real con una latencia adicional insignificante. Fuera de línea, usamos Decider para revisar muestras de estos registros de agentes. Si no se marcó ningún comportamiento problemático, Decider verifica si hay algo que nuestro conjunto de reglas pasó por alto; y si se activó una alarma, Decider verifica si se trató 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ó 1,000 millones de tokens en 7,000 sesiones de agentes e identificó fallas que dieron lugar a 14 correcciones de reglas, 6 de las cuales se aprobaron e implementaron en un plazo de dos días. Al reproducirlas sobre una semana de registros, las correcciones redujeron un 52% el volumen de nuestra regla más activa, y las reglas ampliadas detectaron alrededor de un 40% más de acciones legítimas para investigar.

Ampliar

Monitoreo de rollouts de RL

Cuando hacemos el posentrenamiento de 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 falló. Un rollout 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 sustento, como un valor inventado que ninguna herramienta devolvió.

Usamos Decider para monitorear los rollouts en estos casos. Primero, el código identifica las partes de un rollout que ameritan una inspección más detallada: una llamada a herramienta fallida y el razonamiento que la rodea, código que se ejecutó sin errores o la respuesta final. Luego, Decider responde 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 guardamos 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 de páginas por calidad

Al rastrear páginas web para indexarlas y mostrarlas a los usuarios, encontramos muchas de tan baja calidad que no sirven para nada. Esto incluye muros antibots, CAPTCHA y páginas de error, así como páginas web que cargan correctamente pero que simplemente no contienen información útil, como spam, relleno para SEO o páginas que solo sirven para navegar. 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 adelante, 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 económico.

Ampliar

Además de estos usos internos, Decider también se adapta a 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 apps e identifica fallas. Puede revisar capturas de pantalla de páginas para detectar 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 confundir al lector o incumplir una guía de marca.

Ampliar

Navegación en 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 comience la búsqueda, lo que permite destinar menos recursos a las preguntas simples.

Ampliar

Primeros pasos

Decider devuelve probabilidades. El umbral de decisión adecuado depende de la aplicación. Las frecuencias de las etiquetas y los costos relativos de los falsos positivos y los falsos negativos varían según el caso de uso. Por ello, 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 donde los errores son costosos. Elige Decider Flash v1.3 para enrutamiento, etiquetado y filtrado de alto volumen, cuando la latencia y el costo sean las principales restricciones. Evalúa ambos modelos con ejemplos representativos de tu carga de trabajo y luego elige el modelo 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}
}