À quel point est-il difficile de créer un moteur de recherche vraiment performant ? — Index : Un système de recherche de documents dynamique à la milliseconde conçu spécifiquement pour les agents d’IA. Cette présentation technique complète d'Abhi, fondateur d'@opennote, est consacrée à Index, leur système de recherche interne. Ce système n'est pas un moteur de recherche humain ; il est conçu pour permettre aux agents d'IA d'effectuer une recherche extrêmement rapide et précise au sein des bases de connaissances personnelles des utilisateurs. Pourquoi les systèmes de recherche actuels ne répondent-ils pas aux besoins des agents intelligents ? Les moteurs de recherche traditionnels sont conçus pour les humains. Ces derniers apprennent progressivement à comprendre les particularités du système, à remplacer ou compléter des mots et à contourner les erreurs. Les agents intelligents, en revanche, en sont totalement dépourvus. Chaque requête est traitée à partir de zéro ; ils n’ont ni mémoire ni intuition de la base de connaissances. Plus grave encore : • Les agents intelligents sont très sensibles aux hallucinations ; si le contexte est légèrement erroné, toute la réponse s'effondrera. • Opennote ne traite généralement que quelques milliers de documents (et non des centaines de millions), avec une tolérance aux erreurs pratiquement nulle, exigeant que le segment le plus correct soit trouvé du premier coup. • Étant donné que le produit est destiné aux consommateurs ordinaires, il ne peut pas attendre quelques secondes comme un outil de recherche ; la latence de bout en bout doit être stable à quelques centaines de millisecondes près. Les auteurs soulignent à plusieurs reprises qu'un indice doit simultanément satisfaire aux exigences quasi contradictoires suivantes : 1. Latence extrêmement faible : P99 < 300 ms (même vitesse partout dans le monde) 2. Haute précision : Lorsqu'un même concept apparaît dans différents documents, il est également nécessaire de trouver celui qui possède le contexte le plus précis. 3. Multi-locataire et portée dynamique : Prend en charge les recherches simultanées de toute combinaison de « moi uniquement », « partagé avec des amis », « toute la communauté » et « plus les pages publiques » sans dégradation des performances. 4. Faible latence globale : les utilisateurs et les agents peuvent se trouver aux antipodes. 5. Les données ne sont jamais statiques : les utilisateurs peuvent les modifier, les partager, les supprimer et changer les autorisations à tout moment. Sélection des technologies clés (dont beaucoup sont contre-intuitives) 1. Le moteur de recherche principal et de stockage choisi est Postgres (pgvector + pg_trgm + tsvector), hébergé sur PlanetScale, au lieu des bases de données vectorielles dédiées courantes telles que Pinecone, Weaviate, Qdrant et Chroma. La raison est la suivante : • Filtrage des métadonnées extrêmement rapide, minimisant l'ensemble des candidats avant les calculs vectoriels. • Prise en charge native d'une véritable recherche hybride (texte intégral + correspondance floue + sémantique). • La gestion des limites multi-locataires, le filtrage dynamique et les opérations UPSERT/DELETE sont intrinsèquement efficaces. • Des tests en conditions réelles ont démontré que la latence P99 a été réduite de 475 ms à 209 ms. 2. L'architecture d'exécution distribuée globale complète fonctionne sur l'écosystème Cloudflare : Workers + Hyperdrive + R2 + Workers AI + Vectorize + KV. L'avantage est que le code s'exécute naturellement sur des dizaines de nœuds périphériques à travers le monde, et que lors de l'accès à la base de données, la vitesse est aussi rapide qu'en local après avoir été accélérée par Hyperdrive. 3. Pipeline de traitement des documents (Ingestion) Elle adopte une architecture de stockage d'objets Worker + R2 entièrement sans état, respectant scrupuleusement la limite de mémoire de 128 Mo du Worker. Le processus est le suivant : 1. Décomposition récursive par blocs (suffisamment robuste pour tous types de documents désordonnés) 2. Utilisez le hachage pour comparer avec précision les anciens et les nouveaux blocs, en recalculant uniquement les parties réellement modifiées. 3. Réintégrer uniquement les segments modifiés (gain de temps et d'argent) 4. Générer des résumés pour les documents et les paragraphes importants, donnant à l'agent un contexte supplémentaire sur « le sujet de l'ensemble du document ». 5. Insérer un nouveau bloc 6. Supprimez l'ancien bloc et déclenchez l'invalidation du cache. 4. Processus de recherche 1. Dès réception d'une requête de l'agent, effectuez d'abord le nettoyage des paramètres et la concaténation des conditions de filtrage. 2. Dans Postgres, utilisez les métadonnées pour pré-minimiser l'espace de recherche (locataire, source, étiquette, temps, exclusion explicite, etc.). 3. Exécutez en parallèle la recherche plein texte et la recherche vectorielle sur l'ensemble de données filtré. 4. Normalisez les deux ensembles de scores à 0-1 et fusionnez-les dynamiquement à l'aide d'un paramètre appelé alpha (0 = mots-clés purs, 1 = sémantique pure). 5. Effectuer la déduplication, le tri et la récupération des K meilleurs résultats dans la base de données. 6. En option, utilisez l'IA des travailleurs pour effectuer un tri léger, puis renvoyez le résultat. 5. Système de mise en cache (la partie la plus ingénieuse) Les caches classiques se salissent après les mises à jour de documents ; l’auteur a conçu un mécanisme à trois niveaux pour résoudre complètement ce problème : • Mise en cache précise : Une même requête + les mêmes conditions de filtrage ciblent directement la paire clé-valeur. • Mise en cache sémantique : Vectorize est utilisé pour stocker les représentations vectorielles des requêtes, ce qui permet de mettre en cache les requêtes similaires. • Invalidation de l’index inversé : Chaque segment enregistre les requêtes auxquelles il appartient dans le cache ; si un segment devient invalide, tous les caches associés sont supprimés de manière proactive. Cela réduit considérablement la pression sur la base de données et garantit qu'aucun contenu obsolète ne soit jamais renvoyé. Les résultats réels des tests ont été rigoureusement comparés à ChromaDB en utilisant l'ensemble de données standard MSMARCO (10 000 paires question-réponse) + modèle BGE-M3. En termes de quatre indicateurs (Recall@10, MRR@10, MAP@10 et NDCG@10), Index se situe globalement au même niveau, voire légèrement au-dessus, de Chroma. Il offre également des fonctionnalités supplémentaires telles que la recherche hybride, l'isolation multi-locataire et le filtrage dynamique. En environnement de production réel, la latence P99 est stable à moins de 300 ms. L'index prend désormais officiellement en charge l'intégralité du processus de recherche pour les fonctionnalités communautaires d'Opennote. L'auteur estime que l'index actuel n'est qu'un outil de « récupération », et que la prochaine étape consiste à le faire évoluer vers un outil de « compréhension » : • Ajouter des relations temporelles, causales et évolutives entre les segments. • Introduire des signaux d'importance/de popularité. • Poursuivre le développement de modèles d'intégration plus petits, plus rapides et plus spécialisés. • Permettre aux agents de personnaliser les stratégies de recherche en plusieurs étapes. L'objectif ultime est de permettre aux agents intelligents de posséder véritablement un « modèle mental » de la base de connaissances de l'utilisateur, plutôt que de deviner à l'aveuglette à chaque fois.
