Melloras en todos os niveis de esforzo da Agent API

Os niveis de esforzo da Perplexity Agent API permiten aos desenvolvedores escoller o equilibrio entre custo, velocidade e profundidade de investigación para cada tarefa. Desde hoxe, todos os niveis de esforzo custan menos por consulta, cunha calidade de investigación superior ou igual. Hai dispoñible un novo nivel ultra para a investigación máis ampla e exhaustiva. Calquera solicitude que seleccione o nivel polo seu nome, como effort="fast", obtén automaticamente a configuración actualizada.

Crear un axente de investigación implica escoller o equilibrio axeitado entre custo, velocidade e profundidade para cada tarefa. Os niveis de esforzo da Agent API toman esa decisión polo usuario. Cada nivel é unha configuración agrupada que define o modelo, o orzamento de pasos, a configuración de busca e as ferramentas para un tipo de tarefa específico. Perplexity avalía e actualiza cada nivel co tempo para ofrecer a mellor investigación co seu custo actual ou cun custo inferior.

Estas melloras proviñeron de dous tipos de cambio. Os orzamentos, a xestión do contexto e a extracción reduciron o custo de cada execución, mentres que as skills, a selección de modelos e os axentes en paralelo aumentaron ou mantiveron a calidade da resposta.

O rendemento de medium mellorou do 55 % ao 77 % en BrowseComp e DSQA, mentres que os custos baixaron case un 90 %. BrowseComp e DSQA son benchmarks públicos de investigación; WANDR é o benchmark de Perplexity de tarefas de investigación longas e con múltiples entidades. xhigh realiza traballo axéntico, como executar código nun contorno illado, manter longos bucles de uso de ferramentas e traballar con moitas fontes á vez. xhigh mantivo a súa puntuación en WANDR no 76,5 % cun custo de aproximadamente o 25 % do da configuración de agosto de 2026.

Unha solicitude de investigación profunda pode executar ducias de buscas, ler centos de páxinas e verificar evidencias antes de responder. Cada unha desas accións engade tokens ao contexto e dólares á factura. Sen límites, un axente segue realizando accións que aumentan o custo e saturan o contexto sen mellorar a resposta. Cinco factores explican a maior parte dese custo:

Asignación do orzamento. Os axentes cun orzamento establecido poden quedar sen pasos e rematar a súa execución antes de completar a tarefa. Pola contra, os axentes sen un orzamento fixo poden seguir executándose e xerar custos sen mellorar a resposta final.
Sobrecarga de contexto. Os resultados de busca e as páxinas obtidas conteñen as evidencias, pero, se non se controla, a xanela de contexto pode encherse rapidamente de información irrelevante. As xanelas de contexto arrastran custos dun paso a outro, e unhas xanelas sobrecargadas poden reducir o rendemento do axente.
Selección do fluxo de traballo. Cada tarefa necesita un enfoque distinto. Unha busca dun único dato, unha pregunta de varios saltos e unha revisión ampla de fontes requiren cada unha un fluxo de traballo diferente. Se se deixa que escolla por si mesmo, un modelo adoita elixir un ineficiente. Detallar todas as estratexias dispoñibles no prompt do axente non resolve o problema. As instrucións adicionais transpórtanse como tokens en cada paso, e co tempo o modelo segue cada unha delas de forma menos fiable.
Selección de modelos. Cambiar a un modelo máis grande pode non ofrecer unha mellora de rendemento proporcional ao custo adicional. Os novos modelos chegan acompañados de titulares e puntuacións de benchmarks publicadas. Porén, as melloras nos benchmarks poden estar contaminadas ou reflectir un sobreaxuste do modelo. Sen avaliación en tarefas reais, un cambio de modelo pode aumentar os custos sen mellorar a calidade.
Escalado multiaxente. Un só axente pode buscar, ler e razoar sobre un número finito de fontes en cada execución. Executar varios axentes en paralelo mellora a calidade nas tarefas máis esixentes, pero tamén aumenta os custos e introduce complexidade se non se xestiona correctamente.

Resolver cada un destes retos reduciu os custos de todos os niveis de esforzo sen reducir o rendemento.

Cada nivel de esforzo ten un orzamento de investigación fixo con tres compoñentes:

Límites de pasos: o número de quendas que pode realizar o axente
Chamadas a ferramentas: un límite no número total de chamadas a ferramentas nunha solicitude. Un só paso pode emitir varias chamadas a varias ferramentas á vez, polo que un límite de pasos por si só non controla cantas accións se producen dentro dun paso.
Recordatorios de orzamento: avisos periódicos de cantos pasos quedan, para que o axente poida priorizar e deixar marxe para redactar a resposta en lugar de esgotar o orzamento a metade da tarefa.

O orzamento é o compromiso central: máis pasos supoñen mellores respostas, e cada paso xera custos. Con openai/gpt-6-luna, aumentar o límite de pasos de 1 a 15 eleva a precisión en BrowseComp + DSQA do 41 % ao 80 %, mentres que o custo por consulta sobe de 0,0017 $ a 0,0152 $: unhas 9 veces o custo por unhas 2 veces a puntuación.

Un límite de pasos por si só non controla o custo da investigación. Co mesmo orzamento de cinco pasos, openai/gpt-6.1-terra fai máis chamadas a ferramentas que openai/gpt-6-luna, porque os modelos máis capaces tenden a emitir varias chamadas nun só paso. Os niveis de esforzo limitan tanto as chamadas a ferramentas como os pasos. Para estes modelos, o límite de chamadas a ferramentas importa tanto como o límite de pasos.

Cada nivel de esforzo axusta estes límites, pero o axente tamén ten que saber cantos pasos e accións lle quedan para completar a solicitude. Sen esa información, pode quedar sen pasos ou accións e verse obrigado a responder antes de completar a investigación. O orzamento indícase ao comezo da execución e os recordatorios chegan a medida que o axente se achega aos seus límites, de modo que queda marxe para verificar e entregar os resultados. No nivel high, os recordatorios abarcan tanto o orzamento de pasos como o de chamadas a ferramentas.

Probáronse dous axentes, un con recordatorio de orzamento e outro sen el, nunha tarefa de BrowseComp que consistía en identificar unha serie de televisión dos anos noventa a partir de tres biografías do reparto. O axente con recordatorio atopou a resposta correcta usando 13 dos 40 pasos do orzamento. O axente sen recordatorio de orzamento usou os 40 pasos e non atopou a resposta correcta. O bucle dese axente rematou de forma inesperada e o modelo non era consciente do orzamento de investigación restante. Os recordatorios manteñen os axentes centrados e axúdanlles a priorizar de forma eficaz os recursos restantes.

As tarefas de investigación de longa duración enchen a xanela de contexto do modelo con resultados de busca, páxinas obtidas e notas intermedias. Unha vez chea, o axente ten que deixar de traballar.

A compactación permite que as execucións longas sigan funcionando sen encher a xanela de contexto. Cando o contexto supera un limiar, o axente substitúe o traballo feito ata o momento por un resumo máis breve do que atopou e do que queda por facer e, a continuación, continúa.

A compactación sempre conserva tres elementos no contexto: o prompt do sistema, a solicitude orixinal e calquera skill que o axente xa cargase. Despois de cada compactación, o axente recibe dúas instrucións breves. A primeira é: «Continúa traballando ata que a tarefa estea feita». Isto evita que o axente trate o resumo como un punto de parada. A segunda indica ao axente cantas compactacións se produciron, para que poida planificar as tarefas de investigación restantes. As execucións longas manteñen á vista o obxectivo e o plan orixinais, e o custo dos bucles longos diminúe sen que se reduza a calidade.

Cada páxina que le o axente súmase ao seu contexto, e o axente lévaa consigo en cada paso posterior. Unha páxina web inclúe información non relacionada coa pregunta, como a navegación, texto estándar e outros contidos.

En lugar de entregarlle ao axente unha páxina enteira, fetch_url executa primeiro unha pasada de extracción. O texto da páxina envíase a un modelo máis pequeno xunto coa tarefa actual do axente. O modelo devolve só as pasaxes relevantes, reproducidas literalmente para que o axente poida citalas. Durante unha avaliación, unha páxina de 5.561 tokens reduciuse a 293 tokens, o que liberou espazo para máis contexto relevante.

Usar fetch_url con extracción no nivel de esforzo high reduciu nun 50 % aproximadamente os tokens de entrada por consulta. A extracción tamén mellorou o rendemento nos benchmarks, ao acadar un 88,0 % a 0,073 $ por consulta, fronte ao 83,5 % a 0,094 $ sen extracción.

Buscar na web é fundamental en todas as solicitudes de investigación dos axentes. Fixéronse tres cambios na forma en que buscan os axentes:

Máis contexto por busca: agora cada busca devolve ata 4K tokens de resultados en lugar de 2K. O axente atopa antes o que necesita, o que se traduce en menos buscas e nun custo menor.

Un novo motor de fragmentos: os resultados de busca reciben fragmentos que se axustan mellor á consulta, para que o axente non se vexa sobrecargado con texto irrelevante.
Busca rápida: a 1,00 $ por cada 1.000 solicitudes, Fast Search reduce tanto o custo como a latencia de cada chamada de busca.

O equipo de Perplexity Search mellora continuamente a calidade da recuperación nunha ampla variedade de tarefas. As actualizacións recentes trouxeron melloras en código, documentación para desenvolvedores, páxinas de referencia e contido xurídico e normativo.

Algunhas tarefas requiren executar moitas buscas en paralelo; outras necesitan unha lectura atenta de poucos documentos longos.

Porén, cargar todos os fluxos de traballo no prompt do sistema do axente engade sobrecarga de contexto e pode facer que o modelo rinda peor en tarefas sinxelas. Por iso, as skills organízanse nunha árbore con revelación progresiva. O modelo carga as skills e instrucións relevantes mentres traballa, e deixa fóra do seu contexto a información non relacionada. Cada skill só ocupa o seu nome e a súa descrición ata que o modelo decide que encaixa coa tarefa e a carga; nese momento, as instrucións completas engádense ao contexto e o modelo segue o fluxo de traballo indicado.

Para medir a contribución de cada skill, elimínanse unha a unha e compárase a calidade e o custo en tarefas nas que o axente de referencia cargou esa skill. Estas ablacións mostran que fluxos de traballo axudan ao axente e como afectan á eficiencia da investigación.

As execucións do benchmark WANDR que se mostran a continuación demostran como os axentes escollen os fluxos de traballo correctos para tarefas específicas. As indicacións de wide-search e fanout cargáronse en todas as tarefas, o que reflicte a necesidade de investigar múltiples entidades. People-search só se cargou no 6 % das tarefas, e unicamente cando as preguntas tiñan que ver con persoas.

Ao probar outra tarefa de WANDR, o axente cargou a skill people-search cun patrón de fanout para atopar enxeñeiros de inferencia en Londres. Expandiu 39 termos de rol en 117 consultas e, despois, fusionou os resultados da primeira pasada en 43 perfís únicos para un cribado posterior. A skill people-search guiou o axente nesta expansión sen engadir contexto irrelevante. O extracto seguinte está adaptado do script do axente; os nomes das funcións 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,
            }

O uso de puntos de control é outro fluxo de traballo que axuda aos axentes en tarefas de longa duración. O patrón de puntos de control procede da programación por lotes. Cando un script procesa unha lista longa, escribe cada resultado no disco en canto o ten, en lugar de gardalo todo na memoria ata o final. Se o script falla ou atopa erros a medio camiño, non se perde nada: a seguinte execución le o que xa se gardou e continúa desde onde o deixou, e só reintenta os elementos que fallaron.

Noutra tarefa de WANDR, o axente tivo que cribar os perfís de 188 enxeñeiros. Cargou o patrón de punto de control para rexistrar cada resultado mentres traballaba. A primeira pasada extraeu 160 perfís, pero fallou en 28. Cando o axente volveu executar o script, omitiu os perfís que xa estaban rexistrados e reintentou só os 28 restantes. Sen o punto de control, un só rexistro defectuoso obrigaría a obter de novo os 188.Extracto de Python adaptado; omítense as páxinas de entrada, a instrución de cribado, o esquema e as importacións; os nomes das funcións 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}],
        )

O punto de control rexistra os resultados correctos; non inicia reintentos. Incluír a instrución e o esquema na clave garante que, se cambian os criterios de cribado, se volvan procesar os elementos.

Non todas as probas deron lugar a melloras de calidade e eficiencia. Avaliouse a precarga de todas as skills no axente antes de que comezase a súa tarefa. En BrowseComp e DSQA, a precarga aumentou o custo nun 13 %. En WANDR, onde as traxectorias de investigación máis longas fan que o contido recuperado represente unha proporción maior dos tokens de entrada, a precarga tamén reduce as puntuacións. Estes resultados respaldaron que se seguise empregando a revelación progresiva.

A medida que avanzan as capacidades dos modelos, tamén cambia o mellor modelo para cada nivel de esforzo. Perplexity emprega un bucle de investigación automatizado que supervisa os anuncios e a dispoñibilidade de novos modelos. As avaliacións inícianse en canto un modelo pasa a estar accesible.

Cando se publica un novo modelo, un axente automatizado sométeo ao harness de avaliación. Percorre distintos valores de esforzo de razoamento, orzamentos de pasos e de chamadas a ferramentas e configuracións de ferramentas, e puntúa cada execución en calidade e custo fronte aos niveis de esforzo actuais. Cando unha execución empeora, o axente investiga o motivo, axusta a configuración e volve executar a avaliación. Un candidato só substitúe o modelo actual cando gaña en calidade co mesmo custo ou cun custo inferior.

Os benchmarks públicos son útiles, pero as súas puntuacións non sempre se corresponden co rendemento en tarefas do mundo real. Por exemplo, o gráfico seguinte mostra un modelo candidato que obtivo 13,3 puntos máis que a referencia en BrowseComp, pero que quedou moi por debaixo das referencias correspondentes en tarefas internas de investigación empresarial, xurídica e financeira.

Un só axente só pode abarcar un número limitado de fontes nun bucle. Nas tarefas complexas, varios axentes traballan en paralelo de forma coordinada, e cada un encárgase dunha parte diferente do problema.

O axente principal é o orquestrador. Chama a spawn_agent para crear axentes fillos e asígnalle a cada un unha tarefa específica e concreta. Cada fillo executa o seu propio bucle de investigación cun contexto separado e usa o seu propio modelo, as súas ferramentas e o seu orzamento de pasos. Os fillos informan dos seus resultados ao axente pai, que pode enviarlle a un fillo unha nova tarefa de seguimento ou comprobar o seu progreso. O orquestrador e os seus fillos intercambian mensaxes para compartir evidencias, sinalar bloqueos e axustar os seguintes pasos. A medida que chega nova información, o orquestrador afina as asignacións e, cando o traballo remata, combina os resultados nunha única resposta.

A Agent API admite roles de axente predefinidos, e o orquestrador pode crear axentes fillos con instrucións personalizadas.

O nivel de esforzo ultra executa tres axentes en paralelo nunha tarefa. Cada axente investiga de forma independente a tarefa completa, o que dá lugar a evidencias diferentes. Un cuarto axente combina as súas conclusións, elimina duplicados e redacta a resposta final.

En WANDR, ultra obtén un 85,9 % a 21,71 $ por tarefa. É a puntuación máis alta entre as configuracións probadas.

Os niveis de esforzo avalíanse e mellóranse continuamente. O nivel que seleccionan os usuarios determina canta investigación recibe unha tarefa e canto custará. Os orzamentos de pasos e de chamadas a ferramentas, con recordatorios a medida que se esgotan, manteñen as solicitudes dentro do orzamento. A compactación, a extracción e uns fragmentos mellores manteñen o contexto centrado nas evidencias. As skills adaptan o fluxo de traballo á tarefa, e os axentes en paralelo amplían o que pode abarcar un só bucle. Un bucle de avaliación automatizado só admite un novo modelo cando mellora a calidade da investigación co mesmo custo.

Cada nivel de esforzo seguirá evolucionando a medida que novos modelos e configuracións demostren o seu valor na avaliación. Ao chamar un nivel polo seu nome, incorpóranse automaticamente esas melloras; fixar unha versión mantén unha configuración inalterada.

Proba a Agent API e compara os niveis de esforzo coas túas propias cargas de traballo. Consulta os detalles dos niveis de esforzo na nosa documentación sobre o esforzo da Agent API.

O custo da investigación

Control do orzamento de investigación

Xestión do contexto

Compactación

Obter só o que importa

Busca web focalizada

Selección do fluxo de traballo correcto

Selección de modelos

Escalado multiaxente

Próximos pasos