Улучшения всех уровней усилий 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 сначала выполняет проход извлечения. Текст страницы отправляется в модель меньшего размера вместе с текущей задачей агента. Модель возвращает только релевантные фрагменты, процитированные дословно, чтобы агент мог на них ссылаться. Во время оценки страница объёмом 5561 токен была сокращена до 293 токенов, что освободило место для дополнительного релевантного контекста.

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

Веб-поиск лежит в основе каждого исследовательского запроса агента. В то, как агенты выполняют поиск, внесены три изменения:

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

Новый механизм фрагментов: результаты поиска получают фрагменты, которые точнее соответствуют запросу, поэтому агент не перегружается нерелевантным текстом.
Быстрый поиск: при стоимости 1,00 $ за 1000 запросов 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 для оценки. Он перебирает интенсивность рассуждения, бюджеты шагов и вызовов инструментов, а также конфигурации инструментов и оценивает каждый запуск по качеству и стоимости в сравнении с текущими уровнями усилий. Если результаты запуска ухудшаются, агент выясняет причину, корректирует настройки и снова запускает оценку. Кандидат заменяет текущую модель, только если превосходит её по качеству при той же или более низкой стоимости.

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

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

Основной агент выступает оркестратором. Он вызывает spawn_agent, чтобы создать дочерних агентов, и назначает каждому конкретную узкую задачу. Каждый дочерний агент выполняет собственный исследовательский цикл с отдельным контекстом, используя свою модель, инструменты и бюджет шагов. Дочерние агенты передают результаты родительскому агенту, который может отправить дочернему дополнительное задание или проверить ход его работы. Оркестратор и дочерние агенты обмениваются сообщениями, чтобы делиться найденными сведениями, сообщать о препятствиях и корректировать дальнейшие шаги. По мере поступления новой информации оркестратор уточняет задания, а когда работа завершена, объединяет результаты в единый ответ.

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

Уровень усилий ultra параллельно запускает трёх агентов на одной задаче. Каждый агент независимо исследует всю задачу, поэтому собирает разные сведения. Четвёртый агент объединяет их результаты, удаляет дубликаты и пишет итоговый ответ.

На WANDR уровень ultra набирает 85,9 % при стоимости 21,71 $ за задачу. Это самый высокий результат среди протестированных конфигураций.

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

Каждый уровень усилий продолжит развиваться по мере того, как новые модели и конфигурации будут подтверждать свою эффективность при оценке. При обращении к уровню по имени эти улучшения применяются автоматически; закрепление версии фиксирует конфигурацию.

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

Стоимость исследования

Управление бюджетом исследования

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

Сжатие контекста

Извлечение только важного

Целенаправленный веб-поиск

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

Выбор модели

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

Что дальше