Perplexity представя Photon: базиран на Rust механизъм за извличане, който намалява p99 латентността от 800 мс на 65 мс

Perplexity пусна Photon — собствена машина за извличане и класиране, написана на Rust. Тя заменя машина с отворен код, която Perplexity беше форкнала за своя стек за търсене, базиран на изкуствен интелект. Photon вече обработва извличането и класирането на целия производствен трафик. Тя също така захранва нов режим Fast Search в Search API на Perplexity. Perplexity отчита латентност при едно извикване от 160 ms при p50 и 230 ms при p95.

Може ли да бъде внедрена? Да, като хостван API. Задайте search_type: "fast" при POST /search и плащайте 1 долар за 1000 заявки. Самата Photon не е с отворен код, така че машината не може да бъде хоствана самостоятелно.

Защо Perplexity замени старата си машина

Старата машина достигна 3 ограничения с разрастването на индекса:

• Опашъчна латентност: Производственият p99 беше близо до 800 ms. Наборът от данни надхвърли RAM паметта, така че mlock не беше възможност. Студените прочити предизвикваха значителни грешки на страниците, които забавяха заявките.
• Пикове при сливане: По време на сливането на дисковия индекс p99 се повишаваше до около 1,2 s за 10 до 15 минути.
• Бавно възстановяване: Внедряването и синхронизирането на допълнителен клъстер можеше да отнеме повече от седмица. Възстановяването също така увеличаваше дела на частичните отговори.

Екипът на Perplexity заключи, че изграждането от нулата е по-просто и по-евтино от поддръжката на техния форк.

Как работи Photon

Балансьор на натоварването насочва всяка заявка към брокер на Photon. Брокерът разпределя заявката към група от шарди и следи за изтичане на времето. Всеки шард извършва извличане, първоначално класиране и класиране на втори етап. След това брокерът обединява кандидатите и извлича ключови полета от документите.

• Адаптивни списъци за публикации: Кратките списъци се съхраняват вградени в една страница. По-дългите списъци се разделят на блокове с фиксирани диапазони от идентификатори на документи. Разредените блокове съхраняват сортирани масиви от отмествания и използват галопиращо търсене. Плътните блокове използват битови карти, така че проверката за членство се превръща в еднократно търсене на бит.
• Обхождане с бюджет: Алгоритъм, подобен на WAND, разделя списъците на управляващи и пробни списъци. Евтините проверки за наличие първо ограничават максималната оценка на всеки кандидат. Точните честоти на термините се прочитат само когато кандидатът може да надхвърли прага.
• Записи docblob: Всеки документ получава компактен запис с честоти, маски на полета и позиции. Термините използват кодиране Elias-Fano, така че при класирането се декодират само съвпадащите термини. Класирането на кандидат изисква само 1 търсене на документ.
• Пакетни асинхронни прочити: Отместванията на записите са известни предварително, така че дисковите прочити се извършват на пакети чрез io_uring. Кешът първо проверява целия пакет. Четеците не използват заключвания, а изваждането използва CLOCK вместо споделен LRU списък.
• Отделно изграждане и обслужване: Индексаторите изграждат версионирани индекси на шардове от таблици на YTsaurus на специализирани възли. Контролер завърта групите за обслужване една по една и загрява кешовете чрез повторно изпълнени заявки от регистрационните файлове на търсенията.

Пълният уеб индекс вече се изгражда за едноцифрен брой часове.

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

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

• Латентността на извличането и класирането при p99 спадна от около 800 ms до около 65 ms. Това обхваща само етапите на 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. В 3554 задачи 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 ms до около 65 ms.
• Fast Search отчита 160 ms p50 и 230 ms p95 при 1 долар за 1000 заявки.
• Fast намали изчислената цена на агентните задачи с около 68% при сравнимо качество на задачите.
• Той жертва част от релевантността на извличането, затова запазете пресета по подразбиране за трудни заявки.

Разгледайте техническите подробности и документацията за Fast Search. Всички заслуги са за изследователя на този проект. Също така не се колебайте да ни последвате в Twitter и не забравяйте да се присъедините към нашия ML SubReddit с над 150 хил. членове и да се абонирате за нашия бюлетин. Чакайте! В Telegram ли сте? Сега можете да се присъедините към нас и в Telegram.

Имате нужда от партньор за популяризиране на вашето GitHub хранилище ИЛИ страница в Hugging Face ИЛИ продуктова версия ИЛИ уебинар и т.н.? Свържете се с нас