Architecture et évaluation d’une API de recherche axée sur l’IA

La construction d’une API de recherche évolutive et axée sur l’IA présente des défis de recherche uniques à l’intersection de la recherche d’information, de l’IA et de la conception de systèmes. Contrairement aux services traditionnels qui fonctionnent sur des données délimitées, une API de recherche doit indexer en continu des milliards de documents, comprendre l’intention de requête à travers les langues et les domaines, et afficher des résultats pertinents en quelques millisecondes. Dans un monde d’agents IA, une API de recherche doit également organiser avec soin le contexte fourni aux modèles des développeurs pour garantir que ces modèles fonctionnent de manière optimale et intègrent des informations maximalement précises. Une ingénierie de contexte efficace exige que l’API ne se contente pas de capturer la pertinence au niveau du document, mais traite également les sections et les segments individuels des documents comme des unités de premier ordre à part entière.

Dans cet article, nous présentons la conception et l’évaluation de l’API Perplexity Search. Nous explorons d’abord l’architecture et les décisions techniques clés derrière notre infrastructure de recherche en production qui traite 200 millions de requêtes quotidiennes. Notre architecture combine des mécanismes de récupération hybrides, des pipelines de classement à plusieurs étapes, une indexation distribuée et une analyse dynamique via un module de compréhension de contenu à amélioration automatique.

Nous décrivons ensuite notre approche pour évaluer empiriquement les performances de l’API de recherche via un cadre d’évaluation récemment mis en open-source. Grâce à une analyse comparative complète avec les API commerciales existantes, nous démontrons des performances de pointe en termes de qualité et de latence. L’API Perplexity Search est disponible pour les développeurs du monde entier à partir d’aujourd’hui.

[Trouvez search_evals sur GitHub]

Construire un système de recherche optimisé pour les modèles d’IA

Depuis notre fondation, nous avons compris que des capacités de recherche robustes seraient essentielles pour permettre les produits d’IA qui définissent la catégorie que nous voulions proposer. À l’origine, nous espérions que ces capacités existaient déjà sous une forme accessible au public. Nous avons expérimenté le portefeuille d’API de recherche disponibles fin 2022, et la toute première version du moteur de réponse de Perplexity intégrait en fait certaines de ces offres. Plus précisément, nous analysions les requêtes des utilisateurs, formulions et envoyions des demandes à ces API, et collections les résultats comme contexte pour notre pipeline de génération en aval.

Cependant, alors que les utilisateurs affluaient vers Perplexity, nous avons rapidement réalisé que ces API ne seraient pas à la hauteur de notre croissance. Les prix que nous avons rencontrés étaient exorbitants, l’un des principaux fournisseurs d’API facturant 200 $ par millier de requêtes. Mais plus grave encore, ces API héritées n’étaient tout simplement pas conçues pour les nouveaux paradigmes de récupération introduits par les systèmes d’IA de pointe.

Agrandir

Pour commencer, les formats de requête et de réponse de ces API héritées étaient conçus pour un monde dans lequel les humains seraient les consommateurs exclusifs des résultats de recherche. Par conséquent, ces API privilégiaient les résultats au niveau du document, à l’exclusion d’informations plus fines révélées par des unités de sous-document. Le succès d’un modèle d’IA dépend de la qualité et de la compacité du contexte fourni, et nous avons constaté directement comment une récupération trop large pouvait faire dérailler les modèles d’IA, quelle que soit la pertinence globale des documents récupérés. Nos tentatives pour forcer la précision sur des résultats imprécis n’ont rencontré qu’un succès limité.

Nous avons également observé que les API héritées étaient soit trop obsolètes, soit trop lentes. Les API de recherche développées indépendamment reposaient sur des index incomplets et trop peu fréquemment mis à jour. Les API basées sur le scraping, telles que les diverses API SERP non officielles pour Google Search, bénéficiaient d’un index plus complet mais offraient une latence inacceptablement élevée en raison de l’inefficacité inhérente à l’interrogation d’un moteur de recherche tiers. Une latence élevée rendait les API inadaptées aux applications orientées utilisateur, tandis que l’obsolescence rendait les ensembles de résultats inutilisables pour tout système d’IA souhaitant être précis et digne de confiance.

Enfin, nous avons observé l’écosystème de l’IA bifurquer entre la recherche lexicale et la recherche sémantique, avec l’émergence de systèmes sur-optimisés pour une modalité plutôt que pour l’autre. Nous avons vu la montée en puissance des bases de données vectorielles qui ne pouvaient même pas prendre en charge correctement de simples filtres booléens. Les backends de recherche traditionnels ne s’en sortaient guère mieux, avec une prise en charge primitive du classement sémantique et des opportunités de récupération débloquées par l’IA.

Alors que nous réalisions que rendre Perplexity encore meilleur nécessiterait de construire notre propre infrastructure de recherche dédiée, nous avons distillé nos observations en trois critères clés :

Exhaustivité, fraîcheur et vitesse : l’index de recherche doit être exhaustif, constamment mis à jour et conçu pour une latence en temps réel.

Compréhension fine du contenu : la fragilité des modèles d’IA et les fenêtres de contexte limitées exigent que les résultats de recherche soient présentés et classés au niveau le plus granulaire possible.

Récupération et classement hybrides : les pipelines de récupération et de classement doivent tous deux intégrer des signaux lexicaux et sémantiques pour que les résultats soient utiles pour l’IA.

Agrandir

Infrastructure d’exploration et d’indexation

Opérer à l’échelle de Perplexity nécessite une infrastructure capable de cartographier de manière exhaustive le Web et de répondre à son évolution constante. Notre index de recherche suit plus de 200 milliards d’URL uniques, avec la capacité d’en suivre des centaines de milliards supplémentaires.

S’assurer que notre index couvre une partie suffisamment exhaustive d’Internet et que chaque document reflète l’état le plus récent est un exploit difficile. Il existe une tension inhérente entre l’exhaustivité et la fraîcheur : pour un budget d’indexation fixe, les opérations de rafraîchissement des pages existantes doivent rivaliser avec les opérations d’indexation des nouvelles pages non visitées. Nous équilibrons cette tension par une combinaison de mise à l’échelle (qui assouplit la contrainte d’optimisation en augmentant le budget d’indexation) et de priorisation pilotée par le ML (qui garantit que chaque opération d’indexation est maximalement précieuse pour l’index dans son ensemble).

Nous avons construit un index à l’échelle de l’exaoctet et un appareil d’exploration qui s’adapte horizontalement à la fois en taille et en volume de requêtes. Les flottes d’exploration et d’indexation de Perplexity comprennent collectivement des dizaines de milliers de processeurs et des centaines de téraoctets de RAM, avec une marge de manœuvre considérable pour une mise à l’échelle ultérieure. Nous marions cette infrastructure informatique avec un équilibre de stockage froid et chaud. Nous utilisons à la fois des modèles appris et des heuristiques ajustées pour déterminer quels documents doivent être conservés au chaud, en donnant la priorité aux documents provenant de domaines faisant autorité, aux documents traitant de sujets peu couverts et à d’autres catégories ayant un potentiel exceptionnel pour enrichir notre index.

Cette infrastructure permet à Perplexity de traiter des dizaines de milliers d’opérations d’indexation par seconde. Mais même avec ce budget relativement généreux, l’échelle d’Internet est bien trop vaste pour indexer chaque URL sur une base fréquente et récurrente. C’est là que le ML intervient. Nous entraînons un modèle ML pour prédire si une URL candidate donnée doit être indexée. L’objectif de formation est conçu pour garantir que nous calibrons notre décision d’indexation à la fois sur l’importance et sur la fréquence de mise à jour probable de l’URL spécifique. Nous comptons également sur le ML pour nous dire précisément quand planifier l’opération d’indexation. Pour les sites avec des rythmes de publication et de rafraîchissement routiniers, cela nous permet de différer les opérations au moment où elles sont susceptibles d’être les plus utiles. Grâce à l’affinement continu de ces modèles ML, nous sommes en mesure de maintenir un index qui répond aux exigences à la fois en matière d’exhaustivité et de fraîcheur.

Bien que notre infrastructure d’exploration s’adapte facilement horizontalement, nous sommes conscients que les opérateurs de sites Web sont confrontés à des contraintes techniques différentes. Nous veillons à maintenir un taux de requêtes prévisible et gérable vers n’importe quel domaine. PerplexityBot, notre crawler de recherche, se conforme aux limites explicites définies dans les fichiers robots.txt, ou en l’absence de limites spécifiées par le domaine, aux normes de l’industrie concernant les taux de requêtes. Nous ajustons également notre comportement d’exploration lorsque nous détectons l’indisponibilité d’un site. Notre système distribué est conçu pour faire respecter ces limites même sur des dizaines de milliers d’opérations simultanées.

Compréhension du contenu à amélioration automatique à l’échelle d’Internet

Même avec l’un des indices de recherche les plus vastes et les plus récents de la planète, la qualité des résultats de chaque requête dépend de la compréhension par notre système du contenu de chaque document. Ici, nous sommes confrontés à un défi fondamental : le Web est un endroit désordonné. Aucun ensemble fixe de règles d’analyse ne peut gérer l’infinie variété de mises en page, de structures et de styles trouvés sur tout l’Internet.

Nous avons résolu ce défi en développant un module de compréhension de contenu qui analyse les sites Web et extrait un contenu sémantiquement significatif à l’aide d’ensembles de règles dynamiques. Un site Web riche en données bien structurées sous forme de liste ou de tableau peut bénéficier de règles d’analyse et d’extraction plus formulaires, tandis qu’un autre site Web présentant principalement du contenu généré par les utilisateurs en forme libre peut nécessiter un ensemble de règles plus souple. Parce que le Web est principalement statique sur de courtes périodes, nous constatons que la durée de vie d’une règle donnée est relativement longue. Mais à mesure que les sites évoluent au fil du temps et que nous apprenons les meilleures façons d’extraire des informations, nos ensembles de règles nécessitent également un jardinage continu.

Pour faciliter cette adaptation dynamique, nous nous tournons (bien sûr) vers l’IA. À l’échelle de Perplexity, nous observons une coupe transversale incroyablement riche du Web au cours du service de millions de requêtes utilisateur par heure. Cela forme la base d’une boucle d’auto-amélioration itérative. Nous observons le comportement d’analyse et les sorties extraites de nos ensembles de règles actuels à travers notre univers de requêtes. Nous utilisons ensuite des LLM de pointe pour évaluer les performances selon deux dimensions principales :

Exhaustivité : notre index doit recevoir autant de contenu sémantiquement significatif que possible, tout en évitant l’extraction fallacieuse de matière non informative ou absurde.

Qualité : notre index repose sur un contenu de haute qualité tant au niveau de la substance que de la forme. Les informations doivent être capturées de manière à préserver la structure et la mise en page du contenu original.

Notez que l’exhaustivité et la qualité présentent une autre tension inhérente : l’optimisation manuelle pour la qualité est possible, mais les règles d’analyse résultantes peuvent échouer à capturer un contenu critique. De même, nous pourrions coder manuellement des règles permissives qui appliquent un filtrage minimal au contenu brut, ce qui pourrait améliorer l’exhaustivité mais au détriment de la qualité. C’est pourquoi nous nous tournons vers l’auto-amélioration pilotée par l’IA pour faire évoluer notre ensemble de règles d’une manière qui peut optimiser les deux à la fois de manière adaptable au domaine.

Concrètement, après chaque évaluation par LLM des performances d’analyse, notre système formule un ensemble de modifications proposées aux règles pour traiter les classes d’erreurs les plus significatives. Ces ensembles de règles font l’objet d’une validation supplémentaire, après quoi nous déployons la nouvelle version sur notre indexeur. Étant donné que les améliorations de la logique d’analyse et d’extraction ne peuvent profiter qu’aux futures opérations d’indexation, nos investissements dans la réindexation optimisée par le ML sont particulièrement importants : rafraîchir en continu les documents à fort trafic en utilisant la dernière version de cette logique garantit une boucle d’auto-amélioration serrée.

Ces règles comptent non seulement pour les performances d’analyse de base, mais aussi pour la segmentation en unités de sous-document. Lorsqu’il s’agit de LLM de pointe, chaque jeton de contexte est précieux. Un grand nombre de travaux antérieurs ont documenté comment les performances des LLM se dégradent avec l’augmentation de la taille du contexte et la pollution du contexte par des informations non pertinentes. Avoir une analyse bien structurée et exhaustive nous permet de décomposer les documents en segments autonomes, chacun pouvant être récupéré et classé individuellement au moment de la requête.

Pipeline de récupération et de classement

La recherche moderne nécessite d’assurer à la fois l’exhaustivité et la pertinence dans le cadre d’un budget de latence serré. Le pipeline de récupération et de classement de Perplexity y parvient grâce à une architecture à plusieurs niveaux qui affine progressivement les résultats avec une série de modules de plus en plus sophistiqués. Nous résolvons les goulots d’étranglement potentiels en mettant à l’échelle horizontalement tous les points de congestion potentiels dans la mesure du possible.

Le pipeline commence par la récupération à partir de notre index. Nous ne forçons pas un choix entre la récupération lexicale et sémantique. Au lieu de cela, nous interrogeons l’index de recherche via les deux modalités et fusionnons les résultats dans un ensemble de candidats hybrides. À ce stade, la priorité est l’exhaustivité par rapport à la précision - les étapes ultérieures du pipeline optimiseront pour la précision.

Le pipeline se poursuit avec des étapes de pré-filtrage, au cours desquelles nous appliquons des heuristiques de base et des filtres de première intention pour supprimer le contenu clairement non réactif ou obsolète de l’ensemble des candidats.

Nous employons ensuite plusieurs étapes de classement progressivement avancé. Les étapes antérieures reposent sur des marqueurs lexicaux et basés sur des intégrations optimisés pour la vitesse. Au fur et à mesure que l’ensemble des candidats est progressivement réduit, nous utilisons ensuite des modèles de ré-classement cross-encoder plus puissants pour effectuer la sculpture finale de l’ensemble des résultats. Grâce à nos nombreux investissements dans les performances d’inférence, nous sommes en mesure de tirer parti des architectures de modèles de pointe pour ces étapes ultérieures tout en maintenant une latence de classement globale faible.

Tout au long de ce pipeline, nous récupérons et marquons les résultats aux niveaux du document et du sous-document. Comme discuté ci-dessus, l’IA nécessite une ingénierie de contexte minutieuse. Notre pipeline est conçu pour faire apparaître les unités les plus atomiques possibles au modèle, de sorte que les consommateurs en aval puissent intégrer ces unités précises sans extraire de contexte non pertinent ailleurs dans les documents sources.

Assurer une haute qualité à chaque étape de ce pipeline n’est possible que grâce à une co-conception avec le portefeuille de produits de Perplexity. Chaque détail de la pile de classement est conçu pour tirer parti du riche signal produit par les millions de requêtes utilisateur que nous servons chaque heure de la journée. La grande majorité de ce signal est automatisée, chaque réponse de Perplexity générée fournissant un point de données empirique sur la qualité de la recherche telle qu’utilisée dans un flux de travail agentique en direct. Nous combinons les évaluations pilotées par l’IA avec les commentaires humains en direct pour enrichir les données de formation pour nos modèles d’intégration et de classement bien au-delà de ce que tout ensemble de données construit manuellement peut offrir.

Cette synergie entre la recherche et le produit est unique à Perplexity. Les moteurs de recherche hérités sont limités au signal brut fourni par la télémétrie des liens bleus. Les nouvelles offres de recherche ont tenté d’implémenter certains de ces concepts axés sur l’IA, mais elles manquent d’environnements réels capables de valider la qualité de la recherche et de fournir la richesse du signal nécessaire aux boucles d’amélioration rapide. Nous avons la chance d’avoir l’ingrédient manquant : un terrain d’essai en direct pour la qualité de la recherche, propulsé par des LLM de pointe et continuellement testé au combat par des millions d’utilisateurs curieux dans le monde entier.

Établir une nouvelle frontière pour la qualité et la performance

Après avoir construit l’API Perplexity Search et le SDK pour rendre notre infrastructure de recherche disponible pour les développeurs du monde entier, nous voulions comprendre comment les diverses offres d’API commerciales se situaient dans les cas d’utilisation de l’IA réelle. Il est devenu courant d’évaluer les modèles d’IA eux-mêmes, mais nous avions besoin d’une variante de ce modèle : évaluer la qualité des API de recherche lorsqu’elles sont invoquées par des modèles d’IA.

Nous nous sommes d’abord tournés vers l’écosystème open-source pour comprendre l’état de la technique. Nous avons trouvé bon nombre des ingrédients clés pour une évaluation rigoureuse, mais aucun cadre qui intègre ces ingrédients dans une solution d’analyse comparative prête à l’emploi. Nous avons donc entrepris de développer un cadre d’évaluation qui pourrait être utilisé non seulement par Perplexity, mais par tout chercheur ou développeur cherchant à comparer des API de recherche.

En utilisant ce cadre d’évaluation, nous avons rigoureusement comparé l’API Perplexity Search à d’autres offres. L’optimisation des performances de recherche est complexe, avec de nombreux compromis nuancés entre qualité et vitesse. Pour le plus grand bénéfice des développeurs, nous avons constaté que l’API Perplexity Search établit un nouveau standard en termes de qualité et de latence. Les développeurs n’ont plus besoin de choisir entre la construction d’applications ultra-rapides et la garantie de résultats de haute qualité : avec Perplexity, ils peuvent avoir les deux.

Agrandir

Concevoir des évaluations fiables pour les flux de travail de recherche agentique

Nous avons commencé par définir trois principes directeurs pour notre cadre d’évaluation :

Spectre de complexité : le cadre d’évaluation doit mesurer les performances sur des cas d’utilisation d’IA agentique à la fois simples et complexes.

Neutralité : le cadre d’évaluation doit évaluer toutes les API sur un pied d’égalité.

Simplicité : bien que certains cas d’utilisation puissent être complexes, le cadre lui-même doit être aussi simple que possible afin que d’autres puissent le comprendre, reproduire les résultats et étendre le cadre avec un minimum de fastidiosité.

Notre cadre d’évaluation léger, search_evals, atteint ces objectifs grâce à une conception modulaire simple. Nous avons développé deux harnais d’agents IA pour capturer à la fois les cas d’utilisation de recherche classique en un seul coup et les flux de travail agentiques avancés (illustrés par divers produits de “recherche approfondie” largement disponibles sur le marché grand public). Les deux harnais ont été implémentés de manière simple qui laisse peu de place à un avantage caché.

Pour piloter nos évaluations, nous avons adopté quatre benchmarks : SimpleQA et FRAMES pour la recherche en une seule étape, ainsi que BrowseComp et HLE pour la recherche approfondie. Collectivement, ces benchmarks fournissent des étalons bien acceptés pour les agents de connaissance. Suivant la convention établie, nous notons tous les benchmarks en utilisant la même méthodologie de classificateur avec invite utilisée dans le travail original. Les implémentations précises des benchmarks (y compris la logique de notation) peuvent être examinées dans notre dépôt GitHub.

Nous avons conçu le cadre avec la reproductibilité et l’extensibilité à l’esprit. Les scores au niveau de la tâche et les sorties sous-jacentes de l’agent sont stockés à chaque exécution. Des harnais, des benchmarks et des offres d’API de recherche supplémentaires peuvent être facilement intégrés. Les chercheurs et les développeurs peuvent lire nos documents GitHub pour plus d’informations sur l’extension du cadre pour répondre à vos besoins précis.

Résultats de l’évaluation

Armés de ce cadre d’évaluation, nous avons entrepris d’évaluer notre API de recherche par rapport à d’autres offres d’API. Sur tous les benchmarks testés, Perplexity s’impose comme l’API la plus rapide et de la plus haute qualité sur le marché.

Agrandir

Nous avons constaté que nos investissements décrits ci-dessus dans l’efficacité de l’index, de la récupération et du classement ont porté leurs fruits. La latence médiane de Perplexity est de 358 ms, soit plus de 150 ms devant le deuxième fournisseur le plus rapide. La latence au 95e centile reste confortablement sous les 800 ms. Avec les longues métriques TTFT (temps jusqu’au premier jeton) des modèles de pointe actuels, chaque milliseconde compte pour créer des expériences utilisateur délicieuses. Nous avons passé les deux dernières années à optimiser la latence pour nos propres utilisateurs, et nous sommes heureux que ces mêmes investissements profitent désormais également à la communauté des développeurs.

Latence de l’API de recherche

(requêtes initiées depuis AWS us-east-1)

Percentiles de latence de l’API de recherche pour les requêtes initiées depuis AWS us-east-1.

* De nombreux fournisseurs d’API de recherche utilisent le scraping SERP comme base pour leurs résultats. Pour capturer les performances de telles approches, nous utilisons une API représentative basée sur Google SERP proposée par Tavily.

Cet avantage de vitesse ne se fait pas au détriment de la qualité. L’API Perplexity Search offre des performances de pointe dans les paramètres de recherche en une seule étape et de recherche approfondie. Sur chaque benchmark testé, Perplexity est en tête pour fournir des résultats de haute qualité capables d’alimenter des flux de travail IA de complexité variable. La marge entre Perplexity et la meilleure alternative est particulièrement prononcée sur SimpleQA et HLE, ce qui indique que ces résultats sont robustes sur l’ensemble du spectre de complexité des tâches.

Agrandir

Comme pour la latence, notre leadership en matière de qualité de recherche découle de notre leadership dans la construction de produits d’IA délicieux et très fréquentés. Nos millions d’utilisateurs utilisent Perplexity pour satisfaire leur curiosité sur tous les sujets imaginables, et les signaux de qualité et de pertinence qui en résultent permettent à nos modèles de recherche de s’améliorer à chaque heure qui passe.

Benchmarks de qualité de l’API de recherche

Scores de qualité de l’API de recherche sur SimpleQA, FRAMES, BrowseComp et HLE.

Nous sommes encore aux premiers jours des moteurs de recherche natifs de l’IA, et l’art et la science de la mesure évolueront sans aucun doute. Nous invitons la communauté à contribuer en développant des méthodes rigoureuses et créatives pour évaluer les moteurs de recherche à l’ère des agents IA.

Le bloc de construction pour le prochain chapitre de l’IA

L’avenir des systèmes agentiques et des assistants intelligents dépendra de la disponibilité d’interfaces programmatiques riches sur la connaissance collective mondiale. Les moteurs de recherche hérités d’aujourd’hui ont saturé en utilisation à environ 10¹⁰ requêtes par jour, un chiffre qui a probablement atteint un sommet. La prochaine génération de systèmes de recherche et de récupération servira des ordres de grandeur de requêtes supplémentaires, car un univers toujours croissant d’agents IA s’appuie sur eux pour des informations précises en temps réel.

Nos efforts à ce jour nous ont positionnés comme le moteur de recherche le plus rapide et le plus performant accessible via API. Mais une innovation encore plus ambitieuse sera nécessaire pour nous permettre d’alimenter le prochain chapitre de l’IA. Comment mettre à l’échelle efficacement ces systèmes face à une demande toujours croissante ? Comment ces systèmes de recherche peuvent-ils être optimisés à la lumière de nouvelles approches en ingénierie de contexte et de post-formation ? Et comment naviguer dans la tension toujours présente entre exhaustivité, récence et latence ? Ce sont des questions ouvertes que Perplexity, avec notre combinaison d’empreinte produit, d’échelle et de talent technique, est uniquement positionné pour aborder.

Citation

@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://perplexity.coolkeypoint.com/hub/blog/architecting-and-evaluating-an-ai-first-search-api}
}