1. 这不是“调用API就完事”的信息抽取——为什么LLM正在重写NLP工程师的日常“Demystifying Information Extraction using LLM”——这个标题里藏着一个正在发生的行业转折点。过去五年我带过三支NLP工程团队从金融风控文档结构化、医疗病历实体识别到电商评论情感-属性联合抽取所有项目都绕不开一个铁律传统IEInformation Extraction pipeline 是“三段式牢笼”——NER → Relation Extraction → Event Detection每段都要标注、训练、调优、上线监控光是维护一个生产级的医疗命名实体识别模型每年光在数据清洗和bad case回捞上就要投入2.3人年。而现在当我看到 junior 工程师用一段不到50行的 prompt 一个开源 LLM 就在48小时内完成某保险理赔单关键字段出险时间、责任认定、赔付金额、伤残等级的92.7% F1提取且无需任何微调——我知道那套牢笼的锁扣正在被撬松。这不是说传统方法失效了。恰恰相反它暴露了一个更本质的问题我们过去把“信息抽取”当成一个纯技术任务却忽略了它的底层其实是人类认知压缩的映射过程——医生看一份CT报告3秒内就能定位“左肺上叶见3.2cm结节边缘毛刺SUVmax8.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划分为四个可量化的范式每个都有明确的适用边界和性能拐点范式典型场景准确率F1延迟ms/token人力成本关键限制Zero-shot Prompting快速POC验证、低频简单抽取如邮件主题分类、schema极简≤3字段68%-79%50极低1人天对prompt engineering敏感无法处理模糊指代Few-shot In-context Learning中等复杂度、需少量示例引导如医疗报告中的“肿瘤位置-大小-分级”三元组82%-89%80-120低3人天示例质量决定上限示例数5后收益递减Fine-tuning (LoRA)高精度要求、强领域特异性如金融监管文件中的“处罚依据条款号”抽取91%-94%60-90中2周需1k高质量标注存在灾难性遗忘风险RAG-Augmented Generation超长文档100页PDF、需引用原文证据如法律判决书中的“法条援引-事实依据”匹配87%-92%150-300高3周RAG检索质量是瓶颈需设计chunk策略举个真实案例某省级医保局要做“门诊处方单”结构化需抽“患者ID”“就诊日期”“诊断代码ICD-10”“药品名称”“用法用量”。我们对比了三种方案Zero-shot用Qwen2.5-72B直接prompt“请从以下文本中提取JSON{patient_id, visit_date, diagnosis_code, drug_name, dosage}”F173.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“听懂人话”的底层语言学逻辑很多工程师卡在第一步写了几十版promptLLM还是输出乱码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用pymupdffitz提取文本因为它能保留字体、颜色、位置信息。重点处理两个陷阱① 表格线被识别为换行符用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个细节每个都导致过线上事故温度值temperature必须设为0LLM-IE是确定性任务不是创意写作。设为0.3时同一份病历可能今天抽“高血压”明天抽“Hypertension”破坏数据一致性。禁止使用“请”“务必”“一定要”等祈使语气LLM对礼貌用语不敏感反而会降低指令权重。直接写“输出JSON字段必须包含...”更有效。JSON字段名用下划线不用驼峰patient_name比patientName在Qwen/Gemma系列模型中解析成功率高22%因为训练数据中下划线命名更常见。在few-shot示例中故意加入1个典型错误case并标注“错误”例如给出一个把“2024年3月”误识别为“2024-03-01”的示例然后写“错误日期格式不符合ISO 8601”。这能显著提升模型对格式约束的遵守率。为长文档添加“分段摘要”前置指令对5000字文档先让LLM生成3句摘要再执行抽取。这相当于给模型装了“注意力锚点”在某招标文件项目中关键条款召回率提升17%。用中文标点禁用英文标点“和在LLM tokenization中是不同token中文prompt必须用全角引号。字段描述中避免绝对化词汇不说“必须是”而说“通常是”“一般为”给模型留出合理推断空间。某项目因写“金额必须是数字”导致“伍拾万元整”被拒。在schema末尾加校验指令“请检查输出JSON是否包含且仅包含上述字段缺失字段填NULL多余字段必须删除”。这能拦截83%的格式污染。对数值字段明确定义单位“price_amount”: {type: number, description: 金额单位为人民币元不含税}避免模型把“¥50000”和“50000元”当成不同格式。为嵌套结构设计层级提示如需抽“药品[名称、规格、用法]”prompt中写“每个药品作为一个对象包含name/specification/administration三个子字段”比写“药品名称、药品规格、药品用法”三个平级字段准确率高。在few-shot中示例文本长度要接近真实输入如果真实文档平均800字示例就不能用200字短文本否则模型会忽略长文档中的关键信息。最后加一句“不要解释只输出JSON”这是防止LLM在输出前加“好的我已理解您的需求...”这类废话的终极保险。实操心得我用一个Excel模板管理所有prompt变体列包括场景、模型、temperature、示例数、字段描述关键词、实测F1、失败case类型。每次迭代只改一个变量比如只调整字段描述措辞其他全固定。这样两周就能建立自己的prompt效果归因模型。3.3 模型选型不是越大越好而是“刚刚好”选模型不是看参数量是看它在你的具体任务上“咬得准、吐得快、吃得少”。以下是我在不同硬件条件下实测的模型推荐矩阵场景推荐模型显存需求单次推理耗时1k tokens适用理由本地部署24G显存Qwen2.5-7B-Instruct18GB1.2s中文理解最强对医疗/法律术语覆盖广7B规模可在RTX4090跑满云服务成本敏感Gemma-2-2B-Instruct6GB0.4sGoogle开源license宽松2B模型在简单抽取任务上F1超Qwen7B 2.3%超长文档10k tokensDeepSeek-V2-Lite22GB3.8s支持128k上下文attention优化好某法院卷宗项目中长程依赖recall达89%需要强推理如因果链抽取LLaMA-3-8B-Instruct24GB2.1s推理能力突出适合“因XX事件导致YY损失”这类因果三元组抽取关键避坑点别迷信“最新发布”某团队跟风用刚发布的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模型准确率F1P95延迟GPU显存占用人工校验率Qwen2.5-7B-Instruct92.4%1.3s18.2GB8.3%LLaMA-3-8B-Instruct91.7%2.2s23.8GB9.1%Gemma-2-2B-Instruct87.2%0.45s5.9GB14.6%Phi-3-mini-4k-instruct80.3%0.8s4.1GB28.9%GPT-4o-mini93.1%0.6s-API7.2%结论很清晰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_length1, max_length50) visit_date: str Field(..., patternr^\d{4}-\d{2}-\d{2}$) diagnosis_code: str Field(defaultNOT_FOUND)调用ExtractionOutput.model_validate_json(raw_output)自动抛出字段缺失、类型错误、格式违规等异常。第三层业务规则注入在Pydantic模型中加入自定义validatorfield_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(fInvalid 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前面导致模型先聚焦金额忽略被告身份。解决方案结构化分段提示用unstructured将PDF按语义分段标题、事实认定、本院认为、判决结果对每段单独抽取再merge。某项目中分段后defendant召回率从63%升至98%。强制关联指令在prompt中加一句“请确保defendant字段的值必须与crime_amount字段在同一逻辑段落中出现若不在同一段落defendant填NOT_FOUND”。这利用了LLM对空间关系的理解能力。双阶段抽取第一阶段只抽defendant/plaintiff等核心主体第二阶段用第一阶段结果作为context再抽其他字段。实测延迟增加0.3s但准确率提升29个百分点。4.2 故障场景二数值字段“幻觉式溢出”——把“约5000元”编成“5000.00元”现象在医疗费用单中原文写“检查费约320元”LLM输出exam_fee: 320.00丢失了“约”字的关键不确定性。根因分析LLM被训练成“补全确定性答案”对模糊量词约、左右、大概、不低于天然排斥。我们的schema定义exam_fee: {type: number}强制要求数值逼迫模型忽略模糊性。解决方案修改schema为字符串类型exam_fee: {type: string, description: 费用金额原文描述如约320元、不低于5000元保持原样不转换不四舍五入}。这是最根本的解法。在few-shot中加入模糊示例提供3个含“约”“左右”“不低于”的示例并在输出中标注exam_fee: 约320元。模型会学习到这是合法格式。后处理加模糊标记用正则识别输出中的“约|左右|大概|不低于|不超过”若存在则在字段名后加_approximate后缀如exam_fee_approximate: 约320元。这为下游业务系统提供明确的置信度信号。4.3 故障场景三领域术语“指鹿为马”——把“PCI术后”识别为“PCI手术”现象在心血管病历中“患者于2024年3月行PCI术后恢复良好”LLM输出procedure: PCI手术但临床要求必须区分“PCI术”经皮冠状动脉介入治疗和“PCI术后”术后状态这是两个完全不同的医疗事件。根因分析训练数据中“PCI术后”常作为整体短语出现模型将其视为一个实体而非“PCI术”“术后”两个概念。我们的prompt未明确定义“procedure”字段的语义边界——是指操作行为还是包括其状态解决方案术语表注入RAG Lite构建轻量级医疗术语库包含“PCI术”“PCI术后”“CABG术”等词条及其定义。在prompt中加入“请严格参照以下术语定义PCI术经皮冠状动脉介入治疗一种手术操作PCI术后PCI术后的恢复状态非操作”。字段拆分将单一procedure字段拆为procedure_performed操作和procedure_status状态并定义互斥规则“若原文出现‘术后’‘恢复’‘随访’等词则procedure_performed填NOT_FOUNDprocedure_status填对应描述”。对抗样本训练收集100个“PCI术后”“CABG术后”等易混淆case人工标注正确标签用LoRA微调模型。某三甲医院项目中此方法将术语混淆率从31%降至2.4%。4.4 故障场景四多文档交叉引用“张冠李戴”——把A合同的金额填到B合同的字段中现象批量处理10份采购合同时第3份合同的total_amount字段输出的是第7份合同的金额。根因分析根本原因是batch inference时不同文档的文本被concatenate送入模型LLM无法区分文档边界。更深层是系统设计缺陷我们用了transformers.pipeline的batch_size8但没做文档隔离。解决方案强制单文档处理禁用batch inference用for doc in docs:循环单次调用。虽然慢3倍但杜绝交叉污染。文档隔离符若必须batch用特殊分隔符|DOCUMENT_END|并在prompt中强调“每个|DOCUMENT_END|之后的内容属于新文档严禁跨文档引用信息”。输出校验层后处理时用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 3Bad Case聚类用Sentence-BERT对所有失败case的输入文本编码DBSCAN聚类自动发现高频错误模式如“所有含‘左右’的金额都丢失”。Level 4ROI计算器实时计算人工校验节省工时 × 时薪 - GPU资源成本 prompt迭代成本当ROI0时证明方案已具备经济性。这个仪表盘上线后某保险公司的合同审查团队将模型迭代周期从“月级”压缩到“天级”因为任何一次prompt改动的效果30分钟内就能在仪表盘上看到。5.2 设计“渐进式切换”路径让业务方敢用、愿用、离不开技术再好业务方不敢用也是白搭。我们设计了四阶段切换路径Shadow Mode影子模式LLM抽取结果不入库只与现有系统输出并行运行生成差异报告。业务方看到“LLM比旧系统多抽出了12个关键字段”信任开始建立。Assist Mode辅助模式LLM结果作为弹窗建议出现在业务员操作界面如录入“患者姓名”时自动提示“检测到身份证号110101199003072315”业务员一键采纳或忽略。Hybrid Mode混合模式LLM负责80%的常规case剩余20%复杂case转人工。系统自动识别复杂度如文档含手写体、表格嵌套3层并路由。**Auto Mode