AutoRAG 2.0 : un agent bibliothécaire qui lit vos documents au lieu de vous rendre des chemins de fichiers

Deux projets sous un même nom, et c'est le premier piège

Le dépôt ne contient plus ce que son nom évoquait. Le README annonce que l'ancien AutoRAG, l'outil Python d'AutoML qui cherchait automatiquement un pipeline RAG optimal, vit maintenant dans le répertoire legacy/. Il reste maintenu, en mode maintenance, avec des correctifs, des mises à jour de dépendances et des publications PyPI via pip install AutoRAG. Les nouvelles fonctionnalités vont à AutoRAG 2.0. Si vous arrivez par une recherche sur l'optimisation de pipelines RAG, vous êtes au mauvais endroit du dépôt. Si vous arrivez parce que vous voulez interroger un ensemble de PDF, de wikis et de notes sans écrire de pipeline, lisez la suite. Cette scission est récente et les deux publics se croisent encore dans les mêmes issues, ce qui complique le tri des rapports de bug.

Le problème visé : le tri manuel après une recherche

La critique de départ est explicite dans le README : un outil de recherche classique renvoie une liste de chemins et de lignes correspondantes, puis laisse à l'utilisateur l'ouverture des fichiers, la lecture du contexte, le jugement de pertinence, la synthèse et la mémorisation de ce qui a fonctionné. AutoRAG 2.0 se présente comme un bibliothécaire qui exécute ces étapes. L'exemple du README montre une question sur les conclusions d'un rapport trimestriel et une réponse en unités numérotées, chacune accompagnée d'une plage de pages, sans chemin de fichier ni numéro de ligne. Le public visé est donc celui qui possède une collection documentaire locale hétérogène et qui veut une réponse curatée, pas un jeu de résultats à filtrer soi-même. Le README insiste sur l'absence de prérequis RAG : pas de réglage de pipeline, pas d'opérations sur une base vectorielle, pas de clé API.

Un agent Pi, un seul modèle, et une boucle complète

L'architecture tient en une phrase du README : AutoRAG est un agent Pi personnalisé, la boucle d'agent Pi configurée en bibliothécaire. Le modèle et le fournisseur viennent du runtime authentifié de l'utilisateur, et le projet ne fournit aucun fournisseur par défaut. Point important pour le dimensionnement : AutoRAG n'est pas un coordinateur qui distribuerait des rôles entre plusieurs modèles. Vous configurez un modèle, et ce modèle assume la récupération, la lecture, le jugement et la curation. Le flux décrit est le suivant : les outils de retrieval proposent des chemins candidats, l'agent ouvre ensuite les fichiers sources directement via son outil bash intégré, puis il fusionne les résultats après normalisation des scores et déduplication par ResultMerger, et renvoie un objet structuré SearchDocumentsResponse. Les résultats conservent leur source réelle, chemin de fichier ou identifiant de datasource, dans une table de correspondance interne utilisée pour le retour d'information. Un seul modèle qui fait tout simplifie le coût et la latence, mais concentre aussi tous les échecs au même endroit : si le modèle juge mal une preuve, aucune couche de coordination ne le rattrape.

Fédération en place plutôt qu'ingestion centralisée

Le premier principe affiché est de ne jamais migrer les données pour les chercher. AutoRAG fédère des stores possédés par des CLI (katok, discrawl, qmd, msgvault, rclone, et d'autres) sans ingestion forcée dans un index central et sans serveur tiers qui détiendrait une copie du corpus. Les résultats portent une identité native à la source, l'exemple donné étant kakao:<chat>/<sender>/<chunk>, avec un contrôle de portée sur l'accès. C'est un choix de conception qui a un coût : chaque source externe garde son propre cycle de vie d'archive et d'index, donc la qualité de recherche dépend de ce que chaque store expose. Le README renvoie sur ce point à une étude comparative dans docs/competitive-landscape-2026-09.md, que je n'ai pas lue et dont je ne peux donc rien dire de plus que son existence et son rôle affiché.

MinSync, BM25 et vectoriel : ce qui s'installe tout seul

Le retrieval local repose sur MinSync, qui gère un cycle de vie de chunks CDC partagé et expose le lexical BM25, le vectoriel sémantique et l'hybride à travers un RetrievalMethodRegistry. Les trois méthodes sont activées par défaut dès que MinSync est actif. On désactive l'indexation locale avec "minSync": false, ou seulement le lexical avec "bm25": false. Sur la première utilisation, MinSync installe automatiquement une version vérifiée dans <workspace>/.autorag/bin quand autoInstall vaut true ; passez "autoInstall": false uniquement si vous gérez le binaire vous-même. L'embedder local est EmbeddingGemma via Ollama, et la configuration se fait avec les options autorag init --embedder-* pour des points d'embedding distants. Si votre embedder local a une fenêtre de contexte réduite, réglez minSync.maxChunkSize ou l'option --minsync-max-chunk-size. Le README précise qu'AutoRAG n'impose jamais TEI ni un service d'embedding externe. Le détail des chemins de binaire et du flux de questions-réponses EmbeddingGemma se trouve dans docs/minsync-setup.md. À noter : MinSync indexe des miroirs markdown parsés sous .autorag, ce qui signifie qu'une copie dérivée de vos documents existe bien sur le disque, même si le corpus d'origine n'est pas migré.

Le retry d'extraction PDF et ses seuils

Le parseur PDF par défaut effectue un contrôle de qualité peu coûteux sur les PDF multi-pages. Si le markdown local est anormalement pauvre, soit moins de 800 caractères au total, soit moins de 40 caractères par page détectée, et cela sur au moins trois pages, l'extraction est retentée via le backend hybride docling-fast d'OpenDataLoader avec hybridMode: "auto" et un délai de 30 secondes. Les PDF denses ne sont pas retentés, et l'hybride n'est jamais utilisé pour un PDF d'une seule page ni comme premier chemin pour les images. Ces seuils sont modifiables par parserOptions, avec les clés thinExtract.minPages, minChars, minCharsPerPage, timeoutMs, hybrid et hybridMode. Cette porte est un compromis assumé : elle évite le coût d'un parseur lourd sur les documents qui se convertissent bien, au prix de cas limites. Un PDF de deux pages mal extrait ne déclenchera pas le retry, puisque minPages vaut 3 par défaut. Une image scannée seule ne passera pas non plus par l'hybride. Si votre corpus est majoritairement composé de scans courts, ce mécanisme ne vous aidera pas et il faudra regarder ailleurs.

Mémoire auto-évolutive : ce que le README promet et ce qu'il ne détaille pas

Le projet revendique un système de mémoire auto-évolutif : chaque recherche apprend quelque chose, quelles méthodes de retrieval fonctionnent pour quels types de requêtes, quelles zones documentaires sont productives, et ce que l'appelant a trouvé utile via un retour explicite. Le README résume la différence entre une instance fraîche et une instance rodée, mais ne décrit pas le format de stockage de cette mémoire, ni sa durée de vie, ni son comportement en cas de changement de modèle. La phrase d'accroche du dépôt, « It gets smarter if you are using it frequently », annonce une dépendance à l'usage réel. C'est un point à vérifier avant de bâtir un processus dessus : une mémoire apprise sur un corpus et un modèle donnés n'a aucune raison d'être transférable, et le README ne dit pas comment l'inspecter ni la réinitialiser. Sur ce sujet précis, la documentation est mince et je ne peux pas aller plus loin que ce qu'elle affirme.

Licence, maintenance et coût de mise à jour

Le dépôt déclare NOASSERTION comme licence. Concrètement, cela signifie qu'aucune licence standard n'a été reconnue automatiquement et qu'il faut ouvrir le fichier LICENSE du dépôt pour connaître les termes exacts avant tout usage en entreprise. Je ne peux pas vous dire ce qu'il contient, seulement que ce point doit être tranché avant adoption, surtout si vous redistribuez l'outil ou l'intégrez à un produit. Sur la maintenance, les faits disponibles sont limités : trois versions récentes, v2.4.1 le 5 septembre 2026, v2.4.0 la veille, et v2.3.0 le 24 août 2026, avec un dernier push au 9 septembre 2026. Le rythme est soutenu, ce qui a une contrepartie : des versions rapprochées sur un projet qui se présente comme une réécriture complète impliquent un risque de rupture d'API entre mineures. Le coût de mise à jour ne se limite pas au paquet : MinSync installe un binaire dans <workspace>/.autorag/bin, et ce binaire a son propre cycle de publication, distinct de celui d'AutoRAG. Deux composants à suivre, donc, plus le modèle et l'embedder que vous configurez vous-même.

Quand choisir autre chose

L'alternative la plus directe se trouve dans le même dépôt : l'ancien AutoRAG en Python, sous legacy/. La différence d'approche est nette. Le legacy cherche automatiquement un pipeline RAG optimal pour vos données, avec les topics associés au dépôt (automl, benchmarking, llm-evaluation), donc un cadre d'expérimentation et d'évaluation de configurations. AutoRAG 2.0 ne cherche pas de pipeline : il exécute une boucle de recherche et de curation avec un modèle unique et des méthodes activées par défaut. Si votre besoin est de comparer des stratégies de chunking, des modèles d'embedding ou des réordonnanceurs sur un jeu de test annoté, le legacy correspond à cette question et 2.0 n'y répond pas. Inversement, si vous voulez poser une question à votre arborescence de notes et obtenir une réponse sourcée sans écrire de configuration, 2.0 vise ce cas et le legacy ne le fait pas. Le choix se fait donc sur la nature de votre problème, pas sur l'ancienneté des deux outils.

Conclusion éditoriale

Adoptez AutoRAG 2.0 si votre corpus vit déjà dans des sources locales ou des stores CLI que vous ne voulez pas dupliquer, et si vous acceptez qu'un seul modèle pilote toute la boucle. Passez votre chemin si vous cherchez un cadre d'évaluation de pipelines RAG, un service multi-utilisateurs, ou si vous avez besoin d'une licence explicite avant déploiement. Avant toute intégration, vérifiez deux points dans le dépôt : le contenu réel du fichier LICENSE, et le fichier docs/minsync-setup.md qui décrit l'installation du binaire MinSync dans <workspace>/.autorag/bin.

Sources officielles

1. Issues
2. Marker-Inc-Korea/AutoRAG on GitHub
3. Project website
4. README
5. Releases