Проектиране и оценка на първичен по отношение на AI Search API

Изграждането на мащабируем, ориентиран към изкуствения интелект API за търсене поставя уникални изследователски предизвикателства в кръстопътната точка между извличането на информация, изкуствения интелект и системния дизайн. За разлика от традиционните услуги, които работят с ограничени данни, един API за търсене трябва непрекъснато да индексира милиарди документи, да разпознава намерението зад заявките на различни езици и домени и да извлича релевантни резултати в рамките на милисекунди. В ерата на AI агентите API за търсенето трябва също така внимателно да подбира контекста, предоставен на моделите на разработчиците, за да се гарантира тяхната оптимална работа и включването на максимално точна информация. Ефективното изграждане на контекст изисква API не само да улавя релевантността на ниво документ, но и да третира отделните секции и отрязъци от документи като самостоятелни единици от първостепенно значение.

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

След това описваме нашия подход за емпирична оценка на производителността на API за търсене чрез новопубликувана платформа за оценка с отворен код. Чрез цялостни бенчмарт тестове заедно с налични търговски API демонстрираме най-съвременна производителност както по отношение на качеството, така и на латентността. Perplexity Search API е достъпен за разработчици по целия свят, започвайки от днес.

[Намерете search_evals в GitHub]

Изграждане на система за търсене, оптимизирана за AI модели

От самото си основаване знаехме, че надеждните възможности за търсене ще бъдат от критично значение за създаването на определящите категорията AI продукти, които искахме да пуснем. Първоначално се надявахме, че тези възможности вече съществуват в публично достъпна форма. Експериментирахме с портфолиото от API за търсене, налични в края на 2022 г., и самата първа версия на двигател за отговори на Perplexity всъщност включваше някои от тези предложения. По-конкретно, анализирахме потребителски заявки, формулирахме и изпращахме заявки към тези API и събирахме резултатите като контекст за нашия последващ генеративен пайплайн.

Въпреки това, докато потребителите се стекоха към Perplexity, бързо осъзнахме, че тези API няма да могат да се мащабират заедно с растежа ни. Цените, с които се сблъскахме, бяха прекомерни, като един водещ API доставчик таксуваше 200 долара за хиляда заявки. Но по-фатално беше, че тези стари API просто не бяха проектирани за новите парадигми за извличане, въведени от съвременните AI системи.

Уголеми

Като за начало, форматите за заявки и отговори на тези стари API бяха проектирани за свят, в който хората биха били изключителни потребители на резултатите от търсенето. В резултат на това тези API приоритизираха резултати на ниво документ, за сметка на по-детайлна информация, разкрита от подизточникови единици. Успехът на един AI модел зависи от качеството и компактността на предоставения контекст и видяхме от първа ръка как твърде широкото извличане може да провали AI моделите, независимо колко свързани изглеждат извлечените документи като цяло. Опитите ни да приложим прецизност към неточни резултати доведоха до ограничен успех.

Също така забелязахме, че старите API бяха или прекалено остарели, или прекалено бавни. Независимо разработените API за търсене разчитаха на индекси, които бяха непълни и обновявани твърде рядко. API-тата, базирани на уеб сканиране, като различните неофициални SERP API за Google Search, се възползваха от по-пълен индекс, но предложиха неприемливо висока латентност поради неефективността, присъща на заявките към външна търсачка. Високата латентност направи API неподходящи за приложения, насочени към потребителите, докато остаряването направи наборите от резултати неизползваеми за всяка AI система, която се надява да бъде точна и надеждна.

И накрая, наблюдавахме как AI екосистемата се разклонява между лексикално търсене и семантично търсене, като се появяват системи, които са прекомерно оптимизирани за едната модалност за сметка на другата. Видяхме възхода на векторни бази данни, които не успяват да поддържат адекватно дори прости булеви филтри. Традиционните бекенд системи за търсене се справяха малко по-добре, с примитивна поддръжка за възможностите за семантично класиране и извличане, отключени от изкуствения интелект.

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

Пълнота, актуалност и скорост: индексът за търсене трябва да бъде изчерпателен, постоянно актуализиран и проектиран за латентност в реално време.

Детайлно разбиране на съдържанието: крехкостта на AI моделите и ограничените контекстни прозорци изискват резултатите от търсенето да бъдат представени и класирани на възможно най-гранулирано ниво.

Хибридно извличане и класиране: както пайплайните за извличане, така и тези за класиране трябва да включват лексикални и семантични сигнали, за да бъдат резултатите полезни за AI.

Уголеми

Инфраструктура за обхождане и индексиране

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

Гарантирането, че нашият индекс покрива достатъчно изчерпателна част от интернет и че всеки документ отразява последното състояние, е трудно постижение. Съществува присъщо напрежение между пълнотата и актуалността: за фиксиран бюджет за индексиране, операциите по обновяване на съществуващи страници трябва да се конкурират с операциите по индексиране на нови непосетени страници. Балансираме това напрежение чрез комбинация от мащабиране (което облекчава ограниченията за оптимизация чрез увеличаване на бюджета за индексиране) и приоритизиране, управлявано от машинно обучение (което гарантира, че всяка операция по индексиране е максимално ценна за индекса като цяло).

Изградихме индекс от екзабайтов мащаб и апарат за обхождане, който се мащабира хоризонтално както с размера, така и с обема на заявките. Обходните и индексиращите флотилии на Perplexity съвкупно включват десетки хиляди процесори и стотици терабайти RAM памет, със значителен запас за по-нататъшно мащабиране. Съчетаваме тази изчислителна инфраструктура с баланс между студено и топло съхранение. Използваме както обучени модели, така и настроени евристики, за да определим кои документи трябва да се поддържат горещи, като приоритизираме документи от авторитетни домейни, документи, свързани с недостатъчно отразени теми, и други категории с огромен потенциал да обогатят нашия индекс.

Тази инфраструктура дава възможност на Perplexity да обработва десетки хиляди операции по индексиране в секунда. Но дори и с този относително щедър бюджет, мащабът на интернет е твърде огромен, за да се индексира всеки отделен URL адрес на честа и повтаряща се база. Тук се намесва машинното обучение. Обучаваме модел за машинно обучение, за да предвидим дали даден кандидат URL адрес трябва да бъде индексиран. Целта на обучението е създадена така, че да гарантираме калибриране на решението за индексиране спрямо както важността, така и вероятната честота на актуализиране на конкретния URL адрес. Разчитаме също на машинното обучение, за да ни каже точно кога да планираме операцията по индексиране. За сайтове с рутинни честоти на публикуване и опресняване, това ни позволява да отложим операциите до момента, в който те вероятно ще бъдат най-полезни. Чрез постоянно усъвършенстване на тези модели за машинно обучение успяваме да поддържаме индекс, който отговаря на изискванията както за пълнота, така и за актуалност.

Въпреки че нашата инфраструктура за обхождане лесно се мащабира хоризонтално, съзнаваме, че операторите на уебсайтове са изправени пред различни технически ограничения. Внимаваме да поддържаме предвидим и управляем темп на заявките към всеки даден домейн. PerplexityBot, нашият обходен робот за търсене, спазва изричните ограничения, посочени в файловете robots.txt, или при липса на посочени от домейна ограничения, общоприетите в индустрията норми относно честотата на заявките. Ние също така коригираме поведението си на обхождане, когато засечем недостъпност на сайт. Нашата разпределена система е проектирана да налага тези ограничения дори при десетки хиляди едновременни операции.

Самоусъвършенстващо се разбиране на съдържанието в интернет мащаб

Дори с един от най-големите и най-актуални индекси за търсене на планетата, качеството на резултатите за всяка заявка зависи от разбирането на системата ни за съдържанието на всеки документ. Тук сме изправени пред фундаментално предизвикателство: интернет е хаотично място. Никакъв фиксиран набор от правила за анализ не може да се справи с безкрайното разнообразие от оформления, структури и стилове, срещани в целия интернет.

Решихме това предизвикателство, като разработихме модул за разбиране на съдържанието, който анализира уебсайтове и извлича семантично значимо съдържание чрез динамични набори от правила. Уебсайт, богат на добре структурирани данни във форма на списък или таблица, може да се възползва от по-формулирани правила за анализ и извличане, докато друг уебсайт, представящ предимно генерирано от потребителите съдържание със свободна форма, може да изисква по-свободен набор от правила. Тъй като интернет е предимно статичен в кратки времеви рамки, установяваме, че животът на дадено правило е относително дълъг. Но тъй като сайтовете се развиват с времето и докато научаваме повече за най-добрите начини за извличане на информация, нашите набори от правила също изискват постоянна грижа.

За да улесним това динамично адаптиране, се обръщаме (разбира се) към изкуствения интелект. В мащаба на Perplexity наблюдаваме невероятно богат кръстозразрез на мрежата в хода на обслужването на милиони потребителски заявки на час. Това формира основата за итеративен цикъл на самоусъвършенстване. Наблюдаваме поведението на парсиране и извлечените резултати на настоящите ни набори от правила в цялата ни вселена от заявки. След това използваме модерни LLM модели, за да оценим производителността в две основни измерения:

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

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

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

Конкретно, след всяка оценка на ефективността на парсирането, водена от LLM, нашата система формулира набор от предложени промени в набора от правила за справяне с най-значимите класове грешки. Тези набори от правила преминават през допълнителна валидация, след което внедряваме новата версия в нашия индексатор. Като се има предвид, че подобренията в логиката за парсиране и извличане могат само да бъдат от полза за бъдещите операции по индексиране, нашите инвестиции в оптимизирано чрез машинно обучение преиндексиране са особено важни: постоянното опресняване на документи с висок трафик с помощта на най-новата версия на тази логика гарантира стегнат цикъл на самоусъвършенстване.

Тези правила са от значение не само за базовото представяне при парсиране, но и за сегментирането в подизточникови единици. Когато става въпрос за модерни LLM модели, всеки токен от контекста е ценен. Голям обем предишна работа е документирал как ефективността на LLM намалява с увеличаването на размера на контекста и замърсяването на контекста с нерелевантна информация. Притежаването на добре структуриран, изчерпателен анализ ни позволява да декомпозираме документите на самостоятелни отрязъци, всеки от които може да бъде индивидуално извлечен и класиран в момента на заявката.

Пайплайн за извличане и класиране

Съвременното търсене изисква осигуряване както на пълнота, така и на релевантност при стриктен бюджет за латентност. Пайплайнът за извличане и класиране на Perplexity постига това чрез многоетапна архитектура, която прогресивно усъвършенства резултатите с поредица от все по-усъвършенствани модули. Решаваме потенциалните тесни места чрез хоризонтално мащабиране на евентуалните критични точки до максимална възможна степен.

Пайплайнът започва с извличане от нашия индекс. Ние не налагаме избор между лексикално и семантично извличане. Вместо това отправяме заявка към индекса за търсене и чрез двете модалности и обединяваме резултатите в хибриден набор от кандидати. На този етап приоритетът е изчерпателността пред прецизността - следващите етапи на пайплайна ще оптимизират за прецизност.

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

След това използваме множество етапи на прогресивно напреднало класиране. По-ранните етапи разчитат на лексикални и базирани на ембединги оценяващи модули, оптимизирани за скорост. Тъй като набора от кандидати постепенно се изтънява, ние използваме по-мощни cross-encoder модели за прекласиране, за да извършим крайното оформление на набора от резултати. Благодарение на нашите многобройни инвестиции в ефективността на инференса, ние сме в състояние да използваме съвременни архитектури на модели за тези по-късни етапи, като същевременно поддържаме общата латентност на класирането ниска.

През целия този пайплайн ние извличаме и оценяваме резултати както на ниво документ, така и на ниво подизточник. Както бе обсъдено по-горе, изкуственият интелект изисква внимателно изграждане на контекст. Нашият пайплайн е проектиран да извежда най-атомните възможни единици към модела, така че надолу по веригата потребителите да могат да включат тези точни единици, без да извличат нерелевантен контекст от другаде в изходните документи.

Осигуряването на високо качество през всеки етап от този пайплайн е възможно само чрез съвместно проектиране с портфолиото от продукти на Perplexity. Всеки детайл от стека за класиране е проектиран да се възползва от богатия сигнал, произведен от милионите потребителски заявки, които обслужваме всеки час от денонощието. По-голямата част от този сигнал е автоматизирана, като всеки генериран отговор на Perplexity предоставя емпирична точка с данни за качеството на търсенето, използвано в реален агентен работен процес. Ние съчетаваме оценки, водени от изкуствен интелект, с отзиви от реални потребители на живо, за да обогатим данните за обучение на нашите ембединги и модели за класиране далеч отвъд това, което всеки ръчно създаден набор от данни може да предложи.

Тази синергия между търсене и продукт е уникална за Perplexity. Старите търсачки са ограничени до грубия сигнал, осигурен от телеметрията със сини връзки. По-новите предложения за търсене се опитаха да внедрят някои от тези концепции, насочени към изкуствения интелект, но им липсват среди от реалния свят, които могат да валидират качеството на търсенето и да осигурят богатството на сигнала, необходимо за цикли на бързо подобрение. Ние сме щастливи да имаме липсващата съставка: терен за изпитване на живо за качеството на търсенето, захранван от модерни LLM модели и непрекъснато тестван в бойни условия от милиони любопитни потребители по целия свят.

Установяване на нова граница за качество и производителност

След като изградихме Perplexity Search API и SDK, за да направим нашата инфраструктура за търсене достъпна за разработчици по целия свят, искахме да разберем как различните търговски API предложения се справят в реални сценарии за използване на изкуствен интелект. Стана обичайно да се оценяват самите AI модели, но се нуждаехме от обрат в този модел: да оценим качеството на API за търсене, когато се извикват от AI модели.

Първо потърсихме екосистемата с отворен код, за да разберем предишните постижения. Намерихме много от ключовите съставки за стриктна оценка, но нито една рамка, която да интегрира тези съставки в решение за бенчмаркинг тип „включи и пусни“. Следователно си поставихме за цел да разработим рамка за оценка, която да може да се използва не само от Perplexity, така и от всеки изследовател или разработчик, който се стреми да прави бенчмаркинг на API за търсене.

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

Уголеми

Проектиране на надеждни оценки за агентни работни процеси за търсене

Започнахме с определянето на три водещи принципа за нашата рамка за оценка:

Спектър на сложност: рамката за оценка трябва да измерва производителността както при прости, така и при сложни случаи на употреба на агентен изкуствен интелект.

Неутралност: рамката за оценка трябва да оценява всички API при равни условия.

Опростеност: въпреки че определени случаи на употреба може да са сложни, самата рамка трябва да бъде възможно най-опростена, така че другите да могат да я разберат, да възпроизведат резултатите и да я разширят с минимална досада.

Нашата лека рамка за оценка, search_evals, постига тези цели чрез опростен модулен дизайн. Разработихме две рамки за AI агенти, за да обхванем както класически случаи на употреба с еднократно търсене, така и усъвършенствани агентни работни процеси (олицетворени от различни продукти за „задълбочено проучване“, широко достъпни на потребителския пазар). И двете рамки бяха реализирани по опростен начин, който оставя малко място за скрито предимство.

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

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

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

Въоръжени с тази рамка за оценка, ние си поставихме за цел да оценим нашия Search API в сравнение с други предлагани API. В рамките на всички тествани бенчмаркове, Perplexity се откроява едновременно като най-бързия и с най-високо качество API на пазара.

Уголеми

Установихме, че описаните по-горе инвестиции в индекс, извличане и ефективност на класиране се отплащат щедро. Средната латентност на Perplexity е 358 мс, с над 150 мс пред втория най-бърз доставчик. Латентността на 95-ия персентил се задържа удобно под 800 мс. С дългите метрики на TTFT (време до първия токен) на съвременните модерни модели, всяка милисекунда е от значение за създаването на приятно потребителско изживяване. Прекарахме последните две години в оптимизиране на латентността за нашите собствени потребители и сме доволни, че същите тези инвестиции сега ще са от полза и за общността на разработчиците.

Латентност на Search API

(заявки, инициирани от AWS us-east-1)

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

* Много доставчици на API за търсене използват SERP сканиране като основа за своите резултати. За да уловим производителността на такива подходи, използваме представителен базиран на Google SERP API, предоставен от Tavily.

Това предимство в скоростта не е за сметка на качеството. Perplexity Search API предоставя най-съвременна производителност както в едностъпково търсене, така и в настройки за задълбочено проучване. На всеки тестван бенчмарк Perplexity води групата в предоставянето на висококачествени резултати, които могат да захранят AI работни процеси с различна сложност. Разликата между Perplexity и най-добрата алтернатива е особено изразена при SimpleQA и HLE, което показва, че тези резултати са устойчиви в целия спектър от сложност на задачите.

Уголеми

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

Бенчмаркове за качество на Search API

Оценки за качество на Search API върху SimpleQA, FRAMES, BrowseComp и HLE.

Все още сме в ранните дни на базираните на AI търсачки и изкуството и науката на измерването без съмнение ще се развиват. Каним общността да допринесе, като разработи строги и креативни методи за оценка на търсачките в ерата на AI агентите.

Градивният елемент за следващата глава на AI

Бъдещето на агентните системи и интелигентните асистенти ще зависят от наличието на богати програмни интерфейси към колективното знание в света. Днешните стари търсачки са наситени в използването си с приблизително 10¹⁰ заявки на ден, цифра, която вероятно е достигнала своя връх. Следващото поколение системи за търсене и извличане ще обслужват многократно по-голям брой заявки, тъй като непрекъснато растящата вселена от AI агенти разчита на тях за точна информация в реално време.

Нашите усилия до момента ни позиционираха като най-бързата, най-производителна търсачка, достъпна чрез 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}
}