文档附件解析管线

更新于 2026-08-03

**结论**：文档附件管线的成败由四件事决定 —— ① 分块按文档结构切而不是按字符切；② 表格这类计算任务交给执行器、模型只负责解释结果；③ 全局任务要遍历全部块，不能只取检索排名靠前的几块；④ 附件块独立绑定 Session 并自带 TTL，不挂在既有的整篇向量上。

分块：按结构切，不是按字符切

流程是 上传 → 提取结构 → 生成带位置的块 → 当前问题检索相关块 → 送入模型，不是每隔若干字符切一刀。

要点是块要自带定位信息（页码/表头/行号），否则引用时无法回指原文。

只做「分块 + 检索」无法可靠完成求和、筛选、排序、找异常、生成图表。表格附件应同时进入隔离的表格执行器，由工具计算，模型负责解释结果 —— 不要让模型心算整张表。

按问题检索只适用于「问具体问题」。但「总结整份文件」「比较全部工作表」这类全局任务要遍历所有块：先分块总结，再汇总最终结论。只取搜索排名靠前的几块会漏掉内容。

可以复用已有的 embedding 能力，但附件块必须独立绑定 Session，并按 7 天 TTL 清理。既有向量是按整篇笔记/剪藏建立的，不具备附件级的文件对象、解析状态、过期时间和 chunk 模型 —— 不能把文件硬塞进旧的 attachment 结构。

不是所有格式都值得走 OCR 服务，按「本地解析够不够」分流：

选型判据是依赖与部署复杂度最低：OCR 服务只负责提取，不承担 Session 存储与 TTL；首批因此不必引入重型自建解析容器。