上周三凌晨两点我对着流水线的红色报错页面差点把机械键盘敲出键程异响。当时为了赶内容合规的自动化流程图省事接入了AI检测在线免费的能力结果没捋清楚细节直接上线连着踩了三波坑返工三次才跑通。我们组Q3接了平台内容合规的配套需求所有走发布链路的UGC、PGC内容在进入人工审核之前要新增一道AI生成内容预检环节避免平台出现大面积合规风险。 一开始试过用开源的判别式大模型在本地部署效果实在拉胯。我们自己攒的2000条测试集跑下来假阳性率超过30%很多用户正常写的长技术博客、考研经验帖直接被判定为AI生成运营投诉了整整一周根本没法用。后来评估自研方案的成本要达到商用级的95%以上准确率至少要标注10万条覆盖不同领域的样本微调7B级别的判别大模型每1个QPS就要占用2G左右的GPU显存。我们组这个季度根本没有额外的算力配额申请云厂商的商用检测接口万次调用报价接近700块我们每月要处理近百万条内容预算直接超了三倍当时就把商用方案打回了。 权衡下来先选AI检测在线免费的能力搭过渡流水线想着先跑通流程后面有预算了再换自研的。当时写的第一版调用脚本特别简陋就是直接抓了公开页面的提交接口发POST请求代码大概是这样import requests # 第一版简陋调用逻辑 def ai_detect(content: str) - float: url https://xxx-public-api.com/detect resp requests.post(url, json{content: content}, timeout10) resp.raise_for_status() return resp.json().get(ai_probability, 0)跑了不到200次直接返回403被封IP了。我当时还以为是没模拟浏览器请求头花了半小时加了随机UA池接了代理池还给每一次请求加1到3秒的随机延迟结果第二天刚跑不到一千次直接返回429限流而且限流时长整整24小时。 后来翻响应头才发现藏了个X-RateLimit-Reason字段值是detect non-browser automation access对方早就加了反自动化机制。我之前完全没注意到在线页面提交内容之前会执行一段内嵌的WASM代码算动态令牌没带这个令牌的请求直接就被判定为爬虫拦截了。我把页面里的WASM文件拖出来用工具反编译捋清楚了核心的令牌生成逻辑用当前Unix时间戳加上页面硬编码的盐值迭代三次SHA256哈希最后取前16位字符拼接成X-Detect-Token放在请求头里。补完这个逻辑的代码大概十几行跑通之后连续测了3000次请求都没被拦截import hashlib import time def generate_dynamic_token(salt: str hidden_salt_from_wasm) - str: # 拆解wasm后提取的生成逻辑 ts str(int(time.time())) tmp f{ts}{salt}.encode() for _ in range(3): tmp hashlib.sha256(tmp).digest() return tmp.hex()[:16]我当时一看连续跑了一下午都没报错直接自信满满把代码合并到了主流水线里结果第三天就捅了大娄子。运营抽检的时候发现有一篇1.2万字的AI生成的产品测评预检环节直接返回了0%的AI概率差点就直接发布了要是没查出来整个团队季度KPI都要扣掉15%。 我吓得赶紧拉流水线上的请求日志翻找了半天才发现坑点那个在线检测接口默认对超过5000字符的内容做自动截断只取前1000字做检测剩下的内容直接丢弃。而接口的响应包里默认带了个truncated布尔字段来标记内容是否被截断我写第一版代码的时候完全没处理这个字段直接把返回的AI概率当成全量内容的检测结果用了上万字的长文只测了开头一截结果当然完全不准。AI检测在线免费接口的隐藏坑点汇总针对超过500字的内容我按每片800字的长度做滑动切片相邻切片之间保留20%的重叠度每一个切片单独调用接口做检测最后取所有切片返回的AI概率的最大值作为整篇内容的最终检测结果。改写完切片逻辑之后我习惯性地丢到团象AI检测里跑一遍确认检测率降到阈值以下再往下走。我拿手里攒的1200条标注好的真假样本跑校验改完切片逻辑之后长文本的漏检率直接降到了1%以下整体假阳性率也从之前的30%多降到了7%效果比之前的本地开源模型好太多。 但跑了没两天又发现新问题很多技术类内容里大量贴代码块代码部分本身不是自然语言送到检测接口里完全是无效内容不仅占了字符配额还偶尔会出现误判。我干脆在调用远程接口之前加了一层本地预过滤逻辑用正则把所有Markdown格式的行内代码、代码块全部过滤掉判断过滤后的有效纯文本长度如果不足200字符的内容直接跳过检测不用发请求。import re # 预过滤排除不需要检测的内容 CODE_PATTERN re.compile(r[\s\S]*|{1,2}[^]*{1,2}) def pre_filter(content: str) - tuple[bool, str]: # 移除代码块后判断剩余有效文本长度 pure_text CODE_PATTERN.sub(, content).strip() if len(pure_text) 200: return True, 有效文本长度不足200跳过检测 return False, pure_text这个小改动直接砍掉了我们接近20%的无效调用很多纯贴代码的技术文档不用走检测流程预检的平均耗时也降了0.3秒。 紧接着我又加了一层Redis本地缓存把每一篇内容过滤后的纯文本做SHA256哈希用哈希值作为缓存key把对应的检测结果存在Redis里过期时间设为30天。我们平台有接近40%的内容是运营改几个字就重新提交审核的缓存生效之后这些重复提交的内容直接返回之前的检测结果不用重复发远程请求调用量直接砍半。我后来还发现了一个很少有人提的细节绝大多数AI检测在线免费的服务对中文和英文内容的判定阈值是完全不一样的。我之前统一把AI概率超过0.6的内容标记为高风险结果大量海外用户提交的英文长评被误判。后来我用chardet做了个简单的语种识别逻辑中文内容占比超过60%的继续用0.6的阈值剩下的非中文内容统一调到0.75的阈值又把整体的假阳性率拉低了2个百分点。 为了避免用户提交的内容里有手机号、身份证号、内部项目代号这类敏感信息泄露我还在预过滤环节加了一层掩码替换所有符合手机号、身份证号正则的字符串全部替换成***之后再送到远程检测接口完全规避了数据安全的风险。上周测了整整两周整个流水线跑下来没有再出现之前的漏判、误判也没有再触发过反爬拦截单条内容的平均预检耗时只有1.2秒完全不会拖慢整个内容审核的流程。 前几天有个同组的后端同事问我为什么不干脆在本地部署个轻量的检测模型省得远程调用。我给他算了笔账要达到93%以上准确率的轻量判别模型至少也要1.2B参数INT8量化之后单张T4卡每秒最多处理3条1000字的文本我们峰值QPS大概是12至少要跑4个推理实例核算下来每月的服务器成本比现在对接的AI检测在线免费的方案贵出8倍实在犯不上。