From Policy to Logic for Efficient and Interpretable Coverage Assessment¶

会议: AAAI 2026
arXiv: 2601.01266
代码: 无
领域: 医学图像
关键词: 神经符号推理, 覆盖政策, 规则引擎, 检索增强, 可解释AI

一句话总结¶

本文提出一种神经符号方法，通过覆盖感知检索器（coverage-aware retriever）与基于PyKnow的符号规则推理相结合，帮助人类审查员高效、可解释地评估医疗CPT代码是否被保险政策覆盖，在推理成本降低44%的同时F1提升4.5%。

研究背景与动机¶

医疗保险领域中，判断某项医疗程序（以CPT代码标识）是否被特定保险政策覆盖是一项至关重要但极其复杂的任务。覆盖政策文档（CoC/SPD）通常包含数百页复杂的法律和政策语言，专业审查员需要逐一比对CPT代码与政策条款，工作量巨大且容易出错。

大语言模型（LLM）在法律分析和政策解读方面展现了强大能力，但存在三个关键问题：(1) 幻觉和不一致性——LLM可能生成看似合理但不准确的推理；(2) 成本高昂——对上万个CPT代码反复调用LLM推理费用极高；(3) 缺乏可追溯性——直接提示方式难以让审查员追溯决策依据到具体的政策条文。

链式思维（CoT）虽然能引导多步推理，但同样面临可解释性不足、推理不一致以及大规模应用时计算成本过高的问题。另一方面，传统专家系统通过规则推理保证一致性和可解释性，但依赖人工编码领域知识。

本文的切入点是：将LLM的自然语言理解能力与符号规则引擎的确定性推理结合——先用LLM一次性生成结构化属性和规则，之后用符号推理引擎（PyKnow）执行推理，从而在保证可解释性的前提下大幅降低推理成本。

方法详解¶

整体框架¶

系统分为两个阶段：(1) 策略文本检索阶段——使用微调的覆盖感知检索器从政策文档中提取与CPT代码相关的覆盖条款；(2) 符号推理阶段——利用LLM为CPT代码生成属性和规则，然后用PyKnow推理引擎匹配规则并输出可审计的推理轨迹。

关键设计¶

覆盖感知检索器（Coverage-Aware Retriever）:
- 功能：从政策文档的子章节中精准检索决定CPT代码覆盖状态的条款，而非仅基于主题相似性
- 核心思路：使用Longformer（allenai/longformer-base-4096）作为backbone的cross-encoder，将检索任务建模为对比式多选排序问题。训练损失为交叉熵：$\mathcal{L} = -\log p(i=\text{positive} \mid q, S)$
- 设计动机：标准语义搜索会被主题相似性误导（如胰岛素泵CPT可能匹配到糖尿病自我管理教育，而非真正的耐用医疗设备覆盖条款）。cross-encoder能捕捉查询与段落之间的细粒度交互，识别"需要预先授权""不覆盖""仅限于"等决定性短语
- 训练数据：约20名认证编码专家在172份覆盖文档上标注了超过184万个(CPT, 子章节, 相关性)标注对，161万条用于训练
- 架构选择：候选池每个保险计划仅约60个子章节，cross-encoder的穷举打分在现代GPU上完全可行
属性生成（Attribute Generation）:
- 功能：为每个CPT代码提取描述其特征的是/否属性（如is_implant、is_pregnancy等）
- 核心思路：将同一子章节关联的CPT代码分组，用LLM提示生成与该组代码和覆盖条款共有的属性，同时赋默认值（True/False）
- 设计动机：属性是连接自然语言政策和符号规则的桥梁；每个CPT代码的属性只生成一次，可在不同保险计划间复用，这是成本控制的关键
规则生成（Rule Creation）:
- 功能：为每个政策子章节生成PyKnow格式的符号规则
- 核心思路：对每个子章节，收集关联的CPT代码及其属性，通过结构化提示指导LLM生成PyKnow规则代码。规则形如"if is_pregnancy==True and is_maternity==True, then apply pregnancy_maternity_services rule"
- 设计动机：将非结构化的政策语言转化为可执行的if-then规则，确保推理过程完全可追溯；每个计划文档的规则只生成一次
符号推理引擎（Inference with PyKnow）:
- 功能：给定CPT代码及其属性，通过PyKnow引擎匹配触发的规则，输出推理路径
- 核心思路：PyKnow引擎检查每条规则的前提条件是否被当前CPT代码的属性满足，匹配后将触发的规则和相关属性呈现给人类审查员
- 设计动机：推理阶段完全不需要LLM调用，推理成本近乎为零（1000个CPT仅需 $2.5），且每次推理结果完全确定，无幻觉风险

损失函数 / 训练策略¶

检索器的训练目标是对比式交叉熵损失（等价于InfoNCE），使用AdamW优化器（lr=2e-5, weight decay=0.01），bf16混合精度，梯度检查点节省显存。训练2.5个epoch，在8×H100 GPU上约48小时。

实验关键数据¶

主实验¶

在7个匿名保险计划文档上的性能对比（每个计划814个CPT代码，共5698个测试样本）：

方法	上下文	准确率	F1	推理成本/1K CPTs	推理成本/11K CPTs
GPT-5-mini (微调检索)	检索文本	0.94	0.96	$440	$4,840
GPT-4.1 (微调检索)	检索文本	0.92	0.95	$880	$9,680
O3 (微调检索)	检索文本	0.94	0.96	$880	$9,680
GPT-4.1 (全文)	完整文档	0.82	0.89	$3,520	$38,720
Rule-based (零样本检索)	检索文本	0.85	0.91	$2	$22
Rule-based (微调检索)	检索文本	0.87	0.93	$2	$22

消融实验¶

配置	准确率	F1	说明
零样本检索 + 规则	0.85	0.91	零样本检索器基线
微调检索 + 规则	0.87	0.93	微调提升准确率2.69%，F1提升1.72%
GPT-4.1 + 全文	0.82	0.89	全文输入反而更差，说明精准检索的重要性
GPT-4.1 + 检索文本	0.92	0.95	LLM+优质检索最强但成本高

各计划细分结果：

保险计划	GPT-4.1 F1	零样本规则 F1	微调规则 F1
Plan #1	0.93	0.93	0.90
Plan #2	0.87	0.91	0.90
Plan #3	0.86	0.88	0.94
Plan #4	0.93	0.90	0.93
Plan #5	0.90	0.94	0.96
Plan #6	0.86	0.90	0.93
Plan #7	0.93	0.93	0.94
平均	0.89	0.91	0.93

关键发现¶

微调规则系统在平均F1上（0.93）超过了直接使用GPT-4.1全文推理（0.89），同时推理成本降低了99.9%以上
提供精准检索文本而非全文给LLM可以同时提升性能和降低成本——全文输入反而带来噪音
规则失败的主要原因：73.5%是因为正确属性未被纳入规则生成过程（LLM"遗忘"后部属性），26.5%是规则集不完整
一次性设置成本（检索器训练$2,680 + 属性/规则生成）在处理约850个CPT代码后即可回本

亮点与洞察¶

巧妙的分层设计：用LLM做一次性的知识提取（属性+规则），用符号引擎做可重复的确定性推理，实现了成本和可解释性的最优平衡
覆盖感知检索器的设计思想深刻——检索目标不是"语义相似"而是"覆盖决定性"，这个区分在法律/政策文本中至关重要
184万标注对的训练数据规模体现了真实工业场景的投入；20名认证SME的标注保证了数据质量
系统明确定位为人类审查员的辅助工具而非替代品，最终决策权保留在人类手中，这在医疗和法律领域是正确的产品定位

局限与展望¶

属性生成存在"遗忘"问题（73.5%的错误来源）：当属性列表过长时，LLM倾向于忽略后部属性，这与长上下文中的位置偏置一致
规则集可能不完整（26.5%错误来源），部分样本因缺少规则而无法覆盖
仅在CPT代码上评估，未扩展到HCPCS或其他医疗代码体系
内部数据和匿名处理限制了可复现性
未与专门针对法律推理的模型（如LawLLM）或混合方法做更多对比
规则的维护和更新机制未讨论——当政策文档更新时如何增量更新规则

评分¶

新颖性: ⭐⭐⭐⭐
实验充分度: ⭐⭐⭐⭐
写作质量: ⭐⭐⭐⭐
价值: ⭐⭐⭐⭐