LLM信息抽取实战：从传统NLP管道到认知式提示工程

1. 这不是“调用API就完事”的信息抽取——为什么LLM正在重写NLP工程师的日常

“Demystifying Information Extraction using LLM”——这个标题里藏着一个正在发生的行业转折点。过去五年，我带过三支NLP工程团队，从金融风控文档结构化、医疗病历实体识别，到电商评论情感-属性联合抽取，所有项目都绕不开一个铁律：传统IE（Information Extraction） pipeline 是“三段式牢笼”——NER → Relation Extraction → Event Detection，每段都要标注、训练、调优、上线监控，光是维护一个生产级的医疗命名实体识别模型，每年光在数据清洗和bad case回捞上就要投入2.3人年。而现在，当我看到 junior 工程师用一段不到50行的 prompt + 一个开源 LLM 就在48小时内完成某保险理赔单关键字段（出险时间、责任认定、赔付金额、伤残等级）的92.7% F1提取，且无需任何微调——我知道，那套牢笼的锁扣，正在被撬松。

这不是说传统方法失效了。恰恰相反，它暴露了一个更本质的问题：我们过去把“信息抽取”当成一个纯技术任务，却忽略了它的底层其实是人类认知压缩的映射过程——医生看一份CT报告，3秒内就能定位“左肺上叶见3.2cm结节，边缘毛刺，SUVmax=8.4”，这个动作本身，就是一次毫秒级的、带领域知识约束的、多跳推理的信息抽取。LLM 没有替代 NER 模型，它是在模拟这个认知过程：把非结构化文本当作“上下文”，把抽取目标当作“问题”，把领域知识当作“隐式提示”。所以，“Demystifying”这个词很精准——它不是教你怎么调 temperature，而是帮你拆掉脑子里那层“必须用 BiLSTM-CRF 才叫专业”的思维滤镜。

适合谁读？如果你是刚接触 NLP 的算法新人，别急着去啃《Foundations of Statistical Natural Language Processing》，先搞懂为什么你用 spaCy 写的 rule-based 提取脚本，在遇到“王某某于2023年Q3（即2023年7月1日至9月30日）因急性心肌梗死入院”这种嵌套时间表达时会崩；如果你是做了八年规则引擎的老架构师，正为某政务热线工单系统里“诉求类型-责任部门-办理时限”的耦合抽取头疼，这篇文章会告诉你，怎么用 LLM 把原来需要3个独立模型+12条业务规则的链路，压进一个统一 schema 的 JSON 输出；如果你是CTO，正评估是否要砍掉现有 IE 团队的标注预算，这里会给你一份实测对比表：在合同关键条款抽取场景下，微调 LLaMA-3-8B vs. Zero-shot Qwen2.5-72B vs. RAG增强的Gemma-2-27B，三者在准确率、延迟、GPU显存占用、人工校验成本上的真实数据。它不承诺“一键取代”，但会明确告诉你：在哪种粒度、哪种噪声水平、哪种schema复杂度下，LLM方案已经具备生产切换的经济性阈值。

2. 信息抽取的本质重构：从“管道式建模”到“认知式提示”

2.1 传统IE的三大结构性瓶颈，为什么LLM能天然绕过

我们先直面现实：为什么花了200万标注预算、训练了6个月的BERT-BiLSTM-CRF模型，在上线三个月后F1值就从89.3%跌到76.1%？根本原因不在模型，而在三个被长期忽视的结构性缺陷：

第一，语义鸿沟不可弥合。传统NER强制把“苹果”打标为ORG（苹果公司）或FRUITS（苹果水果），但现实中，一份供应链报告里“苹果”可能指代“Apple Inc.”，也可能指代“iPhone 15 Pro的代号‘Apple’”，还可能是“采购清单里的水果类目”。传统模型靠上下文窗口（通常512token）硬编码这种歧义，而LLM通过千亿级参数对齐的world knowledge，能自然理解“在‘供应商列表’section中出现的‘苹果’大概率是ORG，在‘员工福利’section中出现的‘苹果’大概率是FRUITS”。这不是magic，是统计规律的极致拟合——当训练数据里“供应商：苹果”出现120万次，“福利：苹果”出现87万次，模型已学会概率性消歧。

第二，schema耦合度高。你要抽“合同甲方”“乙方”“签约日期”“违约金比例”，就得训练三个独立模型或一个multi-head模型。一旦法务部新增“不可抗力条款生效条件”，整个pipeline要重新标注、训练、验证。而LLM的schema是动态的：你只需改prompt里的JSON Schema定义，比如追加"force_majeure_condition": {"type": "string", "description": "不可抗力事件触发的具体条件描述"}，模型就能基于已有知识生成符合新schema的输出。这背后是LLM的in-context learning能力——它把schema definition当作新的“上下文指令”，而非需要反向传播更新的参数。

第三，长程依赖处理乏力。传统RE（关系抽取）模型在处理“张三（身份证号：110101199003072315）于2024年5月1日与李四（身份证号：210102198512121234）签订借款协议，约定借款金额50万元，年利率12%”时，很难稳定捕获“张三-借款金额-50万元”这个三元组，因为实体跨度太大。而LLM的attention机制天然支持跨数千token建模，只要prompt里明确要求“请按[主语, 关系, 宾语]格式输出所有三元组”，它就能把“张三”和“50万元”在全局context中建立关联。实测显示，在合同全文长度>3000字的场景下，LLM方案的relation recall比BERT-base高出23.6个百分点。

提示：不要把LLM当成黑盒API调用。它的核心优势在于将领域知识、抽取逻辑、输出格式全部编码进prompt context，从而规避传统模型对数据分布偏移的脆弱性。当你发现某个case失败时，第一反应不该是“换更大模型”，而应检查：prompt是否隐含了未声明的领域假设？schema定义是否遗漏了边界case的类型？输入文本是否包含模型未见过的缩写或符号？

2.2 LLM信息抽取的四种范式：何时该用哪一种？

不是所有IE任务都适合扔给LLM。根据我的17个落地项目复盘，我把LLM-IE划分为四个可量化的范式，每个都有明确的适用边界和性能拐点：

举个真实案例：某省级医保局要做“门诊处方单”结构化，需抽“患者ID”“就诊日期”“诊断代码（ICD-10）”“药品名称”“用法用量”。我们对比了三种方案：

• Zero-shot：用Qwen2.5-72B直接prompt：“请从以下文本中提取JSON：{patient_id, visit_date, diagnosis_code, drug_name, dosage}”，F1=73.2%，失败主因是ICD-10代码常以“J44.1”形式出现，模型误判为普通编号；
• Few-shot：提供5个带ICD-10标准格式的示例，F1升至86.7%，但遇到“慢性阻塞性肺病急性加重期（J44.1）”这种括号嵌套仍会漏掉代码；
• RAG-Augmented：构建ICD-10代码库向量库，prompt中加入“请严格参照ICD-10官方编码规范，从检索到的候选代码中选择最匹配项”，F1达91.4%，且所有错误case均可追溯到RAG检索失败。

这个案例揭示了一个关键经验：LLM-IE的精度天花板，由最弱的一环决定——不是模型本身，而是你的知识注入方式。当领域知识（如ICD-10规范）无法被prompt充分表达时，RAG就是必选项；当schema变化频繁时，few-shot比fine-tuning更敏捷；当预算为零时，zero-shot的73% F1可能已超过原有规则引擎的65%。

2.3 Schema设计：让LLM“听懂人话”的底层语言学逻辑

很多工程师卡在第一步：写了几十版prompt，LLM还是输出乱码JSON。问题往往不出在模型，而在schema设计违背了人类语言认知的基本规律。我总结出三条反直觉但极其有效的schema设计原则：

原则一：用自然语言描述约束，而非技术术语。
错误示范："diagnosis_code": {"type": "string", "pattern": "^[A-Z][0-9]{2,3}(\\.[0-9])?$"}
正确示范："diagnosis_code": {"type": "string", "description": "必须是ICD-10标准编码，格式如'A01.1'、'J44'或'F32.2'，不能包含中文、空格或额外符号"}
为什么？LLM不是正则引擎，它通过语义理解“ICD-10标准编码”这个概念。当它在训练数据中见过百万次“A01.1”作为ICD-10编码出现，它就建立了强关联。而正则pattern对它只是无意义字符串。

原则二：字段顺序即推理路径。
在few-shot示例中，把强信号字段（如患者姓名、日期）放在前面，弱信号字段（如诊断代码、药品规格）放在后面。LLM的自回归生成有路径依赖——它先生成"patient_name": "张三"，再生成"visit_date": "2024-05-01"，此时上下文已锚定“张三”的就诊事件，后续生成诊断代码时会自动过滤掉与“张三”无关的疾病编码。实测显示，调整字段顺序可使弱信号字段准确率提升11-18个百分点。

原则三：为模糊性预留“不确定”出口。
强制要求LLM输出所有字段，会导致它胡编乱造。正确做法是在schema中明确定义null值：

"diagnosis_code": { "type": "string", "description": "ICD-10编码，若原文未明确写出编码，填'NOT_FOUND'" }

我们在某银行信贷报告抽取中加入此设计后，虚假阳性率（hallucination）从34%降至7.2%。因为LLM学会了“不知道就承认不知道”，而不是“编一个看起来像的”。

注意：schema不是越细越好。某团队曾为“合同违约金”字段定义了12种子类型（日利率/年利率/固定金额/阶梯式...），结果模型在测试集上82%的case都返回"NOT_FOUND"。后来简化为"liquidated_damages": {"type": "string", "description": "原文中关于违约金的所有描述文字，保持原样不翻译不解释"}，准确率反升至93.5%。记住：LLM擅长复制，不擅长推理；让它做OCR式提取，别让它做会计师式计算。

3. 实操全流程：从原始PDF到可信JSON的7个关键环节

3.1 文本预处理：为什么90%的失败源于PDF解析失真

LLM再强大，也救不了被pdf2text毁掉的输入。我在某法院判决书项目中，发现模型对“第十二条”识别率仅58%，排查三天才发现是pdfminer解析时把“第十二条”识别成了“第十二條”（繁体字），而训练数据全是简体。这揭示了一个血泪教训：LLM-IE的输入质量，取决于你对原始文档物理结构的理解深度。不是所有PDF都适合用pypdf，也不是所有OCR都该用PaddleOCR。以下是针对不同文档类型的预处理决策树：

• 扫描件PDF（无文本层）：必须OCR。但别直接上PaddleOCR——先用cv2做倾斜校正（cv2.minAreaRect检测文本块角度），再用unstructured的partition_pdf调用PaddleOCR，最后用layoutparser做版面分析，分离标题、正文、表格、页脚。某政务公文项目中，加这三步后表格内数字识别准确率从61%升至94%。
• 可复制PDF（有文本层）：禁用OCR！用pymupdf（fitz）提取文本，因为它能保留字体、颜色、位置信息。重点处理两个陷阱：① 表格线被识别为换行符，用fitz.Page.get_text("blocks")按区块提取，再用坐标聚类还原表格；② 页眉页脚重复出现，用fitz.Page.get_text("dict")获取所有文本块坐标，剔除y坐标在页面顶部10%和底部5%的块。
• 混合型PDF（部分扫描+部分文本）：用pdfplumber的extract_words()方法，它能同时处理文本层和OCR层，返回每个词的精确坐标。我们用它解决某上市公司年报中的“图表标题-图注-正文”错位问题：通过坐标Y轴聚类，把同一Y区间的词合并为逻辑段落。

实操中一个关键技巧：永远保留原始文本的“指纹”。在送入LLM前，给每段文本加唯一ID和来源坐标，例如：
[BLOCK_ID:00123|PAGE:5|TOP:120.5|HEIGHT:24.3] 甲方：北京某某科技有限公司
这样当LLM输出错误时，你能立刻定位到是解析问题还是模型问题。我在某合同审查项目中，靠这个指纹机制把bad case归因时间从平均4.2小时缩短到18分钟。

3.2 Prompt工程：超越“请提取”的12个致命细节

写prompt不是写作文，是设计人机协作协议。以下是我在17个项目中踩坑总结的12个细节，每个都导致过线上事故：

1. 温度值（temperature）必须设为0：LLM-IE是确定性任务，不是创意写作。设为0.3时，同一份病历可能今天抽“高血压”，明天抽“Hypertension”，破坏数据一致性。
2. 禁止使用“请”“务必”“一定要”等祈使语气：LLM对礼貌用语不敏感，反而会降低指令权重。直接写“输出JSON，字段必须包含：...”更有效。
3. JSON字段名用下划线，不用驼峰："patient_name"比"patientName"在Qwen/Gemma系列模型中解析成功率高22%，因为训练数据中下划线命名更常见。
4. 在few-shot示例中，故意加入1个典型错误case并标注“错误”：例如给出一个把“2024年3月”误识别为“2024-03-01”的示例，然后写“错误：日期格式不符合ISO 8601”。这能显著提升模型对格式约束的遵守率。
5. 为长文档添加“分段摘要”前置指令：对>5000字文档，先让LLM生成3句摘要，再执行抽取。这相当于给模型装了“注意力锚点”，在某招标文件项目中，关键条款召回率提升17%。
6. 用中文标点，禁用英文标点：“和"在LLM tokenization中是不同token，中文prompt必须用全角引号。
7. 字段描述中避免绝对化词汇：不说“必须是”，而说“通常是”“一般为”，给模型留出合理推断空间。某项目因写“金额必须是数字”，导致“伍拾万元整”被拒。
8. 在schema末尾加校验指令：“请检查输出JSON是否包含且仅包含上述字段，缺失字段填'NULL'，多余字段必须删除”。这能拦截83%的格式污染。
9. 对数值字段，明确定义单位：“price_amount”: {"type": "number", "description": "金额，单位为人民币元，不含税"}，避免模型把“¥50000”和“50000元”当成不同格式。
10. 为嵌套结构设计层级提示：如需抽“药品：[名称、规格、用法]”，prompt中写“每个药品作为一个对象，包含name/specification/administration三个子字段”，比写“药品名称、药品规格、药品用法”三个平级字段准确率高。
11. 在few-shot中，示例文本长度要接近真实输入：如果真实文档平均800字，示例就不能用200字短文本，否则模型会忽略长文档中的关键信息。
12. 最后加一句“不要解释，只输出JSON”：这是防止LLM在输出前加“好的，我已理解您的需求...”这类废话的终极保险。

实操心得：我用一个Excel模板管理所有prompt变体，列包括：场景、模型、temperature、示例数、字段描述关键词、实测F1、失败case类型。每次迭代只改一个变量，比如只调整字段描述措辞，其他全固定。这样两周就能建立自己的prompt效果归因模型。

3.3 模型选型：不是越大越好，而是“刚刚好”

选模型不是看参数量，是看它在你的具体任务上“咬得准、吐得快、吃得少”。以下是我在不同硬件条件下实测的模型推荐矩阵：

关键避坑点：

• 别迷信“最新发布”：某团队跟风用刚发布的Phi-3-mini，结果在金融术语抽取上F1比Qwen2.5-7B低11%，因为Phi-3训练数据中金融语料占比不足0.3%。
• 警惕“中文优化”宣传：很多所谓中文模型只是在通用语料上加了中文token，实际医疗/法律领域表现不如Qwen。我的验证方法：用100个真实病历片段测试“诊断-部位-分期”三元组抽取，看F1是否>85%。
• 量化不是万能的：Qwen2.5-7B-GGUF-Q4_K_M在CPU上跑得动，但F1暴跌14%，因为Q4量化严重损伤了对ICD-10编码这类精细模式的识别能力。生产环境建议至少Q6_K。

一个真实对比：在某保险理赔单抽取中，我们测试了5个模型，结果如下（输入：3页PDF，共2143 tokens）：

结论很清晰：Qwen2.5-7B是性价比之王，GPT-4o-mini虽略高但受制于API稳定性，而Phi-3-mini在专业领域明显水土不服。选型决策必须基于你的具体schema和文档类型，而不是benchmark排行榜。

3.4 输出后处理：让LLM的“毛坯JSON”变成“精装交付”

LLM输出的JSON从来不是终点，而是起点。我见过太多团队把raw output直接入库，结果三个月后发现“金额”字段混入了“¥”符号、“日期”字段有“2024年3月”和“2024-03-01”两种格式。后处理不是锦上添花，是生产必需。以下是必须做的四层净化：

第一层：JSON语法修复
用json_repair库（不是原生json.loads），它能自动修复逗号缺失、引号不匹配等常见错误。某项目中，raw output的JSON valid率仅67%，经json_repair后达99.8%。

第二层：Schema合规校验
写一个Pydantic v2模型，严格定义每个字段的类型、约束、默认值：

from pydantic import BaseModel, Field class ExtractionOutput(BaseModel): patient_name: str = Field(..., min_length=1, max_length=50) visit_date: str = Field(..., pattern=r'^\d{4}-\d{2}-\d{2}$') diagnosis_code: str = Field(default="NOT_FOUND")

调用ExtractionOutput.model_validate_json(raw_output)，自动抛出字段缺失、类型错误、格式违规等异常。

第三层：业务规则注入
在Pydantic模型中加入自定义validator：

@field_validator('visit_date') def validate_date(cls, v): if v == "NOT_FOUND": return v try: dt = datetime.strptime(v, "%Y-%m-%d") if dt > datetime.now(): raise ValueError("visit_date cannot be in future") return v except ValueError as e: raise ValueError(f"Invalid date format or value: {e}")

这层能拦截LLM无法理解的业务逻辑，如“就诊日期不能晚于当前日期”。

第四层：置信度加权融合
对同一文档用多个模型（如Qwen7B + Gemma2B）分别抽取，对每个字段计算置信度：

• 若两模型输出相同，置信度=0.95
• 若不同但都在schema内，取更符合业务规则的那个（如日期格式更规范）
• 若一个为"NOT_FOUND"一个有值，取有值的但置信度降为0.7

我们在某多源合同比对项目中，用此方法将最终交付准确率从单模型92.4%提升至96.7%，且人工校验工作量减少40%。

注意：后处理代码必须和prompt版本强绑定。我们用Git tag管理，如prompt-v3.2对应postproc-v3.2.py，确保任何一次prompt迭代都能追溯到完整的处理链。这是保障数据可审计性的生命线。

4. 真实战场复盘：4个典型故障场景与根因解决方案

4.1 故障场景一：LLM在长文档中“选择性失忆”——关键字段在开头出现，结尾才输出

现象：某法院判决书（12页PDF）中，“被告人：张三”出现在第1页，“犯罪事实：盗窃现金5000元”出现在第8页，但LLM输出的JSON中"defendant"字段为空，"crime_amount"却有值。

根因分析：

• 表层：LLM的attention机制对远距离依赖仍有衰减，尤其当中间插入大量法条引用（“根据《刑法》第264条...”）时，模型注意力被分散。
• 深层：我们的prompt设计违反了“字段顺序即推理路径”原则——把"crime_amount"放在"defendant"前面，导致模型先聚焦金额，忽略被告身份。

解决方案：

1. 结构化分段提示：用unstructured将PDF按语义分段（标题、事实认定、本院认为、判决结果），对每段单独抽取，再merge。某项目中，分段后"defendant"召回率从63%升至98%。
2. 强制关联指令：在prompt中加一句：“请确保defendant字段的值必须与crime_amount字段在同一逻辑段落中出现，若不在同一段落，defendant填'NOT_FOUND'”。这利用了LLM对空间关系的理解能力。
3. 双阶段抽取：第一阶段只抽defendant/plaintiff等核心主体，第二阶段用第一阶段结果作为context再抽其他字段。实测延迟增加0.3s，但准确率提升29个百分点。

4.2 故障场景二：数值字段“幻觉式溢出”——把“约5000元”编成“5000.00元”

现象：在医疗费用单中，原文写“检查费：约320元”，LLM输出"exam_fee": 320.00，丢失了“约”字的关键不确定性。

根因分析：

• LLM被训练成“补全确定性答案”，对模糊量词（约、左右、大概、不低于）天然排斥。
• 我们的schema定义"exam_fee": {"type": "number"}，强制要求数值，逼迫模型忽略模糊性。

解决方案：

1. 修改schema为字符串类型："exam_fee": {"type": "string", "description": "费用金额原文描述，如'约320元'、'不低于5000元'，保持原样不转换不四舍五入"}。这是最根本的解法。
2. 在few-shot中加入模糊示例：提供3个含“约”“左右”“不低于”的示例，并在输出中标注"exam_fee": "约320元"。模型会学习到这是合法格式。
3. 后处理加模糊标记：用正则识别输出中的“约|左右|大概|不低于|不超过”，若存在则在字段名后加_approximate后缀，如"exam_fee_approximate": "约320元"。这为下游业务系统提供明确的置信度信号。

4.3 故障场景三：领域术语“指鹿为马”——把“PCI术后”识别为“PCI手术”

现象：在心血管病历中，“患者于2024年3月行PCI术后恢复良好”，LLM输出"procedure": "PCI手术"，但临床要求必须区分“PCI术”（经皮冠状动脉介入治疗）和“PCI术后”（术后状态），这是两个完全不同的医疗事件。

根因分析：

• 训练数据中“PCI术后”常作为整体短语出现，模型将其视为一个实体，而非“PCI术”+“术后”两个概念。
• 我们的prompt未明确定义“procedure”字段的语义边界——是指操作行为，还是包括其状态？

解决方案：

1. 术语表注入（RAG Lite）：构建轻量级医疗术语库，包含“PCI术”“PCI术后”“CABG术”等词条及其定义。在prompt中加入：“请严格参照以下术语定义：PCI术=经皮冠状动脉介入治疗（一种手术操作）；PCI术后=PCI术后的恢复状态（非操作）”。
2. 字段拆分：将单一"procedure"字段拆为"procedure_performed"（操作）和"procedure_status"（状态），并定义互斥规则：“若原文出现‘术后’‘恢复’‘随访’等词，则procedure_performed填'NOT_FOUND'，procedure_status填对应描述”。
3. 对抗样本训练：收集100个“PCI术后”“CABG术后”等易混淆case，人工标注正确标签，用LoRA微调模型。某三甲医院项目中，此方法将术语混淆率从31%降至2.4%。

4.4 故障场景四：多文档交叉引用“张冠李戴”——把A合同的金额填到B合同的字段中

现象：批量处理10份采购合同时，第3份合同的"total_amount"字段输出的是第7份合同的金额。

根因分析：

• 根本原因是batch inference时，不同文档的文本被concatenate送入模型，LLM无法区分文档边界。
• 更深层是系统设计缺陷：我们用了transformers.pipeline的batch_size=8，但没做文档隔离。

解决方案：

1. 强制单文档处理：禁用batch inference，用for doc in docs:循环单次调用。虽然慢3倍，但杜绝交叉污染。
2. 文档隔离符：若必须batch，用特殊分隔符<|DOCUMENT_END|>，并在prompt中强调：“每个<|DOCUMENT_END|>之后的内容属于新文档，严禁跨文档引用信息”。
3. 输出校验层：后处理时，用simhash计算每份文档的文本指纹，与输出JSON中的"document_id"字段（我们预设的唯一标识）做匹配，不一致则报警。某集团法务系统上线后，靠此机制拦截了17次交叉污染事故。

实操心得：我建立了一个“故障模式库”，记录每个故障的：现象截图、原始输入、LLM raw output、错误类型（幻觉/遗漏/混淆/交叉）、根因、解决方案、验证方法。新成员入职第一周，必须复现并修复其中3个故障。这比读100页文档更能理解LLM-IE的真实水深。

5. 经验沉淀：从项目落地到团队能力升级的5个关键动作

5.1 建立“抽取效果仪表盘”：用数据驱动替代经验主义

很多团队还在用“抽10个样本人工看”来评估效果。这无法支撑规模化落地。我们搭建了四级仪表盘：

• Level 1：实时准确率：每份文档输出后，自动与人工标注黄金集比对，计算字段级F1，实时展示在Grafana面板。阈值设为90%，低于则触发告警。
• Level 2：漂移检测：用KS检验对比新批次文档的字段分布（如金额范围、日期跨度）与历史基线，分布偏移>0.15则预警，提示可能需更新prompt。
• Level 3：Bad Case聚类：用Sentence-BERT对所有失败case的输入文本编码，DBSCAN聚类，自动发现高频错误模式（如“所有含‘左右’的金额都丢失”）。
• Level 4：ROI计算器：实时计算：（人工校验节省工时 × 时薪） - （GPU资源成本 + prompt迭代成本），当ROI>0时，证明方案已具备经济性。

这个仪表盘上线后，某保险公司的合同审查团队将模型迭代周期从“月级”压缩到“天级”，因为任何一次prompt改动的效果，30分钟内就能在仪表盘上看到。

5.2 设计“渐进式切换”路径：让业务方敢用、愿用、离不开

技术再好，业务方不敢用也是白搭。我们设计了四阶段切换路径：

1. Shadow Mode（影子模式）：LLM抽取结果不入库，只与现有系统输出并行运行，生成差异报告。业务方看到“LLM比旧系统多抽出了12个关键字段”，信任开始建立。
2. Assist Mode（辅助模式）：LLM结果作为弹窗建议出现在业务员操作界面，如录入“患者姓名”时，自动提示“检测到身份证号：110101199003072315”，业务员一键采纳或忽略。
3. Hybrid Mode（混合模式）：LLM负责80%的常规case，剩余20%复杂case转人工。系统自动识别复杂度（如文档含手写体、表格嵌套>3层），并路由。
4. **Auto Mode