标准文档与合规审查场景中最让人头疼的一类任务往往不是“读不懂”而是“看得过来却查不干净”。当审查对象是几十页甚至上百页的技术规范、产品标准、安全条款时人眼逐条对照规则很容易遗漏尤其是那些“必须”“严禁”“不应用”“应满足”这类表意强硬的条款。最近我们在做 LLM 辅助审查的落地实验时遇到了一个更具体的问题模型看起来能读懂规则但它到底有没有“真的按规则”在审不同模型、不同提示词模板之间的差别有多大如果效果不好又应该如何增强这篇文章会把我们构建基准评测和增强方案的过程整理成一套可复用的实战方法覆盖任务定义、数据集构建、评测指标、基线实验、增强策略和常见坑点适合正在做 LLM 评估、合规审查类应用的开发者参考。1. 背景与核心概念1.1 什么是规则密集型审查规则密集型审查英文常称为 Rule-Intensive Review指的是这样一类 NLP 任务模型需要根据一组事先给定的、约定好的规则条款对输入文本进行判定判断文本是否违反规则并指出违反的是哪一条、具体位置在哪里、理由是什么。这类任务和普通文本分类、情感分析有本质区别。普通分类任务只需要判断“正面/负面”“垃圾/正常”规则密集型审查则要求模型做到三件事规则匹配找到与当前文本相关的规则条款。违规判定判断文本是否真的违反该条款。定位与解释指出违规位置并给出可复核的解释。举个例子假设有一条规则是“合同中的金额应当同时包含大写和小写”。模型审查一段合同文本时不仅要回答“是否合规”还要回答“如果不合规是哪一处金额缺少大写形式”最好还能引用规则原文。这就对模型的逻辑能力和文本细粒度理解能力提出了很高要求。国家标准文档、行业规范、企业内部制度、产品检测标准等场景都有大量的这种规则密集型审查需求。人工审查虽然准确但成本高、速度慢而且面对上百条规则时容易出现疲劳忽略LLM 则具备较强的文本理解能力和规则形式的泛化能力适合作为预审工具但前提是必须经过系统评测知道它在不同规则类型上的能力边界。1.2 LLM 用于标准审查的三个挑战用大模型来做规则密集型审查表面上看起来很简单把规则和待审文本一起丢给模型即可。真正落地时会遇到三个挑战。第一个挑战是规则记忆不稳定。模型不是数据库它并不能精确“记住”每一条规则的原文。上下文过长时早期规则可能被遗忘或者被后续内容干扰。尤其当规则存在相似条款时模型容易混淆。第二个挑战是判定标准不统一。不同模型对“违反”“不符合”“建议但不强制”这类语义强度的理解不一致。同一个违规样本不同模型可能给出完全不同结论甚至连同一个模型重复调用两次结果都可能有波动。第三个挑战是评测困难。如果不知道正确答案就无法判断模型输出是对是错。而人工标注规则密集型数据集的成本很高需要专业人员逐条审核普通众包很难保证质量。所以构建一套可复用的基准测试Benchmark和增强方案是 LLM 落地这类任务的第一步。1.3 为什么先要有 Benchmark 再谈增强Benchmark 的本质是“标准答案集 评测指标”。它的价值不只是打分而是告诉我们三个关键信息当前模型在哪些规则类型上表现好哪些规则类型上表现差。提示词和增强策略的改动到底带来了多少真实提升。当效果不达标时问题出在规则理解、文本定位还是输出格式。我们在实践中发现很多团队一开始就追求把模型“调得更聪明”但缺少评测体系导致改了一个 prompt 也说不清效果是变好还是变差。先建立 Benchmark再基于失败样本做增强才是更高效的方式。2. 问题定义与评测体系设计2.1 任务形式化我们将规则密集型审查任务形式化如下输入 1规则集合 R {r1, r2, ..., rn}每条规则包含唯一编号、正文、类别、约束强度。输入 2待审文本 D可以是一段章节、一个条款、一份文档片段。输出一组审查结论 C {c1, c2, ..., cm}每个结论包含判定结果pass / fail / uncertain。命中规则编号与判定相关的规则。违规位置原文字符区间或行号。解释给出理由便于人工复核。这种结构化输出设计很重要它可以让模型结论被程序解析然后计算指标而不是停留在“看着合理”的层面。2.2 评测维度与指标我们建议从四个维度来评测模型规则级命中率Rule Hit Rate对于每条规则模型是否在需要时主动引用它。计算方式被正确引用的规则数 / 应命中规则总数。这个指标反映规则召回能力。违规判定 F1将违规判定视为二分类问题计算 TP、FP、FN然后得到精确率、召回率、F1。这是最核心的指标。定位准确率Location Accuracy模型给出的违规位置与真实位置是否一致。可以按区间交集比例打分例如 IoU 大于 0.5 算定位成功。格式遵循率Format Compliance模型输出是否可被 JSON 解析必填字段是否完整。这是工程可用性的基础指标。2.3 数据集分层规则密集场景的数据集应该分层设计我们建议至少包含三层简单层明确规定、单一规则、文本较短。中等层多条规则同时适用文本较长需要定位。困难层规则之间存在相似性、文本有歧义、需要结合上下文推断。分层的好处是可以精确看出增强手段到底解决了哪一层的问题。例如RAG 增强可能显著提升困难层规则召回但简单层提升不大那么说明瓶颈在规则检索而不是基础理解。3. 环境准备与基准数据集构建3.1 环境与依赖本文示例以 Python 为主要语言使用 OpenAI 兼容接口调用模型向量检索以简单的关键词/向量混合方式演示。版本不需要完全照搬建议按实际项目调整。python -m venv venv source venv/bin/activate pip install openai pandas numpy tiktoken这里我使用 OpenAI 兼容接口但示例代码中的client.chat.completions.create调用方式只要是兼容接口的模型都可以复用。如果你使用本地模型例如基于 vLLM 部署的 Qwen、ChatGLM、DeepSeek 等只需要把base_url和api_key改成本地服务的地址即可。3.2 规则库构建规则库是整套系统的基石。我们用一个 JSON 文件来存储规则每一条规则包含以下几个字段[ { rule_id: R001, category: 格式要求, constraint_type: must, content: 技术文档中的计量单位应使用国际单位制符号如 m、kg、s不得使用中文单位名称与符号混排。, keywords: [计量单位, 国际单位制, 混排] }, { rule_id: R002, category: 安全条款, constraint_type: must_not, content: 产品说明书中不得出现“绝对安全”“零风险”等绝对化承诺用语。, keywords: [绝对安全, 零风险, 绝对化] } ]字段含义如下rule_id规则唯一编号用于结果追踪。category规则所属类别。constraint_type约束类型must表示必须满足must_not表示禁止出现。content规则正文是判断依据。keywords关键词列表用于快速检索候选规则。实际项目中规则数量可能上百条甚至上千条。建议为每条规则设置维护负责人和有效期避免过期规则继续参与审查。3.3 违规样本自动注入人工构造违规样本非常耗时。我们可以借助 LLM 本身来生成候选样本再进行人工校验。核心思路是从规则库中随机抽取规则让 LLM 根据规则原文生成一段“包含违规内容”的文档片段。我们写一个build_benchmark.py脚本来自动生成数据。为了避免模型自我生成时出现“不会犯错”的问题我们采取“改写生成”的策略先生成合规文本再用专门的注入提示词把违规内容混入。# 文件路径build_benchmark.py import json import random from openai import OpenAI client OpenAI( base_urlhttps://your-compatible-api.example.com/v1, api_keyyour-api-key ) RULES [ { rule_id: R001, category: 格式要求, constraint_type: must, content: 技术文档中的计量单位应使用国际单位制符号如 m、kg、s不得使用中文单位名称与符号混排。 }, { rule_id: R002, category: 安全条款, constraint_type: must_not, content: 产品说明书中不得出现“绝对安全”“零风险”等绝对化承诺用语。 } ] def generate_positive(rule): 生成合规文本片段 prompt f请根据以下规则生成一段完全符合规则的文档片段内容要求自然、具体不少于 80 字。 规则{rule[content]} 只输出文本不要输出解释。 resp client.chat.completions.create( modelyour-model-name, messages[{role: user, content: prompt}], temperature0.7 ) return resp.choices[0].message.content.strip() def generate_negative(rule): 生成违规文本片段 prompt f请根据以下规则生成一段明显违反规则的文档片段内容要求自然、具体不少于 80 字。 规则{rule[content]} 注意你的输出应当是违规文本本身不要写任何解释、标注或说明。 只输出文本不要输出解释。 resp client.chat.completions.create( modelyour-model-name, messages[{role: user, content: prompt}], temperature0.9 ) return resp.choices[0].message.content.strip() def build_dataset(): dataset [] for rule in RULES: for i in range(10): # 每条规则生成 10 个正例和 10 个负例 pos generate_positive(rule) neg generate_negative(rule) dataset.append({ rule_id: rule[rule_id], text: neg, label: violation, source: auto_generated }) dataset.append({ rule_id: rule[rule_id], text: pos, label: pass, source: auto_generated }) print(fprogress: rule {rule[rule_id]}, sample {i}) with open(benchmark_raw.jsonl, w, encodingutf-8) as f: for item in dataset: f.write(json.dumps(item, ensure_asciiFalse) \n) if __name__ __main__: build_dataset()这里有一个非常重要的原则自动生成的数据不能直接用来当最终评测集必须经过人工校验。LLM 生成的“违规样本”有可能实际上并不违规或者只违规了一部分。因此生成完后需要至少两名熟练人员独立标注存在分歧时讨论确认。校验阶段我建议对照下面两个问题负例是否的确能被某条规则“一票否决”正例是否真的没有任何一处命中规则只有通过校验的样本才能进入benchmark_final.jsonl。4. 基线评测实现有了数据集之后下一步是跑通基线评测。所谓基线是指“不做过多的工程优化只用一份简单 prompt 加上结构化输出要求”的模型调用方式。基线结果的意义是给后续增强策略提供对比参照。4.1 Prompt 基线模板基线 prompt 设计要注意三点角色明确、规则与文本分隔清晰、输出格式严格约束。# 文件路径prompt_templates.py BASE_PROMPT 你是一名文档合规审查专家。你的任务是根据给定的规则条款对文本片段进行合规性审查。 规则条款 {rules_text} 待审查文本 {content} 请按以下 JSON 格式输出审查结论 {{ result: pass 或 violation, rule_ids: [命中的规则编号没有则为空数组], positions: [违规位置说明没有则为空数组], reason: 简要说明判定理由 }} 注意 1. 只能输出 JSON不要输出多余解释。 2. result 为 pass 时rule_ids、positions 应为空数组。 3. violations 判定请严格依据规则条款。 可以看到我们刻意让基线的输出结构化和评测脚本对齐但 prompt 中并没有加入“先找相关规则再判定”的两阶段引导。这样能更真实反映模型的天然能力。4.2 评测脚本评测脚本负责调用模型、解析输出、计算指标。核心实现如下# 文件路径evaluate.py import json import re import sys from openai import OpenAI client OpenAI( base_urlhttps://your-compatible-api.example.com/v1, api_keyyour-api-key ) def parse_model_output(output): 从模型输出中解析 JSON容忍少量前后缀内容 text output.strip() match re.search(r\{.*\}, text, re.S) if not match: return None try: return json.loads(match.group(0)) except json.JSONDecodeError: return None def evaluate_item(item, rules_text): prompt BASE_PROMPT.format(rules_textrules_text, contentitem[text]) resp client.chat.completions.create( modelyour-model-name, messages[{role: user, content: prompt}], temperature0.2 ) return parse_model_output(resp.choices[0].message.content) def compute_metrics(predictions, golds): tp fp fn tn 0 rule_hit_tp rule_hit_fp rule_hit_fn 0 format_ok 0 for pred, gold in zip(predictions, golds): # 判断输出格式 if pred is not None and result in pred: format_ok 1 # 判断违规识别 pred_label pred.get(result) if pred else invalid gold_label gold[label] if pred_label violation and gold_label violation: tp 1 elif pred_label violation and gold_label pass: fp 1 elif pred_label pass and gold_label violation: fn 1 elif pred_label pass and gold_label pass: tn 1 # 规则命中判断 pred_rule_ids set(pred.get(rule_ids, [])) if pred else set() gold_rule_ids {gold[rule_id]} if pred_rule_ids gold_rule_ids: rule_hit_tp 1 else: if gold_label violation: rule_hit_fn 1 else: rule_hit_fp 1 precision tp / (tp fp) if (tp fp) else 0 recall tp / (tp fn) if (tp fn) else 0 f1 2 * precision * recall / (precision recall) if (precision recall) else 0 rule_precision rule_hit_tp / (rule_hit_tp rule_hit_fp) if (rule_hit_tp rule_hit_fp) else 0 rule_recall rule_hit_tp / (rule_hit_tp rule_hit_fn) if (rule_hit_tp rule_hit_fn) else 0 rule_f1 2 * rule_precision * rule_recall / (rule_precision rule_recall) if (rule_precision rule_recall) else 0 format_rate format_ok / len(golds) return { violation_precision: round(precision, 4), violation_recall: round(recall, 4), violation_f1: round(f1, 4), rule_hit_precision: round(rule_precision, 4), rule_hit_recall: round(rule_recall, 4), rule_hit_f1: round(rule_f1, 4), format_rate: round(format_rate, 4) } def main(dataset_path): rules load_rules() items load_dataset(dataset_path) rules_text \n.join([f[{r[rule_id]}] {r[content]} for r in rules]) predictions [evaluate_item(item, rules_text) for item in items] metrics compute_metrics(predictions, items) print(json.dumps(metrics, ensure_asciiFalse, indent2))运行方式python evaluate.py benchmark_final.jsonl脚本会输出类似下面的结果{ violation_precision: 0.7213, violation_recall: 0.6842, violation_f1: 0.7023, rule_hit_precision: 0.5124, rule_hit_recall: 0.4467, rule_hit_f1: 0.4774, format_rate: 0.9850 }4.3 结果解读从上面的示例结果可以看到一个典型现象违规判定 F1 尚可但规则级命中率偏低。这说明模型很多时候“判断对了结果但引用规则时出了问题”它会给出violation却引用了错误的规则编号或者干脆给空数组。这种情况在业务上是不可接受的因为审查结论必须可追溯。如果不知道违反了哪一条规则就无法整改更无法生成合规证明。因此增强策略的重点首先应该放在规则命中率上其次才是判定准确率。5. 增强策略实战基线评测完成后我们要根据失败样本做针对性增强。下面四类方法是我们实测中提升最明显的按落地成本从低到高排列。5.1 规则感知 Prompting规则感知 PromptingRule-Aware Prompting的核心思想是不再直接让模型“一次性看完再判断”而是让模型先做规则筛选再做文本定位最后给出结论。这是一种简单但有效的两阶段推理。改造后的 prompt 如下# 文件路径prompt_templates.py ENHANCED_PROMPT 你是一名文档合规审查专家。请严格按照以下步骤进行审查 第一步规则筛选 从规则条款中找出与待审查文本相关的所有规则输出规则编号列表。 如果没有相关规则请输出空数组。 第二步逐条比对 针对第一步筛出的每条规则判断文本是否存在违规行为并定位违规位置。 第三步输出结论 按以下 JSON 格式输出最终结果 {{ relevant_rule_ids: [第一步筛出的规则编号], result: pass 或 violation, rule_ids: [判定为违规的规则编号], positions: [违规位置说明], reason: 简要说明判定理由 }} 规则条款 {rules_text} 待审查文本 {content} 这个改动强迫模型“先找规则再下结论”对规则命中率有显著提升。原因是它把“从长文本里找对应规则”这一步显式化减少了模型直接判断时跳过规则编号的概率。5.2 检索增强规则召回当规则数量超过 50 条时把所有规则全部塞进 prompt 会带来两个问题一是 token 开销大二是模型注意力被无关规则干扰。更稳妥的做法是先用检索手段筛选出 top-k 条候选规则再交给模型审查。我们用一个混合检索示例来演示。先按关键词匹配再补充向量检索。这里为了不引入大量重依赖只展示思路生产环境建议使用嵌入式向量库。# 文件路径retrieve_rules.py import json import re from difflib import SequenceMatcher def keyword_score(rule, text): 基于关键词的简单匹配得分 score 0 for kw in rule.get(keywords, []): if kw in text: score 1 return score def similarity_score(rule, text): 基于字符重叠的近似相似度 return SequenceMatcher(None, rule[content], text).ratio() def retrieve_top_rules(rules, text, k5): scored [] for rule in rules: kw keyword_score(rule, text) sim similarity_score(rule, text) # 关键词命中权重更高 total kw * 2 sim * 0.5 scored.append((total, rule)) scored.sort(reverseTrue, keylambda x: x[0]) return [rule for _, rule in scored[:k]] def load_rules(pathrules.json): with open(path, r, encodingutf-8) as f: return json.load(f) def build_rules_text(rules): return \n.join([f[{r[rule_id]}] {r[content]} for r in rules]) if __name__ __main__: rules load_rules() sample_text 该产品经过严格测试绝对安全无任何风险请放心使用。 top_rules retrieve_top_rules(rules, sample_text, k2) print(build_rules_text(top_rules))实际生产环境关键词匹配的覆盖率有限尤其是规则之间用词差异较大时需要引入向量召回。可以使用常见的 embedding 模型将规则和文本编码为向量然后计算余弦相似度。这里不展开特定库的接入基本流程是离线为每条规则生成向量存入向量库。在线为待审文本生成向量。检索 top-k 相似规则。和关键词召回结果做合并去重。检索增强最大的好处是让模型不再面对上百条规则只需要聚焦最相关的几条误判率会下降而且每次调用的 token 成本也显著降低。5.3 结构化输出与规则校验即使 prompt 里要求 JSON 输出模型偶尔还是会输出非 JSON 内容。我们在工程上增加一层“输出校验与修复”逻辑# 文件路径parse_utils.py import json import re def safe_json_parse(text): 尝试多种方式解析模型输出 if not text: return None candidates [ text.strip(), text.strip().replace(json, ).replace(, ).strip(), ] for candidate in candidates: try: return json.loads(candidate) except json.JSONDecodeError: continue match re.search(r\{.*\}, text, re.S) if match: try: return json.loads(match.group(0)) except json.JSONDecodeError: return None return None def validate_prediction(pred): 校验模型输出结构 if not isinstance(pred, dict): return False, output is not a dict if result not in pred: return False, missing result field if pred[result] not in (pass, violation): return False, invalid result value if rule_ids not in pred: return False, missing rule_ids field if positions not in pred: return False, missing positions field return True, ok校验失败时不要把整个流程终止。我们建议对无效输出做一次重试最多重试 2 次如果仍然失败记入format_error.log供后续分析。5.4 多轮投票自洽性增强大模型在规则判定任务上的输出存在随机性。即使 temperature 设为 0不同前缀或模型版本也可能导致输出差异。对于“违规/合规”这种高风险结论我们建议采用多轮投票机制对同一条文本用相同 prompt 调用 N 次例如 N5。统计violation和pass的次数。选择投票数最多的结果作为最终结论。如果 5 次结果分散明显标记为“待人工复核”。投票机制不改变模型本身的推理能力但能降低随机噪声尤其适合那些边界模糊的样本。代价是调用次数增加实际落地时可以只在规则命中数较低或模型置信度较低时启用。下面是一段完整的增强 pipeline 示例融合了规则检索、两阶段 prompt、JSON 校验和投票策略# 文件路径review_pipeline.py import json from collections import Counter from openai import OpenAI from prompt_templates import ENHANCED_PROMPT from retrieve_rules import load_rules, retrieve_top_rules from parse_utils import safe_json_parse, validate_prediction client OpenAI( base_urlhttps://your-compatible-api.example.com/v1, api_keyyour-api-key ) def single_review(text, rules_text): prompt ENHANCED_PROMPT.format(rules_textrules_text, contenttext) resp client.chat.completions.create( modelyour-model-name, messages[{role: user, content: prompt}], temperature0.3 ) parsed safe_json_parse(resp.choices[0].message.content) ok, _ validate_prediction(parsed) if parsed else (False, parse failed) return parsed if ok else None def review_with_vote(text, rules, vote_times3, top_k5): rules_text build_rules_text(retrieve_top_rules(rules, text, ktop_k)) results [] for _ in range(vote_times): pred single_review(text, rules_text) if pred: results.append(pred) if not results: return {result: error, reason: no valid output after retries} result_counter Counter(r[result] for r in results) final_result result_counter.most_common(1)[0][0] if result_counter.most_common(1)[0][1] (vote_times 1) // 2 1: final_result manual_review final_rule_ids sorted(set().union(*[set(r.get(rule_ids, [])) for r in results])) return { result: final_result, rule_ids: final_rule_ids, votes: dict(result_counter), reason: [vote] | .join(r.get(reason, ) for r in results[:2]) } def batch_review(dataset_path, output_path): rules load_rules() with open(dataset_path, r, encodingutf-8) as f: items [json.loads(line) for line in f if line.strip()] outputs [] for item in items: pred review_with_vote(item[text], rules) outputs.append({ rule_id: item[rule_id], gold_label: item[label], text: item[text], pred: pred }) with open(output_path, w, encodingutf-8) as f: for o in outputs: f.write(json.dumps(o, ensure_asciiFalse) \n) print(json.dumps({ total: len(outputs), manual_review: sum(1 for o in outputs if o[pred][result] manual_review) }, ensure_asciiFalse, indent2)) if __name__ __main__: batch_review(benchmark_final.jsonl, predictions_enhanced.jsonl)这段代码里我们把“检索增强 两阶段推理 投票”放进了同一个调用链。注意投票阈值设计当 3 次投票结果不一致且最高票数未超过 2 票时我们会标记为manual_review避免模型低置信度结论直接进入业务系统。6. 完整实验与对比分析6.1 实验设计为了验证增强效果我们建议做一个规范化对比实验至少包含三组设置基线组基础 prompt全部规则直接塞入不检索不投票。规则感知组两阶段 prompt全部规则直接塞入。增强组两阶段 prompt 检索增强 top-5 投票 3 次。三组使用相同的评测集相同模型相同温度设置。只有保证变量单一增强效果对比才有意义。6.2 预期结果表下面是一张典型的结果对比表。注意这里数值仅用于说明实验报告写法不是某个具体模型的权威成绩。实验设置违规判定 F1规则命中 F1格式遵循率基线组0.70230.47740.9850规则感知组0.76110.60480.9802增强组0.81450.76330.9776从趋势上看规则感知 prompt 主要提升的是规则命中率投票机制帮助稳定了违规判定 F1检索增强则对规则命中率的贡献最大。如果你的实验结果和这个趋势不完全一致也很正常不同模型能力、不同规则库复杂度都会影响提升幅度。6.3 失败案例分析每次实验后应该重点看失败样本。我们常见的失败类型有三种第一种是“规则引用遗漏”文本确实违规模型也判断为 violation但rule_ids为空。这种情况说明模型没有把判定过程显式关联到规则需要靠两阶段 prompt 或强制要求输出引用规则编号来修正。第二种是“多规则混淆”两个规则非常相似时模型引用了错误的规则编号。此时可以尝试在规则库中为相似规则增加互斥说明比如在规则原文后补充“本规则不适用于 X 类文本”。第三种是“正例误判”合规文本被误判为违规。通常是因为规则中的否定词处理不好比如“不得出现绝对安全用语”被理解为“出现绝对安全用语是不合规的”模型却把“不含绝对安全用语”的文本判为违规。这类问题需要检查规则文本的约束类型描述是否清晰也可以考虑在 prompt 中显式给出must_not类规则的判断逻辑。7. 常见问题与排查思路在实际运行过程中我们整理了一些高频问题统一列成表格供参考。问题现象常见原因解决思路模型输出不是合法 JSON模型返回了解释文字或 Markdown 包裹使用 safe_json_parse 兜底解析增加格式重试在 prompt 中强调“只能输出 JSON”违规判定正确但 rule_ids 为空模型未将结果关联到规则改用规则感知 Prompting强制输出相关规则编号规则数量多时 token 超限全部规则塞入 prompt 导致上下文超长引入检索增强只传入 top-k 规则或者对规则按类别分桶相同输入重复调用结果不一致模型采样随机性降低 temperature使用多轮投票机制固定随机种子部分接口支持自动生成的正例实际不符合规则LLM 生成样本存在偏差加入人工校验环节扩大正例抽样比例规则相似导致引用错误规则库缺少互斥说明为相似规则补充适用场景说明或在评测集中单独划分相似规则组检索召回不到正确规则关键词设计过窄增加向量召回检查规则 keywords 是否覆盖同义表达投票结果仍然分歧明显样本本身边界模糊标记为 manual_review进入人工复核流程不强行给出结论排查时有一个建议不要一上来就调模型。先打印几个失败样本人工快速判断是 prompt 问题、规则库问题还是模型本身能力边界问题。很多时候多花十分钟看样本比反复调 prompt 更有效。8. 最佳实践与工程建议8.1 规则库治理是重中之重规则密集型审查系统的上限往往不取决于模型而取决于规则库质量。我们建议把规则库当作代码一样管理有版本号、有变更记录、有权限控制。每条规则都应该包含来源、生效日期、维护人。规则之间如果存在冲突应该通过优先级字段解决例如“专门规则优先于通用规则”。规则文本的写法也要注意。用词尽量精确避免模糊表述。比如“不得使用绝对化用语”比“注意宣传用语规范”更容易被模型理解和判定。每条规则尽量拆分为原子规则而不是把多个约束塞进同一条里。原子规则更容易检索、更容易解释、评测时也更容易定位错误。8.2 建立人工复核闭环在合规审查场景中LLM 的定位应该是“辅助预审”而不是“自动终审”。我们建议设计三类输出状态pass模型高置信度通过进入普通流程。violation模型高置信度违规进入整改流程。manual_review模型置信度不足或投票不一致必须人工复核。在工程上manual_review这类的存量最好控制在总样本的 5% 到 15% 之间。如果比例过高说明基准模型还没有到可以上线的程度如果过低可能说明阈值设置过松漏掉了风险样本。8.3 评测集要动态演进评测集不是一次性做好的。随着规则库更新应该补充新的评测样本当模型暴露出新的失败模式时也要把对应样本加入回归集。建议每次修改 prompt、检索策略或升级模型前都跑一遍完整评测集用自动化脚本对比指标变化。这样能避免“这次改好了 A 类问题却弄坏了 B 类问题”的回归风险。8.4 成本与性能平衡增强策略通常会带来额外的 token 消耗和调用延迟。实测中检索增强反而能降低单次调用的成本因为模型不再需要处理全量规则。投票机制则是成倍增加成本因此可以设计成“动态投票”只有规则命中数低于阈值或模型置信度低时才启用投票。此外对长文档应该先做章节切分、分段审查而不是让模型一次性读完整个文档这样既能降低漏检也能避免上下文过长带来的注意力衰减。8.5 保留可追溯日志合规审查的应用场景非常看重可追溯性。每次调用都应该记录模型版本、prompt 模板版本、规则库版本、输入文本、原始输出、最终结论。这样一旦上线后出现争议可以完整复盘。我们在线下项目中遇到过“模型结论和人工复核不一致需要翻历史日志”的场景如果没有版本记录几乎无法定位根因。推荐至少记录以下字段{ trace_id: uuid, model: qwen-72b-chat, prompt_version: v2.3, rule_version: 2025.01, input_text: 待审文本摘要或完整内容, raw_output: 模型原始输出, final_result: pass / violation / manual_review, reviewer: admin, timestamp: 2025-01-15T10:00:0008:00 }9. 总结与下一步这篇文章围绕“LLM 做规则密集型标准文档审查”这件事完整讨论了从基准构建到增强落地的闭环流程。核心是先把任务定义成结构化输出问题然后建立带标准答案的评测集用可量化的指标发现问题再通过规则感知 prompt、检索增强、投票自洽等方式逐步提升。不要试图一次性把所有优化手段全部加上建议从一个最小闭环开始选 5 到 10 条规则构造 200 条左右的评测样本跑通基线再逐步加增强策略。等整个流程跑通后再扩大规则库和数据量这样每一步的效果都清晰可见也不会在一开始就陷入“规则太多、模型太乱、错误无法定位”的泥潭。如果你正在做类似的合规审查、标准比对或规则校验项目可以先从本文的构建评测集和基线评测部分入手把“模型当前表现如何”这个问题回答清楚然后再决定有没有必要引入 RAG、投票等复杂策略。如果要进一步深挖还可以尝试在规则理解环节引入思维链推理或者针对不同规则类型分别训练轻量级分类器把 LLM 作为最后裁决层。希望这套实践方法对你有所启发也欢迎在实际项目中按自己的数据形态做调整和验证。 LLM规则密集型审查实战：基准评测与增强策略
标准文档与合规审查场景中最让人头疼的一类任务往往不是“读不懂”而是“看得过来却查不干净”。当审查对象是几十页甚至上百页的技术规范、产品标准、安全条款时人眼逐条对照规则很容易遗漏尤其是那些“必须”“严禁”“不应用”“应满足”这类表意强硬的条款。最近我们在做 LLM 辅助审查的落地实验时遇到了一个更具体的问题模型看起来能读懂规则但它到底有没有“真的按规则”在审不同模型、不同提示词模板之间的差别有多大如果效果不好又应该如何增强这篇文章会把我们构建基准评测和增强方案的过程整理成一套可复用的实战方法覆盖任务定义、数据集构建、评测指标、基线实验、增强策略和常见坑点适合正在做 LLM 评估、合规审查类应用的开发者参考。1. 背景与核心概念1.1 什么是规则密集型审查规则密集型审查英文常称为 Rule-Intensive Review指的是这样一类 NLP 任务模型需要根据一组事先给定的、约定好的规则条款对输入文本进行判定判断文本是否违反规则并指出违反的是哪一条、具体位置在哪里、理由是什么。这类任务和普通文本分类、情感分析有本质区别。普通分类任务只需要判断“正面/负面”“垃圾/正常”规则密集型审查则要求模型做到三件事规则匹配找到与当前文本相关的规则条款。违规判定判断文本是否真的违反该条款。定位与解释指出违规位置并给出可复核的解释。举个例子假设有一条规则是“合同中的金额应当同时包含大写和小写”。模型审查一段合同文本时不仅要回答“是否合规”还要回答“如果不合规是哪一处金额缺少大写形式”最好还能引用规则原文。这就对模型的逻辑能力和文本细粒度理解能力提出了很高要求。国家标准文档、行业规范、企业内部制度、产品检测标准等场景都有大量的这种规则密集型审查需求。人工审查虽然准确但成本高、速度慢而且面对上百条规则时容易出现疲劳忽略LLM 则具备较强的文本理解能力和规则形式的泛化能力适合作为预审工具但前提是必须经过系统评测知道它在不同规则类型上的能力边界。1.2 LLM 用于标准审查的三个挑战用大模型来做规则密集型审查表面上看起来很简单把规则和待审文本一起丢给模型即可。真正落地时会遇到三个挑战。第一个挑战是规则记忆不稳定。模型不是数据库它并不能精确“记住”每一条规则的原文。上下文过长时早期规则可能被遗忘或者被后续内容干扰。尤其当规则存在相似条款时模型容易混淆。第二个挑战是判定标准不统一。不同模型对“违反”“不符合”“建议但不强制”这类语义强度的理解不一致。同一个违规样本不同模型可能给出完全不同结论甚至连同一个模型重复调用两次结果都可能有波动。第三个挑战是评测困难。如果不知道正确答案就无法判断模型输出是对是错。而人工标注规则密集型数据集的成本很高需要专业人员逐条审核普通众包很难保证质量。所以构建一套可复用的基准测试Benchmark和增强方案是 LLM 落地这类任务的第一步。1.3 为什么先要有 Benchmark 再谈增强Benchmark 的本质是“标准答案集 评测指标”。它的价值不只是打分而是告诉我们三个关键信息当前模型在哪些规则类型上表现好哪些规则类型上表现差。提示词和增强策略的改动到底带来了多少真实提升。当效果不达标时问题出在规则理解、文本定位还是输出格式。我们在实践中发现很多团队一开始就追求把模型“调得更聪明”但缺少评测体系导致改了一个 prompt 也说不清效果是变好还是变差。先建立 Benchmark再基于失败样本做增强才是更高效的方式。2. 问题定义与评测体系设计2.1 任务形式化我们将规则密集型审查任务形式化如下输入 1规则集合 R {r1, r2, ..., rn}每条规则包含唯一编号、正文、类别、约束强度。输入 2待审文本 D可以是一段章节、一个条款、一份文档片段。输出一组审查结论 C {c1, c2, ..., cm}每个结论包含判定结果pass / fail / uncertain。命中规则编号与判定相关的规则。违规位置原文字符区间或行号。解释给出理由便于人工复核。这种结构化输出设计很重要它可以让模型结论被程序解析然后计算指标而不是停留在“看着合理”的层面。2.2 评测维度与指标我们建议从四个维度来评测模型规则级命中率Rule Hit Rate对于每条规则模型是否在需要时主动引用它。计算方式被正确引用的规则数 / 应命中规则总数。这个指标反映规则召回能力。违规判定 F1将违规判定视为二分类问题计算 TP、FP、FN然后得到精确率、召回率、F1。这是最核心的指标。定位准确率Location Accuracy模型给出的违规位置与真实位置是否一致。可以按区间交集比例打分例如 IoU 大于 0.5 算定位成功。格式遵循率Format Compliance模型输出是否可被 JSON 解析必填字段是否完整。这是工程可用性的基础指标。2.3 数据集分层规则密集场景的数据集应该分层设计我们建议至少包含三层简单层明确规定、单一规则、文本较短。中等层多条规则同时适用文本较长需要定位。困难层规则之间存在相似性、文本有歧义、需要结合上下文推断。分层的好处是可以精确看出增强手段到底解决了哪一层的问题。例如RAG 增强可能显著提升困难层规则召回但简单层提升不大那么说明瓶颈在规则检索而不是基础理解。3. 环境准备与基准数据集构建3.1 环境与依赖本文示例以 Python 为主要语言使用 OpenAI 兼容接口调用模型向量检索以简单的关键词/向量混合方式演示。版本不需要完全照搬建议按实际项目调整。python -m venv venv source venv/bin/activate pip install openai pandas numpy tiktoken这里我使用 OpenAI 兼容接口但示例代码中的client.chat.completions.create调用方式只要是兼容接口的模型都可以复用。如果你使用本地模型例如基于 vLLM 部署的 Qwen、ChatGLM、DeepSeek 等只需要把base_url和api_key改成本地服务的地址即可。3.2 规则库构建规则库是整套系统的基石。我们用一个 JSON 文件来存储规则每一条规则包含以下几个字段[ { rule_id: R001, category: 格式要求, constraint_type: must, content: 技术文档中的计量单位应使用国际单位制符号如 m、kg、s不得使用中文单位名称与符号混排。, keywords: [计量单位, 国际单位制, 混排] }, { rule_id: R002, category: 安全条款, constraint_type: must_not, content: 产品说明书中不得出现“绝对安全”“零风险”等绝对化承诺用语。, keywords: [绝对安全, 零风险, 绝对化] } ]字段含义如下rule_id规则唯一编号用于结果追踪。category规则所属类别。constraint_type约束类型must表示必须满足must_not表示禁止出现。content规则正文是判断依据。keywords关键词列表用于快速检索候选规则。实际项目中规则数量可能上百条甚至上千条。建议为每条规则设置维护负责人和有效期避免过期规则继续参与审查。3.3 违规样本自动注入人工构造违规样本非常耗时。我们可以借助 LLM 本身来生成候选样本再进行人工校验。核心思路是从规则库中随机抽取规则让 LLM 根据规则原文生成一段“包含违规内容”的文档片段。我们写一个build_benchmark.py脚本来自动生成数据。为了避免模型自我生成时出现“不会犯错”的问题我们采取“改写生成”的策略先生成合规文本再用专门的注入提示词把违规内容混入。# 文件路径build_benchmark.py import json import random from openai import OpenAI client OpenAI( base_urlhttps://your-compatible-api.example.com/v1, api_keyyour-api-key ) RULES [ { rule_id: R001, category: 格式要求, constraint_type: must, content: 技术文档中的计量单位应使用国际单位制符号如 m、kg、s不得使用中文单位名称与符号混排。 }, { rule_id: R002, category: 安全条款, constraint_type: must_not, content: 产品说明书中不得出现“绝对安全”“零风险”等绝对化承诺用语。 } ] def generate_positive(rule): 生成合规文本片段 prompt f请根据以下规则生成一段完全符合规则的文档片段内容要求自然、具体不少于 80 字。 规则{rule[content]} 只输出文本不要输出解释。 resp client.chat.completions.create( modelyour-model-name, messages[{role: user, content: prompt}], temperature0.7 ) return resp.choices[0].message.content.strip() def generate_negative(rule): 生成违规文本片段 prompt f请根据以下规则生成一段明显违反规则的文档片段内容要求自然、具体不少于 80 字。 规则{rule[content]} 注意你的输出应当是违规文本本身不要写任何解释、标注或说明。 只输出文本不要输出解释。 resp client.chat.completions.create( modelyour-model-name, messages[{role: user, content: prompt}], temperature0.9 ) return resp.choices[0].message.content.strip() def build_dataset(): dataset [] for rule in RULES: for i in range(10): # 每条规则生成 10 个正例和 10 个负例 pos generate_positive(rule) neg generate_negative(rule) dataset.append({ rule_id: rule[rule_id], text: neg, label: violation, source: auto_generated }) dataset.append({ rule_id: rule[rule_id], text: pos, label: pass, source: auto_generated }) print(fprogress: rule {rule[rule_id]}, sample {i}) with open(benchmark_raw.jsonl, w, encodingutf-8) as f: for item in dataset: f.write(json.dumps(item, ensure_asciiFalse) \n) if __name__ __main__: build_dataset()这里有一个非常重要的原则自动生成的数据不能直接用来当最终评测集必须经过人工校验。LLM 生成的“违规样本”有可能实际上并不违规或者只违规了一部分。因此生成完后需要至少两名熟练人员独立标注存在分歧时讨论确认。校验阶段我建议对照下面两个问题负例是否的确能被某条规则“一票否决”正例是否真的没有任何一处命中规则只有通过校验的样本才能进入benchmark_final.jsonl。4. 基线评测实现有了数据集之后下一步是跑通基线评测。所谓基线是指“不做过多的工程优化只用一份简单 prompt 加上结构化输出要求”的模型调用方式。基线结果的意义是给后续增强策略提供对比参照。4.1 Prompt 基线模板基线 prompt 设计要注意三点角色明确、规则与文本分隔清晰、输出格式严格约束。# 文件路径prompt_templates.py BASE_PROMPT 你是一名文档合规审查专家。你的任务是根据给定的规则条款对文本片段进行合规性审查。 规则条款 {rules_text} 待审查文本 {content} 请按以下 JSON 格式输出审查结论 {{ result: pass 或 violation, rule_ids: [命中的规则编号没有则为空数组], positions: [违规位置说明没有则为空数组], reason: 简要说明判定理由 }} 注意 1. 只能输出 JSON不要输出多余解释。 2. result 为 pass 时rule_ids、positions 应为空数组。 3. violations 判定请严格依据规则条款。 可以看到我们刻意让基线的输出结构化和评测脚本对齐但 prompt 中并没有加入“先找相关规则再判定”的两阶段引导。这样能更真实反映模型的天然能力。4.2 评测脚本评测脚本负责调用模型、解析输出、计算指标。核心实现如下# 文件路径evaluate.py import json import re import sys from openai import OpenAI client OpenAI( base_urlhttps://your-compatible-api.example.com/v1, api_keyyour-api-key ) def parse_model_output(output): 从模型输出中解析 JSON容忍少量前后缀内容 text output.strip() match re.search(r\{.*\}, text, re.S) if not match: return None try: return json.loads(match.group(0)) except json.JSONDecodeError: return None def evaluate_item(item, rules_text): prompt BASE_PROMPT.format(rules_textrules_text, contentitem[text]) resp client.chat.completions.create( modelyour-model-name, messages[{role: user, content: prompt}], temperature0.2 ) return parse_model_output(resp.choices[0].message.content) def compute_metrics(predictions, golds): tp fp fn tn 0 rule_hit_tp rule_hit_fp rule_hit_fn 0 format_ok 0 for pred, gold in zip(predictions, golds): # 判断输出格式 if pred is not None and result in pred: format_ok 1 # 判断违规识别 pred_label pred.get(result) if pred else invalid gold_label gold[label] if pred_label violation and gold_label violation: tp 1 elif pred_label violation and gold_label pass: fp 1 elif pred_label pass and gold_label violation: fn 1 elif pred_label pass and gold_label pass: tn 1 # 规则命中判断 pred_rule_ids set(pred.get(rule_ids, [])) if pred else set() gold_rule_ids {gold[rule_id]} if pred_rule_ids gold_rule_ids: rule_hit_tp 1 else: if gold_label violation: rule_hit_fn 1 else: rule_hit_fp 1 precision tp / (tp fp) if (tp fp) else 0 recall tp / (tp fn) if (tp fn) else 0 f1 2 * precision * recall / (precision recall) if (precision recall) else 0 rule_precision rule_hit_tp / (rule_hit_tp rule_hit_fp) if (rule_hit_tp rule_hit_fp) else 0 rule_recall rule_hit_tp / (rule_hit_tp rule_hit_fn) if (rule_hit_tp rule_hit_fn) else 0 rule_f1 2 * rule_precision * rule_recall / (rule_precision rule_recall) if (rule_precision rule_recall) else 0 format_rate format_ok / len(golds) return { violation_precision: round(precision, 4), violation_recall: round(recall, 4), violation_f1: round(f1, 4), rule_hit_precision: round(rule_precision, 4), rule_hit_recall: round(rule_recall, 4), rule_hit_f1: round(rule_f1, 4), format_rate: round(format_rate, 4) } def main(dataset_path): rules load_rules() items load_dataset(dataset_path) rules_text \n.join([f[{r[rule_id]}] {r[content]} for r in rules]) predictions [evaluate_item(item, rules_text) for item in items] metrics compute_metrics(predictions, items) print(json.dumps(metrics, ensure_asciiFalse, indent2))运行方式python evaluate.py benchmark_final.jsonl脚本会输出类似下面的结果{ violation_precision: 0.7213, violation_recall: 0.6842, violation_f1: 0.7023, rule_hit_precision: 0.5124, rule_hit_recall: 0.4467, rule_hit_f1: 0.4774, format_rate: 0.9850 }4.3 结果解读从上面的示例结果可以看到一个典型现象违规判定 F1 尚可但规则级命中率偏低。这说明模型很多时候“判断对了结果但引用规则时出了问题”它会给出violation却引用了错误的规则编号或者干脆给空数组。这种情况在业务上是不可接受的因为审查结论必须可追溯。如果不知道违反了哪一条规则就无法整改更无法生成合规证明。因此增强策略的重点首先应该放在规则命中率上其次才是判定准确率。5. 增强策略实战基线评测完成后我们要根据失败样本做针对性增强。下面四类方法是我们实测中提升最明显的按落地成本从低到高排列。5.1 规则感知 Prompting规则感知 PromptingRule-Aware Prompting的核心思想是不再直接让模型“一次性看完再判断”而是让模型先做规则筛选再做文本定位最后给出结论。这是一种简单但有效的两阶段推理。改造后的 prompt 如下# 文件路径prompt_templates.py ENHANCED_PROMPT 你是一名文档合规审查专家。请严格按照以下步骤进行审查 第一步规则筛选 从规则条款中找出与待审查文本相关的所有规则输出规则编号列表。 如果没有相关规则请输出空数组。 第二步逐条比对 针对第一步筛出的每条规则判断文本是否存在违规行为并定位违规位置。 第三步输出结论 按以下 JSON 格式输出最终结果 {{ relevant_rule_ids: [第一步筛出的规则编号], result: pass 或 violation, rule_ids: [判定为违规的规则编号], positions: [违规位置说明], reason: 简要说明判定理由 }} 规则条款 {rules_text} 待审查文本 {content} 这个改动强迫模型“先找规则再下结论”对规则命中率有显著提升。原因是它把“从长文本里找对应规则”这一步显式化减少了模型直接判断时跳过规则编号的概率。5.2 检索增强规则召回当规则数量超过 50 条时把所有规则全部塞进 prompt 会带来两个问题一是 token 开销大二是模型注意力被无关规则干扰。更稳妥的做法是先用检索手段筛选出 top-k 条候选规则再交给模型审查。我们用一个混合检索示例来演示。先按关键词匹配再补充向量检索。这里为了不引入大量重依赖只展示思路生产环境建议使用嵌入式向量库。# 文件路径retrieve_rules.py import json import re from difflib import SequenceMatcher def keyword_score(rule, text): 基于关键词的简单匹配得分 score 0 for kw in rule.get(keywords, []): if kw in text: score 1 return score def similarity_score(rule, text): 基于字符重叠的近似相似度 return SequenceMatcher(None, rule[content], text).ratio() def retrieve_top_rules(rules, text, k5): scored [] for rule in rules: kw keyword_score(rule, text) sim similarity_score(rule, text) # 关键词命中权重更高 total kw * 2 sim * 0.5 scored.append((total, rule)) scored.sort(reverseTrue, keylambda x: x[0]) return [rule for _, rule in scored[:k]] def load_rules(pathrules.json): with open(path, r, encodingutf-8) as f: return json.load(f) def build_rules_text(rules): return \n.join([f[{r[rule_id]}] {r[content]} for r in rules]) if __name__ __main__: rules load_rules() sample_text 该产品经过严格测试绝对安全无任何风险请放心使用。 top_rules retrieve_top_rules(rules, sample_text, k2) print(build_rules_text(top_rules))实际生产环境关键词匹配的覆盖率有限尤其是规则之间用词差异较大时需要引入向量召回。可以使用常见的 embedding 模型将规则和文本编码为向量然后计算余弦相似度。这里不展开特定库的接入基本流程是离线为每条规则生成向量存入向量库。在线为待审文本生成向量。检索 top-k 相似规则。和关键词召回结果做合并去重。检索增强最大的好处是让模型不再面对上百条规则只需要聚焦最相关的几条误判率会下降而且每次调用的 token 成本也显著降低。5.3 结构化输出与规则校验即使 prompt 里要求 JSON 输出模型偶尔还是会输出非 JSON 内容。我们在工程上增加一层“输出校验与修复”逻辑# 文件路径parse_utils.py import json import re def safe_json_parse(text): 尝试多种方式解析模型输出 if not text: return None candidates [ text.strip(), text.strip().replace(json, ).replace(, ).strip(), ] for candidate in candidates: try: return json.loads(candidate) except json.JSONDecodeError: continue match re.search(r\{.*\}, text, re.S) if match: try: return json.loads(match.group(0)) except json.JSONDecodeError: return None return None def validate_prediction(pred): 校验模型输出结构 if not isinstance(pred, dict): return False, output is not a dict if result not in pred: return False, missing result field if pred[result] not in (pass, violation): return False, invalid result value if rule_ids not in pred: return False, missing rule_ids field if positions not in pred: return False, missing positions field return True, ok校验失败时不要把整个流程终止。我们建议对无效输出做一次重试最多重试 2 次如果仍然失败记入format_error.log供后续分析。5.4 多轮投票自洽性增强大模型在规则判定任务上的输出存在随机性。即使 temperature 设为 0不同前缀或模型版本也可能导致输出差异。对于“违规/合规”这种高风险结论我们建议采用多轮投票机制对同一条文本用相同 prompt 调用 N 次例如 N5。统计violation和pass的次数。选择投票数最多的结果作为最终结论。如果 5 次结果分散明显标记为“待人工复核”。投票机制不改变模型本身的推理能力但能降低随机噪声尤其适合那些边界模糊的样本。代价是调用次数增加实际落地时可以只在规则命中数较低或模型置信度较低时启用。下面是一段完整的增强 pipeline 示例融合了规则检索、两阶段 prompt、JSON 校验和投票策略# 文件路径review_pipeline.py import json from collections import Counter from openai import OpenAI from prompt_templates import ENHANCED_PROMPT from retrieve_rules import load_rules, retrieve_top_rules from parse_utils import safe_json_parse, validate_prediction client OpenAI( base_urlhttps://your-compatible-api.example.com/v1, api_keyyour-api-key ) def single_review(text, rules_text): prompt ENHANCED_PROMPT.format(rules_textrules_text, contenttext) resp client.chat.completions.create( modelyour-model-name, messages[{role: user, content: prompt}], temperature0.3 ) parsed safe_json_parse(resp.choices[0].message.content) ok, _ validate_prediction(parsed) if parsed else (False, parse failed) return parsed if ok else None def review_with_vote(text, rules, vote_times3, top_k5): rules_text build_rules_text(retrieve_top_rules(rules, text, ktop_k)) results [] for _ in range(vote_times): pred single_review(text, rules_text) if pred: results.append(pred) if not results: return {result: error, reason: no valid output after retries} result_counter Counter(r[result] for r in results) final_result result_counter.most_common(1)[0][0] if result_counter.most_common(1)[0][1] (vote_times 1) // 2 1: final_result manual_review final_rule_ids sorted(set().union(*[set(r.get(rule_ids, [])) for r in results])) return { result: final_result, rule_ids: final_rule_ids, votes: dict(result_counter), reason: [vote] | .join(r.get(reason, ) for r in results[:2]) } def batch_review(dataset_path, output_path): rules load_rules() with open(dataset_path, r, encodingutf-8) as f: items [json.loads(line) for line in f if line.strip()] outputs [] for item in items: pred review_with_vote(item[text], rules) outputs.append({ rule_id: item[rule_id], gold_label: item[label], text: item[text], pred: pred }) with open(output_path, w, encodingutf-8) as f: for o in outputs: f.write(json.dumps(o, ensure_asciiFalse) \n) print(json.dumps({ total: len(outputs), manual_review: sum(1 for o in outputs if o[pred][result] manual_review) }, ensure_asciiFalse, indent2)) if __name__ __main__: batch_review(benchmark_final.jsonl, predictions_enhanced.jsonl)这段代码里我们把“检索增强 两阶段推理 投票”放进了同一个调用链。注意投票阈值设计当 3 次投票结果不一致且最高票数未超过 2 票时我们会标记为manual_review避免模型低置信度结论直接进入业务系统。6. 完整实验与对比分析6.1 实验设计为了验证增强效果我们建议做一个规范化对比实验至少包含三组设置基线组基础 prompt全部规则直接塞入不检索不投票。规则感知组两阶段 prompt全部规则直接塞入。增强组两阶段 prompt 检索增强 top-5 投票 3 次。三组使用相同的评测集相同模型相同温度设置。只有保证变量单一增强效果对比才有意义。6.2 预期结果表下面是一张典型的结果对比表。注意这里数值仅用于说明实验报告写法不是某个具体模型的权威成绩。实验设置违规判定 F1规则命中 F1格式遵循率基线组0.70230.47740.9850规则感知组0.76110.60480.9802增强组0.81450.76330.9776从趋势上看规则感知 prompt 主要提升的是规则命中率投票机制帮助稳定了违规判定 F1检索增强则对规则命中率的贡献最大。如果你的实验结果和这个趋势不完全一致也很正常不同模型能力、不同规则库复杂度都会影响提升幅度。6.3 失败案例分析每次实验后应该重点看失败样本。我们常见的失败类型有三种第一种是“规则引用遗漏”文本确实违规模型也判断为 violation但rule_ids为空。这种情况说明模型没有把判定过程显式关联到规则需要靠两阶段 prompt 或强制要求输出引用规则编号来修正。第二种是“多规则混淆”两个规则非常相似时模型引用了错误的规则编号。此时可以尝试在规则库中为相似规则增加互斥说明比如在规则原文后补充“本规则不适用于 X 类文本”。第三种是“正例误判”合规文本被误判为违规。通常是因为规则中的否定词处理不好比如“不得出现绝对安全用语”被理解为“出现绝对安全用语是不合规的”模型却把“不含绝对安全用语”的文本判为违规。这类问题需要检查规则文本的约束类型描述是否清晰也可以考虑在 prompt 中显式给出must_not类规则的判断逻辑。7. 常见问题与排查思路在实际运行过程中我们整理了一些高频问题统一列成表格供参考。问题现象常见原因解决思路模型输出不是合法 JSON模型返回了解释文字或 Markdown 包裹使用 safe_json_parse 兜底解析增加格式重试在 prompt 中强调“只能输出 JSON”违规判定正确但 rule_ids 为空模型未将结果关联到规则改用规则感知 Prompting强制输出相关规则编号规则数量多时 token 超限全部规则塞入 prompt 导致上下文超长引入检索增强只传入 top-k 规则或者对规则按类别分桶相同输入重复调用结果不一致模型采样随机性降低 temperature使用多轮投票机制固定随机种子部分接口支持自动生成的正例实际不符合规则LLM 生成样本存在偏差加入人工校验环节扩大正例抽样比例规则相似导致引用错误规则库缺少互斥说明为相似规则补充适用场景说明或在评测集中单独划分相似规则组检索召回不到正确规则关键词设计过窄增加向量召回检查规则 keywords 是否覆盖同义表达投票结果仍然分歧明显样本本身边界模糊标记为 manual_review进入人工复核流程不强行给出结论排查时有一个建议不要一上来就调模型。先打印几个失败样本人工快速判断是 prompt 问题、规则库问题还是模型本身能力边界问题。很多时候多花十分钟看样本比反复调 prompt 更有效。8. 最佳实践与工程建议8.1 规则库治理是重中之重规则密集型审查系统的上限往往不取决于模型而取决于规则库质量。我们建议把规则库当作代码一样管理有版本号、有变更记录、有权限控制。每条规则都应该包含来源、生效日期、维护人。规则之间如果存在冲突应该通过优先级字段解决例如“专门规则优先于通用规则”。规则文本的写法也要注意。用词尽量精确避免模糊表述。比如“不得使用绝对化用语”比“注意宣传用语规范”更容易被模型理解和判定。每条规则尽量拆分为原子规则而不是把多个约束塞进同一条里。原子规则更容易检索、更容易解释、评测时也更容易定位错误。8.2 建立人工复核闭环在合规审查场景中LLM 的定位应该是“辅助预审”而不是“自动终审”。我们建议设计三类输出状态pass模型高置信度通过进入普通流程。violation模型高置信度违规进入整改流程。manual_review模型置信度不足或投票不一致必须人工复核。在工程上manual_review这类的存量最好控制在总样本的 5% 到 15% 之间。如果比例过高说明基准模型还没有到可以上线的程度如果过低可能说明阈值设置过松漏掉了风险样本。8.3 评测集要动态演进评测集不是一次性做好的。随着规则库更新应该补充新的评测样本当模型暴露出新的失败模式时也要把对应样本加入回归集。建议每次修改 prompt、检索策略或升级模型前都跑一遍完整评测集用自动化脚本对比指标变化。这样能避免“这次改好了 A 类问题却弄坏了 B 类问题”的回归风险。8.4 成本与性能平衡增强策略通常会带来额外的 token 消耗和调用延迟。实测中检索增强反而能降低单次调用的成本因为模型不再需要处理全量规则。投票机制则是成倍增加成本因此可以设计成“动态投票”只有规则命中数低于阈值或模型置信度低时才启用投票。此外对长文档应该先做章节切分、分段审查而不是让模型一次性读完整个文档这样既能降低漏检也能避免上下文过长带来的注意力衰减。8.5 保留可追溯日志合规审查的应用场景非常看重可追溯性。每次调用都应该记录模型版本、prompt 模板版本、规则库版本、输入文本、原始输出、最终结论。这样一旦上线后出现争议可以完整复盘。我们在线下项目中遇到过“模型结论和人工复核不一致需要翻历史日志”的场景如果没有版本记录几乎无法定位根因。推荐至少记录以下字段{ trace_id: uuid, model: qwen-72b-chat, prompt_version: v2.3, rule_version: 2025.01, input_text: 待审文本摘要或完整内容, raw_output: 模型原始输出, final_result: pass / violation / manual_review, reviewer: admin, timestamp: 2025-01-15T10:00:0008:00 }9. 总结与下一步这篇文章围绕“LLM 做规则密集型标准文档审查”这件事完整讨论了从基准构建到增强落地的闭环流程。核心是先把任务定义成结构化输出问题然后建立带标准答案的评测集用可量化的指标发现问题再通过规则感知 prompt、检索增强、投票自洽等方式逐步提升。不要试图一次性把所有优化手段全部加上建议从一个最小闭环开始选 5 到 10 条规则构造 200 条左右的评测样本跑通基线再逐步加增强策略。等整个流程跑通后再扩大规则库和数据量这样每一步的效果都清晰可见也不会在一开始就陷入“规则太多、模型太乱、错误无法定位”的泥潭。如果你正在做类似的合规审查、标准比对或规则校验项目可以先从本文的构建评测集和基线评测部分入手把“模型当前表现如何”这个问题回答清楚然后再决定有没有必要引入 RAG、投票等复杂策略。如果要进一步深挖还可以尝试在规则理解环节引入思维链推理或者针对不同规则类型分别训练轻量级分类器把 LLM 作为最后裁决层。希望这套实践方法对你有所启发也欢迎在实际项目中按自己的数据形态做调整和验证。