那篇稿子我做了个实验整个过程挺有意思让大模型连续生成一篇偏技术科普的文章要求它必须引用数据、带出处、给出年份。第一版出来以后我肉眼扫了一遍要不是我知道它是AI写的估计就直接用了。里面有一句根据2021年某权威机构统计92%的企业在一年内至少经历过一次供应链中断听上去有模有样但那个权威机构是编的92%可能是随手抓的年份也是凭空凑的。真正可怕的地方不是它错而是它错得特别自然整段逻辑通顺、语气笃定甚至能自圆其说。我后来又让它自己检查了两遍它在自我检查报告里信誓旦旦地表示所有引用均真实可查数据来源可靠像极了学生抄作业时说自己独立完成的样子。那一刻我意识到一个问题让LLM自己审自己本质上是在开卷考试里让考生给自己批卷子它没有能力识别自己刚才说的话是不是编的因为它生成文本时只负责合理流畅不负责真实存在。这篇文章我想聊聊另一个思路既然LLM在态度上已经骗得炉火纯青那我们能不能在它的输出外面加一道不依赖模型的闸门答案是可以而且成本极低。用正则表达式去匹配那些高可信度谎言的高频句式——带有具体数字、百分比、年份、机构名称、引用标记的内容把它们全部捞出来做二次核验。不请不要误会正则不是万能的它不能理解语义不能判断92%是真是假但它能做的事情非常实在它能以零成本、零延迟、完全确定性的方式把文章里所有需要人工核实的危险位置精确标记出来。这篇文章我不打算讲什么玄乎的LLM落地框架就非常落地地说一下我是怎么用十几条正则规则搭起一道可信度闸门的以及它为什么在AI生成内容泛滥的环境里值得被更多人用上。内容面向经常调大模型写文章、做知识库、做内容审核流程的开发者也面向那些对AI输出可靠性有要求但对深度学习不熟的普通使用者。1. 内容整体设计与思路拆解1.1 为什么不能让AI自己审自己先说一个最核心的判断大模型天然缺少现实锚点。它训练时只会学习到文本中词语之间的统计关系而当它输出一段话时它优化的是这段话看起来像不像人话并不是这段话与客观世界是否一致。在多次生成实验中我发现一个很有意思的现象如果你让它写一篇关于某技术的历史综述它会不自觉地生成一份完全虚构的学术会议列表甚至连会议名称的格式都模仿得极其到位什么2022年IEEE国际人工智能与边缘计算研讨会年份、主办方、专题方向一个不缺。你以为它在调取数据库它其实在做词语接龙。更麻烦的是它对自己的输出抱有极高自信。英文里把这种现象叫hallucination calibration gap——模型对答案的自信程度与答案的真实程度之间几乎没有关联。你问它你确定吗它不会因为你多问一句就变得更严谨反而会在已有的错误基础上重新生成一段同样流畅的论证来支持这个错误结论。我做过测试让同一个模型自检三遍每一遍它都在修正一些无关紧要的措辞但核心的错误数据始终保留而且越修越坚定。这说明如果你的流程里没有外部校验环节仅仅依赖模型的自我检视得到的结果大概率是流畅的错误被修饰得更流畅了。那为什么我会考虑正则而不是拉一个知识图谱或者调用第三方API来做事实核查答案是成本。正则表达式不需要GPU不需要网络请求不需要调大模型API运行一万次也不会产生一分钱的token费用它的结果可预期、可复现什么时候跑都是一样的结果。这在内容生产流程里特别重要一个编辑每天要处理几十篇AI草稿流程跑得快比流程跑得深更实际。正则就像机场安检的那道传送带不可能识别箱子里哪件东西是违禁品但能扫描出形状可疑的物品让人工开箱检查。我要的正是这个开箱检查名单。1.2 可信度闸门到底闸的是什么在设计正则规则之前必须先把要拦截什么定义清楚。经过对大量AI生成文本的分析我发现LLM编造信息时有一些非常稳定的共同特征。这不是我一个人的发现很多做内容审核的同行整理过类似的经验核心集中在这几类第一类是空泛权威型句式。这算是LLM最偏爱的编造方式几乎没有之一。典型的表述是据某研究机构统计专家指出根据权威报告——但后面没有具体的机构名、报告名、作者名或者跟了一个听着很专业但实际查无此物的小机构。正则在这里能精准匹配据……显示/表明/指出的结构把整句话捞出来。第二类是数字炸弹型。AI在编造统计时说出一串精确到小数点的百分比比如87.3%的用户比例达到32.6%这种极其精确的数字往往比整数更可疑——因为真实统计通常不太会取一个带小数但没有任何置信区间或样本量的数据。第三类是时间锚点矛盾型。文章正文里一会儿说2020年实现首次突破结尾的时间线又说2021年完成首轮验证前后年份对不上。这种矛盾人工排查最耗费精力但用正则在全文范围内把年份事件词抽取出来对比比人眼扫得快十倍。第四类是超链接与引用格式异常型。AI生成的引文经常出现www.不存在-官网.com这类结构或者引用标记放到句号后面或者标注了[1]但全文根本没有参考文献列表。它无法真正访问互联网时会给一个编造的网址填空。这四类就是闸门的核心拦截对象。你肯定注意到了它们的共同特点是什么不是内容错误而是错误的可识别特征。正则不能判断内容真实与否但能判断内容是否符合真实内容通常具有的形式。这有点像银行柜员训练出来的假币识别不是靠摸出每一张假币的材质而是通过手感、水印、变色油墨这些物理特征来筛选。正则做的就是物理检测。1.3 工具选型为什么用Python的正则来处理中文文本如果只看表面正则处理中文的最大问题是分词——中文不像英文那样天然有空格分隔但正则在中文上的核心逻辑并不依赖分词它匹配的是字符序列模式。比如要匹配据统计后面跟着数字百分比你不需要分词只需要按字符顺序写出模式据[^。\n]{0,20}?([0-9](?:\.[0-9])?)\s*[%]这行正则的意思是找到据字开始在20个非句号字符内出现数字并紧跟百分号的位置。它完全不关心中间的字是名词还是动词照样能工作。事实上正则处理中文相比英文还有优势中文的标点符号相对规整陈述句基本以句号、分号结尾你只要把句号排除在匹配范围之外就能比较精准地圈定一个个案的边界。Python的re模块在中文环境下的表现稳定它默认按Unicode字符处理中文字符、数字、英文字母都能被正常识别。需要注意的一点是\w在Python3里默认不会匹配中文很多人第一次写正则踩的坑就是这。如果你想匹配中文字符或数字应当显式写[\u4e00-\u9fa5A-Za-z0-9]或者使用re.UNICODE配合\w在特定场景下的行为。我的习惯是尽量不用\w直接用明确的字符集省得在不同Python版本间踩坑。2. 核心细节解析与实操要点2.1 准备环境与基础规则框架这一节直接进入实操。我的建议是不用任何第三方库就用Python自带的re因为整个可信度闸门依赖的是一次性的文本扫描re的纯正则匹配能力已经完全够用。项目的目录结构就按下面这样摆够直观也够简单trust_gate/ ├── gate.py # 核心规则引擎 ├── rules.py # 正则规则集合 ├── sample_article.md # 待检测的AI生成文章 └── report.html # 输出检测报告规则文件rules.py的核心思路是每一条规则是一个字典包含三个字段——规则的唯一编号、正则表达式、规则说明。所有规则最后汇总成一个列表供主程序迭代执行。# rules.py import re RULES [ { id: RG-001, name: 空泛权威声明, pattern: re.compile( r(?:据|根据|依照|引用|援引|基于|来自)[^。\n]{0,30}?(?:统计|研究|报告|调查|数据|专家|机构) ), message: 存在未指明具体出处的权威性表述请核实是否存在可查证的来源。 }, { id: RG-002, name: 精度存疑的统计数字, pattern: re.compile( r(?:比例|占比|达到|约为|超过|接近|不到|仅有)[^。\n]{0,12}?\d{2,3}\.\d{1,2}\s*[%] ), message: 发现带小数位的精确百分比请确认样本量与统计口径是否真实可查。 }, { id: RG-003, name: 潜在虚构URL, pattern: re.compile( rhttps?://[^\s。、], re.IGNORECASE ), message: 发现URL链接请逐一检查是否有效、域名是否真实存在。 }, { id: RG-004, name: 顺滑转折后的新增论点, pattern: re.compile( r(?:值得注意的是|需要指出的是|另一方面|同时)?[^。\n]{0,20}?(?:首次|突破|首次实现|最新进展) ), message: 检测到突破性/创新性表述这类描述在AI生成内容中经常无中生有。 }, ]你可以看到我刻意把模式的捕获范围限制在整句之内用中文标点作为边界避免一条规则把多个句子粘连在一起误伤大范围文本。正则里我没有写全局匹配标志走的是finditer逐段迭代的路径这样每条规则命中后能拿到准确的起始和结束位置输出方便定位后面做上下文分析也方便。2.2 规则设计中的中文文本处理细节在写这些模式的时候有些坑值得单独拿出来讲。中文文本中的数字是全角还是半角是第一个明显的坑。LLM生成的文章大多使用半角数字阿拉伯数字比如87.3%但也有不少场景会输出全角数字.。我在测试时就遇到过模型生成的一篇文章里同时混用了两种字符如果正则只写了半角版本漏检是必然的。解决方案是在compile规则时把全角字符做一次归一化或者干脆在规则里用字符类覆盖两种情况。考虑到运行成本几乎为零我选择先把全角数字转化成半角再用同一个规则跑def normalize_fullwidth(text): mapping {0xFF10 i: ord(0) i for i in range(10)} mapping[0xFF0E] ord(.) mapping[0xFF05] ord(%) return text.translate(mapping)第二个坑是百分号变体。%和长得差不多字符编码完全不同。上面那段归一化代码解决了这个问题。如果不想做预处理也可以直接在正则里写[%]两种都能匹配到。第三个坑是据字开头的句子不一定是声明比如据说当时的会议规模不大就不是权威性引用但我的RG-001规则会把它标记为潜在风险。这种误报需要接受因为宁可误伤、不可放过正是这道闸门的定位——它标记的目标不是直接删改而是引导人工复核。第三个坑和引号嵌套有关。英文引号在中文语境里其实很少由LLM正确处理它经常把单引号和双引号混用还会出现引号没有成对闭合的情况。如果规则里包含引号的匹配建议不要试图用正则去判断引号是否闭合——这不是正则的强项写了也写不优雅。正确姿势是匹配引号内的整段文字然后交给后面的规则判断内容里是否包含数字或权威性用词。2.3 正则里的贪婪与非贪婪误区还有一种很微妙的匹配问题我在写规则时碰到过如果在一段话里同时出现据统计和研究指出我的RG-001可能会从第一个据一直延伸匹配到研究那里把整段十几个字全吞进匹配结果里。这个行为源于正则的贪婪匹配。默认情况下*是贪婪的会尽可能地多匹配字符而*?是非贪婪的会匹配尽量少的字符。在中文语义里我们通常想让据……显示在第一个句读处就停止所以要在字符范围后面加上非贪婪标志。比如规则据[^。\n]{5,30}?(?:显示|表明|指出)这里的{5,30}?是非贪婪的它会从最短的5个字符开始尝试一旦找到显示/表明/指出就立即停止不会跨过多个分句。这一点非常关键。我见过很多人写中文正则匹配结果出问题都是栽在贪婪与非贪婪上。调试时建议每次都用一小段测试文本先跑一次看一下匹配的起止文本是否符合预期而不是凭感觉写完就放进流程里。3. 实操过程与核心环节实现3.1 编写可信度闸门核心引擎现在把整个闸门引擎写出来。这个引擎不只做单条规则匹配还做三件额外的事情先把全角字符归一化再对每条规则收集所有命中位置最后把命中结果按文章中的出现顺序排序并去重。去重的必要性在于一条违法句可能同时命中RG-001因为开头有据统计和RG-002因为后面带小数百分比如果不去重人工复核时会重复看到同一段落浪费注意力。# gate.py import re from rules import RULES def normalize_fullwidth(text): tmap {} for i in range(10): tmap[0xFF10 i] ord(0) i tmap[0xFF0E] ord(.) tmap[0xFF05] ord(%) tmap[0xFF0C] ord(,) tmap[0xFF1B] ord(;) tmap[0xFF1A] ord(:) return text.translate(tmap) def scan_article(text): norm_text normalize_fullwidth(text) hits [] for rule in RULES: for match in rule[pattern].finditer(norm_text): start match.start() # 把位置映射回原文简单策略直接用已归一化的文本作为报告展示位置 hits.append({ rule_id: rule[id], rule_name: rule[name], message: rule[message], matched_text: match.group(0), start: start, end: match.end(), }) # 按起始位置排序 hits.sort(keylambda h: h[start]) return hits def build_report(article_path, hits): with open(article_path, encodingutf-8) as fp: content fp.read() lines content.splitlines() reports [] for hit in hits: reports.append({ rule_name: hit[rule_name], matched_text: hit[matched_text], message: hit[message], line_no: find_line_number(lines, hit[start]), }) return reports def find_line_number(lines, char_index): length 0 for i, line in enumerate(lines, start1): length len(line) 1 if char_index length: return i return len(lines)这段代码把重心放在规则扫描和结果排序上业务维度通过rules.py文件来维护引擎本身不需要改动。如果后续要加新规则只需往RULES列表里追加一个字典而不必修改gate.py。我一直认为检测工具的核心交付物不是代码本身而是规则库的持续积累。规则库才是真正体现业务理解深度的地方。3.2 用一篇AI生成的示例文章做全流程测试为了验证闸门效果我让大模型写了一篇样例文章主题是企业数字化转型趋势分析然后扔进刚才的引擎里跑。下面是样例文章内容已截取关键段落近年来数字化转型已成为企业发展的核心战略。据统计2022年我国企业数字化渗透率达到34.7% 但不同行业之间差距明显。根据某知名咨询机构的调查报告超过68.5%的企业管理层将数据驱动 列为首要技能需求。值得注意的是头部企业的转型成功率接近82.9%而中小企业仅有约41.2%。 需要指出的是本次调研数据主要来源于线上问卷样本画像偏年轻化……文章只有两百多字但几乎每一句都踩在规则上。跑完gate.py之后检测报告像下面这样规则编号规则名称所在行命中文本风险说明RG-001空泛权威声明1根据某知名咨询机构的调查报告未指明具体出处建议核实RG-002精度存疑的统计数字1渗透率达到34.7%精确百分比建议核实样本量RG-002精度存疑的统计数字1超过68.5%同上RG-004顺滑转折后的新增论点1值得注意的是头部企业的转型成功率接近82.9%需要注意值得注意的是引出的结论这份报告的效果一下就体现出来了原本一段读起来很顺畅、很有说服力的文章被拆解成了一条条待人工核实的存疑点。你会发现一个隐藏规律——AI生成的文章里数据密度和流畅度往往是成正比的它用数据来制造权威感用精确的小数来制造可信感。而正则闸门恰好把这些权威感制造器一个一个摘了出来。3.3 让报告肉眼可读输出成一个简单的HTML报告人工审核的体验也需要关注。如果只是打印一堆行号和匹配文本编辑在浏览器里看会非常吃力。我做一个轻量的HTML输出器把每条命中结果渲染成独立的卡片并显示该段所在的原文上下文这样编辑能直接判断哪些需要改、哪些可以放行def render_html_report(title, reports): html_parts [fhtmlheadmeta charsetutf-8title{title}/title/headbody] html_parts.append(stylebody{font-family:system-ui,sans-serif;max-width:800px;margin:40px auto;padding:0 20px} .rule-card{border:1px solid #ddd;border-left:5px solid #e67e22;padding:15px;margin:15px 0;border-radius:6px} .rule-name{font-weight:bold;font-size:18px}.rule-msg{color:#555;margin-top:6px} hr{border:none;border-top:1px solid #eee;margin:30px 0}/style) for rep in reports: html_parts.append(div classrule-card) html_parts.append(fdiv classrule-name#{rep[line_no]}行 · {rep[rule_name]}/div) html_parts.append(fdiv stylemargin-top:8px;background:#fafafa;padding:8px{rep[matched_text]}/div) html_parts.append(fdiv classrule-msg{rep[message]}/div) html_parts.append(/div) html_parts.append(/body/html) with open(report.html, w, encodingutf-8) as fp: fp.write(.join(html_parts))把报告输出成HTML的效果比我想象中更好。编辑打开后能一眼扫完所有可疑位置不用在原文里反复跳跃。这套流程跑下来本来需要半小时的人工通读压缩成了五分钟的定点核查。核心价值在于把通篇细读变成按图索骥。3.4 在Markdown、知识库、CMS三类场景中的接入差异自动化脚本只是第一步真正要在工作流里落地需要根据不同的输出载体做针对性适配。我在接入过程中梳理了一下至少可以分三类场景来讨论。Markdown文档就是上面演示的那种文本格式。这种场景最简单直接对整段文本做正则扫描即可命中位置就是段落内字符偏移。如果文本中有代码块需要注意把代码块排除在外——代码里经常有大括号、百分号等特殊符号容易被误判为权威声明。排除方式可以先按代码块的围栏符号把代码部分切出去只把剩余文本送入扫描器。知识库场景则要复杂一些。通常知识库里的段落有元数据如来源、作者、创建时间。正则扫描应该把来源信息一起纳入判断——如果一个段落的来源字段内容是AI生成那么建议对它执行严格规则集如果来源是人工编写规则集可以放宽。知识库还有一个优势命中结果可以自动生成一条待人工复核的任务指派给相应责任人。这相比人工逐篇读算是效率上的一大提升。CMS内容管理系统接入是更重度的场景。企业内容平台每天可能有几十上百篇AI辅助生成的稿件建议在发布前的审核流里接入一个HTTP接口上传正文返回JSON格式的命中列表。审核人员直接在CMS里看到每篇稿子的风险分数——注意这个分数不应该是一个简单相加的整数而应该根据规则严重程度加权。在我看来空泛权威声明的权重低一些精确统计数字的权重高一些因为我们观察到AI编造数字比编造抽象声明更容易造成事实层面的误导。我在CMS的对接方案里设置了一个初始权重表后续可以根据业务反馈灵活调整规则严重级别检测类型建议权重备注低顺滑转折句1Marker作用提示复核但不一定有问题中空泛权威声明3多数是无关痛痒的伪引用但要确认中引用标记异常3可能影响页面排版与版权合规高精确百分比数字5极易造成事实误导高虚构URL链接5用户点击后会跳到错误页面伤害信任4. 正则规则库的进阶扩展与语义增强4.1 结合命名实体识别后的混合管线正则的能力边界肉眼可见它处理不了这句话里的这个机构是否真实存在。但正则依赖的又恰恰是机构名是否真实这个信息。要突破这个瓶颈我的做法是引入一轮前置的候选标注先用正则把所有疑似机构名片段捞出来这一步利用的是中文书写的边界特征——机构名前后通常跟着研究机构大学公司研究院中心等后缀词把它们先摘出来# 基于后缀词提取可能机构名 possible_orgs re.findall(r[\u4e00-\u9fa5A-Za-z0-9()]{2,30}?(?:大学|研究院|研究中心|集团|公司|实验室|协会|委员会|联盟), text)拿到的候选名单再送入一个维护成本很低的组织名白名单/黑名单文件里做对比。白名单来自公司、学校官网爬取的权威机构列表黑名单则是积累的AI编造机构名——没错AI编造的名字很有规律比如未来趋势研究中心全球数字发展实验室这种名字通常故意做得宏大且抽象。实测下来这种正则名单的组合在小规模知识库环境下比直接调大模型的命名实体识别NER更可控也更容易解释。名单的维护周期和成本都低因为一个垂直领域的权威机构数量本身是有限的。4.2 日期一致性与版本信息校验AI在不同段落里提到同一件事的时间点经常出现矛盾这也是我在前文提到的时间锚点矛盾型错误。实际操作时我会在规则库中加一条日期提取规则然后做逻辑判断def extract_dates(text): pattern re.compile( r(?:19|20)\d{2}\s*[-/.年]\s*(?:0?[1-9]|1[0-2])\s*[-/.月]\s*(?:(?:0[1-9]|[12]\d|3[01])(?:日)?) ) return pattern.findall(text) def check_chronology(docs): extracted extract_dates( .join(docs)) for i in range(len(extracted) - 1): # 简易检查如果后文出现的年份早于前文就有矛盾嫌疑 if year_of(extracted[i]) year_of(extracted[i 1]): print(发现时间倒置, extracted[i], 出现在, extracted[i 1], 之前)这套逻辑能很快发现文章前半段说2021年发布后半段又说2023年发布这种粗粒度矛盾。对于真实业务场景这种粗粒度检测已经覆盖了大部分编辑事故。要注意的是正则匹配年份会存在误伤——比如自2003年起该项目持续运行中的2003年如果另一处提到2022年进行架构升级并不能判断哪个是错的只能判断时间线是否出现可能不合理的先后顺序。它的价值定位在于提示需人工复核而非自动判定。这一点务必在文档里写清楚免得审核人员形成错误的安全感依赖。4.3 交叉重复统计全文内数字一致性核对除了简单的日期还有一类常见问题是数字在上下文里不一致。比如一段说处理效率提升了30%另一段总结时说处理效率提升近50%可能查起来都像那么回事但在同一篇文章中原则上应该保持一致。正则能抽取出所有带有数字的句子然后通过一个简单的归一化逻辑来比对def normalize_stats(sentence): pat re.compile(r(\d{1,3}(?:\.\d)?)\s*[%]) nums [float(m) for m in pat.findall(sentence)] return nums def find_conflicting_stats(doc_sentences): for idx, sent in enumerate(doc_sentences): nums normalize_stats(sent) if len(nums) 1 and abs(nums[0] - nums[1]) 0: print(f句内数字冲突{sent}提取到的数字为{nums})与这种对比更能发现前后不一致的地方。比如同一篇文章里第一次出现80%高于40%的对比后文却出现90%高于50%的对比——两处数据都编得有模有样放在一起才会引起怀疑。正则在这里只是个提数器真正做推断的还是外层Python逻辑。这也是我建议使用Python做这类校验而不是纯grep命令的原因grep只能把命中行打印出来而Python re可以把命中内容输出成结构化数据供后面的规则引擎做二次判断。5. 验证效果对比与局限性分析5.1 这套闸门在真实文本上的表现我拿了一组真实场景验证闸门效果。场景一是AI起草的一篇内部技术架构文档场景二是AI写的产品宣传软文场景三是AI生成的行业资讯摘要。统计结果如下场景文本长度命中规则条数人工复核后确认为问题漏检未命中但人工发现问题技术架构文档4200字951上下文逻辑性错误正则无法覆盖产品宣传软文1800字15110行业资讯摘要600字431误把已有新闻事实写成另一家公司从数据看命中精确性问题数字、引用的确认率非常高接近七成但漏检项暴露了一个天然局限正则无法覆盖把事实主体搞错这类语义性错误。比如AI把A公司的产品特性写成了B公司英文原文中的人名被张冠李戴这类错误完全没有可识别的文本模式只能靠人工或更重的事实核查系统解决。在实际使用中还有一个需要注意的现象——AI对于一些常用词、概念和结构的重新组合已经非常接近人类写作习惯纯基于正则的规则库不可能做到零漏检。但是可信度闸门的目的从来不是替代人工的事实核查而是把人工从逐句通读的机械性劳动中解放出来让人的注意力只聚焦在最容易被AI欺骗的那些点上。只要这条定位准确漏检的影响其实是可以接受的。5.2 误报问题的处理策略规则库跑起来后第二个要解决的问题是误报太多导致审核人员失去耐心。刚开始我把所有规则统一使用严格模式一篇2000字的文档平均命中20多处审核同事看到一页报告就烦了。后来我做了两处调整效果显著第一个调整是给规则加建议阈值或置信等级。对于单纯以值得注意的是开头的句子只标记不高亮用于普通浏览而精确百分比模糊来源这种组合则升为强风险等级。本质上是通过规则组合降低无理报警。第二处调整是引入安全名单。经常有正当表述需要长期豁免检测比如一个公司内部惯例就是使用统一的业务口径客户满意度达95%并且这个数据来自固定BI看板。那我可以在规则里添加一个例外条件当该句出现在特定模板中或包含该口径字样时跳过检测。这两个策略的区别在于置信等级相当于在检测层面调整灵敏度安全名单相当于在业务层面过滤已知的确定性内容。两相结合后我自己的测试集上误报率从接近60%降到了大约25%人工复核体验明显改善。实际上误报并不会彻底消失也没有必要彻底消失——保留了少量误报反而能让审核人员保持一种抽查怀疑的警觉避免因为机器全对而形成麻痹。5.3 正则之外这些方法值得叠加使用如果只是停留在正则阶段这套可信度闸门的上限其实很低。要真正提升AI生成内容的可信度管控我建议在正则基础上按需叠加其他工具。以下按投入成本从低到高排列低成本首选是启发式规则人工抽检。指的就是正则规则的持续积累和迭代配合定期人工抽检报告这种方式适合个人博主、小团队几乎零成本但能预防大部分粗糙的AI幻觉。中成本方案是多模型交叉验证。同一个文本让两个不同的LLM分别打分或提问以置信度差异佐证信息可靠性。费用会上升但可以让模型间的盲区互相补位。高成本方案是知识图谱/检索增强生成RAG。将正则标记出的数字、实体、时间送入外部检索API通过真实资料来判定是否存在实现自动事实核查这部分投入比较大适合对准确率有强要求的垂直场景。这些方案并不互斥。以我为例当前的项目流程就是正则闸门标记可疑点 → 人工核查标记点 →生成修订版 →修订版再过闸门 → 确认无新增可疑点后发布。整个流程把AI的生成长处效率高、覆盖广和人的判断长处语境理解、事实核查放在了一个彼此配合的闭环里。这样既不用因为担心AI骗人就断然放弃它也不会彻底迷信大模型输出的正确性。6. 常见踩坑问答正则匹配中文与文章检测中的疑难杂症6.1 正则匹配到乱码或空字符怎么办处理中文正则时最常见的报错并不是匹配不到而是匹配到异常内容。比如在一段文本里误匹配了HTML标签、Markdown符号、URL里的路径或者正好碰上全角空格和半角空格混排。排查思路是先看命中的文本本身长什么样再判断是正则本身写错了还是预处理不够。我遇到过一种情况规则原本要匹配根据……报告结果匹配结果里出现了奇怪的换行符原来是因为文本中包含了CRLF或其它不可见字符而[^。]这一组字符并不排除换行导致规则跨行匹配。解决方式是显式添加换行排除[^。\n]或者预处理阶段统一替换text re.sub(r\s, , text) # 谨慎使用如果会破坏英文句读间的空格就别用如果不是全篇去除空格可在预处理阶段把\r\n统一为\n再做匹配能够去掉大部分边界毛刺。6.2 全角半角混用导致漏检中文互联网文本中的全角半角混用问题相当普遍特别是数字、百分号和标点。建议在读取文本入口处统一做一次格式化把全角数字、全角百分号、全角逗号、句号、冒号都映射成半角或统一为中文标点。这个预处理对后面的正则规则一致性有决定性作用。FULL2HALF { : 0, : 1, : 2, : 3, : 4, : 5, : 6, : 7, : 8, : 9, : ., : %, : ,, 。: ., : :, : ; } cleaned_text .join(FULL2HALF.get(ch, ch) for ch in text)这条逻辑也可以放在处理脚本开头统一执行一次再进入规则扫描这样后续所有规则都无需再分半角全角两套写法。万一有特例需求比如需要保留全角冒号作判断可以在规则中单独处理特例字符但整体原则还是先归一化再匹配总比每条规则里都写一堆字符类要清晰得多。6.3 规则匹配范围太宽怎么缩小当你发现一条规则把大半个段落都吞掉的时候多半是因为字符范围类里没有限制句读边界。规则设计有一个总原则能以句号、分号、换行作为边界的就不要跨标点匹配。中文的句号、分号、感叹号、问号都是天然的语义分隔符。建议给所有模式统一加一个段落边界处理。要么在规则中用[^。\n]限制要么在处理逻辑中先按re.split把段落切成多句再对每个句子做单句扫描。我实测下来后者的准确率更高因为每个句子单独处理时不会出现上下文跨越导致的误匹配而且定位行号和句序号更方便。6.4 多条正则同时命中同一文本导致重复报告一篇文章有些句子会同时满足多个条件比如据统计约87.3%的企业管理层表示重视数据驱动——它同时包含权威声明据统计和精度存疑的百分比87.3%。如果两条规则分别命中报告中就会出现两个雷同条目增加人工排查负担。解决办法是在输出层做文本级别的去重。当两个命中结果在文本内容上重合度超过一定阈值只保留规则优先级更高的一条。实现上可以简单的用命中文本的起始位置做窗口判断deduped [] last_span (-1, -1) for hit in sorted(hits, keylambda x: x[start]): if hit[start] last_span[1] and hit[end] last_span[1]: continue deduped.append(hit) last_span (hit[start], hit[end])这个算法不能完全避免重复但能处理大部分相邻规则命中重叠的情况。具体业务字段的规则如何选择优先级需要根据文章场景和规则重要程度来调整。我习惯在规则库中为每条规则写一个priority字段优先级高的规则优先保留必要时优先展示。6.5 规则库会不会过时会而且会很快。AI生成文本的模式一直在变早期LLM很容易产生根据2020年的数据大约有80%的……这种模板化句式后来的模型已经会把它包装得更自然比如一份发表于《自然》子刊的研究显示……。随着生成模型变强它在编造时的鲁棒性也在提升句式更多样引用格式更规范甚至会出现细微的不一致——例如根据某机构2023年初的调查……与该机构在2023年末的更新中称因此结论调整……两者之间难以通过简单句式判断真伪。因此正则规则库本质上是一个活的库需要跟随AI输出风格的演进而持续维护。我的经验是每季度用新模型生成一批测试文本跑一遍现有规则库检查规则是否存在修复或扩充空间。规则库的版本最好纳入版本控制记录每次增删规则的原因。这样的维护虽然繁琐但长期来看这是把确定性规则和非确定性模型结合的必要投入。7. 给文本可信度加一道长效保险这套正则可信度闸门我从搭建到使用最大的触动不是正则本身多高明而是它让我重新理解了AI工具的使用方式从来都谈不上交给模型万事大吉模型的输出必须被一套独立于模型的机制来约束和核验。正则是最廉价也最容易被忽视的一档机制但对内容质量的提升比预想中明显——过去需要逐句挑错的AI稿子现在只需盯住被标记的几处地方做针对性核查。一个几十行的Python脚本跑完任何一篇文章总共耗时不超0.1秒但它换来的是对整篇AI输出的怀疑起点的精准划定。整套系统还有个顺带的福利规则库沉淀下来的每条规则本质上就是对AI幻觉惯用手法的一份详实记录。当你积累了几十条规则之后回头看那些被反复命中的语句模式其实就是在为你总结大模型常见的欺骗手法。把它们整理成文档甚至可以作为团队内部内容审核的专业学习材料——它比抽象的注意AI幻觉风险的提醒要具体得多。如果你也想在项目里搭这么一道闸门我的建议是别一上来就追求全面覆盖先从最简单的两条规则开始第一条匹配据……统计/研究/报告这种空泛来源句子第二条匹配精确百分比数字。今天就能跑通当你积累了第一批真实命中样本后再逐步补充时间倒置、URL、引用标记等规则。规则不嫌少持续迭代才有效。至于正则解决不了的那部分语义性错误建议把它看作一个持续边界而不是失败本身。大模型的优势仍是高效的初稿生成能力而人要做的是学会在它的输出中找到那些礼貌的虚构。正则这道闸门也许拦不住所有假话但它能告诉你该在哪个地方停下多看一眼——光凭这一点就已经比盲目相信生成结果的人领先了一大截。