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

Os níveis de esforço da Perplexity Agent API permitem que os desenvolvedores escolham 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 qualidade de pesquisa superior ou inalterada. Um novo nível ultra está disponível para as pesquisas mais abrangentes e completas. Qualquer solicitação que selecione o nível pelo nome, como effort="fast", recebe a configuração atualizada automaticamente.

Criar um agente de pesquisa significa 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 usuário. Cada nível é uma configuração integrada que define o modelo, o orçamento de etapas, as configurações de busca e as ferramentas para um tipo específico de tarefa. A Perplexity avalia e atualiza cada nível ao longo do tempo para oferecer a melhor pesquisa pelo custo atual ou abaixo dele.

Esses ganhos vieram de dois tipos de mudança. Orçamentos, gerenciamento de contexto e extração reduziram o custo de cada execução, enquanto Skills, seleção de modelos e agentes paralelos aumentaram ou mantiveram a qualidade da resposta.

O desempenho do medium melhorou de 55% para 77% no BrowseComp e no DSQA, enquanto os custos caíram quase 90%. BrowseComp e DSQA são benchmarks públicos de pesquisa; 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 em uma sandbox, sustentar longos loops de uso de ferramentas e trabalhar com muitas fontes ao mesmo tempo. O xhigh manteve sua pontuação no WANDR em 76,5%, operando a cerca de 25% do custo da configuração de agosto de 2026.

Uma solicitação de Pesquisa profunda pode executar dezenas de buscas, ler centenas de páginas e verificar evidências antes de responder. Cada uma dessas ações adiciona tokens ao contexto e dólares à conta. Sem limites, um agente continua realizando ações que aumentam o custo e sobrecarregam o contexto sem melhorar a resposta. Cinco fatores respondem pela maior parte desse custo:

Alocação de orçamento. Agentes com um orçamento definido podem ficar sem etapas e encerrar a execução antes de concluir a tarefa. Por outro lado, agentes sem um orçamento fixo podem continuar em execução, gerando custos sem melhorar a resposta final.
Sobrecarga de contexto. Os resultados de busca e as páginas obtidas trazem as evidências, mas, sem controle, a janela de contexto pode se encher rapidamente de informações irrelevantes. As janelas de contexto carregam custos de uma etapa para outra, e janelas sobrecarregadas podem reduzir o desempenho do agente.
Seleção de fluxo de trabalho. Tarefas diferentes exigem abordagens diferentes. Uma consulta de um único fato, uma pergunta com múltiplos saltos e um levantamento amplo de fontes exigem, cada um, um fluxo de trabalho diferente. Quando escolhe sozinho, um modelo muitas vezes opta por um fluxo de trabalho ineficiente. Detalhar todas as estratégias disponíveis no prompt do agente não resolve isso. As instruções extras são carregadas como tokens em cada etapa, e o modelo segue cada uma delas com menos confiabilidade ao longo do tempo.
Seleção de modelos. Mudar para um modelo maior pode não trazer uma melhoria de desempenho proporcional ao custo extra. Novos modelos chegam com manchetes e pontuações de benchmark publicadas. No entanto, os ganhos em benchmarks podem estar contaminados ou refletir overfitting do modelo. Sem avaliação em tarefas reais, uma troca de modelo pode aumentar os custos sem aumentar a qualidade.
Escalonamento multiagente. Um único agente consegue buscar, 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 bem gerenciado.

Resolver cada um desses desafios reduziu os custos de todos os níveis 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 etapas: o número de turnos que o agente pode realizar
Chamadas de ferramentas: um limite para o número total de chamadas de ferramentas em uma solicitação. Uma única etapa pode emitir várias chamadas para diversas ferramentas ao mesmo tempo, então um limite de etapas, sozinho, não controla quantas ações ocorrem dentro de uma etapa.
Lembretes de orçamento: avisos periódicos sobre quantas etapas restam, para que o agente possa priorizar e reservar espaço para escrever a resposta, em vez de esgotar o orçamento no meio da tarefa.

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

Um limite de etapas, sozinho, não controla o custo da pesquisa. Com o mesmo orçamento de cinco etapas, o openai/gpt-6.1-terra faz mais chamadas de ferramentas do que o openai/gpt-6-luna, porque modelos mais capazes tendem a emitir várias chamadas em uma única etapa. Os níveis de esforço limitam tanto as chamadas de ferramentas quanto as etapas. Para esses modelos, o limite de chamadas de ferramentas importa tanto quanto o limite de etapas.

Cada nível de esforço ajusta esses limites, mas o agente também precisa saber quantas etapas e ações ainda restam para atender à solicitação. Sem essa informação, ele pode ficar sem etapas ou ações e ser forçado a responder antes de concluir a pesquisa. O orçamento é informado no início da execução, e os lembretes chegam à medida que o agente se aproxima dos limites, para que haja espaço para verificar e entregar os resultados. No nível high, os lembretes abrangem tanto o orçamento de etapas quanto o de chamadas de ferramentas.

Dois agentes, um com lembrete de orçamento e outro sem, foram testados em uma tarefa do BrowseComp que consistia em identificar uma série de TV da década de 1990 a partir de três biografias do elenco. O agente com lembrete encontrou a resposta correta usando 13 das 40 etapas do orçamento. O agente sem lembrete de orçamento usou todas as 40 etapas e não encontrou a resposta correta. O loop desse agente terminou de forma inesperada, e o modelo não sabia quanto restava do orçamento de pesquisa. Os lembretes mantêm os agentes focados e os ajudam a priorizar os recursos restantes de forma eficaz.

Tarefas de pesquisa de longa duração enchem a janela de contexto do modelo com resultados de busca, páginas obtidas e anotações intermediárias. Quando ela fica cheia, o agente precisa parar de trabalhar.

A compactação mantém as execuções longas funcionando sem encher a janela de contexto. Quando o contexto ultrapassa um limite, o agente substitui o trabalho feito até então por um resumo mais curto do que encontrou e do que falta fazer e, em seguida, continua.

A compactação sempre mantém três itens no contexto: o prompt do sistema, a solicitação original e todas as Skills que o agente já carregou. Após cada compactação, o agente recebe duas instruções curtas. A primeira é: “Continue trabalhando até que a tarefa esteja concluída.” Isso impede que o agente trate o resumo como um ponto de parada. A segunda informa ao agente quantas compactações já ocorreram, para que ele possa planejar as tarefas de pesquisa restantes. As execuções longas mantêm à vista o objetivo e o plano originais, e o custo dos loops longos diminui sem redução de qualidade.

Cada página que o agente lê é adicionada ao seu contexto, e o agente a carrega em todas as etapas seguintes. Uma página da web inclui informações não relacionadas à pergunta, como navegação, textos padronizados e outros conteúdos.

Em vez de entregar ao agente uma página inteira, o fetch_url primeiro executa uma passagem de extração. O texto da página é enviado a um modelo menor, junto com a tarefa atual do agente. O modelo retorna apenas as passagens relevantes, citadas literalmente para que o agente possa referenciá-las. Durante uma avaliação, uma página de 5.561 tokens foi reduzida a 293 tokens, liberando espaço para mais contexto relevante.

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

Buscar na web é essencial para toda solicitação de pesquisa de um agente. Foram feitas três mudanças na forma como os agentes buscam:

Mais contexto por busca: cada busca agora retorna até 4 mil tokens de resultados, em vez de 2 mil. O agente encontra o que precisa mais rápido, o que resulta em menos buscas e menor custo.

Um novo mecanismo de trechos: os resultados de busca recebem trechos mais alinhados à consulta, para que o agente não fique sobrecarregado com texto irrelevante.
Busca rápida: a US$ 1,00 por mil solicitações, a Fast Search reduz tanto o custo quanto a latência de cada chamada de busca.

A equipe do Perplexity Search melhora continuamente a qualidade da recuperação em uma ampla variedade de tarefas. Atualizações recentes trouxeram ganhos em código, documentação para desenvolvedores, páginas de referência e conteúdo jurídico e regulatório.

Algumas tarefas exigem muitas buscas executadas em paralelo; outras exigem a leitura atenta de alguns documentos longos.

No entanto, carregar todos os fluxos de trabalho no prompt do sistema do agente adiciona sobrecarga de contexto e pode fazer o modelo ter um desempenho inferior em tarefas simples. Em vez disso, as Skills são organizadas em uma árvore com divulgação progressiva. O modelo carrega as Skills e instruções relevantes conforme trabalha, deixando informações não relacionadas fora do contexto. Cada Skill custa apenas seu nome e sua descrição até que o modelo decida que ela se encaixa na tarefa e a carregue; nesse momento, as instruções completas são adicionadas ao contexto e o modelo segue o fluxo de trabalho prescrito.

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

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

Ao testar outra tarefa do WANDR, o agente carregou a Skill de busca de pessoas com um padrão de fanout para encontrar engenheiros de inferência em Londres. Ele expandiu 39 termos de cargo em 117 consultas e, em seguida, mesclou os resultados da primeira passagem em 43 perfis únicos para triagem adicional. A Skill de busca de pessoas guiou o agente nessa expansão sem adicionar contexto irrelevante. O trecho 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,
            }

O checkpointing é outro fluxo de trabalho que ajuda os agentes em tarefas de longa duração. O padrão de checkpointing vem da programação em lote. Quando um script processa uma lista longa, ele grava cada resultado em disco assim que o obtém, em vez de manter tudo na memória até o fim. Se o script falhar ou encontrar erros no meio do caminho, nada se perde: a próxima execução lê o que já foi salvo e continua de onde parou, tentando novamente apenas os itens que falharam.

Em outra tarefa do WANDR, o agente precisou fazer a triagem dos perfis de 188 engenheiros. Ele carregou o padrão de checkpoint para registrar cada resultado à medida que trabalhava. A primeira passagem extraiu 160 perfis, mas falhou em 28. Quando o agente executou o script novamente, ele pulou os perfis que já haviam sido registrados e tentou novamente apenas os 28 restantes. Sem o checkpoint, um único registro com problema exigiria buscar todos os 188 novamente.Trecho adaptado em Python; páginas de entrada, instrução de triagem, schema e imports 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 checkpoint registra os resultados bem-sucedidos; ele não inicia novas tentativas. Incluir a instrução e o schema na chave garante que critérios de triagem alterados acionem um novo processamento.

Nem todos os testes resultaram em ganhos de qualidade e eficiência. Também foi avaliado o pré-carregamento de todas as Skills no agente antes de ele 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 recuperado represente uma parcela maior dos tokens de entrada, o pré-carregamento também reduz as pontuações. Esses resultados sustentaram o uso contínuo 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 usa um loop de pesquisa automatizado que monitora anúncios e a disponibilidade de novos modelos. As avaliações são acionadas assim que um modelo se torna acessível.

Quando um novo modelo é lançado, um agente automatizado o submete ao harness de avaliação. Ele varia o esforço de raciocínio, os orçamentos de etapas e de chamadas de ferramentas e as configurações de ferramentas, e pontua cada execução em qualidade e custo em relação aos níveis de esforço atuais. Quando uma execução apresenta regressão, o agente investiga o motivo, ajusta as configurações e executa a avaliação novamente. Um candidato só substitui o modelo atual quando vence em qualidade pelo mesmo custo ou por um custo menor.

Benchmarks públicos são úteis, mas suas pontuações nem sempre se refletem 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 respectivas linhas de base em tarefas internas de pesquisa corporativa, jurídica e financeira.

Um único agente só consegue cobrir um número limitado de fontes em um loop. Em tarefas complexas, vários agentes trabalham em paralelo, cada um cuidando de uma parte diferente do problema.

O agente principal é o orquestrador. Ele chama spawn_agent para criar agentes filhos e atribui a cada um uma tarefa específica e focada. Cada filho executa seu próprio loop de pesquisa com um contexto separado, usando seu próprio modelo, suas próprias ferramentas e seu próprio orçamento de etapas. Os filhos relatam seus resultados ao agente pai, que pode enviar a um filho uma nova atribuição ou verificar seu progresso. O orquestrador e seus filhos trocam mensagens para compartilhar evidências, sinalizar bloqueios e ajustar os próximos passos. À medida que chegam novas informações, o orquestrador refina as atribuições e, quando o trabalho termina, combina os resultados em uma única resposta.

A Agent API oferece suporte a 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 em paralelo em uma tarefa. Cada agente pesquisa a tarefa inteira de forma independente, o que resulta em evidências diferentes. Um quarto agente mescla as descobertas, remove duplicatas e escreve a resposta final.

No WANDR, o ultra atinge 85,9% a US$ 21,71 por tarefa. É a maior pontuação entre as configurações testadas.

Os níveis de esforço são avaliados e aprimorados continuamente. O nível que o usuário seleciona determina quanta pesquisa uma tarefa recebe e quanto ela vai custar. Os orçamentos de etapas e de chamadas de ferramentas, com lembretes à medida que se esgotam, mantêm as solicitações dentro do orçamento. A compactação, a extração e trechos melhores mantêm o contexto focado em evidências. As Skills adequam o fluxo de trabalho à tarefa, e agentes paralelos ampliam o que um único loop consegue cobrir. Um loop de avaliação automatizado só admite um novo modelo quando ele melhora a qualidade da pesquisa pelo mesmo custo.

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

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

O custo da pesquisa

Controle do orçamento de pesquisa

Gerenciamento de contexto

Compactação

Buscar apenas o que importa

Busca na web focada

Como selecionar o fluxo de trabalho correto

Seleção de modelos

Escalonamento multiagente

Próximos passos