Chroma Context-1: 20-миллиардный поисковый субагент для более дешевого и точного агентного 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загружает полный документ по его идентификатору, если какой-либо фрагмент показался перспективным.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 к 1, что способствует избирательности. Это похоже на обучение поисковой собаки: сначала находить любой запах, а затем конкретный.
Пайплайн обработки данных
Одним из самых полезных инструментов, выпущенных Chroma, может быть его пайплайн генерации синтетических данных, размещенный под открытым кодом на GitHub; он служит шаблоном для создания данных для обучения поиску в любой области. Он следует схеме исследование, проверка, расширение:
Seed Topic → Explore Web → Extract Verifiable Facts → Generate Tasks
↓
Add Distractors → Chain Into Multi-Hop → Verify Answers
- Исследование. Начиная с исходной темы, такой как случайный заголовок в Википедии, агент просматривает Интернет и собирает документы, содержащие уникальные, проверяемые факты.
- Генерация заданий. Документы превращаются в подсказки и вопросы, требующие сложного многоэтапного рассуждения, а не простого поиска информации.
- Отвлекающие факторы. Система генерирует отрывки, похожие на правильный ответ, но указывающие в другом направлении, имитируя реальные помехи при поиске.
- Цепочка заданий. Задания одного уровня связываются с помощью одного ответа для формулировки следующего вопроса, что создаёт задачи разной сложности от одного до четырёх уровней.
По умолчанию он поддерживает четыре типа доменов: веб, документы SEC для финансовой сферы, патенты USPTO для юридической работы и электронную почту, используя наборы данных в стиле Enron. Доверие к данным обеспечивается за счёт верификации на основе извлечения информации, при которой ИИ-модели берут цитаты из документов и соответствующие ключевые фрагменты, нормализуют их и подтверждают достоверность текста. Точность согласования превышает 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-запросы для работы с структурированными данными. Он ищет только в документах.
- Он не изучает структуру ваших данных или метаданные, поэтому определение схемы зависит от вашей инфраструктуры.
- Без официального инструмента достижение указанных результатов невозможно, что пока мешает многим командам.
- Окно памяти в 32 КБ, даже с возможностью саморедактирования, может оказаться недостаточным для выполнения некоторых задач.
Что он предлагает
Контекст-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.