在企业级 AI 应用中，我们经常面临这样的挑战：今天需要审核合规合同，明天可能需要提取医疗病历。如果为每个场景都手写 Prompt，系统将变得臃肿且难以维护。本文将介绍如何利用JSON 插槽（Structured Slots）结合大语言模型（LLM），构建一套“配置即所得”的通用提取方案。
一、 核心设计理念：解耦与元数据驱动
实现“可插拔”的核心在于：Prompt 引擎与业务逻辑分离。
Prompt 引擎：负责理解 JSON 结构、控制提取流程、校验输出格式。
业务模板（JSON）：定义业务准则（Purpose）、关键点（Key Points）和示例。
二、 关键技术路径与案例分析
1. 将模板转化为“推理指令集”
不要把 JSON 只当做输出格式，要把它当做 LLM 的教科书。利用模板中的description字段告诉模型：每一个插槽代表什么。
案例：
假设我们要提取“财务报表”信息。
配置插槽：
JSON{ "name": "营收真实性审核", "purpose": "确认收入确认政策是否符合会计准则", "key_points": ["是否有客户签收单", "金额是否匹配"] }动态指令生成：Prompt 引擎会自动拼接：“请根据【营收真实性审核】的【purpose】，重点检查【key_points】中的内容，并将发现填入 slot。”
2. 利用 JSON Schema 强制约束（Structured Outputs）
利用 OpenAI 的 Function Calling 或 Gemini 的 Structured Output 功能，将 JSON 模板直接声明为 Schema。这能消除 99% 的格式错误。
案例：
通过 Pydantic 定义一个通用的提取基类：
Python
class CheckItem(BaseModel): example_text: str = Field(description="原文中的关键证据片段") reason: str = Field(description="判断为正确或错误的逻辑理由") class SectionResult(BaseModel): section_id: str correct_examples: List[CheckItem] incorrect_examples: List[CheckItem]效果：LLM 会像填表一样精准填充，不会产生多余的废话。
3. “定位 -> 提取”两阶段工作流
对于长文本，直接提取容易丢失信息。采用“先扫描定位，后结构化填槽”的策略。
案例：
Step 1 (Recall)：LLM 扫描一份 50 页的合同，识别出所有涉及“违约责任”的段落。
Step 2 (Extraction)：将这些段落送入对应的 JSON 插槽模板中进行精细化提取。
优势：极大地提高了长文本下的信息召回率（Recall）。
4. 动态 Few-shot：用“负样本”引导逻辑
在可插拔设计中，我们可以根据domain动态加载历史上的“错误案例”，通过incorrect_examples字段教导模型避坑。
案例：
在审核“广告词违禁语”时：
注入案例：在 JSON 模板中预填一个
incorrect_example：“第一、最先进”。LLM 表现：模型看到示例后，能自动学会识别类似的变体（如“行业顶尖”、“NO.1”），并给出准确的
reason。
三、 系统架构示意
| 模块 | 功能描述 | 通用性体现 |
| Template Registry | 存放不同业务领域的 JSON 配置文件。 | 插槽式：新增业务只需上传 JSON。 |
| Meta-Prompt Engine | 将 JSON 中的purpose等字段自动组装成系统提示词。 | 零代码：无需修改 Prompt 代码。 |
| Slot Filler (LLM) | 执行推理并将结果映射到对应的 JSON 路径。 | 模型无关：支持 GPT-4, Gemini, Claude。 |
| Output Validator | 检查逻辑一致性（如：reason 是否引用了 example_text）。 | 自动化：保证数据进入下游系统前的质量。 |
四、 总结
通过将业务逻辑封装在JSON 插槽模板中，我们实现了一个高度灵活的信息提取系统。它不仅能让业务专家（而非 AI 工程师）直接定义审核规则，还能通过标准化的 Schema 确保数据的稳定性。
