正则表达式给LLM生成内容加上可信度闸门

我最早是在做 AI 自动写作工具时发现问题的：模型产出的段落读起来完全顺畅，结构规整，连语气都像那么回事，但一旦你去较真核对它提到的论文标题、统计数据、年份出处，就会开始冒冷汗。有一次它引用了某篇“研究”，我按图索骥去查，作者对不上，期刊对不上，连是否真实存在都存疑。更离谱的是，我追问它为什么这么写，它还会立刻编出一套听起来更合理的解释来圆场。那一刻我意识到一个挺瘆人的事实：LLM 骗起人来，是连自己都一起骗的。所以后来在我的内容生成流程里，我坚持加了一道“可信度闸门”，而这道闸门的第一版实现，用的不是另一个大模型来做交叉审核，也不是复杂的知识图谱校验，就是几行正则表达式。

1. 当 LLM 开始“骗”自己：问题藏在哪儿

1.1 LLM 幻觉并不只在问答环节出没

很多人对 LLM 的幻觉印象还停留在“你问它一个知识性问题，它答错”这个阶段，但真实应用里更麻烦的是长文生成场景。无论是自动写产品介绍、行业研报、科普文章还是学术辅助材料，模型都会在长达几千字的输出中“平滑地”滑入虚构状态。

为什么说平滑？因为 LLM 本质上是在预测下一个 token，它在生成第 1000 个 token 时，并不知道自己在第 300 个 token 处写下了“这项技术诞生于 2019 年”。如果后面某个段落需要再次提到时间、机构、数量，它就可能顺着新的概率分布写出另一个不冲突、但实际上跟前文矛盾的数字。这种自相矛盾往往藏得很深，人快速阅读时根本反应不过来，因为每个句子单独拎出来都通顺，只有合在一起对比才会发现数字对不上。

我在测试中做过一个很典型的实验：让模型写一段 800 字的产品介绍，要求提到“研发周期用了 18 个月”。生成结果里，后文某处写的是“团队在近两年的研发中”。单看这句没问题，但你把它和前文一对照，就会发现“18 个月”和“近两年”有出入。这种问题不会让整段内容突然“很假”，但会让细心的读者慢慢失去信任，积累到一定程度，整篇内容的可信度就塌了。

1.2 为什么模型会一本正经地胡说

把 LLM 拟人化成“故意撒谎”其实不准确。它更像一个极其擅长联想和补全的续写器，所有输出都基于训练中学到的统计规律和模式匹配，并没有一个独立的事实核查机制在后台逐句验证自己说了什么。它说“某某研究指出”，不是因为真的检索过那篇研究，而是因为在类似语境下，“发表过的研究”是最常见的下一段内容形态。

这就是标题里说的“自欺”：模型在生成时并不维护一个“外部世界状态表”，它没有真正记住自己已经生成过的每一个断言。它的注意力窗口看到的是前面的 token，而不是前面 token 对应的“世界事实”。所以一旦某个事实细节不在显式上下文里反复出现，它就很容易顺着更高概率的方向写，最后生产出漂亮的、合理的、但可能是虚构的内容。

我见过不少同行第一次做内容生成应用时，把绝大部分精力都花在 prompt 调优上，期待只要写清楚“你必须输出真实信息”，模型就能乖乖遵守。实际上这种约束的效果非常有限。模型没有能力意识到自己即将写出的内容与真实世界不符，就像一个人没法在梦中靠意志力随时踢自己一脚醒过来。所以需要在输出侧加一道与生成模型完全无关的检查机制，这正是“闸门”的价值。

1.3 两种幻觉必须分开看

如果不做区分，很容易把“用正则拦幻觉”理解成试图用正则判断所有内容真假，那显然会翻车。实际工程里我把幻觉分成两类：

第一类是“语义级幻觉”，特点是内容听上去合理但事实错误，例如把某公司的创立年份搞错，或者编造一个根本不存在的合作案例。这类问题需要外部知识库、检索增强生成（RAG）或者人工复核才能解决，正则基本无能为力。

第二类是“结构级幻觉”或“表达级幻觉”，特点是内容内部的格式、编号、数字、术语前后不一致。这类问题有一个共同点：它们都在文本表面留下了可被检测的痕迹。比如引用了“[3]”，但全文压根没有“[1]”；前文说“共有四项原则”，实际只列出三项；年份写着“2035 年”出现在一篇常识性非科幻文章里。这些痕迹是 LLM 在“自欺”过程中露出的马脚，也是正则真正能发挥作用的地方。

所以我的闸门策略从一开始就很明确：不试图判断“事实对不对”，只判断“输出文本内部是否自洽、格式是否规范、是否存在表面破绽”。这个思路让正则的作用边界一下子清晰起来，也让我不会盲目期待它能解决所有问题。

2. 为什么是“几行正则”——闸门方案的选型逻辑

2.1 先想清楚：为什么不用模型审模型

很多人会问，现在 LLM API 这么方便，为什么不让 GPT 去审 GPT 的输出？听起来很优雅：用 A 模型审 B 模型，A 模型可以理解语义，能识别出错误。我在实际项目中试过这个方案，效果确实有，但它有非常现实的三座大山。

第一是成本。一篇 2000 字的文章用模型做一次完整审核，要消耗的 token 可能是原文的两到三倍。如果每天生成几百篇，这笔开销会让应用很难规模化。第二是时延。用户点完“生成”已经等了十几秒，再追加一轮几十秒的模型互审，体验基本没法用。第三是“同源盲区”。如果两个模型在训练数据、对齐方式上高度相似，它们很可能共享同一种错误认知模式，A 模型会认为 B 模型编造的那篇“研究”同样合理，双方在错误的认知上达成一致，等于审了个寂寞。

正则表达式就没这些毛病。它不依赖模型，不烧 token，执行时间通常是微秒到毫秒级。更重要的是，它是“确定性”的。同样一段文本输入进去，每一次检查结果都完全一致。这种确定性在内容生产的质量控制环节里非常宝贵，因为你可以建立一个稳定可回归的规则库，每次模型迭代后都能跑同一套校验，清楚知道新增了哪些错误。

2.2 正则能拦住的幻觉都有哪些共性

我逐渐总结出一个规律：能被正则有效拦截的幻觉，通常满足“文本表层有显式标记”。就像一个人吹牛说“我上个月去了 15 个国家旅行”，你不需要跟着他核实机票，只要把他前后说的行程细节摆在一起就能看出破绽。规则能抓住的，正是这些摆在一起的破绽。

举几个我实际用来做规则的例子：引用编号不连续、声称数量与实际枚举数量不一致、日期超出合理范围、同一段落里同一数据出现两个版本、绝对化表述密度过高、该成对出现的符号没有闭合。这些模式通通可以通过正则或基于正则的轻量逻辑扫描出来。

有一种情况特别典型：当模型要引用文献时，常常会“创造”参考文献。它会给正文加上 [1]、[2] 这样的上标，然后在文末列一个文献表。盗版也有认真的时候，它会真的把编号排好，但如果让它改写一段内容后，内部的编号可能会错位，比如正文引用跳到 [4]，文献表里却没有第 4 条，或者在正文中只看到 [1] 和 [3]，缺了 [2]。这类问题一旦出现，用正则提取编号集合、比对连续性，一个函数就能搞定。

2.3 “拦截”与“可解释”的平衡

在 AI 生成内容的质量管控中，最怕的是模型输出一个结果，审核流程告诉你“不合格”，却说不清为什么不合格。这种黑盒式拒绝在开发调试阶段是灾难：你只能一次次猜，改 prompt、调温度、又生成一遍，然后再撞运气。

正则闸门的好处是每条规则都自带明确的原因。校验器命中某条规则后，可以直接返回规则编号和失败片段，例如RULE_DATE_YEAR_OUT_OF_RANGE: 2037-04-11。内容运营团队拿到这个结果可以立刻判断是模型真写错了，还是规则需要放宽。这种“可解释性”在 AI 应用里极其稀缺，也是我后来坚持把所有质量日志都按规则维度统计的原因。你能清楚看到哪类错误占大头，从而决定是把 prompt 调得更细，还是直接把某段业务数据塞进 RAG 上下文。

2.4 适用边界：正则解决不了什么

必须得承认，正则的能力边界很窄。它不能做情感判断，不能判断观点对不对，不能查证新发布的事件，更不能判断一段话是否违背某个行业规范里微妙的描述。比如药品广告里禁用词很多是语义层面的，像“安全无副作用”，它文本上看着没问题，但可能违规，这需要专门的合规词表加语义建模。

所以更务实的做法是把正规定位成内容可信度防线中最廉价、最前置的一层。它像小区门口的保安，先拦下明显形迹可疑的人，至于每个人包里装的到底是什么，还需要后续的安检和人工判断去管。先做好这一层，整个系统的容错率就会高很多。我在实践中看到，很多团队一上来就追求大而全的事实验证系统，结果半年还没上线；反而是先上几行正则闸门的项目，第二天就发现了一批可复现的模型输出问题。

3. 给 AI 文章上一道闸门：规则实现与接入方式

3.1 校验器整体设计

我倾向把所有检查规则实现为一个纯函数集合，输入是一段文本，输出是一份校验报告。这样设计的好处是规则之间互不依赖，后续新增规则只需要加一个函数并注册到规则列表里。先看骨架代码。

import re from dataclasses import dataclass, field from typing import List, Callable @dataclass class CheckResult: rule_id: str passed: bool message: str = "" matched_text: str = "" CheckFunc = Callable[[str], List[CheckResult]] class ContentGuard: def __init__(self): self._rules: List[CheckFunc] = [] def register(self, func: CheckFunc): self._rules.append(func) def run(self, text: str) -> List[CheckResult]: results = [] for rule in self._rules: try: results.extend(rule(text)) except Exception as e: results.append(CheckResult( rule_id="INTERNAL_ERROR", passed=False, message=f"rule execution failed: {e}", matched_text="" )) return results

每条规则返回一个结果列表，方便一条规则在文本中多处命中时输出多条记录。注册机制让整个校验器变成可插拔结构。对于只在内部使用的小工具，这看起来有点过度设计，但一旦规则数量超过 10 条，这种结构能帮你省下大量调试时间。

3.2 第一批规则：日期、年份和数字一致性

最早值得加的就是年份边界和日期格式规则。LLM 生成内容时经常年份错乱，尤其是涉及“近年来”“某年某月”的表述。一个参考规则是提取文章中的四位数，并判断它是否在一个合理的年份区间内。

YEAR_PATTERN = re.compile(r"(?<!\d)(1[5-9]\d{2}|20[0-4]\d)(?!\d)") SUSPECT_YEAR_CANDIDATE = re.compile(r"\b(18[0-9]{2}|2[1-9][0-9]{2}|[3-9][0-9]{3})\b") def check_year_range(text: str) -> List[CheckResult]: results = [] for m in SUSPECT_YEAR_CANDIDATE.finditer(text): year = int(m.group()) results.append(CheckResult( rule_id="RULE_YEAR_OUT_OF_RANGE", passed=False, message=f"year {year} is out of reasonable range", matched_text=m.group() )) return results

但光有年份范围还不够。我发现更隐蔽的问题是“数字前后不一致”。比如模型前一段写“用户量达到 1.2 亿”，第三段又说“接近 1.5 亿人使用”。这时不能靠单一正则直接判断真假，但你可以做一个比较保守的检查：把同段或相邻段落中的带有单位的大数字提取出来，如果两个数字的表达结构相同且数值不相等，就标记为“数字疑似前后不一致”，交给人工判断。这个方法误报率不低，所以我在设计上只把它当作提示性规则，而不是拦截规则。

3.3 第二批规则：引用编号与格式完整性

学术风、研报风的内容必须处理文献引用编号。模型生成时非常容易出现引用编号断裂。检查逻辑一句话就能说清：提取所有方括号编号，排序后从 1 开始检查是否存在缺失。

REF_PATTERN = re.compile(r"\[(?:bibcite\s+)?(\d{1,3})\]", re.IGNORECASE) def check_reference_continuity(text: str) -> List[CheckResult]: nums = [int(n) for n in REF_PATTERN.findall(text)] if not nums: return [] present = set(nums) missing = [] for i in range(1, max(nums) + 1): if i not in present: missing.append(i) if missing: return [CheckResult( rule_id="RULE_REF_MISSING", passed=False, message=f"missing reference numbers: {missing}", matched_text=str(missing) )] return []

这套规则同样适用于检查“图编号”“表编号”“步骤编号”。只要内容是以编号形式组织的，模型就可能在某些位置漏编号或跳号。正则提取出编号全量后做一次序列完整性检查，几乎零成本。我见过一份案例，模型在润色一篇技术文档时把一个三级标题下的步骤序号从“1、2、3”改成了“1、2、4”，审稿人肉眼扫过去真的不容易发现，但这种错误会让文档的严谨性大打折扣。

3.4 第三批规则：绝对化表达与自相矛盾

理性、严谨的文章通常不会堆砌“毫无疑问”“众所周知”“绝对不可能”这类绝对化表达。倒不是说这些词一出现就一定是错的，而是当模型不确定内容真实性时，它有概率生成更笃定的措辞来补偿心虚感。我在规则库里做了一版“夸张语气检测”，命中后不直接判死，而是记录可疑。

ABS_WORDS = [ "毫无疑问", "毋庸置疑", "绝对不可能", "100%正确", "众所周知", "全世界都知道", "史上最强", "彻底解决" ] ABS_PATTERN = re.compile("|".join(map(re.escape, ABS_WORDS))) def check_absolute_words(text: str) -> List[CheckResult]: results = [] for m in ABS_PATTERN.finditer(text): results.append(CheckResult( rule_id="RULE_ABSOLUTE_WORD", passed=False, message="absolute expression detected", matched_text=m.group() )) return results

自相矛盾的检测稍微高级一点。最简单的一种可以做“肯定/否定模式”的启发式分析：把包含“必须”“需要”“应该”“禁止”“不能”等词的句子抽出来，做一次很浅的共现分析。如果同一个动作在前文说“必须启用 A 方案”，后文又说“不应启用 A 方案”，就可能撞到规则上。这类规则更像是简单 NLP 管道，正则负责初步提取，后续逻辑做集合比较，属于几行内能完成但又不至于简陋的折中方案。

3.5 接入生成管线的示例

有了规则集，剩下最关键的是在生成流程中把闸门放到正确位置。我的推荐位置有两处：第一处是流式生成结束、拿到完整文本之后；第二处是如果内容后续还有“改写/翻译”环节，那么每次大变动后都跑一次校验。

import json from typing import Dict def generate_with_guard(model, prompt: str, guard: ContentGuard, max_retries: int = 3) -> Dict: last_results = [] for attempt in range(max_retries): raw = model.generate(prompt) results = guard.run(raw) failed = [r for r in results if not r.passed] if not failed: return { "status": "ok", "text": raw, "attempt": attempt + 1, "results": [] } last_results = failed # 把检测到的问题回灌给 prompt，要求模型针对性修正 feedback = build_feedback(failed) prompt = prompt + "\n\n请修正以下质量问题，不要改动其他内容：\n" + feedback return { "status": "failed_after_retries", "text": "", "attempt": max_retries, "results": last_results } def build_feedback(results: List[CheckResult]) -> str: lines = [] for r in results: lines.append(f"- 规则 {r.rule_id}: {r.message}，命中片段：{r.matched_text}") return "\n".join(lines)

用大模型自动修正需要小心：修正轮次可能引入新问题，所以修正后的文本必须重新跑一遍校验，不能直接信任模型“我知道错了”的回应。如果重试多次仍然失败，我倾向于把文本打回“需要人工审校”队列，而不是无限次让模型自攻自守。每增加一轮重试，成本和时延都在涨，内容质量却没有指数级提升。

3.6 规则触发后的降级策略

一道闸门不只是“拦住/放行”两种状态。内容生产场景不同，处理方式也完全不同。我在系统里把规则分成了“拦截级”和“提示级”。

拦截级规则针对的是“一旦出现，内容肯定不可用”的问题，比如明显的文献编号错乱、年份写成 2099 年、药品类内容出现明确违禁词。这类命中会强制触发改写或人工处理。提示级规则则针对“可能有问题但不绝对”的问题，比如数字不一致可疑、绝对化表达较多。这类命中只把结果记入质量标签，不阻断发布流程，但运营人员在后台能看到标注。

这套分级背后是对误报的妥协。正则本身很傻，如果所有规则都设置成硬拦截，业务会被误伤搞得寸步难行。分级机制让你可以把精确度高的规则设置成自动拦截，把精确度一般的规则设置成人工辅助提示，这样既保留了正则闸门的效率，又不会因为它的“目光短浅”伤害正常内容。

4. 我踩过的坑与排查实录

4.1 正则误伤比漏检更让人头疼

上线第一周我就被一个误报案例教训了。规则里有一条“检测引用编号缺失”，结果有一篇完全正常的文章因为某处引用编号写成了“[1-3]”，正则把它解析成单独的 1 和 3，判断缺少了 2。其实作者的意思是从 1 到 3 连续引用。后来我在解析前增加了对连字符区间的预处理，先把[1-3]展开成[1][2][3]，问题才消停。

另一个高频误伤来自“年份范围检测”。一篇讲 AI 发展史的文章从 1950 年代开始写，我这里设的候选年份下限是 1800，当时觉得足够宽松，结果文章里一句“这本书的原型最早可追溯到 1748 年”直接触发告警。这条文章引用的是真实历史文献，不是模型幻觉。后来我把年份规则从“拦截级”降成了“提示级”，并且允许在规则说明里备注置信度，避免了正常内容被冤枉。

4.2 性能问题比想象中来得早

本来以为正则就是毫秒级的事，不会造成性能瓶颈，直到某一天我把所有规则都跑在一个超长文档上，单篇耗时冲到了将近一秒。事后我翻规则才发现，问题出在几条正则写得太贪婪，尤其是有几条使用了.*?加re.DOTALL的组合，导致回溯路径爆炸。

排查时我先把每条规则拿出来单独计时，定位到耗时规则后尝试三种优化：一是尽量缩小字符类范围，不要用.匹配所有内容，明确写成[^。]或[\u4e00-\u9fa5]之类；二是增加正则前面的锚点或否定字符类，让不匹配的文本快速失败；三是把单条复杂正则拆成多个简单正则，先用最快的方式做初筛，只有初筛通过才进入开销较大的逻辑。优化之后，同样一篇长文档的完整校验时间降到了 50 毫秒以内，这个量级已经可以毫无压力地放在每次生成回调里。

4.3 中文场景下的特殊问题

英文场景里单词有天然空格分隔，很多正则写起来顺手，但中文处理是另一回事。比如“1.2亿”和“1.2 亿”，模型有时输出带空格，有时不带。如果正则写得太死，就会漏检或误判。我的做法是在进入规则系统前先做一层简单的标准化：统一把数字和中文之间可能的空格去掉，或者在做数量提取时显式允许\s*。

中文标点也是一个坑。很多规则我在刚开始时没有考虑全角标点，导致“和“这种引号无法配对检查。对于成对符号，我用的是先归一再匹配的策略：把全角左右引号统一映射到 ASCII 引号的替身，再做栈式配对判断。这虽然超出了几步正则的范畴，但本质上仍然属于轻量级文本检查，没有引入重型 NLP 依赖。

4.4 排查流程速查表

当你接到一次“闸门误报”时，别急着改正则，按下面这个顺序走会高效很多。

我在实际项目中经常遇到有人直接在线上服务器把某条规则注释掉，结果三天后团队都不知道这条规则当初为什么加。质量规则库也是代码资产，需要版本管理、变更记录和回归测试。哪怕只是几行正则，也应该像业务代码一样对待。

5. 从闸门到护栏：稳定性的下一步

5.1 正则之外的“二次闸门”

光靠正则不能覆盖所有幻觉问题，所以我在后续版本中把闸门从“单层”扩展成“多层”。正则闸门是第一层，负责发现格式、编号、数量和基础一致性等问题。第二层叫“实体一致性检查”，本质上是一个很轻的词表映射表，把文章中的公司名、人名、产品名提取出来，然后对比它们在全文中的写法是否完全一致。模型可能在第一段写“OpenAI”，第五段变成“Open AI”，初看没问题，但在专业文章中是明显的错误。

第二层可以再叠加“关键数据白名单”机制。如果你的业务中某些参数是绝对不允许写错的，比如某款产品的发布时间、某个核心性能指标，就提前把它们写成键值对形式，在生成文本中扫描这些关键词附近的内容，如果数值跟白名单不一致，直接告警。这个思路和正则没关系，但执行的壳仍然复用前面的规则引擎，实施成本很低，效果却立竿见影。

5.2 高价值内容建议接入人工抽检

即便自动化闸门做得再完善，对于发布后不可撤回的高价值内容，我仍然坚持保留人工抽检环节。正则能帮你把模型明显的“自欺”痕迹挡在门外，但它无法替代人对语义正确性的判断。

实际操作中，可以在校验报告里给每篇文章打分，得分低的内容直接进入“高风险待审池”，由人工优先处理。得分高的内容随机抽取 5% 到 10% 做抽检。这样一来，人工不用看完全部内容，只需要盯着机器觉得可疑的部分，效率提升非常明显。团队里内容运营同学反馈，以前看 AI 文章总觉得心里没底，现在有了标注，他们在审核时能快速定位到具体段落，不用全文找茬。

5.3 对模型提示词的约束要一起做

最后我想提醒一个看似无关、但实际影响很大的点：正则闸门在排查问题上有效，但你别忘了同时优化生成侧的 prompt。质量检查做得再好，也不如模型在一开始就少犯错。我在 prompt 里明确要求“每个引用编号必须连续”“避免使用未经证实的绝对化表述”“多处提到同一统计数字时必须保持一致”，配合输出侧的正则校验，生成质量会好非常多。

最让我感慨的是，几行看起来“很低级”的正则，居然能在 AI 时代继续发挥这么大作用。它不懂语义，不智能，但它稳定、可解释、零成本。在所有人都把目光投向更大模型、更强推理时，用规则守住内容的最后一道底线，反而成了最冷静也最可靠的一环。

我现在的工具链里，这个正则闸门仍然保持着一个朴素的地位：先拦截所有一眼就能看穿的错误，再把剩余的问题交给更聪明的系统。踩过几次坑之后，我越来越觉得，做 AI 应用不能只追求模型的“上限”，还要认真设计系统的“下限”。如果哪一天你也被 LLM 的流畅输出惊艳到，然后在核对一个细节时后背发凉，不妨也花十几分钟写几行正则，给内容上一道可信度闸门。它不一定能让你高枕无忧，但至少能让你在给读者看到之前，少一些心惊胆战。