Points clés
- Licence Apache 2.0, gratuite et open source, aucun palier payant séparé pour la bibliothèque elle-même
- Embarqué par défaut — index vectoriel Faiss plus stockage de métadonnées SQLite, tous deux enregistrés en fichiers locaux
- Un seul paquet couvre recherche vectorielle, RAG, agents et workflows multi-modèles — pas seulement le stockage vectoriel
- Construit sur Hugging Face Transformers, Sentence Transformers et FastAPI ; nécessite Python 3.10+
- Prend en charge les LLM locaux (Hugging Face, llama.cpp, Ollama, vLLM) et les modèles par API (OpenAI, Claude, AWS Bedrock via LiteLLM)
- Maintenu par NeuML (créateur David Mezzetti) — pas encore de produit cloud propre ; une offre hébergée txtai.cloud est encore en développement
📍 En une phrase
txtai est une bibliothèque Python gratuite et open source (Apache 2.0) qui réunit base vectorielle, recherche sémantique, pipelines RAG et orchestration LLM dans un seul paquet embarqué, sans serveur séparé.
💬 En termes simples
Plutôt que de faire tourner Chroma ou Qdrant comme service en arrière-plan et d'y ajouter un framework séparé, on installe txtai via pip et on obtient le stockage vectoriel, la recherche et la logique RAG directement dans son propre programme Python — comme SQLite qui vit dans une application au lieu de tourner comme son propre serveur de base de données.
📌Remarque: txtai échange la scalabilité horizontale d'un service de base vectorielle dédié contre une charge de déploiement nulle. Ce compromis convient aux applications mono-nœud et aux prototypes — pas aux jeux de données à répartir sur plusieurs machines.
Qu'est-ce que txtai ?
txtai est un framework Python open source (licence Apache 2.0, github.com/neuml/txtai) pour la recherche sémantique, l'orchestration de LLM et les workflows de modèles de langage, développé et maintenu par NeuML. Son composant central est une base d'embeddings — décrite par sa propre documentation comme une union d'index vectoriels (denses et épars), de réseaux de graphes et de bases de données relationnelles en un seul objet.
- Recherche vectorielle : embeddings denses et épars, filtrage SQL, modélisation de sujets, analyse de graphes et indexation multimodale (texte, documents, audio, images, vidéo) dans un seul index
- Pipelines : wrappers prêts à l'emploi autour de modèles de langage pour la question-réponse, le résumé, la traduction, la transcription et l'étiquetage de texte
- Workflows : enchaîner plusieurs pipelines en un seul job de traitement, d'un script simple en deux étapes à un traitement par lots multi-modèles
- Agents : agents autonomes combinant embeddings, pipelines et workflows pour résoudre des tâches en plusieurs étapes, construits sur le framework smolagents
- API et bindings : un service REST/FastAPI plus un serveur Model Context Protocol (MCP), avec des bindings clients pour JavaScript, Java, Rust et Go
- Plus de 70 notebooks d'exemple couvrant le framework de bout en bout, maintenus aux côtés de la bibliothèque principale
Comment fonctionne l'architecture embarquée de txtai ?
**L'objet Embeddings de txtai conserve l'index vectoriel et le stockage des métadonnées directement dans le processus Python, en persistant les deux dans des fichiers locaux plutôt que de dialoguer avec un service de base de données séparé.** Par défaut, l'index vectoriel utilise Faiss et les métadonnées de contenu sont stockées dans un fichier SQLite local — le même modèle « embarqué dans le processus applicatif » que SQLite lui-même, à l'inverse du modèle client/serveur de PostgreSQL.
- Backend ANN (configuration
backend) : Faiss par défaut ; HNSW, Annoy et pgvector sont pris en charge comme alternatives interchangeables sans modifier le reste du code - Stockage de contenu (configuration
content) : SQLite par défaut si activé ; prend en charge DuckDB ou une base de données client/serveur via une URL de connexion pour les équipes qui dépassent un simple fichier - Stockage d'objets : stockage binaire optionnel pour des images ou des objets picklés arbitraires, superposé au même index d'embeddings
- Persistance :
embeddings.save(path)écrit l'index et la base sur disque sous forme de répertoire portable ;embeddings.load(path)le rouvre dans un nouveau processus sans étape d'import/export - Aucun processus serveur à démarrer, surveiller ou corriger — l'index vit et meurt avec le processus applicatif, exactement comme un cache en mémoire ou basé sur fichier
En quoi txtai diffère-t-il d'une base vectorielle autonome ?
Chroma, Qdrant, Weaviate et Milvus s'exécutent normalement comme leur propre service — un conteneur ou un point de terminaison géré auquel l'application se connecte via le réseau. txtai s'exécute au contraire dans le processus appelant, à l'image de la différence entre SQLite et PostgreSQL : pas de chaîne de connexion, pas de processus séparé à maintenir en vie, pas de saut réseau entre le code et l'index.
📌Remarque: Chroma propose aussi un mode embarqué pour le prototypage, mais sa voie de production passe par un serveur. txtai n'a pas de mode de production séparé vers lequel évoluer — l'architecture embarquée est la seule qu'il propose.
txtai prend-il en charge le RAG et les agents IA ?
Oui — la génération augmentée par récupération (RAG) et les agents autonomes sont des cas d'usage centraux de txtai, pas des extensions ajoutées à une base vectorielle.
- RAG : le pipeline
RAGassocie un indexEmbeddingsà un LLM, récupère les passages pertinents pour une requête et génère une réponse citant ses sources — la documentation de txtai décrit le RAG comme « plus qu'une simple recherche vectorielle », avec récupération de contexte depuis le web et SQL - Agents : construits sur le framework smolagents de Hugging Face, les agents txtai relient embeddings, pipelines, workflows et autres agents pour traiter des tâches en plusieurs étapes de façon autonome ; le prompting d'agents via les fichiers
agents.mdetskill.mdest pris en charge - Workflows : les pipelines s'enchaînent en jobs linéaires ou ramifiés — par exemple extraire un texte, le découper, l'embarquer, puis résumer chaque section — sans coder à la main la logique de liaison
- Graphes de connaissances : l'extraction d'entités pilotée par LLM peut construire un graphe sémantique au-dessus d'un index d'embeddings, ajoutant une analyse de relations à la simple recherche par similarité
Quels LLM peut-on utiliser avec txtai ?
**txtai prend en charge les modèles locaux et les modèles par API via les mêmes interfaces de pipeline LLM et RAG — passer de l'un à l'autre est un changement de configuration, pas une réécriture de code.**
Voie | Type | Remarque |
|---|---|---|
| Hugging Face Transformers | Local | Tout LLM causal du Hugging Face Hub ou un chemin local |
| llama.cpp | Local | Modèles quantifiés au format GGUF, CPU ou GPU |
| Ollama | Local | Pointe vers un serveur Ollama en cours d'exécution |
| vLLM | Local / auto-hébergé | Serveur d'inférence haut débit pour la production |
| LiteLLM | API | Route vers OpenAI, Anthropic Claude, AWS Bedrock, etc. |
L'exemple de démarrage rapide RAG de txtai charge un modèle Hugging Face par son chemin (par exemple Qwen/Qwen3-0.6B) directement dans le pipeline RAG aux côtés de l'index d'embeddings — aucun serveur LLM séparé n'est requis, sauf choix délibéré pour des raisons de débit.
Comment installer txtai ?
Obtenir un index de recherche sémantique fonctionnel prend un pip install et quelques lignes de Python — aucun conteneur à configurer au préalable.
- 1Installer Python 3.10 ou une version ultérieure, puis le paquet :
pip install txtai. Utiliser `pip install "txtai[pipeline-data]"` si l'extraction de documents (PDF, DOCX, HTML) est aussi nécessaire pour le RAG. - 2Créer un index d'embeddings dans un script Python :
import txtaipuisembeddings = txtai.Embeddings(). - 3Indexer une liste de documents : `embeddings.index(["Correct", "Not what we hoped"])
. Chaque appel ajoute du texte (ou des tuples(id, text)` pour de plus grands jeux de données) à l'index sur disque. - 4Effectuer une recherche sémantique :
embeddings.search("positive", 1)renvoie les résultats les plus proches par sens, pas par simple présence de mots-clés. - 5Persister l'index pour le réutiliser :
embeddings.save("index_path")l'écrit sur disque ; le rouvrir ensuite avecembeddings.load("index_path")— aucune réindexation nécessaire entre deux exécutions. - 6Pour une API web plutôt qu'un script embarqué : définir un
app.ymlminimal avec un modèleembeddings.path, puis le servir :CONFIG=app.yml uvicorn "txtai.api:app"et l'interroger en HTTP aveccurl.
import txtai
# Créer un index d'embeddings (Faiss + stockage local par défaut)
embeddings = txtai.Embeddings()
# Indexer du texte — chaque chaîne devient une entrée interrogeable
embeddings.index(["Correct", "Not what we hoped"])
# Recherche sémantique — trouve le sens, pas seulement les mots-clés
results = embeddings.search("positive", 1)
print(results) # [(0, 0.298...)] — l'index 0 ("Correct") est le plus proche
# Persister sur disque pour réutilisation après redémarrage du processus
embeddings.save("index_path")L'exemple minimal de txtai nécessite-t-il un GPU ?
Non. Le modèle d'embeddings par défaut (sentence-transformers/all-MiniLM-L6-v2) et le backend ANN Faiss tournent tous deux sur CPU. Un GPU accélère la génération d'embeddings et l'inférence LLM à plus grande échelle, mais n'est pas requis pour suivre cette installation.
Comment ajouter la génération augmentée par récupération à cette installation ?
Passer le même objet Embeddings à un pipeline txtai.RAG avec un LLM local ou par API : rag = txtai.RAG(embeddings, "model-name"), puis appeler rag("votre question"). Le pipeline gère la récupération et la construction du prompt.
Pour qui txtai est-il fait ?
Utiliser txtai pour une seule dépendance Python couvrant recherche, RAG et agents sans infrastructure à exploiter — l'éviter s'il faut un stockage vectoriel scalable horizontalement pour de nombreuses applications indépendantes.
📌Remarque: Verdict : choisir txtai quand la contrainte est « une application Python, une machine, un minimum d'exploitation ». Choisir une base vectorielle autonome (Qdrant, Weaviate, Milvus) quand la contrainte est « plusieurs services doivent interroger le même index, à grande échelle, dès le premier jour ».
txtai face à Chroma, Qdrant et LlamaIndex
Ces quatre outils résolvent des problèmes qui se recoupent mais restent distincts : txtai et Chroma embarquent tous deux un stockage vectoriel, Qdrant est un service de base de données dédié, et LlamaIndex est un framework d'orchestration sans stockage propre.
Outil | Architecture | Déploiement | Licence | Idéal pour |
|---|---|---|---|---|
| txtai | Base vectorielle embarquée + RAG/agents | In-process, sans serveur | Apache 2.0 | RAG et agents Python en un paquet |
| Chroma | Base vectorielle | Mode embarqué ou serveur | Apache 2.0 | Stockage vectoriel de prototypage simple |
| Qdrant | Base vectorielle | Serveur (Docker/cloud) | Apache 2.0 | Recherche multi-clients en production |
| LlamaIndex | Framework RAG/orchestration | Nécessite un stockage externe | MIT | Connecteurs de données sur toute base vectorielle |
Erreurs fréquentes en évaluant txtai
Ces erreurs viennent d'appliquer des hypothèses conçues pour les bases vectorielles serveur à une bibliothèque au modèle de déploiement fondamentalement différent.
Questions fréquentes
txtai est-il gratuit ?
Oui. txtai est open source sous licence Apache 2.0, sans plafond d'usage ni frais de licence pour la bibliothèque elle-même. NeuML, l'entreprise qui la maintient, vend du conseil en IA payant et développe séparément un produit hébergé appelé txtai.cloud, encore en développement au moment de la rédaction.
txtai nécessite-t-il un serveur de base de données séparé ?
Non. txtai embarque son index vectoriel et son stockage de métadonnées directement dans le processus Python — par défaut un index ANN Faiss plus un fichier SQLite, tous deux persistés en fichiers locaux, sans processus serveur à déployer ou surveiller.
Quels backends ANN txtai prend-il en charge en dehors de Faiss ?
Faiss est le backend par défaut. txtai prend aussi en charge HNSW, Annoy et pgvector (ainsi que d'autres backends via son paquet supplémentaire ann), configurables via le paramètre backend sans modifier le code applicatif.
En quoi txtai diffère-t-il de Chroma ?
Les deux embarquent un stockage vectoriel, mais la voie de production habituelle de Chroma passe par un serveur, alors que txtai n'a pas de mode serveur séparé vers lequel évoluer — txtai regroupe aussi pipelines RAG, agents et workflows multi-modèles dans le même paquet, ce que Chroma ne fait pas.
En quoi txtai diffère-t-il de Qdrant ?
Qdrant est un service de base vectorielle dédié conçu pour tourner comme son propre processus (via Docker ou un point de terminaison cloud géré) et être interrogé par de nombreux clients à la fois. txtai s'exécute embarqué dans un unique processus applicatif, échangeant cette concurrence et cette scalabilité horizontale contre une charge de déploiement nulle.
txtai prend-il en charge la génération augmentée par récupération (RAG) ?
Oui. Le pipeline RAG combine un index Embeddings avec un LLM local ou par API, récupère les passages pertinents pour une requête et génère une réponse citée — la documentation de txtai présente le RAG comme allant au-delà de la simple recherche vectorielle, avec récupération de contexte web et SQL.
txtai peut-il utiliser des LLM locaux au lieu d'une API cloud ?
Oui. txtai charge des modèles via Hugging Face Transformers, llama.cpp (format GGUF), Ollama ou vLLM pour une inférence entièrement locale, ou route vers OpenAI, Anthropic Claude ou AWS Bedrock via LiteLLM quand un modèle par API est préféré — la même interface de pipeline LLM/RAG couvre les deux cas.
txtai prend-il en charge les agents IA ?
Oui, construits sur le framework smolagents de Hugging Face. Les agents txtai relient embeddings, pipelines et workflows pour traiter des tâches en plusieurs étapes de façon autonome, et prennent en charge les conventions de prompting d'agents comme agents.md et skill.md.
Sous quelle licence txtai est-il publié ?
Apache License 2.0, qui autorise l'usage commercial, la modification et la redistribution sans redevance — la même licence permissive utilisée par Chroma et Qdrant.
Qui maintient txtai ?
txtai est développé et maintenu par NeuML, une entreprise fondée par David Mezzetti. NeuML propose du conseil en IA payant autour du stack txtai en plus de maintenir la bibliothèque open source.
txtai peut-il gérer de grands jeux de données ne tenant pas sur une seule machine ?
Pas dans son mode embarqué par défaut. Un index Faiss/SQLite à fichier unique est limité à la machine qui le contient. Les jeux de données devant être répartis sur plusieurs nœuds, ou nécessitant que de nombreux services indépendants interrogent un index partagé simultanément, conviennent mieux à une base vectorielle dédiée et scalable horizontalement.
txtai est-il un bon choix pour un premier prototype RAG ?
Oui, spécifiquement pour un développeur Python — l'ensemble du stack (index, pipeline RAG et éventuellement un LLM) s'installe avec un seul pip install txtai et s'exécute dans un script unique, sans conteneur de base de données à monter avant la première ligne de logique applicative.
