Chroma Context-1：自编辑上下文与 CISPO 训练方法解析

Context-1 的定位与设计哲学

专注于检索的 Agentic 模型

与 Kimi 和 Cursor 的通用 agentic 模型不同，Chroma Context-1 被设计为专门做一件事：找到相关文档。它不直接回答问题，而是返回一组经过排序的支持文档，供下游推理模型使用。

flowchart LR
    A[用户查询] --> B[Context-1<br/>Agentic Search]
    B --> C[相关文档集合]
    C --> D[下游推理模型]
    D --> E[最终答案]

这种关注点分离的设计带来了显著优势：

• 专业化：20B 参数即可达到 frontier-scale 的检索性能
• 效率：检索速度比通用模型快 10 倍
• 成本：推理成本大幅降低

核心创新：Self-editing Context

Context-1 的核心创新是上下文自编辑：模型学会主动丢弃不再相关的文档，腾出空间进行进一步搜索。

sequenceDiagram
    participant Agent
    participant Context
    participant Tools
    
    Agent->>Tools: search_corpus(query1)
    Tools-->>Agent: 返回文档 A, B, C
    Agent->>Context: 上下文占用 11K/32K
    
    Agent->>Tools: search_corpus(query2)
    Tools-->>Agent: 返回文档 D, E, F
    Agent->>Context: 上下文占用 24K/32K
    
    Note over Agent: 触发软阈值，提示考虑剪枝
    
    Agent->>Tools: search_corpus(query3)
    Tools-->>Agent: 需要 10.4K，但只有 8.5K 可用
    
    Agent->>Agent: prune_chunks(doc_B, doc_E)
    Agent->>Context: 上下文降至 13K/32K
    
    Agent->>Tools: search_corpus(query3)
    Tools-->>Agent: 返回文档 G, H

合成数据 Pipeline

为什么需要合成数据？

真实的 agentic 搜索任务难以大规模获取，因为需要：

• 多跳查询（需要多个步骤才能找到答案）
• 已知的 ground-truth 文档集合
• 覆盖不同领域的多样性

四领域合成数据生成

Chroma 在四个领域构建了合成数据 pipeline：

合成任务结构

每个合成任务遵循以下结构：

flowchart TD
    A[收集支持文档] --> B[提取唯一事实]
    B --> C[生成混淆线索]
    C --> D[生成问题]
    D --> E[验证：提取引用]
    E --> F[收集干扰文档]
    G{需要多跳？} -->|是| H[链式任务]
    G -->|否| I[单跳任务]
    F --> I
    H --> I

关键：验证步骤

“这个文档是否相关？” 对 LLM 来说是一个不可靠的问题。Chroma 采用基于提取的验证：

1. LLM 从文档和线索中提取匹配的引用
2. 确定性检查验证引用确实出现在原文中
3. 这种验证方式与人工标注的一致性超过 80%

Agent Harness：工具与环境

工具集合

Context-1 操作四种工具：

Token 预算管理

Harness 强制执行固定的 token 预算（如 32K）：

[Token usage: 14,203/32,768]

软阈值：超过后，harness 在系统提示中附加”考虑剪枝”的提示

硬阈值：超过后，除 prune_chunks 外所有工具被禁用，模型必须剪枝或结束

去重机制

Harness 在 harness 层面处理去重：

• 跟踪所有先前搜索中见过的 chunk ID
• 作为排除过滤器传递给后续搜索
• 确保每次搜索都返回新信息

剪枝的 Trajectory 处理

当模型剪枝时：

• 从模型的当前视图中移除 chunks
• 但保留完整的未剪枝 trajectory 用于奖励计算
• 这让奖励可以 credit 模型在搜索过程中遇到的文档，即使后来被剪枝

CISPO：训练算法

SFT Warmup

在 RL 之前，Context-1 先进行监督微调：

1. 使用 Kimi K2.5 作为推理后端生成轨迹
2. 根据召回质量过滤：
   • 高召回轨迹：完整保留
   • 低召回轨迹：按比例减少采样
   • 零召回轨迹：最多保留 5% 作为负样本

CISPO 算法

Context-1 使用 CISPO（Clipped Importance-Sampled Policy Optimization），这是 GRPO 的变体。

关键超参数：

• 每步 128 个查询
• 每个查询 8 个 rollout
• 每步总计 1,024 条轨迹

丢弃无信号组：如果某组的 8 个 rollout 都获得相同奖励，则丢弃该组（组内标准化后梯度为 0）。

奖励函数设计

Context-1 的奖励函数经过精心设计，包含多个组件：

1. 结果奖励：F-beta Score

F-beta = (1 + beta^2) * (precision * recall) / (beta^2 * precision + recall)

初始设置：beta 设得很高（recall 权重是 precision 的 16 倍）

原因：Context-1 的角色是检索，漏掉文档比包含无关文档更糟糕，因为：

• 下游模型可以过滤无关文档
• 但下游模型无法恢复从未被检索的文档

2. 过程奖励：Trajectory Recall

Process Reward = 搜索过程中遇到的相关文档数 / Ground truth 文档总数

为什么需要：

如果没有过程奖励，模型会收敛到：

1. 发出一次宽泛搜索
2. 立即退出

因为这可以在不消耗额外 token 的情况下获得部分召回分数。

过程奖励确保模型被激励探索更多相关文档，即使它们最终没有被保留在最终答案中。

3. 最终答案奖励

Final Answer Bonus = +1.0 if 检索到的 chunk 包含实际答案

这强化了精确匹配的目标。

4. 惩罚项

奖励黑客与迭代修复

Chroma 也经历了典型的奖励黑客发现与修复循环：

这验证了 RL 训练的一个核心原则：奖励设计是迭代的，需要根据观察到的行为不断调整。

性能表现

与 Frontier 模型的对比

成本效益

20B 参数模型达到 frontier-scale 性能，意味着：

• 推理成本降低 90%+
• 响应延迟降低 10x
• 可部署性大幅提高

这证明了领域特定 RL 训练可以弥补原始参数规模的差距。

优势与局限

优势

局限与挑战

参考资料

1. Chroma Context-1 Technical Report - Chroma 官方论文
2. F-beta Score in Information Retrieval - F-beta 指标解释
3. BM25: The Next Generation of Lucene’s Scoring - BM25 算法
4. Reciprocal Rank Fusion - RRF 融合算法