I IDEAICU

Technology

LiteParse：文档解析别一上来就烧云服务，先把本地入口做成可分流系统

做 RAG 或文档 Agent，最容易被低估的不是向量库，也不是最后接哪个模型，而是文档进入系统前的第一步：解析。PDF、Word、Excel、PPT、图片和扫描件如果在入口就被切坏，后面再昂贵的召回、重排和大模型生成都只是在修补错误。

LiteParse 值得关注，是因为它没有把所有文档都推向“云端 OCR + VLM + 大模型理解”的重方案，而是明确站在本地优先、轻量解析、可路由的工程位置上。它由 LlamaIndex 团队 run-llama 开源，Apache-2.0 协议，GitHub 当前约 1.13 万 stars，官方定位是 fast and light 的开源 PDF/document parser。

它解决的是文档流水线里的成本边界

很多团队一开始会把文档解析直接交给云服务：上传文件、按页计费、返回 Markdown 或 JSON。这在复杂报表、扫描合同、多栏论文上很省事，但如果所有文档都这么处理，成本和合规压力会很快放大。大量日常文档其实有原生文本层，结构也不复杂，用重型解析并不划算。

LiteParse 的位置就是先把“能本地解决的部分”留在本地。官方 README 写得很清楚：它提供带 bounding box 的高质量空间文本解析，不依赖私有 LLM 特性，也不依赖云服务，所有流程在本机运行。遇到密集表格、多栏布局、图表、手写文字或扫描 PDF 这类硬文档，再路由给 LlamaParse 这类更重的云端解析器。

核心能力不是“转文本”，而是保留空间信息

  • PDFium 文本提取：利用 PDFium 做原生文本层解析，适合大量可复制文本的 PDF。
  • 可插拔 OCR：内置 Tesseract，同时支持 HTTP OCR server，可以接 EasyOCR、PaddleOCR 或自建 OCR 服务。
  • Bounding boxes：输出文本块坐标，方便还原阅读顺序、定位表格区域、做版面分析。
  • Markdown / JSON / Text：既能给人读，也能给 RAG 切块、索引和审计。
  • 页面截图：可以生成高质量页面截图，给需要视觉理解的 Agent 或 VLM 补充上下文。

这点比“能不能把 PDF 变成字符串”重要得多。RAG 里真正麻烦的是标题层级、表格、列表、链接、图片位置和阅读顺序。如果解析阶段把这些结构全部压平成一段纯文本，后面的 chunking 很容易把一个表格拆烂，或者把跨栏内容拼错。

复杂度检测是更实用的工程功能

LiteParse 的 lit is-complex 很适合放在生产流水线入口。它在全文解析前做一个便宜的 text-layer 检测，判断页面是否需要 OCR 或更重处理，并给出原因，比如 scanned、no-text、sparse-text、embedded-images、garbled、vector-text。

lit is-complex document.pdf
lit parse document.pdf --format markdown -o output.md
lit parse document.pdf --format json -o output.json
lit screenshot document.pdf -o ./screenshots

一个更稳的文档流水线可以这样设计：先跑 is-complex；简单 PDF 走 LiteParse 本地解析；需要 OCR 的页面走本地 OCR 或内网 OCR server；复杂扫描件、财报表格、多栏论文再进入 LlamaParse 或人工复核队列。这样不是盲目省钱，而是把每类文档放到合适的处理成本上。

多语言绑定让它容易接进现有系统

LiteParse 的内核是 Rust，同时提供 Python、Node.js/TypeScript、Rust 和 Browser/WASM 入口。CLI 名称统一为 lit，Python 可以 pip install liteparse，Node 可以 npm i @llamaindex/liteparse，Rust 可以 cargo install liteparse 或作为库集成，WASM 版本则让浏览器内文档解析成为可能。

这意味着它不只是一个命令行小工具。Python 适合接 RAG 脚本和离线批处理，Node 适合接 Web 后端和产品控制台，Rust 适合高性能服务，WASM 则适合“文件不出浏览器”的隐私型工具。对于做企业知识库或个人本地文档应用的人，这种部署弹性很关键。

不要把 LiteParse 当万能 OCR

边界也要说清楚。LiteParse 强在快速、轻量、本地和可路由，不是要替代所有复杂文档理解方案。官方也明确提示，密集表格、多栏布局、图表、手写文字和扫描 PDF，LlamaParse 这类云端重型解析器通常会更准。

更合理的判断是：如果你的文档大多有原生文本层、结构相对规整、对隐私和成本敏感，LiteParse 很适合做默认入口；如果你的材料以扫描件、复杂票据、财务报表和多模态页面为主，就应该把 LiteParse 当作分流器和低成本兜底，而不是最终答案。

结论

LiteParse 的价值不是“又一个 PDF 转 Markdown 工具”，而是把文档解析从单一云服务调用，拆成了可观察、可路由、可本地运行的前置层。先用本地解析处理简单文档，保留坐标和结构，再把真正复杂的页面送去重型解析，这条路径对 RAG、Agent 和企业知识库都更接近工程现实。