Chroma Context-1: 20B Sub-Agent do wyszukiwania w celu tańszych i bardziej precyzyjnych rozwiązań typu Agentic RAG

W większości systemów RAG kluczowym problemem jest proces wyszukiwania informacji. Można na górze umieścić GPT-4, Claude, Gemini lub dowolny inny zaawansowany model, ale jeśli krok wyszukiwania zwróci nieprawidłowe dane, model i tak będzie generował pewne siebie, dopracowane, lecz błędne odpowiedzi.

Wyobraźmy sobie wyszukiwanie dokumentów prawniczych, gdzie odpowiedź na pytanie znajduje się w trzech różnych plikach, a system musi je wszystkie odnaleźć. Zwykłe rozwiązanie to użycie zaawansowanego modelu w pętli ReAct w połączeniu z narzędziami do wyszukiwania wektorowego. To działa, ale przy koszcie około 0,12 dolara i piętnastu sekundach na zapytanie jest to jedynie demonstracja, a nie funkcja produktu. Chroma’s Context-1 jest przeznaczony właśnie do rozwiązania tego problemu kosztów i opóźnień.

Czym jest Context-1

Context-1 to model językowy z 20 miliardami parametrów stworzony do jednego zadania: wyszukiwania informacji. Nie generuje ostatecznych odpowiedzi ani nie przeprowadza ogólnego rozumowania – jego zadaniem jest wyłącznie wyszukiwanie.

W typowej architekturze agentic RAG jeden model roboczy robi wszystko: planuje, co wyszukać, przeprowadza wyszukiwanie, decyduje, czy potrzeba więcej informacji, oraz pisze odpowiedź. To tak, jakby zatrudnić chirurga mózgu do robienia zakupów. Context-1 natomiast pełni rolę dedykowanego podagenta do wyszukiwania dokumentów, a oddzielny model roboczy zajmuje się rozumowaniem i pisaniem. Jest to rozdzielenie zadań w architekturze sztucznej inteligencji.

Model został zbudowany na bazie otwartego modelu gpt-oss-20B i przeszkolony metodą fine-tuningu pod nadzorem, a następnie za pomocą uczenia wzmacniającego z wykorzystaniem metody CISPO firmy Chroma (Clipped Importance-Sampled Policy Optimization). Rezultatem jest mały model, który osiąga wyniki znacznie lepsze od tych oczekiwanych na podstawie jego rozmiaru w testach odzyskiwania informacji.

Dlaczego zwykła architektura agentic RAG nie wystarcza

Klasyczny pipeline obejmuje jeden krok: zadanie jest wstawione, powracają najlepsze K fragmentów, a model językowy generuje odpowiedź.

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

To wiąże się z dobrze znanymi problemami. Otrzymuje się fragmenty, a nigdy pełne dokumenty, więc globalny kontekst jest utracony. Jedna próba nie może połączyć faktów rozproszonych w kilku dokumentach. Ponadto podobieństwo semantyczne nie jest tym samym co istotność, ponieważ fragment może dzielić słownictwo z pytaniem i mimo to nie odpowiedzieć na nie.

Ulepszenie oparte na agencjach otacza to pętlą ReAct, w której model planuje, przeszukuje, analizuje wyniki i decyduje, czy przeprowadzić ponowne poszukiwania.

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

Lepiej, ale jest jeden haczyk. Ten sam duży model frontier wykonywa każdy krok: planowanie, wywoływanie narzędzi, ocenę wyników oraz usuwanie nieistotnych fragmentów, wszystko po cenach typu frontier. Mniejsze modele nie mogą konkurować, ponieważ sam prompt systemu i definicje narzędzi już je dezorientują, a one nie potrafią wiarygodnie realizować całego procesu. W rezultacie płacisz wyższe stawki za pracę, która nie wymaga zaawansowanej inteligencji.

Jak to działa

Chroma nie tylko dostosowało model – stworzyło specjalne narzędzie do jego obsługi i wytrenowało model w jego ramach, dzięki czemu model wraz z narzędziami dostępne są jako całość. Częścią treningu są cztery narzędzia:

• search_corpus realizuje hybrydowe wyszukiwanie, łącząc dopasowywanie słów kluczowych metodą BM25 z intensywnym wyszukiwaniem wektorowym poprzez fuzję rankingu wzajemnego, dzięki czemu uzyskujesz zarówno dokładne dopasowania, jak i semantyczne zrozumienie.
• grep_corpus przeprowadza dopasowanie wzorca regularnego w całym korpusie i zwraca maksymalnie pięć pasujących fragmentów, co jest przydatne przy wyszukiwaniu konkretnej daty, nazwy lub numeru sprawy.
• read_document ładuje pełny dokument na podstawie ID, gdy jakiś fragment wydaje się obiecujący.
• prune_chunks umożliwia modelowi usuwanie fragmentów z własnego kontekstu, gdy uzna je za nieistotne. To jest najważniejsza funkcja.

Śledzenie procesu pokazuje wzorzec działania. W pierwszym kroku model szuka informacji na temat kary za fuzje i przejęcia, a powraca osiem fragmentów, przy czym licznik tokenów wskazuje 8 432 z 32 768. W drugim kroku model czyta cały dokument i szuka ponownie, a następnie usuwa to, co nie było pomocne, tworząc więcej miejsca na dalsze poszukiwania.

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

Kontekst samoredagujący

W większości systemów powszechnym zwyczajem jest pobieranie serii fragmentów tekstu, umieszczanie ich wszystkich w instrukcji i poleganie na modelu, by ten zignorował te nieważne. Badania pokazują, że modele nie tylko ignorują szum, ale także są przez niego dezorientowane – efekt ten nazywany jest zepsuciem kontekstu. Context-1 rozwiązuje ten problem bezpośrednio. Jego okno kontekstowe ma pojemność 32 000 tokenów, a narzędzie monitoruje zużycie w trakcie pracy:

1. Po każdej wywołanej funkcji model widzi aktualne zużycie w formie takiej jak [Token usage: 14,203/32,768].
2. Gdy ilość tokenów osiąga około 24 000, narzędzie sugeruje usunięcie niepotrzebnych elementów lub zakończenie pracy.
3. Po przekroczeniu ustawionej granicy maksymalnego zużycia model może jedynie usuwać elementy lub zakończyć pracę, bez dalszego pobierania danych, co zapobiega niekontrolowanemu rozrostowi kontekstu.
4. Decyzja o przycinaniu należy do samego modelu. Nie jest używany żaden oddzielny narzędzie do ponownego rankowania ani heurystyka – to model, który pobrał fragmenty tekstu, ocenia je.

Dokładność przycinania osiąga 0,941, co jest lepsze niż 0,824 w modelu bazowym, dzięki czemu model identyfikuje nieistotne fragmenty w około 94% przypadków. Jest to lepsze wynik niż w przypadku Provence od Naver Labs, który wykorzystywał dedykowany model do przycinania zdań. Tutaj agent wyszukiwawczy przycina fragmenty jako część swojej standardowej procedury, bez użycia dodatkowego modelu.

Trzy poziomy

Chroma podkreśla – i to słuszna rada – że Context-1 powinien być używany wyłącznie do wyszukiwania, a nie do generowania treści. Architektura składa się z trzech poziomów: warstwy danych, podagenta wyszukiwawczego Context-1 oraz modelu rozumowania na najwyższym poziomie. Taki podział przynosi korzyści na cztery sposoby:

• Każdą część można ulepszyć osobno, więc jutro można zastąpić gorszy narzędzie do wyszukiwania lepszym, nie wpływając na proces generowania.
• Drugi model, droższy, ma dostęp tylko do uporządkowanego, przygotowanego kontekstu, a nie do surowych wyników wyszukiwania.
• Context-1 generuje od 400 do 500 tokenów na sekundę na karcie Nvidia B200, co jest szybkie przy wyszukiwaniu wieloetapowym.
• System analityczny otrzymuje skoncentrowane dane i w ten sposób tworzy lepsze odpowiedzi.

To znowu zasada mikrosług: nie zmuszaj jednego modelu do wykonywania wszystkiego.

Jak został wytrenowany

Dokręcanie modelu pod nadzorem. Nauczycielem był Kimi K2.5, duży model typu frontier. Zespół wygenerował z jego pomocą trajektorie wyszukiwania w ramach czterotorowego zestawu narzędzi, przefiltrował je pod kątem dokładności i wytrenował Context-1 do naśladowania zarówno udanych, jak i nieudanych prób. Nieudane próby zostały celowo zachowane, ponieważ nawet wyszukiwania o niskiej dokładności zawierają dobrze sformułowane wywołania narzędzi, dekompozycję zapytań oraz decyzje dotyczące ich optymalizacji. Model uczy się mechaniki wyszukiwania na podstawie prób, które nie przyniosły żadnych rezultatów.

Uczenie się przez wzmacnianie z CISPO. Każdy krok treningowy wykorzystywał 128 zapytań, z których każde zawierało 8 wariantów, co dawało łącznie 1 024 trajektorie, rozproszone na 5 epok, konwergujące około kroku 230. Każdy token przyczynia się do procesu uczenia, w tym te rzadkie, ale kluczowe, takie jak decyzje dotyczące przycinania. Nagroda składa się z kilku składników:

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

Szkolenie również odbywało się zgodnie z dwuetapowym programem nauczania. Na początku wykorzystywano prostsze zadania jednoetapowe, w których ważność odnalezienia była 16 razy większa niż precyzja, co zachęcało do agresywnej eksploracji. Później przeszło się na trudniejsze zadania wieloetapowe z wagą 4x, co promowało selektywność. Przypomina to szkolenie psa tropiącego: najpierw znalezienie jakiegokolwiek zapachu, a następnie tego konkretnego.

Proces przetwarzania danych

Jedną z najprzydatniejszych funkcji wprowadzonych przez Chroma może być jego pipeline do generowania danych syntetycznych, udostępniony otwarcie na GitHubie, który służy jako wzór do tworzenia danych treningowych do wyszukiwania w dowolnej dziedzinie. Opiera się on na schemacie: eksploracja, weryfikacja, rozwijanie.

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

1. Eksploracja. Na podstawie tematu początkowego, takiego jak losowy tytuł na Wikipedii, agent przegląda internet i zbiera dokumenty zawierające unikalne, sprawdzalne fakty.
2. Generowanie zadań. Dokumenty stają się wskazówkami i pytaniami wymagającymi rzeczywistego, wieloetapowego rozumowania, a nie prostego wyszukiwania.
3. Rozpraszacze. Proces generuje fragmenty tekstu przypominające prawidłową odpowiedź, ale skierowane w inne miejsce, naśladując rzeczywiste zakłócenia w procesie wyszukiwania.
4. Łączenie zadań. Zadania jednoetapowe są łączone poprzez wykorzystanie jednej odpowiedzi do postawienia kolejnego pytania, co tworzy wyzwania wieloetapowe o głębokości od jednego do czterech etapów.

Od razu obsługuje cztery domeny: internet, dokumenty SEC w dziedzinie finansów, patenty USPTO w pracy prawniczej oraz e-maile, wykorzystując zestawy danych w stylu Enrona. Zaufanie do danych pochodzi z weryfikacji opartej na wydobywaniu informacji, przy której modele LLM wybierają cytaty z dokumentów oraz odpowiadające im fragmenty, normalizują je i potwierdzają, że tekst ma solidne podstawy. Dokładność dopasowania przekracza 80% we wszystkich domenach, a kontrola przez ludzi polega już nie na czytaniu całych dokumentów, lecz na porównywaniu par cytatów.

Próbuj już dziś

Istnieją trzy sposoby.

Hostowana API jest najprostsza, ponieważ cała infrastruktura jest za Ciebie załatwiona, choć wymaga zgłoszenia się na listę oczekujących.

Wagi modelu znajdują się na Hugging Face pod licencją 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")

Ważną zastrzeżeniem jest to, że sam framework, czyli mechanizm wykonywania narzędzi, zarządzanie budżetem tokenów, przycinanie kontekstu oraz usuwanie duplikatów, nie jest jeszcze dostępny publicznie. Bez niego nie uda się odtworzyć wyników raportu technicznego. Ten schemat jest dobrze znany z agentów programistycznych: ten sam model zachowuje się zupełnie inaczej w różnych narzędziach, ponieważ to framework sprawia tę różnicę. Context-1 bez niego to silnik Formuły 1 bez samochodu. Chroma twierdzi, że planuje opublikować ten framework oraz kod do oceny.

Trzecią opcją jest stworzenie własnego frameworku wokół czterech udokumentowanych narzędzi. Ten pseudokod daje przybliżone wyobrażenie, ale nie będzie odpowiadał wersji produkcyjnej Chromy:

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

Bieżące ograniczenia

• Został przeszkolony na głębię, czyli na znajdowanie konkretnych elementów. Zapytania o szerokość, które muszą odnaleźć wszystkie dokumenty spełniające określone kryteria, nie są jego mocną stroną.
• Nie pisze żadnego kodu, więc nie może generować zapytań SQL do przeszukiwania danych strukturalnych. Przeszukuje jedynie dokumenty.
• Nie uczy się struktury ani metadanych twoich danych, więc odkrywanie schematu zależy od twojej infrastruktury.
• Bez oficjalnego narzędzia uzyskanie podanych wyników nie jest możliwe, co na razie utrudnia pracę wielu zespołom.
• Okno pamięci 32K, nawet przy możliwości samokorekty, może okazać się zbyt małe dla niektórych zadań.

Co proponuje

Context-1 ma znaczenie nie tylko w przypadku Chromy. Przez ostatnie dwa lata powszechnym zwyczajem było wybieranie największego modelu, na jaki pozwalał budżet, i pozwalanie mu na obsługę każdego kroku. Context-1 wskazuje, że małe, specjalistyczne modele mogą dorównywać modelom najnowocześniejszym w zadaniach o ograniczonym zakresie, a łączenie takich specjalistów, jak systemy do wyszukiwania informacji, rozumowania i generowania kodu, pozwala stworzyć system, który działa szybciej, kosztuje mniej i często daje lepsze wyniki niż jeden monolityczny model. Oprogramowanie przeszło przez podobną zmianę, gdy duże, monolityczne aplikacje zostały podzielone na mikrosługi. Monolity nadal funkcjonowały dobrze, natomiast małe, skoncentrowane komponenty łatwiej się skalowały.

Dla twórców systemów RAG w 2026 roku zmieniło się pytanie kluczowe. Zamiast zastanawiać się, który model o najwyższych możliwościach powinien obsługiwać wszystko, należy zapytać, który specjalista nadaje się do każdego etapu. Model o mocy 20 miliardów parametrów, który dorównuje GPT-5.4 i Opus-4.5 pod względem szybkości wyszukiwania informacji, podważa przekonanie, że im większy model, tym lepszy, które promuje marketing.