北京
很多人处理文档时有个惯性假设：上传的是PDF，就该用一套PDF提取方案。但文件真正打开后，现实往往更混乱——前两页是结构化表单，接下来五页是带表格的发票，然后是叙述性说明、签字审批页、几张照片，最后还有一段密集排版的合同摘录。用户眼里这是一份提交材料，存储层也只存了一个文件，但内容本身根本不是一回事。
表单、表格、自由文本承载信息的方式截然不同。表单要的是命名字段，表格重复的是行记录，叙述段落靠上下文和论证结构传递含义。强行把三者塞进同一种格式，结果往往是：散文被挤进JSON字段，表格压平成不可靠的文本，复选框消失在Markdown里，或者表单字段埋进一大段下游系统还得重新解析的内容块。
真正该问的不是"怎么提取这份文档"，而是"文档的每个部分需要什么表示形式"。
表单的核心是命名值。业务流程通常需要特定事实：申请人姓名、出生日期、同意状态、申请金额、保单号、会员ID、签字日期、税务状态或所选权益。这些事实直接驱动工作流决策——创建案件、路由审核、确认资格、生成回复，或在缺少同意书时阻断下一步。对这种内容，类型化字段才是合适的形态。字段名应对接目标系统，而非页面上的标签文字。复选框应转化为"has_signed_consent"这样的业务决策，而非模糊的标记；日期应说明是哪个日期；缺失值就该保持缺失，而不是变成看似有意的空字符串。
表单提取的难点不只是读取方框，而是判断某个字段能否安全驱动下一步。低置信度的可选备注或许可以接受，低置信度的付款授权则必须暂停流程。一个基本清晰的表单区块可以生成部分记录，同时让某一字段等待复核。这使得表单提取既是解析问题，也是状态问题——输出必须保留置信度、引用来源、复核状态和已批准值，否则工作流无法区分"用户未提供""提取器不确定"和"复核员后来修正"这三种情况。
表格的逻辑完全不同，它建立在重复记录之上。发票含明细行，银行对账单含交易记录，供应商目录含SKU，合规报告含发现项。表格提取的目标不是定位单个值，而是识别哪些单元格属于同一行、哪些表头对应哪些列，以及当表格跨页时如何保持行的连续性。输出形式通常是对象数组，每行一个条目，列名作为键。这里的挑战在于结构一致性：有些表格有合并单元格，有些有嵌套表头，有些在PDF里只是视觉上对齐而非真正的表格结构。错误的行分组或列映射会让下游计算完全失真。
自由文本又是另一套规则。叙述性内容——事故描述、医疗记录、合同条款、研究背景——的价值在于论证结构：段落如何展开，标题如何组织话题，句子如何建立指代关系。把这种内容压平成键值对会丢失上下文，拆成独立句子则会切断指代链条。自由文本需要的是保留层级结构的格式，比如带标题的Markdown或分节的JSON，让下游系统能够引用特定段落、检测话题边界，或在需要时重构完整叙述。
混合文档的真正解法，是在提取前先做内容分类。不是按文件类型，而是按内容类型：这一页是表单，这一区域是表格，这一段是叙述文本。每种类型走各自的提取路径，生成各自的表示形式，最后在文档层面组装成统一输出——表单字段、表格数组、文本区块各自就位，同时保留页码、坐标和置信度等元数据，供下游路由和审核使用。
一刀切的时代早就该结束了。PDF只是容器，不是内容。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
