你把一叠理赔材料交给 AI，问“第二张维修发票在不在”，它不能只搜索“第二张发票”几个字。因为真正的答案可能是：根本没有这份文件。再问申请表和查勘报告里的出险日期是否一致，也不能靠找到一段相似文字解决，而要分别取出两个日期，再做比较。
这正是 Angela Shi 在 Towards Data Science 文章里讨论的问题：企业文档检索的处理单位，不该总是一份 PDF 或几个文字片段；遇到案卷类资料，应该先把整个文件夹还原成一个可查询的对象。以下架构主张和示例均来自这一篇文章，尚无论文、第三方测评或实际部署数据交叉验证。
一个案卷，不是一堆小文档
RAG（Retrieval-Augmented Generation，检索增强生成）通常先从外部资料里找到相关内容，再让语言模型据此回答。常见做法是“切块”：把长文拆成小段，为每段建立索引，提问时召回相似片段。
这对寻找某句话很有用，却容易抹掉案卷本来的结构。作者举的虚构火灾理赔案例有 11 份 PDF、共 60 多页，包括申请表、保单、付款证明、查勘报告、报价单、发票、照片和往来信件，还有一份误放进来的车辆清单。它们围绕同一案件，却长得完全不同：有的是表格，有的是 prose，有的照片没有文字。
这些文件据作者粗略估计，可多次装入一个 200,000-token 的上下文窗口——也就是模型一次能够接收的文本容量。但“都塞进去”仍回答不好两个关键问题。缺失文件没有正文可供召回；日期核对则需要跨文件抽取和比较。作者还提到，模型读取长输入中部信息的可靠性可能低于两端，但供稿没有给出具体研究、模型、测试条件或差距，因此不能把它当成适用于所有模型的定律。
先列应有材料，再检查现有文件
作者建议先为每类案件写一份“预期材料清单”：应该有哪些文件、各要几份，以及在什么条件下需要。随后识别文件的元数据——描述文件的数据，例如文档类型、所属案件、日期和版本——再把预期与实际情况对照。
系统最后应给出三组结果：已经存在的材料、缺失的材料，以及属于其他案件的文件。这样，“没有找到”不再只代表检索失败，也可以成为明确的业务答案。
进一步说，可以把案件、文件和抽取出的日期等值放进关系型数据模型：不同对象各自成表，再用标识符连接。核对出险日期时，系统先从 claim form 和 adjuster’s report 分别取得对应字段，再比较两者，而不是让模型在一长串段落里凭印象回答。
输出案件状态，而不是一段原文
传统 RAG 常返回最相关的段落。作者认为，案卷任务更需要的是案件整体状态：材料是否齐全、是否混入错件、关键字段是否冲突。换句话说，检索仍然有用，但它发生在案卷结构之内，不能替代结构本身。
这套思路值得关注，因为它把工程问题从“怎样召回得更准”前移到了“系统究竟在管理什么”。对于理赔、信贷、医疗记录或招聘档案，一份文件的内容只是答案的一部分；文件之间的归属、数量和对应关系也需要进入索引。
局限与未知
- 文中的机构、日期、金额和文件均为作者虚构，不能视为真实保险业务成效；预期材料清单也不是摘自保险机构规范。
- 文章未提供准确率、召回率、错误率、成本或与传统 RAG 的对照实验。
- 配套仓库
doc-intel/notebooks-vol1提供了可对自有文件夹运行完整性检查的 notebook，但它与文章属于同一作者和项目，不能算独立验证。