CTRAG 把合规检查做成了 RAG 流水线，还在四大跑通了 POC

合规检查这件事，做过的人都懂——翻监管文件，抽控制项，对着公司文档一条一条核对，碰上依赖第三方云服务或者外包商的情况，还得去追对方的合规凭证。手动跑一轮，几周时间就填进去了，而且不同人查同一份文档，漏掉的东西往往不一样。

最近 arXiv 上有一篇论文让我多看了两眼，叫 CTRAG，全称是「基于上下文检索的自动化合规检查框架」，就是用 RAG 流水线去干合规审核的活。作者是 Muhammad Roman、Karen Rafferty 和 Barry Devereux，来自 Queen's University Belfast。RAG 框架已经不少了，但这篇不一样的地方在于，他们真的在一个 Big Four 会计师事务所（就是四大之一）内部做了 POC 验证，拿真实案例跑了一遍，还把结果跟人工合规报告做了交叉核对。

它不是只在一个干净的数据集上跑了个 benchmark 就发论文，而是在真实合规审查环境里被验证过的。

先看架构。CTRAG 的核心思路不算花哨：从监管文本里提取出「控制问题」（control questions），然后拿这些问题去检索公司提供的非结构化文档，用 LLM 做上下文学习来判断是否合规。但真正让它跑出结果的是里面几层设计——adaptive chunking（自适应分块）、dynamic retrieval configurations（动态检索配置），以及 in-context learning 的 prompt 组织方式。这些词听起来像常规操作，但在合规场景下，分块大小直接决定了一条控制项能不能被完整召回，检索策略得根据文档类型动态调整，不然第三方服务的合规说明很容易被漏掉。

数字上说，最终部署的配置下 CTRAG 达到了 78% 的 F1 和 85% 的 Recall。Recall 做到 85% 是关键——在合规检查里，漏报比误报严重得多，漏掉一条不合规项可能直接导致审计失败。85% 的召回意味着大部分违规案例被抓住了，剩下的部分靠人工兜底，但整体负担已经大幅下降。

论文还重点提到了 indirect compliance——间接合规。很多企业自己符合规定，但用的云服务商或者数据处理外包商不合规，等于白搭。CTRAG 的检索设计里专门考虑了这个场景，能把第三方文档也拉进比对范围。

78% 的 F1 放在通用 QA 或文档问答里不算惊艳，但在合规审查这个领域，能跑通四大内部的真实案例，已经说明 RAG 从「能回答问题」走到了「能帮人做判断」的阶段。人工审核员不需要再从头到尾翻几百页文档了，只需要对 CTRAG 标记出来的疑似不合规项做二次确认。

过去一年 RAG 演进最扎实的一个方向就在这：不卷更长上下文、不比谁生成得更像人，而是扎进具体的、有责权边界的业务场景，把召回率和准确率做到让人敢用。合规、审计、法务这些领域，LLM 的幻觉最不能被容忍，也是 RAG 最能证明自己价值的地方。

论文提到，CTRAG 的 POC 是在真实案例上做的，结果跟人工报告做了交叉验证。不过论文没有公开具体的误报率和漏报明细，也没有说明在多少案例、多少份文档上做的测试。这些细节如果能放出来，会对行业更有参考价值。

合规自动化，信任门槛比技术门槛更难跨过去。CTRAG 能进四大做 POC，至少说明有一家顶级专业服务机构觉得这条路值得试试。

相关链接：
- 论文页面：https://arxiv.org/abs/2608.02472
- PDF 全文：https://arxiv.org/pdf/2608.02472