Article · SaaS & dev

Écrire une recherche composable pour un agent sans masquer ses contraintes

Algebraic Retrieval transforme le retrieval en expression inspectable : scores, filtres et pondérations restent composables avant le top-k.

Une recherche composable relie requête, scores, filtres et preuves classées.

Une recherche n’est pas toujours un appel unique

Une interface de recherche exposée à un agent prend souvent la forme d’un appel avec une requête et quelques paramètres. Cette surface devient vite étroite lorsqu’il faut privilégier une intention, en diminuer une autre, filtrer les candidats et conserver une préférence de classement. Le preprint Algebraic Retrieval: Composable Search for Agents propose de représenter ces choix comme une expression que l’agent peut composer puis réviser après inspection des résultats.

L’idée centrale est de conserver ensemble les scores et les identifiants des documents. Une opération arithmétique modifie les scores, un masque restreint les identifiants admissibles, une pondération applique une préférence par document, puis un opérateur top-k sélectionne les résultats. Cette séquence ressemble davantage à un petit programme de retrieval qu’à une boîte noire.

Les opérations exposées

Le cadre s’appuie sur des vecteurs de requête et une matrice d’embeddings. Une expression peut favoriser une direction et en soustraire une autre, par exemple en calculant la similarité avec une requête puis en retirant une fraction de la similarité avec une seconde direction. Elle peut aussi limiter le calcul à un ensemble de candidats issu d’un premier passage BM25. Enfin, une relation de poids peut moduler le score de chaque candidat avant la sélection.

Le point d’ordre compte. Le papier insiste sur la différence entre restreindre les candidats avant le scoring et soustraire deux listes déjà tronquées. Les deux opérations ne répondent pas à la même question et ne produisent pas nécessairement le même classement. Pour un agent, rendre cette position explicite aide à contrôler ce que le programme a réellement demandé au moteur.

Ce que rapportent les auteurs

Les auteurs comparent trois expressions avec des équivalents SQL et PyTerrier sur la collection Vaswani de 11 429 documents. Les implémentations sélectionnent le même ensemble de documents et les écarts de scores restent inférieurs à 10-6. Une paire à égalité est toutefois ordonnée différemment selon le chemin de calcul, avec un écart d’environ 5,96 × 10-8 dans le chemin SQL. Le résultat montre une parité d’exécution sur le fixture retenu, pas un gain de qualité de recherche ni une preuve de qualité des requêtes écrites par un agent.

Lecture éditoriale

Pour une application, la valeur principale est la lisibilité du contrat. L’agent peut découvrir les opérandes autorisés, proposer une expression et recevoir une relation scorée qu’il pourra composer à nouveau. Cette surface rend les choix de ranking testables : on peut vérifier le masque, la pondération, la règle d’égalité et le nombre de résultats avant de transmettre le contexte à un générateur.

Cette composabilité demande une gouvernance. Les opérandes doivent être déclarés, les limites de coût doivent être mesurées et l’agent ne doit pas pouvoir transformer une expression en accès arbitraire à toutes les données. Le programme de retrieval mérite aussi des tests de propriétés : ordre des filtres, stabilité des égalités et équivalence entre deux implémentations.

Limites à garder

Le papier ne mesure ni l’efficacité comparative des résultats, ni le rappel d’un index approximatif, ni la capacité d’un agent à écrire de bonnes expressions. La collection et les vecteurs sont contrôlés pour la reproductibilité. Une intégration réelle devra donc tester des corpus vivants, des permissions, des coûts et des requêtes ambiguës.

Source et périmètre

Source principale : arXiv:2609.19482v1 · PDF. Les résultats numériques et les réserves ci-dessus reprennent le preprint ; la proposition de gouvernance est une interprétation éditoriale.