Mejoras en todos los niveles de esfuerzo de Agent API

Los niveles de esfuerzo de Perplexity Agent API permiten a los desarrolladores elegir el equilibrio entre coste, velocidad y profundidad de investigación para cada tarea. A partir de hoy, todos los niveles de esfuerzo cuestan menos por consulta, con una calidad de investigación superior o igual. Hay disponible un nuevo nivel ultra para la investigación más amplia y exhaustiva. Cualquier solicitud que seleccione el nivel por su nombre, como effort="fast", recibe automáticamente la configuración actualizada.

Crear un agente de investigación implica encontrar el equilibrio adecuado entre coste, velocidad y profundidad para cada tarea. Los niveles de esfuerzo de Agent API toman esa decisión por el usuario. Cada nivel es una configuración empaquetada que define el modelo, el presupuesto de pasos, los ajustes de búsqueda y las herramientas para un tipo de tarea concreto. Perplexity evalúa y actualiza cada nivel con el tiempo para ofrecer la mejor investigación con un coste igual o inferior al actual.

Estas mejoras se debieron a dos tipos de cambios. Los presupuestos, la gestión del contexto y la extracción redujeron el coste de cada ejecución, y las Skills, la selección de modelos y los agentes en paralelo aumentaron o mantuvieron la calidad de la respuesta.

El rendimiento de medium mejoró del 55 % al 77 % en BrowseComp y DSQA, mientras que los costes se redujeron casi un 90 %. BrowseComp y DSQA son benchmarks de investigación públicos; WANDR es el benchmark de Perplexity de tareas de investigación largas con múltiples entidades. xhigh realiza trabajo agéntico, como ejecutar código en un entorno aislado, mantener bucles largos de uso de herramientas y trabajar con muchas fuentes a la vez. xhigh mantuvo su puntuación en WANDR en el 76,5 % con aproximadamente un 25 % del coste de la configuración de agosto de 2026.

Una solicitud de Investigación profunda puede ejecutar decenas de búsquedas, leer cientos de páginas y comprobar evidencias antes de responder. Cada una de esas acciones añade tokens al contexto y dólares a la factura. Sin límites, un agente sigue realizando acciones que elevan el coste y saturan el contexto sin mejorar la respuesta. Cinco factores explican la mayor parte de ese coste:

Asignación del presupuesto. Los agentes con un presupuesto fijo pueden quedarse sin pasos y terminar su ejecución antes de completar su tarea. Por el contrario, los agentes sin un presupuesto fijo pueden seguir ejecutándose y generar costes sin mejorar la respuesta final.
Sobrecarga de contexto. Los resultados de búsqueda y las páginas obtenidas aportan las evidencias, pero, sin control, la ventana de contexto puede llenarse rápidamente de información irrelevante. Las ventanas de contexto arrastran costes de un paso a otro, y las ventanas sobrecargadas pueden reducir el rendimiento del agente.
Selección del flujo de trabajo. Cada tarea requiere un enfoque distinto. Una consulta de un solo dato, una pregunta de varios saltos y un análisis amplio de fuentes requieren cada una un flujo de trabajo diferente. Si se le deja elegir por su cuenta, un modelo suele escoger uno ineficiente. Detallar todas las estrategias disponibles en el prompt del agente no lo resuelve. Las instrucciones adicionales se arrastran como tokens en cada paso, y el modelo sigue cada una de ellas con menos fiabilidad con el tiempo.
Selección de modelos. Cambiar a un modelo más grande puede no aportar una mejora de rendimiento proporcional al coste adicional. Los nuevos modelos llegan acompañados de titulares y puntuaciones de benchmarks publicadas. Sin embargo, las mejoras en los benchmarks pueden estar contaminadas o reflejar un sobreajuste del modelo. Sin una evaluación en tareas reales, un cambio de modelo puede elevar los costes sin mejorar la calidad.
Escalado multiagente. Un solo agente puede buscar, leer y razonar sobre un número finito de fuentes por ejecución. Ejecutar varios agentes en paralelo mejora la calidad en las tareas más exigentes, pero también aumenta los costes e introduce complejidad si no se gestiona correctamente.

Resolver cada uno de estos retos redujo los costes de todos los niveles de esfuerzo sin reducir el rendimiento.

Cada nivel de esfuerzo tiene un presupuesto de investigación fijo con tres componentes:

Límites de pasos: el número de turnos que puede realizar el agente
Llamadas a herramientas: un límite al número total de llamadas a herramientas en una solicitud. Un solo paso puede emitir varias llamadas a varias herramientas a la vez, por lo que un límite de pasos por sí solo no controla cuántas acciones se producen dentro de un paso.
Recordatorios de presupuesto: avisos periódicos de cuántos pasos quedan, para que el agente pueda priorizar y reservar margen para redactar la respuesta en lugar de agotar el presupuesto a mitad de la tarea.

El presupuesto es la disyuntiva central: más pasos implican mejores respuestas, y cada paso genera costes. Con openai/gpt-6-luna, aumentar el límite de pasos de 1 a 15 eleva la precisión en BrowseComp + DSQA del 41 % al 80 %, mientras que el coste por consulta sube de 0,0017 $ a 0,0152 $: unas 9 veces el coste para aproximadamente el doble de puntuación.

Un límite de pasos por sí solo no controla el coste de la investigación. Con el mismo presupuesto de cinco pasos, openai/gpt-6.1-terra realiza más llamadas a herramientas que openai/gpt-6-luna, porque los modelos más capaces tienden a emitir varias llamadas en un solo paso. Los niveles de esfuerzo limitan tanto las llamadas a herramientas como los pasos. Para estos modelos, el límite de llamadas a herramientas importa tanto como el límite de pasos.

Cada nivel de esfuerzo ajusta estos límites, pero el agente también tiene que saber cuántos pasos y acciones le quedan para completar la solicitud. Sin esa información, puede quedarse sin pasos o acciones y verse obligado a responder antes de completar la investigación. El presupuesto se indica al comienzo de la ejecución y los recordatorios llegan a medida que el agente se acerca a sus límites, de modo que haya margen para verificar y entregar los resultados. En high, los recordatorios abarcan tanto el presupuesto de pasos como el de llamadas a herramientas.

Se probaron dos agentes, uno con recordatorio de presupuesto y otro sin él, en una tarea de BrowseComp que consistía en identificar una serie de televisión de los años noventa a partir de las biografías de tres miembros del reparto. El agente con recordatorio encontró la respuesta correcta usando 13 de los 40 pasos del presupuesto. El agente sin recordatorio de presupuesto usó los 40 pasos y no encontró la respuesta correcta. El bucle de ese agente terminó de forma inesperada y el modelo no sabía cuánto presupuesto de investigación le quedaba. Los recordatorios mantienen a los agentes centrados y les ayudan a priorizar eficazmente los recursos restantes.

Las tareas de investigación de larga duración llenan la ventana de contexto del modelo con resultados de búsqueda, páginas obtenidas y notas intermedias. Una vez llena, el agente debe dejar de trabajar.

La compactación permite que las ejecuciones largas sigan funcionando sin llenar la ventana de contexto. Cuando el contexto supera un umbral, el agente sustituye el trabajo realizado hasta el momento por un resumen más breve de lo que ha encontrado y lo que queda por hacer, y después continúa.

La compactación siempre conserva tres elementos en el contexto: el prompt del sistema, la solicitud original y cualquier Skill que el agente ya haya cargado. Tras cada compactación, el agente recibe dos instrucciones breves. La primera es: «Sigue trabajando hasta completar la tarea». Esto evita que el agente trate el resumen como un punto de parada. La segunda indica al agente cuántas compactaciones se han producido, para que pueda planificar las tareas de investigación restantes. Las ejecuciones largas mantienen a la vista el objetivo y el plan originales, y el coste de los bucles largos disminuye sin pérdida de calidad.

Cada página que lee el agente se suma a su contexto, y el agente la arrastra en cada paso posterior. Una página web incluye información no relacionada con la pregunta, como la navegación, texto repetitivo y otros contenidos.

En lugar de entregar al agente una página completa, fetch_url realiza primero una pasada de extracción. El texto de la página se envía a un modelo más pequeño junto con la tarea actual del agente. El modelo devuelve solo los pasajes relevantes, citados literalmente para que el agente pueda referenciarlos. Durante una evaluación, una página de 5561 tokens se redujo a 293 tokens, lo que liberó espacio para más contexto relevante.

Usar fetch_url con extracción en el nivel de esfuerzo high redujo los tokens de entrada por consulta aproximadamente un 50 %. La extracción también mejoró el rendimiento en los benchmarks, con un 88,0 % a 0,073 $ por consulta, frente al 83,5 % a 0,094 $ sin extracción.

Buscar en la web es fundamental en toda solicitud de investigación de un agente. Se introdujeron tres cambios en la forma en que buscan los agentes:

Más contexto por búsqueda: cada búsqueda devuelve ahora hasta 4K tokens de resultados en lugar de 2K. El agente encuentra antes lo que necesita, lo que se traduce en menos búsquedas y un coste menor.

Un nuevo motor de fragmentos: los resultados de búsqueda reciben fragmentos que se ajustan mejor a la consulta, de modo que el agente no se sobrecarga con texto irrelevante.
Búsqueda rápida: a 1,00 $ por cada 1000 solicitudes, Fast Search reduce tanto el coste como la latencia de cada llamada de búsqueda.

El equipo de Perplexity Search mejora continuamente la calidad de la recuperación en una amplia variedad de tareas. Las actualizaciones recientes han aportado mejoras en código, documentación para desarrolladores, páginas de referencia y contenido jurídico y normativo.

Algunas tareas requieren ejecutar muchas búsquedas en paralelo; otras necesitan una lectura atenta de unos pocos documentos largos.

Sin embargo, cargar todos los flujos de trabajo en el prompt del sistema del agente añade sobrecarga de contexto y puede hacer que el modelo rinda por debajo de lo esperado en tareas sencillas. En su lugar, las Skills se organizan en un árbol con divulgación progresiva. El modelo carga las Skills e instrucciones relevantes a medida que trabaja y deja fuera de su contexto la información no relacionada. Cada Skill solo cuesta su nombre y su descripción hasta que el modelo decide que encaja con la tarea y la carga; en ese momento, las instrucciones completas se añaden al contexto y el modelo sigue el flujo de trabajo establecido.

Para medir la contribución de cada Skill, se elimina cada una por separado y se comparan la calidad y el coste en las tareas en las que el agente de referencia cargó esa Skill. Estas ablaciones muestran qué flujos de trabajo ayudan al agente y cómo afectan a la eficiencia de la investigación.

Las siguientes ejecuciones del benchmark WANDR muestran a agentes eligiendo los flujos de trabajo correctos para tareas concretas. Las pautas de wide-search y fanout se cargaron en todas las tareas, lo que refleja la necesidad de investigar múltiples entidades. People-search se cargó solo en el 6 % de las tareas, y únicamente cuando las preguntas se referían a personas.

En otra tarea de WANDR, el agente cargó la Skill people-search con un patrón de fanout para encontrar ingenieros de inferencia en Londres. Amplió 39 términos de cargo en 117 consultas y, a continuación, fusionó los resultados de la primera pasada en 43 perfiles únicos para un cribado posterior. La Skill people-search guio al agente en esta ampliación sin añadir contexto irrelevante. El fragmento siguiente está adaptado del script del agente; los nombres de las funciones auxiliares son ilustrativos.

code1

text

Python

# roles contains the 39 role variants selected by the agent.
queries = []
for role in roles:
    queries.extend([
        {"query": f"Google DeepMind {role} London"},
        {"query": f"Google {role} London"},
        {"query": role, "company": "Google", "location": "London"},
    ])

results = pplx_sdk.search.people_many(
    queries, limit_per_query=50, concurrency=8
)

profiles = {}
for result in results:
    if not result.ok:
        continue
    for profile in result.result:
        if "linkedin.com/in/" not in profile.url:
            continue
        url = profile.url.split("?")[0].rstrip("/")
        previous = profiles.get(url, {})
        if url not in profiles or len(profile.summary or "") > len(
            previous.get("summary") or ""
        ):
            profiles[url] = {
                "url": url,
                "title": profile.title,
                "summary": profile.summary,
            }

Los puntos de control son otro flujo de trabajo que ayuda a los agentes en tareas de larga duración. El patrón de puntos de control procede de la programación por lotes. Cuando un script procesa una lista larga, escribe cada resultado en disco en cuanto lo obtiene, en lugar de mantenerlo todo en memoria hasta el final. Si el script falla o encuentra errores a mitad de camino, no se pierde nada: la siguiente ejecución lee lo que ya se había guardado y continúa desde donde se quedó, reintentando solo los elementos que fallaron.

En otra tarea de WANDR, el agente tenía que cribar los perfiles de 188 ingenieros. Cargó el patrón de puntos de control para registrar cada resultado a medida que trabajaba. La primera pasada extrajo 160 perfiles, pero falló en 28. Cuando el agente volvió a ejecutar el script, omitió los perfiles que ya se habían registrado y reintentó solo los 28 restantes. Sin el punto de control, un solo registro erróneo habría obligado a obtener de nuevo los 188.Fragmento de Python adaptado; se omiten las páginas de entrada, la instrucción de cribado, el esquema y las importaciones; los nombres de las funciones auxiliares son ilustrativos.

code 2

text

Python

checkpoint = Checkpoint("research/profile-screening")
config = instruction + json.dumps(schema)
config_id = hashlib.md5(config.encode()).hexdigest()[:6]

def checkpoint_key(page):
    url_id = hashlib.md5(page["url_in"].encode()).hexdigest()[:10]
    return config_id + url_id

pending = [
    page for page in pages if not checkpoint.has(checkpoint_key(page))
]
for offset in range(0, len(pending), 20):
    batch = pending[offset : offset + 20]
    inputs = [
        json.dumps({
            "url": page["url_in"], "content": page["content"][:30_000]
        })
        for page in batch
    ]
    results = pplx_sdk.llm.extract_many(
        inputs,
        instruction=instruction,
        output_schema=schema,
        chunk_size=5,
        concurrency=4,
    )
    for page, result in zip(batch, results):
        if not result.ok or result.result.error:
            continue
        checkpoint.record(
            checkpoint_key(page),
            [{"url": page["url_in"], **result.result.result}],
        )

El punto de control registra los resultados obtenidos correctamente; no lanza reintentos. Incluir la instrucción y el esquema en la clave garantiza que los cambios en los criterios de cribado desencadenen un nuevo procesamiento.

No todas las pruebas se tradujeron en mejoras de calidad y eficiencia. Se evaluó la precarga de todas las Skills en el agente antes de que comenzara su tarea. En BrowseComp y DSQA, la precarga aumentó el coste un 13 %. En WANDR, donde las trayectorias de investigación más largas hacen que el contenido recuperado represente una mayor proporción de los tokens de entrada, la precarga también reduce las puntuaciones. Estos resultados respaldaron seguir utilizando la divulgación progresiva.

A medida que avanzan las capacidades de los modelos, también cambia el mejor modelo para cada nivel de esfuerzo. Perplexity utiliza un bucle de investigación automatizado que supervisa los anuncios de nuevos modelos y su disponibilidad. Las evaluaciones se ponen en marcha en cuanto un modelo pasa a estar accesible.

Cuando se lanza un modelo nuevo, un agente automatizado lo somete al harness de evaluación. Prueba distintos valores de esfuerzo de razonamiento, presupuestos de pasos y de llamadas a herramientas, y configuraciones de herramientas, y puntúa cada ejecución en calidad y coste frente a los niveles de esfuerzo actuales. Cuando una ejecución empeora, el agente investiga por qué, ajusta la configuración y vuelve a ejecutar la evaluación. Un candidato solo sustituye al modelo actual cuando lo supera en calidad con un coste igual o inferior.

Los benchmarks públicos son útiles, pero sus puntuaciones no siempre se trasladan a las tareas del mundo real. Por ejemplo, el siguiente gráfico muestra un modelo candidato que obtuvo 13,3 puntos más que la referencia en BrowseComp, pero quedó muy por debajo de las referencias correspondientes en tareas internas de investigación empresarial, jurídica y financiera.

Un solo agente solo puede abarcar un número limitado de fuentes en un bucle. Para las tareas complejas, varios agentes trabajan en paralelo de forma coordinada, y cada uno se ocupa de una parte distinta del problema.

El agente principal es el orquestador. Llama a spawn_agent para crear agentes secundarios y asigna a cada uno una tarea concreta y acotada. Cada agente secundario ejecuta su propio bucle de investigación con un contexto independiente, usando su propio modelo, sus herramientas y su presupuesto de pasos. Los agentes secundarios comunican sus resultados al principal, que puede enviarles un nuevo encargo de seguimiento o consultar su progreso. El orquestador y sus agentes secundarios intercambian mensajes para compartir evidencias, señalar bloqueos y ajustar los siguientes pasos. A medida que llega nueva información, el orquestador afina los encargos y, cuando el trabajo termina, combina los resultados en una única respuesta.

Agent API admite roles de agente predefinidos, y el orquestador puede crear agentes secundarios con instrucciones personalizadas.

El nivel de esfuerzo ultra ejecuta tres agentes en paralelo sobre una tarea. Cada agente investiga de forma independiente la tarea completa, lo que da lugar a evidencias distintas. Un cuarto agente combina sus hallazgos, elimina duplicados y redacta la respuesta final.

En WANDR, ultra obtiene un 85,9 % con 21,71 $ por tarea. Logra la puntuación más alta entre las configuraciones probadas.

Los niveles de esfuerzo se evalúan y mejoran continuamente. El nivel que seleccionan los usuarios determina cuánta investigación recibe una tarea y cuánto costará. Los presupuestos de pasos y de llamadas a herramientas, con recordatorios a medida que se agotan, mantienen las solicitudes dentro del presupuesto. La compactación, la extracción y unos fragmentos mejores mantienen el contexto centrado en las evidencias. Las Skills adaptan el flujo de trabajo a la tarea, y los agentes en paralelo amplían lo que puede abarcar un solo bucle. Un bucle de evaluación automatizado solo admite un modelo nuevo cuando mejora la calidad de la investigación con el mismo coste.

Cada nivel de esfuerzo seguirá evolucionando a medida que nuevos modelos y configuraciones demuestren su valía en la evaluación. Llamar a un nivel por su nombre incorpora automáticamente esas mejoras; fijar una versión mantiene una configuración sin cambios.

Prueba Agent API y compara los niveles de esfuerzo con tus propias cargas de trabajo. Consulta los detalles de los niveles de esfuerzo en nuestra documentación sobre el esfuerzo de Agent API.

El coste de la investigación

Control del presupuesto de investigación

Gestión del contexto

Compactación

Obtener solo lo que importa

Búsqueda web focalizada

Seleccionar el flujo de trabajo correcto

Selección de modelos

Escalado multiagente

Próximos pasos