rag chroma context-1 retrieval ai-agents llm

Chroma Context-1: Ein 20B-Such-Sub-Agent für günstigere, präzisere agierende RAG-Systeme

Chroma Context-1 ist ein 20B-Such-Sub-Agent für agierende RAG-Systeme, der seinen eigenen Kontext reduziert. Wie er trainiert wurde, was er von seinem Betriebssystem benötigt und seine Grenzen.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 202610 Min. Lesezeit2335 Wörter

Quellen: Replace Your RAG Agent’s Brain With a 20B Model. It Got Smarter.

In den meisten RAG-Systemen ist die Informationsabrufung der schwache Punkt. Man kann GPT-4, Claude, Gemini oder jedes andere State-of-the-Art-Modell darauf setzen – doch wenn der Suchschritt unbrauchbare Ergebnisse liefert, erzeugt das Modell dennoch zuverlässig, gut formuliert, aber falsche Antworten.

Nehmen wir eine Suche in rechtlichen Dokumenten: Die Antwort auf eine Frage ist in drei verschiedenen Unterlagen verteilt, und der Agent muss alle drei finden. Die übliche Lösung besteht aus einem State-of-the-Art-Modell in einem ReAct-Loop zusammen mit Vektor-Suchwerkzeugen. Das funktioniert zwar, kostet aber etwa 0,12 Dollar und 15 Sekunden pro Abfrage – es handelt sich dabei um eine Demonstration und nicht um eine produktive Funktion. Chromas Context-1 zielt genau auf dieses Problem von Kosten und Latenz ab.

Was Context-1 ist

Context-1 ist ein Sprachmodell mit 20 Milliarden Parametern, das ausschließlich für eine Aufgabe entwickelt wurde: die Informationsabrufung. Es erzeugt keine endgültigen Antworten und führt auch keine allgemeinen Schlussfolgerungen durch – es sucht lediglich.

In einer typischen agierenden RAG-Architektur übernimmt ein einziges Grenzmodell alles: Es plant, was gesucht werden soll, führt die Suche durch, entscheidet, ob weitere Informationen benötigt werden, und formuliert die Antwort. Das ist so, als würde man einen Gehirnchirurgen auch noch beauftragen, den Einkauf zu erledigen. Context-1 hingegen fungiert als spezialisierter Such-Sub-Agent, der die Dokumente findet, während ein separates Grenzmodell für das Schlussfolgern und Schreiben zuständig ist. Es handelt sich dabei um eine Trennung der Aufgaben in der KI-Architektur.

Das Modell basiert auf gpt-oss-20B, einem offenen Basismodell, und wurde durch überwachtes Feintuning sowie anschließendes Verstärkungslernen mithilfe von Chromas CISPO-Methode (Clipped Importance-Sampled Policy Optimization) trainiert. Das Ergebnis ist ein kleines Modell, das bei Suchleistungs-Benchmarks deutlich bessere Ergebnisse erzielt als aufgrund seiner Größe zu erwarten wäre.

Warum herkömmliche agierende RAG-Systeme nicht ausreichen

Ein klassischer Pipeline-Prozess umfasst nur einen Schritt: Die Frage wird eingebettet, die top-K-Teile werden zurückgegeben und ein LLM schreibt die Antwort.

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

Das weist bekannte Probleme auf. Man erhält nur Teilstücke und niemals vollständige Dokumente, wodurch der globale Kontext verloren geht. Ein einziger Durchlauf kann Fakten, die über mehrere Dokumente verteilt sind, nicht miteinander verknüpfen. Zudem ist semantische Ähnlichkeit nicht dasselbe wie Relevanz – ein Teilstück kann zwar das gleiche Vokabular wie die Frage verwenden, diese dennoch nicht beantworten.

Die agentbasierte Verbesserung umschließt dies in einen ReAct-Zyklus, bei dem das Modell plant, sucht, die Ergebnisse prüft und entscheidet, ob es erneut suchen soll.

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

Besser – aber es gibt einen Haken. Derselbe große Grenzmodell führt alle Schritte aus: Planung, Aufruf von Tools, Bewertung der Ergebnisse sowie Entfernung unrelevanter Teile – und das alles zu Grenzkosten. Kleinere Modelle können nicht mithalten, denn bereits der Systemprompt und die Tool-Definitionen verwirren sie, sodass sie den Prozess nicht zuverlässig durchlaufen. Am Ende zahlt man Premium-Preise für Arbeit, die keine Premium-Intelligenz benötigt.

Wie es funktioniert

Chroma hat nicht nur ein Modell feinabgestimmt, sondern auch einen Agentenrahmen entwickelt und das Modell darin trainiert, sodass Modell und seine Tools als Paar geliefert werden. Vier Tools sind Teil des Trainings:

search_corpus führt eine hybride Suche durch, indem es die BM25-Schlüsselwortabgleich-Methode mit einer dichten Vektorsuche über die rekursive Rangfusion kombiniert – dadurch erhält man sowohl präzise Treffer als auch semantisches Verständnis.
grep_corpus führt eine Regex-Überprüfung im gesamten Korpus durch und gibt bis zu fünf passende Abschnitte zurück, was bei der Suche nach einem bestimmten Datum, Namen oder Aktenzeichen nützlich ist.
read_document lädt ein vollständiges Dokument anhand der ID herunter, wenn ein Abschnitt vielversprechend erscheint.
prune_chunks ermöglicht es dem Modell, Abschnitte aus seinem eigenen Kontext zu löschen, wenn es sie für irrelevant hält. Das ist das Besondere daran.

Ein Ablaufverlauf zeigt das Muster. In der ersten Runde sucht das Modell nach Begriffen wie Fusion- und Übernahmepenalen, und es werden acht Abschnitte zurückgegeben, während die Token-Zahl bei 8.432 von insgesamt 32.768 liegt. In der zweiten Runde liest es ein Dokument vollständig ein und sucht erneut, bevor es alles Unnötige entfernt, um Platz für weitere Suche zu schaffen.

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

Der selbstbearbeitende Kontext

In den meisten Pipelines besteht die Gewohnheit, eine Gruppe von Textabschnitten abzurufen, sie alle in die Anfrage einzufügen und darauf zu vertrauen, dass das Modell die unwichtigen ignoriert. Forschungen zeigen, dass Modelle nicht nur Rauschen ignorieren, sondern auch dadurch verwirrt werden – ein Effekt, der als Kontextverderb bezeichnet wird. Context-1 begegnet diesem Problem direkt. Sein Kontextfenster umfasst 32.000 Token, und das Steuerungssystem überwacht die Nutzung im Laufe der Zeit:

Nach jedem Aufruf eines Tools sieht das Modell seine aktuelle Nutzung in einer Form wie [Token Nutzung: 14.203/32.768].
Bei etwa 24.000 Token gibt das Steuerungssystem einen Hinweis, den Kontext zu kürzen oder abzuschließen.
Über eine einstellbare Obergrenze hinaus kann das Modell nur noch kürzen oder abschließen, ohne weitere Inhalte abzurufen – dadurch wird ein unkontrolliertes Wachstum des Kontexts verhindert.

Die Entscheidung zur Reduzierung obliegt dem Modell selbst. Es werden weder ein separater Neurangier noch Heuristiken eingesetzt, sondern das Modell, das die Abschnitte abgerufen hat, beurteilt sie.

Die Genauigkeit bei der Reduzierung erreicht 0,941, was einem Anstieg von 0,824 beim Basismodell entspricht – somit werden irrelevante Abschnitte zu etwa 94 Prozent der Zeit erkannt. Dies übertrifft sogar Provence von Naver Labs, das ein spezielles Modell zur Reduzierung von Sätzen verwendet hat. Hier führt der Suchagent die Reduzierung im Rahmen seines normalen Arbeitsablaufs durch, ohne ein zusätzliches Modell.

Drei Ebenen

Chroma betont – und das ist weiser Rat –, dass Context-1 ausschließlich für die Suche und nicht für die Generierung verwendet werden sollte. Die Architektur besteht aus drei Ebenen: der Datenschicht, dem Context-1-Suchsubagenten sowie einem darüber liegenden Reasoning-Modell. Diese Aufteilung bringt vier Vorteile mit sich:

Jeder Teil kann unabhängig verbessert werden, sodass man morgen einen besseren Abrufmechanismus einsetzen kann, ohne die Generierung zu beeinflussen.
Das teure Modell erhält nur sauberen, sorgfältig ausgewählten Kontext, nicht rohe Suchergebnisse.
Context-1 erzeugt 400 bis 500 Token pro Sekunde auf einer Nvidia B200, was für mehrstufige Suchvorgänge schnell ist.
Der Reasoner erhält fokussiertes Material und liefert bessere Antworten.

Es ist wieder das Prinzip der Microservices: Lassen Sie kein einziges Modell alles erledigen.

Wie es trainiert wurde

Überwachtes Feintuning. Der Lehrer war Kimi K2.5, ein großes Frontier-Modell. Das Team erzeugte mit ihm Suchverläufe innerhalb des Vier-Tools-Systems, filterte diese nach Trefferquote und trainierte Context-1, sowohl erfolgreiche als auch fehlgeschlagene Suchvorgänge nachzuahmen. Die fehlgeschlagenen Suchvorgänge wurden absichtlich beibehalten, denn selbst Suchvorgänge mit niedriger Trefferquote enthalten gut strukturierte Toolaufrufe, Abfragedekompositionen sowie Entscheidungen zur Reduzierung der Ergebnisse. Das Modell lernt die Mechanismen der Suche aus Suchvorgängen, bei denen etwas übersehen wurde.

Verstärkungslernen mit CISPO. Jeder Trainingsschritt nutzte 128 Abfragen mit jeweils 8 Ausführungen, was insgesamt 1.024 Trajektorien ergibt, über 5 Epochen hinweg, die bei Schritt 230 annähernd konvergieren. Jeder Token trägt zum Lernen bei, einschließlich seltener, aber wichtiger Token wie Entscheidungen zur Pruning. Die Belohnung setzt sich aus mehreren Faktoren zusammen:

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

Die Ausbildung folgte ebenfalls einem zweistufigen Curriculum. Zunächst wurden einfachere, einstufige Aufgaben verwendet, bei denen die Erinnerung 16 Mal stärker gewichtet wurde als die Genauigkeit, was eine aggressive Erkundung fördert. Später wechselte man zu schwierigeren, mehrstufigen Aufgaben mit einer 4-fachen Gewichtung, die Selektivität lehrt. Dies ähnelt der Ausbildung eines Suchhundes: Zuerst soll er irgendeinen Geruch finden, anschließend den spezifischen.

Der Datensatz-Workflow

Eines der nützlichsten Elemente, die Chroma veröffentlicht hat, ist vermutlich sein Pipeline zur Erzeugung synthetischer Daten, das auf GitHub als Open Source bereitgestellt wird und als Vorlage für die Erstellung von Suchtrainingsdaten in jedem Bereich dient. Es folgt dem Muster Erkunden, Überprüfen, Erweitern:

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

Erkundung. Aus einem Ausgangsthema, wie beispielsweise einem zufälligen Wikipedia-Titel, durchforstet ein Agent das Internet und sammelt Dokumente mit einzigartigen, überprüfbaren Fakten.
Task-Generierung. Die Dokumente werden zu Hinweisen und Fragen, die echtes mehrstufiges Denken erfordern, nicht nur eine einfache Suche.
Ablenkungen. Der Prozess erstellt Abschnitte, die der richtigen Antwort ähneln, aber in eine andere Richtung weisen, wodurch echter Suchrauschen nachgeahmt wird.
Kettenbildung. Einzelstufige Aufgaben werden miteinander verbunden, indem eine Antwort verwendet wird, um die nächste Frage zu stellen, wodurch Herausforderungen mit einer bis vier Schritten Tiefe entstehen.

Es unterstützt standardmäßig vier Bereiche: das Web, SEC-Berichte für Finanzfragen, USPTO-Patente für rechtliche Zwecke sowie E-Mails, wobei Enron-stilisierte Datensätze verwendet werden. Das Vertrauen in die Daten ergibt sich aus einer auf Extraktion basierenden Überprüfung, bei der LLMs Zitate aus Dokumenten sowie passende Hinweiszitate heraussuchen, sie normalisieren und bestätigen, dass der Text fundiert ist. Die Abstimmungsgenauigkeit liegt in jedem Bereich über 80%, und die menschliche Überprüfung beschränkt sich auf den Vergleich von Zitatpaaren anstelle des Lesens ganzer Dokumente.

Heute ausprobieren

Es gibt drei Möglichkeiten.

Die gehostete API ist am einfachsten, da die Infrastruktur bereits für einen bereitgestellt wird, allerdings steht sie auf einer Warteliste.

Die Gewichte sind auf Hugging Face unter der Apache 2.0-Lizenz verfügbar:

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")

Der große Haken ist, dass das Harness selbst – also die Tool-Verwaltung, die Token-Verwaltung, das Kontext-Pruning sowie die Deduplizierung – noch nicht öffentlich verfügbar ist. Ohne es können Sie die Ergebnisse des technischen Berichts nicht reproduzieren. Dieses Muster ist aus Coding-Agents bekannt: Derselbe Modell verhält sich in verschiedenen Tools sehr unterschiedlich, weil das Harness den Unterschied macht. Context-1 ohne dieses Harness ist wie ein Formel-1-Motor ohne Auto. Chroma gibt an, das Harness sowie den Evaluierungscode veröffentlichen zu wollen.

Der dritte Ansatz besteht darin, Ihr eigenes Harness um die vier dokumentierten Tools zu entwickeln. Dieser Pseudocode gibt eine Vorstellung, entspricht aber nicht der Produktionsversion von 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."
        )

Derzeitige Grenzen

Es ist auf die Suche in großer Tiefe, um die „Nadel“ zu finden, trainiert. Abfragen, die alle Dokumente finden müssen, die einem Kriterium entsprechen, sind nicht seine Stärke.
Es schreibt keinen Code, daher kann es keinen SQL-Code zur Abfrage strukturierter Daten erzeugen. Es durchsucht nur Dokumente.
Es lernt weder die Struktur noch die Metadaten Ihrer Daten, sodass die Entdeckung des Schemas Ihrer Infrastruktur überlassen bleibt.
Ohne das offizielle Tool sind die gemeldeten Ergebnisse nicht erreichbar, was viele Teams vorerst blockiert.
Ein 32K-Speicherbereich, selbst bei Selbstbearbeitung, kann für einige Aufgaben zu geringer Arbeitsspeicher sein.

Was es vorschlägt

Context-1 ist von Bedeutung – und zwar nicht nur im Zusammenhang mit Chroma. In den letzten zwei Jahren war es üblich, das größte Modell zu wählen, das das Budget zulässt, und es alle Schritte übernehmen zu lassen. Context-1 legt nahe, dass kleine, spezialisierte Modelle bei spezifischen Aufgaben mit hochentwickelten Modellen mithalten können, und dass die Kombination solcher Spezialisten – wie eines Informationsabrufers, eines Logikers und eines Codegenerators – ein System ergibt, das schneller läuft, weniger kostet und häufig bessere Ergebnisse liefert als ein monolithisches Modell. Auch bei Software gab es einen ähnlichen Wandel, als große monolithische Anwendungen in Microservices aufgeteilt wurden. Monolithen funktionierten weiterhin einwandfrei – kleine, fokussierte Komponenten ließen sich jedoch leichter skalieren.

Für Entwickler von RAG-Systemen im Jahr 2026 hat sich die wichtige Frage geändert. Statt zu fragen, welches Spitzenmodell alles verarbeiten soll, sollte man fragen, welches Spezialmodell für jede Phase geeignet ist. Ein 20B-Modell, das mit GPT-5.4 und Opus-4.5 bei der Informationsabrufung mithalten kann, stellt die Annahme in Frage, dass größere Modelle immer besser seien – eine Ansicht, die von der Marketingabteilung verbreitet wird.