标签
面向大学使用场景的本地文档处理工具（Docling、Liteparse、Mineru 和 Unstructured）对比，评估它们对本地部署的适用性。
百度发布了Unlimited-OCR，它可以一次性处理整个文档而无需分块，克服了当前OCR技术的一个主要限制。
Vik Paruchuri 正在开源一个9B模型，该模型可以从文档中提取结构化数据，性能接近前沿水平（在其基准测试中达到90.2%，而Gemini 3.5 Flash为91.3%）。
Hyper-Extract 是一个开源框架，可将混乱文档转换为类型化知识结构，支持多种图谱架构（如 GraphRAG、LightRAG 和 KG-Gen），拥有 10 多种提取引擎和 80 多个面向不同领域的 YAML 模板。
Typst 0.15 是开源排版系统的一个重要版本，引入了对可变字体、MathML 导出、多文件输出、多个参考文献列表和多个 PDF 标准的支持，同时还改进了文档和诊断功能。
PP-OCRv6是百度PaddleOCR新推出的开源OCR模型系列，提供Tiny/Small/Medium三种尺寸，精度和速度优秀，优于多个商业模型。
DeepSeek-OCR是一个3B参数的视觉模型，使用上下文光学压缩进行高效的文档处理。使用Unsloth在波斯语文本上进行微调，字符错误率降低了88.26%，全部开源且可在单GPU上运行。
# 用本地 LLM 构建文档转 JSON 提取器的心得——模型大小没你想的那么重要 几个月前，我着手构建一个完全本地运行的文档信息提取流水线。目标很简单：输入 PDF 或纯文本文档，输出结构化 JSON，整个过程不调用任何外部 API，数据不离开本机。 以下是我踩过的坑、学到的东西，以及目前仍在纠结的问题。 --- ## 技术栈 - **模型**：llama3.2 3B（通过 Ollama 运行） - **语言**：Python - **关键库**：`ollama` Python 客户端、`pydantic` 做数据校验、`pypdf` 解析 PDF - **运行环境**：普通消费级笔记本，无独立 GPU 选择 3B 模型是迫不得已——硬件限制。但这个限制反而逼着我把更多精力放在**系统设计**上，而不是一味依赖模型能力。 --- ## 核心发现：后处理比模型更重要 这是最反直觉的收获。 一开始，我以为只要 prompt 写得足够好，模型就能输出干净的 JSON。现实是：**即使提示词再完美，模型输出也会夹带噪声**——多余的解释性文字、截断的括号、偶尔出现的幻觉字段。 真正让提取质量飞跃的，是在模型输出之后加了一层**确定性后处理**： ```python import re import json def extract_json_from_response(text: str) -> dict: # 先尝试直接解析 try: return json.loads(text.strip()) except json.JSONDecodeError: pass # 用正则抓取第一个 JSON 块 pattern = r'\{[^{}]*(?:\{[^{}]*\}[^{}]*)*\}' matches = re.findall(pattern, text, re.DOTALL) for match in matches: try: return json.loads(match) except json.JSONDecodeError: continue raise ValueError(f"响应中未找到有效 JSON：{text[:200]}") ``` 这个简单的函数处理了大约 80% 的格式异常情况。 --- ## Schema 约束：另一个关键杠杆 与其让模型"自由发挥"决定输出哪些字段，不如把 schema 直接塞进 prompt，效果会好很多。 我用 Pydantic 定义目标结构，然后动态生成提示词： ```python from pydantic import BaseModel from typing import Optional, List class InvoiceData(BaseModel): invoice_number: str date: str vendor_name: str total_amount: float line_items: List[str] currency: Optional[str] = "CNY" def build_extraction_prompt(document_text: str, schema: BaseModel) -> str: schema_json = schema.schema() return f"""你是一个结构化数据提取助手。请从以下文档中提取信息，并**严格按照**指定的 JSON schema 输出。 ## 目标 Schema ```json {json.dumps(schema_json, ensure_ascii=False, indent=2)} ``` ## 文档内容 {document_text} ## 输出要求 - 只输出 JSON，不要有任何额外说明 - 所有字段必须存在 - 找不到的信息填 null，不要编造 """ ``` 加了这个约束之后，幻觉字段（模型凭空捏造的字段名）减少了大约 60%。 --- ## 仍在头疼的两个问题 ### 1. 长文档的上下文截断 llama3.2 3B 的上下文窗口有限。处理超过 3000 词的文档时，模型会开始"忘记"前面的内容，提取质量明显下降。 我目前的临时方案是滑动窗口分块： ```python def chunk_document(text: str, chunk_size: int = 2000, overlap: int = 200) -> List[str]: words = text.split() chunks = [] start = 0 while start < len(words): end = start + chunk_size chunk = ' '.join(words[start:end]) chunks.append(chunk) start += chunk_size - overlap # 重叠区域保留上下文 return chunks ``` 但分块之后又带来新问题：**如何合并来自不同块的提取结果？** 当一条关键信息横跨两个块的边界时，两边都只拿到了残缺的片段，合并逻辑变得很复杂。 有没有人处理过这类跨块实体合并的问题？ ### 2. 幻觉：模型会"脑补"不存在的信息 这是目前最让我头疼的问题。模型有时会对 `null` 值感到"不安"，倾向于用听起来合理的内容填充空字段。 我加了一个置信度校验层，但感觉还是治标不治本： ```python def validate_extraction(extracted: dict, source_text: str, threshold: float = 0.8) -> dict: validated = {} for key, value in extracted.items(): if value is None: validated[key] = None continue # 粗略检查：提取的值是否在原文中有据可查 value_str = str(value).lower() source_lower = source_text.lower() if value_str in source_lower: validated[key] = value else: # 标记为存疑，而非直接丢弃 validated[key] = { "value": value, "confidence": "low", "warning": "原文中未找到该值，请人工核查" } return validated ``` 这个方法对数字和日期还算有效，但对于语义层面的幻觉（比如用同义词替换原文表述）就完全失效了。 --- ## 意外惊喜：3B 模型的表现超出预期 坦白说，我预期 3B 模型会很拉垮，结果出乎意料。 在**结构清晰的文档**（发票、表单、标准合同）上，只要后处理做扎实，准确率能到 85–90%。 真正的瓶颈不是模型智力，而是： - 文档格式混乱（扫描件 OCR 质量差） - 字段定义模糊（"总金额"到底含不含税？） - 上下文跨块丢失 这让我重新思考一个问题：**在结构化提取任务上，我们是不是高估了大模型的必要性？** 很多时候，一个设计良好的小模型 + 严密的工程约束，能干掉一个被随意调用的大模型。 --- ## 希望听到你们的想法 目前最想求解的几个问题： 1. **跨块合并**：处理长文档分块提取时，你们是怎么做实体对齐和结果合并的？ 2. **幻觉检测**：有没有比字符串匹配更可靠的本地化幻觉检测方案？ 3. **替代方案**：有没有人试过用 `phi3` 或 `qwen2.5` 做类似任务？在相同硬件上表现如何？ 4. **上下文窗口**：Ollama 的 `num_ctx` 参数调大之后，内存占用和推理速度的权衡是怎样的？实际用下来值不值？ 这个项目目前是我自用的小工具，但如果能把幻觉问题压下去，我觉得可以做成一个更通用的本地文档处理框架。 欢迎拍砖、分享经验，或者告诉我哪里的思路完全走偏了。
用户分享了使用NotebookLM 6个月的经验，并给出了10个提示词，声称可以在1小时内将200页文档转化为清晰答案。
Microsoft 开源了 MarkItDown 工具，可将 PDF、Word、Excel、PPT 等文件一键转换为结构完整的 Markdown 格式，便于直接喂给 LLM，目前 GitHub Star 超过 138k。
参加了在柏林举办的应用人工智能大会，并做了关于构建文档代理的演讲，其中包括使用LlamaIndex构建的文档处理代理LobsterX的详细演示，该代理采用了结构化输出和事件驱动工作流。
这篇博客文章描述了使用Temporal构建可扩展的数据摄取管道的架构，用于处理来自不同来源的客户文档的抓取、提取、分块和嵌入，强调了持久性、状态性和并发控制。
作者分享了自己三年使用PDF喂AI的踩坑经历，指出Markdown比PDF更适合作为AI输入格式，因为PDF本质上是坐标+字符的混合体，AI需要先解析结构，容易出错且消耗更多token。文章提供了具体案例和推荐工具（markitdown、pandoc、LlamaParse），并预告了一个名为“喂AI的艺术”的新系列。
LightRAG v1.5 已发布，带来六大重大改进，包括多模态文档处理、增强的解析功能以及角色特定的 LLM 配置，使 RAG 更简单、更快速、更强大。
LlamaParse 现在为 Parse、Extract 和 Classify 任务提供延迟指标，包括排队时间、处理时间和总延迟的详细分解。这有助于用户监控和扩展其文档处理。
pdf-inspector 是一个开源的 Rust 库，用于智能分类 PDF 类型（文字版或扫描版），并提取文本和转换为 Markdown，避免不必要的 OCR，提高速度和节省成本。
MADP是一种用于企业文档处理的多智能体架构，结合了深度学习和大型语言模型，并采用人机回环验证，实现了97%的自动化率以及资源消耗的大幅降低。
该参考实现展示了如何利用 Rust、LiteParse 和 microsandbox，在本地沙盒中安全运行 LLM Agent，从而处理和分析各类文档。该开源 CLI 工具借助 OpenAI 的 GPT 模型与原生 bash 命令，在隔离环境中执行文件检索与分析任务。
Paper2Any 是一款开源 AI 工具，可将研究论文转换为可编辑的图表、技术路线图和幻灯片，支持通用文件格式和自定义样式。