Perplexity перевела пошук на Photon і запустила швидкий режим Search API

Perplexity перевела свою пошукову систему на Photon — власний рушій для пошуку й ранжування вебсторінок — і на його основі запустила швидкий режим Search API для ШІ-агентів. Як пише «Хабр» 18 жовтня 2026 року, новий режим зменшує затримку й вартість пошуку, але в окремих перевірках поступається стандартному за релевантністю. Він розрахований на завдання, у яких агенту потрібно багаторазово звертатися до пошуку; для дослідження з широким охопленням джерел стандартний режим може підійти краще.

Чому Perplexity замінила пошуковий рушій

До Photon компанія використовувала адаптований рушій з відкритим кодом. Зі зростанням індексу й навантаження він перестав справлятися, тож Perplexity замінила його власною розробкою. За даними компанії, затримка на 99-му перцентилі скоротилася приблизно з 800 до 65 мс. Це показник роботи рушія, а не час повного виклику Search API: для швидкого режиму компанія наводить окремі цифри.

Заміна рушія важлива не лише через швидкість одного запиту. Photon тепер обслуговує пошукову систему Perplexity, а швидкий режим API працює на тій самій основі. Тому в новині йдеться одразу про два рівні: про те, як обробляється пошук усередині системи, і про режим, доступний для завдань агентів. Їхні показники затримки краще не зводити до однієї красивої, але хибної цифри.

Що Photon робить під час пошуку

Photon використовує інвертований індекс, який пов’язує слова з документами, де вони трапляються. Для оцінювання знайденого рушій має окремий компактний запис документа: у ньому зазначено частоти слів, їхні позиції та поля. Із цього запису він дістає лише дані, потрібні для конкретного запиту, замість того щоб розпаковувати все цілком. Алгоритм відбору кандидатів, подібний до WAND, дає змогу пропускати документи, які не зможуть потрапити до підсумкової видачі. Дані також зчитуються асинхронно, а побудова індексу відокремлена від обробки запитів — за описом компанії, це зменшує затримки під час читання з диска й оновлення бази.

Економія часу не означає, що Photon компактніший за попереднє рішення в усьому. Для кожного документа він зберігає приблизно у 2,5 раза більше даних, натомість для обслуговування запитів йому потрібно приблизно на 20% менше серверів. Тут варто розрізняти обсяг збереженої інформації та ресурси, потрібні для обробки пошуку: наведені компанією показники змінюються в різних напрямках.

Швидкість, вартість і якість

У швидкому режимі Search API медіанна затримка пошукового виклику становить 160 мс, а 95% викликів укладаються у 230 мс. Це вже показники API, а не згадані вище 65 мс на 99-му перцентилі рушія. Різниця принципова, якщо порівнювати способи підключення пошуку до агента: для такого вибору важливий виклик, який робить сервіс, а не лише швидкість одного компонента всередині Perplexity.

Компанія перевірила обидва режими на 3554 завданнях із шести агентних бенчмарків. Швидкий отримав результат 64,3% за розрахункової вартості моделі й пошуку $59,73; стандартний — 64,0% за вартості $187,60 на тому самому наборі. Розрахункова економія становила близько 68%. Це дані конкретного порівняння: переносити відсоток економії на будь-який продукт чи набір запитів без власної перевірки було б надто сміливо.

Водночас внутрішні тести окремих пошукових видач показують зниження якості. Метрика релевантності DCG зменшилася з 2,45 до 2,21, а частка запитів, для яких серед знайдених сторінок була відповідь, — із 59,6% до 56,7%. Результати завдань агентів близькі, хоча показники релевантності окремих видач у тестах нижчі. Ці оцінки вимірюють різне; матеріал не пояснює, чому вони розійшлися.

Для розробників ШІ-сервісів практичне питання — який режим використовувати для конкретного завдання. Якщо агент виконує багато типових пошукових звернень, швидкий режим дає змогу зменшити затримку й розрахункову вартість. Якщо завдання потребує широкого охоплення джерел, стандартний пошук може виявитися кращим. Тут немає універсального переможця: поряд зі швидкістю доводиться оцінювати, чи достатньо знайдені сторінки відповідають на запит.

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

Моя думка: швидкий пошук однаково потрібно перевіряти

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

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

Джерела

Звідки новина. Текст — переказ своїми словами, факти — з джерела, думка — автора.

1. Perplexity представила Photon — поисковый движок для ИИ-агентов с задержкой от 160 мс habr.com

Про автора

Леа Маєр

студентка вебдизайну

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

Усі публікації автора