1. 文档分类这件事，为什么值得单独拿出来测

文档分类听起来像是个老掉牙的命题，做 NLP 的谁没跑过几个分类模型。但真正落到实际业务里，你会发现事情远没有想象中那么简单。我手头有一批混合了技术文档、产品说明、会议纪要、合同条款、客服工单的文本，量级在几万条左右，格式从纯文本到 Markdown 再到 PDF 提取的乱码都有。之前一直用规则加关键词匹配的方式在扛，准确率勉强维持在七成出头，维护成本却越来越高——每来一批新类型的文档就得重新调规则，调到最后规则文件比代码还长。

这次我决定认真做一次横向对比，把Jev、Laya和DeepSeek三个方案放在同一个测试集上跑一遍。选这三个不是随便挑的：Jev 是最近在文档理解和结构化输出方面讨论度很高的模型，Laya 在分类任务上的轻量化和推理速度有口皆碑，DeepSeek 则是通用能力极强、API 调用生态成熟的代表。我想知道的是，在文档分类这个具体场景下，三者各自的边界在哪里，什么情况下该选谁，以及实际部署时会踩哪些坑。

这篇文章适合两类人看：一类是正在做文档分类、信息抽取相关项目的工程师，另一类是在选型阶段纠结用哪个模型的朋友。我会把测试设计、实操过程、参数选择、踩坑记录全部摊开讲，尽量做到你照着做就能复现。测试用的数据集是我自己整理的，包含 12 个类别、约 8000 条样本，覆盖技术、商务、法律、客服四个大方向。下面从整体设计思路开始拆。

2. 测试方案的整体设计与选型逻辑

2.1 为什么是这三个模型，而不是别的

先说选型逻辑。文档分类任务的核心诉求其实就三个：准确率、推理速度、部署成本。准确率决定了能不能用，速度决定了能不能规模化，成本决定了能不能长期跑。这三个维度上，Jev、Laya、DeepSeek 各有侧重。

Jev 的优势在于它对长文档的理解和结构化输出能力。我试过把一篇五千字的混合格式文档直接丢给它，它能准确识别出文档的层级结构，并且在分类的同时给出分类依据。这对于需要可解释性的场景非常关键——你不仅要知道它分到了哪一类，还要知道为什么。Laya 则是另一种思路，它的模型体积小、推理快，在边缘设备或者资源受限的环境下表现很好。我实测下来，Laya 在同等硬件上的吞吐量大约是 Jev 的三到四倍。DeepSeek 不用多说，通用能力强，API 稳定，生态工具多，但成本和延迟需要仔细算账。

注意：选型时不要只看 benchmark 上的数字。很多模型在公开数据集上分数很高，但换到你的实际数据分布上可能直接掉十几个点。一定要用自己的数据做验证集。

2.2 测试数据集的构建与预处理

数据集这块我花了大概三天时间整理。原始数据来自四个渠道：内部技术 Wiki 导出、客服系统工单记录、合同管理系统归档、以及一部分公开的技术文档。总共 8237 条，去掉重复和过短的之后剩 7912 条。类别分布不太均衡，最多的技术文档类有 2100 多条，最少的法律条款类只有 380 条。这种不均衡在真实场景里很常见，所以我保留了原始分布，没有做上采样。

预处理流程分三步走。第一步是格式清洗，把 HTML 标签、多余空行、乱码字符去掉，PDF 提取的文本还要处理断行和页眉页脚。第二步是长度截断，超过 8000 字符的文档截取前 6000 字符加后 2000 字符，中间用省略标记连接——这个策略是试出来的，直接截前 8000 会丢失结论部分的信息，而文档的结论往往对分类很关键。第三步是标签对齐，把原始的多级标签统一映射到 12 个一级类别上。

import re def clean_document(text): # 去除 HTML 标签 text = re.sub(r'<[^>]+>', '', text) # 合并多余空行 text = re.sub(r'\n{3,}', '\n\n', text) # 去除常见乱码字符 text = re.sub(r'[\x00-\x08\x0b\x0c\x0e-\x1f]', '', text) # 去除页眉页脚模式（如"第 X 页 共 Y 页"） text = re.sub(r'第\s*\d+\s*页\s*共\s*\d+\s*页', '', text) return text.strip() def truncate_document(text, head=6000, tail=2000): if len(text) <= head + tail: return text return text[:head] + '\n...[中间内容省略]...\n' + text[-tail:]

这个截断策略值得展开说一下。我对比过三种方案：纯头部截断、头尾截断、以及按段落重要性采样。纯头部截断在技术文档上表现最差，因为技术文档的核心结论经常在最后。头尾截断比纯头部好了大约 4 个百分点。按段落重要性采样理论上最好，但实现复杂度高，而且需要额外的模型来判断段落重要性，性价比不高。最终选了头尾截断，简单有效。

2.3 评价指标的选择与计算方式

准确率（Accuracy）是最直观的指标，但在类别不均衡的情况下会误导人。所以我同时看了宏平均 F1（Macro-F1）和加权平均 F1（Weighted-F1）。宏平均 F1 对少数类更敏感，能反映模型在小类别上的表现；加权平均 F1 则更贴近整体业务效果。另外我还记录了每个类别的精确率和召回率，方便定位具体问题。

推理速度方面，我测的是单条平均延迟（毫秒）和每秒吞吐量（QPS）。测试环境统一用同一台机器：AMD Ryzen 9 5950X、64GB 内存、NVIDIA RTX 4090。Jev 和 Laya 走本地部署，DeepSeek 走 API 调用。为了公平对比，API 调用的网络延迟单独记录，不混入模型推理时间。

3. 三个方案的核心细节与实操要点

3.1 Jev 的部署与分类流程拆解

Jev 的本地部署比我预想的要顺利。官方提供了 Docker 镜像和 Windows 原生安装包两种方式，我选了 Docker 方案，因为依赖管理更干净。拉取镜像、挂载模型权重、启动服务，整个过程大概二十分钟。需要注意的是显存占用，Jev 的基础版本在 FP16 精度下大约需要 14GB 显存，RTX 4090 的 24GB 显存跑起来绰绰有余，但如果你用的是 12GB 显存的卡，就得考虑量化版本了。

分类流程上，Jev 支持两种模式：零样本分类和少样本微调。零样本模式下，你只需要在 prompt 里列出所有类别和简要说明，它就能直接分类。我实测零样本的 Macro-F1 在 0.78 左右，对于没有标注数据的场景已经可用了。少样本微调则需要准备每个类别至少 50 条标注数据，微调后的 Macro-F1 能到 0.91 以上。微调时间在单卡 4090 上大约 40 分钟，学习率设 2e-5，batch size 设 8，跑 3 个 epoch 就够了。

# Jev 分类调用示例（本地服务模式） import requests import json def classify_with_jev(text, categories): prompt = f"""请将以下文档分类到最合适的类别中。 可选类别：{', '.join(categories)} 文档内容： {text[:4000]} 请只输出类别名称，不要输出其他内容。""" response = requests.post( "http://localhost:8080/v1/classify", json={ "prompt": prompt, "temperature": 0.1, "max_tokens": 32 } ) return response.json()["category"]

这里有个细节值得注意：temperature 一定要设低，我试过 0.7 的时候模型会偶尔"发挥创意"，把技术文档分到"其他"类别去。0.1 到 0.2 之间比较稳。另外 max_tokens 设 32 足够，因为只需要输出类别名称，设大了反而浪费推理时间。

3.2 Laya 的轻量化优势与适用边界

Laya 最大的特点就是轻。模型文件只有 1.2GB，INT8 量化后压到 400MB 左右，在 CPU 上都能跑到 15 QPS 以上。我用 ONNX Runtime 部署的，启动时间不到 3 秒，内存占用峰值 2GB 出头。这对于需要在边缘设备或者低配服务器上跑分类任务的场景来说，吸引力很大。

但轻量化是有代价的。Laya 在短文本分类上表现不错，Macro-F1 能到 0.85 左右，但文档长度超过 3000 字符之后，准确率开始明显下降。我分析原因是它的上下文窗口有限，长文档被截断后丢失了关键信息。另外 Laya 对类别定义的敏感度比较高，如果类别之间的边界模糊，它的表现会明显不如 Jev 和 DeepSeek。

# Laya ONNX 推理示例 import onnxruntime as ort import numpy as np from transformers import AutoTokenizer tokenizer = AutoTokenizer.from_pretrained("laya-classifier") session = ort.InferenceSession("laya_classifier_int8.onnx") def classify_with_laya(text): inputs = tokenizer( text, max_length=512, truncation=True, padding="max_length", return_tensors="np" ) outputs = session.run( None, { "input_ids": inputs["input_ids"].astype(np.int64), "attention_mask": inputs["attention_mask"].astype(np.int64) } ) logits = outputs[0] return int(np.argmax(logits, axis=-1)[0])

Laya 的适用边界很清晰：短文本、类别边界清晰、资源受限。如果你的文档平均长度在 1000 字符以内，类别之间差异明显，而且部署环境没有 GPU，Laya 是性价比最高的选择。反过来，如果文档长、类别细、对准确率要求苛刻，就别为难它了。

3.3 DeepSeek API 调用的成本与效率平衡

DeepSeek 走的是 API 路线，不需要本地部署，调用也简单。但成本这块得算清楚。我用的分类 prompt 平均在 1500 token 左右（包含类别说明和文档内容），输出 10 token 以内。按当前价格算，8000 条文档跑一轮大概花费在几十块钱的量级。如果每天都要跑全量分类，一个月下来成本就得上千了。

效率方面，API 调用的延迟主要受网络和并发限制影响。我实测单条延迟在 800ms 到 1.5s 之间波动，开 10 个并发之后 QPS 能到 8 左右。这个速度对于离线批量分类够用，但如果是实时分类场景，就得考虑加缓存或者用本地模型兜底。

# DeepSeek API 批量分类示例 import asyncio import aiohttp async def classify_batch(texts, categories, api_key, concurrency=10): semaphore = asyncio.Semaphore(concurrency) async def classify_one(session, text): async with semaphore: prompt = f"类别：{', '.join(categories)}\n文档：{text[:3000]}\n类别：" async with session.post( "https://api.deepseek.com/v1/chat/completions", headers={"Authorization": f"Bearer {api_key}"}, json={ "model": "deepseek-chat", "messages": [{"role": "user", "content": prompt}], "temperature": 0.1, "max_tokens": 16 } ) as resp: data = await resp.json() return data["choices"][0]["message"]["content"].strip() async with aiohttp.ClientSession() as session: tasks = [classify_one(session, t) for t in texts] return await asyncio.gather(*tasks)

DeepSeek 的优势在于零部署成本和通用能力强。它的零样本分类 Macro-F1 在 0.83 左右，比 Jev 零样本略低，但比 Laya 在长文档上的表现好很多。如果你的文档类型经常变化、类别定义频繁调整，用 API 方案可以省去重新微调的麻烦。

4. 完整实操过程与关键环节实现

4.1 环境准备与依赖安装

三个方案的环境准备各有各的坑。Jev 的 Docker 方案最省心，但需要提前确认显卡驱动和 CUDA 版本。我遇到过驱动版本太旧导致容器启动后找不到 GPU 的情况，升级驱动到 535 以上就解决了。Laya 的 ONNX Runtime 方案在 Windows 上需要装 VC++ 运行库，Linux 上则要注意 glibc 版本。DeepSeek 最简单，有网络和 API Key 就能跑。

# Jev Docker 部署 docker pull jev/model:latest docker run -d --gpus all -p 8080:8080 \ -v /path/to/models:/models \ jev/model:latest \ --model-path /models/jev-base \ --precision fp16 # Laya ONNX 环境 pip install onnxruntime-gpu transformers numpy # 如果只用 CPU pip install onnxruntime transformers numpy # DeepSeek 依赖 pip install aiohttp asyncio

提示：Jev 的 Docker 镜像比较大（约 8GB），拉取时建议配置国内镜像源加速。Laya 的 ONNX 模型文件需要从官方渠道获取，注意核对文件哈希值，避免下载到损坏的模型。

4.2 分类 Prompt 的设计与调优

Prompt 设计对分类效果的影响比很多人想象的要大。我试过三种 prompt 结构：极简版（只列类别名）、说明版（类别名加一句话描述）、示例版（类别名加描述加一个例子）。极简版在类别名称自解释的情况下够用，但遇到"技术文档"和"产品说明"这种边界模糊的类别就容易出错。说明版加了类别描述之后，Macro-F1 提升了大约 3 个百分点。示例版效果最好，但 prompt 长度增加明显，成本上去了。

最终我用的是一种折中方案：类别名加关键词提示。比如"技术文档：包含 API 说明、架构设计、代码示例等内容"，这样既控制了长度，又给了模型足够的区分信息。另外我发现在 prompt 末尾加一句"如果无法确定，请选择最接近的类别"能减少模型输出"未知"的情况。

4.3 批量推理与结果后处理

批量推理这块，Jev 和 Laya 都支持 batch 输入，DeepSeek 则需要自己控制并发。Jev 的 batch size 设 16 时显存占用约 18GB，设 32 会 OOM，所以 16 是比较稳妥的选择。Laya 的 batch size 可以设大一些，32 甚至 64 都没问题，因为模型本身小。DeepSeek 的并发数我建议控制在 10 到 20 之间，太高了容易触发限流。

结果后处理包括三个步骤：格式规范化（把模型输出的类别名映射到标准标签）、置信度过滤（低于阈值的标记为待人工复核）、以及结果汇总统计。置信度阈值我设的是 0.7，低于这个值的样本大约占 5% 左右，人工复核的成本可以接受。

def postprocess_results(raw_results, label_map, confidence_threshold=0.7): processed = [] for item in raw_results: label = label_map.get(item["raw_label"].strip(), "未知") confidence = item.get("confidence", 1.0) if confidence < confidence_threshold: label = f"待复核:{label}" processed.append({ "text_id": item["text_id"], "label": label, "confidence": confidence }) return processed

4.4 实测数据与对比分析

跑完 7912 条测试样本之后，三个方案的表现如下表所示。Jev 微调版在准确率和 Macro-F1 上都是最高的，但推理速度最慢。Laya 速度最快，但长文档上的召回率明显偏低。DeepSeek 各项指标居中，没有明显短板，但成本是持续性的。

从数据上看，Jev 微调版的优势非常明显，但前提是你得有标注数据。如果标注数据不足，Jev 零样本和 DeepSeek 的差距不大，这时候就要看成本和部署条件了。Laya 在短文本子集上的表现其实不错，我单独测了长度小于 500 字符的样本，Laya 的 Macro-F1 能到 0.88，和 DeepSeek 持平。

5. 常见问题与排查技巧实录

5.1 模型输出不稳定怎么办

这是最常见的问题。同一个文档，跑两次可能得到不同的分类结果。原因通常是 temperature 设高了，或者 prompt 里的类别顺序影响了模型的注意力。解决办法是把 temperature 降到 0.1 以下，并且固定类别列表的顺序。另外我发现在 prompt 里加一句"请严格按照以下类别顺序考虑"也能提升稳定性。

还有一个隐蔽的原因：文档截断位置不同导致的信息差异。如果你的截断策略是随机的（比如按 token 数截断但没对齐段落），同一文档在不同次调用中可能截到不同的内容。解决办法是固定截断策略，确保每次处理同一文档时截取的内容一致。

5.2 类别不均衡导致的偏置问题

我的测试集里法律条款类只有 380 条，模型在这个类别上的召回率明显偏低。Jev 微调版通过调整类别权重缓解了这个问题，具体做法是在损失函数里给少数类更高的权重。Laya 和 DeepSeek 则需要在 prompt 里显式强调少数类的重要性，比如加一句"请注意法律条款类文档数量较少，但同样重要"。

5.3 部署环境相关的坑

Jev 在 Windows 上原生部署时，我遇到过路径中包含中文导致模型加载失败的情况。解决办法是把模型文件放在纯英文路径下。Laya 的 ONNX 模型在 ARM 架构上需要重新编译 ONNX Runtime，直接用 x86 的 wheel 包会报错。DeepSeek 的 API 调用要注意网络稳定性，建议加超时和重试机制。

注意：Jev 的 Docker 容器默认不开启 GPU 支持，需要在启动参数里显式加--gpus all。如果容器启动后推理速度异常慢，先检查 GPU 是否被正确识别。

5.4 成本控制的实操经验

DeepSeek API 的成本控制有几个实用技巧。第一，把类别说明和文档内容分开缓存，相同类别的说明不需要每次重复传输。第二，对于短文档，可以用更小的模型或者本地模型先做粗筛，只把不确定的样本送给 API。第三，批量调用比单条调用更划算，因为可以复用连接和减少 overhead。

我实测下来，用本地 Laya 做粗筛、DeepSeek 做精筛的混合方案，成本能降低大约 60%，而整体准确率只下降不到 2 个百分点。这个方案特别适合文档量大、但对延迟不敏感的场景。

6. 一些实操后的个人体会

跑完这一轮测试，我最大的感受是：没有最好的模型，只有最合适的组合。Jev 在准确率和可解释性上确实强，但部署成本和推理速度是硬伤。Laya 轻快便宜，但长文档和细分类别上力不从心。DeepSeek 通用性好、上手快，但持续调用成本需要认真评估。

如果让我给一个具体的建议：文档平均长度在 1000 字符以内、类别边界清晰、预算有限，直接上 Laya；文档长、类别细、有标注数据、对准确率要求高，Jev 微调是首选；文档类型经常变、不想维护模型、能接受 API 成本，DeepSeek 最省心。混合方案则是兼顾成本和效果的选择，适合有一定工程能力的团队。

最后分享一个小技巧：不管用哪个方案，都建议保留一份人工复核的样本。我每个月会随机抽 200 条分类结果人工检查，一方面能监控模型效果是否漂移，另一方面也能积累新的标注数据用于后续优化。这个习惯帮我提前发现了好几次模型退化的问题。