几个月前有朋友跟我聊起他们团队做的一项自动化尝试他们想用大模型直接判断施工方案里的安全措施是否满足规范要求。第一批测试结果还算好看但第二周就出了问题——模型对一个明显不合规的工序给出了“符合要求”的结论理由里引用了一条“规范”中根本不存在的条款。问题不是模型能力不够而是他们让模型在没有规则上下文的情况下凭记忆回答合规判断。这个场景在合同审核、建筑合规、制度审查、金融信息披露等大量行业里反复出现。LLM 确实能读懂文本也能做逻辑推理但“合规检查”这件事最底层的矛盾是判断依据不在模型脑子里。规则库动辄几十万字规则还在持续更新新发布的条款模型不知道旧条款的细节也可能记混。于是 CTRAG 这类方案出现了——它不是让模型更聪明而是把“先检索规则、再看具体材料、最后给结论”这个过程变成一套可复用的框架。CTRAG 的名字已经把关键信息拆清楚了In-Context Retrieval基于检索的上下文增强面向自动化合规检查使用 LLM 推理。我更愿意把 CTRAG 理解成一次对“合规自动化和大模型协作方式”的重构。它的核心不是某个算法而是一个流程先找到与当前材料最相关的规则条文把规则和材料同时放进 LLM 的上下文里再要求模型基于这两部分内容产出判断。这听起来并不复杂真正落地的难点在于规则库怎么组织、检索怎么设计、结果怎么校验、失败怎么处理。这篇文章就从这几个层面展开。1. 先理解合规检查为什么不能靠大模型“凭空判断”1.1 合规检查的真实工作流人、规则、证据三者缺一不可人工做合规检查时通常不是直接读一遍材料就能给结论。我见过很多资深合规人员的工作习惯他们是先把待检材料拆成问题项然后翻开规则库定位相关条款看一眼条款原文再回到材料里比对事实最后在审查意见里写清楚“违反了什么规则、事实依据是什么、建议怎么整改”。如果遇到规则本身有歧义还要翻历史案例、修订说明或官方答复。这条工作流里规则是独立于审查人员的知识来源。人不能死记硬背所有条款而是依靠检索系统、目录索引、搜索引擎快速定位到最可能相关的条款再基于条款和事实做判断。这其实是“精确检索 人类推理”的协作而不是“全凭记忆答题”。当团队试图用大模型自动化合规检查时最容易犯的错误就是跳过“检索环节”直接让模型根据训练数据里残存的规则知识做判断。训练数据里确实包含不少法律法规、技术标准但这些知识不完整、不新鲜、也不可追溯。更重要的是模型无法告诉你是从哪一条规则得出这个结论的。没有依据的合规结论在真实项目里就是一颗定时炸弹。1.2 直接让 LLM 做“纯记忆推理”的四个坑从过往项目经验看绕过检索直接让 LLM 做合规判断通常会掉进四个坑里第一个坑是规则时效性。模型训练完成之后规则库还在变。模型不知道新发布的强制条款也不知道旧条款是否被废止。尤其是行业标准、地方规范这类更新频繁的文本模型记忆几乎不可能跟上。第二个坑是长尾规则记忆模糊。大型语言模型对常见法规可能有较好的把握但对小众标准、地方细则、企业内部制度这类低频文本记忆错误率会明显上升。第三个坑是置信度误读。模型输出“这个操作不符合规范”时语气流畅、逻辑完整但如果不提供引用来源你很难判断它是真的检索了规则还是基于概率生成了一段“听起来像那么回事”的话。第四个坑是复核困难。合规检查项目通常要求每条结论都可追溯。人工复核需要看到模型判断所依赖的规则原文。如果模型只是给出结论而说不出规则编号复核方只能回到原始材料重新核对自动化价值几乎归零。CTRAG 这类框架的价值恰好在于把“检索”这个环节显式地补回来。它要求模型在回答时不依赖参数化记忆而是依赖动态检索得到的上下文片段。这样既缓解了规则更新的问题也让结论有了可引用的依据。不过光有想法不够具体怎么实现才是更实际的问题。2. CTRAG 的解题思路把规则和材料一起放进上下文再让模型做推理2.1 从 RAG 到 CTRAG检索增强生成还少了一环很多人会想到 RAG检索增强生成并认为 CTRAG 只是 RAG 在合规赛道的应用。这个理解方向不错但不够准确。通用 RAG 的做法通常是把用户的提问经过向量检索找到相关文档片段拼接到 prompt 里让模型生成回答。在问答场景里用户问题本身是清晰的目标而合规检查场景里输入是一份材料、一个方案、一段合同需要判断的点可能有几十个甚至几百个。CTRAG 的“In-Context Retrieval”强调的不是一次问答而是把检索到的规则和待检材料同时放入上下文让模型在推理过程中随时引用规则条文。这比普通 RAG 多了一层任务设计你需要先判断当前材料涉及哪些规则维度再针对每个维度检索对应条文。如果材料是“一份施工方案”那它可能涉及消防安全、结构安全、劳动保护、环境影响等多组规则如果材料是“一份合同”则可能涉及付款条款、保密义务、违约责任等。规则维度的拆解直接决定了检索和判断的质量。合规检查的复杂度通常不是单条提问而是多维度的联合评估。CTRAG 更准确的做法是“先拆维、后检索、再判断”也就是把待检材料分成若干可核查的检查项对每个检查项独立检索规则再汇总规则判断。这样既控制上下文长度也便于后续定位问题。2.2 核心链路规则库切片 - 向量化 - 召回 - 拼接 Prompt - 模型判断在工程实现上CTRAG 通常由几个固定环节构成。第一个环节是规则库的切片与治理。规则库不是一整本 PDF而是需要清洗成可检索的单元比如一个章、一条、一个条款编号作为最小检索单位。每一个条款都需要有唯一 ID、版本号、来源文本、适用范围等元信息。第二个环节是向量化与索引。将每个条款文本通过 embedding 模型转为向量建索引。第三个环节是召回。对待检材料中的某一段或某个句子也转化为查询向量在向量库中找出最相似的 TopK 个条款。第四个环节是拼接 prompt。把召回的条款原文、对应的元信息、待检材料的对应片段按顺序放入 prompt 中并给模型明确指令。第五个环节是输出并校验。让模型输出“合规 / 不合规 / 待人工复核”并附上依据的规则 ID、规则原文片段和推理理由。这五个环节里最容易优化的是前三个也最容易出问题的是后两个。很多团队把精力都放在向量模型选择上却忽略了规则库本身的结构化程度结果检索出来的规则不精确后续一切白搭。更常见的另一个问题是只让模型输出“是或否”却没有要求它引用规则 ID。没有引用就没有复核依据自动化也就失去了可信度。2.3 一个最小可运行示例参考下面是一个简化版 CTRAG 的实现思路用最常见的 Python 向量库来落地。这段代码不是完整生产实现而是帮你建立流程直觉。# 示例结构一个简化版 CTRAG # 假设 rule_chunks 是已经切好片的规则列表每个元素是 { # id: ART-102-3, version: 2024-06, text: ……, meta: …… # } from sentence_transformers import SentenceTransformer import chromadb # 1. 加载 embedding 模型 model SentenceTransformer(BAAI/bge-small-zh-v1.5) # 2. 创建向量库并写入规则条款 client chromadb.Client() collection client.create_collection(compliance_rules) for rule in rule_chunks: collection.add( ids[rule[id]], documents[rule[text]], metadatas[{version: rule[version]}] ) # 3. 输入一段待检材料比如施工方案中的某段描述 query_text 现场切割作业未办理动火审批手续 # 4. 召回 TopK 相关条款 query_embedding model.encode(query_text).tolist() results collection.query( query_embeddings[query_embedding], n_results5, include[documents, metadatas] ) # 5. 拼接 prompt prompt f 你是合规审查助手。请根据以下检索到的规则条文判断待检材料是否合规。 检索到的规则 {format_rules(results)} 待检材料片段 {query_text} 请输出 JSON {{ status: compliant / non_compliant / needs_review, rule_ids: [引用的规则ID], reasoning: 判断理由 }} 这段代码里prompt 中明确要求引用规则 ID是 CTRAG 流程里很关键的一步。你不应该只让模型输出结论还要让它把结论和规则绑定起来。如果rule_ids里出现了规则库中不存在的 ID这个结果就要被判定为无效。3. 从示例到真实项目单条检查跑通之后工程化才是分水岭3.1 第一步让规则库“可检索”而不是只放进数据库很多团队接到合规自动化需求时第一反应是“把规则文档传给大模型不就行了”。这往往会导致两种结果一种是上下文窗口塞满规则模型处理不过来另一种是规则文本没有被切分检索退化成关键词匹配召回质量很差。规则库必须经过重构才能成为可检索的知识资产。切片方式通常按“规则语义边界”来而不是简单按字数切。比如一条完整的条款、一个独立的规定细则适合作为最小检索单位如果条款很长可以再往下拆到“款”或“项”但要保留父子编号关系方便拼接时回溯。每条切片都应该有稳定的 ID、生效日期、适用地域、适用业务类型等元信息。规则库还需要有版本管理。当新版本发布时旧版本不是被覆盖而是要保留历史记录因为跨版本的合规判断需要知道当时依据的是哪一版规则。在真实项目中我建议先做规则库盘点。把散落在 Word、PDF、网页上的规则统一抽出来标注编号、层级、生效状态。做过这个动作之后你才会真正意识到为什么大模型不能靠记忆做合规——好多规则本身就存在重复、冲突、更新未同步等问题。这时切分和索引反而是次要的规则治理才是自动化能否成功的前置条件。3.2 第二步给判断结果加上“依据链”检查一个应用 CTRAG 的项目是否成熟我往往会先看它的输出结构。如果输出只有一个“是否合规”不管准确率多高我都认为它没有真正落地。因为到了复核环节人类专家需要知道“为什么”而且需要快速核对原始条款。合理的输出应该包含状态、引用条款、推理理由和证据定位。可以设计成结构化 JSON或者更友好的表格。状态至少有三类合规、不合规、待复核。不能只输出二元结论因为有些规则存在自由裁量空间模型难以直接判定。引用条款必须来自检索结果不能是模型自己编造的。判断理由则需要模型结合“规则文本”和“材料片段”进行解释不能只罗列关键词。这里有一个工程细节校验生成结果时要检查rule_ids里的每一个 ID 是否真实存在于本地规则库并且是否被检索到。如果没有直接丢弃该结果并触发重试。这是防止 LLM 幻觉传播的有效手段。另一个细节是 prompt 里要写清楚“如果检索结果不足以判断请输出 needs_review不要编造规则”。这可以显著降低虚假合规结论的比例。3.3 第三步批量自动化必须处理的四个工程问题当单条检查流程稳定后团队往往会马上想做批量自动化。比如一次性检查 200 份合同或一个大型项目的全部设计图纸说明。这时问题通常不在模型而在工程系统的稳定性。下面几个问题是批量任务中最容易遇到的问题现象建议并发控制批量提交导致 API 限流或崩溃按 API 配额设置信号量或队列控制并发数不要一次拉满失败重试网络抖动、模型返回错误格式导致任务中断对超时和解析失败设置重试机制设置最大重试次数上下文长度控制单个检查项拼接的规则太多超过模型上下文窗口限制召回条款数量优先返回相似度最高的 TopK并做规则摘要输出解析容错模型偶尔输出额外说明或前后缀导致 JSON 解析失败使用后处理正则提取 JSON 块解析失败时触发“待复核”而不是直接报错这些看起来都是工程细节但它们决定了项目是停留在“演示”还是能进入“生产”。合规系统一旦挂掉复核流程就会中断。更合理的做法是先小批量跑比如一次 10 条检查日志和输出质量再逐步扩大到几百条。先跑通、再优化、最后规模化在合规自动化里不是保守策略而是必要流程。4. 跑 CTRAG 最容易翻车的四个问题与排查链路4.1 现象一检索到的规则不对或缺失当你发现某个待检材料明明应该有对应的条款却没有被召回或者召回了完全无关的条款时不要急着换 embedding 模型。先按顺序排查先看规则切片。是不是一个条款被切成了两半导致语义不完整再看规则库本身是否有这条规则是否被正确索引。然后看查询文本。检查时输入的是整份合同还是拆出来的某个检查项如果是整份长文档直接去检索向量检索的效果往往很差因为噪声太多。需要先做检查项拆解比如按条款、按段落拆出一个个需要判断的句子或片段再针对每个检查项检索。最后看 embedding 模型与领域文本的匹配度。如果领域术语很强比如建筑规范中的“动火作业”“临边防护”通用 embedding 模型可能理解得不够好。可以尝试微调或选择领域增强模型。4.2 现象二判断结论与检索到的规则自相矛盾有时候规则库里已经检索到“必须办理动火审批手续”这条条文但模型仍然输出“合规”。这种自相矛盾通常不是检索问题而是推理阶段的 prompt 约束不够强。模型的默认行为可能是“尽量给出肯定回答”尤其在没有明确严格指令时。你需要在 prompt 中明确要求“只能基于上方检索到的规则条文判断条文未明确允许的操作均视为不确定需输出待复核。”同时如果规则条文中存在例外、前置条件也要要求模型先判断条件是否满足。也可以在 prompt 中加入一条强约束如果结论对应的规则没有出现在检索结果中则输出待复核。还要检查是否把过多不相关的规则塞进了上下文导致模型注意力被稀释。TopK 不是越多越好。通常 3 到 5 条命中规则就足够如果一条相关规则都没有就不应该做合规判断。4.3 现象三输出格式不稳定下游解析失败LLM 输出 JSON 时偶尔会多出“json”标记或者在前面加一句“根据你的要求结果如下”。这在单次演示里不致命但批量自动化时解析失败率会直接拖垮任务。比较实用的做法是第一在 prompt 里明确输出格式并给出一个示例。第二后处理时不直接要求严格 JSON而是用正则从文本中提取首个{...}块。第三如果提取后仍解析失败将这条记录标记为“待复核”而不是直接报错中断任务。第四对偶尔出现的失败记录可以设置一次“重新让模型生成”的机会但不要无限重试。合规任务里数据的完整性比效率更重要宁可让一个样本进入人工队列也不能让整个批量任务停在中断状态。4.4 现象四规则库更新后仍然失效当规则库新增或修改条款后如果发现模型依旧按旧规则判断先检查是不是索引没有更新。很多团队只更新了规则文本忘记清空向量库或重新构建索引导致检索阶段仍然返回旧版本。另一个容易被忽略的问题规则切片 ID 要包含版本号或生效日期。比如ART-102-2025-01这样同一条规则的不同版本可以并存检索结果里也可以显示版本信息。在 prompt 中要求模型优先引用“生效日期最新”的版本能显著减少版本冲突。从工程角度看规则库的更新应该作为一个独立流程解析新规则 - 生成新切片 - 写入向量库 - 标记旧版本失效 - 重建索引 - 运行回归测试。回归测试也很关键选一组固定的历史检查样本每次更新规则库后跑一遍确保新规则没有破坏原有判断的稳定性。5. 边界判断CTRAG 适合谁不适合谁5.1 适合的场景特征CTRAG 看起来像个万能框架但真正适合它的场景有清晰特征。第一规则文本化程度高。规则可以被切分成明确条目而且文本本身相对成熟、歧义较少。第二材料也是文本或结构化文本比如合同、制度文档、检查报告、设计方案说明。如果材料是复杂图纸或大量非结构化图像应用难度会显著增加。第三允许一定误报率并且有复核环节。自动化检查的目标是提升初审效率而不是一次性替代专家终审。第四规则更新频率可控。规则库不需要一天变三次否则维护成本会超过收益。典型场景包括企业内部制度合规自查、合同条款与标准模板比对、施工方案中的危险源识别、金融宣传材料中的违规词筛查、投标文件对招标要求的响应度检查。这些场景的共性是判断依据明确规则库相对稳定而且最终可以有人工兜底。5.2 不适合的场景特征有几类场景要谨慎使用。规则高度依赖主观裁量时比如“是否构成商业贿赂”“是否侵犯公平竞争”这类判断需要结合语境、商业习惯、案例先例很难用几条检索到的条款说清。规则更新极其频繁时比如每天都有新监管问答或风险清单如果规则库维护机制跟不上检索结果会很快失真。对错误零容忍时比如生成具有法律效力的合规意见书LLM 目前的表达能力不足以承担最终责任。材料本身包含大量非文本信息时比如需要分析施工现场照片、视频或复杂图纸CTRAG 也难以独立处理。另一个容易被忽视的边界是数据权限和隐私。将合同、员工信息、内部制度发送到外部 LLM API 前需要确认数据脱敏、授权范围和传输链路。这部分和 CTRAG 本身无关但往往是实际落地审核中最硬的卡点。5.3 一个务实建议让 LLM 做初审让人做复核把 CTRAG 做成“协作层”我不建议把 CTRAG 的目标定义成“全自动合规判断”。更合理的定位是“人机协作层”。具体流程是CTRAG 先对每一条检查项产生预判附带引用的规则依据和理由合规专员只需要对“不合规”和“待复核”的条目做重点复核对“合规”条目抽样检查如果发现模型误判直接修正并反馈到规则库或检索策略中。这样既保留了模型的效率也保存了专家判断的最终权威。在真实项目里这种模式通常能把初审效率提升 40% 到 70%同时保证最终结论可追溯。如果某个团队希望完全脱离人工复核我会建议他们冷静下来先想清楚结论出了问题谁负责。6. 长期价值CTRAG 真正改变的是合规团队的“知识使用方式”6.1 从“人记规则”到“人维护规则库”过去合规团队的经验分散在每个人的简历和脑海里。老员工换岗后新人需要很长时间重新熟悉规则跨部门协作时每个人对同一规则的理解可能不一致。CTRAG 把规则库作为独立的知识资产沉淀下来这是一个值得长期投入的方向。规则一旦被结构化、切片、标注元信息、版本化整个团队的工作方式都会发生变化。新人不再需要背大量条文只需要掌握如何检索、校验和维护规则库。专家的核心价值也因此从“记得住”转移到“理解得深”和“判断得准”。但这也意味着规则库的维护成为一个持续职责。有人负责解析新规则、检查切片质量、处理规则冲突、监控模型误判。这部分工作不能完全交给非专业人员而是要由懂合规业务的人参与设计规则库结构才能保证检索和判断的逻辑真实可用。6.2 从“一次性复核”到“持续学习循环”CTRAG 还可以形成一条数据闭环每次人工复核的结果可以回填到结构化样本中用于评估召回质量和判断准确率。比如发现某条规则频繁被漏召回就可以调整切片策略发现某类文本频繁被误判可以在 prompt 中补充更严格的规则说明发现模型经常输出额外的解释段落可以改进输出约束。这些反馈不一定需要重新训练模型更多时候改进的是规则库、检索参数和 prompt 结构。持续学习不等于模型永远不更新。当 embedding 模型迭代或切换时需要重新构建索引并跑一遍回归集。这里的经验是永远保留一个固定的评测集包含各种规则类型、材料类型和困难样本。每次改动规则库或模型后都要用评测集跑一遍用准确率、召回率、无效输出率等指标判断是否退化。没有度量就没有优化。6.3 回到落地第一件事如果你所在团队正考虑用 CTRAG 或类似思路做合规自动化不需要一开始就搭建完整平台。先取一个最具体的业务场景准备 50 到 100 条规则整理成结构化切片收集 20 份典型待检材料然后手工标注这 20 份材料对应的检查项和规则引用。之后再实现一个最小的检索 判断流程观察召回情况和模型输出质量。这一步往往比想象中慢但它是整个规划里最有价值的部分。我见过不少团队跳过这一步直接选择向量库、配置 API、搭建前端页面。系统倒是很快跑起来了但结论一出错整个项目就要推倒重来。合规自动化的核心从来不是界面也不是模型参数。把规则理解清楚、把依据链路做扎实效率和可信度自然会跟上来。合规范畴是一个容错率极低的领域但正因为如此CTRAG 这种“先检索、后推理、再复核”的思路才更有意义。它没有试图让模型变成规则百科全书而是让模型成为一个会查资料、会引用的审查助理。这个思路在逻辑上是对的在工程上也足够落地。剩下的就看执行的人是否愿意把规则库当作长期资产来经营。 CTRAG：先检索后推理，用大模型构建合规检查自动化框架
几个月前有朋友跟我聊起他们团队做的一项自动化尝试他们想用大模型直接判断施工方案里的安全措施是否满足规范要求。第一批测试结果还算好看但第二周就出了问题——模型对一个明显不合规的工序给出了“符合要求”的结论理由里引用了一条“规范”中根本不存在的条款。问题不是模型能力不够而是他们让模型在没有规则上下文的情况下凭记忆回答合规判断。这个场景在合同审核、建筑合规、制度审查、金融信息披露等大量行业里反复出现。LLM 确实能读懂文本也能做逻辑推理但“合规检查”这件事最底层的矛盾是判断依据不在模型脑子里。规则库动辄几十万字规则还在持续更新新发布的条款模型不知道旧条款的细节也可能记混。于是 CTRAG 这类方案出现了——它不是让模型更聪明而是把“先检索规则、再看具体材料、最后给结论”这个过程变成一套可复用的框架。CTRAG 的名字已经把关键信息拆清楚了In-Context Retrieval基于检索的上下文增强面向自动化合规检查使用 LLM 推理。我更愿意把 CTRAG 理解成一次对“合规自动化和大模型协作方式”的重构。它的核心不是某个算法而是一个流程先找到与当前材料最相关的规则条文把规则和材料同时放进 LLM 的上下文里再要求模型基于这两部分内容产出判断。这听起来并不复杂真正落地的难点在于规则库怎么组织、检索怎么设计、结果怎么校验、失败怎么处理。这篇文章就从这几个层面展开。1. 先理解合规检查为什么不能靠大模型“凭空判断”1.1 合规检查的真实工作流人、规则、证据三者缺一不可人工做合规检查时通常不是直接读一遍材料就能给结论。我见过很多资深合规人员的工作习惯他们是先把待检材料拆成问题项然后翻开规则库定位相关条款看一眼条款原文再回到材料里比对事实最后在审查意见里写清楚“违反了什么规则、事实依据是什么、建议怎么整改”。如果遇到规则本身有歧义还要翻历史案例、修订说明或官方答复。这条工作流里规则是独立于审查人员的知识来源。人不能死记硬背所有条款而是依靠检索系统、目录索引、搜索引擎快速定位到最可能相关的条款再基于条款和事实做判断。这其实是“精确检索 人类推理”的协作而不是“全凭记忆答题”。当团队试图用大模型自动化合规检查时最容易犯的错误就是跳过“检索环节”直接让模型根据训练数据里残存的规则知识做判断。训练数据里确实包含不少法律法规、技术标准但这些知识不完整、不新鲜、也不可追溯。更重要的是模型无法告诉你是从哪一条规则得出这个结论的。没有依据的合规结论在真实项目里就是一颗定时炸弹。1.2 直接让 LLM 做“纯记忆推理”的四个坑从过往项目经验看绕过检索直接让 LLM 做合规判断通常会掉进四个坑里第一个坑是规则时效性。模型训练完成之后规则库还在变。模型不知道新发布的强制条款也不知道旧条款是否被废止。尤其是行业标准、地方规范这类更新频繁的文本模型记忆几乎不可能跟上。第二个坑是长尾规则记忆模糊。大型语言模型对常见法规可能有较好的把握但对小众标准、地方细则、企业内部制度这类低频文本记忆错误率会明显上升。第三个坑是置信度误读。模型输出“这个操作不符合规范”时语气流畅、逻辑完整但如果不提供引用来源你很难判断它是真的检索了规则还是基于概率生成了一段“听起来像那么回事”的话。第四个坑是复核困难。合规检查项目通常要求每条结论都可追溯。人工复核需要看到模型判断所依赖的规则原文。如果模型只是给出结论而说不出规则编号复核方只能回到原始材料重新核对自动化价值几乎归零。CTRAG 这类框架的价值恰好在于把“检索”这个环节显式地补回来。它要求模型在回答时不依赖参数化记忆而是依赖动态检索得到的上下文片段。这样既缓解了规则更新的问题也让结论有了可引用的依据。不过光有想法不够具体怎么实现才是更实际的问题。2. CTRAG 的解题思路把规则和材料一起放进上下文再让模型做推理2.1 从 RAG 到 CTRAG检索增强生成还少了一环很多人会想到 RAG检索增强生成并认为 CTRAG 只是 RAG 在合规赛道的应用。这个理解方向不错但不够准确。通用 RAG 的做法通常是把用户的提问经过向量检索找到相关文档片段拼接到 prompt 里让模型生成回答。在问答场景里用户问题本身是清晰的目标而合规检查场景里输入是一份材料、一个方案、一段合同需要判断的点可能有几十个甚至几百个。CTRAG 的“In-Context Retrieval”强调的不是一次问答而是把检索到的规则和待检材料同时放入上下文让模型在推理过程中随时引用规则条文。这比普通 RAG 多了一层任务设计你需要先判断当前材料涉及哪些规则维度再针对每个维度检索对应条文。如果材料是“一份施工方案”那它可能涉及消防安全、结构安全、劳动保护、环境影响等多组规则如果材料是“一份合同”则可能涉及付款条款、保密义务、违约责任等。规则维度的拆解直接决定了检索和判断的质量。合规检查的复杂度通常不是单条提问而是多维度的联合评估。CTRAG 更准确的做法是“先拆维、后检索、再判断”也就是把待检材料分成若干可核查的检查项对每个检查项独立检索规则再汇总规则判断。这样既控制上下文长度也便于后续定位问题。2.2 核心链路规则库切片 - 向量化 - 召回 - 拼接 Prompt - 模型判断在工程实现上CTRAG 通常由几个固定环节构成。第一个环节是规则库的切片与治理。规则库不是一整本 PDF而是需要清洗成可检索的单元比如一个章、一条、一个条款编号作为最小检索单位。每一个条款都需要有唯一 ID、版本号、来源文本、适用范围等元信息。第二个环节是向量化与索引。将每个条款文本通过 embedding 模型转为向量建索引。第三个环节是召回。对待检材料中的某一段或某个句子也转化为查询向量在向量库中找出最相似的 TopK 个条款。第四个环节是拼接 prompt。把召回的条款原文、对应的元信息、待检材料的对应片段按顺序放入 prompt 中并给模型明确指令。第五个环节是输出并校验。让模型输出“合规 / 不合规 / 待人工复核”并附上依据的规则 ID、规则原文片段和推理理由。这五个环节里最容易优化的是前三个也最容易出问题的是后两个。很多团队把精力都放在向量模型选择上却忽略了规则库本身的结构化程度结果检索出来的规则不精确后续一切白搭。更常见的另一个问题是只让模型输出“是或否”却没有要求它引用规则 ID。没有引用就没有复核依据自动化也就失去了可信度。2.3 一个最小可运行示例参考下面是一个简化版 CTRAG 的实现思路用最常见的 Python 向量库来落地。这段代码不是完整生产实现而是帮你建立流程直觉。# 示例结构一个简化版 CTRAG # 假设 rule_chunks 是已经切好片的规则列表每个元素是 { # id: ART-102-3, version: 2024-06, text: ……, meta: …… # } from sentence_transformers import SentenceTransformer import chromadb # 1. 加载 embedding 模型 model SentenceTransformer(BAAI/bge-small-zh-v1.5) # 2. 创建向量库并写入规则条款 client chromadb.Client() collection client.create_collection(compliance_rules) for rule in rule_chunks: collection.add( ids[rule[id]], documents[rule[text]], metadatas[{version: rule[version]}] ) # 3. 输入一段待检材料比如施工方案中的某段描述 query_text 现场切割作业未办理动火审批手续 # 4. 召回 TopK 相关条款 query_embedding model.encode(query_text).tolist() results collection.query( query_embeddings[query_embedding], n_results5, include[documents, metadatas] ) # 5. 拼接 prompt prompt f 你是合规审查助手。请根据以下检索到的规则条文判断待检材料是否合规。 检索到的规则 {format_rules(results)} 待检材料片段 {query_text} 请输出 JSON {{ status: compliant / non_compliant / needs_review, rule_ids: [引用的规则ID], reasoning: 判断理由 }} 这段代码里prompt 中明确要求引用规则 ID是 CTRAG 流程里很关键的一步。你不应该只让模型输出结论还要让它把结论和规则绑定起来。如果rule_ids里出现了规则库中不存在的 ID这个结果就要被判定为无效。3. 从示例到真实项目单条检查跑通之后工程化才是分水岭3.1 第一步让规则库“可检索”而不是只放进数据库很多团队接到合规自动化需求时第一反应是“把规则文档传给大模型不就行了”。这往往会导致两种结果一种是上下文窗口塞满规则模型处理不过来另一种是规则文本没有被切分检索退化成关键词匹配召回质量很差。规则库必须经过重构才能成为可检索的知识资产。切片方式通常按“规则语义边界”来而不是简单按字数切。比如一条完整的条款、一个独立的规定细则适合作为最小检索单位如果条款很长可以再往下拆到“款”或“项”但要保留父子编号关系方便拼接时回溯。每条切片都应该有稳定的 ID、生效日期、适用地域、适用业务类型等元信息。规则库还需要有版本管理。当新版本发布时旧版本不是被覆盖而是要保留历史记录因为跨版本的合规判断需要知道当时依据的是哪一版规则。在真实项目中我建议先做规则库盘点。把散落在 Word、PDF、网页上的规则统一抽出来标注编号、层级、生效状态。做过这个动作之后你才会真正意识到为什么大模型不能靠记忆做合规——好多规则本身就存在重复、冲突、更新未同步等问题。这时切分和索引反而是次要的规则治理才是自动化能否成功的前置条件。3.2 第二步给判断结果加上“依据链”检查一个应用 CTRAG 的项目是否成熟我往往会先看它的输出结构。如果输出只有一个“是否合规”不管准确率多高我都认为它没有真正落地。因为到了复核环节人类专家需要知道“为什么”而且需要快速核对原始条款。合理的输出应该包含状态、引用条款、推理理由和证据定位。可以设计成结构化 JSON或者更友好的表格。状态至少有三类合规、不合规、待复核。不能只输出二元结论因为有些规则存在自由裁量空间模型难以直接判定。引用条款必须来自检索结果不能是模型自己编造的。判断理由则需要模型结合“规则文本”和“材料片段”进行解释不能只罗列关键词。这里有一个工程细节校验生成结果时要检查rule_ids里的每一个 ID 是否真实存在于本地规则库并且是否被检索到。如果没有直接丢弃该结果并触发重试。这是防止 LLM 幻觉传播的有效手段。另一个细节是 prompt 里要写清楚“如果检索结果不足以判断请输出 needs_review不要编造规则”。这可以显著降低虚假合规结论的比例。3.3 第三步批量自动化必须处理的四个工程问题当单条检查流程稳定后团队往往会马上想做批量自动化。比如一次性检查 200 份合同或一个大型项目的全部设计图纸说明。这时问题通常不在模型而在工程系统的稳定性。下面几个问题是批量任务中最容易遇到的问题现象建议并发控制批量提交导致 API 限流或崩溃按 API 配额设置信号量或队列控制并发数不要一次拉满失败重试网络抖动、模型返回错误格式导致任务中断对超时和解析失败设置重试机制设置最大重试次数上下文长度控制单个检查项拼接的规则太多超过模型上下文窗口限制召回条款数量优先返回相似度最高的 TopK并做规则摘要输出解析容错模型偶尔输出额外说明或前后缀导致 JSON 解析失败使用后处理正则提取 JSON 块解析失败时触发“待复核”而不是直接报错这些看起来都是工程细节但它们决定了项目是停留在“演示”还是能进入“生产”。合规系统一旦挂掉复核流程就会中断。更合理的做法是先小批量跑比如一次 10 条检查日志和输出质量再逐步扩大到几百条。先跑通、再优化、最后规模化在合规自动化里不是保守策略而是必要流程。4. 跑 CTRAG 最容易翻车的四个问题与排查链路4.1 现象一检索到的规则不对或缺失当你发现某个待检材料明明应该有对应的条款却没有被召回或者召回了完全无关的条款时不要急着换 embedding 模型。先按顺序排查先看规则切片。是不是一个条款被切成了两半导致语义不完整再看规则库本身是否有这条规则是否被正确索引。然后看查询文本。检查时输入的是整份合同还是拆出来的某个检查项如果是整份长文档直接去检索向量检索的效果往往很差因为噪声太多。需要先做检查项拆解比如按条款、按段落拆出一个个需要判断的句子或片段再针对每个检查项检索。最后看 embedding 模型与领域文本的匹配度。如果领域术语很强比如建筑规范中的“动火作业”“临边防护”通用 embedding 模型可能理解得不够好。可以尝试微调或选择领域增强模型。4.2 现象二判断结论与检索到的规则自相矛盾有时候规则库里已经检索到“必须办理动火审批手续”这条条文但模型仍然输出“合规”。这种自相矛盾通常不是检索问题而是推理阶段的 prompt 约束不够强。模型的默认行为可能是“尽量给出肯定回答”尤其在没有明确严格指令时。你需要在 prompt 中明确要求“只能基于上方检索到的规则条文判断条文未明确允许的操作均视为不确定需输出待复核。”同时如果规则条文中存在例外、前置条件也要要求模型先判断条件是否满足。也可以在 prompt 中加入一条强约束如果结论对应的规则没有出现在检索结果中则输出待复核。还要检查是否把过多不相关的规则塞进了上下文导致模型注意力被稀释。TopK 不是越多越好。通常 3 到 5 条命中规则就足够如果一条相关规则都没有就不应该做合规判断。4.3 现象三输出格式不稳定下游解析失败LLM 输出 JSON 时偶尔会多出“json”标记或者在前面加一句“根据你的要求结果如下”。这在单次演示里不致命但批量自动化时解析失败率会直接拖垮任务。比较实用的做法是第一在 prompt 里明确输出格式并给出一个示例。第二后处理时不直接要求严格 JSON而是用正则从文本中提取首个{...}块。第三如果提取后仍解析失败将这条记录标记为“待复核”而不是直接报错中断任务。第四对偶尔出现的失败记录可以设置一次“重新让模型生成”的机会但不要无限重试。合规任务里数据的完整性比效率更重要宁可让一个样本进入人工队列也不能让整个批量任务停在中断状态。4.4 现象四规则库更新后仍然失效当规则库新增或修改条款后如果发现模型依旧按旧规则判断先检查是不是索引没有更新。很多团队只更新了规则文本忘记清空向量库或重新构建索引导致检索阶段仍然返回旧版本。另一个容易被忽略的问题规则切片 ID 要包含版本号或生效日期。比如ART-102-2025-01这样同一条规则的不同版本可以并存检索结果里也可以显示版本信息。在 prompt 中要求模型优先引用“生效日期最新”的版本能显著减少版本冲突。从工程角度看规则库的更新应该作为一个独立流程解析新规则 - 生成新切片 - 写入向量库 - 标记旧版本失效 - 重建索引 - 运行回归测试。回归测试也很关键选一组固定的历史检查样本每次更新规则库后跑一遍确保新规则没有破坏原有判断的稳定性。5. 边界判断CTRAG 适合谁不适合谁5.1 适合的场景特征CTRAG 看起来像个万能框架但真正适合它的场景有清晰特征。第一规则文本化程度高。规则可以被切分成明确条目而且文本本身相对成熟、歧义较少。第二材料也是文本或结构化文本比如合同、制度文档、检查报告、设计方案说明。如果材料是复杂图纸或大量非结构化图像应用难度会显著增加。第三允许一定误报率并且有复核环节。自动化检查的目标是提升初审效率而不是一次性替代专家终审。第四规则更新频率可控。规则库不需要一天变三次否则维护成本会超过收益。典型场景包括企业内部制度合规自查、合同条款与标准模板比对、施工方案中的危险源识别、金融宣传材料中的违规词筛查、投标文件对招标要求的响应度检查。这些场景的共性是判断依据明确规则库相对稳定而且最终可以有人工兜底。5.2 不适合的场景特征有几类场景要谨慎使用。规则高度依赖主观裁量时比如“是否构成商业贿赂”“是否侵犯公平竞争”这类判断需要结合语境、商业习惯、案例先例很难用几条检索到的条款说清。规则更新极其频繁时比如每天都有新监管问答或风险清单如果规则库维护机制跟不上检索结果会很快失真。对错误零容忍时比如生成具有法律效力的合规意见书LLM 目前的表达能力不足以承担最终责任。材料本身包含大量非文本信息时比如需要分析施工现场照片、视频或复杂图纸CTRAG 也难以独立处理。另一个容易被忽视的边界是数据权限和隐私。将合同、员工信息、内部制度发送到外部 LLM API 前需要确认数据脱敏、授权范围和传输链路。这部分和 CTRAG 本身无关但往往是实际落地审核中最硬的卡点。5.3 一个务实建议让 LLM 做初审让人做复核把 CTRAG 做成“协作层”我不建议把 CTRAG 的目标定义成“全自动合规判断”。更合理的定位是“人机协作层”。具体流程是CTRAG 先对每一条检查项产生预判附带引用的规则依据和理由合规专员只需要对“不合规”和“待复核”的条目做重点复核对“合规”条目抽样检查如果发现模型误判直接修正并反馈到规则库或检索策略中。这样既保留了模型的效率也保存了专家判断的最终权威。在真实项目里这种模式通常能把初审效率提升 40% 到 70%同时保证最终结论可追溯。如果某个团队希望完全脱离人工复核我会建议他们冷静下来先想清楚结论出了问题谁负责。6. 长期价值CTRAG 真正改变的是合规团队的“知识使用方式”6.1 从“人记规则”到“人维护规则库”过去合规团队的经验分散在每个人的简历和脑海里。老员工换岗后新人需要很长时间重新熟悉规则跨部门协作时每个人对同一规则的理解可能不一致。CTRAG 把规则库作为独立的知识资产沉淀下来这是一个值得长期投入的方向。规则一旦被结构化、切片、标注元信息、版本化整个团队的工作方式都会发生变化。新人不再需要背大量条文只需要掌握如何检索、校验和维护规则库。专家的核心价值也因此从“记得住”转移到“理解得深”和“判断得准”。但这也意味着规则库的维护成为一个持续职责。有人负责解析新规则、检查切片质量、处理规则冲突、监控模型误判。这部分工作不能完全交给非专业人员而是要由懂合规业务的人参与设计规则库结构才能保证检索和判断的逻辑真实可用。6.2 从“一次性复核”到“持续学习循环”CTRAG 还可以形成一条数据闭环每次人工复核的结果可以回填到结构化样本中用于评估召回质量和判断准确率。比如发现某条规则频繁被漏召回就可以调整切片策略发现某类文本频繁被误判可以在 prompt 中补充更严格的规则说明发现模型经常输出额外的解释段落可以改进输出约束。这些反馈不一定需要重新训练模型更多时候改进的是规则库、检索参数和 prompt 结构。持续学习不等于模型永远不更新。当 embedding 模型迭代或切换时需要重新构建索引并跑一遍回归集。这里的经验是永远保留一个固定的评测集包含各种规则类型、材料类型和困难样本。每次改动规则库或模型后都要用评测集跑一遍用准确率、召回率、无效输出率等指标判断是否退化。没有度量就没有优化。6.3 回到落地第一件事如果你所在团队正考虑用 CTRAG 或类似思路做合规自动化不需要一开始就搭建完整平台。先取一个最具体的业务场景准备 50 到 100 条规则整理成结构化切片收集 20 份典型待检材料然后手工标注这 20 份材料对应的检查项和规则引用。之后再实现一个最小的检索 判断流程观察召回情况和模型输出质量。这一步往往比想象中慢但它是整个规划里最有价值的部分。我见过不少团队跳过这一步直接选择向量库、配置 API、搭建前端页面。系统倒是很快跑起来了但结论一出错整个项目就要推倒重来。合规自动化的核心从来不是界面也不是模型参数。把规则理解清楚、把依据链路做扎实效率和可信度自然会跟上来。合规范畴是一个容错率极低的领域但正因为如此CTRAG 这种“先检索、后推理、再复核”的思路才更有意义。它没有试图让模型变成规则百科全书而是让模型成为一个会查资料、会引用的审查助理。这个思路在逻辑上是对的在工程上也足够落地。剩下的就看执行的人是否愿意把规则库当作长期资产来经营。