Perplexity превращает поиск в код: что даёт архитектура Search as Code

Что нового

Perplexity перестраивает свой поиск под агентные сценарии и называет это Search as Code (SaC).

Ключевые изменения:

1. Поиск как SDK, а не один чёрный ящик

   • Вместо одного фиксированного /search теперь есть набор примитивов в виде Python‑SDK.
   • Модель управляет отдельными шагами: извлечение документов, ранжирование, фильтрация, фан-аут по вариантам запросов, агрегация, рендеринг.

2. Всё управление — через сгенерированный код

   • Никаких function calling и MCP для поиска внутри SaC.
   • Модель пишет Python‑код, который выполняется в защищённом sandbox‑окружении.
   • За один прогон LLM можно запустить сотни и тысячи операций поиска вместо десятков последовательных вызовов API.

3. SDK поверх полностью переразобранного поискового стека Perplexity

   • Инженеры разрезали прежний монолитный поиск на низкоуровневые модули: субдокументный поиск, комбинирование семантических и лексических сигналов, фильтры, агрегации.
   • Высокоуровневые «готовые» пайплайны в SDK остались, но теперь это всего лишь шорткаты, а не единственный вариант.

4. Python как основной язык исполнения

   • Рассматривали Python, Rust, TypeScript и Bash.
   • После внутренних тестов выбрали Python как лучший вариант для LLM с точки зрения привычности и экосистемы библиотек обработки данных.
   • Perplexity оставляет за собой право сменить рантайм, если это улучшит работу агентов.

5. Автоисследование (autoresearch) для улучшения SDK и навыков

   • Запущен непрерывный цикл: модель сама предлагает изменения в SDK, проверяет их по трём метрикам — латентность, качество генерируемого кода, итоговая успешность задач.
   • За несколько недель такой оптимизации SDK уже сильно поменялся по структуре и «эстетике» (имена функций, сигнатуры, паттерны использования).
   • Тот же цикл использован для настройки Agent Skills, которые учат модели правильно пользоваться SDK.

6. Новая архитектура трёх слоёв

   • Модели — «мозг» и контрольный план: разбирают задачу, планируют пайплайн поиска, пишут код.
   • Sandbox‑окружение — безопасный рантайм для исполнения кода, с доступом к SDK и файловой системе.
   • Agentic Search SDK — слой примитивов поверх поисковой инфраструктуры Perplexity.

7. Работа с промежуточным состоянием через файловую систему

   • Тестировали два подхода: REPL с сохранением переменных в памяти и файловую систему с явной сериализацией.
   • В длинных сценариях лучше показал себя вариант с persistent filesystem + явной сериализацией/десериализацией.
   • Модели записывают промежуточное состояние в файлы и читают его в следующих шагах, вместо того чтобы тащить всё через токены.

8. Новый уровень управляемости поиска для агентов

   • Модель получает доступ к сигналам ранжирования, спискам кандидатов и другим промежуточным данным, а не только к финальному списку ссылок.
   • Можно строить и оптимизировать «на лету» пайплайны из тысяч операций поиска.

9. Практические результаты

   • Perplexity заявляет, что SaC сдвигает «фронтир» по соотношению стоимость/качество для агентного поиска на наборе внутренних и публичных бенчмарков.
   • Конкретных чисел в описании нет, но подчёркивается, что выигрыш достигается именно за счёт более точного и дешёвого обращения к поисковому стеку.

SaC уже внедряется во все ключевые продукты Perplexity: Search API, Agent API и Perplexity Computer. Внутри Computer отдельные задачи уже запускают сотни и тысячи операций поиска за несколько минут — руками так работать невозможно, но для агентов это нормальный режим.

Как это работает

1. От монолита к программируемому стеку

Классический сценарий выглядел так:

1. LLM формирует текстовый запрос.
2. Поисковый сервис запускает внутри себя фиксированный пайплайн: парсинг, извлечение, ранжирование, постобработка.
3. Модель получает готовый набор документов и использует его как контекст.

LLM мог управлять только параметрами запроса: текст, иногда фильтры, количество документов. Всё, что происходило дальше, оставалось «под капотом» и не поддавалось тонкой настройке.

SaC меняет границу ответственности:

• Модель больше не вызывает «один большой поиск» как функцию.
• Модель пишет код, который шаг за шагом вызывает примитивы SDK: например, сначала быстрый широкоугольный поиск, потом уточняющий семантический, потом агрегацию и фильтр по доменам.

2. Agentic Search SDK

Perplexity не просто обернула существующий API в библиотеку. Поисковый стек заново разложили на модули и открыли их через SDK.

В SDK есть два уровня:

• Высокоуровневые функции — готовые пайплайны «как раньше», когда нужен простой поиск или когда модель не хочет тратить токены на сложное планирование.
• Низкоуровневые примитивы — отдельные шаги:
  • извлечение документов по ключевым словам;
  • семантический поиск;
  • комбинирование сигналов;
  • фильтрация по источникам;
  • дедупликация;
  • агрегация по ключам (например, по сайту или автору);
  • рендеринг фрагментов под потребности LLM (субдокументный поиск, компактные сниппеты).

Модель может свободно смешивать эти уровни: где-то использовать готовый пайплайн, где-то вручную собрать кастомный.

3. Python‑sandbox как исполнитель

Сгенерированный моделью код не уходит напрямую на сервер с правами root. Perplexity запускает его в защищённом окружении:

• Изолированный рантайм: модель не может выйти за пределы доступных библиотек и SDK.
• Детерминированность: sandbox контролирует вычисления, чтобы результаты были воспроизводимыми.
• Доступ к SDK и файловой системе: код может вызывать примитивы поиска и читать/писать файлы для хранения промежуточных результатов.

Сценарий работы:

1. Модель получает задачу от пользователя или «родительского» агента.
2. Планирует, какие шаги поиска и обработки нужны.
3. Генерирует Python‑код, используя подсказки из Agent Skills.
4. Код выполняется в sandbox, вызывает SDK, сохраняет промежуточные данные при необходимости.
5. Результаты (не обязательно сырые документы, а уже отфильтрованный и агрегированный материал) возвращаются модели как контекст для следующего шага рассуждений.

4. Управление состоянием между шагами

Perplexity протестировала два подхода к хранению состояния между шагами агента.

Вариант 1: REPL‑подход

• Sandbox сохраняет весь контекст исполнения: переменные, объекты, состояние.
• В следующем шаге модель просто продолжает писать код, обращаясь к уже существующим переменным.
• Плюс: минимум токенов — не нужно писать код сериализации.
• Минус: со временем пространство имён «засоряется», модель сложнее отслеживает, какие данные актуальны и зачем они нужны.

Вариант 2: файловая система + явная сериализация

• Sandbox предоставляет постоянную файловую систему, доступную между шагами.
• Модель сама решает, какие данные сохранить: пишет код save_*() и load_*() с помощью утилит SDK.
• Плюс: явный контроль над тем, что сохраняется и зачем. Легче отлаживать и отслеживать траекторию агента.
• Минус: дополнительные строки кода и небольшая задержка на сериализацию.

В тестах оба варианта показали схожую производительность на коротких задачах. Но на длинных цепочках действий файловая система с явной сериализацией оказалась надёжнее. Perplexity связывает это с тем, что требование «объявить, что именно ты сохраняешь» дисциплинирует модель и снижает хаос в состоянии.

В итоге SaC использует persistent filesystem + serde как основной вариант, но команда продолжает экспериментировать с подходами.

5. Agent Skills: как научить модель пользоваться SDK

SDK сам по себе — это просто набор функций. Чтобы LLM начала использовать его эффективно, Perplexity настроила специальные Agent Skills.

Особенности этих навыков:

• Написаны по внутренним принципам дизайна Skills Perplexity.
• Оптимизированы через отдельный autoresearch‑цикл с теми же метриками, что и для SDK: латентность, качество кода, итоговый успех задачи.
• Жёсткое ограничение размера: менее 2000 токенов в корневом SKILL.md. Это важно, чтобы не раздувать контекст и не съедать лимит модели.

Содержимое Skills:

• Не просто список функций SDK (его можно получить через рефлексию в рантайме).
• Краткие, но обобщаемые рекомендации: какие паттерны пайплайнов подходят под какие задачи.
• Несколько примеров «как собрать сложный пайплайн из примитивов».

После настройки Skills Perplexity наблюдает, что frontier‑модели уверенно строят пайплайны с тысячами операций поиска в рамках одной задачи.

Что это значит для вас

Для кого вообще SaC

SaC — это не один новый «поисковик» для ручного использования, а архитектура для продуктов Perplexity. Она важна, если вы:

• строите агентные системы, которые должны много читать, сравнивать и проверять информацию;
• используете Perplexity Search API, Agent API или Perplexity Computer;
• разрабатываете сложные пайплайны, где поиск — не один шаг, а постоянный фоновый процесс.

Если вы просто задаёте один вопрос LLM и ждёте один ответ, разницу вы почти не заметите. SaC раскрывается на длинных задачах.

Где SaC помогает

1. Сложные исследовательские запросы
   Пример: агенту нужно сравнить десятки отчётов, собрать статистику, проверить противоречия.

   Что даёт SaC:

   • Агент может разнести задачу на этапы: широкий сбор, фильтрация по источникам, проверка дат, поиск уточняющих фактов.
   • В каждом этапе он использует разные стратегии поиска и разные примитивы SDK.
   • В контекст модели попадает только то, что реально нужно для рассуждений, а не груда сырых документов.

2. Массовые фан-ауты и параллельные запросы
   Если нужно:

   • прогнать сотни вариантов запросов;
   • собрать результаты;
   • дедуплицировать и отсортировать по важности.

   В классическом подходе это сотни вызовов LLM с отдельными поисковыми запросами.
   В SaC модель один раз генерирует код, который сам делает параллельные вызовы к поисковому стеку, агрегирует и возвращает уже сжатый результат.

3. Задачи с жёстким лимитом контекста
   Frontier‑модели хорошо рассуждают по компактному, плотному контексту. SaC позволяет:

   • не тащить в контекст все промежуточные списки документов;
   • оставить тяжёлую фильтрацию, дедупликацию и сортировку внутри кода;
   • «кормить» модель уже отфильтрованными, релевантными фрагментами.

4. Доменные сценарии с особыми правилами поиска
   Если у вас свой набор источников, свои правила приоритизации и фильтрации, свои способы агрегировать данные, SaC позволяет:

   • явно зашить эти правила в пайплайны;
   • использовать знания модели о домене при выборе стратегии поиска (например, когда сочетать лексический и семантический поиск, какие источники доверять).

5. Длинные агентные сессии (часы и дни)
   SaC даёт агенту файловую систему для промежуточных результатов.
   Агент может:

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

Где SaC не особенно нужен

1. Простые одношаговые вопросы
   «Кто выиграл матч вчера?» или «объясни, что такое attention в нейросетях» — тут достаточно обычного поиска или даже знаний модели.

2. Сценарии без кода и без агентов
   Если вы не используете Perplexity как платформу для агентов, а просто задаёте вопросы в интерфейсе, SaC останется «под капотом».

3. Системы, где поиск — второстепенен
   Если ваш агент в основном работает с внутренними базами данных, API и действиями (например, бронирование, управление CRM), а веб‑поиск — редкий гость, выигрыши от SaC будут ограниченными.

Важные ограничения

• SaC — архитектура внутри Perplexity. Это не отдельный открытый продукт, который можно поставить локально.
• Для доступа к SaC вам нужен доступ к продуктам Perplexity (Search API, Agent API, Computer). В российских сетях такой доступ может потребовать VPN, как и для многих западных AI‑сервисов.

Место на рынке

По сравнению с классическим поиском

Большинство поисковых систем, даже «заточенных под ИИ», продолжают работать по схеме:

• LLM формирует запрос.
• Поиск возвращает готовый SERP или набор фрагментов.
• LLM читает и отвечает.

Даже если под капотом есть векторные индексы, субдокументный поиск и сложные ранжировщики, модель не может ими управлять. SaC сдвигает границу: модель получает прямой доступ к этим шагам через код.

По сравнению с function calling / MCP

Многие агентные фреймворки сейчас опираются на function calling и MCP:

• Модель вызывает «функцию поиска» или MCP‑инструмент.
• Каждый вызов — отдельный шаг диалога с LLM.
• Чтобы сделать сложный пайплайн, нужно много шагов, каждый из которых стоит токены и время.

SaC убирает этот «челнок» между моделью и поиском:

• Модель один раз генерирует код.
• Код сам вызывает нужные примитивы поиска десятки и сотни раз.
• В LLM возвращается уже агрегированный итог.

Это снижает латентность и стоимость сложных сценариев, потому что дорогой ресурс — вызовы LLM — используются реже, а дешёвый ресурс — вычисления в sandbox и обращения к поисковому стеку — чаще.

По сравнению с другими агентными платформами

Многие платформы для агентов дают доступ к поиску в виде одного или нескольких инструментов:

• «web_search(query)»;
• иногда: «web_search_news», «web_search_scholarly» и т.п.

Perplexity делает ставку на более низкий уровень абстракции:

• SDK с примитивами вместо набора крупных инструментов.
• Python‑sandbox как стандартный способ оркестрации.
• Автоисследование для постоянной подстройки SDK под поведение frontier‑моделей.

Точных сравнительных цифр по скорости или стоимости с GPT‑4o, Claude 3.5 или другими стеками Perplexity не приводит. Но из описания архитектуры видно, что ставка сделана на снижение числа LLM‑вызовов в сложных сценариях и на более точное использование поискового индекса.

Как запустить (концептуально)

Исходный текст не содержит готовых фрагментов кода SDK, но по описанию архитектуры рабочий сценарий для разработчика или продуктовой команды, использующей Perplexity Computer / Agent API, выглядит так:

1. Определяете задачу агента
   Например: «собрать и сопоставить данные из сотен статей по теме X за последние два года, найти противоречия, подготовить отчёт».

2. Подключаете Perplexity Agent API или Computer

   • Настраиваете агента с нужной моделью.
   • Включаете доступ к SaC (он интегрирован в эти продукты).

3. Определяете стратегию поиска
   В промпте или конфигурации агента описываете:

   • какие источники приоритетны;
   • как относиться к новизне/старым данным;
   • какие типы документов нужны (статьи, отчёты, документация);
   • как проверять противоречивую информацию.

4. Агент сам собирает пайплайн через SDK

   • Модель, опираясь на Agent Skills, пишет Python‑код с вызовами примитивов SDK.
   • Код запускается в sandbox, делает десятки/сотни поисковых операций, сохраняет промежуточные результаты в файловую систему.
   • В контекст модели возвращаются только агрегированные и отфильтрованные данные.

5. Вы получаете результат
   Агент формирует отчёт, графики, резюме — в зависимости от задачи и настроек.

Для конечного пользователя это всё выглядит как «агент, который лучше и стабильнее ищет и анализирует», но под капотом именно SaC делает тяжёлую работу по оркестрации поиска.

---

SaC — это шаг от «поиска как сервиса» к «поиску как программируемому стеку» внутри Perplexity. Если вы строите агентные системы, которые много взаимодействуют с веб‑знаниями, архитектура Perplexity даёт больше контроля над тем, что именно и как попадает в контекст модели, и позволяет экономнее расходовать дорогие вызовы LLM на фоне всё более сложных задач.

---

Читайте также

• Microsoft Purview научили защищать данные в AI‑агентах — от локального Copilot до сторонних приложений
• Microsoft запустила серверless‑рантайм для AI‑агентов в Azure Functions (паблик превью)
• Microsoft расширяет Azure API Management: единый вход для API, моделей, агентов и MCP-инструментов