请教下：长 PDF / Word 解析后喂给 LLM，结构丢失问题大家都怎么处理

最近搞了个小项目，给一段 prompt 加一份长文档，自动出一版可以继续编辑的 PPT 草稿。本来以为最难的部分是 prompt 设计或者 PPT 渲染，结果 80% 的时间都耗在了文档解析上，记录一下踩过的坑，顺便想请教下各位在这块都是怎么处理的。

场景大概是这样：用户上传的资料是产品白皮书、研究报告、需求文档之类的，几十页起步，PDF 居多，也有 Word 和 Excel 。要做的事其实就一句话——把内容读懂，然后让 LLM 出一版 outline 加各页要点。

第一版我懒，直接把 PDF 转 base64 丢给 Gemini ，反正它号称百万 token 。跑了几次发现：

• 表格里的数字模型经常算错，碰到一份白皮书把"营收"和"利润"两列加在一起算了
• 章节层级基本崩，3.2 节的内容会跑到附录里去
• 模型自由发挥的成分肉眼可见地高，幻觉很重
• token 烧得也猛，账单看一眼就关了

第二版自己写解析。pdf.js + mammoth + SheetJS 一套全上。理论上很美好，跑起来就是另一回事：

• pdf.js 出来就是流水账文本，标题正文连段落都断不准
• 表格被压成空格分隔的字符串，模型一看就开始胡编
• 图片直接没了
• 多 sheet 的 Excel 还没来得及处理，docx 里的嵌套列表层级先丢了一半

写到第二天凌晨看着满屏 if/else 兼容代码我开始怀疑这条路。这事本身就不是手搓能搞定的，它涉及版面识别、OCR 、表格还原、章节关系恢复，本质上是一个独立的工程问题，不是周末项目能糊出来的。

然后开始看现成的方案，目前我试过和了解过的：

• LlamaParse：表格处理还行，国内访问要折腾代理，定价对小项目不算友好
• Unstructured：开源，自己部署。能跑，复杂表格的还原一般，要自己写一层 post-processing
• Knowhere：API 形式，异步 job 模型（创建 job → 拿 upload_url → PUT 文件 → 轮询 → 下载 ZIP ）。返回 chunks 带 type / 层级 / 页码 / bbox ，表格是 HTML ，图片单独抽出来还带摘要。我目前接的这个，主要图省事，省了自己做 OCR 和表格还原的活。缺点是 fallback 到自有 pipeline 比较麻烦，要做缓存层
• 某些大厂的 OCR / 文档智能 API：识别准但定位偏文字抽取，结构化这部分还得自己拼
• MinerU：开源里口碑不错，但部署起来对 GPU 有要求，小项目跑不太起

选完之后问题没全解决，下游怎么用结构化结果也得想。我现在的做法：

• chunks 持久化进 Postgres ，每个 chunk 单独存，方便后面按需引用
• 喂给 LLM 的优先是 sections + table summaries + image highlights ，原文只在事实核对的时候按需调
• 解析这步包成异步 workflow （用 Vercel Workflow ），失败可重试，命中缓存直接复用

这套改完之后同一份白皮书重新跑，10 页 PPT 之前有 4 页跑偏、2 个数据错，现在基本对得上原文。表格那块改善最明显，之前我都不敢让 LLM 直接看原始表格。

写下来还有几个事情没想清楚，想请教下大家：

1. 多文档场景下，cross-document 的引用和对比怎么处理？现在简单按 section 对齐，但两份报告对同一指标给出不同结论这种，很难自动对得上
2. 大表格（几百行）整块塞 prompt 里 token 吃不消，有没有比较成熟的"按列采样"或者"先 summary 再 drill down"的做法
3. 自己拼开源 pipeline vs 直接调 API ，长期成本你们怎么算的？我现在用 API 主要是图省事，但跑量上去之后心里没底
4. async job 这种模式，前端轮询和 SSE 你们更倾向哪种？我现在是混着来的，感觉不太干净

技术栈顺手记一下：Next.js 16 + Bun + Turborepo + oRPC + Drizzle + Postgres + Vercel AI SDK + Vercel Blob 。

https://github.com/Ontos-AI/knowhere-pitchpilot