AREX Feed Article
Perplexity CEO 汇总七项开源成果，决策模型自报 11 项基准均值 85.71%
10 月 2 日，Perplexity CEO Aravind Srinivas 在 ，用一条清单列出公司的七项「近期」开源贡献：多模态决策模型 pplx-decider-v1-27b、上下文嵌入模型 pplx-embed-v2-context-9b-preview、Apple 芯片本地推理引擎 Lily、端侧个人身份信息（PII）分类器 PII-Tracer 与配套的 PII-TRACE 基准、研究智能体基准 WANDR，以及端点安全工具 Numbat 和 Bumblebee。清单共七个条目，PII-Tracer 所在的那一条同时包含 PII-TRACE 基准。
Srinivas 称 pplx-decider-v1-27b 在 11 项基准上平均 85.7%，「领先 Jev」。这个平均分写在 Perplexity 自己的上：85.71%，对照 Jev 的 84.51% 和微调基座 Qwen3.8-27B 的 74.76%。发帖前一天，已经宣布由该模型驱动的 Decisions API 上线，价格是每百万输入 token 0.04 美元。
决策模型：均值领先 Jev，11 项分项里 6 项落后
模型卡写明，pplx-decider-v1-27b 由 Qwen/Qwen3.8-27B 微调而来，以 Apache-2.0 许可发布，Hugging Face 上的任务标签是 text-classification。它不生成文本：Perplexity 开发者账号的描述是，模型输出的是「对一个固定答案集合的概率分布，而不是文本」。模型卡的示例给出三类用法——在给定候选项之间选择（choice）、返回一句陈述为真的概率（noul），以及把截图作为图片传入。
模型卡附了一张 11 项基准的对照表，把 Jev、Qwen3.8-27B 和 decider 逐行排开。分项看，Jev 在 6 项上分数更高：WinoGrande 90.70% 对 83.30%、BBH 94.27% 对 82.80%、TruthfulQA binary 92.00% 对 85.40%、JevBench public hard 73.27% 对 70.30%、Belebele 95.00% 对 94.00%、JudgeBench 78.57% 对 78.29%。decider 在 4 项上更高，包括 RAGTruth 88.80% 对 77.27%、FinancialPhraseBank 84.18% 对 76.98%、Circa 89.20% 对 84.60%、TabFact 90.60% 对 89.80%；ContractNLI 两项同为 80.78%。按 11 项逐行拆开，「领先 Jev」只在 Overall 一行成立。
Jev 是 TypeSafe AI 的商业决策模型。9 月 29 日提交到 arXiv 的这样描述它：不生成文本，接收状态与类型化问题后，从固定选项里返回一个选择、一个量表位置，或一句陈述为真的概率，也就是所谓「System One」模型。该论文在 37 个数据集上零样本评测了 jev-1.13.0，与 Perplexity 这 11 项面板不是同一套集合。
模型卡注明，pplx-decider-v1-27b 的分数是通过 Perplexity API 测得的。权重虽然开放，本地运行的门槛写在卡里：需要 Python 3.12+ 和一块放得下约 49 GiB 权重及工作内存的 CUDA GPU。
嵌入模型：每个 chunk 的向量要带上整篇文档
9 月 30 日，宣布 pplx-embed-v2-context-9b-preview，称它在 ConTEB 和 turbopuffer 新的 context-bench 上刷新了 SOTA（最优成绩）。同一条帖子写明，context-bench 是 turbopuffer 私有的基准。
把机制写得更具体：一个文档以 chunk（文档分块）列表的形式传入，模型把它们放在一起编码，每个 chunk 的向量因此带有整篇文档的上下文，返回时仍是每个 chunk 一个向量。输出 2048 维，支持 Matryoshka 截断到 1024 维，INT8 量化，平均池化，许可为 MIT。
使用上有两个硬约束。查询和文档必须走不同方法：查询用 encode_queries，文档 chunk 用 encode，模型卡说用 encode 编码查询会「静默降低检索质量」。另外这是 preview 版本，权重、向量和接口都可能变，官方提示不要把这一版产生的向量与未来版本混用。
Lily：只服务一个检查点的 Rust + Metal 引擎
在 9 月 2 日宣布开源 Lily，定位是为 Perplexity Computer 的混合计算（hybrid compute）准备的本地推理引擎，专门服务 Apple 芯片上的 Qwen3.6-35B-A3B。代码放在 的 lily 目录下，许可 Apache-2.0。
Srinivas 帖子里的说法是：Rust 加自写的 Metal kernel，执行路径里没有 PyTorch 也没有 MLX，在 M5 Max 上 prefill（预填充）比 MLX-LM 快 1.23 倍、decode（解码）快 1.35 倍。
仓库里有两份性能报告，把对照版本和上下文长度都标了出来。两份都在 Apple M5 Max（40 核 GPU、128 GB 统一内存）上跑，batch size 1、贪心解码、每个长度取两轮中位数：
- 对 MLX 0.31.2（9 月 1 日报告）：在 256～131,072 token（词元）十个长度上，prefill 比值为 1.125～1.495，decode 比值为 1.257～1.343。
- 对 MLX 0.32.2（9 月 2 日报告）：prefill 比值降到 0.801～1.166，其中 32,768 token 处为 0.991、65,536 处为 0.902、131,072 处为 0.801，长上下文下 MLX 反超；decode 比值为 1.236～1.319。
帖子只写了硬件（M5 Max），没写对照的 MLX 版本和上下文长度；仓库的两份报告显示这两项会改变结论。
Lily 的窄是设计选择，也写在仓库说明里：它只服务一个检查点，即 Qwen3.6-35B-A3B 转成的 MLX affine 4-bit 权重、group size 64；dense 或其他尺寸的 Qwen、BF16、GGUF、AWQ、GPTQ、int8、fp8 一律不支持。运行要求 Apple GPU family 10 或更新（M5 及以后）、macOS 26 或更新、Rust 1.92。HTTP 接口同样被收紧：只接受纯文本消息、max_tokens、stream: false 和一个可选的 prompt_cache_key，采样参数、流式响应、工具调用、多模态输入和投机解码都会被拒绝。
PII-Tracer：0.6B 分类器决定任务留在哪台机器上
Srinivas 对 PII-Tracer 的描述是：一个 0.6B 的端侧 PII 分类器，用来决定一项混合计算任务是否留在用户的 Mac 上执行；他称它在 5 个公开基准上全部胜过 OpenAI 的 Privacy Filter，同一批发布里还有 PII-TRACE 基准。
细节在里。PII-TRACE 于 8 月 31 日提交 arXiv，全名 Tracing Recurring PII Across Conversational Exchanges，共 13,148 段合成多轮对话，覆盖 13 种语言，标注到字符级 span（文本区间）和标识符簇；其中 5,645 段含金标 PII，7,503 段不含 PII。它的评分口径针对一个具体漏洞：同一个标识符在对话里反复出现时，只要漏掉一次提及，这个实体就不算被完整覆盖。论文用两个数字说明这个口径为什么重要：含 PII 的对话里，63.8% 的实体出现多次，28.7% 跨轮出现。
基准的构造方式也写在论文里：把标注过的真实人机对话转成保留类型与位置的模板，逐轮改写但不动占位符，再把占位符替换成同类型实体的替代值并记录精确偏移；改写失败的样本重做，被门槛拦下的文档可以带着新的替代值重新进入合成。
论文给出的结果是：在包括前沿 LLM 在内的 11 个基线上，没有检测器能既做到实体级全覆盖、又不在无 PII 对话上产生大量误报，长对话中单遍读取还会丢掉三分之一的字符。PII-Tracer 用对话级监督训练，实体级覆盖率在所有被评测系统里最高。在 5 个外部基准上，它的字符级 F1 是 ai4privacy 0.950、Nemotron-PII 0.847、SPY 0.585、Gretel PII masking 0.952、TAB 0.594，相同评测下 OpenAI Privacy Filter 依次为 0.907、0.709、0.543、0.895、0.350。
WANDR、Numbat、Bumblebee：一个基准和两个端点安全工具
Srinivas 把 WANDR 描述为「宽而深」的研究智能体基准，500 个任务需要 17 万条有来源支撑的记录。给出的数字是合计 170,495 条必需记录，中位数为每个任务 100 个成员、每个成员 3.00 条记录、每个任务 245 条记录。评分不比对固定答案，而是由任务专用 judge（评判程序）重新抓取被引用的页面，逐条核验提交记录的说法，基准因此能覆盖仍在变化的事实。报告写明基准远未饱和：在高 effort 设置下，最强系统只拿到 0.363 soft F1 和 0.133 hard F1。
报告还按记录级检查项拆解了失败率。六个系统提交的页面里，不可用页面占 3.2%～8.9%，OpenAI 以 23.1% 明显偏离；更大的问题出在抓取之后：33.6%～68.3% 的记录引用了至少不满足一项实质要求的页面，Anthropic 在这一项上最好（33.6%），Perplexity 次之（41.4%）。报告里的 Figure 11 把六个系统在六个失败维度上的比率排成一张表。
在 7 月 29 日由 宣布开源，Srinivas 给出的版本是：面向笔记本和工作站的 agent 检测与响应，52 条规则，单一 Go 二进制覆盖 macOS、Linux 和 Windows。仓库说明里有两处值得注意的默认值：阻断默认关闭，且只对声明 enforce: true 的规则生效，随附规则全部是 monitor-only（只记录不拦截）；检测在本地完成，事件与发现以 NDJSON（逐行 JSON）记录输出，普通输出不含完整原始对话，把原始证据文件加入 case bundle（证物包）需要显式开启。它还能从磁盘上的会话痕迹做取证重建，不需要事先埋点。
是一个只读的开发者端点清点工具，回答的是供应链响应里的一个窄问题：当一份安全公告点名某个包、扩展或版本时，哪些开发机的磁盘元数据里现在能匹配上。它读 lockfile（依赖锁定文件）、包管理器安装元数据、扩展清单和受支持的 MCP JSON 配置，覆盖 npm/pnpm/Yarn/Bun、PyPI、Go modules、RubyGems、Composer、Homebrew，以及 VS Code、Cursor、Windsurf 扩展和 Chromium 系、Firefox 浏览器扩展；单个静态 Go 二进制、零非标准库依赖，不执行 npm ls 之类的包管理器命令，也不读源码文件。MCP 主机配置的 env 块可能带凭据，仓库说明它为了清点服务器会解析这些配置，但不会把其中的值写进记录。
截至 10 月 3 日，Bumblebee 仓库有 5,050 个 star，Numbat 有 1,090 个， 有 288 个。
「近期」两个字，跨度超过四个月
Srinivas 用的词是「近期」，但把清单上的项目按仓库与发布记录排开，时间跨度从 5 月中旬一直到 10 月 1 日：
- 5 月 20 日：Bumblebee 的仓库创建。
- 7 月 14 日：WANDR 的仓库创建；技术报告落款 7 月 16 日，8 月 14 日以 arXiv:2608.14747 发布。
- 7 月 16 日：出现在 Hugging Face。
- 7 月 24 日：Numbat 仓库创建，7 月 29 日官方宣布开源。
- 9 月 2 日：Lily 开源。
- 9 月 13 日：发布。
- 9 月 25 日：pplx-embed-v2-context-9b-preview 的模型仓库创建，9 月 30 日官方发帖。
- 10 月 1 日：pplx-decider-v1-27b 与 Decisions API 上线。
文中这些性能数字，出处都是 Perplexity 自己的公告、模型卡、仓库报告和论文。帖子的最后一句是「还有更多开源贡献很快就会来」，没有给出项目名称、数量或时间表。