Perplexity представила Photon: движок извлечения на Rust, сокращающий p99-задержку с 800 до 65 мс

Perplexity выпустила Photon — собственный движок поиска и ранжирования, написанный на Rust. Он заменил движок с открытым исходным кодом, который Perplexity форкнула для своего AI-native поискового стека. Теперь Photon обрабатывает поиск и ранжирование всего производственного трафика. Он также лежит в основе нового режима Fast Search в Search API Perplexity. Perplexity сообщает о задержке одного вызова 160 мс на p50 и 230 мс на p95.

Можно ли его развернуть? Да, в виде размещённого API. Укажите search_type: "fast" в POST /search и платите $1 за 1 000 запросов. Сам Photon не имеет открытого исходного кода, поэтому самостоятельно разместить этот движок нельзя.

Почему Perplexity заменила старый движок

По мере роста индекса старый движок столкнулся с тремя ограничениями:

• Хвостовая задержка: Производственный p99 составлял около 800 мс. Объём набора данных превысил доступный объём ОЗУ, поэтому использовать mlock было невозможно. Холодное чтение вызывало массовые страничные сбои, из-за которых запросы останавливались.
• Скачки при слиянии: Во время объединения дисковых индексов p99 возрастал примерно до 1,2 с на 10–15 минут.
• Медленное восстановление: Развёртывание и синхронизация дополнительного кластера могли занимать больше недели. Восстановление также увеличивало долю частичных ответов.

Команда Perplexity пришла к выводу, что разработка с нуля была проще и дешевле, чем поддержка собственного форка.

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

Балансировщик нагрузки направляет каждый запрос брокеру Photon. Брокер распределяет запросы по группе шардов и отслеживает тайм-ауты. Каждый шард выполняет поиск, первоначальное ранжирование и ранжирование на втором этапе. Затем брокер объединяет кандидатов и извлекает ключевые поля документов.

• Адаптивные списки публикаций: Короткие списки хранятся непосредственно внутри одной страницы. Более длинные списки разбиваются на блоки с фиксированными диапазонами идентификаторов документов. Разреженные блоки хранят отсортированные массивы смещений и используют «галопирующий» поиск. Плотные блоки используют битовые карты, поэтому проверка принадлежности сводится к одному обращению к биту.
• Обход с ограниченным бюджетом: Алгоритм, похожий на WAND, разделяет списки на ведущие и проверочные. Сначала дешёвые проверки наличия ограничивают максимальную оценку каждого кандидата. Точные частоты терминов считываются только тогда, когда кандидат может преодолеть порог.
• Записи docblob: Для каждого документа создаётся компактная запись с частотами, масками полей и позициями. Для терминов используется кодирование Elias–Fano, поэтому при ранжировании декодируются только совпавшие термины. Для ранжирования кандидата требуется всего одно обращение к документу.
• Пакетные асинхронные чтения: Смещения записей известны заранее, поэтому чтение с диска выполняется пакетами через io_uring. Сначала кэш проверяет весь пакет. Читатели не используют блокировки, а для вытеснения применяется CLOCK вместо общей LRU-очереди.
• Раздельные сборка и обслуживание: Индексаторы создают версионированные индексы шардов из таблиц YTsaurus на выделенных узлах. Контроллер поочерёдно переключает группы обслуживания и прогревает кэши с помощью повторно воспроизводимых запросов из журнала поиска.

Теперь полный веб-индекс создаётся за однозначное количество часов.

Интерактивное объяснение: внутри Photon

Результаты в производственной среде

• Задержка поиска и ранжирования на уровне p99 снизилась примерно с 800 мс до 65 мс. Это охватывает только этапы Photon.
• Photon работает примерно на 20% меньшем количестве обслуживающих машин, чем старые узлы контента.
• Он хранит примерно в 2,5 раза больше данных на документ, что Perplexity использовала для повышения качества ранжирования.
• Для закрепления того же набора данных с помощью mlock потребовалось бы примерно в 4,6 раза больше резидентной памяти, чем Photon использует сегодня.
• Переключение версий индекса больше не вызывает скачков задержки.

Fast Search: скорость и стоимость для агентов

Fast Search объединяет Photon с более лёгким ранжированием, оптимизированным для агентских рабочих процессов. Perplexity протестировала его на 6 бенчмарках: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 и SEAL-Hard. В 3 554 задачах Fast набрал 64,3% при расчётной совокупной стоимости модели и поиска $59,73. Пресет по умолчанию набрал 64,0% при стоимости $187,60, поэтому Fast оказался примерно на 68% дешевле.

Компромисс проявляется в более широком качестве поиска. На внутренних бенчмарках для длинного хвоста релевантность (DCG) снизилась с 2,45 до 2,21. Доступность ответа упала с 0,596 до 0,567 — на 2,9 процентного пункта. Perplexity рекомендует Fast для повседневных агентских циклов, а пресет по умолчанию — для сложных неоднозначных запросов.

curl -X POST 'https://api.perplexity.ai/search' \
  -H "Authorization: Bearer $PERPLEXITY_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"query": "latest stable Rust release", "search_type": "fast", "max_results": 5}'

В Python SDK 0.43.4 и 0.43.5 передавайте extra_body={"search_type": "fast"} согласно документации.

Fast Search и ближайшие конкуренты

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

Основные выводы

• Photon — движок поиска и ранжирования Perplexity на Rust, который теперь обслуживает весь производственный трафик.
• Производственная задержка p99 снизилась примерно с 800 мс до 65 мс.
• Fast Search показывает 160 мс на p50 и 230 мс на p95 при цене $1 за 1 000 запросов.
• Fast снизил расчётную стоимость агентской задачи примерно на 68% при сопоставимом качестве выполнения задач.
• Он жертвует частью релевантности поиска, поэтому для сложных запросов следует использовать пресет по умолчанию.

Ознакомьтесь с техническими подробностями и документацией Fast Search. Вся заслуга принадлежит исследователю этого проекта. Также подписывайтесь на нас в Twitter и не забудьте присоединиться к нашему сабреддиту о машинном обучении с более чем 150 тыс. участников и подписаться на нашу рассылку. Стоп! Вы есть в Telegram? Теперь к нам можно присоединиться и в Telegram.

Хотите сотрудничать с нами для продвижения своего репозитория GitHub, страницы Hugging Face, релиза продукта, вебинара и т. д.? Свяжитесь с нами