Mejoras en todos los niveles de esfuerzo de la Agent API

Los niveles de esfuerzo de la Perplexity Agent API permiten a los desarrolladores elegir el equilibrio entre costo, 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 un nuevo nivel ultra disponible para la investigación más amplia y exhaustiva. Cualquier solicitud que seleccione el nivel por su nombre, como effort="fast", obtiene automáticamente la configuración actualizada.

Crear un agente de investigación implica elegir el equilibrio adecuado entre costo, velocidad y profundidad para cada tarea. Los niveles de esfuerzo de la Agent API toman esa decisión por el usuario. Cada nivel es una configuración integrada que define el modelo, el presupuesto de pasos, los ajustes de búsqueda y las herramientas para un tipo de tarea específico. Perplexity evalúa y actualiza cada nivel con el tiempo para ofrecer la mejor investigación a su costo actual o por debajo de él.

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

El rendimiento de medium mejoró del 55% al 77% en BrowseComp y DSQA, mientras que los costos disminuyeron casi un 90%. BrowseComp y DSQA son benchmarks públicos de investigación; 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, sostener ciclos largos de uso de herramientas y trabajar con muchas fuentes a la vez. xhigh mantuvo su puntuación en WANDR en 76.5% mientras operaba a aproximadamente el 25% del costo 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 verificar evidencia 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 costo y saturan el contexto sin mejorar la respuesta. Cinco factores explican la mayor parte de ese costo:

Asignación del presupuesto. Los agentes con un presupuesto establecido 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 costos sin mejorar la respuesta final.
Sobrecarga de contexto. Los resultados de búsqueda y las páginas obtenidas contienen la evidencia, pero, si no se controla, la ventana de contexto puede llenarse rápidamente de información irrelevante. Las ventanas de contexto arrastran costos de un paso a otro, y las ventanas saturadas 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 resuelve el problema. Las instrucciones adicionales se arrastran como tokens en cada paso, y el modelo sigue cada una con menos fiabilidad con el tiempo.
Selección de modelos. Cambiar a un modelo más grande puede no ofrecer una mejora de rendimiento proporcional al costo 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 costos 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 costos y añade complejidad si no se gestiona correctamente.

Resolver cada uno de estos desafíos redujo los costos de cada nivel 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 tomar 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 distintas herramientas a la vez, por lo que un límite de pasos por sí solo no controla cuántas acciones ocurren dentro de un paso.
Recordatorios de presupuesto: avisos periódicos de cuántos pasos quedan, para que el agente pueda priorizar y dejar margen para redactar la respuesta en lugar de quedarse sin presupuesto a mitad de la tarea.

El presupuesto es la disyuntiva central: más pasos significan mejores respuestas, y cada paso genera costos. 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 costo por consulta sube de 0.0017 USD a 0.0152 USD: unas 9 veces el costo por aproximadamente el doble de puntuación.

Un límite de pasos por sí solo no controla el costo de la investigación. Con el mismo presupuesto de cinco pasos, openai/gpt-6.1-terra hace 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 necesita 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 terminar 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 quede margen para verificar y entregar los resultados. En high, los recordatorios cubren 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 elenco. 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 ciclo de ese agente terminó de forma inesperada, y el modelo no sabía cuánto presupuesto de investigación le quedaba. Los recordatorios mantienen enfocados a los agentes 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 reemplaza el trabajo realizado hasta ese momento por un resumen más breve de lo que ha encontrado y de lo que falta, y luego 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. Después de cada compactación, el agente recibe dos instrucciones breves. La primera es: “Sigue trabajando hasta terminar la tarea”. Esto evita que el agente trate el resumen como un punto de parada. La segunda le indica al agente cuántas compactaciones se han producido, para que pueda planificar sus tareas de investigación restantes. Las ejecuciones largas mantienen a la vista el objetivo y el plan originales, y el costo de los ciclos largos disminuye sin que se reduzca la 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 otro contenido.

En lugar de entregarle al agente una página completa, fetch_url primero ejecuta 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 textualmente para que el agente pueda referenciarlos. Durante una evaluación, una página de 5,561 tokens se redujo a 293 tokens, lo que liberó espacio para más contexto relevante.

El uso de fetch_url con extracción en el nivel de esfuerzo high redujo aproximadamente un 50% los tokens de entrada por consulta. La extracción también mejoró el rendimiento en los benchmarks: alcanzó un 88.0% a 0.073 USD por consulta, frente a un 83.5% a 0.094 USD sin extracción.

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

Más contexto por búsqueda: Cada búsqueda ahora devuelve 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 costo menor.

Un nuevo motor de fragmentos: Los resultados de búsqueda reciben fragmentos que coinciden mejor con la consulta, para que el agente no se sature con texto irrelevante.
Búsqueda rápida: A 1.00 USD por cada 1000 solicitudes, Fast Search reduce tanto el costo 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 aportaron mejoras en código, documentación para desarrolladores, páginas de referencia y contenido legal y regulatorio.

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

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 ocupa su nombre y su descripción hasta que el modelo decide que se ajusta a la tarea y la carga; en ese momento, las instrucciones completas se añaden al contexto y el modelo sigue el flujo de trabajo indicado.

Para medir la contribución de cada Skill, se elimina una a la vez y se comparan la calidad y el costo 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 la eficiencia de la investigación.

Las siguientes ejecuciones del benchmark WANDR muestran a los agentes eligiendo los flujos de trabajo correctos para tareas específicas. Las guías de búsqueda amplia y fanout se cargaron en todas las tareas, lo que refleja la necesidad de investigar múltiples entidades. La búsqueda de personas se cargó solo en el 6% de las tareas, y únicamente cuando las preguntas se referían a personas.

Al probar otra tarea de WANDR, el agente cargó la Skill de búsqueda de personas con un patrón fanout para encontrar ingenieros de inferencia en Londres. Amplió 39 términos de cargo a 117 consultas y luego combinó los resultados de la primera pasada en 43 perfiles únicos para una evaluación posterior. La Skill de búsqueda de personas guio al agente en esta ampliación sin añadir contexto irrelevante. El extracto 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 (checkpointing) son otro flujo de trabajo que ayuda a los agentes en tareas de larga duración. El patrón de puntos de control proviene de la programación por lotes. Cuando un script procesa una lista larga, escribe cada resultado en el disco en cuanto lo obtiene, en lugar de guardarlo todo en memoria hasta el final. Si el script falla o encuentra errores a mitad del proceso, no se pierde nada: la siguiente ejecución lee lo que ya se guardó y continúa desde donde se quedó, reintentando solo los elementos que fallaron.

En otra tarea de WANDR, el agente tuvo que evaluar 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 estaban registrados y reintentó solo los 28 restantes. Sin el punto de control, un solo registro defectuoso habría implicado volver a obtener los 188.Extracto adaptado de Python; se omiten las páginas de entrada, la instrucción de evaluación, 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 exitosos; no inicia reintentos. Incluir la instrucción y el esquema en la clave garantiza que los cambios en los criterios de selección provoquen un nuevo procesamiento.

No todas las pruebas generaron mejoras en 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 costo 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 que se siguiera usando 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 emplea un ciclo de investigación automatizado que monitorea los anuncios de nuevos modelos y su disponibilidad. Las evaluaciones se activan en cuanto un modelo pasa a estar accesible.

Cuando se lanza un nuevo modelo, un agente automatizado lo somete al harness de evaluación. Recorre 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 costo frente a los niveles de esfuerzo actuales. Cuando una ejecución empeora, el agente investiga el motivo, ajusta la configuración y vuelve a ejecutar la evaluación. Un candidato reemplaza al modelo actual solo cuando lo supera en calidad con un costo igual o menor.

Los benchmarks públicos son útiles, pero sus puntuaciones no siempre se reflejan en tareas del mundo real. Por ejemplo, el siguiente gráfico muestra un modelo candidato que obtuvo 13.3 puntos por encima de la línea base en BrowseComp, pero muy por debajo de las líneas base correspondientes en tareas internas de investigación empresarial, legal y financiera.

Un solo agente solo puede abarcar cierto número de fuentes en un ciclo. En las tareas complejas, varios agentes trabajan en paralelo y de forma coordinada, cada uno en una parte distinta del problema.

El agente principal es el orquestador. Llama a spawn_agent para crear agentes hijos y asigna a cada uno una tarea específica y acotada. Cada hijo ejecuta su propio ciclo de investigación con un contexto independiente, con su propio modelo, sus herramientas y su presupuesto de pasos. Los hijos informan sus resultados al padre, que puede enviarle a un hijo una asignación de seguimiento o consultar su progreso. El orquestador y sus hijos intercambian mensajes para compartir evidencia, señalar obstáculos y ajustar los siguientes pasos. A medida que llega información nueva, el orquestador afina las asignaciones y, cuando el trabajo termina, combina los resultados en una sola respuesta.

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

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

En WANDR, ultra obtiene un 85.9% a 21.71 USD por tarea. Es la puntuación más alta entre las configuraciones probadas.

Los niveles de esfuerzo se evalúan y mejoran continuamente. El nivel que eligen 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 mejores fragmentos mantienen el contexto centrado en la evidencia. Las Skills adaptan el flujo de trabajo a la tarea, y los agentes en paralelo amplían lo que puede abarcar un solo ciclo. Un ciclo de evaluación automatizado admite un nuevo modelo solo cuando mejora la calidad de la investigación con el mismo costo.

Cada nivel de esfuerzo seguirá evolucionando a medida que nuevos modelos y configuraciones demuestren su valor en la evaluación. Al llamar a un nivel por su nombre, se incorporan automáticamente esas mejoras; fijar una versión mantiene la configuración sin cambios.

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

El costo de la investigación

Control del presupuesto de investigación

Gestión del contexto

Compactación

Obtener solo lo que importa

Búsqueda web enfocada

Selección del flujo de trabajo correcto

Selección de modelos

Escalado multiagente

Próximos pasos