Îmbunătățiri pentru fiecare nivel de efort din Agent API

Nivelurile de efort din Perplexity Agent API le permit dezvoltatorilor să aleagă echilibrul dintre cost, viteză și profunzimea cercetării pentru fiecare sarcină. De astăzi, fiecare nivel de efort costă mai puțin per interogare, cu o calitate a cercetării mai ridicată sau neschimbată. Un nou nivel ultra este disponibil pentru cea mai amplă și cuprinzătoare cercetare. Orice solicitare care selectează nivelul după nume, precum effort="fast", primește automat configurația actualizată.

Construirea unui agent de cercetare înseamnă alegerea echilibrului potrivit între cost, viteză și profunzime pentru fiecare sarcină. Nivelurile de efort din Agent API iau această decizie în locul utilizatorului. Fiecare nivel este o configurație predefinită care stabilește modelul, bugetul de pași, setările de căutare și instrumentele pentru un anumit tip de sarcină. Perplexity evaluează și actualizează fiecare nivel în timp, pentru a oferi cea mai bună cercetare la costul actual sau sub acesta.

Aceste câștiguri au provenit din două tipuri de modificări. Bugetele, gestionarea contextului și extragerea au redus costul fiecărei rulări, iar skill-urile, selecția modelului și agenții paraleli au crescut sau au menținut calitatea răspunsului.

Performanța nivelului medium a crescut de la 55% la 77% pe BrowseComp și DSQA, în timp ce costurile au scăzut cu aproape 90%. BrowseComp și DSQA sunt benchmarkuri publice de cercetare; WANDR este benchmarkul Perplexity pentru sarcini de cercetare lungi, cu entități multiple. xhigh execută activități agentice, precum rularea de cod într-un sandbox, menținerea unor bucle lungi de utilizare a instrumentelor și lucrul simultan cu numeroase surse. xhigh și-a menținut scorul WANDR la 76,5%, funcționând la aproximativ 25% din costul configurației din august 2026.

O solicitare de cercetare aprofundată poate rula zeci de căutări, poate citi sute de pagini și poate verifica dovezile înainte de a răspunde. Fiecare dintre aceste acțiuni adaugă tokenuri în context și dolari la factură. Fără limite, un agent continuă să efectueze acțiuni care cresc costul și aglomerează contextul fără a îmbunătăți răspunsul. Cinci factori determină cea mai mare parte a acestui cost:

Alocarea bugetului. Agenții cu un buget stabilit pot rămâne fără pași și își pot încheia rularea prematur, înainte de a-și finaliza sarcina. În schimb, agenții fără un buget fix pot continua să ruleze, generând costuri fără a îmbunătăți răspunsul final.
Costul suplimentar al contextului. Rezultatele căutării și paginile preluate conțin dovezile, dar, dacă nu este ținută sub control, fereastra de context se poate umple rapid cu informații irelevante. Ferestrele de context transportă costuri de la un pas la altul, iar ferestrele supraîncărcate pot reduce performanța agentului.
Selectarea fluxului de lucru. Sarcini diferite necesită abordări diferite. Căutarea unui singur fapt, o întrebare cu mai mulți pași de raționament și o trecere în revistă amplă a surselor necesită fiecare un flux de lucru diferit. Lăsat să aleagă singur, un model alege adesea unul ineficient. Detalierea tuturor strategiilor disponibile în promptul agentului nu rezolvă această problemă. Instrucțiunile suplimentare sunt transportate ca tokenuri la fiecare pas, iar modelul le urmează pe fiecare tot mai puțin fiabil în timp.
Selecția modelului. Trecerea la un model mai mare poate să nu aducă o îmbunătățire a performanței pe măsura costului suplimentar. Modelele noi apar însoțite de titluri de presă și de scoruri publicate în benchmarkuri. Totuși, câștigurile din benchmarkuri pot fi contaminate sau pot reflecta supraadaptarea modelului. Fără evaluare pe sarcini reale, o schimbare de model poate crește costurile fără a crește calitatea.
Scalare multi-agent. Un singur agent poate căuta, citi și analiza un număr finit de surse per rulare. Rularea mai multor agenți în paralel îmbunătățește calitatea la cele mai solicitante sarcini, dar crește și costurile și introduce complexitate dacă nu este gestionată corect.

Rezolvarea fiecăreia dintre aceste provocări a redus costurile pentru fiecare nivel de efort fără a reduce performanța.

Fiecare nivel de efort are un buget fix de cercetare, cu trei componente:

Limite de pași: numărul de ture pe care le poate efectua agentul
Apeluri de instrumente: o limită a numărului total de apeluri de instrumente dintr-o solicitare. Un singur pas poate emite simultan mai multe apeluri către mai multe instrumente, așa că o limită de pași nu controlează, singură, câte acțiuni au loc într-un pas.
Mementouri de buget: notificări periodice despre câți pași mai rămân, astfel încât agentul să poată prioritiza și să lase loc pentru redactarea răspunsului, în loc să rămână fără buget în mijlocul sarcinii.

Bugetul este compromisul central: mai mulți pași înseamnă răspunsuri mai bune, iar fiecare pas generează costuri. Cu openai/gpt-6-luna, creșterea limitei de pași de la 1 la 15 ridică acuratețea pe BrowseComp + DSQA de la 41% la 80%, în timp ce costul per interogare crește de la 0,0017 USD la 0,0152 USD, adică un cost de aproximativ 9 ori mai mare pentru un scor de aproximativ 2 ori mai mare.

O limită de pași nu controlează, singură, costul cercetării. Cu același buget de cinci pași, openai/gpt-6.1-terra face mai multe apeluri de instrumente decât openai/gpt-6-luna, deoarece modelele mai capabile tind să emită mai multe apeluri într-un singur pas. Nivelurile de efort limitează atât apelurile de instrumente, cât și pașii. Pentru aceste modele, limita de apeluri de instrumente contează la fel de mult ca limita de pași.

Fiecare nivel de efort ajustează aceste limite, dar agentul trebuie să știe și câți pași și câte acțiuni îi mai rămân pentru a îndeplini solicitarea. Fără această informație, poate rămâne fără pași sau acțiuni și poate fi forțat să răspundă înainte ca cercetarea să fie completă. Bugetul este comunicat la începutul rulării, iar mementourile apar pe măsură ce agentul se apropie de limite, astfel încât să rămână o marjă pentru verificarea și livrarea rezultatelor. Pentru nivelul high, mementourile acoperă atât bugetul de pași, cât și bugetul de apeluri către instrumente.

Doi agenți, unul cu memento privind bugetul și unul fără, au fost testați pe o sarcină BrowseComp care cerea identificarea unui serial TV din anii 1990 pe baza a trei biografii ale membrilor distribuției. Agentul cu memento a găsit răspunsul corect folosind 13 din cei 40 de pași din buget. Agentul fără memento privind bugetul a folosit toți cei 40 de pași și nu a găsit răspunsul corect. Bucla acelui agent s-a încheiat neașteptat, iar modelul nu cunoștea bugetul de cercetare rămas. Mementourile îi mențin pe agenți concentrați și îi ajută să își prioritizeze eficient resursele rămase.

Sarcinile de cercetare de lungă durată umplu fereastra de context a modelului cu rezultate de căutare, pagini preluate și note intermediare. Odată ce fereastra este plină, agentul trebuie să se oprească.

Compactarea permite rulărilor lungi să continue fără a umple fereastra de context. Când contextul depășește un prag, agentul înlocuiește munca de până atunci cu un rezumat mai scurt despre ce a găsit și ce a mai rămas de făcut, apoi continuă.

Compactarea păstrează întotdeauna trei elemente în context: promptul de sistem, solicitarea inițială și orice skill-uri pe care agentul le-a încărcat deja. După fiecare compactare, agentul primește două instrucțiuni scurte. Prima instrucțiune este: „Continuă să lucrezi până când sarcina este finalizată.” Aceasta împiedică agentul să trateze rezumatul ca pe un punct de oprire. A doua instrucțiune îi spune agentului câte compactări au avut loc, astfel încât să își poată planifica sarcinile de cercetare rămase. Rulările lungi păstrează în vizor obiectivul și planul inițial, iar costul buclelor lungi scade fără o reducere a calității.

Fiecare pagină pe care o citește agentul se adaugă la contextul său, iar agentul o poartă cu el la fiecare pas ulterior. O pagină web include informații care nu au legătură cu întrebarea, precum elemente de navigare, text standard și alt conținut.

În loc să îi ofere agentului o pagină întreagă, fetch_url rulează mai întâi o etapă de extragere. Textul paginii este trimis unui model mai mic, împreună cu sarcina curentă a agentului. Modelul returnează doar pasajele relevante, redate exact, astfel încât agentul să le poată cita. În timpul unei evaluări, o pagină de 5.561 de tokenuri a fost redusă la 293 de tokenuri, eliberând spațiu pentru context relevant suplimentar.

Utilizarea fetch_url cu extragere la nivelul de efort high a redus tokenurile de intrare per interogare cu aproximativ 50%. Extragerea a îmbunătățit și performanța în benchmarkuri, atingând 88,0% la 0,073 USD per interogare, comparativ cu 83,5% la 0,094 USD fără extragere.

Căutarea pe web este esențială pentru fiecare solicitare de cercetare a unui agent. Au fost aduse trei modificări modului în care caută agenții:

Mai mult context per căutare: Fiecare căutare returnează acum până la 4K tokenuri de rezultate, în loc de 2K. Agentul găsește mai repede ce îi trebuie, ceea ce duce la mai puține căutări și la un cost mai mic.

Un nou motor de fragmente: Rezultatele căutării primesc fragmente care se potrivesc mai bine cu interogarea, astfel încât agentul nu este suprasolicitat cu text irelevant.
Căutare rapidă: La 1,00 USD per 1.000 de solicitări, Fast Search reduce atât costul, cât și latența fiecărui apel de căutare.

Echipa Perplexity Search îmbunătățește continuu calitatea regăsirii informațiilor pentru o gamă largă de sarcini. Actualizările recente au adus câștiguri pentru cod, documentația pentru dezvoltatori, paginile de referință, precum și pentru conținutul juridic și de reglementare.

Unele sarcini necesită rularea în paralel a multor căutări; altele necesită citirea atentă a câtorva documente lungi.

Totuși, încărcarea tuturor fluxurilor de lucru în promptul de sistem al agentului adaugă costuri suplimentare de context și poate face ca modelul să aibă performanțe mai slabe la sarcinile simple. În schimb, skill-urile sunt organizate într-un arbore, cu dezvăluire progresivă. Modelul încarcă skill-urile și instrucțiunile relevante pe măsură ce lucrează, lăsând informațiile fără legătură în afara contextului. Fiecare skill costă doar numele și descrierea sa până când modelul decide că se potrivește sarcinii și îl încarcă; în acel moment, instrucțiunile complete sunt adăugate în context, iar modelul urmează fluxul de lucru prescris.

Pentru a măsura contribuția fiecărui skill, skill-urile sunt eliminate pe rând, pentru a compara calitatea și costul la sarcinile în care agentul de referință a încărcat skill-ul respectiv. Aceste ablații arată ce fluxuri de lucru ajută agentul și cum influențează eficiența cercetării.

Rulările din benchmarkul WANDR de mai jos demonstrează cum aleg agenții fluxurile de lucru corecte pentru anumite sarcini. Instrucțiunile wide-search și fanout au fost încărcate pentru fiecare sarcină, reflectând nevoia de a investiga mai multe entități. People-search a fost încărcat doar pentru 6% dintre sarcini și doar atunci când întrebările implicau persoane.

La testarea unei alte sarcini WANDR, agentul a încărcat skill-ul people-search cu un model fanout pentru a găsi ingineri de inferență din Londra. A extins 39 de termeni de rol în 117 interogări, apoi a combinat rezultatele primei treceri în 43 de profiluri unice pentru o selecție ulterioară. Skill-ul people-search a ghidat agentul prin această extindere fără a adăuga context irelevant. Fragmentul de mai jos este adaptat din scriptul agentului; numele funcțiilor auxiliare sunt ilustrative.

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

Salvarea punctelor de control (checkpointing) este un alt flux de lucru care ajută agenții la sarcinile de lungă durată. Acest model provine din programarea batch. Când un script procesează o listă lungă, scrie fiecare rezultat pe disc imediat ce îl obține, în loc să păstreze totul în memorie până la final. Dacă scriptul se blochează sau întâmpină erori pe parcurs, nu se pierde nimic: următoarea rulare citește ce a fost deja salvat și continuă de unde a rămas, reîncercând doar elementele care au eșuat.

Într-o altă sarcină WANDR, agentul a trebuit să analizeze profilurile a 188 de ingineri. A încărcat modelul de punct de control pentru a înregistra fiecare rezultat pe măsură ce lucra. Prima trecere a extras 160 de profiluri, dar a eșuat la 28. Când agentul a rulat din nou scriptul, a omis profilurile deja înregistrate și a reîncercat doar cele 28 rămase. Fără punctul de control, o singură înregistrare defectă ar fi însemnat preluarea din nou a tuturor celor 188.Fragment Python adaptat; paginile de intrare, instrucțiunea de selecție, schema și importurile au fost omise; numele funcțiilor auxiliare sunt ilustrative.

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

Punctul de control înregistrează rezultatele reușite; nu lansează reîncercări. Includerea instrucțiunii și a schemei în cheie asigură că modificarea criteriilor de selecție declanșează reprocesarea.

Nu toate testele au dus la câștiguri de calitate și eficiență. A fost evaluată și preîncărcarea tuturor skill-urilor în agent înainte ca acesta să înceapă sarcina. Pe BrowseComp și DSQA, preîncărcarea a crescut costul cu 13%. Pe WANDR, unde traiectoriile de cercetare mai lungi fac ca conținutul preluat să reprezinte o pondere mai mare din tokenurile de intrare, preîncărcarea reduce și scorurile. Aceste rezultate au susținut utilizarea în continuare a dezvăluirii progresive.

Pe măsură ce capacitățile modelelor avansează, se schimbă și cel mai bun model pentru fiecare nivel de efort. Perplexity folosește o buclă automată de cercetare care monitorizează anunțurile și disponibilitatea modelelor noi. Evaluările sunt declanșate imediat ce un model devine accesibil.

Când este lansat un model nou, un agent automat îl trece prin harness-ul de evaluare. Acesta testează sistematic efortul de raționament, bugetele de pași și de apeluri de instrumente și configurațiile instrumentelor, apoi evaluează fiecare rulare din punctul de vedere al calității și costului, comparativ cu nivelurile de efort actuale. Acolo unde o rulare înregistrează o regresie, agentul investighează cauza, ajustează setările și rulează din nou evaluarea. Un candidat înlocuiește modelul actual doar atunci când câștigă la calitate, la un cost egal sau mai mic.

Benchmarkurile publice sunt utile, dar scorurile lor nu se reflectă întotdeauna în sarcinile din lumea reală. De exemplu, graficul de mai jos arată un model candidat care a obținut un scor cu 13,3 puncte peste valoarea de referință pe BrowseComp, dar mult sub valorile de referință corespunzătoare la sarcinile interne de cercetare din domeniile corporativ, juridic și financiar.

Un singur agent poate acoperi doar un număr limitat de surse într-o buclă. Pentru sarcinile complexe, mai mulți agenți lucrează în paralel, fiecare ocupându-se, în mod coordonat, de o parte diferită a problemei.

Agentul principal este orchestratorul. Acesta apelează spawn_agent pentru a crea agenți copil și atribuie fiecăruia o sarcină specifică și bine delimitată. Fiecare agent copil rulează propria buclă de cercetare, cu un context separat, folosind propriul model, propriile instrumente și propriul buget de pași. Agenții copil își raportează rezultatele agentului părinte, care le poate trimite o sarcină suplimentară sau le poate verifica progresul. Orchestratorul și agenții copil schimbă mesaje pentru a partaja dovezi, a semnala blocaje și a ajusta pașii următori. Pe măsură ce sosesc informații noi, orchestratorul rafinează sarcinile și, când munca este gata, combină rezultatele într-un singur răspuns.

Agent API acceptă roluri de agent predefinite, iar orchestratorul poate crea agenți copil cu instrucțiuni personalizate.

Nivelul de efort ultra rulează trei agenți în paralel pe o sarcină. Fiecare agent cercetează independent întreaga sarcină, obținând dovezi diferite. Un al patrulea agent combină constatările acestora, elimină duplicatele și scrie răspunsul final.

Pe WANDR, ultra obține 85,9% la 21,71 USD per sarcină. Este cel mai mare scor dintre configurațiile testate.

Nivelurile de efort sunt evaluate și îmbunătățite continuu. Nivelul selectat de utilizatori determină câtă cercetare primește o sarcină și cât va costa. Bugetele de pași și de apeluri de instrumente, cu mementouri pe măsură ce se epuizează, mențin solicitările în limitele bugetului. Compactarea, extragerea și fragmentele mai bune mențin contextul concentrat pe dovezi. Skill-urile potrivesc fluxul de lucru cu sarcina, iar agenții paraleli extind ceea ce poate acoperi o singură buclă. O buclă automată de evaluare acceptă un model nou doar atunci când acesta îmbunătățește calitatea cercetării la același cost.

Fiecare nivel de efort va continua să evolueze pe măsură ce modele și configurații noi își dovedesc valoarea în evaluare. Apelarea unui nivel după nume preia automat aceste îmbunătățiri; fixarea unei versiuni menține o configurație neschimbată.

Încercați Agent API și comparați nivelurile de efort pe propriile sarcini de lucru. Găsiți detalii despre nivelurile de efort în documentația Agent API despre nivelurile de efort.

Costul cercetării

Controlul bugetului de cercetare

Gestionarea contextului

Compactare

Preluarea doar a ceea ce contează

Căutare web focalizată

Selectarea fluxului de lucru corect

Selecția modelului

Scalare multi-agent

Ce urmează