Perplexity Fast Search или web: какой режим выбрать

Perplexity Fast Search или режим по умолчанию: что выбрать?

Выбирайте Fast Search для ограниченных и повторяемых задач, а стандартный web — когда один пропущенный источник может изменить решение. Fast выигрывает по цене и задержке. Стандартный web — по качеству поиска и вероятности найти материал для ответа. В рабочем агенте запросы стоит распределять между режимами, а не отправлять все через один.

В актуальном руководстве Perplexity по Fast Search режим fast рекомендуется для повседневной работы агентов, а стандартный web — для редких, сложных или неоднозначных вопросов. Цены и замеры поставщика в этом сравнении сверены с актуальными страницами Perplexity 24 сентября 2026 года.

Независимому разработчику, который запускает агента поддержки, стоит начать с режима fast для типовых запросов к документации и статусам, а при пустой или слабой доказательной базе переключаться на web. Доплата $0.004 за вызов стандартного web невелика, если промах приводит к ручной проверке, но расточительна для низкорискового запроса, который повторяется тысячи раз.

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

Техническому директору компании среднего бизнеса стоит сохранить стандартный web для закупок, безопасности, регулирования и разбора инцидентов, пока внутренний повторный прогон не покажет, что Fast Search сохраняет необходимый набор источников. Запрос, который дешевле в пять раз, не даёт экономии, если аналитику приходится восстанавливать доказательную базу вручную.

Perplexity Fast Search API: что изменилось с Photon

Fast Search меняет бюджет на поиск, но не эндпоинт и не схему результата. Компания Perplexity представила этот режим 24 сентября 2026 года на базе Photon — собственной системы поиска и ранжирования. Актуальная документация Fast Search подтверждает: тот же эндпоинт POST /search возвращает тот же ранжированный массив results[], а в запрос достаточно добавить search_type: "fast".

Если не передать search_type, Perplexity использует стандартный web. Это важно: «по умолчанию» здесь не означает стандартную языковую модель в пользовательском приложении Perplexity. Речь идёт о стандартном режиме извлечения данных в Search API. Оба режима возвращают заголовки, URL, сниппеты, а также необязательные даты публикации и обновления для дальнейшей обработки.

В описании релиза Photon говорится, что движок читает только необходимые для запроса данные, совмещает ожидание дисковых операций и использует кэширование с учётом пакетов; на официальной архитектурной схеме Perplexity показан путь запроса через брокер и шарды. Эти инженерные решения объясняют заявленную скорость. Но они не отменяют осознанный компромисс в ранжировании: Fast Search использует меньше вычислительных ресурсов, уступая в широте и качестве поиска.

Perplexity Photon — движок, а не третий режим

Photon — инфраструктурная часть поискового стека Perplexity. На уровне API по-прежнему доступны fast, web и отдельный тип поиска people. Разработчик не выбирает Photon напрямую, не развёртывает его и не получает ответ другого формата.

Есть и практический нюанс с текущими SDK. Для версий Python-библиотеки 0.43.4 и 0.43.5 Perplexity указывает extra_body={"search_type": "fast"}, потому что прямая валидация отклоняет новое значение. В примере для TypeScript с SDK 0.38.5 используется приведение "fast" as any, пока типы не обновлены. Прямые HTTP-запросы обходят оба временных ограничения клиента.

Стоимость Perplexity Search API: $10 против $50 при 10,000 запросов

Победитель — Fast Search. По актуальному тарифу Perplexity, 1,000 успешных базовых запросов Fast Search стоят $1, а 1,000 запросов стандартного web — $5; отдельной платы за токены Search API нет.

Расчёт для сопоставимой нагрузки прост:

• 10,000 вызовов Fast Search: 10,000 × $0.001 = $10.
• 10,000 вызовов стандартного web: 10,000 × $0.005 = $50.
• Разница: $40, то есть базовая строка расходов на поиск сокращается на 80%.

Эти $40 — не весь счёт за работу агента. Дальше оплачиваются модель, которая читает результаты, дополнительные загрузки, повторы, валидация и ручная проверка. Fast выигрывает лишь в том случае, если не создаёт более $40 дополнительных расходов на пакет из 10,000 вызовов.

Успешный пустой ответ тоже оплачивается

Успешный ответ на POST /search тарифицируется, даже если массив results[] пуст. Согласно действующим правилам тарификации, некорректные запросы, запросы с ограничением по частоте и сбои вышестоящих систем не оплачиваются. Поэтому доля пустых результатов — не только показатель качества, но и бюджетная метрика.

Пакетирование меняет счёт, но не критерий качества

Краткое руководство Perplexity по нескольким запросам позволяет передать до пяти связанных запросов за один раз. Успешный мультизапрос считается одной единицей тарификации, хотя каждый входящий запрос по-прежнему учитывается в лимитах частоты. Поэтому двадцать запросов, объединённых в четыре обращения для каждого режима, в сумме обойдутся в $0.024, тогда как 40 отдельных одиночных запросов будут стоить $0.12.

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

Тарифы инструментов Agent API должны оставаться отдельной строкой бюджета

В таблице инструментов Agent API указаны другие стандартные цены: $1 за 1,000 вызовов быстрого web_search и $2.50 за 1,000 вызовов стандартного web, плюс стоимость токенов выбранной модели. Это не тарифы базового Search API — $1 и $5. Кроме того, Fast Search не равен отдельному пресету fast в Agent API, несмотря на одинаковое слово.

Предыдущее сравнение стоимости Perplexity, Exa и Tavily отвечает на вопрос, какого поставщика выбрать. Здесь решение принимается уровнем ниже — когда Perplexity уже входит в стек.

По задержке выигрывает Fast — с оговоркой о замерах поставщика

Победитель — Fast Search, если опираться на замеры Perplexity. На официальном графике задержки Perplexity указаны 160 ms на p50 и 230 ms на p95 для одиночного вызова Fast Search. В сопроводительном тексте анонса и актуальном руководстве по Fast Search нет сопоставимых p50 и p95 для стандартного web, поэтому честно назвать парное соотношение задержек нельзя.

Процентили здесь важны. p50 — время среднего запроса. p95 — порог, в который укладываются 95% запросов. Агент с несколькими последовательными поисковыми вызовами сильнее ощущает длинный хвост, чем медиану: один медленный вызов инструмента способен задержать выполнение всего плана.

Поэтому Fast заслуживает место в сценариях, чувствительных к задержке, но для продакшена ответ по-прежнему зависит от конкретной нагрузки. Расстояние до сети, фильтры, запрошенное число результатов, объём извлечённого контекста, пакетирование и политика повторов — всё это влияет на итоговое время, которое видит агент. Цифра поставщика — отправная точка, а не гарантия уровня сервиса для любой интеграции.

Практическая формулировка Mikhail Basyuk задаёт верный стандарт: p95 ниже 250 ms полезен только в том случае, если сохраняется необходимая для задачи релевантность. Скорость и доказательная база должны находиться на одной панели мониторинга.

По охвату выигрывает стандартный web

Победитель для сложных и неоднозначных исследований — стандартный web. Во внутреннем графике качества поиска Perplexity у Fast Search оценка релевантности составляет 2.21, у стандартного режима — 2.45, разница равна 0.24 балла. Доступность ответа — 0.567 против 0.596, разрыв составляет 2.9 процентного пункта.

Релевантность показывает, насколько хорошо ранжированный материал соответствует запросу. Доступность ответа — нашлось ли достаточно материала, чтобы подкрепить ответ. Fast может сработать быстро, но оставить следующей модели более слабую доказательную базу. Поэтому широкий вопрос о политике, сравнение нескольких компаний или спорное утверждение стоит отправлять в стандартный web, даже если быстрый путь субъективно кажется отзывчивым.

При этом на сводном графике поставщика приведён на первый взгляд противоположный результат по шести публичным бенчмаркам для агентов и 3,554 отобранным задачам: Fast набрал 64.3% при расчётной общей стоимости модели и поиска $59.73, а стандартный режим — 64.0% при $187.60. По описанию поставщика, быстрая конфигурация примерно на 68% дешевле при сопоставимом совокупном качестве выполнения задач.

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

В более широком руководстве по поисковым API для ИИ тот же принцип применяется к разным поставщикам: покупайте самый дешёвый уровень поиска, который выдаёт пакет доказательств, приемлемый для следующей детерминированной проверки.

Как включить режим fast в Perplexity Search API

Дважды отправьте один и тот же запрос, меняя только search_type. Оставьте неизменными query, max_results, search_context_size, фильтры, регион и местоположение клиента. В актуальном справочнике Search API указано, что web используется по умолчанию, стандартное значение max_results равно 10, а стандартный размер извлекаемого контекста — high. Явно задайте оба параметра сравнения, чтобы будущее изменение значений API по умолчанию не повлияло на повторный прогон.

Эта пара запросов готова к запуску без изменений:

set -euo pipefail
: "${PERPLEXITY_API_KEY:?Set PERPLEXITY_API_KEY first}"

QUERY='Which CRM has the stronger current EU data residency and audit-control evidence?'
COMMON=$(jq -nc --arg query "$QUERY" '{
  query: $query,
  max_results: 10,
  search_context_size: "high"
}')

for MODE in fast web; do
  jq --arg mode "$MODE" '. + {search_type: $mode}' <<<"$COMMON" |
    curl -sS 'https://api.perplexity.ai/search' \
      -H "Authorization: Bearer $PERPLEXITY_API_KEY" \
      -H 'Content-Type: application/json' \
      -o "$MODE.json" \
      -w "$MODE\tHTTP %{http_code}\t%{time_total}s\n" \
      --data-binary @-
done

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

Возьмите 20 запросов для бизнес-исследований: 10 конкретных задач с ожидаемым авторитетным источником и 10 неоднозначных вопросов, для которых нужно несколько источников. В практический фиксированный набор можно включить актуальные цены SaaS, лимиты облачных сервисов, даты вступления правил в силу, поддерживаемые страны, меры безопасности, свежую отчётность, сравнения поставщиков, последствия политик, вопросы полной стоимости и утверждения, по которым есть убедительные доказательства с обеих сторон.

При одиночных запросах эти 40 успешных базовых обращений обойдутся в $0.12 без учёта последующих вызовов модели: $0.02 за 20 вызовов fast плюс $0.10 за 20 вызовов стандартного web.

Ключевой показатель — не среднее число результатов. Груда слабых ссылок может быть хуже небольшого набора первичных источников. Полезный охват и подтверждённые ответы — именно те метрики, которые придают смысл цене и задержке.

Во что на самом деле обходится переключение

Изменить тело запроса легко; основная работа — изменить правила эксплуатации. Перевод нагрузки со стандартного web на fast не требует миграции данных или нового эндпоинта. Но он всё равно влияет на поиск, идентификатор кэша, мониторинг и обработку сбоев.

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

Записывайте режим каждого запроса и каждого последующего утверждения. Иначе снижение доли принятых источников будет выглядеть как дрейф модели или случайный поисковый шум. Маршрутизатору также нужна явная причина эскалации, например empty_results, missing_primary_source, ambiguous_query или high_impact.

Повторы должны учитывать режим. Повтор после тайм-аута в том же режиме — мера доступности. Повтор с переключением fast на web — повышение качества, которое меняет цену. Эти события нельзя учитывать одним счётчиком.

Кому не стоит переходить

Не делайте Fast Search универсальным режимом по умолчанию, если:

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

Лучший путь миграции — поэтапное внедрение с маршрутизацией. Переведите на fast один повторяемый класс, сохраните web как путь эскалации и сравните принятую доказательную базу, прежде чем расширять охват.

Что сделать в понедельник

Сначала внедрите простое правило поиска, а уже потом меняйте глобальную настройку по умолчанию. Повторяемые низкорисковые запросы направляйте в fast, неоднозначные или критичные — в web. Отклонение доказательств должно автоматически приводить к эскалации, а не к незаметно слабому ответу.

Начните с запросов прошлой недели, а не с придуманных демонстраций. Выберите 20 примеров обычной работы продукта, разделите их на конкретную и неоднозначную группы и повторите описанную выше пару запросов. Если все 40 одиночных запросов завершатся успешно, тест обойдётся в $0.12 базовой платы за поиск.

Во вторник оцените четыре результата: p95 задержки запроса, успешные пустые ответы, охват полезных источников и подтверждённость ответа источниками. Если fast проходит порог качества для конкретной группы, переведите только этот класс. Если в неоднозначной группе пропадает первичный источник, оставьте там стандартный web независимо от сводного бенчмарка.

Таков бизнес-смысл Photon: не единая дешёвая глобальная настройка, а практический маршрутизатор поискового риска. Агент тратит $1 за 1,000 вызовов, когда запрос допускает промах, и доплачивает $4 только там, где более широкий поиск способен предотвратить куда более дорогую ошибку.

Часто задаваемые вопросы

Хотите собрать маршрутизацию, валидацию и расчёт стоимости в одной рабочей таблице? Скачайте чек-лист аудита бизнес-процессов с ИИ и спроектируйте первый маршрутизатор поискового риска уже в понедельник.