txtai : une base d'embeddings qui tient lieu de socle pour la recherche vectorielle et les workflows LLM

Le problème : recoller une pile de recherche et de RAG à la main

Monter une recherche sémantique sérieuse demande aujourd'hui d'assembler plusieurs briques : un modèle d'embeddings, un index vectoriel, une couche de métadonnées pour filtrer, un serveur HTTP, puis un orchestrateur pour brancher un LLM sur les résultats. Chaque brique a son format de configuration et son cycle de mise à jour. txtai prend le parti inverse : une seule bibliothèque Python expose ces couches sous une API commune, et le README la présente comme un cadre « all-in-one AI framework » couvrant la recherche sémantique, l'orchestration LLM et les workflows de modèles de langage. Le public visé est celui qui écrit du Python et veut indexer du texte, des documents, de l'audio, des images ou de la vidéo dans le même espace, puis interroger cet espace en langage naturel. Le README insiste sur un point qui distingue txtai de beaucoup d'alternatives : tout peut tourner en local, sans expédier les données vers des services distants. C'est un argument concret pour les corpus internes, pas un argument de principe.

La base d'embeddings : union d'index, de graphes et de tables

Le README décrit la base d'embeddings comme « a union of vector indexes (sparse and dense), graph networks and relational databases ». C'est la phrase qui explique le reste de l'architecture. Un index dense porte la similarité sémantique, un index creux couvre la correspondance lexicale, les réseaux de graphes relient les éléments entre eux, et la partie relationnelle stocke les métadonnées et les champs sur lesquels filtrer. Cette combinaison permet de traiter des requêtes que la seule similarité vectorielle gère mal : filtrer par date ou par source tout en classant par proximité sémantique. Le README mentionne aussi l'indexation multimodale, avec des embeddings pour le texte, les documents, l'audio, les images et la vidéo, ce qui suppose un modèle capable de projeter ces modalités dans un espace partagé. Les pipelines, construits sur des modèles de langage, couvrent les prompts, le question-answering, l'étiquetage, la transcription, la traduction et le résumé. Les workflows assemblent ces pipelines et y ajoutent de la logique métier, tandis que les agents connectent embeddings, pipelines, workflows et autres agents. Le README ne détaille pas le format de persistance des index ni la manière dont les composants se synchronisent en écriture : c'est une zone à vérifier dans la documentation si vous prévoyez des mises à jour fréquentes du corpus.

Mise en route : deux lignes en Python, un YAML pour l'API

Le README donne un exemple minimal en Python : on importe txtai, on instancie txtai.Embeddings(), on appelle index(["Correct", "Not what we hoped"]) puis search("positive", 1), et le résultat retourné est [(0, 0.29862046241760254)], soit un couple identifiant et score. Aucun modèle n'est nommé dans cet exemple, ce qui suggère que la classe utilise un modèle par défaut. Pour l'API HTTP, le README fournit un fichier app.yml contenant une seule clé, embeddings, avec une sous-clé path pointant vers sentence-transformers/all-MiniLM-L6-v2. Le lancement se fait avec CONFIG=app.yml uvicorn "txtai.api:app", et l'interrogation avec curl -X GET "http://localhost:8000/search?query=positive". Deux variables d'environnement portent donc la configuration : CONFIG pour le chemin du fichier, et le chemin du modèle pour le reste. Le README mentionne également une installation par pip ou par Docker, ainsi qu'un serveur MCP et des bindings pour JavaScript, Java, Rust et Go. Ce dernier point compte si votre équipe n'est pas exclusivement Python : l'API devient la frontière, et les clients sont maintenus séparément dans leurs propres dépôts.

Ce que la documentation ne tranche pas

Le README est généreux en promesses et avare en chiffres. Il annonce plus de 70 notebooks d'exemple, ce qui est un volume de documentation notable, mais il ne donne aucune indication sur la latence d'une recherche, sur le coût d'indexation d'un corpus volumineux, ni sur le comportement en mémoire quand on charge plusieurs pipelines simultanément. La mention « Low footprint - install additional dependencies and scale up when needed » indique une installation par défaut légère et des extras à ajouter, sans préciser lesquels correspondent à quels cas d'usage. Autre point laissé ouvert : le README parle de « scale out with container orchestration » sans décrire de mode distribué pour l'index lui-même. On peut donc raisonnablement supposer, mais la documentation fournie ne le confirme pas, que la montée en charge consiste à répliquer des instances de service plutôt qu'à répartir un index unique. Si votre besoin est un index de plusieurs centaines de millions de vecteurs avec écriture continue, ce n'est pas dans ce matériau que vous trouverez la réponse. C'est un manque, pas une faiblesse rédhibitoire : beaucoup de projets internes tiennent dans une seule instance.

Quand txtai n'est pas le bon outil

Trois situations plaident contre txtai. La première est l'existence d'un magasin vectoriel déjà en production, par exemple un cluster géré avec ses sauvegardes, sa surveillance et ses procédures d'exploitation. Remplacer cette brique par la base d'embeddings de txtai revient à reprendre une partie de l'exploitation, sans que le README fournisse d'éléments sur la réplication ou la reprise après incident. La deuxième est le besoin de connecteurs nombreux vers des services tiers : txtai est une bibliothèque Python centrée sur les modèles Hugging Face Transformers et Sentence Transformers, pas un catalogue d'intégrations. La troisième concerne le versionnement des modèles. Le README cite sentence-transformers/all-MiniLM-L6-v2 comme exemple de chemin, et rien n'indique un mécanisme de verrouillage de version côté txtai : le comportement du modèle dépend du dépôt Hugging Face, pas du paquet. Une mise à jour de modèle en amont peut donc décaler les scores de recherche sans qu'aucune ligne de votre code n'ait changé. Ce point mérite un test de non-régression sur vos propres requêtes.

Face à LangChain : bibliothèque intégrée contre boîte à composants

LangChain est l'alternative la plus souvent citée pour les applications LLM, et la différence d'approche est nette. LangChain fournit des abstractions interchangeables : vous choisissez un magasin vectoriel, un chargeur de documents, un modèle, puis vous les composez, et l'intégration avec l'écosystème se fait par des paquets de connecteurs. txtai part de l'inverse : une base d'embeddings est le composant central, et les pipelines, workflows et agents s'y rattachent. La conséquence pratique est double. Côté avantage, vous n'avez pas à écrire la glue entre index, filtres et recherche : la configuration tient dans un YAML comme celui montré plus haut. Côté contrainte, vous adoptez le modèle de données de txtai et ses choix de persistance, et vous dépendez de son rythme pour suivre les évolutions des modèles. Un projet qui change souvent de fournisseur de modèles ou de magasin vectoriel sera plus à l'aise avec une boîte à composants. Un projet qui veut un service de recherche sémantique stable, interrogeable en HTTP et enrichi de RAG, trouvera dans txtai moins de code à maintenir. Aucune des deux positions n'est universelle, et le README ne cherche pas à trancher.

Maintenance, versions et licence

Le dépôt n'est pas archivé et les versions récentes s'enchaînent à un rythme mensuel : v9.13.0 en août 2026, v9.12.0 en juillet 2026, v9.11.0 en juin 2026. Cette cadence signifie deux choses pour un projet qui adopte txtai. D'abord, les correctifs arrivent vite, ce qui réduit le risque de rester bloqué sur un bug. Ensuite, une version majeure peut modifier des comportements, et il faut prévoir de relire les notes de version avant de monter de version, d'autant que la bibliothèque s'appuie sur Transformers et Sentence Transformers, deux dépendances qui bougent également. Le coût d'installation dépend des extras choisis : le README parle d'une empreinte légère par défaut et de dépendances supplémentaires à ajouter selon les besoins, donc le poids réel dépend de votre usage. Côté licence, txtai est distribué sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et d'état des modifications. Attention toutefois : cette licence couvre le code de txtai, pas les modèles que vous téléchargez depuis Hugging Face ni les données que vous indexez. Ces éléments ont leurs propres conditions, qu'il faut vérifier séparément. Ce texte n'est pas un avis juridique.

Conclusion éditoriale

txtai convient aux équipes Python qui veulent une recherche sémantique et un socle RAG local, sans empiler une base vectorielle, un serveur d'API et un framework d'orchestration séparés. Il faut passer son chemin si le projet repose sur un magasin vectoriel déjà exploité en production, sur des connecteurs SaaS nombreux ou sur une exécution distribuée que la documentation ne décrit pas. Avant d'adopter, vérifier trois points dans le dépôt : la version de Python requise (3.10+), les dépendances optionnelles réellement nécessaires à votre cas, et le contenu de la licence Apache-2.0 pour les modèles que vous comptez télécharger, car ils ne relèvent pas de cette licence.

Sources officielles

1. License: Apache-2.0
2. neuml/txtai on GitHub
3. Project website
4. README
5. Releases