Покращення всіх рівнів зусиль Agent API

Рівні зусиль у Perplexity Agent API дають розробникам змогу обирати баланс між вартістю, швидкістю та глибиною дослідження для кожного завдання. Відтепер кожен рівень зусиль коштує менше за запит, а якість дослідження вища або незмінна. Для найширших і найґрунтовніших досліджень доступний новий рівень ultra. Будь-який запит, що обирає рівень за назвою, наприклад effort="fast", автоматично отримує оновлену конфігурацію.

Створення дослідницького агента означає пошук правильного балансу між вартістю, швидкістю та глибиною для кожного завдання. Рівні зусиль в Agent API ухвалюють це рішення за користувача. Кожен рівень — це готова конфігурація, яка визначає модель, бюджет кроків, налаштування пошуку та інструменти для певного типу завдань. Perplexity з часом оцінює та оновлює кожен рівень, щоб забезпечувати найкраще дослідження за поточної або нижчої вартості.

Ці покращення стали результатом змін двох типів. Бюджети, робота з контекстом і вилучення знизили вартість кожного запуску, а навички, вибір моделі та паралельні агенти підвищили або зберегли якість відповіді.

Продуктивність medium на BrowseComp і DSQA зросла з 55% до 77%, а витрати знизилися майже на 90%. BrowseComp і DSQA — публічні дослідницькі бенчмарки; WANDR — бенчмарк Perplexity для довгих дослідницьких завдань із багатьма сутностями. xhigh виконує агентну роботу, як-от запуск коду в пісочниці, підтримання довгих циклів використання інструментів і роботу з багатьма джерелами одночасно. xhigh зберіг результат WANDR на рівні 76,5%, працюючи приблизно за 25% вартості конфігурації серпня 2026 року.

Глибоке дослідження за одним запитом може включати десятки пошуків, читання сотень сторінок і перевірку доказів, перш ніж буде надано відповідь. Кожна з цих дій додає токени до контексту й долари до рахунку. Без обмежень агент і далі виконує дії, які підвищують вартість і захаращують контекст, не покращуючи відповіді. Більшість цих витрат зумовлюють п’ять чинників:

Розподіл бюджету. Агентам із заданим бюджетом можуть закінчитися кроки, і вони завершать запуск передчасно, не довівши завдання до кінця. І навпаки, агенти без фіксованого бюджету можуть працювати далі, накопичуючи витрати без покращення фінальної відповіді.
Навантаження на контекст. Результати пошуку та отримані сторінки містять докази, але без контролю контекстне вікно може швидко заповнитися нерелевантною інформацією. Вміст контекстного вікна переноситься з кроку на крок разом із витратами, а перевантажене вікно може погіршити продуктивність агента.
Вибір робочого процесу. Різні завдання потребують різних підходів. Для пошуку одного факту, багатоетапного запитання й широкого огляду джерел потрібен різний робочий процес. Якщо модель обирає сама, вона часто зупиняється на неефективному варіанті. Детальний опис усіх доступних стратегій у промпті агента цієї проблеми не вирішує. Додаткові інструкції переносяться як токени на кожному кроці, а модель із часом дотримується кожної з них дедалі менш надійно.
Вибір моделі. Перехід на більшу модель може не дати покращення продуктивності, співмірного з додатковими витратами. Нові моделі з’являються з гучними заголовками й опублікованими результатами бенчмарків. Однак приріст у бенчмарках може бути наслідком контамінації даних або перенавчання моделі. Без оцінювання на реальних завданнях зміна моделі може підвищити витрати, не підвищивши якості.
Багатоагентне масштабування. Один агент за запуск може знайти, прочитати й проаналізувати лише обмежену кількість джерел. Паралельний запуск кількох агентів покращує якість у найскладніших завданнях, але також збільшує витрати й ускладнює систему, якщо цим неправильно керувати.

Розв’язання кожної з цих проблем знизило витрати на кожному рівні зусиль без погіршення продуктивності.

Кожен рівень зусиль має фіксований бюджет на дослідження, що складається з трьох компонентів:

Ліміти кроків: кількість ходів, які може зробити агент
Виклики інструментів: обмеження загальної кількості викликів інструментів у запиті. Один крок може одночасно ініціювати кілька викликів різних інструментів, тому саме лише обмеження кроків не контролює, скільки дій відбувається в межах одного кроку.
Нагадування про бюджет: періодичні повідомлення про те, скільки кроків залишилося, щоб агент міг розставити пріоритети й залишити запас на написання відповіді, а не вичерпати бюджет посеред завдання.

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

Саме лише обмеження кроків не контролює вартість дослідження. За однакового бюджету в п’ять кроків openai/gpt-6.1-terra здійснює більше викликів інструментів, ніж openai/gpt-6-luna, оскільки потужніші моделі зазвичай ініціюють кілька викликів за один крок. Рівні зусиль обмежують і виклики інструментів, і кроки. Для цих моделей ліміт викликів інструментів важить так само, як і ліміт кроків.

Кожен рівень зусиль налаштовує ці обмеження, але агент також має знати, скільки кроків і дій у нього залишилося для виконання запиту. Без цієї інформації в нього можуть закінчитися кроки чи дії, і він буде змушений відповісти до завершення дослідження. Бюджет повідомляється на початку запуску, а нагадування надходять, коли агент наближається до своїх лімітів, тож залишається час перевірити й надати результати. Для рівня high нагадування охоплюють як бюджет кроків, так і бюджет викликів інструментів.

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

Тривалі дослідницькі завдання заповнюють контекстне вікно моделі результатами пошуку, отриманими сторінками та проміжними нотатками. Щойно вікно заповниться, агент мусить припинити роботу.

Ущільнення дає змогу довгим запускам працювати, не заповнюючи контекстне вікно. Коли контекст перевищує поріг, агент замінює виконану досі роботу коротшим підсумком того, що він знайшов і що ще залишилося, а потім продовжує.

Під час ущільнення в контексті завжди зберігаються три речі: системний промпт, початковий запит і всі навички, які агент уже завантажив. Після кожного ущільнення агент отримує дві короткі інструкції. Перша: «Продовжуй працювати, доки завдання не буде виконано». Це не дає агенту сприйняти підсумок як точку зупинки. Друга інструкція повідомляє агенту, скільки ущільнень уже відбулося, щоб він міг спланувати решту дослідницьких завдань. Довгі запуски не втрачають з поля зору початкову мету й план, а вартість довгих циклів знижується без втрати якості.

Кожна сторінка, яку читає агент, додається до його контексту, і агент несе її з собою на кожному наступному кроці. Вебсторінка містить інформацію, не пов’язану із запитанням, як-от навігацію, шаблонний текст та інший контент.

Замість того щоб передавати агенту всю сторінку, fetch_url спершу виконує прохід вилучення. Текст сторінки надсилається меншій моделі разом із поточним завданням агента. Модель повертає лише релевантні уривки, процитовані дослівно, щоб агент міг на них посилатися. Під час оцінювання сторінку обсягом 5 561 токен скоротили до 293 токенів, звільнивши місце для додаткового релевантного контексту.

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

Вебпошук — основа кожного дослідницького запиту агента. У те, як агенти виконують пошук, внесено три зміни:

Більше контексту на кожен пошук: тепер кожен пошук повертає до 4 тис. токенів результатів замість 2 тис. Агент швидше знаходить потрібне, тож пошуків стає менше, а вартість — нижча.

Новий рушій сніпетів: результати пошуку отримують сніпети, які краще відповідають запиту, тож агент не перевантажується нерелевантним текстом.
Швидкий пошук: за ціною 1,00 $ за 1 тис. запитів Fast Search знижує і вартість, і затримку кожного пошукового виклику.

Команда Perplexity Search постійно покращує якість пошуку в широкому спектрі завдань. Останні оновлення забезпечили покращення для коду, документації для розробників, довідкових сторінок, юридичного та регуляторного контенту.

Одні завдання потребують багатьох паралельних пошуків, інші — уважного читання кількох довгих документів.

Однак завантаження всіх робочих процесів у системний промпт агента збільшує навантаження на контекст і може призвести до того, що модель гірше справлятиметься з простими завданнями. Тому навички організовано в дерево з поступовим розкриттям. Модель завантажує релевантні навички та інструкції під час роботи, не додаючи до свого контексту непов’язану інформацію. Кожна навичка коштує лише своєї назви й опису, доки модель не вирішить, що вона підходить для завдання, і не завантажить її. Тоді до контексту додаються повні інструкції, і модель виконує передбачений робочий процес.

Щоб виміряти внесок окремих навичок, їх вилучають по одній і порівнюють якість і вартість на завданнях, у яких базовий агент завантажував відповідну навичку. Ці абляції показують, які робочі процеси допомагають агенту і як вони впливають на ефективність дослідження.

Наведені нижче запуски бенчмарку WANDR демонструють, як агенти обирають правильні робочі процеси для конкретних завдань. Інструкції wide-search і fanout завантажувалися для кожного завдання, що відображає потребу досліджувати кілька сутностей. Навичка people-search завантажувалася лише для 6% завдань і лише тоді, коли запитання стосувалися людей.

Під час тестування іншого завдання WANDR агент завантажив навичку people-search із шаблоном fanout, щоб знайти інженерів з інференсу в Лондоні. Він розгорнув 39 назв ролей у 117 запитів, а потім об’єднав результати першого проходу в 43 унікальні профілі для подальшого відбору. Навичка people-search провела агента через це розгортання, не додаючи нерелевантного контексту. Наведений нижче фрагмент адаптовано зі скрипту агента; назви допоміжних функцій умовні.

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 для оцінювання. Він перебирає значення параметра «Міркування», бюджети кроків і викликів інструментів та конфігурації інструментів, а потім оцінює кожен запуск за якістю й вартістю порівняно з поточними рівнями зусиль. Якщо запуск показує регрес, агент з’ясовує причину, коригує налаштування й повторює оцінювання. Кандидат замінює поточну модель лише тоді, коли перевершує її за якістю за такої самої або нижчої вартості.

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

Один агент може охопити за один цикл лише обмежену кількість джерел. Для складних завдань кілька агентів працюють паралельно, кожен — над своєю частиною проблеми.

Основний агент — це оркестратор. Він викликає spawn_agent, щоб створити дочірніх агентів, і доручає кожному конкретне, вузьке завдання. Кожен дочірній агент виконує власний цикл дослідження з окремим контекстом, використовуючи свою модель, інструменти та бюджет кроків. Дочірні агенти звітують про результати батьківському агенту, який може надіслати дочірньому наступне доручення або перевірити його прогрес. Оркестратор і дочірні агенти обмінюються повідомленнями, щоб ділитися доказами, позначати перешкоди та коригувати наступні кроки. Щойно надходить нова інформація, оркестратор уточнює доручення, а коли роботу завершено, об’єднує результати в єдину відповідь.

Agent API підтримує попередньо визначені ролі агентів, а оркестратор може створювати дочірніх агентів із власними інструкціями.

Рівень зусиль ultra запускає трьох агентів паралельно над одним завданням. Кожен агент незалежно досліджує завдання повністю, тож отримує різні докази. Четвертий агент об’єднує їхні результати, усуває дублікати й пише фінальну відповідь.

На WANDR ultra набирає 85,9% за 21,71 $ за завдання. Це найвищий результат серед протестованих конфігурацій.

Рівні зусиль постійно оцінюються та вдосконалюються. Рівень, який обирає користувач, визначає, скільки дослідження отримає завдання і скільки воно коштуватиме. Бюджети кроків і викликів інструментів разом із нагадуваннями в міру їх вичерпання утримують запити в межах бюджету. Ущільнення, вилучення та кращі сніпети зосереджують контекст на доказах. Навички підбирають робочий процес відповідно до завдання, а паралельні агенти розширюють те, що може охопити один цикл. Автоматизований цикл оцінювання допускає нову модель лише тоді, коли вона покращує якість дослідження за тієї самої вартості.

Кожен рівень зусиль і далі розвиватиметься в міру того, як нові моделі та конфігурації доводитимуть свою ефективність під час оцінювання. Якщо викликати рівень за назвою, ці покращення застосовуються автоматично; закріплення версії фіксує конфігурацію.

Спробуйте Agent API і порівняйте рівні зусиль на власних робочих навантаженнях. Докладніше про рівні зусиль — у нашій документації щодо зусиль в Agent API.

Вартість дослідження

Контроль бюджету на дослідження

Керування контекстом

Ущільнення

Отримання лише важливого

Цільовий вебпошук

Вибір правильного робочого процесу

Вибір моделі

Багатоагентне масштабування

Що далі