Проектирование и оценка API поиска, ориентированного на ИИ

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

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

Затем мы описываем наш подход к эмпирической оценке производительности API поиска с помощью недавно опубликованной инфраструктуры оценки с открытым исходным кодом. Благодаря всестороннему сравнительному анализу наряду с существующими коммерческими API мы демонстрируем передовую производительность как в отношении качества, так и задержки. Perplexity Search API доступен для разработчиков по всему миру начиная с сегодняшнего дня.

[Найдите search_evals на GitHub]

Создание системы поиска, оптимизированной для моделей ИИ

С момента основания мы понимали, что надежные возможности поиска будут иметь решающее значение для создания ИИ-продуктов, определяющих категорию, которые мы хотели выпустить. Изначально мы надеялись, что такие возможности уже существуют в общедоступной форме. Мы экспериментировали с портфелем API поиска, доступных в конце 2022 года, и самая первая версия поискового движка Perplexity фактически включала некоторые из этих предложений. В частности, мы анализировали запросы пользователей, формировали и отправляли запросы к этим API, а затем собирали результаты в качестве контекста для нашего последующего конвейера генерации.

Однако по мере того, как пользователи стекались в Perplexity, мы быстро поняли, что эти API не смогут масштабироваться вместе с нашим ростом. Цены, с которыми мы столкнулись, были непомерными: один ведущий поставщик API взимал 200 долларов за тысячу запросов. Но, что еще важнее, эти устаревшие API просто не были разработаны для новых парадигм поиска, внедренных передовыми системами ИИ.

Развернуть

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

Мы также заметили, что устаревшие API были либо слишком устаревшими, либо слишком медленными. Независимо разработанные API поиска полагались на индексы, которые были неполными и обновлялись слишком редко. API на основе парсинга, такие как различные неофициальные API SERP для Google Search, выигрывали от более полного индекса, но предлагали неприемлемо высокую задержку из-за неэффективности, присущей запросам к сторонней поисковой системе. Высокая задержка делала API непригодными для пользовательских приложений, а устаревание делало наборы результатов непригодными для любой системы ИИ, надеющейся быть точной и надежной.

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

Когда мы поняли, что для того, чтобы сделать Perplexity еще лучше, потребуется создание нашей собственной выделенной инфраструктуры поиска, мы выделили наши наблюдения в три ключевых критерия:

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

Детальное понимание контента: хрупкость моделей ИИ и ограниченные контекстные окна требуют, чтобы результаты поиска были представлены и ранжированы на максимально возможном уровне детализации.

Гибридное извлечение и ранжирование: как конвейеры извлечения, так и ранжирования должны включать лексические и семантические сигналы, чтобы результаты были полезны для ИИ.

Развернуть

Инфраструктура сканирования и индексирования

Работа в масштабе Perplexity требует инфраструктуры, которая может всесторонне отображать веб и реагировать на его постоянную эволюцию. Наш индекс поиска отслеживает более 200 миллиардов уникальных URL-адресов с возможностью отслеживания еще сотен миллиардов.

Обеспечение того, чтобы наш индекс охватывал достаточно всеобъемлющий диапазон интернета и чтобы каждый документ отражал новейшее состояние, является трудной задачей. Существует внутреннее напряжение между полнотой и свежестью: при фиксированном бюджете индексирования операции обновления для существующих страниц должны конкурировать с операциями индексирования для новых, не посещенных страниц. Мы уравновешиваем это напряжение сочетанием масштабирования (которое ослабляет ограничение оптимизации за счет увеличения бюджета индексирования) и приоритизации на основе машинного обучения (которая гарантирует, что каждая операция индексирования максимально ценна для индекса в целом).

Мы создали индекс эксабайтового масштаба и аппарат для сканирования, который масштабируется горизонтально как по размеру, так и по объему запросов. Флоты краулеров и индексаторов Perplexity в совокупности включают десятки тысяч процессоров и сотни терабайт оперативной памяти с значительным запасом для дальнейшего масштабирования. Мы объединяем эту вычислительную инфраструктуру с балансом холодного и горячего хранения. Мы используем как обученные модели, так и настроенные эвристики для определения того, какие документы должны храниться горячими, приоритизируя документы из авторитетных доменов, документы, затрагивающие недостаточно освещенные темы, и другие категории с огромным потенциалом обогащения нашего индекса.

Эта инфраструктура позволяет Perplexity обрабатывать десятки тысяч операций индексирования в секунду. Но даже при таком относительно щедром бюджете масштаб интернета слишком велик, чтобы индексировать каждый URL-адрес на частой и регулярной основе. Именно здесь на помощь приходит машинное обучение. Мы обучаем модель машинного обучения предсказывать, нужно ли индексировать любой заданный кандидатский URL-адрес. Цель обучения разработана так, чтобы обеспечить калибровку нашего решения об индексации как с точки зрения важности, так и вероятной частоты обновления конкретного URL-адреса. Мы также полагаемся на машинное обучение, чтобы точно сказать нам, когда планировать операцию индексирования. Для сайтов с обычной публикацией и частотой обновления это позволяет нам откладывать операции до того момента, когда они, скорее всего, будут наиболее полезны. Благодаря постоянному уточнению этих моделей машинного обучения мы можем поддерживать индекс, который соответствует отметке как по полноте, так и по свежести.

Хотя наша инфраструктура сканирования легко масштабируется горизонтально, мы понимаем, что владельцы веб-сайтов сталкиваются с различными техническими ограничениями. Мы тщательно поддерживаем предсказуемый и управляемый уровень запросов к любому заданному домену. PerplexityBot, наш поисковый краулер, соблюдает явные ограничения, установленные в файлах robots.txt, или, при отсутствии указанных доменов ограничений, отраслевые стандарты относительно уровней запросов. Мы также корректируем наше поведение сканирования, когда обнаруживаем недоступность сайта. Наша распределенная система спроектирована так, чтобы обеспечивать соблюдение этих ограничений даже при десятках тысяч параллельных операций.

Самоулучшающееся понимание контента в масштабе интернета

Даже с одним из крупнейших и свежайших индексов поиска на планете качество результатов каждого запроса зависит от понимания нашей системой содержания каждого документа. Здесь мы сталкиваемся с фундаментальной проблемой: веб — это хаотичное место. Никакой фиксированный набор правил парсинга не может справиться с бесконечным разнообразием макетов, структур и стилей, найденных по всему интернету.

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

Чтобы способствовать этой динамической адаптации, мы (конечно) обращаемся к ИИ. В масштабе Perplexity мы наблюдаем невероятно богатый срез интернета в ходе обслуживания миллионов пользовательских запросов ежечасно. Это формирует основу для итеративного цикла самосовершенствования. Мы наблюдаем за поведением парсинга и извлеченными результатами наших текущих наборов правил по всей нашей вселенной запросов. Затем мы используем передовые LLM для оценки производительности по двум основным измерениям:

Полнота: наш индекс должен получать как можно больше семантически значимого контента, избегая при этом ложного извлечения неинформативных или бессмысленных материалов.

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

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

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

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

Конвейер извлечения и ранжирования

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

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

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

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

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

Обеспечение высокого качества на каждом этапе этого конвейера возможно только благодаря совместному проектированию с портфелем продуктов Perplexity. Каждая деталь стека ранжирования разработана для использования богатого сигнала, создаваемого миллионами пользовательских запросов, которые мы обслуживаем каждый час дня. Подавляющее большинство этого сигнала автоматизировано, при этом каждый сгенерированный ответ Perplexity предоставляет эмпирическую точку данных о качестве поиска, используемую в реальном агентическом рабочем процессе. Мы сочетаем оценки на основе ИИ с обратной связью от реальных людей, чтобы обогатить обучающие данные для наших моделей эмбеддингов и ранжирования далеко за пределами того, что может предложить любой созданный вручную набор данных.

Эта синергия между поиском и продуктом уникальна для Perplexity. Устаревшие поисковые системы ограничены грубым сигналом, предоставляемым телеметрией синих ссылок. Более новые поисковые предложения пытались реализовать некоторые из этих концепций с поддержкой ИИ, но им не хватает реальных сред, которые могут подтвердить качество поиска и обеспечить богатство сигнала, необходимое для быстрых циклов улучшения. Нам повезло иметь недостающий ингредиент: живой полигон для проверки качества поиска, поддерживаемый передовыми LLM и постоянно тестируемый миллионами любопытных пользователей по всему миру.

Установление нового рубежа качества и производительности

После создания Perplexity Search API и SDK, чтобы сделать нашу инфраструктуру поиска доступной для разработчиков по всему миру, мы хотели понять, как различные коммерческие предложения API соответствуют реальным случаям использования ИИ. Стало обычным делом оценивать сами модели ИИ, но нам нужен был поворот в этой схеме: оценить качество API поиска при вызове моделями ИИ.

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

Используя эту инфраструктуру оценки, мы строго провели бенчмаркинг Perplexity Search API наряду с другими предложениями. Оптимизация производительности поиска сложна, с множеством тонких компромиссов между качеством и скоростью. К радости разработчиков, мы обнаружили, что Perplexity Search API устанавливает новый стандарт производительности как по качеству, так и по задержке. Разработчикам больше не нужно выбирать между созданием молниеносных приложений и обеспечением высококачественных результатов: с Perplexity они могут получить и то, и другое.

Развернуть

Проектирование надежных оценок для агентических поисковых рабочих процессов

Мы начали с определения трех руководящих принципов для нашей инфраструктуры оценки:

Спектр сложности: инфраструктура оценки должна измерять производительность как в простых, так и в сложных случаях использования агентического ИИ.

Нейтральность: инфраструктура оценки должна оценивать все API на равных условиях.

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

Наша легковесная инфраструктура оценки, search_evals, достигает этих целей благодаря простому модульному дизайну. Мы разработали две обвязки для агентов ИИ, чтобы фиксировать как классические одношаговые варианты использования поиска, так и продвинутые агентические рабочие процессы (примеры которых можно найти в различных продуктах «глубокого исследования», широко доступных на потребительском рынке). Обе обвязки были реализованы простым способом, который оставляет мало места для скрытых преимуществ.

Для проведения наших оценок мы приняли четыре бенчмарка: SimpleQA и FRAMES для одношагового поиска, а также BrowseComp и HLE для глубокого исследования. В совокупности эти бенчмарки предоставляют общепризнанные мерила для агентов знаний. Следуя установившейся конвенции, мы оцениваем все бенчмарки, используя ту же методологию классификатора с подсказками, которая использовалась в оригинальной работе. Точные реализации бенчмарков (включая логику оценки) можно просмотреть в нашем репозитории GitHub.

Мы разработали эту инфраструктуру с учетом воспроизводимости и расширяемости. Как оценки на уровне задач, так и базовые выходные данные агентов сохраняются при каждом запуске. Дополнительные обвязки, бенчмарки и предложения API поиска могут быть легко интегрированы. Исследователи и разработчики могут прочитать нашу документацию GitHub для получения дополнительной информации о расширении инфраструктуры для удовлетворения ваших точных потребностей.

Результаты оценки

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

Развернуть

Мы обнаружили, что наши описанные выше инвестиции в эффективность индекса, извлечения и ранжирования окупились сполна. Медианная задержка Perplexity составляет 358 мс, что более чем на 150 мс быстрее, чем у второго по скорости провайдера. Задержка на 95-м процентиле комфортно остается ниже 800 мс. С учетом высоких показателей TTFT (времени до первого токена) современных передовых моделей, каждая миллисекунда имеет значение для создания приятного пользовательского опыта. Мы потратили последние два года на оптимизацию задержки для наших собственных пользователей, и мы рады, что те же самые инвестиции теперь принесут пользу и сообществу разработчиков.

Задержка API поиска

(запросы инициированы из AWS us-east-1)

Перцентили задержки Search API для запросов, инициированных из AWS us-east-1.

* Многие поставщики API поиска используют парсинг SERP в качестве основы для своих результатов. Чтобы оценить производительность таких подходов, мы используем репрезентативный API на основе Google SERP, предлагаемый Tavily.

Это преимущество в скорости не достигается за счет качества. Perplexity Search API обеспечивает передовую производительность как в одношаговом поиске, так и в сценариях глубокого исследования. По каждому протестированному бенчмарку Perplexity лидирует в предоставлении высококачественных результатов, которые могут питать рабочие процессы ИИ различной сложности. Разница между Perplexity и лучшей альтернативой особенно выражена в SimpleQA и HLE, что указывает на надежность этих результатов во всем спектре сложности задач.

Развернуть

Как и в случае с задержкой, наше лидерство в качестве поиска вытекает из нашего лидерства в создании восхитительных, высоконагруженных продуктов ИИ. Наши миллионы пользователей используют Perplexity, чтобы удовлетворить свое любопытство по любой мыслимой теме, а полученные сигналы качества и релевантности позволяют нашим моделям поиска совершенствоваться с каждым часом.

Бенчмарки качества API поиска

Оценки качества Search API на SimpleQA, FRAMES, BrowseComp и HLE.

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

Строительный блок для следующей главы ИИ

Будущее агентических систем и интеллектуальных помощников будет зависеть от доступности богатых программных интерфейсов к коллективному знанию мира. Использование современных устаревших поисковых систем насытилось примерно на уровне 10¹⁰ запросов в день — цифра, которая, вероятно, достигла своего пика. Следующее поколение систем поиска и извлечения будет обслуживать на порядки больше запросов, поскольку постоянно растущая вселенная агентов ИИ будет полагаться на них для получения точной информации в реальном времени.

Наши усилия на сегодняшний день позволили нам занять позицию самой быстрой и производительной поисковой системы, доступной через API. Но для того, чтобы подпитывать следующую главу ИИ, потребуется еще более амбициозная инновация. Как нам эффективно масштабировать эти системы перед лицом постоянно растущего спроса? Как можно оптимизировать эти поисковые системы в свете новых подходов к инженерии контекста и пост-обучению? И как нам ориентироваться в вечном напряжении между всесторонностью, актуальностью и задержкой? Это открытые вопросы, которые Perplexity, с нашей комбинацией продуктового охвата, масштаба и технического таланта, уникально способна решить.

Цитирование

@online{perplexity2025ArchitectingAndEvaluatingAnAiFirstSearchApi,
  author = {{Perplexity} and Aleksandr Bogutskii and Aleksandr Nikolenko and Aleksei Bykov and Alexander Pecheny and Alexandr Yarats and Arsenii Shevchenko and Denis Bykov and Dmitry Pervukhin and Ismail Gadzhiev and James Liounis and Kevin Hu and Kirill Priemko and Maksim Gaiduk and Maksim Morozov and Marko Kevac and Michael Liang and Mikhail Galanin and Nandor Licker and Nataliya Pevgova and Nikita Kireev and Nikolai Tretiak and Paul Schofield and Saif Ali Raja and Saleh Alghusson and Sebastian Sepulveda and Sergei Miller and Svyatoslav Feldsherov and Vitalii Polshkov and Vladimir Zaytsev and Denis Yarats},
  title = {{Architecting and evaluating an AI-first Search API}},
  date = {2025-09-25},
  url = {https://www.perplexity.ai/hub/blog/architecting-and-evaluating-an-ai-first-search-api}
}