W
AI-Wiki
ENTITY

LongParser

定义或身份

LongParser 是一款面向生产级 RAG 流水线的文档智能引擎，核心职责是解决 RAG 架构中的文档导入与前处理问题，而不是通用聊天框架。

它的定位非常明确：围绕文档摄取链路，处理多格式文档解析、分块、脱敏、OCR 质量控制、摘要、交叉引用关联、向量化前整理等工作，减少开发者在“源头数据进入知识库之前”的工程负担。

文中介绍的版本为 v0.1.5。该工具已 开源免费，采用 MIT 协议，允许免费使用与二次开发。

产品定位

LongParser 的产品定位有三个关键词：

  • 隐私优先：强调本地处理，尽量避免把敏感文档内容外发。
  • 面向生产环境：不是只做演示级解析，而是围绕真实部署中的吞吐、合规、任务解耦和集成问题设计。
  • 用于构建高质量 RAG 数据摄取流水线：它关注的是知识入库之前的数据质量，而不是回答生成本身。

这意味着它主要服务于 RAG 的“输入侧”。开发者可以继续使用自己的大模型、向量库、检索框架和对话层，但把文档处理这一段交给 LongParser。

角色职责

LongParser 在 RAG 系统中的职责主要包括：

  • 解析 PDF、DOCX、PPTX、XLSX、CSV 等多种格式文档。
  • 在切块时尽量保持语义完整，避免传统固定长度切分造成上下文割裂。
  • 对文档中的敏感信息进行脱敏，降低企业合规风险。
  • 过滤低质量 OCR 结果，避免乱码进入向量库污染检索。
  • 生成摘要，并把耗时摘要任务从主解析流程中拆出。
  • 解析“参见图 3”“下表”等内部交叉引用，保留文档内部关系结构。
  • 提供 SDK、REST API 以及对 LangChain、LlamaIndex 的集成接口，方便接入现有系统。

从职责边界看，它不是完整的企业 AI 平台，也不是大模型编排框架；它更像 RAG 前置摄取层中的专业引擎。

v0.1.5 的关键升级

语义分块

v0.1.5 的核心升级之一是语义分块。

传统 RAG 分块常按固定词元长度切割，容易把一句话切断、把同一主题拆散，导致召回失败或回答缺乏上下文。LongParser 在这一版本中引入 all-MiniLM-L6-v2 模型，通过跟踪文本块之间的余弦相似度，仅在主题真正发生变化时创建边界。

这类做法的目标不是单纯“切得更细”或“切得更整齐”，而是尽量保留完整语义单元，这与 数据库文档分块、结构化文档标注 所强调的“完整知识块优先”思路一致。

它还支持混合分块模式，可同时考虑：

  • 词元限制
  • 标题层级
  • 表格结构

文中明确提到，这使其能更好处理多栏论文、跨页表格、嵌套标题等场景，减少信息错乱。

PII 脱敏

v0.1.5 的另一项重点能力是双层 PII脱敏。

其脱敏引擎采用：

  • 正则表达式 + Luhn 验证：用于处理银行卡号、社保号等结构化敏感数据。
  • spaCy 命名实体识别（NER）：用于识别上下文中的个人信息。

这种组合形成“双层防护”：一层抓结构化字段，一层抓自然语言上下文中的敏感实体。

文中还提到一个重要细节：未脱敏原始数据会安全存储在隐藏元数据中。这意味着它在合规展示与后续可复用性之间做了折中：对外输出可以是脱敏后的内容，但底层仍保留受控原文以便后续处理。

零 ML OCR 过滤

LongParser v0.1.5 增加了零 ML OCR 过滤能力，用来自动剔除低质量 OCR 文本，防止乱码污染向量库。

它使用的是启发式评分器，综合：

  • OCR 置信度
  • 词典验证
  • fastText 语言识别

文中强调其特点是不依赖复杂机器学习模型，因此更加轻量。

异步摘要

对于需要 LLM 参与的摘要任务，LongParser 采用异步方式处理：把摘要调用卸载到 ARQ/Redis 后台进程，避免主解析管道被冻结。

这项能力的价值在于：

  • 让主文档处理流程不被摘要阻塞
  • 提升整体处理效率
  • 更适合生产环境中的任务队列式部署

交叉引用解析

LongParser 还支持文档内部交叉引用解析。文中说明，它使用 O(N) 单遍算法，把“参见图 3”“下表”等内部引用直接关联到对应数据块。

这使得入库后的内容不只是孤立文本块，而是尽量保留原始文档中的关系结构。

支持的接入方式

Python SDK

文中给出的 SDK 用法以 DocumentPipeline 和 ProcessingConfig 为入口，可直接处理本地文件：

from longparser import DocumentPipeline, ProcessingConfig
pipeline = DocumentPipeline(ProcessingConfig())
result = pipeline.process_file("document.pdf")

print(f"文档总页数：{result.document.metadata.total_pages}")
print(f"生成分块数量：{len(result.chunks)}")
print(f"第一个分块内容：{result.chunks[0].text}")

从示例可见，处理结果至少暴露了：

  • 文档元数据中的总页数
  • 分块列表
  • 每个 chunk 的文本内容

REST API

在生产场景中，文中更推荐通过 REST API 使用。其流程包括：

  1. 复制并修改配置文件。
  2. 启动 MongoDB 与 Redis。
  3. 启动 API 服务，示例端口为 8000。
  4. 上传文档，创建处理任务。
  5. 查询任务状态。
  6. 执行 finalize。
  7. 执行 embed，把内容写入向量库。
  8. 可继续创建对话会话并发起 RAG 问答。

文中的 API 样例体现出它把文档处理拆成了多个阶段性动作，而不是“一次调用完成全部”。这更符合生产流水线对审核、确认和异步执行的要求。

其中示例里的向量化请求给出了一个具体组合：

  • provider：huggingface
  • model：BAAI/bge-base-en-v1.5
  • vector_db：chroma

与文档对话

文中还给出了基于已处理任务发起问答的接口：

  • 创建 chat session
  • 向 /chat 发送 session_id、job_id 和问题

这说明 LongParser 不仅能做解析，还能把摄取后的内容继续接到文档问答链路上；但其核心价值仍在文档处理与入库前链路，而不是作为通用对话系统存在。

与框架集成

LongParser 提供对 LangChain 和 LlamaIndex 的直接集成。

LangChain 集成示例使用 LongParserLoader，返回 LangChain 文档列表；LlamaIndex 集成示例使用 LongParserReader，通过 load_data("report.pdf") 读取内容。

这意味着已有 RAG 项目若基于这些框架构建，可以把 LongParser 作为文档加载与预处理层接入，而无需重写一整套解析流程。

安装方式

文中列出三种安装方式。

方式 1：推荐安装

包含服务器、嵌入模型、向量数据库、OCR、LangChain、LlamaIndex 等完整功能：

pip install "longparser[gpu]"

文中说明 GPU 和 CPU 机器都可使用，torch 会自动适配模式。

方式 2：核心 SDK 安装

如果只需要核心解析能力，不需要服务器，也不需要 torch：

pip install longparser

方式 3：CPU-only 安装