QuantMind : un dépôt que l'on ouvre au lieu de l'importer

Le problème : de la donnée brute à un artefact citable

Un chercheur quantitatif qui interroge un LLM sur un article arXiv récupère le plus souvent un résumé sans traçabilité. Impossible de savoir quelle page a produit telle affirmation, ni à quelle date cette affirmation était vraie. QuantMind attaque ce point précis. Le README annonce un processeur d'information qui raffine des articles, des actualités et des dépôts réglementaires en connaissances structurées, où chaque élément conserve sa citation et son horodatage. Le public visé n'est pas l'utilisateur final d'un chatbot : ce sont les personnes qui construisent les flux de raffinement, et, de plus en plus, les agents de codage qui travaillent sous leur supervision. Le dépôt est donc organisé autour de contrats lisibles par une machine, pas autour d'une documentation destinée à un humain pressé.

Deux familles de formes typées

Le README distingue deux sorties. D'un côté un arbre de structure pour le document entier, présenté comme une hiérarchie de nœuds cités par page. De l'autre des fiches plates pour News, Earnings, Factor et Thesis. Chaque artefact porte son propre texte, un horodatage as_of et une référence de source légère, ce qui lui permet d'être persisté et interrogé dans le temps sans dépendre du document d'origine. Le choix du type se fait par la configuration : PaperStructureCfg produit un PaperStructureTree, PaperSemanticCfg produit un PaperSemanticResult. C'est une décision de conception discutable. Une fiche plate se compare et s'agrège facilement, un arbre de pages se cite précisément mais se prête mal au tri par date. Le projet ne tranche pas, il expose les deux et laisse le flux décider.

Le préprocess déterministe avant le modèle

Le point le plus intéressant du dépôt tient dans l'ordre des opérations. Le préprocess, décrit comme fetch, parse, format et clean, s'exécute sans modèle dans la boucle. La conséquence est directe : les valeurs produites restent fidèles à la source et l'exécution est rejouable. Beaucoup de pipelines RAG font l'inverse, ils nettoient et résument avec un LLM dès l'ingestion, puis découvrent trop tard qu'ils ne peuvent plus reproduire un résultat. QuantMind place la provenance avant la sémantique. Le coût est réel : un nettoyage déterministe rate ce qu'un modèle rattraperait, notamment sur des PDF mal structurés ou des tableaux de résultats financiers. Le README ne décrit pas de mécanisme de repli pour ces cas.

PaperFlow, collect_news et batch_run

L'API exposée est petite. PaperFlow(cfg).build(input) lie une configuration immuable une fois, puis l'applique à chaque entrée. collect_news collecte une fenêtre de sources rejouable. batch_run applique n'importe quelle opération à une liste d'entrées, ce qui évite d'écrire soi-même la plomberie asyncio.gather. L'exemple du README construit un arbre de structure pour l'identifiant arXiv 1706.03762v7 avec PaperStructureCfg(model="gpt-5.6-luna"), puis affiche l'identifiant et le nombre de nœuds. Le modèle est donc un paramètre de configuration, pas une dépendance codée en dur. À noter : le README indique que la surface réellement livrée se limite aujourd'hui à PaperFlow et collect_news, le reste étant renvoyé à la feuille de route.

Trois couches de récupération

Sous les flux, le dépôt organise la récupération en trois répertoires. rag/ couvre le découpage en chunks et la recherche BM25 ou par similarité. library/ assure la persistance locale et une recherche par le sens. mind/ propose une récupération agentique fondée sur le raisonnement. Ces trois couches ne répondent pas à la même question. BM25 excelle sur un ticker ou un identifiant exact, la recherche sémantique sur une formulation vague, la récupération agentique sur une question qui demande plusieurs sauts entre documents. Le README mentionne RAG, Agentic RAG, la recherche approfondie et un service data-MCP, mais ne détaille ni les formats de stockage de library/ ni la manière dont mind/ enchaîne ses étapes. C'est la zone la plus floue de la documentation fournie.

Le harnais comme produit

La partie qui distingue vraiment QuantMind de ses voisins est le harnais. Le dépôt contient des contrats AGENTS.md et CLAUDE.md, des pages contexts/ en divulgation progressive avec un aperçu Quick Summary, une compétence portable quantmind-dev déclinée pour Claude et Codex, des hooks partagés entre les deux agents, et un script scripts/verify.sh qui enchaîne lint, types, frontières d'import et tests, en échouant vite dans un ordre fixe. La CI exécute ce même script. Le pari est énoncé sans détour dans le README : un modèle faible dans un bon harnais bat un modèle fort lancé à nu. C'est une affirmation à prendre comme une position, pas comme un résultat. Le mécanisme, lui, est vérifiable dans l'arborescence : une règle écrite une fois, appliquée aux deux agents.

Mise en route et coût de maintenance

Deux chemins. Le chemin agent, recommandé : git clone https://github.com/LLMQuant/quant-mind.git, puis cd quant-mind && claude, ou codex. On décrit ensuite le pipeline souhaité en langage naturel, l'agent lit AGENTS.md, charge les pages contexts/ utiles, écrit le code et lance scripts/verify.sh avant de rendre la main. Le chemin bibliothèque suppose uv : uv venv, source .venv/bin/activate, uv pip install -e . Le paquet déclare Python 3.8 et plus. Sur la maintenance, le dépôt a été poussé pour la dernière fois le 15 août 2026 et aucune release n'apparaît dans les données récupérées. Sans version publiée, un utilisateur qui épingle un commit hérite du coût de suivi du master, et les pages contexts/ peuvent évoluer indépendamment du code qu'elles décrivent. La licence MIT est permissive, ce qui autorise l'usage commercial et la redistribution ; elle ne règle évidemment pas la question des droits sur les PDF et dépôts que vous ingérez, qui dépend de vos sources, pas du dépôt.

Face à un pipeline RAG classique

L'alternative la plus proche n'est pas un autre framework mais l'assemblage maison : un parseur de PDF, un découpage en chunks, un index vectoriel et quelques appels de modèle. Cette approche donne un contrôle total et ne dépend d'aucun contrat de dépôt. QuantMind prend le chemin inverse : il impose des formes typées, un horodatage as_of par artefact, une provenance conservée dès le préprocess et une vérification déterministe avant tout rendu. La différence se paie en flexibilité. Un pipeline maison acceptera un format de source exotique en une heure ; avec QuantMind il faut passer par le contrat de configuration et le type de sortie correspondant. En échange, vous obtenez des artefacts qui se comparent entre eux et se citent sans reconstituer la chaîne. C'est le bon compromis si vos sources sont des articles et des actualités publiques. C'est le mauvais outil si vos données sont propriétaires et que vous ne voulez pas les faire transiter par un flux orienté agent.

Conclusion éditoriale

Adoptez QuantMind si vous avez besoin d'artefacts financiers typés, horodatés et citables, et si vous acceptez de faire travailler un agent de codage dans un checkout plutôt que d'appeler une bibliothèque. Passez votre chemin si vos données ne sont pas publiques ou si vous cherchez une API stable : aucune release n'est publiée, la surface livrée se limite à PaperFlow et collect_news, et le reste est décrit comme cible. Avant tout engagement, clonez le dépôt, lancez uv venv puis uv pip install -e ., et exécutez scripts/verify.sh sur le commit que vous comptez figer.

Sources officielles

1. Issues
2. License: MIT
3. LLMQuant/quant-mind on GitHub
4. Project website
5. README