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

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

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

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

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

写到第二天凌晨看着满屏 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 有要求，小项目跑不太起

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

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

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

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