# Categary Classify Model: Jev vs DeepSeek vs Laya, 文档分类实测
## 一、背景

**Jev 最近很火。** 它是 TypeSafe 推出的 **System One 决策模型**:不像生成式大模型那样"写一段话",而是给它一段文本和若干候选类别,**一次前向就直接返回一个结构化的选择 + 一个校准过的置信度**,不生成自由文本。它主打的,正是生成式 LLM 拿来做判断时的两个老痛点——

1. **输出要解析**:生成式模型返回一段话或 JSON,得写代码解析,还可能格式出错。
2. **不知道有多确定**:它说"这是合同",但到底九成把握还是随口一说?生成式模型给不出可靠概率。

Jev 用"结构化返回 + 原生校准概率"把这两点一起解决,因此最近作为一种新的模型范式受到不少关注。

**Jev 的能力矩阵——三种"问题原语"(Primitive):**

| 能力 | 干什么 | 返回什么 | 典型用途 |
|---|---|---|---|
| **Choice(选择)** | 从一组候选里选出一个 | 选中项 + 每个选项的概率 + 置信度 | **分类**、路由、意图识别 |
| **Score(打分)** | 按有序等级给内容打分 | 分值 + 每个等级的概率 + 置信度 | 质量 / 风险 / 优先级评分 |
| **Noul(判定)** | 回答一个是/否问题 | "是"的概率(校准过) | 合规、护栏、触发条件判断 |

三者可以在**一次调用里同时问**(例如给一封工单同时问"分到哪个部门 / 有多紧急 / 是否要求退款")。本文只用到其中的 **Choice**——因为文档分类就是"从若干类别里选一个"。

**AI Knowledge(RAG / Embedding)是它的一个典型应用。** 在这类场景(如腾讯 IMA、WorkBuddy 的资料库),很多业务都要先做"文档分类":一封邮件是投诉、咨询还是账单?一份 PDF 是发票、合同还是简历?尤其当数据量较大(亿级以上)时,数据一般要**先归类、再查询**。

**举个例子(为什么"先分类再查询"更省):**

> 设一个 **1 亿(1e8)** 文档的向量库,均匀分成 **20 个类目**,平均每类约 **500 万**。
>
> - **不分类**:每次查询都要在全部 1 亿向量里做近邻检索。
> - **先分类**:先判定这条 query / 文档属于哪个类目(或 Top-2),只在对应子库里检索。
>   扫描规模从 **1 亿 → 约 500 万(Top-1)/ 1000 万(Top-2)**,即**降到 1/20 ~ 1/10**。
>
> 结果:候选向量少一个数量级 → **查询时延更低、CPU/内存/显存占用更省**,还能按类目分片扩容。
> 而"分类"这一步越准、越快、越便宜,整条链路的收益就越大——**这正是我们要评测分类模型的原因**。

过去大家习惯用生成式大模型(LLM)来做分类——让它"输出一个类别名",但正是前面说的那两个老问题让它不够顺手。**紧接着,Jev 的开源竞品 Laya 也很快上线了。** Laya 同样是非生成的决策模型、用法和 Jev 几乎一模一样,但**开源、可本地部署**——决策模型从此不止"云 API"一条路。

**我们再拉上大家最熟悉的生成式模型 DeepSeek 做对照。** 三方正好覆盖两条技术路线:**决策模型(Jev、Laya)vs 生成式模型(DeepSeek)**。

于是这次要回答一个很实际的问题:**在真实的中英文文档分类任务上,它们到底谁更准、谁更快、谁更靠谱?**

---

## 二、三个模型是什么,区别在哪

| 维度 | **Jev** | **DeepSeek** | **Laya** |
|---|---|---|---|
| 出品方 | TypeSafe | DeepSeek | Convai Innovations(开源) |
| 类型 | 托管**决策模型**(非生成) | 托管**生成式大模型** | 本地**决策模型**(非生成) |
| 本次版本 | `jev-1.13.0` | `deepseek-flash` | `convaiinnovations/laya`(英)+ `laya-multilingual`(多语言) |
| 输出形式 | 原生"选择/是否/打分" + 校准置信度 | 生成文本(需约定成 JSON) | 原生 typed decision + 校准置信度 |
| 要不要解析结果 | 不用,结构化返回 | 要,解析 JSON,可能格式出错 | 不用,结构化返回 |
| 部署方式 | 云 API | 云 API | **本地**(自备硬件,开源权重) |
| 多语言处理 | 单模型多语言 | 单模型多语言 | 英文 / 多语言**分两个 checkpoint,自动按语言路由** |
| 计费方式 | 按调用 | 按 token | 自持硬件摊销(无 API 费) |

---

## 三、测试方案

**范围:只测 Decision-only(纯文本分类)。** 输入是已经准备好的文本,输出是类别。
不含 OCR、PDF 解析等前置环节——我们只比"模型判断"这一步,避免链路噪声干扰结论。

**两条独立的评价轴:**

1. **质量**:分类分得准不准。
2. **延迟**:一次判断要多久。

**中英文分开测、分开报告**,不做加权平均——因为业务往往对某一种语言更敏感。

**核心公平原则:**

- 每篇文档**每个模型只判一次**(不反复调用挑最好结果)。
- 三个模型看到**完全相同的输入、相同的类别、相同的类别顺序**。


---

## 四、数据集介绍

我们各选了一个**规模大、贴近真实**的公开数据集,一中一英,类别数接近(便于横向看难度)。

### 英文:DBpedia-14

- **内容**:维基百科词条摘要,判断它描述的是哪一类实体。
- **规模**:约 56 万训练 / 7 万测试。
- **下载**:HuggingFace [`fancyzhx/dbpedia_14`](https://huggingface.co/datasets/fancyzhx/dbpedia_14)(本次用 test split 的 parquet)。
- **14 个类别**:公司、教育机构、艺术家、运动员、政治人物、交通工具、建筑、自然地貌、村庄、动物、植物、专辑、电影、著作。
- **文本长度**:每条为词条摘要,**中位数约 256 个字符**(约 1–3 句)。
- **特点**:文本较长、类别区分度高,属于"相对容易"的分类。
- **样例**(标签 → 文本):
  - `公司` → "inContact Inc. (NASDAQ: SAAS) is a provider of on-demand contact center software."
  - `动物` → "Hastula tenera is a species of sea snail a marine gastropod mollusk in the family Terebridae the auger snails."

### 中文:THUCNews

- **内容**:新闻**正文全文**,判断它属于哪个频道。
- **规模**:清华 THUCNews 语料;本次用其 10 类版本,验证集每类约 500 条。
- **下载**:本次用 HuggingFace [`seamew/THUCNewsText`](https://huggingface.co/datasets/seamew/THUCNewsText)(长正文版);原始语料见清华 [THUCTC](http://thuctc.thunlp.org/)。
- **10 个类别**:教育、娱乐、时尚、财经、游戏、时政、社会、体育、股票、科技。
- **文本长度**:完整正文,**中位数约 700 个字符**(超长的截断到 2000 字)。
- **样例**(标签 → 文本节选):
  - `体育` → "首战后，两队都找准了对方阵中的防守焦点，绿衫军的焦点是德维恩-韦德，热火则着眼于阿伦。但阿伦受限程度远大于韦德…"
  - `财经` → "全国政协委员钟晓渝日前建议，应进一步规范基金信息披露，涉及基金信息披露的相关法规制度应进一步细化、简化、具体化…"

### 本次抽样

为快速出结论,做了有限规模抽样(可一键放大):每个数据集**每类 100 条**做分类测试。

---

## 五、三个模型的接口 Demo

同一个任务"把这段文本分到 invoice / contract / bank_statement 之一",三家的调用方式如下。

### Jev(REST API)

```bash
curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" -H "Content-Type: application/json" \
  -d '{
    "state": "Your monthly bank statement is ready...",
    "model": "jev-1.13.0",
    "questions": {
      "doc_class": {
        "type": "choice",
        "instructions": "Classify this document.",
        "criteria": {
          "invoice": "A bill requesting payment",
          "contract": "A legal agreement",
          "bank_statement": "A periodic account statement"
        }
      }
    }
  }'
# 返回:直接给结构化结果,含每个类别的概率和置信度
# {"answers":{"doc_class":{"choice":"bank_statement","confidence":1.0,
#   "probabilities":{"bank_statement":1.0,"contract":0.0,"invoice":0.0}}}}
```

### DeepSeek(生成式,约束成 JSON)

```bash
curl -X POST https://api.deepseek.com/chat/completions \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-flash",
    "temperature": 0, "max_tokens": 64,
    "thinking": {"type": "disabled"},
    "response_format": {"type": "json_object"},
    "messages": [
      {"role":"system","content":"Categories:\n- invoice: A bill\n- contract: A legal agreement\n- bank_statement: A statement\nRespond ONLY as {\"label_id\":\"..\",\"is_oos\":false,\"confidence\":0.0}"},
      {"role":"user","content":"Your monthly bank statement is ready..."}
    ]
  }'
# 返回:一段需要你自己解析的 JSON 文本
# content = {"label_id":"bank_statement","is_oos":false,"confidence":0.95}
```

> ⚠️ **实测踩坑**:`deepseek-flash` 默认会"思考",若不关闭,64 个 token 全被推理吃光、
> 返回**空 JSON**。必须加 `"thinking":{"type":"disabled"}`。

### Laya(本地,pip 安装)

```python
pip install laya

from laya import Router
router = Router(preload=True)          # 预加载权重,首次会下载模型

questions = {
    "doc_class": {
        "type": "choice",
        "instructions": "Classify this document.",
        "criteria": {
            "invoice": "A bill requesting payment",
            "contract": "A legal agreement",
            "bank_statement": "A periodic account statement",
        },
    }
}
res = router.predict("Your monthly bank statement is ready...", questions)
res["answers"]["doc_class"]["choice"]   # -> "bank_statement"
res["routing"]["model"]                 # -> "english"(自动按语言选了英文 checkpoint)
```

> 可以看到:**Jev 和 Laya 的"问题格式"几乎一模一样**(choice + criteria),
> 差别只是一个走云 API、一个本地跑;DeepSeek 则要靠 prompt 约束 + 事后解析。

---

## 六、验证规则

**分类准确率**:模型选的类别 == 正确答案,即为对。反映"分类器本身准不准"。

**延迟**:客户端计时,报 p50/p95/p99。无预热、连接复用。
托管模型(Jev/DeepSeek)含网络往返;本地模型(Laya)无网络,两者分开列,不混比。

---

## 七、测试结果

### 1)分类准确率(越高越好)

> 样本:每类 100 条(DBpedia 1100 条 / THUCNews 700 条,每模型各判一次)。

| 数据集 | 语言 | Jev | DeepSeek | Laya |
|---|---|---:|---:|---:|
| DBpedia-14 | 英文 | **99.3%** | 99.0% | 92.6% |
| THUCNews | 中文 | 84.1% | **85.3%** | 72.8% |

- **英文:Jev ≈ DeepSeek(均 ~99%),几乎并列封顶**;Laya 略低但也有 92.6%,三家都很能打。
- **中文长文本:DeepSeek(85.3%)≈ Jev(84.1%),Laya(72.8%)偏低。** 长正文下三家都达到可用水平,和英文的差距明显收窄。
- **Laya 是三家里最弱的,但差距不大**;它的优势在延迟和可本地部署(见下)。

### 2)延迟

**托管 API(含网络往返,并发 1,按输入长度):**
| 模型 | 输入长度 | p50 | p95 |
|---|---|---:|---:|
| Jev | 128 tokens | 278ms | 331ms |
| Jev | 512 tokens | 273ms | 342ms |
| Jev | 1024 tokens | 280ms | 327ms |
| DeepSeek | 128 tokens | 616ms | 968ms |
| DeepSeek | 512 tokens | 670ms | 914ms |
| DeepSeek | 1024 tokens | 658ms | 994ms |

并发拉到 8 时吞吐:Jev ~18/s、DeepSeek ~10/s。

**Laya(本地,单流,按输入长度):**
| 模型 | 输入长度 | p50 | 吞吐 |
|---|---|---:|---:|
| Laya | 128 tokens | 97ms | 10/s |
| Laya | 512 tokens | 172ms | 5.8/s |
| Laya | 1024 tokens | 171ms | 5.8/s |

- **Jev、DeepSeek 对输入长度基本不敏感**(128→1024 几乎持平)——托管模型单次耗时主要花在网络往返和固定推理上;**Jev 比 DeepSeek 快约 2.3 倍**。
- **Laya 本地单次最快(~100ms)**,没有网络开销;但**随文本变长而变慢**(真实的本地 encoder 计算,128→512 后翻倍)。
- 说明:我们的测试机离云服务较远,Jev 的 ~275ms 里很大一部分是网络;TypeSafe 官方近服务端的数字约 138ms。所以"托管"和"本地"两张表不直接横比。

**网络往返占多少?** 我们从测试机对两个 API 端点发轻量请求(GET `/models`,连接复用后)实测往返:

| 端点 | 轻量请求往返(warm) | 首次(含 TLS 握手) |
|---|---:|---:|
| TypeSafe(Jev) | ~200ms | ~650ms |
| DeepSeek | ~100ms | ~160ms |

据此拆分分类请求的耗时构成:

- **Jev**:~275ms 里,**网络往返占大头(~140–200ms)**,真正的模型推理很小(TypeSafe 官方近服务端约 138ms)——**Jev 的"慢"几乎全来自网络**。
- **DeepSeek**:~650ms 里网络往返仅约 100ms(~15%),其余 ~550ms 是服务端生成 JSON——**DeepSeek 的"慢"主要慢在生成**。
- 含义:若都贴近服务端部署,Jev 与 DeepSeek 的**推理速度差距会比这里的 2.3× 更大**(Jev 本身就是一次快速前向)。

**扣除网络往返后的推算(近服务端纯推理 p50):**

| 模型 | 观测 p50 | 减去网络往返 | ≈ 推算纯推理 p50 |
|---|---:|---:|---:|
| Jev | ~275ms | ~200ms | **~75ms**(官方近服务端 ~138ms 可交叉参考) |
| DeepSeek | ~650ms | ~100ms | **~550ms** |

- 这是**粗略推算**:网络地板用上面 GET `/models` 的 warm 往返近似,存在测量噪声;Jev 取"我们的减法 ~75ms"与"TypeSafe 官方 ~138ms"两个口径,真实值应在两者之间。
- 结论不变且更强:**近服务端下 Jev 纯推理约是 DeepSeek 的 1/7 ~ 1/4(即快 4~7 倍)**,远大于含网络时观测到的 2.3 倍。

### 3)消费(API 成本 —— Laya 本地模型不做对照)

先看**实测 token 用量**(每篇平均):

| 模型 | 数据集 | 输入 tok/篇 | 输出 tok/篇 |
|---|---|---:|---:|
| Jev | DBpedia(英) | 791 | 159(免费) |
| Jev | THUCNews(中) | 1622 | 124(免费) |
| DeepSeek | DBpedia(英) | 342 | 26 |
| DeepSeek | THUCNews(中) | 773 | 27 |

计费口径(官网价):

- **Jev**:**只按输入 token 收费,输出免费**,`$0.042 / 1M 输入 token`(无峰谷)。
- **DeepSeek(deepseek-flash)**:输入(cache miss)`$0.15 / 1M`、输出 `$0.6 / 1M`(off-peak 价;峰时翻倍)。

**换算成每 1000 篇文档的成本(off-peak):**

| 模型 | DBpedia(英) | THUCNews(中) |
|---|---:|---:|
| **Jev** | **$0.033** | **$0.068** |
| DeepSeek | $0.067 | $0.132 |

- **Jev 每千篇成本约为 DeepSeek 的一半**(off-peak)。DeepSeek 峰时价格翻倍,而 Jev 无峰谷,峰时差距拉大到约 **4 倍**。
- 有意思的是:**Jev 消耗的 token 更多**(输入约 2 倍,还额外输出每个类别的概率),但仍更便宜——因为它输入单价低约 3.6 倍、且**输出免费**。
- DeepSeek 若命中 system prompt 的上下文缓存(cache hit,输入 `$0.003/1M`),输入成本会进一步降低;上表按 cache miss 保守估算。
- **Laya 是本地模型,无 API 费用**(只有自持硬件 + 电费摊销),不与云端 API 成本直接对照。

---

## 八、最终结论

| | 英文 | 中文(长文本) |
|---|---|---|
| **分类质量最好** | Jev ≈ DeepSeek(~99%) | DeepSeek ≈ Jev(85/84%) |
| **速度最快** | Laya 本地(~100ms) | Laya 本地 |
| **API 成本更低** | Jev(约 DeepSeek 一半) | Jev(约 DeepSeek 一半) |

- **Jev —— 综合最强。** 英文与 DeepSeek 并列封顶(99.3%),中文长文本(84.1%)与 DeepSeek 基本持平;结构化返回、无需解析,原生带校准置信度。适合看重"准确 + 可信度 + 少运维"的场景。代价是托管延迟受网络影响。
- **DeepSeek —— 质量能打,但更重。** 分类质量与 Jev 持平甚至微弱领先(中文长文本 85.3%),但慢约 2.3 倍、需自己约束 JSON 并解析(还有"关思考"这个坑)。适合已在用它、不想引入新服务的团队。
- **Laya —— 潜力股,可本地部署。** 开源、单次最快、数据不出门;英文 92.6%、中文长文本 72.8%,均可用,虽是三家最低但差距不大。需要自己维护环境和调参。适合有本地部署诉求、愿意投入调参的团队。



Jev 最近很火。 它是 TypeSafe 推出的 System One 决策模型:不像生成式大模型那样"写一段话",而是给它一段文本和若干候选类别,一次前向就直接返回一个结构化的选择 + 一个校准过的置信度,不生成自由文本。它主打的,正是生成式 LLM 拿来做判断时的两个老痛点——

Jev 文档分类实测：vs Laya & DeepSeek

Categary Classify Model: Jev vs DeepSeek vs Laya, 文档分类实测

人工智能

算法

开发工具

实测Jev、DeepSeek、Laya三款模型在中英文文档分类任务中的表现：英文场景Jev与DeepSeek准确率均达99%，中文长文本两者持平（84-85%），Laya略低但可本地部署。Jev结构化输出免解析、成本仅为DeepSeek一半，DeepSeek延迟高2.3倍且需JSON解析，Laya单次最快但需自持硬件调参。

代码解释

WorkBuddy 

DeepSeek

路由

JSON

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

实测Jev、DeepSeek、Laya三款模型在中英文文档分类任务中的表现：英文场景Jev与DeepSeek准确率均达99%，中文长文本两者持平（84-85%），Laya略低但可本地部署。Jev结构化输出免解析、成本仅为DeepSeek一半，DeepSeek延迟高2.3倍且需JSON解析，Laya单次最快但需自持硬件调...

Jev 文档分类实测：vs Laya & DeepSeek-腾讯云开发者社区-腾讯云

Jev 文档分类实测：vs Laya & DeepSeek

Jev 文档分类实测：vs Laya & DeepSeek

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐