AI 应用的下一道工程题：怎样选择、检索与验证

我把今天的材料分成三个观察面：使用规模、决策方式和检索输入。它们不是同一条产品路线，也不足以证明某种技术已经胜出；但对准备做 AI 应用的开发者而言，可以借此整理一份更具体的评估清单。

Tibo 在帖子中称，Codex 与 ChatGPT Work 合计活跃用户达到 4000 万。这里应保留“合计”这一口径，不能把数字分别归给两个产品；输入也没有交代活跃用户的统计周期。

我的观察是，用户规模适合用来判断关注方向，却不能代替对具体任务的评估。如果要决定是否采用某个工具，我会先问它能否完成目标工作、失败时如何处理，而不是直接用总体用户数推导质量或生产力收益。

OpenRouter 宣布提供 GPT-6 Luna Decisions，并将其描述为用于模型、工具或动作选择的接口。其公告介绍了文本、JSON 和图像输入，以及带概率信息的类型化返回结果。

对我而言，值得评估的不是“能否返回一个选择”这么简单，而是选择错误会带来什么后果。我会把概率是否可信、是否需要拒绝决策、是否保留人工确认列为测试问题；公告中的接口描述本身还不能回答这些问题。

另一条路线来自 Unsloth。它报告了一项针对 Qwen3.5 0.8B 的本地决策模型训练实验：在三个决策基准上的汇总准确率由 20.7% 提升到 74.3%，并称实验使用了 4GB 显存。

我不会把这个分数直接拿来与托管接口比较。两条材料没有提供统一的测试条件。若考虑本地训练，我会先核对数据划分和复现配置，再用自己的任务检验收益；是否值得投入，还应由错误代价和维护要求决定。

Aravind Srinivas 宣布开放 pplx-embed-v2-late 的权重，介绍了 9B 与 0.6B 两种规模，以及在同一嵌入空间中处理文本和图像的多向量表示。帖子提出用较大模型建立索引、用较小模型在设备端查询，并声称可以不经过 OCR 检索 PDF 页面。

我的关注点是，这种设计是否适合手头的文档，而不是先把“不需要 OCR”视为普遍结论。我会选择包含表格、图示和扫描内容的真实样本，分别检查检索结果与答案依据。如果尝试大小模型分工，也应同时记录索引成本和查询体验，而不只看单一分数。

我更想看到的是可复现的任务结果：决策接口会在哪些情形下选错，本地训练能否在新样本上保持收益，页面检索能否稳定找到正确依据。这些是后续验证方向，不是本次材料已经证实的结论。

月明