标签
# 用本地 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` 参数调大之后，内存占用和推理速度的权衡是怎样的？实际用下来值不值？ 这个项目目前是我自用的小工具，但如果能把幻觉问题压下去，我觉得可以做成一个更通用的本地文档处理框架。 欢迎拍砖、分享经验，或者告诉我哪里的思路完全走偏了。
作者使用本地Qwen 3.5-4B模型通过llama-server运行，将其Hermes代理升级为TencentDB Agent Memory，用于结构化JSON提取和多步骤工具调用，实现了一个基于游标检查点的弹性分层记忆流水线。
Numind发布了NuExtract3，这是一个基于Qwen3.5-4B的4B开放权重视觉语言模型，专为将文档图像转换为Markdown、OCR和结构化数据提取而设计。该模型采用Apache-2.0许可证，可自行托管，并提供量化版本以适应低显存环境。
NuExtract3 是一个 4B 参数规模的视觉-语言推理模型，用于文档理解，支持结构化提取和图像到 Markdown 的转换。