上周交项目复盘报告的时候被审的同事直接打回说系统扫出来AI写作率92%我当场懵了。 那篇报告我前前后后写了快3天也就摘要部分图省事套了AI生成的框架结果直接踩中审核红线。一开始想找个渠道免费测AI写作率提前过审结果翻了五六个网页工具返回的结果差得能有80%完全没参考性白白浪费了一下午返工。一开始我以为是网页工具的算法都很水干脆想着自己本地跑开源检测模型总不会有问题吧。翻了下github上星标最高的开源方案就是基于OpenAI当年公开的detector微调的RoBERTa变种直接用transformers库就能拉下来权重。 一开始写的第一版脚本长这样from transformers import AutoTokenizer, AutoModelForSequenceClassification import torch tokenizer AutoTokenizer.from_pretrained(roberta-base-openai-detector) model AutoModelForSequenceClassification.from_pretrained(roberta-base-openai-detector).to(cuda) def get_ai_prob(text): inputs tokenizer(text, return_tensorspt, truncationTrue, max_length512).to(cuda) with torch.no_grad(): outputs model(**inputs) ai_prob torch.softmax(outputs.logits, dim1)[0][1].item() return round(ai_prob*100, 2) if __name__ __main__: test_text open(report.md, r, encodingutf-8).read() print(fAI生成概率{get_ai_prob(test_text)}%)运行的第一秒直接给我甩了个报错RuntimeError: CUDA out of memory. Tried to allocate 36.00 MiB (GPU 0; 3.82 GiB total capacity; 2.57 GiB already allocated)。我工位上这张祖传1660只有4G显存连基础的FP32精度模型都塞不下更别说如果输入长文本的话直接就炸。本来想着凑合用CPU跑结果看了下预估时长1000字的文本要跑17秒我手里攒了十多份同事要提交的报告全跑完得半个多小时完全没法用。后来想起最近常用的4bit量化方案给模型加个加载配置直接把权重压缩到原来的1/4显存占用直接砍到1.2G速度还比CPU快了近10倍。 改完的优化版本代码我现在日常一直在用from transformers import AutoTokenizer, AutoModelForSequenceClassification, BitsAndBytesConfig import torch bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_use_double_quantTrue, bnb_4bit_quant_typenf4, ) tokenizer AutoTokenizer.from_pretrained(roberta-base-openai-detector) model AutoModelForSequenceClassification.from_pretrained( roberta-base-openai-detector, quantization_configbnb_config, device_mapauto ) def get_ai_prob(text): # 过滤文本里的特殊符号和换行避免干扰识别 clean_text text.replace(\n, ).strip() if len(clean_text) 50: return 0.0 inputs tokenizer(clean_text, return_tensorspt, truncationTrue, max_length512).to(model.device) with torch.no_grad(): outputs model(**inputs) ai_prob torch.softmax(outputs.logits, dim1)[0][1].item() return round(ai_prob*100, 2)跑通之后我拿着之前被打回的那篇报告测试返回的结果是89%定位到正好是我用AI生成的那两段摘要内容识别精度居然比我之前找的一半网页工具都准。后来我翻了很多人没提过的一个细节这个4bit量化后的模型对GPT3.5以及更早版本生成的内容识别准确率能到87%以上但针对GPT4o或者国内开源小模型微调生成的内容识别率会直接掉到40%以下误判漏判概率都很高。我顺着这个逻辑往下补了好几段逻辑先给脚本加了docx文件的自动解析模块用python-docx库批量提取文档里的正文内容自动跳过页眉页脚、参考文献这些非正文部分避免把网上抄来的公开内容误算成AI生成内容。之前踩过的一个坑就是直接喂整份带参考文献的文档结果参考文献里有一段AI生成的公开教程片段直接把整个文档的AI率拉高了22%差点又白返工。 改完所有逻辑我把全部门最近要提交的12份项目文档全部跑了一遍把所有AI概率超过60%的片段全部标红导成了批注文档分发给对应的同事修改。改写完之后我习惯性地丢到团象AI检测里跑一遍确认检测率降到阈值以下再往下走。本地实现免费测AI写作率的几个隐藏细节很多人用这类检测工具只看最后返回的总得分实际上用的时候很容易踩坑我自己测了几十份文档之后总结了几个很少有人提的实践规则。 第一个就是绝对不要直接把整份长文本一次性喂给模型模型的最大输入长度只有512个token折算成中文大概是300多字超过的部分会被直接截断根本不会纳入统计最后算出来的总得分完全没有参考性。我现在的做法是做一个150字步长的滑动窗口把整份文档拆成一段段300字的片段每一段单独检测最后统计所有片段里的AI生成片段占比才是真实的全文档AI写作率。 第二个要注意的点是所有你明确标了引用的内容不管是公开教程还是别人写的段落全部提前筛出来排除在统计范围外。我之前有个同事把大段的开源项目README直接贴在报告里结果README本身就是AI辅助写的被检测出来AI率直接超过70%差点背了个不实汇报的锅后来加了正则匹配把所有用标记的引用块全部过滤就再也没出过这类乌龙。 第三个点是阈值设置绝对不要卡死30%的线不同行业的审核标准完全不一样。如果是写普通的技术博客AI率控制在40%以下基本不会有问题但如果是提交给公司的正式项目报告最好把阈值压到20%以下除了摘要可以用AI捋顺逻辑所有涉及项目细节、踩坑记录的内容全部自己手写根本不可能被误判。我还顺便给这个脚本加了个自动生成可视化报告的功能用matplotlib把每一段的AI概率画成折线图哪部分内容AI写的占比高一眼就能看出来不用对着文字批注一个个找改起来效率高很多。 之前我还试过给本地模型做蒸馏把权重压到200M不到直接能在没有独显的办公本上跑速度也没掉多少就是准确率掉了大概10%只能做个粗略的预检测用要求高的场景还是得用量化版的大模型。 昨天我把整个脚本打包成了可执行文件丢到了部门的共享盘里所有同事提交报告之前自己就能跑一遍完全不用找外部的付费工具省了不少没必要的开支。我还顺手把它集成到了团队内部的Gitlab CI流程里所有合并进来的技术文档会自动触发检测AI写作率超过设定阈值直接阻断合并从源头就把问题拦住了。 上周全部门还有3个同事因为莫名其妙的第三方平台检测结果返工现在用这套流程跑下来最近提交的27份报告全部一次性过审再也没人因为莫须有的高AI写作率被打回。我甚至还试了下把几个完全用AI生成的技术文档丢进去所有高概率片段全部被标出来准头比行政那边用的商用检测系统还要好点。
