Подобрения във всяко ниво на усилие на Agent API

Нивата на усилие в Perplexity Agent API позволяват на разработчиците да избират баланса между разходи, скорост и задълбоченост на проучването за всяка задача. Днес всяко ниво на усилие струва по-малко на заявка, а качеството на проучването е по-високо или непроменено. Ново ниво ultra е налично за най-обхватните и изчерпателни проучвания. Всяка заявка, която избира нивото по име, например effort="fast", получава обновената конфигурация автоматично.

Изграждането на агент за проучване означава да се избере правилният баланс между разходи, скорост и задълбоченост за всяка задача. Нивата на усилие в Agent API вземат това решение вместо потребителя. Всяко ниво е пакетна конфигурация, която определя модела, бюджета от стъпки, настройките за търсене и инструментите за конкретен тип задача. Perplexity оценява и обновява всяко ниво с времето, за да осигури най-доброто проучване при текущата му цена или по-ниска.

Тези подобрения се дължат на два вида промени. Бюджетите, управлението на контекста и извличането намалиха разходите за всяко изпълнение, а уменията, изборът на модел и паралелните агенти повишиха или запазиха качеството на отговора.

Производителността на medium се подобри от 55% на 77% в BrowseComp и DSQA, докато разходите намаляха с почти 90%. BrowseComp и DSQA са публични бенчмаркове за проучване; WANDR е бенчмаркът на Perplexity за дълги проучвателни задачи с множество обекти. xhigh извършва агентна работа, като изпълнение на код в Sandbox, поддържане на дълги цикли на използване на инструменти и работа с много източници едновременно. xhigh запази резултата си в WANDR от 76,5%, като работи с около 25% от разходите на конфигурацията от август 2026 г.

Една заявка за Задълбочено проучване може да изпълни десетки търсения, да прочете стотици страници и да провери доказателствата, преди да отговори. Всяко от тези действия добавя токени към контекста и долари към сметката. Без ограничения агентът продължава да предприема действия, които повишават разходите и претоварват контекста, без да подобряват отговора. Пет фактора определят по-голямата част от тези разходи:

Разпределение на бюджета. Агентите със зададен бюджет може да изчерпат стъпките си и да прекратят изпълнението преждевременно, преди да довършат задачата си. И обратно, агентите без фиксиран бюджет може да продължат да работят и да натрупват разходи, без да подобряват крайния отговор.
Натоварване на контекста. Резултатите от търсенето и извлечените страници носят доказателствата, но без контрол контекстният прозорец бързо може да се запълни с нерелевантна информация. Контекстните прозорци пренасят разходи от стъпка на стъпка, а претоварените прозорци могат да влошат работата на агента.
Избор на работен процес. Различните задачи изискват различни подходи. Търсенето на единичен факт, въпросът с няколко логически стъпки и широкият преглед на източници изискват различен работен процес. Оставен сам да избира, моделът често избира неефективен. Описването на всяка налична стратегия в промпта на агента не решава проблема. Допълнителните инструкции се пренасят като токени на всяка стъпка и с времето моделът следва всяка от тях все по-малко надеждно.
Избор на модел. Преминаването към по-голям модел може да не донесе подобрение, съизмеримо с допълнителните разходи. Новите модели се появяват с гръмки заглавия и публикувани резултати от бенчмаркове. Подобренията в бенчмарковете обаче може да са изкривени от замърсени данни или да отразяват преобучение (overfitting) на модела. Без оценка при реални задачи смяната на модела може да повиши разходите, без да повиши качеството.
Мащабиране с множество агенти. Един агент може да търси, чете и анализира ограничен брой източници при едно изпълнение. Паралелното изпълнение на няколко агента подобрява качеството при най-взискателните задачи, но също така увеличава разходите и внася сложност, ако не се управлява правилно.

Решаването на всяко от тези предизвикателства намали разходите за всяко ниво на усилие, без да влоши производителността.

Всяко ниво на усилие има фиксиран бюджет за проучване с три компонента:

Ограничения на стъпките: броят ходове, които агентът може да направи
Извиквания на инструменти: ограничение на общия брой извиквания на инструменти в една заявка. Една стъпка може да направи едновременно няколко извиквания към няколко инструмента, затова само ограничението на стъпките не контролира колко действия се извършват в рамките на една стъпка.
Напомняния за бюджета: периодични известия колко стъпки остават, така че агентът да може да определя приоритети и да остави място за написване на отговора, вместо да изчерпа бюджета по средата на задачата.

Бюджетът е основният компромис: повече стъпки означават по-добри отговори, а всяка стъпка носи разходи. С openai/gpt-6-luna увеличаването на ограничението на стъпките от 1 на 15 повишава точността в BrowseComp + DSQA от 41% на 80%, докато разходите на заявка нарастват от 0,0017 $ на 0,0152 $ — около 9 пъти по-високи разходи за около 2 пъти по-добър резултат.

Само ограничението на стъпките не контролира разходите за проучване. При един и същ бюджет от пет стъпки openai/gpt-6.1-terra прави повече извиквания на инструменти от openai/gpt-6-luna, тъй като по-способните модели са склонни да правят няколко извиквания в една стъпка. Нивата на усилие ограничават както извикванията на инструменти, така и стъпките. За тези модели ограничението на извикванията на инструменти е също толкова важно, колкото и ограничението на стъпките.

Всяко ниво на усилие настройва тези ограничения, но агентът също трябва да знае колко стъпки и действия му остават, за да изпълни заявката. Без тази информация той може да изчерпа стъпките или действията си и да бъде принуден да отговори, преди проучването да е завършено. Бюджетът се обявява в началото на изпълнението, а когато агентът наближи ограниченията си, получава напомняния, така че да остане място за проверка и представяне на резултатите. При high напомнянията обхващат както бюджета от стъпки, така и бюджета за извиквания на инструменти.

Два агента — единият с напомняне за бюджета, а другият без — бяха тествани със задача от BrowseComp да идентифицират телевизионен сериал от 90-те години по три биографии на актьори от състава. Агентът с напомняне намери верния отговор, като използва 13 от 40-те стъпки в бюджета. Агентът без напомняне за бюджета изразходва всичките 40 стъпки и не намери верния отговор. Цикълът на този агент приключи неочаквано, а моделът не знаеше какъв бюджет за проучване му остава. Напомнянията помагат на агентите да останат фокусирани и да разпределят ефективно оставащите ресурси.

Продължителните задачи за проучване запълват контекстния прозорец на модела с резултати от търсения, извлечени страници и междинни бележки. След като прозорецът се запълни, агентът трябва да спре работа.

Компактирането позволява дългите изпълнения да продължат, без да запълват контекстния прозорец. Когато контекстът надхвърли определен праг, агентът заменя досегашната работа с по-кратко резюме на откритото и на оставащото, след което продължава.

Компактирането винаги запазва три неща в контекста: системния промпт, първоначалната заявка и всички умения, които агентът вече е заредил. След всяко компактиране агентът получава две кратки инструкции. Първата е: „Продължи да работиш, докато задачата бъде изпълнена.“ Така агентът не възприема резюмето като точка на спиране. Втората инструкция казва на агента колко компактирания са извършени, за да може да планира оставащите си задачи по проучването. Дългите изпълнения не изпускат от поглед първоначалната цел и плана, а разходите за дългите цикли намаляват без понижаване на качеството.

Всяка страница, която агентът прочита, се добавя към контекста му и агентът я носи на всяка следваща стъпка. Уеб страницата съдържа информация, несвързана с въпроса, като навигация, шаблонен текст и друго съдържание.

Вместо да предаде на агента цялата страница, fetch_url първо изпълнява етап на извличане. Текстът на страницата се изпраща на по-малък модел заедно с текущата задача на агента. Моделът връща само релевантните пасажи, цитирани дословно, за да може агентът да ги посочи като източник. По време на една оценка страница от 5561 токена беше сведена до 293 токена, което освободи място за допълнителен релевантен контекст.

Използването на fetch_url с извличане при ниво на усилие high намали входните токени на заявка с около 50%. Извличането подобри и резултатите в бенчмарковете — 88,0% при 0,073 $ на заявка в сравнение с 83,5% при 0,094 $ без извличане.

Търсенето в мрежата е в основата на всяка заявка за проучване от агент. Бяха направени три промени в начина, по който агентите търсят:

Повече контекст при всяко търсене: Всяко търсене вече връща до 4K токена резултати вместо 2K. Агентът намира нужното по-бързо, което води до по-малко търсения и по-ниски разходи.

Нов механизъм за откъси: Резултатите от търсенето получават откъси, които по-добре съответстват на заявката, така че агентът не се претоварва с нерелевантен текст.
Бързо търсене: При цена от 1,00 $ за 1K заявки Fast Search намалява както разходите, така и латентността на всяко извикване за търсене.

Екипът на Perplexity Search непрекъснато подобрява качеството на извличането на информация в широк набор от задачи. Последните обновления донесоха подобрения при код, документация за разработчици, справочни страници, правно и регулаторно съдържание.

Някои задачи изискват много паралелни търсения; други се нуждаят от внимателно четене на няколко дълги документа.

Зареждането на всеки работен процес в системния промпт на агента обаче добавя натоварване на контекста и може да доведе до по-слаби резултати на модела при прости задачи. Вместо това уменията са организирани в дърво с постепенно разкриване. Моделът зарежда релевантните умения и инструкции в хода на работата, като оставя несвързаната информация извън контекста си. Всяко умение струва само колкото името и описанието му, докато моделът не реши, че то е подходящо за задачата, и не го зареди — тогава пълните инструкции се добавят към контекста и моделът следва предписания работен процес.

За да се измери приносът на отделните умения, всяко умение се премахва поотделно, за да се сравнят качеството и разходите при задачите, в които базовият агент е заредил това умение. Тези аблации показват кои работни процеси помагат на агента и как влияят на ефективността на проучването.

Изпълненията на бенчмарка WANDR по-долу показват как агентите избират правилните работни процеси за конкретни задачи. Насоките за широко търсене и разклоняване (fanout) бяха заредени за всяка задача, тъй като се налагаше проучване на множество обекти. Търсенето на хора беше заредено само при 6% от задачите и само когато въпросите засягаха хора.

При тестване на друга задача от WANDR агентът зареди умението за търсене на хора с модел на разклоняване (fanout), за да намери инженери по инференция в Лондон. Той разшири 39 термина за длъжности в 117 заявки, след което обедини резултатите от първия етап в 43 уникални профила за по-нататъшен подбор. Умението за търсене на хора насочи агента през това разширяване, без да добавя нерелевантен контекст. Откъсът по-долу е адаптиран от скрипта на агента; имената на помощните функции са илюстративни.

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

Контролните точки са друг работен процес, който помага на агентите при продължителни задачи. Моделът с контролни точки идва от пакетното програмиране. Когато скрипт обработва дълъг списък, той записва всеки резултат на диска веднага щом го получи, вместо да държи всичко в паметта до края. Ако скриптът се срине или срещне грешки по средата, нищо не се губи: следващото изпълнение прочита вече запазеното и продължава оттам, докъдето е стигнало, като повтаря само неуспешните елементи.

В друга задача от WANDR агентът трябваше да прегледа профилите на 188 инженери. Той зареди модела с контролни точки, за да записва всеки резултат в хода на работата. При първия етап бяха извлечени 160 профила, но при 28 имаше неуспех. Когато агентът изпълни скрипта отново, той пропусна вече записаните профили и опита повторно само оставащите 28. Без контролната точка един-единствен проблемен запис би означавал повторно извличане на всичките 188.Адаптиран откъс на Python; входните страници, инструкцията за подбор, схемата и импортите са пропуснати; имената на помощните функции са илюстративни.

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

Контролната точка записва успешните резултати; тя не стартира повторни опити. Включването на инструкцията и схемата в ключа гарантира, че промяната на критериите за подбор води до повторна обработка.

Не всеки тест доведе до подобрение в качеството и ефективността. Беше оценено предварителното зареждане на всички умения в агента, преди той да започне задачата си. В BrowseComp и DSQA предварителното зареждане увеличи разходите с 13%. В WANDR, където по-дългите траектории на проучване правят извлеченото съдържание по-голям дял от входните токени, предварителното зареждане също понижава резултатите. Тези резултати подкрепиха продължаването на използването на постепенното разкриване.

С напредването на възможностите на моделите най-добрият модел за всяко ниво на усилие също се променя. Perplexity използва автоматизиран цикъл на проучване, който следи обявяването и наличността на нови модели. Оценките се стартират веднага щом даден модел стане достъпен.

Когато бъде пуснат нов модел, автоматизиран агент го прекарва през harness за оценяване. Той обхожда различни нива на усилие за разсъждение, бюджети за стъпки и извиквания на инструменти, както и конфигурации на инструментите, и оценява всяко изпълнение по качество и разходи спрямо текущите нива на усилие. Когато дадено изпълнение покаже влошаване, агентът проучва причината, коригира настройките и изпълнява оценката отново. Кандидатът заменя текущия модел само когато го превъзхожда по качество при същите или по-ниски разходи.

Публичните бенчмаркове са полезни, но резултатите от тях не винаги се пренасят върху реални задачи. Например графиката по-долу показва кандидат-модел, който е постигнал резултат с 13,3 пункта над базовата линия в BrowseComp, но значително под съответните базови линии при вътрешни корпоративни, правни и финансови задачи за проучване.

Един агент може да обхване само ограничен брой източници в един цикъл. При сложни задачи няколко агента работят паралелно, като всеки се занимава с различна част от проблема.

Основният агент е оркестраторът. Той извиква spawn_agent, за да създаде дъщерни агенти, и възлага на всеки конкретна, фокусирана задача. Всеки дъщерен агент изпълнява собствен цикъл на проучване с отделен контекст, като използва свой модел, инструменти и бюджет от стъпки. Дъщерните агенти докладват резултатите си на родителския агент, който може да им възложи последваща задача или да провери напредъка им. Оркестраторът и дъщерните агенти обменят съобщения, за да споделят доказателства, да сигнализират за пречки и да коригират следващите стъпки. С постъпването на нова информация оркестраторът прецизира задачите, а когато работата приключи, обединява резултатите в един отговор.

Agent API поддържа предварително зададени роли на агенти, а оркестраторът може да създава дъщерни агенти с персонализирани инструкции.

Нивото на усилие ultra изпълнява паралелно три агента по една задача. Всеки агент проучва независимо цялата задача и така достига до различни доказателства. Четвърти агент обединява откритията им, премахва дублиранията и написва крайния отговор.

В WANDR ultra постига 85,9% при 21,71 $ на задача. Това е най-високият резултат сред тестваните конфигурации.

Нивата на усилие непрекъснато се оценяват и подобряват. Нивото, което потребителите изберат, определя колко проучване получава дадена задача и колко ще струва тя. Бюджетите за стъпки и извиквания на инструменти, заедно с напомнянията при изчерпването им, удържат заявките в рамките на бюджета. Компактирането, извличането и по-добрите откъси държат контекста фокусиран върху доказателствата. Уменията съобразяват работния процес със задачата, а паралелните агенти разширяват обхвата отвъд възможностите на един цикъл. Автоматизиран цикъл за оценяване допуска нов модел само когато той подобрява качеството на проучването при същите разходи.

Всяко ниво на усилие ще продължи да се развива, докато нови модели и конфигурации се доказват при оценяването. Извикването на ниво по име автоматично включва тези подобрения; фиксирането на версия запазва конфигурацията непроменена.

Изпробвайте Agent API и сравнете нивата на усилие при собствените си работни натоварвания. Подробности за нивата на усилие ще намерите в нашата документация за нивата на усилие в Agent API.

Цената на проучването

Контрол на бюджета за проучване

Управление на контекста

Компактиране

Извличане само на същественото

Фокусирано търсене в мрежата

Избор на правилния работен процес

Избор на модел

Мащабиране с множество агенти

Какво следва