信息抽取：规则 vs LLM

回答与解析

规则、LLM 与混合链路的选择标准

规则适合输入结构稳定、边界可枚举、容错要求低且需要可解释审计的任务，例如固定字段校验、身份证号格式、单位换算和白名单映射。它的执行成本通常较低、行为可追踪，但绝不是零成本或零延迟：规则要开发、测试、发布、监控并随业务变化维护，覆盖之外也不会自动泛化。

LLM 适合语言表达多样、语义边界难以完整枚举、需要归纳或抽取的任务。优势是用自然语言和少量示例即可快速覆盖长尾；代价包括输入输出 token、模型延迟、概率性错误、版本变化以及隐私合规。Few-shot 是把示例放进输入上下文，因此会增加输入 token；它可能提升表现、减少重试或缩短开发迭代，但不能宣称直接减少 token。结构化输出能约束格式，不代表字段语义必然正确。

工程上通常采用分层方案：确定性校验和高风险决策交给规则，模糊语义抽取交给 LLM，输出再经过 schema、词典、范围与跨字段校验，低置信或冲突样本进入人工复核。选型应在同一金标集上比较准确率、覆盖率、单位成本、端到端延迟、失败严重度和维护工时，并通过流量分布计算总拥有成本，而不是只比较一次 API 价格。

口语版讲法(30秒速答 + 90秒主答 + 完整展开)

• 用任务边界与错误成本决定方案
• 说明规则的稳定性与维护成本
• 说明 LLM 的泛化能力与概率风险
• 解释 Few-shot 的真实 token 成本
• 以混合链路和金标评测收尾

【30秒速答】 规则和 LLM 不是互相替代。输入稳定、边界可枚举、结果要审计时优先规则；语言多样、长尾多、语义边界难写全时再让 LLM 做抽取或分类。规则执行通常便宜，但仍有开发、测试、维护和运行开销，也不可能天然百分之百正确。Few-shot 把示例放入提示，会增加输入 token，只可能通过提升一次成功率减少重试或迭代。生产链路常让 LLM 处理模糊部分，再用 schema、业务规则和人工复核守住高风险边界。

【90秒主答】 选型先看四件事：输入分布是否稳定，错误能否接受，结果是否需要解释，业务变化有多快。固定日期、金额范围、编码映射、必填字段这类任务适合规则，因为结果可复现，失败也容易定位。规则的局限是覆盖依赖人工枚举，规则叠加后会有冲突和维护债务；每次业务变更仍要回归测试，所以不能说零成本、零延迟或百分之百正确。LLM 更适合从邮件、合同或客服文本中抽取意图和实体，能通过指令与示例适应多种表达，但同一语义可能出现遗漏、幻觉或格式漂移。即使使用严格 JSON schema，也只是约束输出结构，金额、主体和日期是否抽对仍需验证。Few-shot 的示例本身属于 prompt 上下文，例子越多通常输入 token 越多。它的商业价值可能来自少写规则、少重试或更快覆盖新场景，而不是输入 token 自动下降。

【完整展开】 一个稳妥的文档抽取链路可以先做文件类型、编码和固定字段规则，再把非结构化段落交给 LLM，随后执行类型校验、值域校验、跨字段一致性、权限检查和来源定位。比如发票金额不能只相信模型输出，还要核对币种、小计与总计关系；身份和审批结论应由权威系统确认。低置信、多个候选冲突或高金额样本进入人工队列。这样把 LLM 放在它擅长的语义层，把不可逆决定留给确定性组件。

成本评估也要按全链路计算。规则侧记录开发工时、规则数量、变更频率、误拦与漏放；模型侧记录输入输出 token、批量能力、缓存命中、模型延迟、重试率和人工复核率。建立覆盖真实长尾的金标集，用字段级 precision、recall、整单通过率和严重错误率比较，再按每天流量换算总成本。小流量且变化快的任务可能 LLM 更划算，高流量稳定字段可能规则更合适。模型升级、提示变化或上游格式变化后都要回归。最终方案不是“规则免费”或“模型更聪明”，而是让每一层承担可验证、可回滚的职责。

关键一句:Few-shot 示例增加输入上下文，是否降低总成本取决于一次成功率、重试和维护工时。

核验来源

1. Language Models are Few-Shot Learners
2. OpenAI: Introducing Structured Outputs in the API

面试官还可能这样问

1. 问法 1 · 场景切入

   假设现在从半结构化文档中抽取既有固定格式字段，也有依赖上下文的长尾语义。你会怎样组合规则、LLM 和人工审核？

2. 问法 2 · 层层追问

   固定模式为什么适合规则？……语义变化大时 LLM 的优势和风险是什么？……JSON 合规是否代表内容正确？……高风险字段怎样校验、审计和回退？

3. 问法 3 · 直球技术

   请比较规则与 LLM 信息抽取的适用场景、准确性、维护成本、延迟、可审计性和错误边界，并设计混合架构与评测。