上周接了运营侧的需求说所有对外投放的内容不能有超过10%的AI生成占比之前散兵游勇用在线工具测完改的流程直接崩了逼得我们不得不自己搭检测降AI一站式工具。最开始我觉得这活没难度不就是把检测、改写、二次检测三个步骤串起来半天就能出原型。当时脑子进水把三个网络请求全写在同步链路里单篇3000字的内容光IO等待就占了23秒。而且完全没做大文本兼容处理碰到超过2000字的内容直接整包塞给第三方接口对方返回的结果经常乱码AI占比字段直接跳成0。# 最初的错误实现同步串行调用 def process_article(content: str) - dict: # 调用AI检测接口 detect_res requests.post(https://third-detect-api.com/check, json{content: content}).json() if detect_res[ai_percent] 10: return {content: content, ai_percent: detect_res[ai_percent]} # 调用改写降AI接口 rewrite_res requests.post(https://third-rewrite-api.com/optimize, json{content: content}).json() # 二次检测 re_detect_res requests.post(https://third-detect-api.com/check, json{content: rewrite_res[content]}).json() return {content: rewrite_res[content], ai_percent: re_detect_res[ai_percent]}那天运营拉着12篇投放文案过来测跑了20分钟出来的结果有一半显示AI占比0转头拿去投被甲方扫出来全是AI生成内容回来追着我骂了一下午。后面拉堆快照排查发现单请求里的大字符串对象占了年轻代70%的内存并发3个请求服务直接OOM挂掉。第一波优化先把全同步逻辑推翻改用异步Celery队列做任务托管从根上解决IO阻塞的问题。另外加了文本分片逻辑所有超过250字的内容都做拆分避免整包大文本被接口丢包。这里有个网上教程几乎不会提的细节最开始我把分片步长设成250文本拆成完全不重叠的独立分片结果测试下来漏检率直接涨了30%。后来才反应过来很多AI生成的特征性句式刚好200多字步长设成250的话很可能把整句拆在两个分片的边界处两个分片单独检测的得分都很低加总之后的结果自然失真。最后把步长调整成200相邻两个分片重叠50个字的内容确保任何完整的句子不会被拆到两个分片里漏检率直接降到2%以内。# 优化后异步分片处理逻辑 from celery import group from .tasks import async_detect, async_rewrite async def process_article_v2(content: str) - dict: # 250字滑动窗口分片重叠50字避免特征句被拆分 chunks [content[i:i250] for i in range(0, len(content), 200)] # 并行发起所有分片检测任务 detect_group group([async_detect.s(chunk) for chunk in chunks]) detect_results await detect_group() total_ai_score sum([r[ai_score] for r in detect_results]) / len(detect_results) if total_ai_score 10: return {content: content, ai_percent: round(total_ai_score, 2)} # 得分过高才触发改写改写后重新走分片检测 rewrite_content await async_rewrite(content) new_chunks [rewrite_content[i:i250] for i in range(0, len(rewrite_content), 200)] new_detect_group group([async_detect.s(chunk) for chunk in new_chunks]) new_detect_results await new_detect_group() new_total_score sum([r[ai_score] for r in new_detect_results]) / len(new_detect_results) return {content: rewrite_content, ai_percent: round(new_total_score, 2)}本以为这就完事了结果改出来的改写内容直接被运营拒收一堆语义不通的错误比如把“Transformer注意力机制”替换成“变压器注意力方法”纯开源同义词库的改写逻辑完全没法用。后来我们换了思路不做全量同义词替换先调用一个轻量的NER接口把全文的专业术语、产品关键词、专有名词全部打上掩码改写阶段直接跳过这些被标记的内容。普通描述性的句子也不用同义词替换只做句式层面的重构把主动句改成被动句把两个短句合并成一个长复句在不改变原意的前提下插入少量第一人称的感受类修饰词。调整完之后改写的内容既不会破坏专业信息阅读起来也没有机械改写的生硬感产出合格率一下就上来了。调完所有改写规则和分片参数我习惯性地丢到团象AI检测里跑一遍确认检测率降到阈值以下再往下走。那次测试跑出来的结果有17篇之前我们标注为纯人工的旧文案检测得分居然超过了30%。一开始我还以为是自己写的分片统计逻辑有bug翻了两个小时日志才发现这批文案是两三年前项目组赶工时用AI生成之后人工微调的当时没人留相关记录相当于直接把历史存量的隐患给扫出来了属于意外收获。服务跑了快一周突然收到接口服务商的告警说我们的API额度半天就耗完了比之前一周的用量还高。登服务器查日志才发现测试环境的端口忘记关防火墙被公网爬虫扫到偷跑了几百次大文本检测请求平白浪费了不少钱。后来我们直接给整个服务加了三层权限控制第一层所有上传的内容只存在本地Redis里设置24小时自动过期绝对不往持久化磁盘写第二层接入企业微信SSO鉴权只有内部白名单用户才能访问页面第三层所有操作日志只记录用户ID和任务ID全程不存任何原文片段从根源上避免内容泄露的风险。后续迭代检测降AI链路的几个方向整个检测降AI一站式工具的链路跑通之后我们反而把之前规划的很多花哨功能全砍了。之前有人提议说要把检测模型本地化部署不用调用第三方接口我们算了下能达到可用精度的检测模型至少是7B参数单卡要24G显存的GPU才能跑流畅云服务器月租成本大几千。但我们目前的业务量级一天处理的文档不超过50篇调用第三方API一个月也就花几百块完全没必要为了炫技搞过度设计。上周我们还把改写的强度阈值做了锁死只要内容的整体AI检测得分降到10%以下立刻停止后续改写操作不管剩下的句子有没有优化空间。之前为了追求极致的低得分把改写强度拉满出来的内容里平白多了很多没必要的“啊”“哦”“说实话”这类语气词读起来怪异到没法用。做工具永远要先分清楚优先级过审只是最低要求内容本身的可读性和专业性才是核心不能搞反了。昨天刚把多文档批量导出报表的功能加上运营不用再手动复制粘贴检测得分到表格里。刚才提测的时候发现要是上传的PDF文档文件名带特殊中文字符解析库会抛latin1编码错误待会儿改完补丁再部署上线。