rag chroma context-1 retrieval ai-agents llm

Chroma Context-1：一款200亿参数的搜索子代理，助力更高效、更精准的代理式RAG系统

Chroma Context-1 是一种用于代理式 RAG 的 200 亿参数搜索子代理，能够自行筛选上下文。它的训练方式、对配套系统的需求以及存在的局限。

发布者：REACTAPP.TOP加入本站 2026年10月28日阅读约 10 分钟2335 词

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

在大多数RAG系统中，信息检索环节是薄弱环节。即便在检索结果之上使用GPT-4、Claude、Gemini或任何先进的模型，如果检索步骤返回了错误信息，这些模型依然会给出看似合理且表述流畅的错误答案。

以法律文件检索为例，某个问题的答案分散在三个文件中，系统需要找到所有相关文件。常见的实现方式是将先进模型置于ReAct循环中，并结合向量搜索工具使用。虽然这种方法可行，但每次查询的成本约为0.12美元，耗时15秒，仅适用于演示，无法作为实际产品功能。Chroma的Context-1正是为解决这一成本与延迟问题而设计的。

Context-1是什么

Context-1是一款拥有200亿参数的语言模型，专为信息检索任务而打造。它不负责生成最终答案或进行通用推理，仅负责执行检索功能。

在典型的智能代理式RAG架构中，一个前沿模型承担所有任务：它决定要搜索什么、执行搜索、判断是否需要进一步搜索，以及撰写答案。这就好比雇用脑外科医生同时还让他去买菜一样。而Context-1则充当专门的搜索子代理，负责查找文档，另一个独立的前沿模型则负责推理和写作。这便是将职责分离理念应用到人工智能架构中的体现。

该模型基于开源基础模型gpt-oss-20B构建，通过监督微调进行训练，随后再利用Chroma的CISPO方法（截断重要性采样策略优化）进行强化学习训练。最终得到的模型体积虽小，但在检索基准测试中的表现却远超其规模所限。

为何普通的智能代理式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 允许模型在判断某些片段无关紧要时将其从自身上下文中删除，这是该工具最突出的功能。

流程轨迹展示了其工作模式：在第一轮中，模型会搜索诸如并购处罚之类的内容，返回八个片段，此时标记计数器显示为32,768个标记中的8,432个；在第二轮中，模型会完整读取一份文档后再进行搜索，随后删除无用的片段，为进一步搜索腾出空间。

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%的时间都能识别出无关的文本片段。这一表现优于Naver Labs的Provence，后者需要专用模型来剪枝句子。而此处，搜索代理在常规工作流程中即可完成剪枝，无需额外模型。

三层架构

Chroma强调——这也是合理的建议——Context-1仅应用于信息检索，而非内容生成。该架构分为三层：数据层、Context-1搜索子代理，以及最上层的前沿推理模型。这种分层设计在四个方面具有优势：

各层可以独立优化，因此你明天就可以更换更优秀的检索器，而无需影响生成部分。
高级型号只能获取经过整理的优质上下文，无法看到原始的搜索结果。
在Nvidia B200硬件上，Context-1每秒可生成400到500个标记，这一速度足以支持多轮搜索。
由于能够获得聚焦的输入材料，该模型能生成更优质的答案。

这依然是微服务架构的原则：不要让一个模型承担所有任务。

训练方式

监督式微调。训练师模型是大型前沿模型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风格的数据集。数据的可靠性源于基于提取的验证机制，即大型语言模型会从文档中抽取引文及对应的线索引文，对它们进行标准化处理，从而确认文本的真实性。每个领域的对齐准确率均超过80%，而且人工审核也仅需对比引文对，无需通读整份文档。

立即试用

共有三种使用方式。

托管API最为简单，因为相关工具已由服务商处理好，不过需要排队等待。

模型权重以Apache 2.0许可证的形式发布在Hugging Face上：

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就如同没有车体的F1引擎。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的窗口大小对于某些任务来说可能仍显不足，工作内存不够用。

它的建议

Context-1 的重要性不仅体现在 Chroma 上。过去两年里，人们的习惯一直是选择预算允许的最大型号，让它处理所有步骤。但 Context-1 表明，在特定任务上，小型专用模型也能与最先进的模型相媲美；而将检索器、推理器和代码生成器等专用组件组合起来，就能构建出运行更快、成本更低，且往往能给出比单一大型模型更好答案的系统。软件领域也曾经历过类似的变革，即大型单体应用被拆分为微服务。单体应用依然可以正常运行，只是那些小型、专注的组件更易于扩展。

对于2026年的RAG构建者而言，关键问题已经发生变化。不必再纠结该用哪种前沿模型来处理所有任务，而应思考哪个专用模型更适合每个处理阶段。目前有200亿参数的模型在检索性能上已能与GPT-5.4和Opus-4.5相媲美，这动摇了营销宣传中“规模越大越好”这一观点。