Chroma Context-1 : Un sous-agent de recherche de 20 milliards de paramètres pour un RAG agent plus économique et plus précis

Dans la plupart des systèmes RAG, l’étape de récupération des informations est le maillon faible. On peut y ajouter GPT-4, Claude, Gemini ou n’importe quel autre modèle avancé, mais si l’étape de recherche fournit des données de mauvaise qualité, le modèle produira malgré tout des réponses convaincantes, bien formulées, mais fausses.

Imaginons une recherche dans un document juridique où la réponse à une question se trouve répartie sur trois dossiers, et où l’agent doit les localiser tous. La configuration habituelle consiste à utiliser un modèle avancé dans un cycle ReAct accompagné d’outils de recherche vectorielle. Cela fonctionne, mais avec un coût d’environ 0,12 dollar et quinze secondes par requête, il s’agit seulement d’une démonstration et non d’une fonctionnalité réelle du produit. Context-1 de Chroma vise précisément ce problème de coût et de latence.

Qu’est-ce que Context-1 ?

Context-1 est un modèle de langage doté de 20 milliards de paramètres, conçu pour une seule tâche : la récupération d’informations. Il ne génère pas de réponses finales ni ne procède à de raisonnements généraux. Il se contente de rechercher.

Dans une configuration typique de RAG agent, un seul modèle principal fait tout : il planifie ce à rechercher, effectue la recherche, décide s’il a besoin de plus d’informations et rédige la réponse. C’est un peu comme embaucher un chirurgien cérébral pour faire aussi les courses. Context-1, quant à lui, agit comme un sous-agent de recherche dédié qui trouve les documents, tandis qu’un modèle principal distinct s’occupe du raisonnement et de la rédaction. Il s’agit d’une séparation des responsabilités appliquée à l’architecture des IA.

Le modèle est basé sur gpt-oss-20B, un modèle de base ouvert, et a été entraîné par un affinage supervisé suivi d’un apprentissage par renforcement utilisant la méthode CISPO de Chroma (Clipped Importance-Sampled Policy Optimization). Le résultat est un modèle de petite taille qui performe bien au-delà de ce à quoi on pourrait s’attendre en fonction de ses dimensions sur les benchmarks de récupération d’informations.

Pourquoi les systèmes RAG agents ordinaires sont insuffisants

Un pipeline classique effectue un seul passage : la question est intégrée, les fragments les plus pertinents (top-K) sont retournés et un LLM rédige la réponse.

User Query → Embedding Search → Top-K Chunks → LLM → Response

Cela présente des problèmes bien connus. On reçoit des fragments et jamais des documents complets, ce qui fait perdre le contexte global. Une seule passe ne peut pas relier des faits répartis sur plusieurs documents. De plus, la similarité sémantique n’est pas identique à la pertinence, car un fragment peut partager un vocabulaire avec la question sans pour autant y répondre.

La mise à niveau agente intégre cela dans un cycle ReAct, où le modèle planifie, effectue des recherches, examine les résultats et décide s’il doit rechercher à nouveau.

User Query → Plan → Search → Observe → Need more info? → Search again → Generate

Mieux, mais il y a un piège. Le même grand modèle de frontière effectue chaque étape : la planification, l’appel des outils, l’évaluation des résultats et le retrait des parties irrelevantes, tout cela au prix des modèles de frontière. Les modèles plus petits ne peuvent pas concurrencer, car seuls le prompt du système et les définitions des outils les déconcertent déjà, et ils ne suivent pas de manière fiable le cycle de travail. Vous finissez donc par payer des tarifs élevés pour un travail qui n’a pas besoin d’une intelligence de haut niveau.

Comment ça marche

Chroma n’a pas simplement affiné un modèle. Il a créé un cadre d’agent et y a entraîné le modèle, de sorte que le modèle et ses outils sont fournis ensemble. Quatre outils font partie de cet entraînement :

• search_corpus effectue une recherche hybride, combinant la correspondance par mots-clés BM25 avec une recherche vectorielle dense grâce à la fusion des rangs réciproques, vous permettant ainsi d’obtenir à la fois des résultats exacts et une compréhension sémantique.
• grep_corpus effectue une recherche régulière dans le corpus et retourne jusqu’à cinq extraits correspondants, utile pour une date, un nom ou un numéro de dossier spécifique.
• read_document récupère un document complet en fonction de son ID lorsque un extrait semble prometteur.
• prune_chunks permet au modèle de supprimer des extraits de son propre contexte s’il juge qu’ils sont irrelevants. C’est la fonction la plus remarquable.

Un suivi montre le schéma de fonctionnement. Au premier tour, le modèle cherche des termes tels que « pénalités de fusion et d’acquisition », et huit extraits sont retournés, tandis que le compteur de tokens indique 8 432 sur 32 768. Au deuxième tour, il lit un document dans son intégralité, effectue à nouveau une recherche, puis supprime ce qui n’a pas été utile, libérant ainsi de l’espace pour continuer la recherche.

Turn 1: search_corpus("merger acquisition penalties 2024")
  → Retrieves 8 chunks [Token usage: 8,432/32,768]
Turn 2: read_document("doc_14") + search_corpus("SEC filing penalties")
  → Retrieves 4 more chunks [Token usage: 18,203/32,768]
Turn 3: prune_chunks(["chunk_3", "chunk_7", "chunk_9", "chunk_11"])
  → Removes 4 irrelevant chunks [Token usage: 14,203/32,768]
Turn 4: search_corpus("specific penalty amounts regulatory action")
  → Retrieves 3 final chunks [Token usage: 21,847/32,768]
→ Returns ranked supporting documents to the reasoning model

Le contexte auto-éditable

Dans la plupart des pipelines, on a l’habitude de récupérer un lot de fragments, de les intégrer tous dans la requête et de faire confiance au modèle pour ignorer ceux qui ne sont pas importants. Des recherches montrent que les modèles ne se contentent pas d’ignorer le bruit : ils en sont même perturbés, phénomène appelé dégradation du contexte. Context-1 s’y attaque directement. Sa fenêtre de contexte est de 32 000 tokens, et l’outil de gestion surveille l’utilisation en temps réel :

1. Après chaque appel à une fonction, le modèle voit son utilisation actuelle, sous une forme telle que [Utilisation des tokens : 14 203/32 768].
2. Lorsque l’utilisation atteint environ 24 000 tokens, l’outil de gestion suggère de supprimer des éléments ou de terminer le traitement.
3. Lorsque l’utilisation dépasse une limite fixe, le modèle ne peut plus que supprimer des éléments ou terminer, sans pouvoir récupérer de nouveaux éléments, ce qui empêche une croissance incontrôlée du contexte.

La décision de suppression relève du modèle lui-même. Aucun réordonneur ou heuristique distinct n’est impliqué, et c’est celui qui a récupéré les fragments qui les évalue.

La précision de suppression atteint 0,941, contre 0,824 dans le modèle de base, ce qui signifie qu’il identifie les fragments irrelevants dans environ 94 % des cas. Cela dépasse les performances de Provence de Naver Labs, qui utilisait un modèle dédié pour supprimer des phrases. Ici, l’agent de recherche effectue les suppressions dans le cadre de son flux de travail normal, sans modèle supplémentaire.

Trois niveaux

Chroma insiste, et c’est un conseil judicieux, sur le fait que Context-1 doit être utilisé uniquement pour la récupération des données, et non pour la génération. L’architecture comporte trois niveaux : la couche de données, le sous-agent de recherche Context-1, et un modèle de raisonnement en haut de la hiérarchie. Cette séparation présente quatre avantages :

• Chaque composant peut être amélioré indépendamment, ce qui vous permet de remplacer le moteur de récupération par un meilleur demain sans toucher à la génération.
• Le modèle coûteux ne prend en compte que des contextes propres et sélectionnés avec soin, et non des résultats de recherche bruts.
• Context-1 génère de 400 à 500 tokens par seconde sur une Nvidia B200, ce qui est rapide pour des recherches à plusieurs étapes.
• Le moteur de raisonnement reçoit des données ciblées et produit de meilleures réponses.

C’est encore le principe des microservices : ne demandez pas à un seul modèle de faire tout le travail.

Comment il a été entraîné

Ajustement fin supervisé. Le modèle de référence était Kimi K2.5, un grand modèle de pointe. L’équipe a généré des trajectoires de recherche à l’aide de cet outil au sein du cadre à quatre outils, les a filtrées en fonction du taux de rappel et a entraîné Context-1 à imiter à la fois les recherches réussies et celles qui ont échoué. Les recherches infructueuses ont été conservées intentionnellement, car même celles ayant un faible taux de rappel contiennent des appels d’outils bien structurés, ainsi que des choix de décomposition et de suppression des requêtes. L’apprenti apprend ainsi les mécanismes de recherche à partir des recherches qui n’ont pas abouti.

Apprentissage par renforcement avec CISPO. Chaque étape d’entraînement utilisait 128 requêtes, chacune comportant 8 itérations, ce qui donne 1 024 trajectoires sur 5 époches, convergeant vers l’étape 230. Chaque token contribue à l’apprentissage, y compris ceux qui sont rares mais essentiels, tels que les décisions de suppression. La récompense combine plusieurs termes :

Reward = F1_score (recall-weighted)
       + trajectory_recall_bonus
       + final_answer_bonus (+1.0)
       - repeated_pruning_penalty (0.1 per excess)
       - turn_count_penalty

La formation suivait également un programme en deux étapes. Au début, elle utilisait des tâches simples à un seul saut, où le taux de rappel était pondéré 16 fois par rapport à la précision, ce qui favorise une exploration agressive. Par la suite, elle est passée à des tâches plus difficiles à plusieurs sauts, avec un poids de 4 fois, ce qui favorise la sélectivité. Cela ressemble à l’entraînement d’un chien de recherche : d’abord trouver n’importe quelle odeur, puis en identifier une en particulier.

Le pipeline de données

L’un des éléments les plus utiles mis à disposition par Chroma est peut-être son pipeline de génération de données synthétiques, open source sur GitHub, qui sert de modèle pour créer des données d’entraînement à la récupération dans n’importe quel domaine. Il suit un schéma d’exploration, de vérification et d’extension :

Seed Topic → Explore Web → Extract Verifiable Facts → Generate Tasks
     ↓
Add Distractors → Chain Into Multi-Hop → Verify Answers

1. Exploration. À partir d’un sujet de départ, tel qu’un titre aléatoire de Wikipédia, un agent parcourt le web et collecte des documents contenant des faits uniques et vérifiables.
2. Génération de tâches. Les documents se transforment en indices et en questions nécessitant une réflexion en plusieurs étapes, et non simplement une recherche rapide.
3. Distractions. Le processus génère des passages ressemblant à la bonne réponse mais menant ailleurs, imitant les bruits réels liés à la récupération d’informations.
4. Chaînage. Les tâches à un seul saut sont reliées en utilisant une réponse pour poser la question suivante, ce qui crée des défis allant de un à quatre sauts de profondeur.

Il prend en charge quatre domaines dès la sortie d’usine : le web, les déclarations SEC pour les questions financières, les brevets USPTO pour les travaux juridiques, et l’e-mail, en utilisant des ensembles de données de type Enron. La fiabilité des données provient d’une vérification basée sur l’extraction, où des modèles LLM extraient des extraits des documents ainsi que des extraits de référence correspondants, les normalisent et confirment que le texte est fiable. La précision de l’alignement dépasse 80 % dans chaque domaine, et la vérification humaine se réduit de la lecture de documents complets à la comparaison de paires d’extraits.

Essayer dès aujourd’hui

Il existe trois options.

L’API hébergée est la plus simple, car tout est géré à votre place, bien qu’elle soit soumise à une liste d’attente.

Les poids sont disponibles sur Hugging Face sous licence Apache 2.0 :

from transformers import AutoModelForCausalLM, AutoTokenizer
model = AutoModelForCausalLM.from_pretrained(
    "chromadb/context-1",
    torch_dtype="auto",
    device_map="auto"
)
tokenizer = AutoTokenizer.from_pretrained("chromadb/context-1")

Le gros problème est que le framework lui-même, c’est-à-dire l’exécution des outils, la gestion des budgets de tokens, le tri et la suppression des doublons dans le contexte, n’est pas encore public. Sans lui, vous ne pourrez pas reproduire les résultats du rapport technique. Ce schéma est familier pour les agents de programmation : le même modèle se comporte de manière très différente au sein de différents outils, car c’est le framework qui fait la différence. Context-1 sans lui, c’est un moteur de Formule 1 sans voiture. Chroma affirme qu’elle prévoit de publier le framework ainsi que le code d’évaluation.

La troisième solution consiste à créer votre propre framework autour des quatre outils documentés. Ce pseudocode donne une idée générale mais ne correspondra pas à la version finale de Chroma :

# Pseudocode for a basic Context-1 harness

tools = {
    "search_corpus": hybrid_bm25_vector_search,    # BM25 + dense vector via RRF
    "grep_corpus": regex_pattern_search,             # Regex matching, max 5 chunks
    "read_document": full_document_retrieval,        # Full doc by ID
    "prune_chunks": context_pruner                   # Remove chunks from context
}
context_budget = 32_768  # tokens
soft_threshold = 24_000
current_usage = 0
while not done:
    # Get model's next action
    response = model.generate(conversation_history)
    # Execute tool calls (model may call multiple in parallel)
    for tool_call in response.tool_calls:
        result = tools[tool_call.name](**tool_call.args)
        conversation_history.append(result)
        current_usage = count_tokens(conversation_history)
    # Enforce context budget
    if current_usage > soft_threshold:
        # Suggest pruning or concluding
        conversation_history.append(
            f"[Token usage: {current_usage}/{context_budget}] "
            "Consider pruning irrelevant chunks or concluding search."
        )

Limits actuels

• Il est conçu pour la profondeur, c’est-à-dire pour trouver l’élément recherché. Les requêtes de largeur qui doivent identifier tous les documents correspondant à un critère ne sont pas son point fort.
• Il ne génère pas de code, il ne peut donc pas produire de SQL pour interroger des données structurées. Il ne recherche que dans les documents.
• Il ne prend pas en compte la structure ou les métadonnées de vos données, ce qui signifie que la découverte des schémas relève de votre infrastructure.
• Sans l’outil officiel, les résultats annoncés ne peuvent pas être obtenus, ce qui bloque actuellement de nombreuses équipes.
• Une fenêtre de 32 K, même avec la fonction d’édition automatique, peut être insuffisante en mémoire de travail pour certaines tâches.

Ce qu’il suggère

Le Context-1 est important au-delà de Chroma. Au cours des deux dernières années, on a eu pour habitude de choisir le modèle le plus puissant que le budget permettait et de le laisser gérer toutes les étapes. Le Context-1 suggère que de petits modèles spécialisés peuvent rivaliser avec les modèles de pointe pour des tâches spécifiques, et que la combinaison de spécialistes tels qu’un récupérateur d’informations, un raisonneur et un générateur de code permet d’obtenir un système qui fonctionne plus rapidement, coûte moins cher, et donne souvent de meilleurs résultats qu’un modèle monolithique. Le logiciel a connu le même changement lorsque les grandes applications monolithiques ont été divisées en microservices. Les monolithes continuaient de fonctionner correctement, mais les petits composants ciblés s’adaptent plus facilement en termes de scalabilité.

Pour ceux qui développent des systèmes RAG en 2026, la question pertinente a changé. Oubliez l’idée de savoir quel modèle de pointe doit gérer tout le processus, et demandez plutôt quel modèle spécialisé convient à chaque étape. Un modèle de 20 milliards de paramètres capable de rivaliser avec GPT-5.4 et Opus-4.5 en matière de récupération d’informations remet en question l’idée selon laquelle plus c’est gros, mieux c’est, idée que le marketing a toujours promue.