便宜判断扫全量：Jev 大数据特征发现

先说结论

• 官方把“AI Map Reduce over Big Data”列为独立用例，核心口径是：100 倍便宜意味着可以处理巨型数据集，并在其中搜索、分类和提取特征。这是官方说法。
• 官方 autoresearch cookbook 展示了一条可复算路径：让 LLM 提议问题，Jev 对每条语料做结构化判断转成数值特征，再训练监督模型，并用误差报告回灌下一轮。
• 工程上通常采用 map-reduce 式分工：模型只做逐条 map 判断，聚合、筛选、训练等 reduce 逻辑交给代码，避免让模型控制流程。
• 按官方定价 $42/十亿输入 token 推算，扫一千万条 200-token 短文，输入成本约 84 美元；这是自己推算，不是官方报价，且未计入输出费用。
• 不适合的场景：语料高度重复、判断需要长链推理、结果必须解释成规则级审计证据。

官方为什么把“大数据”单列

打开官方 use-case map。在“AI Map Reduce over Big Data”一节，官方原文是：

“100x cheaper means you can process giant datasets. Search for relevant information over giant corpuses, classify giant agent traces, and extract features to make predictions.”

这句是官方口径：便宜 100 倍带来的是可对巨型语料做搜索、分类和特征提取。它没有说一定要用某种架构，但把“处理全量”和“成本下降”直接绑定。这个提法与常见“抽样本再泛化”的思路不同：如果单条判断足够便宜，就可以把模型判断当作一种可大规模计算的原始数据，而不是珍贵资源。

官方 cookbook 的 autoresearch loop

第二份一手来源是官方 cookbook：Autoresearch / feature discovery。它的开篇描述是：

“Runs an autoresearch loop that proposes TypeSafe questions, converts free text into numeric features, and uses model errors to improve a supervised CatBoost regressor.”

再往下，它把问题说得更具体：

“TypeSafe questions turn free text into numeric features for a supervised CatBoost model; use an autoresearch loop to discover them.”

也就是说，官方示例把非结构化文本变成 CatBoost 能用的数值表：先由 LLM 提出“问题”——这些问题是结构化判断模板，比如“这款酒是否以果味为主”或“它的单宁强度处于哪个等级”。然后 Jev 对每一行文本回答这些问题，输出为等级、概率或分类。CatBoost 在这些数值特征上训练，并报告哪些问题被实际采用、哪些样本仍然预测错误；下一轮提案调用读这些误差报告，继续建议新问题。这个循环是 autoresearch 的关键。

这里要强调一个混淆点：最终做预测的是 CatBoost，不是 Jev。Jev 的产出是可聚合、可比较的数值列，而不是自然语言结论。

map-reduce 式骨架：模型只 map，代码来 reduce

官方How to build with TypeSafe中有一条原则：

“Ask independent questions together, then compose their answers in code.”

这条原则直接支撑了 map-reduce 式结构。但它没规定你必须用 Spark、Ray 或某个具体批处理框架。工程上常用的一种做法是：把全量语料按批次切分；对每批提交一组相互独立的问题，并行评估；把返回结果落成一张宽表；然后在代码里完成聚合、筛选、训练或者阈值判断。

下面是一个示意片段，不是官方 API 用法，只是结构展示：

# 示意：map-reduce 式特征抽取流程
# map 阶段：模型只回答结构化问题，不决定下一步
for batch in chunks(corpus, batch_size=1000):
    rows = []
    for item in batch:
        # 每个问题独立评估；可并行调用
        features = client.ask(question_set, context=item.text)
        rows.append({"id": item.id, "text": item.text, **features})
    # 结果落表，而不是直接让模型生成总结
    feature_table.append(rows)

# reduce 阶段：完全在代码里
df = load_feature_table()
model = train_model(df, labels)
importance = model.feature_importance()

这个结构的要点是：模型只负责 map 阶段的逐条判断；reduce 交给代码。不要把“该保留哪些特征”“下一步怎么组合”这些控制流放回模型。模型输出一对多列，代码再决定如何使用。这样做的收益是：每个判断可并行、可重算、可审计到单条；错误也更容易定位。这不是官方对 map-reduce 的强制定义，但从官方“独立问题一起问，答案在代码里组合”的原则可以自然得到这种工程形态。

成本量级：官方定价与推算

官方首页在定价区块列出：

“$42 Per Billion input tokens.”

来源：TypeSafe AI。

这是官方数据。下面是我自己的推算，不是官方报价。假设每条语料平均 200 input token，一千万条就是：

10,000,000 × 200 = 2,000,000,000 tokens = 2 billion tokens
2 × $42 = $84

所以只按输入 token 算，扫一千万条 200-token 短文的成本大约是 84 美元。为了更直观，给一组不同平均 token 数的估算：

注意：官方页面只给了 input token 价格，没有写输出 token 价格；所以上述只是输入侧成本，实际总成本可能更高。另外，官方另有“193.6x Faster, 444.6x Cheaper”的对比口径，但那个数字带 * 且基于 System One tasks 的特定 benchmark，不能直接拿来当所有任务的成本系数。建议以官方定价作为下限估算。

什么时候不该这么做

以下判断来自我对官方文档的理解和常见工程实践，不是官方条文。

语料高度重复。如果全量数据里大量文本几乎一样，逐条做结构化判断会浪费大量 token。先去重或聚类，再对代表样本做判断，成本才能降下来。官方 cookbook 里用的是 wine reviews，每条差异较大；如果你的数据重复度高，不要照搬。

判断任务本身需要长链推理。官方 how-to 把 System One 定位为“does not generate code or choose its own next action”，也就是它不擅长自己规划下一步。对需要多步推理、基于中间结果动态调整的复杂判断，不适合拍成一组原子问题。这里“不擅长长链推理”是我的推断，官方没有直接写这个短语。

结果要求可审计到规则级。如果监管或业务方要求“人可读的规则”，例如“因为出现关键词 X 且金额 > Y，所以判定为风险”，那么概率特征这条路就不够。Jev 输出的是概率或等级，对下游预测模型很重要，但它本身不代表一条可解释的规则。你要么把判断结果当作中间特征，要么另建规则层把分数映射回可解释条件。

这次没核实的

• 官方输出 token 价格：给定页面未列出，实际总成本无法从官方来源直接算出。
• 官方是否明确说“Jev 不擅长长链推理”：未找到原文，只在 how-to 里读到“不生成代码、不选择下一步动作”，这是我们把它解释为不适合长链推理。
• 官方 cookbook 中每条语料的平均 token 数：未提供，所以成本推算基于自己假设的 50/200/500 token 三档。
• 官方是否要求使用 map-reduce 框架：未核实；官方只给出“独立问题一起问，代码里组合答案”的原则，工程框架选择不是官方规定。

参考来源

• 官方 use-case map（大数据处理一节）
• 官方 cookbook：Autoresearch / feature discovery
• 官方首页（定价）
• 官方 how to build with System One