之前团队要做内网专属的AIGC生成内容筛查系统前前后后踩了快俩月的坑。最早试过PaperPass的AI内容溯源接口然后找了知网研学自带的生成内容筛查模块下了团象AIGC检测的本地离线包还申请过腾讯云的内容合规API试用最后甚至找了百度文心百中的公有云校验接口。结果这些方案要么必须连公网传数据要么内置的中文技术语料太少全都不好用完全满足不了我们物理断网的内网需求只能硬着头皮自研。先给大家说下我们的硬约束需求一条都没法妥协。 第一是绝对数据隔离所有待校验的文档、代码全程不能出内网一步连接口回调都不能碰公网。 第二是多格式兼容要支持docx、md、txt、源代码文件、扫描转PDF五类常见场景覆盖所有办公产出。 第三是误判率指标要求把真人手写内容被误判为AI生成的比例压到3%以下绝对不能打扰正常办公。 第四是并发要求要扛住500人同时提交校验平均响应时间不能超过10秒。一开始图省事我直接找到了GitHub上星标最高的开源检测库detect-gpt-zero想着装完就能跑。from detect_gpt_zero import Detector detector Detector() # 喂100份中文AI生成方案100份手写工程师文档测试 acc detector.evaluate(test_chinese_dataset.json) print(f中文检测准确率{acc})跑出来的结果我至今记得终端输出直接跳了个中文检测准确率0.468差点把我显示器干碎。后来查了源码才反应过来这个库完全是用英文语料预训练的对中文的语义特征几乎没有学习连中文常用的标点逻辑都搞不懂能到47%的准确率都算碰对了一半。当时走的第二个弯路是直接拿开源中文语料去微调这个检测模型找了网上爬的10万条中文文本扔进去训了一轮。 训完测试更离谱误判率直接干到了27%所有带互联网热词、口语化吐槽的技术文档全被标成了AI生成的。 我翻了训练集才发现里面混了大量短视频文案、社交媒体水帖完全是垃圾数据把模型带偏到姥姥家了。这时候我才反应过来做中文技术场景的AIGC检测第一步绝对不是训模型而是攒完全属于自己的纯净数据集。 正样本我们花了一周时间从内网文件服务器里导出了2018-2023年全部存量的工程师手写技术文档、代码提交记录一共127万份这批数据产生的时候还没有可用的开源大模型100%是真人写的。 负样本我们在内网部署了Llama2-7B、Qwen-7B、ChatGLM3-6B三个主流开源大模型用我们自己的业务语料微调后生成了120万份同主题的AI技术文档、代码片段全程没有任何数据流出内网。有了纯净数据集之后我放弃了传统的全文困惑度差值方案专门针对中文技术场景做了7个维度的独立特征工程。 第一个是字符级n-gram分布特征真人写中文技术文档的时候几乎不会连续堆3个以上四字成语大模型生成内容却经常出现这类规整的排比表述。 第二个是代码专属特征真人写的Python代码60%以上会留下调试用的废print语句、变量拼写错误AI生成的代码往往完全符合PEP8规范连多余的空行都找不到。 第三个是语义跳变特征真人写文档经常插两句无关吐槽、前后段落话题跳转没有平滑过渡大模型生成的内容逻辑顺滑到几乎没有断点。 第四个是滑动窗口困惑度特征把文本拆成20字一个的滑动小窗口分别算每个窗口的困惑度真人写的内容困惑度波动极大AI生成的内容波动几乎是平的这个特征单拎出来区分度就能到92%。 剩下三个分别是标点使用习惯、常用术语搭配占比、段落长度分布三个特征加起来又把准确率拉高了4个百分点。特征工程做完之后我根本没选大模型做检测选了轻量的XGBoost分类器把7个维度的特征全部向量化之后喂进去训练整个训练过程用一张3090显卡跑了不到3小时。 最终训出来的分类器模型大小才78MB随便找个低配服务器就能部署完全不需要大量算力资源。 这里还要说个之前踩的隐形坑一开始算困惑度用的是通用中文预训练模型结果我们内网的专属项目代号模型从来没见过算出来的困惑度奇高好多提到内部代号的真人文档都被误判了。 后来我们用内网全部无敏感的技术语料微调了一个专属的轻量GPT2小模型来算困惑度这个问题立刻就解决了连非常冷门的内部项目代号都不会影响特征计算的准确性。from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments, Trainer from datasets import load_dataset # 加载开源中文小模型作为基座整个过程在内网离线完成 model_name uer/gpt2-chinese-cluecorpussmall tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name) # 加载内网导出的无业务敏感信息的技术语料数据集 dataset load_dataset(text, data_files./inner_tech_corpus.txt) # 微调1个epoch就足够适配内部术语不需要太多算力 training_args TrainingArguments(output_dir./p_model, per_device_train_batch_size8, num_train_epochs1) trainer Trainer(modelmodel, argstraining_args, train_datasetdataset[train]) trainer.train()部署架构我们做了三层解耦全链路跑在内网隔离区连公网网线都没插。 第一层是接入转换层用FastAPI写的轻量接口内置python-docx、pymupdf、mistune等依赖自动把不同格式的文件转成纯文本扫描件则调用本地部署的PaddleOCR离线识别。 第二层是任务调度层用RedisCelery做分布式任务队列所有校验请求先入队列排队后台4台计算节点异步取任务执行避免突发流量打垮服务。 第三层是结果输出层返回的报告不会只给一个干巴巴的百分制分数而是把7个维度的得分全部列出来异常内容直接定位到具体行数方便审核人员人工复核。整套系统写完我们用JMeter做压测500并发的场景下平均响应时间7.2秒完全达标。 在2000份样本的测试集里最终准确率达到97.3%误判率只有2.1%完全符合我们最初定的要求。 我们还给系统加了两个非常实用的优化功能。 第一个是个人白名单功能如果某些老工程师的写作风格非常特殊容易被误判直接把他的10份历史文档喂进去系统就会提取他的个人写作特征后续校验自动适配误判率还能再降。 第二个是自动增量迭代功能每周日凌晨系统会自动把本周人工复核过的新样本补充到正负样本集里自动跑一轮增量微调模型越用越准几乎不需要人工运维。现在这套系统已经在内网稳定跑了3个多月累计校验了12万份文档、37万份代码文件从来没出过数据泄露问题。 之前行政合规抽查一份3000字的文档人工逐字看至少要10分钟现在系统1秒出结果整体效率直接提了十几倍。其实回过头来看很多特殊场景下的通用工具不好用本质上是需求的定制化程度太高了。 尤其是物理断网的内网合规场景所有通用产品都不可能提前适配你们内部的专属术语、写作习惯与其花大量时间挨个试工具踩坑不如集中少量资源自研一套后续迭代起来也完全灵活可控。