自动合规检查这个方向最近经常能看到一个框架名字CTRAG。它的全称是 In-Context Retrieval-based Framework for Automated Compliance Checking using LLMs简单说就是“用大模型做自动合规检查之前先做上下文检索再让模型基于检索到的条款做判断”。我先说结论CTRAG 不是某一个具体模型也不是一个装好就能用的现成工具它更像一套解决“法规很长、条文很多、结果必须可引用”这类场景的工程方案。如果你正在做图纸合规、合同条款审查、安全检查表核对、规章制度比对或者你已经在用 LLM 做规则判断但发现模型经常答非所问、引用条文不准那这篇文章值得看完。传统人工检查是拿法规一条一条比对效率低、容易漏而且不同人理解还不一样。后来有人做规则引擎把法规翻译成 if-else维护成本又特别高。到了 LLM 时代很多人以为直接让模型“读懂”法规就能判断真跑一轮才会发现法规太长模型记不住条款太多模型会混没有条文原文兜底模型会编。CTRAG 的核心思路是先把法规做成可检索的条款库等真正检查某一条内容时只把最相关的几条条款放进模型上下文再用提示词要求模型必须基于这些条款给结论、给引用。思路听起来不复杂落地时却有不少细节值得拆开讲。1. 先搞清楚 CTRAG 要解决的是哪一类合规检查1.1 传统合规检查为什么麻烦合规检查有一个共同特点判断依据是外部规则不是检查员自己的经验。建筑图纸要对照设计规范合同要对照公司标准条款安全方案要对照行业检查表医保报销要对照报销目录。这些规则通常有几个特点篇幅长。一本规范少则几十页多则几百页根本塞不进模型上下文。条文多且互相引用。经常出现“按第 X 章第 X 条执行”只截取某一条会丢掉关键前置条件。更新频繁。规范修订后旧结论可能直接失效。判断结果必须可追溯。你说不合格要能指出是哪一条不合格而不是“模型觉得不行”。传统规则引擎把法规转成代码最致命的问题是维护成本。法规改一句话代码逻辑、测试用例、输出文案可能都要动。人工检查又受制于投入。所以这个场景一直需要一种“规则变化时只改数据不改主流程”的自动化方案。1.2 为什么不能直接让 LLM 背法规LLM 本身并不适合直接做合规判断。原因不是模型笨而是任务形态不匹配。第一模型上下文窗口有限。你把一整本规范塞进提示词还没开始判断可能已经超出限制就算窗口够大有效注意力也会被无关条文稀释。第二模型训练时见过的法规和当前版本不一定一致。规范更新之后模型记忆里还是旧版本判断结果就会错。第三生成式模型有“补全倾向”面对不确定的条款容易生成看似合理但实际不存在的引用。对合规检查来说幻觉一个不存在的条款编号比判断错误更危险。所以在工程上合规检查不能用“记忆型”方案要用“检索支撑型”方案检查哪一条内容就临时去找对应的规则原文把规则原文放进上下文里让模型现场判断。这就是 CTRAG 里 In-Context Retrieval 的含义。检索到的内容作为“现场证据”进入上下文模型的任务从“回忆规则”变成“根据给定的规则做判断”幻觉空间被大幅压缩。1.3 CTRAG 的定位检索、上下文、生成三件事从框架设计角度看CTRAG 把任务拆成三个相对独立的环节离线阶段把法规文档加工成带编号、带层级、可检索的条款片段建立索引。在线检索拿到待检内容后找出最相关的若干条条款。生成判断把待检内容和检索到的条款拼进提示词让 LLM 输出结构化结论比如“合规 / 不合规 / 不适用”并附上引用条款编号和说明。这种拆法最大的好处是职责分离。法规变了只更新条款库和索引不用改判断逻辑检索不准只调检索参数不用重新设计提示词模型效果不行可以换模型主流程基本不动。这也是这类框架在工程上比“单次大提示词”方案更稳的原因。2. 理解框架核心条款库、检索器和生成器怎么协作2.1 条款库构建把法规变成可检索的结构化片段很多人做 RAG 时习惯按固定字数切文本比如每 500 字一刀。但合规场景不建议这么干。法规有天然结构章、节、条、款、项。最理想的切分单位是“条”必要时把同一条中的多个款项合并成一个完整片段因为一条法规往往包含了完整判断条件切开之后判断语义就断了。条款库里的每一条记录至少应该包含这些字段条款编号例如 3.2.1或者 GB 50016-8.3.4 这类带标准号的格式。条款原文。法规来源例如标准名称、版本号。章节路径例如“第三章 第二节”方便追溯。可选的标签例如“防火”“疏散”“荷载”用于过滤。构建索引时除了把条款原文做向量化还要把编号、来源、标签作为元数据单独保存。这样检索回来之后不仅能看到相似度还能把条款上下文拼接出来生成时可以附带完整章节路径避免模型只看到孤立一句话而产生误判。2.2 检索器从“搜到相关”到“搜到可引用”检索器在这个框架里的作用不只是给模型找“参考材料”而是给最终结论提供“引用来源”。所以检索质量直接决定判断质量甚至比模型选型更关键。常见的检索策略是混合检索向量检索负责语义相似关键词检索负责精确命中。比如检查“疏散门宽度”向量检索能找到“门的净宽不应小于 1.2 米”这种语义相近的条文关键词检索能直接命中“疏散门”“宽度”这些精确词。两个结果合并去重后再按相关度取前 top_k 条。实际工程中我一般会再补两个细节相似度阈值。检索结果不是越多越好。低于阈值的条款宁可不要硬塞进上下文只会干扰判断。阈值通常靠一小批人工标注样例来调不要凭感觉定。重排序。如果条款库很大第一步检索可以先取 top_k 的 2 到 3 倍比如取 20 条再用一个轻量重排序模型或基于关键词命中率打分最后压缩到 5 到 8 条进上下文。重排序能明显减少“语义相近但不该引用”的噪声。2.3 生成器让 LLM 只基于给定条款下结论检索做得再好提示词设计不行模型还是会乱答。合规检查的提示词有两条硬性要求。第一角色和任务要写死。比如“你是合规检查助手只根据用户提供的法规条款判断待检内容是否合规”。这里的“只”字很重要它会显著降低模型引入外部知识或者自己脑补的概率。第二输出格式要结构化。建议强制输出 JSON至少包含结论、引用条款列表、说明三个字段。如果某条结论找不到对应条款要允许模型输出“不适用”或者“未找到明确条款”而不是强行判定。这个“允许不确定”的设计比逼模型必须给结论更符合合规场景。提示词模板示意如下你是一个合规检查助手。请只根据下面提供的法规条款判断待检内容是否合规。 待检内容 {target_text} 法规条款 {clause_list} 要求 1. 只能引用上面给出的条款不得引用其他条文。 2. 输出 JSON格式为 {结论: 合规|不合规|不适用, 引用条款: [条款编号], 说明: 判断理由} 请输出注意条款列表里要同时有条款编号和原文。如果没有编号模型就算引用了后处理也无法核对。3. 落地前需要准备的输入数据与运行环境3.1 数据准备法规文件、待检文件、验收样例CTRAG 落地前数据要分成三类准备。第一类是法规数据也叫规则源。它决定系统能查什么、能判什么。法规文件常见格式是 PDF、Word、网页。PDF 是最麻烦的很多扫描版 PDF 需要 OCR而 OCR 对条文编号的识别经常出错比如把“1.2”识别成“12”。我建议在进入切片前先做一个清洗环节人工抽检 PDF 转换后的文本中条款编号是否完整特别是“条”“款”“项”这类关键结构词。这一步做得越干净后面检索和引用的坑越少。第二类是待检数据。待检内容可能是图纸导出的文本、合同条款、检查表、申请材料。它不需要预先入库检查时才临时输入。但需要注意输入清洗表格转文本后列关系会丢PDF 里多栏排版转出来顺序会乱。输入乱检索就不准判断自然不对。第三类是验收样例也是很多人最容易忽略的。至少准备 30 到 50 条已经人工标注好结论、且注明了对应条款的检查样例作为评估集。这个评估集用来回答两个问题检索有没有召回正确条款判断结论是否与人工一致。没有评估集你根本不知道参数调得好还是坏。3.2 运行环境本地模型还是 API资源怎么评估环境选择主要看三个条件数据敏感程度、调用频率、可用预算。如果法规和待检数据都不能出内网就要用本地模型。本地方案至少需要一张能跑推理的 GPU具体显存取决于模型大小。实践中7B 到 14B 级别的量化模型在合规判断这种“不需要太强创作能力”的任务上是常见起点显存不够就跑更小的模型或多卡分载。嵌入模型相对轻量很多 300M 到 1B 级别的嵌入模型在 CPU 上也能跑但批量建立索引时还是建议上 GPU 加速。如果数据允许走 API开发速度会快很多。API 方案优先看三点上下文长度是否覆盖“目标文本 top_k 条款 提示词”的总长输出是否稳定支持 JSON 格式单位测试成本是否在可接受范围。不要一开始就追求超大上下文模型因为 CTRAG 的核心是“少而准的上下文”把 top_k 从 5 提到 20 并不代表判断更准反而可能引入更多噪声和更高成本。原始材料没有给出具体模型和版本落地时建议先确认你选用的嵌入模型、LLM 以及向量数据库之间的依赖兼容性尤其是 Python 版本和底层库的对应关系。3.3 初始参数先按一套保守配置起步第一次跑通链路时参数先保守一点。给一套我常用的初始配置后续再根据评估集调整参数初始建议说明切片单位按条款编号切保持判断条件完整检索方式向量 关键词混合语义和精确命中互补初始 top_k8上下文够用且成本可控相似度阈值0.2 到 0.3太低会引入噪声太高会漏召回LLM 温度0合规判断不要随机性输出格式JSON便于后处理和归档单次最大重试3 次处理输出解析失败这套配置不是为了拿最优效果而是为了让第一次跑通可复现、结果可检查。先看流程通不通再谈优化。4. 单条合规检查流程怎么跑通4.1 流程拆解切片、索引、检索、拼装、生成、校验单条检查看起来简单实际一条完整链路至少包含六个环节法规切片。按条款切分保留编号和来源。建立索引。对每条切片生成向量写入向量库同时保留元数据。检索条款。输入待检内容得到关联度最高的条款集合。拼装上下文。把条款编号、原文、来源按固定格式拼进提示词。调用模型生成。得到 JSON 结构的判断结果。校验输出。检查模型引用的条款编号是否真的存在于本轮的检索结果里不存在就拒绝该输出并重试。第六步是很多实现里缺失的。模型可以在 JSON 里写一个看起来很合理的条款编号但这个编号可能根本没进过上下文也可能根本不存在。后处理必须做引用存在性校验。校验不通过就让模型重新生成或者把问题标记为“待人工复核”。4.2 一个最小链路示例伪代码下面给一个示意性的 Python 伪代码只用来表达主流程不代表某个具体库的精确调用方式# 示意代码CTRAG 单条检查主流程 def check_item(target_text, top_k8, threshold0.25): # 1. 检索相关条款返回带 score 的结构化记录 candidate_clauses retrieve_clauses(target_text, top_ktop_k * 2) # 2. 按相似度阈值过滤并压缩到 top_k selected_clauses [c for c in candidate_clauses if c.score threshold][:top_k] end # 3. 拼装提示词 clause_list format_clauses(selected_clauses) prompt build_prompt(target_text, clause_list) # 4. 调用 LLM并设置低温度 raw_output llm_generate(prompt, temperature0) # 5. 解析和校验输出 result parse_json(raw_output) assert_references_exist(result[引用条款], selected_clauses) return result这段伪代码省略了很多细节比如索引怎么建、检索具体用什么库、超时如何设置但它把最核心的执行顺序表达清楚了检索、过滤、拼装、生成、校验。4.3 输出格式和验证标准单条检查跑通后先不要急着接更多输入先看输出是不是满足这几点结论字段只能是预设枚举值比如“合规 / 不合规 / 不适用”不能出现其他自由文本。引用条款字段里的每个编号都能在本次检索结果里找到。说明字段能描述“哪个条件不满足导致不合规”而不是泛泛而谈。同一输入重复跑两次结果一致率足够高。合规判断不该依赖随机性。第一次跑通时我一般会拿 5 条人工标注样例做一次完整测试逐条看检索结果和最终判断。重点关注检索阶段有没有把真正依据的条款召回到 top_k 里。如果条款压根没被召回后面模型再强也没用。5. 从单条到批量并发、重试和结果归档5.1 批量任务和单条任务的差异单条跑通后很多人直接把单条逻辑塞进 for 循环然后发现一堆问题有些请求失败有些输出解析失败有些结果写进同一个文件覆盖了有些跑到一半断了不知道从哪继续。这不是模型问题而是批量化设计缺失。批量和单条最大的区别在于单条失败不影响整体每条任务要有独立状态。批量必须考虑并发限制尤其是 API 方案的速率限制和本地方案的显存占用。输出必须按任务隔离避免并发写同一文件。大批量需要断点续跑处理到第 500 条中断时不能从头再来。这些都属于工程问题但直接影响合规检查的可靠性。合规检查结果要留痕任务中断重跑如果产生不同结果归档就会混乱。5.2 输出命名、失败重试和断点续跑我的建议是每个待检对象生成一个唯一任务 ID可以用原始文件名加哈希后缀。输出目录结构按“任务 ID / 输入副本、结果 JSON、日志”来组织。这样即使同一批任务跑多轮也不会互相覆盖。批量循环里要区分三类失败网络或服务超时可以重试一般重试 2 到 3 次。输出 JSON 解析失败可以带错误信息重新生成一次。引用校验不通过不要盲目重试先记录下来归到“待复核”集合。断点续跑最简单的做法是任务开始前先写一个“已完成”标记文件或者把任务状态记录在 SQLite 里。重启时扫描标记跳过已完成任务。这类逻辑不复杂但能省下大量重复调用成本。5.3 批量的验收指标批量不是“跑完没报错”就算完成。合规检查至少要统计这几个指标成功率成功输出且通过引用校验的任务占比。条款召回率人工标注的正确条款是否出现在每条任务的检索结果里。判定一致率模型结论与人工结论一致的比例。平均耗时和成本单条平均耗时、总 token 消耗评估是否可接受。待复核比例引用校验失败或结论不明确的占比这个比例不能太高。如果某个指标明显异常先看是不是输入数据有问题再看检索参数最后才怀疑模型。不要一上来就换模型。6. 常见问题与排查顺序6.1 检索不到正确条款这是 CTRAG 类系统最常遇到的问题。现象是模型给出的结论看着合理但引用的条款和人工标注的不一样或者上下文里压根没有正确条款。排查顺序我建议这样走先确认法规切片是否完整。检查目标条款是否真的被切出来编号有没有被 OCR 弄丢。再确认待检文本是否被清洗干净。表格、多栏、乱码都会影响检索。看检索结果列表。把 top_k 调大到 20看目标条款是否出现在候选里。如果出现但最终没被选中可能是重排序或阈值把它挤掉了如果没出现问题在切分、向量化或者检索方式。调整嵌入模型。中英文法规混合场景有些嵌入模型对法律文本的语义理解明显偏弱换一个领域更匹配的模型往往比调参数更有效。6.2 模型不按条款回答模型引用了上下文里不存在的条款或者明明没有对应条款也要强行判“不合规”这类问题多半出在提示词和后处理。先检查提示词里的“只依据给定条款”约束是否写清楚。再用后处理拦截引用编号不在给定集合内直接判定该次生成无效。最后看模型本身。小模型在强约束任务上表现往往不稳定如果提示词和后处理都做对了还经常违规就要考虑换更大模型或者换一个对齐更好的模型。6.3 结果不稳定或速度慢结果不稳定先看温度。合规判断场景温度应该设为 0如果设为默认值结果抖动是必然的。温度已经是 0 还不稳定可能是提示词里条款顺序每次不同可以固定条款排序方式比如按条款编号排序。速度慢先看瓶颈在哪里。检索慢优化向量索引和候选集生成慢检查是不是 top_k 太大导致上下文过长单条请求超时把超时时间调长或者拆解目标文本。不要盲目并行本地 GPU 显存不够时并行反而会导致 OOM 和卡死。6.4 通用排查链路如果整套流程跑出异常我的习惯是按下面这个顺序排查先看现象是报错、卡住、无输出还是输出格式错误。再看输入待检文本、法规文本、路径、编码、格式是否正常。再看检索目标条款是否被召回相似度分数是否异常。再看参数top_k、阈值、温度、超时是否合理。最后看依赖嵌入模型、LLM、向量库、Python 版本之间是否兼容。这个顺序的核心原则是先解决数据问题再解决流程问题最后才换模型。很多看起来像模型能力不足的问题最后都查出来是输入没清洗干净或者条款没被切出来。7. 哪些场景适合 CTRAG哪些不适合7.1 适合的场景CTRAG 最适合的判断依据是“显式条文”的场景。典型特征包括规则以条款形式存在有编号、有明确表述。待检对象是具体内容可以翻译成文本比如一段描述、一张属性表、一段合同文字。判断结果需要引用具体条款不能只给结论。法规会更新需要快速切换到新版本。人工检查量大希望先自动筛掉明显不合规或明显合格的部分剩下小部分交给人工复核。在这些场景里CTRAG 能把“人工逐条翻规范”变成“机器先检索、再判断、人工复核结果”价值非常直接。7.2 不适合的场景不是所有“规则判断”都适合 CTRAG。如果遇到下面这些情况建议谨慎规则本身模糊依赖行业经验。比如“做法是否合理”“设计是否美观”没有明确条文可引用检索检索不出来模型也只能猜。判断需要综合几十条跨章节条款做权衡。一次性把几十条塞进上下文效果不一定好可能需要拆成多步推理。没有标注数据。连人工验收样例都没有就无法评估检索和判断质量上线风险太高。法规文本质量极差。扫描件、缺编号、排版混乱先花时间清洗数据否则整套框架跑起来都是垃圾进垃圾出。另外要明确一点CTRAG 是辅助工具不是“无人值守审批系统”。合规检查的最终责任通常还是要落在专业人员身上。把系统定位成“自动预筛 人工复核”比定位成“全自动判定”稳妥得多。7.3 我的建议先跑小样本再谈上线这套框架真正落地时最该盯住的不是功能列表而是输入格式、检索召回和失败重试。我更建议把第一次测试拆成三步先用 30 到 50 条标注样例把检索调通再用 100 条混合数据把批量流程和结果归档跑顺最后才考虑接入实时接口或者嵌入业务系统。踩过几次之后我发现很多问题不是框架能力不够而是前置环境和输入材料没有处理干净。法规文本清洗、条款编号规范化、待检文本结构保留这些看起来不起眼的环节恰恰决定了 CTRAG 在真实项目里能不能稳定工作。如果你正在评估要不要用这类方案先把数据样例拿过来按上面的链路跑一遍小样本你会比看任何功能列表都更快知道它适不适合你的场景。