返回资讯中心
外部精选
软件工程
#开发者实时流

Besk Tech 发布开源模型 Ru-Jev,可在 CPU 上对调用方提供的选项打分

来源标题:Show HN: Ru-Jev – an open model that scores caller-supplied options on CPU (MIT)

Besk Tech 在 Hugging Face 发布开源文本分类模型 Ru-Jev(besktech/ru-jev),采用 MIT 许可,可在 CPU 上对调用方提供的选项进行打分。模型基于 modernbert,支持俄语、英语及多语言,标签涵盖零样本分类、意图识别与路由等场景。模型卡给出 Transformers 的 pipeline 与 AutoModel 两种加载方式。

Hacker News 最新vladimirbesk2026/11/6 · 今天30 分钟阅读

以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

Like 0 关注 Besk Tech 1 文本分类 Transformers Safetensors 俄语 英语 多语言 modernbert 特征抽取 零样本分类 类型化决策 俄语 路由 意图分类 已校准 校准 本地部署 CPU mmbert text-embeddings-inference arxiv: 2611.08439 许可证:mit 模型卡 文件 文件与版本 xet 社区 1 部署 复制到存储桶 使用此模型 使用 besktech/ru-jev 配合各类库、推理提供商、Notebook 和本地应用的说明。请访问以下链接开始使用。 库 Transformers 如何配合 Transformers 使用 besktech/ru-jev:

使用 pipeline 作为高层辅助工具

from transformers import pipeline pipe = pipeline("text-classification", model="besktech/ru-jev")

pip install -U transformers accelerate

直接加载模型

from transformers import AutoTokenizer, AutoModel tokenizer = AutoTokenizer.from_pretrained("besktech/ru-jev") model = AutoModel.from_pretrained("besktech/ru-jev", device_map="auto") Notebook Google Colab Kaggle Ру-Жев (Ru-Jev) v1.3 自 v1.1 以来的变化 结果 为什么与 v1.1 的大部分对比不得不被丢弃 在相同行、相同选项措辞上测量的六项任务 其余七项任务,每个模型在各自留出的切片上 训练了四个 epoch,发布了第三个 谨慎命名你的选项 拒绝给出答案 局限性 CPU 上的速度 用法 训练数据 引用 许可证 Ру-Жев (Ru-Jev) v1.3 不要使用标准的零样本 pipeline。调用 pipeline("zero-shot-classification", model="besktech/ru-jev") 既不会失败也不会 正常工作:它返回的是来自随机初始化头的数字,而且这些数字在 每次加载时都会变化。请使用下面的代码片段加载模型。 开放的、俄语优先的类型化决策模型。它不生成文本。给定一个 上下文和一组候选选项,它返回选项上的校准概率并挑选一个。它覆盖三种 决策形态:是/否、从选项中选择,以及序数量表。它是一个紧凑的编码器(mmBERT-base,307M),因此 可以在 CPU 上运行,并可部署在封闭边界内。 更早的版本保留在分支上:v1.1 和 v1。如果你依赖其精确行为,请使用 revision="v1.1" 加载。 推理小部件被故意关闭,标准 pipeline 也无法 工作。这是一个骨干网络加上单独的评分头,不是标准的 序列分类检查点。每个标准 pipeline 都会通过 AutoModelForSequenceClassification 加载检查点, 这会悄悄初始化一个新的头而不是加载 head.safetensors,然后用它进行评分。在 下面的示例中,标准零样本 pipeline 在正确选项上最多给出 0.44,而此模型给出 0.95, 并且在相同代码的三次加载中,它有两次给出了不同的首选选项。请使用下面的代码片段。 与 TypeSafe AI 无关。未在 Jev 输出上训练。Ru-Jev 是一个 独立构建的 Jev 类类型化决策模型:评分头从随机初始化开始训练, mmBERT-base 骨干网络与之一起微调,仅使用开放的人工标注数据集。在任何时候都没有调用、 蒸馏或使用封闭决策 API 作为标签来源。名称是对该类别的戏仿, 并非兼容性或背书的声明。 自 v1.1 以来的变化 v1.1 读取选项文本,这是设计的要点,但它读取的范围很窄。 它学会了训练数据中使用的精确措辞。重命名一个 类别,准确率就会断崖式下跌。一个名为 погода 的场景在 0.956 的情况下被正确路由, 而同一个场景名为 вэзер 时只有 0.633。更糟的是, 置信度并没有随之下降:在术语措辞上,v1.1 仍报告 0.754 的平均置信度,而准确率为 0.633,差距为 0.121, 而 v1.3 的差距为 0.030。概率恰好在调用者最需要的地方停止了携带信息。 v1.3 将每个固定选项集以多种措辞发布,每个示例抽取一种, 因此模型必须读取选项而不是识别它。对于路由 任务,这包括用西里尔字母书写的英语键及其截断形式,由规则生成。 然后用相同的 1,000 个路由问题反复提问,仅改变标签 措辞,其他不变。报告了两种候选集大小,因为 差距以不同方式取决于大小,对于不同词汇表,仅在一种大小上探测 可能会误述效果:从十八个类别中抽取五个候选,这是本卡片早期版本报告的方式,以及 一次性全部十八个候选。随机概率为 0.20 和 0.056。 前两行是对照,不是结果。俄语单词和 英语键是两个版本都训练过的措辞:它们的基准词汇 就是训练风格本身,取自数据构建器中的同一张表。这两行测量的是已训练形式的召回率,接近零的差距 正是对照应该显示的。俄语短语是 v1.3 的训练风格 而非 v1.1 的,因此其差距在构造上是预期的,也不是鲁棒性的证据。 只有标记为留出的行才能说明泛化能力。 关于留出行有两点注意事项。意图键以其场景名称开头, 因此十八个术语标签中有三个与转写规则产生的结果重合,并作为第一个词进入训练;干净切片丢弃那 三个,严格切片丢弃任何与训练选项有精确或前缀关系的标签。规则没有针对此测试词汇进行调整, 而且该词汇是两者中较旧的:它在规则之前六小时 三十四分钟被提交。不同切片的数字测量不同的标签集,因此一个永远不应放在另一个旁边。 增强帮助了什么。以多种表面形式训练标签 有助于由单词组成的留出措辞,无论是普通词还是借词,包括 训练中从未出现过的词类:术语获得 +0.235,五个

(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →