XERJ : un moteur de recherche local pour agents de code qui avoue ses propres chiffres

Il est rare de tomber sur un projet dont la caractéristique la plus intéressante est sa propre confession.

XERJ est un moteur de recherche en Rust pour le code et les documents, conçu pour les agents de codage, avec un protocole compatible Elasticsearch et une licence Apache-2.0. Il propose un tableau de benchmarks avec de vrais montants en dollars. Il contient aussi une note du mainteneur qui reconnaît que son nombre d’étoiles GitHub est gonflé d’environ treize fois par une cohorte synthétique, et qui demande de ne pas le citer.

Ces deux choses méritent votre temps, et elles sont liées.

Le problème qu’il vise

Quand un agent de codage doit comprendre une base de code, le réflexe par défaut est grep. Grep est honnête : il trouve les lignes qui correspondent à un motif. Mais un agent qui utilise grep doit lire les fichiers pour savoir si la correspondance compte, et lire des fichiers, c’est ce qui remplit une fenêtre de contexte. Un seul gros fichier peut consommer plus de tokens que la réponse n’en valait.

L’alternative de XERJ est un index local. Pointez-le sur un dossier, et autoindex renifle les types de fichiers, déduit les jeux de données, jette les déchets et construit un index séparé par jeu de données. Le journal d’une vraie exécution, dans le dépôt, se lit ainsi : 593 datasets déduits, 1 955 fichiers indésirables ou ignorés en phase A, puis la phase B indexant 25 329 fichiers avec huit workers, terminée en 158,1 secondes avec 83 103 enregistrements actifs.

Le code est analysé avec tree-sitter, en conservant les symboles et les numéros de ligne au lieu d’aplatir le tout en texte. C’est pourquoi xerj def <symbol> peut renvoyer un fichier, une ligne et une signature — un saut à la définition à l’échelle d’un dépôt, exactement ce dont un agent avait besoin au départ.

Le benchmark, à lire attentivement

Le projet a exécuté huit tâches dans quatre langages, seize passes par bras, et a mesuré la consommation réelle de tokens de claude -p plutôt que de l’estimer. Trois configurations : mémoire seule, pilotée par grep, et XERJ.

Mémoire seule : 260 916 tokens de sortie, 11,18 $, 11 tâches résolues sur 16. Grep : 26 477 tokens, 3,27 $, les 16 résolues. XERJ : 9 982 tokens, 1,58 $, les 16 également.

Soit environ 2,7 fois moins de tokens de sortie que grep, 26 fois moins que de s’en remettre à la mémoire du modèle, sans changement du taux de réussite. Le meilleur cas isolé — une tâche Java — économise 278 fois. Les utilisateurs rapportent environ 5x de bout en bout.

Maintenant, la réserve qui rend cet article nécessaire. L’accroche du dépôt annonce « 40x moins de tokens que grep ». L’expérience contrôlée du corps du texte dit 2,7x. Ce ne sont pas les mêmes affirmations, et l’écart entre les deux est exactement le schéma qui rend le marketing fondé sur des benchmarks peu fiable. À son crédit, le README lui-même invite à préférer le chiffre du corps. Un titre qui survend et une note de bas de page qui le corrige, c’est une drôle de façon de livrer un projet, mais au moins la correction est là.

La contrainte dont personne ne parle dans les annonces

Voici la phrase que la plupart des projets de « recherche pour agents » omettent : le bénéfice dépend de si le modèle connaît déjà le code.

Sur du code privé, interne, de niche ou postérieur à la date de coupure de l’entraînement, la recherche fait gagner beaucoup, parce que le modèle ne peut vraiment pas deviner. Sur les bibliothèques open source populaires que le modèle a vues dix mille fois, l’index est neutre ou franchement nuisible : vous dépensez des tokens à récupérer ce que le modèle savait déjà.

Cette seule contrainte change la façon de le déployer. Ce n’est pas une mise à niveau universelle. C’est un remède à un mode de défaillance précis : des agents qui travaillent sur du code dont personne n’a écrit d’article de blog.

Le drapeau --insecure est une vraie frontière de confiance

Lancer xerj --insecure désactive TLS et l’authentification de l’API. Quiconque atteint le port est de facto superutilisateur : lire, écrire, supprimer tous les index, y compris tout ce qui est sous /_memory. C’est acceptable sur l’ordinateur portable d’un développeur, et catastrophique sur tout ce qui est partagé.

Les valeurs par défaut sont meilleures que le drapeau. Un nouveau nœud se lie à 127.0.0.1, et une liaison en clair sur une adresse non locale refuse de démarrer sauf si vous définissez explicitement server.allow_insecure_network_bind = true. Le projet note aussi que faire tourner l’insecure sur 0.0.0.0 a été une vraie vulnérabilité — des clients du LAN pouvaient écrire sans autorisation — et qu’elle est corrigée. Nommer sa propre vulnérabilité passée est une bonne habitude.

La divulgation qui devrait servir de modèle

Dans un commit d’instrumentation, le mainteneur écrit que les étoiles et forks du dépôt ont été amplifiés d’environ treize fois par une cohorte synthétique, que les données d’installation réelles sont minces — environ 145 téléchargements d’artefacts de release et à peu près 28 installations menées à terme — et que Cloudflare RUM a cessé d’enregistrer en juillet, donc le graphique de trafic nul sur le site est un artefact.

Pour un projet qui revendique la compatibilité Elasticsearch et fait passer 1 371 tests de conformité (zéro échec, trois ignorés), c’est une chose remarquable à publier. Cela dit aussi quelque chose de l’état actuel des signaux open source : un compteur d’étoiles est une surface marketing, et quiconque fait tourner une boucle de croissance peut le faire bouger. Les seuls chiffres qui méritent confiance sont ceux qu’un auteur avance contre son propre intérêt.

Ce que vous croiserez aussi

L’installation est un curl piped vers le shell, qui vérifie le SHA256 et refuse de continuer s’il ne trouve pas d’outil de somme de contrôle — une garde étonnamment sensée pour ce schéma. Les builds sont en musl statique avec jemalloc, Linux d’abord, Windows en installation manuelle. Il y a un serveur MCP exposant treize outils, dont xerj_plan et xerj_map, et xerj init branche Claude Code ou Cursor en une commande. Le kNN avec quantification scalar8 est pris en charge. Le déploiement multi-nœuds arrive avec un chart Helm et un fichier compose.

La version est 1.0.0-rc.x, et la CLI bouge encore. Le CLA est adapté de celui d’Apache, avec une note du mainteneur précisant qu’un juriste ne l’a pas relu et qu’il reste deux champs de remplissage. Beaucoup de commits sont écrits par des agents de codage et étiquetés comme tels, ce qui est transparent et donne aussi une raison de lire le code dont vous dépendez.

Le codage par référence, le cas d’usage que personne ne benchmarke

Enterré dans le README se trouve l’application la plus intéressante : pointer l’index sur le projet open source le plus proche du problème que vous résolvez, puis écrire votre propre version avec la référence en contexte.

C’est ainsi qu’une grande partie de l’ingénierie réelle se fait — trouver la bibliothèque qui a déjà résolu le problème, la lire, puis implémenter quelque chose de plus étroit. Mal fait, cela consiste à coller la moitié d’un dépôt dans un prompt. Bien fait, cela consiste à pouvoir demander « où ce projet gère-t-il la contre-pression » et obtenir un fichier, une ligne et une signature de fonction.

Cela montre aussi les limites du benchmark ci-dessus. Le codage par référence exige de télécharger et d’indexer le dépôt de quelqu’un d’autre, ce qui coûte du temps, du disque et du réseau. L’économie arrive à la deuxième et à la troisième requête, pas à la première. Qui veut évaluer cela devrait mesurer la session entière, pas une tâche.

L’affirmation de compatibilité Elasticsearch

XERJ parle le protocole filaire d’Elasticsearch, et le projet annonce 1 371 tests de conformité passés, zéro échec et trois ignorés. Si cela tient, les outils déjà écrits pour Elasticsearch peuvent pointer vers lui avec des changements minimes, et les équipes qui paient un cluster pour héberger quelques millions de documents ont une sortie.

L’argument contre la licence SSPL d’Elasticsearch est juste : SSPL n’est pas open source au sens de l’OSI, et cela compte pour les entreprises qui veulent livrer un produit au-dessus d’un moteur de recherche. Mais « compatible » est un spectre. La couverture du Query DSL, les agrégations et le comportement des analyseurs sont là où les différences apparaissent, et la suite de conformité est le seul moyen de savoir de quel côté de la ligne vous êtes.

Faut-il l’utiliser

Si vos agents travaillent sur du code interne, de gros dépôts privés, ou des journaux et documents qu’aucun modèle n’a vus, le dossier est correct : un index local, Apache-2.0, compatible ES, avec la conscience des symboles tree-sitter et un benchmark honnête. Si votre travail porte surtout sur des bibliothèques publiques, vous trouverez probablement grep et une bonne configuration ripgrep tout aussi efficaces, avec bien moins à maintenir.

Et si vous ne retenez qu’une chose de ce projet, retenez l’habitude de la divulgation plutôt que le moteur de recherche. Un outil qui vous dit que ses propres chiffres sont gonflés mérite plus d’attention qu’un outil qui vous dit qu’il est quarante fois meilleur.