Perplexity añade conexión web en tiempo real a su API Decisions

Perplexity anunció el 4 de noviembre de 2026 que la conexión web está disponible de inmediato para su API Decisions, con búsquedas web en tiempo real opcionales antes de que el modelo devuelva probabilidades. La función está pensada para decisiones cuyas respuestas pueden cambiar después del entrenamiento, como el cargo directivo de una persona, la versión más reciente de un paquete de software o si un evento sigue programado.

La API Decisions acepta contenido como state y devuelve respuestas numéricas estructuradas en lugar de prosa. Una pregunta de sí o no produce la probabilidad de que la respuesta sea afirmativa; una pregunta con opciones produce una probabilidad para cada opción definida; y una pregunta de puntuación produce probabilidades para una escala ordenada, además de una puntuación esperada. Los desarrolladores pueden usar esos valores como umbrales en tareas de clasificación, enrutamiento y otras decisiones automatizadas. El estado puede contener texto, JSON o imágenes, y el lanzamiento también permite incluir una URL que dirija el modelo a una página específica.

Búsqueda en tiempo real antes de que responda el modelo

Al establecer mode en web_grounding se activa Fast Search en la pasarela de API de Perplexity antes de invocar el modelo. La pasarela genera una consulta por pregunta a partir de la pregunta y el comienzo del texto del estado, ejecuta búsquedas en paralelo, combina los resultados y elimina las URL duplicadas. Las preguntas que generan la misma consulta comparten una búsqueda. A continuación, la pasarela agrega al estado los títulos de las páginas, las URL y el texto como evidencia. Las respuestas siguen basándose en probabilidades, mientras que un search_results campo permite a los desarrolladores inspeccionar lo que vio el modelo.

Las búsquedas tienen límites explícitos. Se ejecutan hasta 10 en paralelo, con un límite de un segundo por búsqueda y de tres segundos en total. No se buscan imágenes. Las consultas se envían a Perplexity Search API y pueden incluir tanto el texto de la pregunta como el comienzo del estado, por lo que los datos enviados para la búsqueda forman parte de las consideraciones de privacidad de la integración.

Los fallos de búsqueda no necesariamente impiden que se genere una respuesta a la decisión. Si solo algunas búsquedas tienen éxito, el modelo utiliza los resultados recibidos. Si ninguna tiene éxito, responde a partir del estado original y devuelve una matriz search_results vacía. Por lo tanto, una respuesta puede conservar la estructura habitual aunque no se haya incorporado evidencia en tiempo real.

Mejoras de precisión y diferencias de medición

Perplexity informó que probó el mismo modelo de toma de decisiones con 328 afirmaciones de verdadero o falso tomadas de noticias de octubre de 2026 y de datos poco conocidos de Wikipedia. Cada afirmación verdadera tenía una contraparte falsa que difería en un solo detalle, y no se proporcionó evidencia en el estado. La precisión fue del 56,4 % sin conexión web y del 97,3 % con ella, mientras que los errores bajaron de 143 a nueve. La latencia mediana aumentó de 139 ms a 366 ms y la latencia del percentil 95, de 514 ms a 742 ms, lo que supone un costo de velocidad cuantificable a cambio de la mejora en precisión.

Parallel Web Systems afirmó que su prueba de referencia PWS-Decisions contiene 300 preguntas cerradas: 100 públicas con respuestas de referencia y 200 privadas. La evaluación utiliza coincidencia exacta, y el conjunto se seleccionó para medir dificultad, no para estimar la precisión en el tráfico promedio. La clasificación de Parallel informa la precisión media y la desviación estándar muestral de tres ejecuciones evaluadas el 29 de octubre de 2026; entre los resultados figura una precisión del 51,00 % para Perplexity Decisions en el conjunto público.

Perplexity afirmó que pplx-decider-v1.2 con la conexión web, respondió correctamente 86 de las 100 preguntas públicas en una ejecución del 4 de noviembre de 2026, que describió como la mayor precisión en el conjunto público frente a esa clasificación publicada. Su cliente midió una latencia mediana de 370 ms y una latencia del percentil 95 de 685 ms en esas 100 preguntas. Las mediciones de latencia independientes de Parallel abarcan respuestas completas en tres ejecuciones del conjunto de 300 preguntas, por lo que las dos series de cifras de latencia tienen alcances distintos.

Precios e integración

Una solicitud con conexión web puede incluir hasta 100 preguntas. Cada búsqueda completada cuesta 0,001 $, por lo que los cargos de búsqueda no superan los 0,10 $ por una solicitud de 100 preguntas; además, la evidencia recuperada se factura como tokens de entrada y cuenta para el límite de entrada de 256K. El modelo estándar pplx-decider-v1.2 cuesta 0,02 $ por millón de tokens de entrada y pplx-decider-flash-v1.2 cuesta 0,01 $ por millón; los tokens de salida son gratuitos.

La agrupación de preguntas afecta el costo final de los tokens. En el modelo estándar, la evidencia se contabiliza de nuevo cuando los límites de entrada obligan a distribuir las preguntas en grupos separados. Flash evalúa cada pregunta de forma independiente y vuelve a facturar el estado y la evidencia cada vez. Por lo tanto, el costo de la conexión web depende del número de búsquedas, de la cantidad de texto recuperado y de cómo el modelo elegido agrupa las preguntas.

La integración tiene actualmente una limitación relacionada con los tipos. La biblioteca Python de Perplexity, versión 0.44.0 o posterior, y el SDK de TypeScript, versión 0.39.0 o posterior, son compatibles con la API, pero sus tipos todavía no exponen mode ni search_results. Python pasa el modo a través de extra_body, mientras que TypeScript lo envía en el cuerpo de la solicitud.

Las cargas de trabajo que sugiere Perplexity incluyen comprobar si las cuentas han conseguido financiación en los últimos 90 días, vigilar las dependencias para detectar versiones estables posteriores a una versión fijada y confirmar que un evento sigue programado antes de que un agente lo reserve. En esos flujos de trabajo, la fundamentación aporta evidencia actual que se puede inspeccionar a una probabilidad a la que el software puede aplicar un umbral o que puede revisar. La contrapartida va más allá de la precisión: la latencia, el uso de tokens, las tarifas de búsqueda y la falta de evidencia en search_results todos ellos determinan qué representa la probabilidad devuelta.