汪汪简报

全部新闻

1. 精选深读 · Hugging Face

   NeoMME：一种高效的多模态原生和多语言编码器

   新编码器同时处理多模态与多语言，效率提升或受限于模型规模，适合跨语言检索场景。

   跨语言视觉文档检索团队应把 NeoMME-Retriever 260M 列为首选候选，而不是默认沿用生成式 VLM 检索堆栈；代价是放弃因果解码器的生成能力，并接受多语言长尾与 800M 收益未在材料中量化。

   展开全文收起

   依据

   Hugging Face 团队 Tony Wu 与 Hcompany 的 Aurélien Lac 在 9月3日文章中称，NeoMME 是不带独立预训练视觉塔（vision tower，专门抽取图像特征的视觉编码器）和因果语言模型（causal language model，逐词生成文本的解码器）的多语言多模态编码器。机制上，单一双向 Transformer 同时处理文本 token 与 32×32 图像 patch；预训练用 masked discrete-diffusion（掩码离散扩散，遮住文本 token 后让模型重建），高掩码率迫使模型依赖可见图像证据，而不是语言先验。Retriever 双头一次前向返回 dense（稠密向量）与 late-interaction（后交互，多向量匹配）嵌入。数字上，260M 模型在 NVIDIA L40S、2048×2048 输入下约 51 页/秒，约两倍 ColModernVBERT；分层 token pooling 与非对称量化把后交互索引从约 1.5 MB/页压到 6 kB/页（255× 更小），同时保留 >95% baseline nDCG@10。取舍在于：这适合索引成本敏感的跨语言检索，但材料没有证明 800M 相对 260M 在多语言长尾上的 nDCG@10 增益，不能把吞吐与压缩直接当成检索质量提升。

   • 260M 编码吞吐约 51 页/秒
   • 单页索引存储约 1.5 MB → 6 kB
   • 存储缩减255× 更小
   • nDCG@10 保留>95%

   没写清 材料没给 800M 相对 260M 在跨语言或低资源语言上的 nDCG@10 差值，也没说明 6 kB/页精度保留对应哪个模型尺寸。

   下一步 下一步核对官方 ViDoRe v3 排行榜或技术报告，确认 260M 与 800M 在跨语言子集上的 nDCG@10 和索引大小是否同时公开。

   原文 →

   剪报

2. 精选深读 · Hugging Face

   在100个GRPO步骤中微调350M模型以获得更好的结构化输出

   百步GRPO微调350M模型，效率亮点但需验证任务适用性。

   打算把结构化输出接进下游解析的团队，可先在免费 Colab 上花一次 100 步 GRPO 微调 350M，再决定要不要换更大模型；但 29.7% 的通过率意味着多数请求仍需解析兜底，别撤。

   展开全文收起

   依据

   作者 Leonie Monigatti、Ben Burtenshaw、Sergio Paniego 在 Hugging Face 发布这套配方：用 TRL（Hugging Face 的强化学习训练库）对 LFM2.5-350M 做 GRPO（Group Relative Policy Optimization，组相对策略优化，按同一提示下多条回答的相对好坏给奖励）微调，约 500 条样本、100 步，跑得动免费档 Colab 或 Kaggle GPU；评测走 IFStruct（检验输出能否被解析、是否符合 schema 的基准）。机制上是任务特定微调带来的提升，不是换更大的模型。对照数字：基础模型 452/2000 通过（22.6%），微调后 29.7%；基础模型按格式 JSON 18.0%、YAML 27.2%，按结构 wrapper key 28.5%、bare list 16.6%，最差的 test__recipe 只有 4.3%；平均延迟 1453ms，失败里 7228 次是 required field missing（该给的必填字段没给）。

   • 微调前整体通过率22.6%
   • 微调后整体通过率29.7%
   • 基础模型 JSON18.0%
   • 基础模型 YAML27.2%

   没写清 材料只给微调后的整体 29.7%，没有按 JSON、YAML 或实体类型拆开，所以无法判断哪条支线真的涨了。

   下一步 等作者放出 GRPO 版的 results/ 结果文件，核对 JSON 与 YAML 各自从 18.0% 和 27.2% 涨到多少。

   原文 →

   剪报