如何让 AI 提取关键信息：先定义字段，再处理缺失和冲突
把“提取重点”改造成字段、类型、证据和缺失规则清楚的信息抽取任务，让结果可复用、可核验、可追溯。
相关工具
提取重点不等于写一段概括
“请从这份资料里提取重点”是一个很常见的要求，也很容易得到不稳定的结果。模型可能写一段摘要，可能列出几个主题，也可能挑出它认为重要的句子。它们都像是在提取重点，但没有统一字段，后续无法比较、筛选或放进业务流程。
信息提取的第一步不是让模型阅读，而是先定义你到底要拿到什么。是姓名、日期、金额和订单号，还是问题、影响、负责人和截止时间？如果结果要进入表格或数据库，字段必须比“重点”“相关信息”更具体。
《LLM 入门资料》中关于文本转换和输出检查的内容，反复强调输入与输出的对应关系。抽取任务也是一样：先定义字段，再规定类型、缺失值和来源，模型才知道哪些信息需要找，找到后应该怎样交付。
从字段定义开始，定位原文、提取内容、处理缺失与冲突，最后形成结构化输出。
字段设计决定提取结果能不能用
一个好字段至少要有名称、含义和范围。比如“日期”可能指下单日期、交付日期或会议日期；“金额”可能是含税金额、折扣前金额或退款金额。字段名越宽，模型越需要猜。可以把字段写成“订单交付日期”“含税订单总额”，并说明对应的上下文。
还要说明字段类型。姓名和问题通常是字符串，金额可能是数字，日期可以统一为 YYYY-MM-DD，多个商品应当是数组。类型约束不是为了形式整齐，而是让结果能被程序或人工批量处理。一个字段一会儿输出数字，一会儿输出“约一千元”，后续统计就会出问题。
字段还需要缺失规则。没有找到信息时，是使用 null、空字符串、空数组，还是写“未提供”？不同任务可以采用不同规则，但必须提前说明。不要让模型用“应该是”“可能为”填满空白，那会把未知内容伪装成已提取的信息。
明确字段名、类型、必填性、缺失值和原文依据，才能让提取结果稳定、可追溯。
要求保留原文证据，而不是只给结论
提取结果如果没有证据，复核会很困难。除了字段值，还可以要求返回原文片段、页码、段落或表格行号。比如提取合同里的付款条件时，不能只给出“30 天内付款”，还应该保留对应条款和来源位置。证据让人知道结果从哪里来，也方便处理争议。
证据不一定要很长。可以要求“每个字段最多保留一段支持判断的原文”，或者“返回原文片段和页码，不要复制无关上下文”。证据范围太大，会增加输出噪声；完全不留证据，则很难判断模型是不是把相邻内容拼在了一起。
对于无法确定的内容，可以同时输出值、证据和置信说明，但不要把模型的置信度当成事实证明。真正的核验仍然要回到原文，尤其是金额、日期、政策条款和责任信息。模型的分数只能帮助排序人工检查优先级，不能替代来源。
缺失、重复和冲突要分开处理
缺失是材料没有提供，重复是同一信息出现多次，冲突是不同位置给出了不同值。三种情况不能都写成一个答案。缺失应标记为空或待确认；重复可以保留来源并去重；冲突则要列出各个值、来源和时间，交给规则或人工判断。
Prompt 可以这样写：“如果字段在原文中没有出现，使用 null；同一字段出现多次时，保留所有来源并判断是否为重复；出现不同金额或日期时，不要自行选择，输出冲突列表并标记待核验”。这类规则比“请准确提取”更能防止模型把矛盾内容悄悄合并。
如果存在版本优先级，也要写出来。例如新版本文件优先于旧版本，正式合同优先于讨论稿，明确日期的记录优先于没有日期的记录。优先级是业务规则，不应让模型只凭语言感觉自行决定。
用结构化输出减少结果漂移
信息提取通常适合表格或 JSON。表格方便人阅读和检查，JSON 方便程序读取和后续自动化。无论使用哪一种，都要固定字段、顺序和空值写法，并要求不要输出字段之外的解释。否则模型可能在一次回答中增加字段，下一次又改变名称。
可以给出一个最小 Schema：姓名是字符串，日期是日期，金额是数字，证据是字符串，商品明细是数组。对于枚举字段，要列出允许的取值，例如 severity 只能是 high、medium、low。示例负责展示结构，规则负责说明边界，两者最好同时出现。
复杂资料可以先提取，再让另一个步骤做格式检查；也可以在同一 Prompt 中要求“输出后检查字段是否齐全、类型是否正确、是否有无依据内容”。但自检只能作为辅助，关键数据仍然需要程序校验或人工复核。
一份可以直接复用的信息提取 Prompt
以从采购订单中提取字段为例，可以这样写：
任务：从下面的采购订单中提取结构化信息。
字段：order_id、supplier、order_date、delivery_date、contact、items、total_amount、payment_method、evidence。
类型：日期统一为 YYYY-MM-DD；total_amount 为数字；items 为数组，每项包含 name、quantity、unit_price、amount。
缺失规则：原文没有提供的字段使用 null；没有商品明细时 items 使用 []。
证据规则：每条核心字段保留对应原文片段和页码；不要用常识补充。
冲突规则：同一字段出现多个不同值时全部列出，并标记 conflict=true，不要自行选择。
输出：只输出合法 JSON，不要添加解释文字。
材料：
<<<
在这里粘贴订单文本
>>>这个 Prompt 的价值在于它把“提取什么”和“遇到特殊情况怎么办”同时交代出来。换成合同、会议记录或客户反馈，只需要替换字段和冲突规则，整体结构仍然适用。
交付前按五项检查提取质量
第一，字段是否齐全；第二，内容是否真的来自原文；第三，类型和格式是否正确；第四，有没有重复或冲突没有标记；第五，每个关键结果能不能回到来源。检查时不要只看 JSON 是否合法，合法 JSON 里也可能装着错误字段和无依据内容。
如果字段缺失，补充字段定义或原文定位规则；如果内容不是原文，标记待确认并回到材料核验；如果类型错误，统一 Schema 和示例；如果有冲突，按版本规则或人工流程处理；如果无法追溯，增加证据字段和来源位置。每类问题对应不同修复动作。
信息提取的最终目标，不是让模型看起来很会读，而是把非结构化资料变成一组可以使用、检查和追溯的数据。字段先于表达，证据先于结论，未知就标记未知。把这三个原则写进 Prompt，提取结果会稳定很多。
检查字段完整性、原文依据、类型、重复冲突和可追溯性，不通过时返回对应环节处理。
常见问题
为什么只说“提取重点”不够？
因为重点没有固定字段和验收标准。明确字段、类型、来源和缺失规则，结果才更稳定。
提取结果一定要返回原文证据吗？
涉及金额、日期、合同、政策和责任信息时，建议返回原文片段和来源位置，方便复核和追溯。
遇到多个冲突值时应该怎么做？
列出各个值及其来源和时间，按照预先定义的版本或优先级处理；没有明确规则时标记待确认，不要自行合并。