Miglioramenti a tutti i livelli di impegno dell'Agent API

I livelli di impegno della Perplexity Agent API consentono agli sviluppatori di scegliere l'equilibrio tra costo, velocità e profondità della ricerca per ogni attività. Da oggi, ogni livello di impegno costa meno per query, con una qualità della ricerca superiore o invariata. È disponibile un nuovo livello ultra per le ricerche più ampie e complete. Qualsiasi richiesta che selezioni il livello per nome, ad esempio effort="fast", riceve automaticamente la configurazione aggiornata.

Creare un agente di ricerca significa scegliere il giusto equilibrio tra costo, velocità e profondità per ogni attività. I livelli di impegno dell'Agent API prendono questa decisione al posto dell'utente. Ogni livello è una configurazione predefinita che stabilisce il modello, il budget di passaggi, le impostazioni di ricerca e gli strumenti per un tipo specifico di attività. Perplexity valuta e aggiorna ogni livello nel tempo per offrire la migliore ricerca a un costo pari o inferiore a quello attuale.

Questi miglioramenti derivano da due tipi di modifiche. Budget, gestione del contesto ed estrazione hanno ridotto il costo di ogni esecuzione, mentre Skill, selezione del modello e agenti paralleli hanno aumentato o mantenuto la qualità della risposta.

Le prestazioni di medium sono passate dal 55% al 77% su BrowseComp e DSQA, mentre i costi sono diminuiti di quasi il 90%. BrowseComp e DSQA sono benchmark di ricerca pubblici; WANDR è il benchmark di Perplexity per attività di ricerca lunghe e su più entità. xhigh svolge lavoro agentico, come eseguire codice in una sandbox, sostenere lunghi cicli di utilizzo degli strumenti e lavorare su molte fonti contemporaneamente. xhigh ha mantenuto il suo punteggio WANDR al 76,5% con un costo pari a circa il 25% di quello della configurazione di agosto 2026.

Una richiesta di Ricerca approfondita può eseguire decine di ricerche, leggere centinaia di pagine e verificare le prove prima di rispondere. Ognuna di queste azioni aggiunge token al contesto e dollari al conto. Senza limiti, un agente continua a compiere azioni che aumentano i costi e affollano il contesto senza migliorare la risposta. Cinque fattori determinano la maggior parte di questi costi:

Allocazione del budget. Gli agenti con un budget stabilito possono esaurire i passaggi e terminare l'esecuzione in anticipo, prima di aver completato l'attività. Al contrario, gli agenti senza un budget fisso possono continuare a funzionare, generando costi senza migliorare la risposta finale.
Overhead del contesto. I risultati di ricerca e le pagine recuperate contengono le prove ma, se non viene controllata, la finestra di contesto può riempirsi rapidamente di informazioni irrilevanti. Le finestre di contesto trasportano costi da un passaggio all'altro e finestre sovraccariche possono ridurre le prestazioni dell'agente.
Selezione del flusso di lavoro. Attività diverse richiedono approcci diversi. La ricerca di un singolo fatto, una domanda multi-hop e un'ampia rassegna di fonti richiedono ciascuna un flusso di lavoro diverso. Se lasciato libero di scegliere, un modello spesso ne sceglie uno inefficiente. Descrivere ogni strategia disponibile nel prompt dell'agente non risolve il problema. Le istruzioni aggiuntive vengono trasportate come token a ogni passaggio e, con il tempo, il modello segue ciascuna di esse in modo meno affidabile.
Selezione del modello. Passare a un modello più grande potrebbe non offrire un miglioramento delle prestazioni commisurato al costo aggiuntivo. I nuovi modelli arrivano accompagnati da annunci altisonanti e punteggi di benchmark pubblicati. Tuttavia, i miglioramenti nei benchmark possono essere contaminati o riflettere l'overfitting del modello. Senza una valutazione su attività reali, un cambio di modello può aumentare i costi senza aumentare la qualità.
Scalabilità multi-agente. Un singolo agente può cercare, leggere e ragionare su un numero finito di fonti per esecuzione. Eseguire più agenti in parallelo migliora la qualità nelle attività più impegnative, ma aumenta anche i costi e introduce complessità se non viene gestito correttamente.

Risolvere ciascuna di queste sfide ha ridotto i costi di ogni livello di impegno senza ridurre le prestazioni.

Ogni livello di impegno ha un budget di ricerca fisso composto da tre elementi:

Limiti di passaggi: il numero di turni che l'agente può compiere
Chiamate agli strumenti: un limite al numero totale di chiamate agli strumenti in una richiesta. Un singolo passaggio può effettuare più chiamate su più strumenti contemporaneamente, quindi un limite di passaggi da solo non controlla quante azioni avvengono all'interno di un passaggio.
Promemoria del budget: avvisi periodici su quanti passaggi restano, così l'agente può stabilire le priorità e lasciare spazio per scrivere la risposta invece di esaurire il budget a metà attività.

Il budget è il compromesso centrale: più passaggi significano risposte migliori, e ogni passaggio comporta dei costi. Con openai/gpt-6-luna, aumentare il limite di passaggi da 1 a 15 porta l'accuratezza su BrowseComp + DSQA dal 41% all'80%, mentre il costo per query sale da 0,0017 $ a 0,0152 $: circa 9 volte il costo per circa il doppio del punteggio.

Un limite di passaggi da solo non controlla il costo della ricerca. Con lo stesso budget di cinque passaggi, openai/gpt-6.1-terra effettua più chiamate agli strumenti di openai/gpt-6-luna, perché i modelli più capaci tendono a effettuare diverse chiamate in un singolo passaggio. I livelli di impegno limitano sia le chiamate agli strumenti sia i passaggi. Per questi modelli, il limite di chiamate agli strumenti conta quanto il limite di passaggi.

Ogni livello di impegno regola questi limiti, ma l'agente deve anche sapere quanti passaggi e azioni gli restano per soddisfare la richiesta. Senza questa informazione, può esaurire i passaggi o le azioni ed essere costretto a rispondere prima che la ricerca sia completa. Il budget viene indicato all'inizio dell'esecuzione e i promemoria arrivano quando l'agente si avvicina ai limiti, così resta spazio per verificare e fornire i risultati. Per high, i promemoria riguardano sia il budget di passaggi sia quello di chiamate agli strumenti.

Due agenti, uno con un promemoria del budget e uno senza, sono stati testati su un'attività di BrowseComp che chiedeva di identificare una serie TV degli anni '90 a partire dalle biografie di tre membri del cast. L'agente con il promemoria ha trovato la risposta corretta usando 13 dei 40 passaggi previsti dal budget. L'agente senza promemoria del budget ha usato tutti i 40 passaggi e non ha trovato la risposta corretta. Il ciclo di quell'agente si è interrotto inaspettatamente e il modello non era consapevole del budget di ricerca rimanente. I promemoria mantengono gli agenti concentrati e li aiutano a dare priorità in modo efficace alle risorse rimanenti.

Le attività di ricerca di lunga durata riempiono la finestra di contesto del modello con risultati di ricerca, pagine recuperate e note intermedie. Una volta che la finestra è piena, l'agente deve smettere di lavorare.

La compattazione consente alle esecuzioni lunghe di continuare a funzionare senza riempire la finestra di contesto. Quando il contesto supera una soglia, l'agente sostituisce il lavoro svolto fino a quel momento con un riepilogo più breve di ciò che ha trovato e di ciò che resta da fare, quindi prosegue.

La compattazione conserva sempre tre elementi nel contesto: il prompt di sistema, la richiesta originale e tutte le Skill che l'agente ha già caricato. Dopo ogni compattazione, l'agente riceve due brevi istruzioni. La prima è: «Continua a lavorare finché l'attività non è completata». Questo impedisce all'agente di considerare il riepilogo come un punto di arresto. La seconda indica all'agente quante compattazioni sono avvenute, in modo che possa pianificare le attività di ricerca rimanenti. Le esecuzioni lunghe mantengono in vista l'obiettivo e il piano originali, e il costo dei cicli lunghi diminuisce senza una riduzione della qualità.

Ogni pagina letta dall'agente si aggiunge al suo contesto, e l'agente se la porta dietro in ogni passaggio successivo. Una pagina web include informazioni non pertinenti alla domanda, come la navigazione, testo standard e altri contenuti.

Invece di passare all'agente un'intera pagina, fetch_url esegue prima una fase di estrazione. Il testo della pagina viene inviato a un modello più piccolo insieme all'attività corrente dell'agente. Il modello restituisce solo i brani pertinenti, riportati alla lettera in modo che l'agente possa citarli. Durante una valutazione, una pagina di 5.561 token è stata ridotta a 293 token, liberando spazio per ulteriore contesto pertinente.

L'uso di fetch_url con l'estrazione al livello di impegno high ha ridotto di circa il 50% i token di input per query. L'estrazione ha anche migliorato le prestazioni nei benchmark, raggiungendo l'88,0% a 0,073 $ per query, rispetto all'83,5% a 0,094 $ senza estrazione.

La ricerca sul web è centrale in ogni richiesta di ricerca degli agenti. Sono state apportate tre modifiche al modo in cui gli agenti effettuano le ricerche:

Più contesto per ricerca: ogni ricerca ora restituisce fino a 4K token di risultati anziché 2K. L'agente trova prima ciò che gli serve, con meno ricerche e costi inferiori.

Un nuovo motore di snippet: i risultati di ricerca ricevono snippet più pertinenti alla query, così l'agente non viene sovraccaricato di testo irrilevante.
Ricerca rapida: a 1,00 $ ogni 1.000 richieste, Fast Search riduce sia il costo sia la latenza di ogni chiamata di ricerca.

Il team di Perplexity Search migliora costantemente la qualità del recupero delle informazioni in un'ampia gamma di attività. I recenti aggiornamenti hanno portato miglioramenti per codice, documentazione per sviluppatori, pagine di riferimento e contenuti legali e normativi.

Alcune attività richiedono molte ricerche eseguite in parallelo; altre richiedono una lettura attenta di pochi documenti lunghi.

Tuttavia, caricare ogni flusso di lavoro nel prompt di sistema dell'agente aggiunge overhead di contesto e può portare il modello a rendere meno nelle attività semplici. Le Skill sono invece organizzate in un albero con divulgazione progressiva. Il modello carica le Skill e le istruzioni pertinenti mentre lavora, lasciando fuori dal contesto le informazioni non correlate. Ogni Skill costa solo il suo nome e la sua descrizione finché il modello non decide che è adatta all'attività e la carica: a quel punto le istruzioni complete vengono aggiunte al contesto e il modello segue il flusso di lavoro prescritto.

Per misurare il contributo delle singole Skill, ogni Skill viene rimossa una alla volta, confrontando qualità e costo sulle attività in cui l'agente di base aveva caricato quella Skill. Queste ablazioni mostrano quali flussi di lavoro aiutano l'agente e come influiscono sull'efficienza della ricerca.

Le esecuzioni del benchmark WANDR riportate di seguito mostrano agenti che scelgono i flussi di lavoro corretti per attività specifiche. Le indicazioni per wide-search e fanout sono state caricate per ogni attività, data la necessità di analizzare più entità. People-search è stata caricata solo per il 6% delle attività, e solo quando le domande riguardavano persone.

Durante il test di un'altra attività WANDR, l'agente ha caricato la Skill people-search con un pattern di fanout per trovare ingegneri di inferenza a Londra. Ha espanso 39 termini relativi al ruolo in 117 query, poi ha unito i risultati della prima elaborazione in 43 profili unici da sottoporre a un'ulteriore selezione. La Skill people-search ha guidato l'agente in questa espansione senza aggiungere contesto irrilevante. L'estratto seguente è adattato dallo script dell'agente; i nomi delle funzioni helper sono illustrativi.

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,
            }

Il checkpointing è un altro flusso di lavoro che aiuta gli agenti nelle attività di lunga durata. Il pattern di checkpointing deriva dalla programmazione batch. Quando uno script elabora un lungo elenco, scrive ogni risultato su disco non appena lo ottiene, invece di tenere tutto in memoria fino alla fine. Se lo script si arresta in modo anomalo o incontra errori a metà, non si perde nulla: l'esecuzione successiva legge ciò che è già stato salvato e riprende da dove si era interrotta, ritentando solo gli elementi non riusciti.

In un'altra attività WANDR, l'agente doveva esaminare i profili di 188 ingegneri. Ha caricato il pattern di checkpoint per registrare ogni risultato man mano che procedeva. La prima elaborazione ha estratto 160 profili, ma non è riuscita su 28. Quando l'agente ha eseguito di nuovo lo script, ha saltato i profili già registrati e ha ritentato solo i 28 rimanenti. Senza il checkpoint, un solo record difettoso avrebbe significato recuperare di nuovo tutti i 188 profili.Estratto Python adattato; pagine di input, istruzione di selezione, schema e import omessi; i nomi delle funzioni helper sono illustrativi.

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}],
        )

Il checkpoint registra i risultati andati a buon fine; non avvia nuovi tentativi. Includere l'istruzione e lo schema nella chiave garantisce che, se i criteri di selezione cambiano, venga avviata una nuova elaborazione.

Non tutti i test hanno portato a miglioramenti di qualità ed efficienza. È stato valutato il precaricamento di tutte le Skill nell'agente prima dell'inizio dell'attività. Su BrowseComp e DSQA, il precaricamento ha aumentato i costi del 13%. Su WANDR, dove le traiettorie di ricerca più lunghe fanno sì che il contenuto recuperato rappresenti una quota maggiore dei token di input, il precaricamento riduce anche i punteggi. Questi risultati hanno confermato la scelta di continuare a usare la divulgazione progressiva.

Con l'avanzare delle capacità dei modelli, cambia anche il modello migliore per ciascun livello di impegno. Perplexity utilizza un ciclo di ricerca automatizzato che monitora gli annunci e la disponibilità di nuovi modelli. Le valutazioni vengono avviate non appena un modello diventa accessibile.

Quando viene rilasciato un nuovo modello, un agente automatizzato lo sottopone all'harness di valutazione. Varia il livello di ragionamento, i budget di passaggi e di chiamate agli strumenti e le configurazioni degli strumenti, e assegna a ogni esecuzione un punteggio di qualità e costo rispetto agli attuali livelli di impegno. Quando un'esecuzione peggiora, l'agente ne indaga le cause, modifica le impostazioni ed esegue di nuovo la valutazione. Un candidato sostituisce il modello attuale solo se lo supera in qualità a un costo pari o inferiore.

I benchmark pubblici sono utili, ma i loro punteggi non sempre si traducono in risultati sulle attività reali. Ad esempio, il grafico qui sotto mostra un modello candidato che ha ottenuto 13,3 punti in più rispetto alla baseline su BrowseComp, ma risultati ben al di sotto delle baseline corrispondenti nelle attività di ricerca interne in ambito aziendale, legale e finanziario.

Un singolo agente può coprire solo un numero limitato di fonti in un ciclo. Per le attività complesse, più agenti lavorano in parallelo, ciascuno coordinandosi su una parte diversa del problema.

L'agente principale è l'orchestratore. Chiama spawn_agent per creare agenti figli e assegna a ciascuno un compito specifico e mirato. Ogni agente figlio esegue il proprio ciclo di ricerca con un contesto separato, usando il proprio modello, i propri strumenti e il proprio budget di passaggi. I figli riportano i risultati all'agente padre, che può inviare a un figlio un incarico successivo o verificarne l'avanzamento. L'orchestratore e i suoi figli si scambiano messaggi per condividere prove, segnalare ostacoli e adattare le azioni successive. Man mano che arrivano nuove informazioni, l'orchestratore perfeziona gli incarichi e, una volta completato il lavoro, combina i risultati in un'unica risposta.

L'Agent API supporta ruoli di agente predefiniti e l'orchestratore può creare agenti figli con istruzioni personalizzate.

Il livello di impegno ultra esegue tre agenti in parallelo su un'attività. Ogni agente ricerca in modo indipendente l'intera attività, ottenendo prove diverse. Un quarto agente unisce i risultati, elimina i duplicati e scrive la risposta finale.

Su WANDR, ultra ottiene l'85,9% a 21,71 $ per attività. È il punteggio più alto tra le configurazioni testate.

I livelli di impegno vengono valutati e migliorati di continuo. Il livello selezionato dagli utenti determina quanta ricerca riceve un'attività e quanto costerà. I budget di passaggi e di chiamate agli strumenti, con promemoria man mano che si esauriscono, mantengono le richieste entro il budget. Compattazione, estrazione e snippet migliori mantengono il contesto concentrato sulle prove. Le Skill adattano il flusso di lavoro all'attività e gli agenti paralleli estendono ciò che un singolo ciclo può coprire. Un ciclo di valutazione automatizzato adotta un nuovo modello solo quando migliora la qualità della ricerca a parità di costo.

Ogni livello di impegno continuerà a evolversi man mano che nuovi modelli e configurazioni daranno prova di sé nelle valutazioni. Richiamando un livello per nome si ottengono automaticamente questi miglioramenti; fissando una versione, la configurazione resta invariata.

Prova l'Agent API e confronta i livelli di impegno sui tuoi carichi di lavoro. Trovi i dettagli sui livelli di impegno nella nostra documentazione sui livelli di impegno dell'Agent API.

Il costo della ricerca

Controllo del budget di ricerca

Gestione del contesto

Compattazione

Recuperare solo ciò che conta

Ricerca web mirata

Selezionare il flusso di lavoro corretto

Selezione del modello

Scalabilità multi-agente

Prossimi passi