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

查看 10|回复 0
作者:Tsang72   
最近搞了个小项目,给一段 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 直接看原始表格。
    写下来还有几个事情没想清楚,想请教下大家:
    [ol]
  • 多文档场景下,cross-document 的引用和对比怎么处理?现在简单按 section 对齐,但两份报告对同一指标给出不同结论这种,很难自动对得上
  • 大表格(几百行)整块塞 prompt 里 token 吃不消,有没有比较成熟的"按列采样"或者"先 summary 再 drill down"的做法
  • 自己拼开源 pipeline vs 直接调 API ,长期成本你们怎么算的?我现在用 API 主要是图省事,但跑量上去之后心里没底
  • async job 这种模式,前端轮询和 SSE 你们更倾向哪种?我现在是混着来的,感觉不太干净
    [/ol]
    技术栈顺手记一下:Next.js 16 + Bun + Turborepo + oRPC + Drizzle + Postgres + Vercel AI SDK + Vercel Blob 。
    https://github.com/Ontos-AI/knowhere-pitchpilot
  • 您需要登录后才可以回帖 登录 | 立即注册

    返回顶部