Melhorias em todos os níveis de esforço da Agent API

Os níveis de esforço da Perplexity Agent API permitem aos programadores escolher o equilíbrio entre custo, velocidade e profundidade de pesquisa para cada tarefa. A partir de hoje, todos os níveis de esforço custam menos por consulta, com uma qualidade de pesquisa superior ou inalterada. Está disponível um novo nível ultra para a pesquisa mais abrangente e exaustiva. Qualquer pedido que selecione o nível pelo nome, como effort="fast", recebe automaticamente a configuração atualizada.

Criar um agente de pesquisa implica escolher o equilíbrio certo entre custo, velocidade e profundidade para cada tarefa. Os níveis de esforço da Agent API tomam essa decisão pelo utilizador. Cada nível é uma configuração agregada que define o modelo, o orçamento de passos, as definições de pesquisa e as ferramentas para um tipo de tarefa específico. A Perplexity avalia e atualiza cada nível ao longo do tempo para oferecer a melhor pesquisa com um custo igual ou inferior ao atual.

Estes ganhos resultaram de dois tipos de alteração. Os orçamentos, a gestão do contexto e a extração reduziram o custo de cada execução, e as skills, a seleção de modelos e os agentes em paralelo aumentaram ou mantiveram a qualidade da resposta.

O desempenho do nível medium melhorou de 55% para 77% no BrowseComp e no DSQA, enquanto os custos diminuíram quase 90%. O BrowseComp e o DSQA são benchmarks de pesquisa públicos; o WANDR é o benchmark da Perplexity para tarefas de pesquisa longas e com múltiplas entidades. O xhigh realiza trabalho agêntico, como executar código numa sandbox, manter longos ciclos de utilização de ferramentas e trabalhar com muitas fontes em simultâneo. O xhigh manteve a sua pontuação no WANDR em 76,5%, com um custo de cerca de 25% do da configuração de agosto de 2026.

Um pedido de pesquisa aprofundada pode executar dezenas de pesquisas, ler centenas de páginas e verificar evidências antes de responder. Cada uma dessas ações acrescenta tokens ao contexto e dólares à fatura. Sem limites, um agente continua a realizar ações que aumentam o custo e sobrecarregam o contexto sem melhorar a resposta. Cinco fatores determinam a maior parte desse custo:

Atribuição de orçamento. Os agentes com um orçamento definido podem esgotar os passos e terminar a execução antecipadamente, antes de concluírem a tarefa. Por outro lado, os agentes sem um orçamento fixo podem continuar a ser executados, gerando custos sem melhorar a resposta final.
Sobrecarga de contexto. Os resultados de pesquisa e as páginas obtidas contêm as evidências, mas, sem controlo, a janela de contexto pode encher-se rapidamente de informações irrelevantes. As janelas de contexto transportam custos de passo para passo, e janelas sobrecarregadas podem reduzir o desempenho do agente.
Seleção do fluxo de trabalho. Tarefas diferentes exigem abordagens diferentes. Uma pesquisa de um único facto, uma pergunta com vários saltos e um levantamento alargado de fontes exigem, cada um, um fluxo de trabalho diferente. Quando escolhe por si próprio, um modelo opta frequentemente por um fluxo de trabalho ineficiente. Detalhar todas as estratégias disponíveis no prompt do agente não resolve o problema. As instruções adicionais são transportadas como tokens em cada passo e o modelo segue cada uma delas de forma menos fiável ao longo do tempo.
Seleção de modelos. Mudar para um modelo maior pode não proporcionar uma melhoria de desempenho proporcional ao custo adicional. Os novos modelos chegam acompanhados de manchetes e pontuações de benchmarks publicadas. No entanto, os ganhos nos benchmarks podem estar contaminados ou refletir sobreajuste do modelo. Sem avaliação em tarefas reais, uma mudança de modelo pode aumentar os custos sem aumentar a qualidade.
Escalabilidade multiagente. Um único agente consegue pesquisar, ler e raciocinar sobre um número finito de fontes por execução. Executar vários agentes em paralelo melhora a qualidade nas tarefas mais exigentes, mas também aumenta os custos e introduz complexidade se não for gerido corretamente.

A resolução de cada um destes desafios reduziu os custos de cada nível de esforço sem reduzir o desempenho.

Cada nível de esforço tem um orçamento de pesquisa fixo com três componentes:

Limites de passos: o número de turnos que o agente pode realizar
Chamadas de ferramentas: um limite ao número total de chamadas de ferramentas num pedido. Um único passo pode emitir várias chamadas para várias ferramentas em simultâneo, pelo que um limite de passos, por si só, não controla quantas ações ocorrem num passo.
Lembretes de orçamento: avisos periódicos sobre quantos passos restam, para que o agente possa definir prioridades e deixar margem para redigir a resposta, em vez de esgotar o orçamento a meio da tarefa.

O orçamento é o compromisso central: mais passos significam melhores respostas, e cada passo gera custos. Com o openai/gpt-6-luna, aumentar o limite de passos de 1 para 15 eleva a precisão no BrowseComp + DSQA de 41% para 80%, enquanto o custo por consulta sobe de 0,0017 US$ para 0,0152 US$: cerca de 9 vezes o custo para cerca de 2 vezes a pontuação.

Um limite de passos, por si só, não controla o custo da pesquisa. Com o mesmo orçamento de cinco passos, o openai/gpt-6.1-terra faz mais chamadas de ferramentas do que o openai/gpt-6-luna, porque os modelos mais capazes tendem a emitir várias chamadas num único passo. Os níveis de esforço limitam tanto as chamadas de ferramentas como os passos. Para estes modelos, o limite de chamadas de ferramentas é tão importante como o limite de passos.

Cada nível de esforço ajusta estes limites, mas o agente também precisa de saber quantos passos e ações lhe restam para concluir o pedido. Sem essa informação, pode esgotar os passos ou as ações e ser forçado a responder antes de a pesquisa estar concluída. O orçamento é indicado no início da execução e os lembretes chegam à medida que o agente se aproxima dos seus limites, para que haja margem para verificar e entregar os resultados. No nível high, os lembretes abrangem tanto o orçamento de passos como o orçamento de chamadas de ferramentas.

Dois agentes, um com lembrete de orçamento e outro sem, foram testados numa tarefa do BrowseComp para identificar uma série de televisão dos anos 90 a partir de três biografias de membros do elenco. O agente com lembrete encontrou a resposta correta utilizando 13 dos 40 passos do orçamento. O agente sem lembrete de orçamento utilizou os 40 passos e não encontrou a resposta correta. O ciclo desse agente terminou inesperadamente e o modelo não tinha conhecimento do orçamento de pesquisa restante. Os lembretes mantêm os agentes focados e ajudam-nos a dar prioridade aos recursos restantes de forma eficaz.

As tarefas de pesquisa de longa duração enchem a janela de contexto do modelo com resultados de pesquisa, páginas obtidas e notas intermédias. Quando fica cheia, o agente tem de parar de trabalhar.

A compactação permite que as execuções longas continuem a funcionar sem encher a janela de contexto. Quando o contexto excede um limiar, o agente substitui o trabalho feito até ao momento por um resumo mais curto do que encontrou e do que falta fazer e, depois, continua.

A compactação mantém sempre três elementos no contexto: o prompt de sistema, o pedido original e quaisquer skills que o agente já tenha carregado. Após cada compactação, o agente recebe duas instruções curtas. A primeira instrução é: «Continue a trabalhar até a tarefa estar concluída.» Isto impede que o agente trate o resumo como um ponto de paragem. A segunda instrução indica ao agente quantas compactações já ocorreram, para que possa planear as restantes tarefas de pesquisa. As execuções longas mantêm à vista o objetivo e o plano originais, e o custo dos ciclos longos diminui sem perda de qualidade.

Cada página que o agente lê é acrescentada ao seu contexto, e o agente transporta-a em todos os passos seguintes. Uma página web inclui informações não relacionadas com a pergunta, como navegação, texto padrão e outros conteúdos.

Em vez de entregar ao agente uma página inteira, o fetch_url executa primeiro uma passagem de extração. O texto da página é enviado para um modelo mais pequeno juntamente com a tarefa atual do agente. O modelo devolve apenas as passagens relevantes, reproduzidas na íntegra para que o agente as possa citar. Durante uma avaliação, uma página de 5561 tokens foi reduzida para 293 tokens, libertando espaço para mais contexto relevante.

A utilização de fetch_url com extração no nível de esforço high reduziu os tokens de entrada por consulta em cerca de 50%. A extração também melhorou o desempenho nos benchmarks, atingindo 88,0% a 0,073 US$ por consulta, em comparação com 83,5% a 0,094 US$ sem extração.

A pesquisa na web é fundamental para todos os pedidos de pesquisa de agentes. Foram feitas três alterações à forma como os agentes pesquisam:

Mais contexto por pesquisa: Cada pesquisa devolve agora até 4 mil tokens de resultados, em vez de 2 mil. O agente encontra mais depressa o que precisa, o que resulta em menos pesquisas e num custo mais baixo.

Um novo motor de excertos: Os resultados de pesquisa recebem excertos que correspondem melhor à consulta, para que o agente não fique sobrecarregado com texto irrelevante.
Pesquisa rápida: A 1,00 US$ por 1000 pedidos, a Fast Search reduz tanto o custo como a latência de cada chamada de pesquisa.

A equipa da Perplexity Search melhora continuamente a qualidade da recuperação numa vasta gama de tarefas. As atualizações recentes trouxeram ganhos em código, documentação para programadores, páginas de referência e conteúdos jurídicos e regulamentares.

Algumas tarefas exigem que muitas pesquisas sejam executadas em paralelo; outras precisam de uma leitura atenta de alguns documentos longos.

No entanto, carregar todos os fluxos de trabalho no prompt de sistema do agente acrescenta sobrecarga de contexto e pode levar o modelo a ter um desempenho inferior em tarefas simples. Em vez disso, as skills estão organizadas numa árvore com divulgação progressiva. O modelo carrega as skills e instruções relevantes à medida que trabalha, deixando de fora do contexto as informações não relacionadas. Cada skill custa apenas o seu nome e descrição até o modelo decidir que é adequada à tarefa e carregá-la; nesse momento, as instruções completas são acrescentadas ao contexto e o modelo segue o fluxo de trabalho prescrito.

Para medir o contributo de cada Skill, cada uma é removida, uma de cada vez, para comparar a qualidade e o custo em tarefas nas quais o agente de referência carregou essa Skill. Estas ablações mostram que fluxos de trabalho ajudam o agente e de que forma afetam a eficiência da pesquisa.

As execuções do benchmark WANDR abaixo demonstram agentes a escolher os fluxos de trabalho corretos para tarefas específicas. As orientações wide-search e fanout foram carregadas em todas as tarefas, refletindo a necessidade de investigar várias entidades. A skill people-search foi carregada em apenas 6% das tarefas, e apenas quando as perguntas envolviam pessoas.

Ao testar outra tarefa do WANDR, o agente carregou a skill people-search com um padrão de fanout para encontrar engenheiros de inferência em Londres. Expandiu 39 termos de funções em 117 consultas e, depois, juntou os resultados da primeira passagem em 43 perfis únicos para triagem adicional. A skill people-search orientou o agente nesta expansão sem acrescentar contexto irrelevante. O excerto abaixo foi adaptado do script do agente; os nomes das funções auxiliares são 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,
            }

A utilização de pontos de controlo é outro fluxo de trabalho que ajuda os agentes em tarefas de longa duração. O padrão de pontos de controlo provém da programação em lote. Quando um script processa uma lista longa, escreve cada resultado no disco assim que o obtém, em vez de manter tudo na memória até ao fim. Se o script falhar ou encontrar erros a meio, nada se perde: a execução seguinte lê o que já foi guardado e continua a partir do ponto onde ficou, repetindo apenas os itens que falharam.

Noutra tarefa do WANDR, o agente teve de fazer a triagem de 188 perfis de engenheiros. Carregou o padrão de ponto de controlo para registar cada resultado à medida que trabalhava. A primeira passagem extraiu 160 perfis, mas falhou em 28. Quando o agente voltou a executar o script, ignorou os perfis que já tinham sido registados e repetiu apenas os 28 restantes. Sem o ponto de controlo, um único registo com erros obrigaria a obter novamente os 188.Excerto de Python adaptado; as páginas de entrada, a instrução de triagem, o esquema e as importações foram omitidos; os nomes das funções auxiliares são 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 ponto de controlo regista os resultados bem-sucedidos; não lança novas tentativas. Incluir a instrução e o esquema na chave garante que a alteração dos critérios de triagem desencadeia um novo processamento.

Nem todos os testes resultaram em ganhos de qualidade e eficiência. Foi avaliado o pré-carregamento de todas as skills no agente antes de este iniciar a tarefa. No BrowseComp e no DSQA, o pré-carregamento aumentou o custo em 13%. No WANDR, onde trajetórias de pesquisa mais longas fazem com que o conteúdo obtido represente uma maior parte dos tokens de entrada, o pré-carregamento também reduz as pontuações. Estes resultados sustentaram a continuação da utilização da divulgação progressiva.

À medida que as capacidades dos modelos avançam, o melhor modelo para cada nível de esforço também muda. A Perplexity utiliza um ciclo de pesquisa automatizado que monitoriza os anúncios e a disponibilidade de novos modelos. As avaliações são iniciadas assim que um modelo fica acessível.

Quando é lançado um novo modelo, um agente automatizado submete-o ao harness de avaliação. Percorre diferentes valores de esforço de raciocínio, orçamentos de passos e de chamadas de ferramentas e configurações de ferramentas, e pontua cada execução quanto à qualidade e ao custo em comparação com os níveis de esforço atuais. Quando uma execução regride, o agente investiga a causa, ajusta as definições e volta a executar a avaliação. Um candidato só substitui o modelo atual quando é superior em qualidade com um custo igual ou inferior.

Os benchmarks públicos são úteis, mas as suas pontuações nem sempre se traduzem em tarefas do mundo real. Por exemplo, o gráfico abaixo mostra um modelo candidato que obteve 13,3 pontos acima da linha de base no BrowseComp, mas ficou bem abaixo das linhas de base correspondentes em tarefas internas de pesquisa empresarial, jurídica e financeira.

Um único agente só consegue abranger um número limitado de fontes num ciclo. Em tarefas complexas, vários agentes trabalham em paralelo, cada um a coordenar uma parte diferente do problema.

O agente principal é o orquestrador. Chama spawn_agent para criar agentes filhos e atribui a cada um uma tarefa específica e focada. Cada agente filho executa o seu próprio ciclo de pesquisa com um contexto separado, utilizando o seu próprio modelo, ferramentas e orçamento de passos. Os agentes filhos comunicam os resultados ao agente pai, que pode enviar a um agente filho uma tarefa de seguimento ou verificar o seu progresso. O orquestrador e os agentes filhos trocam mensagens para partilhar evidências, assinalar bloqueios e ajustar os próximos passos. À medida que chegam novas informações, o orquestrador refina as tarefas atribuídas e, quando o trabalho está concluído, combina os resultados numa única resposta.

A Agent API suporta funções de agente predefinidas, e o orquestrador pode criar agentes filhos com instruções personalizadas.

O nível de esforço ultra executa três agentes numa tarefa em paralelo. Cada agente pesquisa de forma independente a tarefa completa, obtendo evidências diferentes. Um quarto agente junta as conclusões, elimina duplicados e redige a resposta final.

No WANDR, o ultra obtém 85,9% a 21,71 US$ por tarefa. Alcança a pontuação mais elevada entre as configurações testadas.

Os níveis de esforço são continuamente avaliados e melhorados. O nível que os utilizadores selecionam determina quanta pesquisa uma tarefa recebe e quanto vai custar. Os orçamentos de passos e de chamadas de ferramentas, com lembretes à medida que se esgotam, mantêm os pedidos dentro do orçamento. A compactação, a extração e melhores excertos mantêm o contexto focado nas evidências. As skills adequam o fluxo de trabalho à tarefa, e os agentes em paralelo alargam o que um único ciclo consegue abranger. Um ciclo de avaliação automatizado só admite um novo modelo quando este melhora a qualidade da pesquisa com o mesmo custo.

Cada nível de esforço continuará a evoluir à medida que novos modelos e configurações derem provas na avaliação. Chamar um nível pelo nome incorpora automaticamente essas melhorias; fixar uma versão mantém uma configuração inalterada.

Experimente a Agent API e compare os níveis de esforço nas suas próprias cargas de trabalho. Encontre os detalhes dos níveis de esforço na nossa documentação sobre o esforço da Agent API.

O custo da pesquisa

Controlar o orçamento de pesquisa

Gestão do contexto

Compactação

Obter apenas o que importa

Pesquisa web focada

Selecionar o fluxo de trabalho correto

Seleção de modelos

Escalabilidade multiagente

Próximos passos