解析整個案卷，而不只是 PDF：案件卷宗需要的關係型表結構

在文档智能的工程实践中，一个反复出现的误区是把 RAG 系统简化成「把 PDF 切成片段、做向量检索、再丢给大模型」。这套流程在处理博客文章、技术文档或内部 Wiki 时或许够用，但一旦进入法律卷宗、保险理赔、信贷审批这类以「案件」为单位的场景，就会暴露出根本性的缺陷。一篇近期来自 Towards Data Science 的分析文章直指这个问题：真正需要解析的不是 PDF，而是整个案卷；真正值得构建的两个查询根本不是检索问题，而是关系型表结构问题。这个判断之所以重要，是因为它点破了当前大多数企业级文档系统在架构起点上的偏差。案件类文档的核心价值不在单页文本的语义里，而在跨文档、跨页面、跨时间线的关系网络中。一份贷款申请材料，其意义不在于某一张收入证明上写了多少数字，而在于收入证明与银行流水、征信报告、申请表之间能否被精确地对应、比对与追溯。

把这一切塞进一个向量数据库，等于把一张关系网压成一把散落的沙子。从技术原理上看，向量检索的本质是语义相似度匹配，它擅长回答「哪段文本和这个问题最相关」，却不擅长回答「A 文档里的金额和 B 文档里的金额是否一致」「这份合同的签署方是否覆盖了所有必需条款」「某个时间戳落在哪个审批流程的哪一环」。这些问题没有相似度答案，只有真值或假值、是或否、匹配或不匹配。它们属于关系型数据库的领地，属于外键、约束、聚合与连接操作，而不是嵌入空间的余弦距离。作者的核心主张是，在打开任何案卷之前，索引系统就应该知道这份案卷属于哪种案件类型，并据此预先列出该类型所要求的内容清单。这意味着系统需要具备领域知识：一个离婚案件的卷宗需要哪些文件，一个工程招标需要哪些资质证明，一个保险理赔需要哪些单据。

这种「按案件类型驱动的结构化抽取」与「先全文切块再被动检索」是两种对立的范式。前者把业务规则前置为 schema，让抽取有章可循；后者把一切平等地摊平，依赖模型在检索时临时拼凑。后者在法律场景里尤其危险，因为一旦关键关系在切块过程中被切断，模型只能基于残缺的语义碎片去推断，错误会以极高的置信度呈现出来。从商业与行业影响来看，这个区分的后果直接体现在准确率与责任归属上。法律、金融、医疗等行业对文档处理的错误容忍度极低，一个字段错位可能导致整笔贷款被拒、一个理赔被误判、一份合同条款被漏读。当错误源自向量检索的语义漂移时，责任模糊、难以追溯；当错误源自关系表结构的缺失时，责任清晰、可被架构修正。

因此，头部企业正在把资源从「更好的切块策略」转向「更严谨的案件 schema 设计」。竞争格局也随之分化：一批厂商继续卷嵌入模型与检索排序，另一批则开始构建面向垂直案件的结构化抽取引擎，后者在专业场景里往往更具壁垒。对用户群体而言，这意味着选择文档智能方案时，不能只问「你的检索准确率多高」，而要问「你能否在读取文件前就告诉我这份案卷需要哪些材料、哪些字段、哪些关联」。至于后续发展，值得关注的信号有几个。其一，案件类型驱动的 schema 能否被自动化生成，即系统是否学会从历史案卷中归纳出某类案件的通用表结构，而不是每次靠人工定义。其二，关系型结构与向量检索如何在一个系统内协同，让「结构化查询定位关键文档」与「语义检索填充细节」形成互补而非互相替代。其三，这类表结构能否标准化为跨机构、跨系统的通用案件数据模型，从而让不同律所、不同保险公司、不同银行之间实现真正的数据互通。如果这三个方向能够推进，文档智能才会从「能读懂 PDF」真正迈向「能办成案件」。这或许是整个行业从演示走向生产的关键分水岭。