Ulepszenia wszystkich poziomów wysiłku w Agent API

Poziomy wysiłku w Perplexity Agent API pozwalają deweloperom wybrać równowagę między kosztem, szybkością i głębokością badań dla każdego zadania. Od dziś każdy poziom wysiłku kosztuje mniej za zapytanie, a jakość badań jest wyższa lub niezmieniona. Dostępny jest nowy poziom ultra do najbardziej rozległych i kompleksowych badań. Każde żądanie, które wybiera poziom po nazwie, np. effort="fast", automatycznie otrzymuje zaktualizowaną konfigurację.

Budowa agenta badawczego oznacza wybór właściwej równowagi między kosztem, szybkością i głębokością dla każdego zadania. Poziomy wysiłku w Agent API podejmują tę decyzję za użytkownika. Każdy poziom to gotowa konfiguracja, która określa model, budżet kroków, ustawienia wyszukiwania i narzędzia dla określonego typu zadania. Perplexity z czasem ocenia i aktualizuje każdy poziom, aby zapewniać najlepsze badania przy obecnym koszcie lub niższym.

Te korzyści wynikały z dwóch rodzajów zmian. Budżety, zarządzanie kontekstem i ekstrakcja obniżyły koszt każdego przebiegu, a Skille, wybór modelu i równoległe agenty podniosły lub utrzymały jakość odpowiedzi.

Wydajność poziomu medium wzrosła z 55% do 77% w BrowseComp i DSQA, a koszty spadły o prawie 90%. BrowseComp i DSQA to publiczne benchmarki badawcze; WANDR to benchmark Perplexity obejmujący długie zadania badawcze dotyczące wielu podmiotów. Poziom xhigh wykonuje pracę agentową, taką jak uruchamianie kodu w piaskownicy, podtrzymywanie długich pętli korzystania z narzędzi i jednoczesna praca z wieloma źródłami. Poziom xhigh utrzymał wynik WANDR na poziomie 76,5%, działając przy około 25% kosztu konfiguracji z sierpnia 2026 r.

Zapytanie w trybie Dogłębne badania może uruchomić dziesiątki wyszukiwań, przeczytać setki stron i sprawdzić dowody, zanim udzieli odpowiedzi. Każde z tych działań dodaje tokeny do kontekstu i dolary do rachunku. Bez limitów agent wciąż podejmuje działania, które podnoszą koszt i zapychają kontekst, nie poprawiając odpowiedzi. Większość tego kosztu wynika z pięciu czynników:

Przydział budżetu. Agenty z ustalonym budżetem mogą wyczerpać kroki i przedwcześnie zakończyć przebieg, zanim sfinalizują zadanie. Z kolei agenty bez stałego budżetu mogą działać dalej, generując koszty bez poprawy ostatecznej odpowiedzi.
Narzut kontekstu. Wyniki wyszukiwania i pobrane strony zawierają dowody, ale bez kontroli okno kontekstu może szybko zapełnić się nieistotnymi informacjami. Okna kontekstu przenoszą koszty z kroku na krok, a przeciążone okna mogą obniżać wydajność agenta.
Wybór przepływu pracy. Różne zadania wymagają różnych podejść. Wyszukanie pojedynczego faktu, pytanie wieloetapowe i szeroki przegląd źródeł wymagają odmiennych przepływów pracy. Gdy model wybiera samodzielnie, często decyduje się na nieefektywny przepływ pracy. Opisanie w prompcie agenta każdej dostępnej strategii nie rozwiązuje tego problemu. Dodatkowe instrukcje są przenoszone jako tokeny na każdym kroku, a model z czasem stosuje się do każdej z nich coraz mniej niezawodnie.
Wybór modelu. Przejście na większy model może nie zapewnić poprawy wydajności proporcjonalnej do dodatkowego kosztu. Nowe modele pojawiają się w nagłówkach wraz z opublikowanymi wynikami benchmarków. Jednak wzrosty w benchmarkach mogą wynikać z kontaminacji danych lub odzwierciedlać nadmierne dopasowanie modelu. Bez oceny na rzeczywistych zadaniach zmiana modelu może podnieść koszty bez poprawy jakości.
Skalowanie wieloagentowe. Pojedynczy agent może w jednym przebiegu przeszukać, przeczytać i przeanalizować ograniczoną liczbę źródeł. Równoległe uruchamianie wielu agentów poprawia jakość w najbardziej wymagających zadaniach, ale też zwiększa koszty i wprowadza złożoność, jeśli nie jest prawidłowo obsługiwane.

Rozwiązanie każdego z tych wyzwań obniżyło koszty na każdym poziomie wysiłku bez pogorszenia wydajności.

Każdy poziom wysiłku ma stały budżet badawczy złożony z trzech elementów:

Limity kroków: liczba tur, które może wykonać agent
Wywołania narzędzi: limit łącznej liczby wywołań narzędzi w żądaniu. Pojedynczy krok może jednocześnie wysłać wiele wywołań do wielu narzędzi, więc sam limit kroków nie kontroluje, ile działań odbywa się w ramach jednego kroku.
Przypomnienia o budżecie: okresowe powiadomienia o liczbie pozostałych kroków, dzięki którym agent może ustalać priorytety i zostawić miejsce na napisanie odpowiedzi, zamiast wyczerpać budżet w połowie zadania.

Budżet to główny kompromis: więcej kroków oznacza lepsze odpowiedzi, a każdy krok generuje koszty. W przypadku openai/gpt-6-luna zwiększenie limitu kroków z 1 do 15 podnosi dokładność w BrowseComp + DSQA z 41% do 80%, podczas gdy koszt na zapytanie rośnie z 0,0017 USD do 0,0152 USD — to około 9 razy wyższy koszt za mniej więcej 2 razy lepszy wynik.

Sam limit kroków nie kontroluje kosztu badań. Przy tym samym budżecie pięciu kroków model openai/gpt-6.1-terra wykonuje więcej wywołań narzędzi niż openai/gpt-6-luna, ponieważ bardziej zaawansowane modele zwykle wysyłają kilka wywołań w jednym kroku. Poziomy wysiłku ograniczają zarówno wywołania narzędzi, jak i kroki. W przypadku tych modeli limit wywołań narzędzi jest równie ważny jak limit kroków.

Każdy poziom wysiłku dostosowuje te limity, ale agent musi też wiedzieć, ile kroków i działań mu pozostało na zrealizowanie żądania. Bez tej informacji może wyczerpać kroki lub działania i zostać zmuszony do udzielenia odpowiedzi przed ukończeniem badań. Budżet jest podawany na początku przebiegu, a przypomnienia pojawiają się, gdy agent zbliża się do limitów, dzięki czemu zostaje miejsce na weryfikację i dostarczenie wyników. W przypadku poziomu high przypomnienia obejmują zarówno budżet kroków, jak i budżet wywołań narzędzi.

Dwa agenty — jeden z przypomnieniem o budżecie, a drugi bez niego — przetestowano na zadaniu BrowseComp polegającym na zidentyfikowaniu serialu telewizyjnego z lat 90. na podstawie trzech biografii członków obsady. Agent z przypomnieniem znalazł poprawną odpowiedź, wykorzystując 13 z 40 kroków przewidzianych w budżecie. Agent bez przypomnienia o budżecie wykorzystał wszystkie 40 kroków i nie znalazł poprawnej odpowiedzi. Pętla tego agenta zakończyła się nieoczekiwanie, a model nie wiedział, ile budżetu na badania mu pozostało. Przypomnienia pomagają agentom zachować koncentrację i skutecznie ustalać priorytety w wykorzystaniu pozostałych zasobów.

Długotrwałe zadania badawcze zapełniają okno kontekstu modelu wynikami wyszukiwania, pobranymi stronami i notatkami pośrednimi. Gdy okno się zapełni, agent musi przerwać pracę.

Kompaktowanie pozwala długim przebiegom kontynuować pracę bez zapełniania okna kontekstu. Gdy kontekst przekroczy określony próg, agent zastępuje dotychczasową pracę krótszym podsumowaniem tego, co znalazł i co pozostało do zrobienia, a następnie kontynuuje.

Kompaktowanie zawsze zachowuje w kontekście trzy elementy: prompt systemowy, pierwotne żądanie oraz wszystkie Skille, które agent już załadował. Po każdym kompaktowaniu agent otrzymuje dwie krótkie instrukcje. Pierwsza brzmi: „Kontynuuj pracę, dopóki zadanie nie zostanie wykonane”. Dzięki temu agent nie traktuje podsumowania jako punktu zakończenia. Druga instrukcja informuje agenta, ile kompaktowań już nastąpiło, aby mógł zaplanować pozostałe zadania badawcze. Długie przebiegi zachowują w polu widzenia pierwotny cel i plan, a koszt długich pętli spada bez utraty jakości.

Każda strona przeczytana przez agenta powiększa jego kontekst, a agent przenosi go na każdy kolejny krok. Strona internetowa zawiera informacje niezwiązane z pytaniem, takie jak nawigacja, szablonowe teksty i inne treści.

Zamiast przekazywać agentowi całą stronę, fetch_url najpierw przeprowadza ekstrakcję. Tekst strony jest wysyłany do mniejszego modelu wraz z bieżącym zadaniem agenta. Model zwraca tylko istotne fragmenty, cytowane dosłownie, aby agent mógł się na nie powoływać. Podczas jednej z ocen strona o rozmiarze 5561 tokenów została zredukowana do 293 tokenów, co zwolniło miejsce na dodatkowy istotny kontekst.

Użycie fetch_url z ekstrakcją na poziomie wysiłku high zmniejszyło liczbę tokenów wejściowych na zapytanie o około 50%. Ekstrakcja poprawiła też wyniki w benchmarkach, osiągając 88,0% przy koszcie 0,073 USD za zapytanie, w porównaniu z 83,5% przy 0,094 USD bez ekstrakcji.

Wyszukiwanie w sieci ma kluczowe znaczenie dla każdego żądania badawczego agenta. Wprowadzono trzy zmiany w sposobie wyszukiwania przez agenty:

Więcej kontekstu na wyszukiwanie: każde wyszukiwanie zwraca teraz do 4 tys. tokenów wyników zamiast 2 tys. Agent szybciej znajduje to, czego potrzebuje, co oznacza mniej wyszukiwań i niższy koszt.

Nowy silnik fragmentów: wyniki wyszukiwania otrzymują fragmenty lepiej dopasowane do zapytania, dzięki czemu agent nie jest przeciążony nieistotnym tekstem.
Szybkie wyszukiwanie: w cenie 1,00 USD za 1 tys. żądań Fast Search obniża zarówno koszt, jak i opóźnienie każdego wywołania wyszukiwania.

Zespół Perplexity Search nieustannie poprawia jakość wyszukiwania w szerokim zakresie zadań. Ostatnie aktualizacje przyniosły poprawę w przypadku kodu, dokumentacji dla deweloperów, stron referencyjnych oraz treści prawnych i regulacyjnych.

Niektóre zadania wymagają równoległego uruchomienia wielu wyszukiwań; inne — uważnej lektury kilku długich dokumentów.

Jednak ładowanie każdego przepływu pracy do promptu systemowego agenta zwiększa narzut kontekstu i może sprawić, że model będzie gorzej radził sobie z prostymi zadaniami. Zamiast tego Skille są uporządkowane w drzewo ze stopniowym ujawnianiem. Model ładuje odpowiednie Skille i instrukcje w trakcie pracy, pomijając w swoim kontekście niepowiązane informacje. Każdy Skill kosztuje tylko tyle, ile jego nazwa i opis, dopóki model nie uzna, że pasuje on do zadania, i go nie załaduje — wtedy pełne instrukcje są dodawane do kontekstu, a model postępuje zgodnie z określonym przepływem pracy.

Aby zmierzyć wkład poszczególnych Skilli, każdy z nich jest usuwany pojedynczo, co pozwala porównać jakość i koszt w zadaniach, w których agent bazowy załadował dany Skill. Te ablacje pokazują, które przepływy pracy pomagają agentowi i jak wpływają na efektywność badań.

Poniższe przebiegi benchmarku WANDR pokazują, jak agenty wybierają właściwe przepływy pracy dla konkretnych zadań. Wskazówki wide-search i fanout były ładowane w każdym zadaniu, co odzwierciedla potrzebę badania wielu podmiotów. Skill people-search został załadowany tylko w 6% zadań i tylko wtedy, gdy pytania dotyczyły ludzi.

Podczas testowania innego zadania WANDR agent załadował Skill people-search ze wzorcem fanout, aby znaleźć inżynierów ds. inferencji w Londynie. Rozwinął 39 nazw ról w 117 zapytań, a następnie scalił wyniki pierwszego przebiegu w 43 unikalne profile do dalszej selekcji. Skill people-search poprowadził agenta przez to rozwinięcie bez dodawania nieistotnego kontekstu. Poniższy fragment jest adaptacją skryptu agenta; nazwy funkcji pomocniczych mają charakter poglądowy.

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

Tworzenie punktów kontrolnych to kolejny przepływ pracy, który pomaga agentom w długotrwałych zadaniach. Wzorzec punktów kontrolnych wywodzi się z programowania wsadowego. Gdy skrypt przetwarza długą listę, zapisuje każdy wynik na dysku, gdy tylko go uzyska, zamiast przechowywać wszystko w pamięci do samego końca. Jeśli skrypt ulegnie awarii lub w trakcie napotka błędy, nic nie zostaje utracone: następne uruchomienie odczytuje to, co zostało już zapisane, i kontynuuje od miejsca, w którym przerwano, ponawiając tylko te elementy, których nie udało się przetworzyć.

W innym zadaniu WANDR agent musiał przeprowadzić selekcję profili 188 inżynierów. Załadował wzorzec punktu kontrolnego, aby zapisywać każdy wynik na bieżąco. W pierwszym przebiegu wyodrębnił 160 profili, ale nie poradził sobie z 28. Gdy agent ponownie uruchomił skrypt, pominął profile, które zostały już zapisane, i ponowił próbę tylko dla pozostałych 28. Bez punktu kontrolnego jeden błędny rekord oznaczałby konieczność ponownego pobrania wszystkich 188.Adaptowany fragment kodu w Pythonie; pominięto strony wejściowe, instrukcję selekcji, schemat i importy; nazwy funkcji pomocniczych mają charakter poglądowy.

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

Punkt kontrolny zapisuje udane wyniki; nie uruchamia ponownych prób. Uwzględnienie instrukcji i schematu w kluczu sprawia, że zmiana kryteriów selekcji powoduje ponowne przetworzenie.

Nie każdy test przyniósł poprawę jakości i efektywności. Oceniono wstępne ładowanie wszystkich Skilli do agenta przed rozpoczęciem zadania. W BrowseComp i DSQA wstępne ładowanie zwiększyło koszt o 13%. W WANDR, gdzie dłuższe trajektorie badawcze sprawiają, że pobrana treść stanowi większą część tokenów wejściowych, wstępne ładowanie również obniża wyniki. Te rezultaty przemawiały za dalszym stosowaniem stopniowego ujawniania.

Wraz z rozwojem możliwości modeli zmienia się też najlepszy model dla każdego poziomu wysiłku. Perplexity stosuje zautomatyzowaną pętlę badawczą, która monitoruje zapowiedzi i dostępność nowych modeli. Oceny są uruchamiane, gdy tylko model staje się dostępny.

Gdy zostaje wydany nowy model, zautomatyzowany agent przepuszcza go przez harness ewaluacyjny. Sprawdza różne wartości wysiłku rozumowania, budżetów kroków i wywołań narzędzi oraz konfiguracje narzędzi, a każdy przebieg ocenia pod względem jakości i kosztu w porównaniu z obecnymi poziomami wysiłku. Jeśli w danym przebiegu nastąpi regresja, agent bada jej przyczynę, dostosowuje ustawienia i ponownie przeprowadza ewaluację. Kandydat zastępuje obecny model tylko wtedy, gdy wygrywa pod względem jakości przy tym samym lub niższym koszcie.

Publiczne benchmarki są przydatne, ale ich wyniki nie zawsze przekładają się na rzeczywiste zadania. Na przykład poniższy wykres przedstawia model kandydujący, który w BrowseComp uzyskał wynik o 13,3 punktu wyższy od bazowego, ale w wewnętrznych zadaniach badawczych dotyczących przedsiębiorstw, prawa i finansów wypadł znacznie poniżej odpowiednich wyników bazowych.

Pojedynczy agent może w jednej pętli objąć tylko ograniczoną liczbę źródeł. W przypadku złożonych zadań kilka agentów pracuje równolegle, a każdy z nich zajmuje się inną częścią problemu.

Agent główny pełni rolę orkiestratora. Wywołuje spawn_agent, aby tworzyć agenty podrzędne, i przydziela każdemu z nich konkretne, ściśle określone zadanie. Każdy agent podrzędny prowadzi własną pętlę badawczą w osobnym kontekście, korzystając z własnego modelu, narzędzi i budżetu kroków. Agenty podrzędne przekazują wyniki agentowi nadrzędnemu, który może zlecić im kolejne zadanie lub sprawdzić postęp ich pracy. Orkiestrator i agenty podrzędne wymieniają wiadomości, aby dzielić się dowodami, sygnalizować przeszkody i korygować kolejne kroki. W miarę napływu nowych informacji orkiestrator doprecyzowuje zadania, a po zakończeniu pracy łączy wyniki w jedną odpowiedź.

Agent API obsługuje predefiniowane role agentów, a orkiestrator może tworzyć agenty podrzędne z niestandardowymi instrukcjami.

Poziom wysiłku ultra uruchamia równolegle trzy agenty do jednego zadania. Każdy agent niezależnie bada całe zadanie, co daje różne dowody. Czwarty agent scala ich ustalenia, usuwa duplikaty i pisze ostateczną odpowiedź.

W WANDR poziom ultra osiąga wynik 85,9% przy koszcie 21,71 USD za zadanie. To najwyższy wynik spośród testowanych konfiguracji.

Poziomy wysiłku są stale oceniane i ulepszane. Poziom wybrany przez użytkownika określa, ile badań otrzyma zadanie i ile będzie ono kosztować. Budżety kroków i wywołań narzędzi, wraz z przypomnieniami w miarę ich wyczerpywania się, utrzymują żądania w ramach budżetu. Kompaktowanie, ekstrakcja i lepsze fragmenty utrzymują kontekst skupiony na dowodach. Skille dopasowują przepływ pracy do zadania, a równoległe agenty rozszerzają zakres tego, co może objąć jedna pętla. Zautomatyzowana pętla oceny dopuszcza nowy model tylko wtedy, gdy poprawia on jakość badań przy tym samym koszcie.

Każdy poziom wysiłku będzie nadal ewoluował, w miarę jak nowe modele i konfiguracje będą się sprawdzać w ocenach. Wywołanie poziomu po nazwie automatycznie uwzględnia te ulepszenia; przypięcie wersji utrzymuje stałą konfigurację.

Wypróbuj Agent API i porównaj poziomy wysiłku na własnych obciążeniach. Szczegóły dotyczące poziomów wysiłku znajdziesz w naszej dokumentacji poziomów wysiłku Agent API.

Koszt badań

Kontrolowanie budżetu badawczego

Zarządzanie kontekstem

Kompaktowanie

Pobieranie tylko tego, co istotne

Ukierunkowane wyszukiwanie w sieci

Wybór właściwego przepływu pracy

Wybór modelu

Skalowanie wieloagentowe

Co dalej