这次我们来看一个偏研究但工程落地价值很明显的 NLP 方向用级联无监督-监督 Pipeline 检测公共采购文本中的指责性语言。项目标题直译过来就是“用于检测公共采购中指责性语言的级联无监督-监督 NLP 流水线”。核心要解决的问题很简单在海量招投标文件、供应商质疑函、评标报告、审计底稿里自动找出那些带有指责、归责、指控色彩的句子。这类文本在采购合规、审计风控、投诉处理场景中非常多人工筛选成本极高直接上监督模型又面临标注数据不足的问题。级联架构的价值就在于先用无监督的语义聚类做“粗召回”把疑似指责的句子从几十万条文本中捞出来再用一个小规模监督模型做“精判”。整体兼顾了召回率、准确率和标注成本。文章会按数据准备、无监督阶段、监督阶段、级联编排、API 封装、批量推理的顺序把整套方案完整拆开讲。适合三类读者做 NLP 文本分类的算法工程师需要采购文本风险扫描的审计信息化研发以及研究弱监督文本分类方向的学生。下面直接进入实现。1. 核心能力速览能力项说明任务类型文本分类 / 话语行为识别核心架构级联Cascaded无监督粗筛 监督精判主要输入招投标文件、质疑投诉函、评标报告、审计底稿、会议纪要核心输出句子级是否包含指责性语言以及指责对象、严重程度可选标注依赖小规模人工标注即可无监督阶段用于辅助构建候选集推荐硬件训练阶段建议 8GB 显存以上的 GPU推理阶段 CPU 可运行接口能力可封装为 REST API 服务批量任务支持 CSV / JSON 输入批量推理适用场景采购风险预警、供应商投诉自动分流、审计文本扫描注意这里的显存要求是按 bert-base 级别的分类模型给出的通用建议。如果你换成更大的模型或者把输入句子拼得非常长显存占用会明显上涨部署前需要按实际模型和 batch size 做压测。2. 项目背景公共采购里的“指责性语言”到底是什么公共采购流程会产生大量文本。从招标公告、资格预审文件、投标文件到评标报告、质疑函、投诉处理决定、审计意见每一步都有书面记录。这些文本里存在一种特殊的语言现象说话人不是简单地表达情绪而是在“归责”。举例来说“评标委员会在打分过程中存在明显不公导致我方报价被不合理淘汰。”“采购文件设置的技术参数指向特定品牌涉嫌以不合理条件限制供应商。”“中标人未按合同约定时间完成交付却仍在验收报告中获得通过。”“审计发现项目经办人在供应商选择环节未执行必要的回避程序。”这些句子都带有明显的指责性。它们和普通负面情感不同负面情感可能只是“这个项目很难做”而指责性语言一定包含“某个主体做错了什么需要为此承担责任”的判断。这个差异决定了我们不能简单套用情感分类模型必须做专门的话语行为识别。从业务价值看检测指责性语言至少有四个用途投诉自动分流采购平台每天收到大量质疑和投诉先自动判断是否有实质指责内容再转人工处理。审计线索发现在历史采购公告、合同履约报告中扫描归责性描述辅助审计人员定位高风险项目。舆情与合规监控监测供应商在公开渠道对采购项目的指责性反馈。争议证据整理把项目档案中所有互相指责的段落抽取出来形成争议焦点时间线。这个任务还有一个实际难点。真实采购语料中指责性句子占比通常不高可能只有 2% 到 5%。少数类问题非常严重。如果直接训练一个监督分类器模型很容易把所有句子都预测为“非指责”因为这样准确率也能到 95% 以上。正是这个情况决定了级联无监督-监督架构比单模型更合适。3. 整体思路为什么要用级联无监督-监督架构先说结论级联不是为了让模型结构更复杂而是为了在标注数据有限的情况下把“召回”和“精确”两件事分开解决。3.1 直接端到端监督模型的痛点如果直接标注 2 万条句子然后训练一个 BERT 分类器理论上可行。但现实中采购文本场景千变万化不同机构、不同采购方式、不同行业指责语言的表达方式差异很大。你可能标了某省交通项目的投诉文本换成医疗设备采购很多表达又变了。端到端监督模型需要非常多的标注样本才能覆盖这种变化而公共采购文本涉及商业信息标注成本和人手往往都不够。3.2 无监督阶段负责“粗召回”无监督阶段的输入是大量未标注文本。我们先对文本进行分句然后用预训练句向量模型把每个句子转成向量再做聚类或相似度聚合。这个阶段的目标不是判断“这句话一定是指责”而是找出“这句话可能在谈责任、争议、批评、违规”。哪怕找回来的候选集里有大量噪声也没关系因为后面还有监督模型兜底。关键指标是无监督阶段的召回率。我们希望 95% 以上的真指责句子都在候选集里哪怕精确率只有 20% 甚至 10%。这比直接让监督模型面对全量文本要轻松得多。3.3 监督阶段负责“精判”监督阶段只对无监督阶段捞回来的候选句子做二分类判断是否确实包含指责性语言。因为候选集已经过滤掉了大量明显无关的文本类别不平衡问题被大幅缓解。监督模型可以从 10:1 甚至 100:1 的不平衡变成 2:1 或 3:1 的较平衡状态训练难度显著下降。3.4 级联架构的优势与代价优势标注量小。无监督阶段用通用句向量基本不需要领域标注。可解释性好。每一级都有中间产物候选句子和聚类簇都可以被检查、审计。提升快。无监督召回率不够就调阈值监督精确率不够就加标注、调模型两件事互不干扰。推理可控。第一阶段可以用 CPU 批量跑只有候选句子才需要过 GPU 精判模型节省资源。代价也必须明确级联会产生错误累积。如果无监督阶段漏掉了一个指责句监督阶段永远看不到它最终结果就是漏报。所以第一阶段的阈值要偏向“宁滥勿缺”优先保召回。另外级联的整体指标不是简单的两个模型相乘而是第一召回率乘第二精确率工程上必须分别做监测。4. 数据准备与标注策略4.1 文本来源与预处理推荐从采购网站、采购人内部系统或公开的投诉处理公告中收集原始文本。文本格式通常是 PDF、Word、HTML。PDF 解析推荐先用文档解析工具转成纯文本再按结构段落抽取。处理流程大致是# 伪命令示例按实际文件路径调整 python extract_pdf.py --input ./raw_docs --output ./extracted_txt文本清洗要做这几件事去掉页眉页脚、页码、表格噪声。统一全角半角符号。分句。中文分句不能只按句号还要按“。”和换行符切分。去标识化。如果文本包含企业名称、人员姓名、身份证号、手机号在分析和存储前做脱敏。分句这一步值得单独强调。指责性语言往往出现在句子级别如果按整篇文章做分类信息被稀释如果按词级别做序列标注标注成本又太高。最实用的粒度是“一句话”。4.2 无监督预筛选构建候选标注集在人工标注之前先用无监督方法把全量语料压缩成一个候选集。对候选集抽样标注比直接随机抽样标注更高效。原因是随机抽样大多抽到无关句子标注员会觉得无聊且效率低而候选集里聚集了可能含指责的句子标注员能更快建立正例判断标准。具体做法是用第 5 节的句向量聚类方法从全量语料中取每个聚类簇中心附近和离群点中的句子各一部分交给标注员。这样可以先用较低成本形成第一版标注数据再用这些数据训练监督模型形成“无监督找候选 - 人工标注 - 监督模型训练 - 再扫描新数据”的迭代循环。4.3 标注规范设计标注规范是整个项目里最重要、也最容易偷懒的东西。建议至少标注两个维度。第一维是否有指责性语言。定义要写清楚。建议标注为“是”的情况包括句子中包含对某个主体的不当行为指控、对程序违规的明确归责、对结果不公的批评、对履约失信的指责。建议标注为“否”的情况包括单纯表达失望、描述问题但未归责、转述他人观点、无主体指向的消极情绪。第二维指责对象。可以设计几个互斥类别类别说明采购人/代理机构招标文件设置不合理、评标不公、拖延付款等供应商/中标人围标串标、提供虚假材料、不按合同履约评标专家打分异常、存在利益关联、违反评审纪律审计/监管机构程序瑕疵、问责不当等相对少见需要单列不明确有归责含义但主体不清晰如果产品要求更高还可以标注第三维“严重程度”轻微质疑、明确指控、强烈归责。这三个维度不是一次标完第一版可以只标第一维第二版再扩展后两维。4.4 标注质量检查至少安排两个人独立标注同一批数据然后计算标注一致性。一般用 Cohen‘s Kappa目标值建议在 0.7 以上。如果低于 0.6说明标注规范中“指责性语言”的定义还模糊不要急着训练模型先回来改规范。5. 无监督阶段实现用语义嵌入把疑似指责句捞出来5.1 句向量模型选择无监督阶段的核心是句向量。推荐使用中文场景下效果稳定的 sentence-transformers 模型例如shibing624/text2vec-base-chinese或者基于BAAI/bge-large-zh-v1.5的嵌入模型。选择原则是在 CPU 上能跑、句向量维度适中、对采购领域文本有基本泛化能力。领域特殊性不用太担心因为预训练模型已经见过足够多的中文表达后续监督阶段会做领域适配。5.2 聚类与候选筛选对全量句子生成向量后有两种思路可以混合使用。思路一是聚类。用 HDBSCAN 或 K-Means 对句向量聚类。HDBSCAN 的好处是不用预先指定聚类数且能把噪声点单独分出来缺点是参数敏感需要调min_cluster_size。聚类之后统计每个簇内句子的关键词语境人工观察那些包含“投诉”“不公”“违规”“串通”“倾向性”等词语的簇把它们作为候选。思路二是相似度聚合。先准备一组“指责性种子句”例如“该行为严重违反政府采购法相关规定。”“评标委员会未按招标文件规定的评审标准进行打分。”“中标人提供的产品与投标文件承诺严重不符。”“本项目存在明显的倾向性条款。”“供应商在投标过程中存在围标串标嫌疑。”然后用这些种子句与全量句子计算余弦相似度。对每个句子取它能匹配到的最相似种子句的分数设定一个阈值比如相似度 0.6 以上进入候选集。阈值要偏宽松宁可多召回不要漏。下面是思路二的可运行示例代码。假设你已经把所有文本分句并保存在一个sentences列表中from sentence_transformers import SentenceTransformer # 可选模型text2vec-base-chinese 或 bge-large-zh-v1.5 model SentenceTransformer(shibing624/text2vec-base-chinese) seed_sentences [ 该行为严重违反政府采购法相关规定。, 评标委员会未按招标文件规定的评审标准进行打分。, 中标人提供的产品与投标文件承诺严重不符。, 本项目存在明显的倾向性条款。, 供应商在投标过程中存在围标串标嫌疑。, ] # 对全量句子和种子句生成向量 sen_vecs model.encode(sentences, batch_size64, show_progress_barTrue) seed_vecs model.encode(seed_sentences, batch_size16) # 计算每个句子与种子句的最大余弦相似度 import numpy as np from sklearn.metrics.pairwise import cosine_similarity sim_matrix cosine_similarity(sen_vecs, seed_vecs) max_sim sim_matrix.max(axis1) # 设置候选集阈值 candidate_indices np.where(max_sim 0.6)[0] candidate_sentences [sentences[i] for i in candidate_indices] print(f全量句子数: {len(sentences)}) print(f候选句子数: {len(candidate_sentences)}) print(f候选比例: {len(candidate_sentences) / len(sentences):.4f})运行完之后你会得到一个候选句子列表。如果阈值 0.6 召回的候选太多比如超过全量的 30%说明阈值太松或者种子句覆盖面太广可以上调到 0.7 或 0.75。如果候选太少比如不到 1%说明阈值太紧可以下调。这里要提醒一句无监督阶段不要追求“精确”要追求“不漏”。候选集多一点监督阶段只是多处理几条候选集太少后面再厉害也救不回来。5.3 聚类结果的可解释性分析如果使用 HDBSCAN可以输出每个簇的代表句和关键词import hdbscan from collections import Counter clusterer hdbscan.HDBSCAN(min_cluster_size10, metriceuclidean) cluster_labels clusterer.fit_predict(sen_vecs) # 统计聚类数量 counter Counter(cluster_labels) print(counter.most_common(10))label -1的点通常被认为是噪声在小样本场景下不一定意味着无价值你可以在噪声点里单独抽样查看。整个无监督阶段完成之后建议输出一份候选集报告包括每个簇的句子数量、最高频关键词、代表句交给业务方人工扫一遍确认没有明显遗漏后再进入监督阶段。6. 监督阶段实现用小规模标注精判指责句6.1 模型选择监督阶段推荐使用轻量级预训练模型例如hfl/rbt3、bert-base-chinese或者法律领域模型law-ai/ChineseBERT-law。如果项目有中文法律文本背景可以优先试法律领域模型如果只是一个通用文本分类任务直接用bert-base-chinese更稳妥。模型权重建议从 Hugging Face 下载。如果是在国内网络环境可以配置镜像站点或者提前把模型权重放在本地目录。6.2 训练数据格式训练数据采用 CSV 格式text,label 评标委员会在打分过程中存在明显不公导致我方报价被不合理淘汰。,1 采购文件设置的技术参数指向特定品牌涉嫌以不合理条件限制供应商。,1 本项目已完成施工并进入竣工验收阶段。,0 会议审议通过了项目招标方案。,0训练之前需要把 label 转成模型需要的格式并做训练集、验证集、测试集划分。建议按 8:1:1 划分同时保证三个集合中正负样本比例一致。6.3 微调训练代码下面给出一段基于 Hugging FaceTrainer的微调代码这是最不容易出错的方式import pandas as pd from datasets import Dataset from transformers import ( AutoTokenizer, AutoModelForSequenceClassification, Trainer, TrainingArguments, DataCollatorWithPadding, ) df pd.read_csv(candidate_labeled.csv) train_df df.sample(frac0.8, random_state42) rest_df df.drop(train_df.index) valid_df rest_df.sample(frac0.5, random_state42) test_df rest_df.drop(valid_df.index) train_ds Dataset.from_pandas(train_df[[text, label]]) valid_ds Dataset.from_pandas(valid_df[[text, label]]) test_ds Dataset.from_pandas(test_df[[text, label]]) model_name bert-base-chinese tokenizer AutoTokenizer.from_pretrained(model_name) def tokenize_fn(examples): return tokenizer(examples[text], truncationTrue, max_length128) train_ds train_ds.map(tokenize_fn, batchedTrue) valid_ds valid_ds.map(tokenize_fn, batchedTrue) test_ds test_ds.map(tokenize_fn, batchedTrue) data_collator DataCollatorWithPadding(tokenizertokenizer) model AutoModelForSequenceClassification.from_pretrained( model_name, num_labels2 ) training_args TrainingArguments( output_dir./checkpoints, evaluation_strategyepoch, save_strategyepoch, learning_rate2e-5, per_device_train_batch_size32, per_device_eval_batch_size32, num_train_epochs5, weight_decay0.01, logging_dir./logs, fp16True, load_best_model_at_endTrue, ) trainer Trainer( modelmodel, argstraining_args, train_datasettrain_ds, eval_datasetvalid_ds, tokenizertokenizer, data_collatordata_collator, ) trainer.train()训练完成后用测试集评估from sklearn.metrics import classification_report preds trainer.predict(test_ds) pred_labels preds.predictions.argmax(axis1) true_labels preds.label_ids print(classification_report(true_labels, pred_labels, target_names[非指责, 指责]))输出里重点看“指责”类的召回率和 F1。如果召回率低于 0.85说明无监督候选集或标注规范还有问题如果精确率低于 0.75说明特征没有学够需要补充更多难负例。6.4 类别不平衡与缓解策略如果监督阶段的候选集里正负比例仍然悬殊可以采取三个办法在损失函数中使用类别权重。Trainer不支持直接传class_weight但可以在自定义模型里实现或者用torch.nn.CrossEntropyLoss(weight...)替换。增加难负例。把无监督阶段捞出来但实际不是指责句的“高相似噪声句”作为负样本补充帮助模型学边界。调整最终判定阈值。默认 0.5 不一定是最优可以在验证集上扫描阈值选择 F1 最大的点。最终不要只报告准确率。因为指责句占比低准确率很容易虚高要优先看正类的精确率、召回率和 F1。7. 级联流水线编排把两个阶段串起来无监督和监督模型各自单独训练完成后需要写一个编排脚本把二者串成完整的推理流水线。级联编排的核心是先向量化再相似度粗筛再监督精判最后输出结果和置信度。示例实现如下class CascadedAccusationPipeline: def __init__(self, embed_model, classifier, tokenizer, sim_threshold0.6): self.embed_model embed_model self.classifier classifier self.tokenizer tokenizer self.sim_threshold sim_threshold self.seed_vecs None def set_seed_sentences(self, seed_sentences): self.seed_vecs self.embed_model.encode(seed_sentences, batch_size16) def _recall(self, sentence): vec self.embed_model.encode([sentence]) sim cosine_similarity(vec, self.seed_vecs).max() return sim self.sim_threshold def _classify(self, sentence): inputs self.tokenizer(sentence, return_tensorspt, truncationTrue, max_length128) outputs self.classifier(**inputs) probs torch.softmax(outputs.logits, dim1) label int(probs.argmax(dim1).item()) confidence float(probs.max(dim1).values.item()) return label, confidence def predict(self, sentence): if not self._recall(sentence): return {sentence: sentence, is_accusatory: 0, confidence: 0.0, stage: recall_filtered} label, confidence self._classify(sentence) if label 1: return {sentence: sentence, is_accusatory: 1, confidence: confidence, stage: classifier} return {sentence: sentence, is_accusatory: 0, confidence: confidence, stage: classifier} def predict_batch(self, sentences, batch_size64): results [] for i in range(0, len(sentences), batch_size): batch sentences[i : i batch_size] results.extend([self.predict(s) for s in batch]) return results这个编排类把“是否进入精判”和“精判结果”都体现在输出里。工程上建议把stage字段保留下来方便后续排查漏报和误报发生在哪一级。级联整体评估时不能在测试集上只算监督模型的指标还要把无监督阶段的召回率乘进去。例如无监督阶段召回率是 0.95监督阶段在候选集上的召回率是 0.90那整条流水线对真正指责句的召回率大约是 0.86。如果整体指标不达标优先回看无监督阶段而不是盲目加更多训练数据。8. 接口 API 与批量任务8.1 封装 REST API生产环境建议用 FastAPI 封装推理服务。先加载模型到内存再做推理。为了不重复加载模型用一个全局变量承接 model 和 pipeline 实例from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class TextRequest(BaseModel): text: str class BatchRequest(BaseModel): texts: list[str] with open(seed_sentences.txt, r, encodingutf-8) as f: seed_sentences [line.strip() for line in f if line.strip()] pipeline CascadedAccusationPipeline( embed_modelembed_model, classifiermodel, tokenizertokenizer, sim_threshold0.6, ) pipeline.set_seed_sentences(seed_sentences) app.post(/predict) def predict(req: TextRequest): return pipeline.predict(req.text) app.post(/predict_batch) def predict_batch(req: BatchRequest): return pipeline.predict_batch(req.texts)启动服务uvicorn api_server:app --host 0.0.0.0 --port 8000注意list[str]这种方式要求 Python 3.9 以上。如果你的环境是 Python 3.8换成List[str]。8.2 curl 调用示例curl -X POST http://127.0.0.1:8000/predict \ -H Content-Type: application/json \ -d {text: 评标委员会在打分过程中存在明显不公导致我方报价被不合理淘汰。}返回示例{ sentence: 评标委员会在打分过程中存在明显不公导致我方报价被不合理淘汰。, is_accusatory: 1, confidence: 0.93, stage: classifier }接口路径、返回字段按你的实际实现调整。关键是保留 confidence 和 stage方便调试。8.3 Python 批量调用如果离线批量处理整个目录的文件可以直接用 Python 请求 API也可以用本地predict_batch。下面是用 API 调用的示例import requests import json url http://127.0.0.1:8000/predict_batch texts [ 中标人未按合同约定时间完成交付。, 本次会议主要讨论了项目进度安排。, 供应商在投标过程中存在围标串标嫌疑。, ] resp requests.post(url, json{texts: texts}, timeout120) data resp.json() with open(batch_result.json, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) print(f处理条数: {len(data)})批量任务建议设计为分片处理。例如每次提交 1000 条处理完写一个 checkpoint记录已经处理到的文件偏移量。一旦进程中断从 checkpoint 恢复避免重复跑同一批数据。8.4 批量任务队列设计如果输入文本非常多比如一次扫 50 万条句子不要把请求直接打到 FastAPI 上容易超时。更稳妥的做法是拆成三步定时抽取任务从数据库或文件系统读文本分句后写入待处理队列。推理 Worker消费队列逐条或逐小批调用流水线。结果回写将每条结果写入数据库记录 batch_id、stage、confidence。一个简化的 Python 多进程示例import multiprocessing as mp import pandas as pd def process_chunk(chunk_df, pipeline, output_path): results pipeline.predict_batch(chunk_df[text].tolist()) out_df chunk_df.copy() out_df[is_accusatory] [r[is_accusatory] for r in results] out_df[confidence] [r[confidence] for r in results] out_df[stage] [r[stage] for r in results] out_df.to_csv(output_path, indexFalse, encodingutf-8-sig) if __name__ __main__: df pd.read_csv(all_sentences.csv) chunks [df.iloc[i : i 1000] for i in range(0, len(df), 1000)] with mp.Pool(processes4) as pool: for idx, chunk in enumerate(chunks): pool.apply_async( process_chunk, args(chunk, pipeline, fresult_{idx}.csv), ) pool.close() pool.join()多进程内部共享同一个 pipeline 对象时要注意模型是否线程安全。更稳妥的方式是每个 Worker 进程单独加载一次模型或者使用模型推理框架做并发。9. 资源占用与性能观察训练阶段和推理阶段的资源需求差别很大。训练阶段如果用bert-base-chinesebatch size 32、max length 128、开启 fp16建议 GPU 显存 8GB 以上。如果显存只有 6GB可以把 batch size 降到 16或者换rbt3这种 3 层小模型。推理阶段相对轻量。CPU 上处理单条短文本可能几十到几百毫秒具体取决于模型规模和文本长度。GPU 推理会快很多但小批量处理时 GPU 不一定比 CPU 有数量级优势因为模型加载到显存后推理还需经过前后处理。观察资源占用可以直接用系统命令nvidia-smi重点看两个值显存占用和 GPU 利用率。显存占用高不一定是坏事但要保证在服务运行期间不会因为其他任务抢占而 OOM。GPU 利用率如果长期低于 20%说明瓶颈在前后处理或单条推理延迟上可以考虑提高并发或者使用批处理接口。另外输入文本长度对资源影响非常明显。如果 max_length 从 128 增到 512显存和推理时间都会成倍上涨。公共采购句子通常不会太长建议先按 128 截断观察对正类例句是否会造成信息丢失。如果模型因为截断而漏判再把长度提到 256但不要盲目拉长。无监督阶段的资源占用主要体现在句向量嵌入。如果一次性对几十万句子生成向量内存消耗较大。建议分批编码或者用 SQLite、FAISS 保存向量避免一次性全部载入内存。10. 常见问题与排查方法问题现象可能原因排查方式解决方案无监督候选集比例过低相似度阈值太高或种子句与真实语料表达差异大检查候选集比例和种子句中最匹配样本下调阈值扩充种子句增加领域语料无监督候选集比例过高阈值太低或种子句太宽泛抽样查看候选句中真正指责句占比上调阈值细化种子句监督模型泛化差标注样本太少或训练集与测试集分布不一致检查验证集和测试集 F1对比训练集表现增加标注量加入难负例使用领域预训练模型模型几乎全部预测为非指责类别不平衡严重查看正类召回率调整类别权重降低判定阈值使用 Focal Loss训练时 GPU 显存不足batch size 过大或 max length 过长观察出错时的 batch size 和显存占用减小 batch size开 fp16换成更小模型接口调用超时单条推理过慢或请求并发过高查看日志耗时和 CPU/GPU 利用率使用批量接口增加异步队列扩容批量任务中断后重复处理没有 checkpoint检查输出文件是否覆盖增加断点记录按批次编号输出级联整体召回率远低于两个模型单独指标错误累积分别统计无监督阶段候选集内真阳性数量优先提高无监督阶段召回率扩大候选集排查的时候一定要先把问题定位到具体阶段。如果你发现一条指责句没有出现在候选集里那一定是无监督阶段的问题监督模型改得再好也没用。把 stage 字段输出到结果表里是快速定位这类问题的最有效手段。11. 最佳实践与合规边界11.1 工程最佳实践第一次跑通用小数据。先用 2000 条句子把全流程跑通再扩展到全量语料避免在数据规模上浪费时间。保留最小可运行配置。写一个config.yaml把模型路径、相似度阈值、max_length、batch size 全部固定下来方便复现。数据和模型分开管理。原始文本、分句结果、候选集、标注集、模型权重、推理结果分别放不同目录便于版本回溯。监控每一级输出。在结果表里记录文本来源、候选集匹配分数、监督模型置信度、最终标签。这些中间信息是排查假阳性和假阴性的依据。定期评测。采购文本的表达会随时间变化建议每季度抽样一批新数据人工评估模型是否出现严重漂移。11.2 合规边界公共采购文本包含大量敏感信息投诉人身份、联系方式、企业商业秘密。正在调查中的采购项目信息。可能涉及个人隐私的经办人信息。处理这类文本时必须注意只处理你被授权处理的文本。如果是从公开网站抓取要遵守网站服务条款和相关法规如果是内部文件必须在授权范围内使用。文本入库前做去标识化。姓名、企业名、联系方式、身份证号建议用脱敏工具替换。投诉信息和审计线索属于敏感业务数据访问权限要控制日志要留痕。模型输出只能作为辅助判断。自动识别出的指责性内容需要人工复核后再进入正式流程不建议直接由模型生成投诉处理结论。另外指责性语言检测和“对个人进行负面评价”只有一线之隔。模型只负责发现文本中的归责表达不代表作者对某个主体的判断是真实的。产品设计上要避免“被模型识别为指责句”就直接给相关企业和个人打上负面标签这个责任边界必须把握好。12. 总结与下一步这个级联无监督-监督 NLP Pipeline 最值得尝试的点是把“召回”和“精判”两件事分开处理用小样本标注解决公共采购文本中指责性语言检测的少数类问题。如果按本文流程实施建议最先验证两个环节无监督阶段的候选集召回率以及监督阶段在候选集上的正类 F1。这两个数字决定了整条流水线的上限。最容易踩的坑有三个无监督阶段阈值调得太严导致漏召回直接用准确率评估监督模型导致对少数类问题失真级联整体指标没有从端到端计算导致单看每一级都很好、合起来却很差。后续可以扩展的方向包括把二分类升级为多任务同时输出指责对象和严重程度。引入大型语言模型做数据增强或难样本挖掘降低人工标注量。在推理阶段加入规则引擎对特定采购法规条款做精确匹配提升高置信区间的效率。把流水线接入现有采购管理平台对新增投诉文本做实时风险标记。建议先按“候选集 小型分类器”的架构跑通一版再根据业务数据反馈决定是否升级模型规模。这个方向的工程难点不在模型结构而在数据组织、级联指标设计和合规边界控制上把这三点处理好整套方案会比单模型分类稳定很多。 级联无监督-监督NLP流水线：检测公共采购文本中的指责性语言
这次我们来看一个偏研究但工程落地价值很明显的 NLP 方向用级联无监督-监督 Pipeline 检测公共采购文本中的指责性语言。项目标题直译过来就是“用于检测公共采购中指责性语言的级联无监督-监督 NLP 流水线”。核心要解决的问题很简单在海量招投标文件、供应商质疑函、评标报告、审计底稿里自动找出那些带有指责、归责、指控色彩的句子。这类文本在采购合规、审计风控、投诉处理场景中非常多人工筛选成本极高直接上监督模型又面临标注数据不足的问题。级联架构的价值就在于先用无监督的语义聚类做“粗召回”把疑似指责的句子从几十万条文本中捞出来再用一个小规模监督模型做“精判”。整体兼顾了召回率、准确率和标注成本。文章会按数据准备、无监督阶段、监督阶段、级联编排、API 封装、批量推理的顺序把整套方案完整拆开讲。适合三类读者做 NLP 文本分类的算法工程师需要采购文本风险扫描的审计信息化研发以及研究弱监督文本分类方向的学生。下面直接进入实现。1. 核心能力速览能力项说明任务类型文本分类 / 话语行为识别核心架构级联Cascaded无监督粗筛 监督精判主要输入招投标文件、质疑投诉函、评标报告、审计底稿、会议纪要核心输出句子级是否包含指责性语言以及指责对象、严重程度可选标注依赖小规模人工标注即可无监督阶段用于辅助构建候选集推荐硬件训练阶段建议 8GB 显存以上的 GPU推理阶段 CPU 可运行接口能力可封装为 REST API 服务批量任务支持 CSV / JSON 输入批量推理适用场景采购风险预警、供应商投诉自动分流、审计文本扫描注意这里的显存要求是按 bert-base 级别的分类模型给出的通用建议。如果你换成更大的模型或者把输入句子拼得非常长显存占用会明显上涨部署前需要按实际模型和 batch size 做压测。2. 项目背景公共采购里的“指责性语言”到底是什么公共采购流程会产生大量文本。从招标公告、资格预审文件、投标文件到评标报告、质疑函、投诉处理决定、审计意见每一步都有书面记录。这些文本里存在一种特殊的语言现象说话人不是简单地表达情绪而是在“归责”。举例来说“评标委员会在打分过程中存在明显不公导致我方报价被不合理淘汰。”“采购文件设置的技术参数指向特定品牌涉嫌以不合理条件限制供应商。”“中标人未按合同约定时间完成交付却仍在验收报告中获得通过。”“审计发现项目经办人在供应商选择环节未执行必要的回避程序。”这些句子都带有明显的指责性。它们和普通负面情感不同负面情感可能只是“这个项目很难做”而指责性语言一定包含“某个主体做错了什么需要为此承担责任”的判断。这个差异决定了我们不能简单套用情感分类模型必须做专门的话语行为识别。从业务价值看检测指责性语言至少有四个用途投诉自动分流采购平台每天收到大量质疑和投诉先自动判断是否有实质指责内容再转人工处理。审计线索发现在历史采购公告、合同履约报告中扫描归责性描述辅助审计人员定位高风险项目。舆情与合规监控监测供应商在公开渠道对采购项目的指责性反馈。争议证据整理把项目档案中所有互相指责的段落抽取出来形成争议焦点时间线。这个任务还有一个实际难点。真实采购语料中指责性句子占比通常不高可能只有 2% 到 5%。少数类问题非常严重。如果直接训练一个监督分类器模型很容易把所有句子都预测为“非指责”因为这样准确率也能到 95% 以上。正是这个情况决定了级联无监督-监督架构比单模型更合适。3. 整体思路为什么要用级联无监督-监督架构先说结论级联不是为了让模型结构更复杂而是为了在标注数据有限的情况下把“召回”和“精确”两件事分开解决。3.1 直接端到端监督模型的痛点如果直接标注 2 万条句子然后训练一个 BERT 分类器理论上可行。但现实中采购文本场景千变万化不同机构、不同采购方式、不同行业指责语言的表达方式差异很大。你可能标了某省交通项目的投诉文本换成医疗设备采购很多表达又变了。端到端监督模型需要非常多的标注样本才能覆盖这种变化而公共采购文本涉及商业信息标注成本和人手往往都不够。3.2 无监督阶段负责“粗召回”无监督阶段的输入是大量未标注文本。我们先对文本进行分句然后用预训练句向量模型把每个句子转成向量再做聚类或相似度聚合。这个阶段的目标不是判断“这句话一定是指责”而是找出“这句话可能在谈责任、争议、批评、违规”。哪怕找回来的候选集里有大量噪声也没关系因为后面还有监督模型兜底。关键指标是无监督阶段的召回率。我们希望 95% 以上的真指责句子都在候选集里哪怕精确率只有 20% 甚至 10%。这比直接让监督模型面对全量文本要轻松得多。3.3 监督阶段负责“精判”监督阶段只对无监督阶段捞回来的候选句子做二分类判断是否确实包含指责性语言。因为候选集已经过滤掉了大量明显无关的文本类别不平衡问题被大幅缓解。监督模型可以从 10:1 甚至 100:1 的不平衡变成 2:1 或 3:1 的较平衡状态训练难度显著下降。3.4 级联架构的优势与代价优势标注量小。无监督阶段用通用句向量基本不需要领域标注。可解释性好。每一级都有中间产物候选句子和聚类簇都可以被检查、审计。提升快。无监督召回率不够就调阈值监督精确率不够就加标注、调模型两件事互不干扰。推理可控。第一阶段可以用 CPU 批量跑只有候选句子才需要过 GPU 精判模型节省资源。代价也必须明确级联会产生错误累积。如果无监督阶段漏掉了一个指责句监督阶段永远看不到它最终结果就是漏报。所以第一阶段的阈值要偏向“宁滥勿缺”优先保召回。另外级联的整体指标不是简单的两个模型相乘而是第一召回率乘第二精确率工程上必须分别做监测。4. 数据准备与标注策略4.1 文本来源与预处理推荐从采购网站、采购人内部系统或公开的投诉处理公告中收集原始文本。文本格式通常是 PDF、Word、HTML。PDF 解析推荐先用文档解析工具转成纯文本再按结构段落抽取。处理流程大致是# 伪命令示例按实际文件路径调整 python extract_pdf.py --input ./raw_docs --output ./extracted_txt文本清洗要做这几件事去掉页眉页脚、页码、表格噪声。统一全角半角符号。分句。中文分句不能只按句号还要按“。”和换行符切分。去标识化。如果文本包含企业名称、人员姓名、身份证号、手机号在分析和存储前做脱敏。分句这一步值得单独强调。指责性语言往往出现在句子级别如果按整篇文章做分类信息被稀释如果按词级别做序列标注标注成本又太高。最实用的粒度是“一句话”。4.2 无监督预筛选构建候选标注集在人工标注之前先用无监督方法把全量语料压缩成一个候选集。对候选集抽样标注比直接随机抽样标注更高效。原因是随机抽样大多抽到无关句子标注员会觉得无聊且效率低而候选集里聚集了可能含指责的句子标注员能更快建立正例判断标准。具体做法是用第 5 节的句向量聚类方法从全量语料中取每个聚类簇中心附近和离群点中的句子各一部分交给标注员。这样可以先用较低成本形成第一版标注数据再用这些数据训练监督模型形成“无监督找候选 - 人工标注 - 监督模型训练 - 再扫描新数据”的迭代循环。4.3 标注规范设计标注规范是整个项目里最重要、也最容易偷懒的东西。建议至少标注两个维度。第一维是否有指责性语言。定义要写清楚。建议标注为“是”的情况包括句子中包含对某个主体的不当行为指控、对程序违规的明确归责、对结果不公的批评、对履约失信的指责。建议标注为“否”的情况包括单纯表达失望、描述问题但未归责、转述他人观点、无主体指向的消极情绪。第二维指责对象。可以设计几个互斥类别类别说明采购人/代理机构招标文件设置不合理、评标不公、拖延付款等供应商/中标人围标串标、提供虚假材料、不按合同履约评标专家打分异常、存在利益关联、违反评审纪律审计/监管机构程序瑕疵、问责不当等相对少见需要单列不明确有归责含义但主体不清晰如果产品要求更高还可以标注第三维“严重程度”轻微质疑、明确指控、强烈归责。这三个维度不是一次标完第一版可以只标第一维第二版再扩展后两维。4.4 标注质量检查至少安排两个人独立标注同一批数据然后计算标注一致性。一般用 Cohen‘s Kappa目标值建议在 0.7 以上。如果低于 0.6说明标注规范中“指责性语言”的定义还模糊不要急着训练模型先回来改规范。5. 无监督阶段实现用语义嵌入把疑似指责句捞出来5.1 句向量模型选择无监督阶段的核心是句向量。推荐使用中文场景下效果稳定的 sentence-transformers 模型例如shibing624/text2vec-base-chinese或者基于BAAI/bge-large-zh-v1.5的嵌入模型。选择原则是在 CPU 上能跑、句向量维度适中、对采购领域文本有基本泛化能力。领域特殊性不用太担心因为预训练模型已经见过足够多的中文表达后续监督阶段会做领域适配。5.2 聚类与候选筛选对全量句子生成向量后有两种思路可以混合使用。思路一是聚类。用 HDBSCAN 或 K-Means 对句向量聚类。HDBSCAN 的好处是不用预先指定聚类数且能把噪声点单独分出来缺点是参数敏感需要调min_cluster_size。聚类之后统计每个簇内句子的关键词语境人工观察那些包含“投诉”“不公”“违规”“串通”“倾向性”等词语的簇把它们作为候选。思路二是相似度聚合。先准备一组“指责性种子句”例如“该行为严重违反政府采购法相关规定。”“评标委员会未按招标文件规定的评审标准进行打分。”“中标人提供的产品与投标文件承诺严重不符。”“本项目存在明显的倾向性条款。”“供应商在投标过程中存在围标串标嫌疑。”然后用这些种子句与全量句子计算余弦相似度。对每个句子取它能匹配到的最相似种子句的分数设定一个阈值比如相似度 0.6 以上进入候选集。阈值要偏宽松宁可多召回不要漏。下面是思路二的可运行示例代码。假设你已经把所有文本分句并保存在一个sentences列表中from sentence_transformers import SentenceTransformer # 可选模型text2vec-base-chinese 或 bge-large-zh-v1.5 model SentenceTransformer(shibing624/text2vec-base-chinese) seed_sentences [ 该行为严重违反政府采购法相关规定。, 评标委员会未按招标文件规定的评审标准进行打分。, 中标人提供的产品与投标文件承诺严重不符。, 本项目存在明显的倾向性条款。, 供应商在投标过程中存在围标串标嫌疑。, ] # 对全量句子和种子句生成向量 sen_vecs model.encode(sentences, batch_size64, show_progress_barTrue) seed_vecs model.encode(seed_sentences, batch_size16) # 计算每个句子与种子句的最大余弦相似度 import numpy as np from sklearn.metrics.pairwise import cosine_similarity sim_matrix cosine_similarity(sen_vecs, seed_vecs) max_sim sim_matrix.max(axis1) # 设置候选集阈值 candidate_indices np.where(max_sim 0.6)[0] candidate_sentences [sentences[i] for i in candidate_indices] print(f全量句子数: {len(sentences)}) print(f候选句子数: {len(candidate_sentences)}) print(f候选比例: {len(candidate_sentences) / len(sentences):.4f})运行完之后你会得到一个候选句子列表。如果阈值 0.6 召回的候选太多比如超过全量的 30%说明阈值太松或者种子句覆盖面太广可以上调到 0.7 或 0.75。如果候选太少比如不到 1%说明阈值太紧可以下调。这里要提醒一句无监督阶段不要追求“精确”要追求“不漏”。候选集多一点监督阶段只是多处理几条候选集太少后面再厉害也救不回来。5.3 聚类结果的可解释性分析如果使用 HDBSCAN可以输出每个簇的代表句和关键词import hdbscan from collections import Counter clusterer hdbscan.HDBSCAN(min_cluster_size10, metriceuclidean) cluster_labels clusterer.fit_predict(sen_vecs) # 统计聚类数量 counter Counter(cluster_labels) print(counter.most_common(10))label -1的点通常被认为是噪声在小样本场景下不一定意味着无价值你可以在噪声点里单独抽样查看。整个无监督阶段完成之后建议输出一份候选集报告包括每个簇的句子数量、最高频关键词、代表句交给业务方人工扫一遍确认没有明显遗漏后再进入监督阶段。6. 监督阶段实现用小规模标注精判指责句6.1 模型选择监督阶段推荐使用轻量级预训练模型例如hfl/rbt3、bert-base-chinese或者法律领域模型law-ai/ChineseBERT-law。如果项目有中文法律文本背景可以优先试法律领域模型如果只是一个通用文本分类任务直接用bert-base-chinese更稳妥。模型权重建议从 Hugging Face 下载。如果是在国内网络环境可以配置镜像站点或者提前把模型权重放在本地目录。6.2 训练数据格式训练数据采用 CSV 格式text,label 评标委员会在打分过程中存在明显不公导致我方报价被不合理淘汰。,1 采购文件设置的技术参数指向特定品牌涉嫌以不合理条件限制供应商。,1 本项目已完成施工并进入竣工验收阶段。,0 会议审议通过了项目招标方案。,0训练之前需要把 label 转成模型需要的格式并做训练集、验证集、测试集划分。建议按 8:1:1 划分同时保证三个集合中正负样本比例一致。6.3 微调训练代码下面给出一段基于 Hugging FaceTrainer的微调代码这是最不容易出错的方式import pandas as pd from datasets import Dataset from transformers import ( AutoTokenizer, AutoModelForSequenceClassification, Trainer, TrainingArguments, DataCollatorWithPadding, ) df pd.read_csv(candidate_labeled.csv) train_df df.sample(frac0.8, random_state42) rest_df df.drop(train_df.index) valid_df rest_df.sample(frac0.5, random_state42) test_df rest_df.drop(valid_df.index) train_ds Dataset.from_pandas(train_df[[text, label]]) valid_ds Dataset.from_pandas(valid_df[[text, label]]) test_ds Dataset.from_pandas(test_df[[text, label]]) model_name bert-base-chinese tokenizer AutoTokenizer.from_pretrained(model_name) def tokenize_fn(examples): return tokenizer(examples[text], truncationTrue, max_length128) train_ds train_ds.map(tokenize_fn, batchedTrue) valid_ds valid_ds.map(tokenize_fn, batchedTrue) test_ds test_ds.map(tokenize_fn, batchedTrue) data_collator DataCollatorWithPadding(tokenizertokenizer) model AutoModelForSequenceClassification.from_pretrained( model_name, num_labels2 ) training_args TrainingArguments( output_dir./checkpoints, evaluation_strategyepoch, save_strategyepoch, learning_rate2e-5, per_device_train_batch_size32, per_device_eval_batch_size32, num_train_epochs5, weight_decay0.01, logging_dir./logs, fp16True, load_best_model_at_endTrue, ) trainer Trainer( modelmodel, argstraining_args, train_datasettrain_ds, eval_datasetvalid_ds, tokenizertokenizer, data_collatordata_collator, ) trainer.train()训练完成后用测试集评估from sklearn.metrics import classification_report preds trainer.predict(test_ds) pred_labels preds.predictions.argmax(axis1) true_labels preds.label_ids print(classification_report(true_labels, pred_labels, target_names[非指责, 指责]))输出里重点看“指责”类的召回率和 F1。如果召回率低于 0.85说明无监督候选集或标注规范还有问题如果精确率低于 0.75说明特征没有学够需要补充更多难负例。6.4 类别不平衡与缓解策略如果监督阶段的候选集里正负比例仍然悬殊可以采取三个办法在损失函数中使用类别权重。Trainer不支持直接传class_weight但可以在自定义模型里实现或者用torch.nn.CrossEntropyLoss(weight...)替换。增加难负例。把无监督阶段捞出来但实际不是指责句的“高相似噪声句”作为负样本补充帮助模型学边界。调整最终判定阈值。默认 0.5 不一定是最优可以在验证集上扫描阈值选择 F1 最大的点。最终不要只报告准确率。因为指责句占比低准确率很容易虚高要优先看正类的精确率、召回率和 F1。7. 级联流水线编排把两个阶段串起来无监督和监督模型各自单独训练完成后需要写一个编排脚本把二者串成完整的推理流水线。级联编排的核心是先向量化再相似度粗筛再监督精判最后输出结果和置信度。示例实现如下class CascadedAccusationPipeline: def __init__(self, embed_model, classifier, tokenizer, sim_threshold0.6): self.embed_model embed_model self.classifier classifier self.tokenizer tokenizer self.sim_threshold sim_threshold self.seed_vecs None def set_seed_sentences(self, seed_sentences): self.seed_vecs self.embed_model.encode(seed_sentences, batch_size16) def _recall(self, sentence): vec self.embed_model.encode([sentence]) sim cosine_similarity(vec, self.seed_vecs).max() return sim self.sim_threshold def _classify(self, sentence): inputs self.tokenizer(sentence, return_tensorspt, truncationTrue, max_length128) outputs self.classifier(**inputs) probs torch.softmax(outputs.logits, dim1) label int(probs.argmax(dim1).item()) confidence float(probs.max(dim1).values.item()) return label, confidence def predict(self, sentence): if not self._recall(sentence): return {sentence: sentence, is_accusatory: 0, confidence: 0.0, stage: recall_filtered} label, confidence self._classify(sentence) if label 1: return {sentence: sentence, is_accusatory: 1, confidence: confidence, stage: classifier} return {sentence: sentence, is_accusatory: 0, confidence: confidence, stage: classifier} def predict_batch(self, sentences, batch_size64): results [] for i in range(0, len(sentences), batch_size): batch sentences[i : i batch_size] results.extend([self.predict(s) for s in batch]) return results这个编排类把“是否进入精判”和“精判结果”都体现在输出里。工程上建议把stage字段保留下来方便后续排查漏报和误报发生在哪一级。级联整体评估时不能在测试集上只算监督模型的指标还要把无监督阶段的召回率乘进去。例如无监督阶段召回率是 0.95监督阶段在候选集上的召回率是 0.90那整条流水线对真正指责句的召回率大约是 0.86。如果整体指标不达标优先回看无监督阶段而不是盲目加更多训练数据。8. 接口 API 与批量任务8.1 封装 REST API生产环境建议用 FastAPI 封装推理服务。先加载模型到内存再做推理。为了不重复加载模型用一个全局变量承接 model 和 pipeline 实例from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class TextRequest(BaseModel): text: str class BatchRequest(BaseModel): texts: list[str] with open(seed_sentences.txt, r, encodingutf-8) as f: seed_sentences [line.strip() for line in f if line.strip()] pipeline CascadedAccusationPipeline( embed_modelembed_model, classifiermodel, tokenizertokenizer, sim_threshold0.6, ) pipeline.set_seed_sentences(seed_sentences) app.post(/predict) def predict(req: TextRequest): return pipeline.predict(req.text) app.post(/predict_batch) def predict_batch(req: BatchRequest): return pipeline.predict_batch(req.texts)启动服务uvicorn api_server:app --host 0.0.0.0 --port 8000注意list[str]这种方式要求 Python 3.9 以上。如果你的环境是 Python 3.8换成List[str]。8.2 curl 调用示例curl -X POST http://127.0.0.1:8000/predict \ -H Content-Type: application/json \ -d {text: 评标委员会在打分过程中存在明显不公导致我方报价被不合理淘汰。}返回示例{ sentence: 评标委员会在打分过程中存在明显不公导致我方报价被不合理淘汰。, is_accusatory: 1, confidence: 0.93, stage: classifier }接口路径、返回字段按你的实际实现调整。关键是保留 confidence 和 stage方便调试。8.3 Python 批量调用如果离线批量处理整个目录的文件可以直接用 Python 请求 API也可以用本地predict_batch。下面是用 API 调用的示例import requests import json url http://127.0.0.1:8000/predict_batch texts [ 中标人未按合同约定时间完成交付。, 本次会议主要讨论了项目进度安排。, 供应商在投标过程中存在围标串标嫌疑。, ] resp requests.post(url, json{texts: texts}, timeout120) data resp.json() with open(batch_result.json, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) print(f处理条数: {len(data)})批量任务建议设计为分片处理。例如每次提交 1000 条处理完写一个 checkpoint记录已经处理到的文件偏移量。一旦进程中断从 checkpoint 恢复避免重复跑同一批数据。8.4 批量任务队列设计如果输入文本非常多比如一次扫 50 万条句子不要把请求直接打到 FastAPI 上容易超时。更稳妥的做法是拆成三步定时抽取任务从数据库或文件系统读文本分句后写入待处理队列。推理 Worker消费队列逐条或逐小批调用流水线。结果回写将每条结果写入数据库记录 batch_id、stage、confidence。一个简化的 Python 多进程示例import multiprocessing as mp import pandas as pd def process_chunk(chunk_df, pipeline, output_path): results pipeline.predict_batch(chunk_df[text].tolist()) out_df chunk_df.copy() out_df[is_accusatory] [r[is_accusatory] for r in results] out_df[confidence] [r[confidence] for r in results] out_df[stage] [r[stage] for r in results] out_df.to_csv(output_path, indexFalse, encodingutf-8-sig) if __name__ __main__: df pd.read_csv(all_sentences.csv) chunks [df.iloc[i : i 1000] for i in range(0, len(df), 1000)] with mp.Pool(processes4) as pool: for idx, chunk in enumerate(chunks): pool.apply_async( process_chunk, args(chunk, pipeline, fresult_{idx}.csv), ) pool.close() pool.join()多进程内部共享同一个 pipeline 对象时要注意模型是否线程安全。更稳妥的方式是每个 Worker 进程单独加载一次模型或者使用模型推理框架做并发。9. 资源占用与性能观察训练阶段和推理阶段的资源需求差别很大。训练阶段如果用bert-base-chinesebatch size 32、max length 128、开启 fp16建议 GPU 显存 8GB 以上。如果显存只有 6GB可以把 batch size 降到 16或者换rbt3这种 3 层小模型。推理阶段相对轻量。CPU 上处理单条短文本可能几十到几百毫秒具体取决于模型规模和文本长度。GPU 推理会快很多但小批量处理时 GPU 不一定比 CPU 有数量级优势因为模型加载到显存后推理还需经过前后处理。观察资源占用可以直接用系统命令nvidia-smi重点看两个值显存占用和 GPU 利用率。显存占用高不一定是坏事但要保证在服务运行期间不会因为其他任务抢占而 OOM。GPU 利用率如果长期低于 20%说明瓶颈在前后处理或单条推理延迟上可以考虑提高并发或者使用批处理接口。另外输入文本长度对资源影响非常明显。如果 max_length 从 128 增到 512显存和推理时间都会成倍上涨。公共采购句子通常不会太长建议先按 128 截断观察对正类例句是否会造成信息丢失。如果模型因为截断而漏判再把长度提到 256但不要盲目拉长。无监督阶段的资源占用主要体现在句向量嵌入。如果一次性对几十万句子生成向量内存消耗较大。建议分批编码或者用 SQLite、FAISS 保存向量避免一次性全部载入内存。10. 常见问题与排查方法问题现象可能原因排查方式解决方案无监督候选集比例过低相似度阈值太高或种子句与真实语料表达差异大检查候选集比例和种子句中最匹配样本下调阈值扩充种子句增加领域语料无监督候选集比例过高阈值太低或种子句太宽泛抽样查看候选句中真正指责句占比上调阈值细化种子句监督模型泛化差标注样本太少或训练集与测试集分布不一致检查验证集和测试集 F1对比训练集表现增加标注量加入难负例使用领域预训练模型模型几乎全部预测为非指责类别不平衡严重查看正类召回率调整类别权重降低判定阈值使用 Focal Loss训练时 GPU 显存不足batch size 过大或 max length 过长观察出错时的 batch size 和显存占用减小 batch size开 fp16换成更小模型接口调用超时单条推理过慢或请求并发过高查看日志耗时和 CPU/GPU 利用率使用批量接口增加异步队列扩容批量任务中断后重复处理没有 checkpoint检查输出文件是否覆盖增加断点记录按批次编号输出级联整体召回率远低于两个模型单独指标错误累积分别统计无监督阶段候选集内真阳性数量优先提高无监督阶段召回率扩大候选集排查的时候一定要先把问题定位到具体阶段。如果你发现一条指责句没有出现在候选集里那一定是无监督阶段的问题监督模型改得再好也没用。把 stage 字段输出到结果表里是快速定位这类问题的最有效手段。11. 最佳实践与合规边界11.1 工程最佳实践第一次跑通用小数据。先用 2000 条句子把全流程跑通再扩展到全量语料避免在数据规模上浪费时间。保留最小可运行配置。写一个config.yaml把模型路径、相似度阈值、max_length、batch size 全部固定下来方便复现。数据和模型分开管理。原始文本、分句结果、候选集、标注集、模型权重、推理结果分别放不同目录便于版本回溯。监控每一级输出。在结果表里记录文本来源、候选集匹配分数、监督模型置信度、最终标签。这些中间信息是排查假阳性和假阴性的依据。定期评测。采购文本的表达会随时间变化建议每季度抽样一批新数据人工评估模型是否出现严重漂移。11.2 合规边界公共采购文本包含大量敏感信息投诉人身份、联系方式、企业商业秘密。正在调查中的采购项目信息。可能涉及个人隐私的经办人信息。处理这类文本时必须注意只处理你被授权处理的文本。如果是从公开网站抓取要遵守网站服务条款和相关法规如果是内部文件必须在授权范围内使用。文本入库前做去标识化。姓名、企业名、联系方式、身份证号建议用脱敏工具替换。投诉信息和审计线索属于敏感业务数据访问权限要控制日志要留痕。模型输出只能作为辅助判断。自动识别出的指责性内容需要人工复核后再进入正式流程不建议直接由模型生成投诉处理结论。另外指责性语言检测和“对个人进行负面评价”只有一线之隔。模型只负责发现文本中的归责表达不代表作者对某个主体的判断是真实的。产品设计上要避免“被模型识别为指责句”就直接给相关企业和个人打上负面标签这个责任边界必须把握好。12. 总结与下一步这个级联无监督-监督 NLP Pipeline 最值得尝试的点是把“召回”和“精判”两件事分开处理用小样本标注解决公共采购文本中指责性语言检测的少数类问题。如果按本文流程实施建议最先验证两个环节无监督阶段的候选集召回率以及监督阶段在候选集上的正类 F1。这两个数字决定了整条流水线的上限。最容易踩的坑有三个无监督阶段阈值调得太严导致漏召回直接用准确率评估监督模型导致对少数类问题失真级联整体指标没有从端到端计算导致单看每一级都很好、合起来却很差。后续可以扩展的方向包括把二分类升级为多任务同时输出指责对象和严重程度。引入大型语言模型做数据增强或难样本挖掘降低人工标注量。在推理阶段加入规则引擎对特定采购法规条款做精确匹配提升高置信区间的效率。把流水线接入现有采购管理平台对新增投诉文本做实时风险标记。建议先按“候选集 小型分类器”的架构跑通一版再根据业务数据反馈决定是否升级模型规模。这个方向的工程难点不在模型结构而在数据组织、级联指标设计和合规边界控制上把这三点处理好整套方案会比单模型分类稳定很多。