Infino, fondée par d’anciens membres expérimentés d’OpenSearch, a annoncé sa sortie de la phase furtive avec une plateforme de récupération destinée aux agents d’intelligence artificielle. L’idée centrale est de fournir à l’agent une interface unique pour interroger des données structurées et non structurées, au lieu de répartir la tâche entre un entrepôt de données, un moteur de recherche et une base de données vectorielle, puis de laisser l’agent fusionner les résultats au fil de plusieurs cycles.
L’entreprise affirme que les agents se distinguent des utilisateurs et des applications traditionnels par leur manière de lire. Au lieu d’envoyer une seule requête et d’attendre le résultat, l’agent pose de petites questions simultanées pour construire une réponse plus vaste, et chaque résultat qui lui est renvoyé consomme une partie du contexte du modèle et peut ajouter du temps et des coûts aux appels ultérieurs.
Que propose Infino ?
Infino intègre directement les fonctions de récupération dans SQL, ce qui permet de combiner dans une seule requête la recherche par mots-clés, la recherche sémantique, les filtres, le comptage, les jointures, l’agrégation et le tri. Selon son directeur général, Ekechi Nwokah, l’idée ne consiste pas à utiliser SQL en soi, mais à regrouper des modes de requête qui nécessitaient habituellement des systèmes distincts.
L’entreprise affirme que le développeur peut saisir une question en langage naturel et la convertir en une seule requête exécutée en quelques fractions de seconde. Infino a également ajouté des modèles de raisonnement destinés au moteur de récupération pour gérer les tâches répétitives au sein des boucles de recherche, comme la formulation de la requête, l’évaluation de la qualité des résultats, l’essai d’une requête alternative et la vérification de la réponse, au lieu de confier systématiquement ces étapes à des modèles avancés plus coûteux.
Une seule copie des données au format Parquet
L’architecture repose sur le stockage des données dans des fichiers Apache Parquet sur un stockage objet, avec l’intégration des index de recherche à côté du pied de page du fichier Parquet. Infino affirme que son moteur de base est open source et distribué sous licence Apache-2.0 sur GitHub, tandis que le service Infino Cloud permet d’utiliser les données Parquet existantes et de les rendre interrogeables sans construire soi-même l’infrastructure.
Les données restent lisibles avec les outils compatibles avec Parquet, notamment Iceberg, Hudi, Spark, DuckDB et d’autres entrepôts de données. Il est également possible d’ingérer des données Parquet ou JSON, puis de connecter l’agent à l’interface d’Infino, sans gérer de clusters, de nœuds ou de fragments distribués, selon la description de l’entreprise.
Pourquoi cette actualité est-elle importante ?
Si l’idée fonctionne dans des charges de production, la couche de récupération unifiée pourrait réduire le nombre de pipelines d’ingestion, de fonctions ETL, de schémas et de clients que l’agent doit appeler. Plus important encore du point de vue de la sécurité, l’existence d’une seule copie des données pourrait permettre d’appliquer les politiques d’accès de manière centralisée, notamment en déterminant les lignes et les colonnes visibles par l’agent ainsi que les éléments enregistrés, au lieu de répartir les autorisations entre les passerelles MCP et les connecteurs de services.
La plateforme cible les ingénieurs des plateformes et des données, les équipes de sécurité, les équipes de machine learning et de science des données, ainsi que les développeurs qui construisent des agents travaillant avec du code, des journaux, les sorties de l’intégration continue et les tickets. Infino affirme que son architecture est conçue pour être environ dix fois moins coûteuse que les architectures traditionnelles de recherche et d’analyse, tandis que sa comparaison publiée fait apparaître un coût environ 10,5 fois inférieur à celui d’Elasticsearch et 23 fois inférieur à celui d’OpenSearch dans la charge de travail testée.
Limites et questions ouvertes
Ces chiffres proviennent de l’entreprise et sont liés à une charge de test précise ; ils ne suffisent donc pas, à eux seuls, à démontrer une supériorité générale sur toutes les applications Elasticsearch ou OpenSearch. De même, la réduction du nombre de systèmes n’élimine pas la nécessité de vérifier la qualité de la récupération, les limites des politiques d’accès et le comportement des index lorsque les données évoluent ou augmentent. La valeur de cette approche reste liée à l’adéquation de Parquet et du stockage objet aux modèles de données et de requêtes propres à chaque équipe.