Chroma Context-1: 20B-потужний підагент для пошуку з метою отримання дешевших та точніших результатів у рамках агентських систем RAG
Chroma Context-1 — це 20-мільярдний пошуковий підагент для агентного RAG, який видаляє власний контекст. Як його навчали, що йому потрібно від інфраструктури та його обмеження.
Джерела: Replace Your RAG Agent’s Brain With a 20B Model. It Got Smarter.
У більшості систем RAG процес пошуку є слабкою ланкою. Ви можете використовувати GPT-4, Claude, Gemini чи будь-яку іншу передову модель, але якщо крок пошуку повертає некорисну інформацію, модель все одно буде генерувати впевнені, витончені, але неправильні відповіді.
Уявіть пошук у юридичному документі, де відповідь на запитання розташована у трьох документах, і агенту потрібно знайти всі три. Зазвичай використовується передова модель у циклі ReAct із інструментами векторного пошуку. Це працює, але за вартістю близько 0,12 долара та п’ятнадцяти секунд на запит це лише демонстрація, а не функція продукту. Chroma’s Context-1 спрямований саме на вирішення проблеми витрат та затримок.
Що таке Context-1
Context-1 — це мовна модель з 20 мільярдів параметрів, створена для однієї задачі: пошуку інформації. Вона не генерує кінцеві відповіді та не виконує загальне міркування. Вона лише шукає.
У типовій архітектурі агентного RAG одна модель виконує всі завдання: вона планує, що шукати, проводить пошук, вирішує, чи потрібні додаткові дані, та формулює відповідь. Це все одно, що найняти нейрохірурга, який ще й робитиме покупки. Натомість Context-1 виступає як спеціалізований підагент для пошуку документів, а окрема модель відповідає за логічні міркування та формулювання відповідей. Це є розділенням функцій у архітектурі ШІ.
Модель побудована на основі gpt-oss-20B — відкритої базової моделі — та навчалася за допомогою керованої фінтюнінгу з подальшим використанням методу посилення навчання CISPO від Chroma (Clipped Importance-Sampled Policy Optimization). Результатом є невелика модель, яка показує значно кращі результати у тестах на пошук інформації, ніж можна було б очікувати від її розміру.
Чому звичайний агентний RAG не є оптимальним
Класична система обробки складається з одного етапу: ставиться запит, повертаються топ-K фрагментів, а ШІ пише відповідь.
User Query → Embedding Search → Top-K Chunks → LLM → Response
У цього підходу є добре відомі проблеми. Ви отримуєте лише фрагменти, а не повні документи, тому загальний контекст втрачається. Одна процедура обробки не може поєднати факти, розкидані по кількох документах. Крім того, семантична схожість — це не те саме, що релевантність, адже фрагмент може мати спільну лексику з запитанням, проте все одно не відповідати на нього.
Оновлення з використанням агентного підходу охоплює це процес ReAct-циклом, у якому модель планує, шукає, аналізує результати та вирішує, чи потрібно шукати знову.
User Query → Plan → Search → Observe → Need more info? → Search again → Generate
Краще, але є одна умова. Той самий великий модель фронтиру виконує кожен крок: планування, виклик інструментів, оцінка результатів та видалення непотрібних частин — усе це за високими тарифами. Менші моделі не можуть конкурувати, адже вже самі системні інструкції та визначення інструментів їх плутають, і вони не можуть надійно виконувати цей цикл. У підсумку ви платите преміальні тарифи за роботу, яка не потребує преміальних інтелектуальних здібностей.
Як це працює
Chroma не просто налаштувала модель. Вона створила спеціальну платформу для агентів та навчила модель у межах неї, тож модель та її інструменти постачаються разом. У процесі навчання використовуються чотири інструменти:
search_corpusвиконує гібридний пошук, поєднуючи пошук за ключовими словами BM25 із щільним векторним пошуком через фузію взаємних рангів, що дозволяє отримати як точні збіги, так і семантичне розуміння.grep_corpusвиконує пошук за правилами регулярних виразів у всьому корпусі та повертає до п’яти відповідних фрагментів, що зручно для пошуку за конкретною датою, ім’ям чи номером справи.read_documentзавантажує повний документ за його ID, якщо певний фрагмент видається перспективним.prune_chunksдозволяє моделі видаляти фрагменти з власного контексту, якщо вона вважає їх нерелевантними. Це найцікавіша функція.
Хід роботи моделі демонструє її підхід. На першому кроці модель шукає інформацію про штрафи за злиття та поглинання, і повертається вісім фрагментів, при цьому лічильник токенів показує 8,432 з 32,768. На другому кроці вона читає документ повністю та знову шукає, після чого видаляє все, що не було корисним, звільняючи місце для подальшого пошуку.
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
Контекст самокорекції
У більшості підходів існує звичка брати певну кількість фрагментів тексту, додавати їх у запит та покладатися на модель, щоб та проігнорувала неважливі елементи. Дослідження показують, що моделі не просто ігнорують «шум», а й плутаються через нього — цей ефект називається розкладанням контексту. Context-1 прямо бореться з цією проблемою. Його вікно контексту становить 32 000 токенів, а система контролює їх використання протягом роботи:
- Після кожного виклику інструменту модель бачить своє поточне використання у форматі
[Token usage: 14,203/32,768]. - При досягненні приблизно 24 000 токенів система дає сигнал про необхідність скорочення обсягу контексту або завершення роботи.
- Після перевищення налаштованого жорсткого ліміту модель може лише скорочувати контекст або завершувати роботу, без можливості додаткового збору інформації, що запобігає неконтрольованому зростанню обсягу контексту.
Точність обрізки досягає 0,941, що є покращенням порівняно з 0,824 у базовій моделі, тож вона виявляє нерелевантні фрагменти приблизно у 94% випадків. Це краще, ніж система Provence від Naver Labs, яка використовувала окрему модель для обрізки речень. Тут пошуковий агент виконує обрізку як частину своєї звичайної роботи, без додаткової моделі.
Три рівні
Chroma наголошує, і це слушна порада, що Context-1 слід використовувати лише для пошуку інформації, а не для її генерації. Архітектура складається з трьох рівнів: шар даних, пошуковий підагент Context-1 та верхній рівень у вигляді моделі для міркувань. Такий поділ має чотири переваги:
- Кожну частину можна покращувати окремо, тож ви можете завтра замінити пошуковий інструмент на кращий, не торкаючись процесу генерації.
- Дорога версія моделі бачить лише очищений, підготовлений контекст, а не сирі результати пошуку.
- Context-1 генерує від 400 до 500 токенів на секунду на процесорі Nvidia B200, що є швидким темпом для багатоетапного пошуку.
- Механізм аналізу отримує фокусований матеріал та створює кращі відповіді.
Це знову принцип мікросервісів: не змушуйте одну модель робити все.
Як її навчали
Керована доробка. Вчителем була Kimi K2.5 — велика модель нового покоління. Команда створювала траєкторії пошуку за її допомогою в рамках чотириінструментального комплексу, фільтрувала їх за рівнем відтворення результатів та навчала Context-1 імітувати як успішні, так і невдалий пошук. Невдалі спроби зберігалися навмисно, адже навіть пошуки з низьким рівнем відтворення містять правильно сформульовані виклики інструментів, розкладання запитів та вибір способів оптимізації. Учень вивчає механіку пошуку на прикладі тих пошуків, які щось пропустили.
Навчання з посиленням за допомогою CISPO. Кожен крок навчання використовував 128 запитів по 8 варіантів кожен, тобто 1 024 траєкторії протягом 5 епох, які збігалися близько до 230-го кроку. Кожен токен сприяє навчанню, включаючи рідкісні, але критичні, такі як рішення щодо обрізки. Нагорода складається з кількох компонентів:
Reward = F1_score (recall-weighted)
+ trajectory_recall_bonus
+ final_answer_bonus (+1.0)
- repeated_pruning_penalty (0.1 per excess)
- turn_count_penalty
Навчання також відбувалося за двоступеневою схемою. Спочатку використовувалися простіші завдання з одним кроком, у яких вага точності була у 16 разів меншою за вагу відтворення даних, що сприяло агресивному дослідженню. Пізніше перейшли до складніших завдань з кількома кроками з коефіцієнтом ваги 4, що сприяло вибірковості. Це схоже на навчання пошукової собаки: спочатку знаходити будь-який запах, а потім конкретний.
Канал обробки даних
Однією з найкорисніших речей, які оприлюднила Chroma, може бути її система генерації синтетичних даних, опублікована у відкритому коді на GitHub, яка слугує шаблоном для створення даних для навчання пошуку в будь-якій галузі. Вона дотримується схеми дослідження, перевірки та розширення:
Seed Topic → Explore Web → Extract Verifiable Facts → Generate Tasks
↓
Add Distractors → Chain Into Multi-Hop → Verify Answers
- Дослідження. Виходячи з початкової теми, наприклад випадкової назви у Вікіпедії, агент переглядає Інтернет та збирає документи з унікальними, перевіряючимися фактами.
- Створення завдань. Документи перетворюються на підказки та запитання, які вимагають справжнього багатоетапного міркування, а не простого пошуку.
- Відволікаючі елементи. Система створює уривки, схожі на правильну відповідь, але спрямовані в інший бік, імітуючи справжній шум під час пошуку.
- Ланцюгування. Завдання одного кроку поєднуються шляхом використання однієї відповіді для постановки наступного запитання, що створює завдання з кількістю кроків від одного до чотирьох.
Він заздалегідь підтримує чотири домени: веб, документи SEC для фінансової сфери, патенти USPTO для юридичної роботи та електронну пошту, використовуючи набори даних у стилі Enron. Довіра до даних забезпечується шляхом перевірки на основі витягування інформації, де моделі LLM беруть цитати з документів та відповідні ключові фрагменти, нормалізують їх та підтверджують, що текст має підстави. Точність вирівнювання перевищує 80% у кожному домені, а перевірка людиною скорочується від читання всіх документів до порівняння пар цитат.
Спробуємо сьогодні
Існує три способи використання.
Хостований API є найпростішим, оскільки всі налаштування робляться за вас, хоча він знаходиться у списку очікування.
Ваги моделі доступні на Hugging Face під ліцензією 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")
Великою проблемою є те, що сам інструментарій — тобто механізми виконання інструментів, керування бюджетом токенів, обробка контексту та усунення дублікатів — ще не є публічним. Без нього ви не зможете відтворити результати технічного звіту. Ця ситуація знайома з кодуючими агентами: одна й та сама модель поводиться дуже по-різному в різних інструментах, оскільки саме інструментарій створює цю різницю. Context-1 без нього — це двигун Формули-1 без автомобіля. Chroma заявляє, що планує оприлюднити цей інструментарій та код для оцінки.
Третій шлях — це створення власного інструментарію навколо чотирьох задокументованих інструментів. Цей псевдокод дає уявлення про принцип, але не буде відповідати фінальній версії від 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."
)
Текущі обмеження
- Він навчений на пошук у глибину, щоб знайти конкретну інформацію. Запити, які мають знайти кожен документ, що відповідає критерію, — не його сильна сторона.
- Він не пише коду, тому не може створювати SQL-запити для обробки структурованих даних. Він шукає лише в документах.
- Він не вивчає структуру чи метадані ваших даних, тому визначення схеми залежить від вашої інфраструктури.
- Без офіційного інструментарію отримати звітовані результати неможливо, що наразі заважає багатьом командам.
- Вікно обробки у 32K, навіть із можливістю самостійної редагування, може бути занадто малим для пам’яті при виконанні деяких завдань.
Що він пропонує
Контекст-1 має значення не лише у Chroma. Протягом останніх двох років існує тенденція обирати найпотужнішу модель, яку дозволяє бюджет, та дозволяти їй виконувати всі кроки. Контекст-1 свідчить про те, що невеликі спеціалізовані моделі можуть зрівнятися з найсучаснішими у виконанні вузькоспеціалізованих завдань, а поєднання таких спеціалістів, як засіб пошуку інформації, міскуматор та генератор коду, дає систему, яка працює швидше, коштує дешевше та часто дає кращі результати, ніж одна монолітна модель. Програмне забезпечення пройшло таку саму трансформацію, коли великі монолітні додатки були розділені на мікросервіси. Моноліти все ще працювали добре, але невеликі спеціалізовані компоненти легше масштабувалися.
Для тих, хто створює системи RAG у 2026 році, актуальне питання змінилося. Не варто більше запитувати, яка фронтальна модель має обробляти все, а краще з’ясувати, який спеціаліст підходить для кожної стадії. Модель обсягом 20 мільярдів параметрів, яка тримається на рівні з GPT-5.4 та Opus-4.5 у завданнях зі знаходження інформації, ставить під сумнів ідею про те, що більший завжди кращий, ідею, яку просуває маркетинг.
Пов’язані матеріали
- Stateful RAG на Databricks: багатокрокова пам’ять з Lakebase та LangGraph — Надайте агенту RAG у Databricks справжню пам’ять для розмов: парсуйте PDF-файли, створюйте систему векторного пошуку, зберігайте записи розмов у Lakebase Postgres, а потім розгортайте їх за допомогою MLflow та Model Serving.