文档处理已成为各个机构日常运营中不可或缺的一部分。从合同审核到客户身份验证，从财务报告分析到交易记录审查，文档智能技术的应用极大地提高了工作效率和准确性。然而，如何在保障数据安全的前提下，充分利用大语言模型（LLMs）的强大能力，一直是一大难题。本文介绍一个基于 Docling、Ollama、Phi-4 与 ExtractThinker 构建企业级文档智能处理的解决方案。
一、ExtractThinker 框架概述
ExtractThinker 是一个开源框架，旨在协调 OCR（光学字符识别）、分类和数据提取等流程，为 LLMs 提供强大的支持。它通过将不同的组件集成到一个统一的平台中，使得用户可以轻松地构建自定义的文档智能解决方案。ExtractThinker 的核心优势在于其高度的灵活性和可扩展性，用户可以根据自己的需求选择适合的组件和配置，以构建最适合自己的文档智能堆栈。
二、选择合适的模型：文本模型与视觉模型
在搭建文档智能处理栈的初始阶段，精准判定所需模型类型至关重要。对于本地部署方案而言，纯文本模型因其广泛的可用性和相对宽松的限制条件，常常成为首选。例如，在处理大量常规文本文件时，纯文本模型能够高效地进行文本分析与提取任务，无需复杂的视觉处理能力。
然而，在某些特定场景下，具备视觉处理能力的模型则不可或缺。当文档的理解和处理高度依赖于视觉线索，如页面布局、色彩模式或独特格式时，视觉模型便能发挥关键作用。在处理包含图表、复杂排版的财务报告或设计图纸等文档时，视觉模型能够识别并解析其中的关键信息，为后续的分析和提取奠定基础。
在实际应用中，根据不同任务阶段灵活搭配不同模型是一种高效的策略。一些大型机构会选择部署如 Llama 3.3 或 Qwen 2.5 等强大的单一模型，以应对各种复杂的用例，凭借其高参数和强大的学习能力，实现从文档分类到信息提取的全流程处理。而对于某些特定需求，如仅需处理英语为主的智能文档处理（IDP）任务，Phi-4 模型在多数情况下表现出色，同时可配备轻量级的 Moondream 模型作为备用，用于处理边缘情况的分割任务，确保在不同场景下都能实现高效、准确的文档处理。
三、文档处理：Docling 与 MarkItDown 的比较
在文档解析方面，Docling 和 MarkItDown 是两个备受推崇的库。MarkItDown 以其简单直观、广泛支持 Microsoft 的特点而著称，非常适合直接基于文本的任务，且不需要多个 OCR 引擎。而 Docling 则以其多 OCR 支持（包括 Tesseract、AWS Textract、Google Document AI 等）和适用于扫描工作流程或从图像 PDF 中进行稳健提取的能力而脱颖而出。Docling 还提供了详细的文档和灵活的复杂布局处理能力。ExtractThinker 允许用户根据自己的需求，在 DocumentLoaderMarkItDown 和 DocumentLoaderDocling 之间进行选择，以满足简单数字 PDF 或多引擎 OCR 的需求。
四、本地模型运行：Ollama 与其他解决方案
Ollama 作为本地托管 LLMs 的热门工具，以其便捷的设置和简单的命令行界面（CLI）深受用户喜爱。通过 Ollama，用户能够轻松地在本地部署语言模型，如 Phi-4 或 Llama 3.x 等，并快速搭建起本地的文档智能处理环境。
在企业级或高性能计算（HPC）场景下，其他解决方案也各有优势：
- LocalAI：这是一个开源平台，能够在本地模拟 OpenAI 的 API，这使得其在与现有基于 OpenAI 接口的应用程序集成时具有天然的优势。尤为突出的是，它可以在消费级硬件上运行 LLMs，甚至在仅配备 CPU 的设备上也能实现一定程度的模型运行，为资源有限的企业或个人提供了一种低成本的本地模型运行方案。
- OpenLLM：由 BentoML 开发，通过 OpenAI 兼容的 API 暴露 LLMs，在吞吐量和低延迟方面进行了深度优化。这种优化使其在本地部署和云端环境中都能表现出色，能够满足企业对高效文档处理的需求。
- Llama.cpp：采用了一种较低级别的方法来运行 Llama 模型，它允许用户进行高级的自定义配置，适用于对模型运行有精细控制需求的场景，如在 HPC 设置中，用户可以根据硬件资源和任务特点，对模型的运行参数进行深度调整，以实现最佳的性能表现。
在实际应用中，企业可根据自身的场景需求和技术能力，选择最合适的本地模型运行方案，并通过简单的配置，将其与 ExtractThinker 进行无缝集成。只需在代码中将本地 LLM 端点指向相应的环境变量或基础 URL，即可实现 ExtractThinker 与不同本地模型运行工具的协同工作，构建起强大的本地文档智能处理系统。
五、处理小上下文窗口的策略
在使用具有有限上下文窗口（如约 8K 令牌或更少）的本地模型时，有效的管理策略至关重要。其中，文档分割是避免超出模型输入容量的关键环节。
Lazy Splitting 策略：通过增量式比较页面的方式，实现了高效且内存友好的文档分割。与一次性摄入整个文档不同，它逐页或逐段地比较相邻页面，判断它们是否属于同一子文档。如果属于同一子文档，则将其合并为下一步处理的单元；如果不属于，则开启新的片段。这种方式在处理大型 PDF 文档时优势显著，每次仅需加载和分析少量页面，极大地降低了内存压力，确保模型能够稳定运行，即使面对数百页甚至上千页的大型文档，也能有条不紊地进行处理。
PaginationHandler 处理部分响应：由于本地小型模型在面对较大提示时可能会截断响应，PaginationHandler 提供了一种有效的解决方案。它将文档页面分割为单独的请求，每次仅向模型发送一页内容，避免了因输入过长导致的响应截断问题。在获取各个页面的结果后，PaginationHandler 会对页级结果进行合并，并在必要时处理不同页面之间在某些字段上的冲突，确保最终提取的信息完整、准确。
一个典型的工作流程示例如下：首先，使用 Lazy Split 技术将 PDF 文档分割为多个小块或页面，确保每个块都在模型的容量限制之内；然后，通过分页方式（Paginate）向模型发送请求，获取每个块的单独结果；最后，将这些部分页面结果合并为最终的结构化数据。这种简洁而高效的方法从输入和输出两个维度确保了不会超出本地模型的上下文窗口，保障了文档智能处理的准确性和稳定性。
六、ExtractThinker：构建文档智能处理的核心框架实践示例
安装 ExtractThinker
pip install extract-thinker
加载文档
from extract_thinker import DocumentLoaderMarkItDown, DocumentLoaderDocling
# DocumentLoaderDocling or DocumentLoaderMarkItDown
document_loader = DocumentLoaderDocling()
实体定义
from extract_thinker.models.contract import Contract
from pydantic import Field
class InvoiceContract(Contract):
invoice_number: str = Field(description="Unique invoice identifier")
invoice_date: str = Field(description="Date of the invoice")
total_amount: float = Field(description="Overall total amount")
class DriverLicense(Contract):
name: str = Field(description="Full name on the license")
age: int = Field(description="Age of the license holder")
license_number: str = Field(description="License number")
分类配置
from extract_thinker import Classification
TEST_CLASSIFICATIONS = [
Classification(
name="Invoice",
description="This is an invoice document",
contract=InvoiceContract
),
Classification(
name="Driver License",
description="This is a driver license document",
contract=DriverLicense
)
]
提取逻辑
import os
from dotenv import load_dotenv
from extract_thinker import (
Extractor,
Process,
Classification,
SplittingStrategy,
ImageSplitter,
TextSplitter
)
# Load environment variables (if you store LLM endpoints/API_BASE, etc. in .env)
load_dotenv()
# Example path to a multi-page document
MULTI_PAGE_DOC_PATH = "path/to/your/multi_page_doc.pdf"
def setup_local_process():
"""
Helper function to set up an ExtractThinker process
using local LLM endpoints (e.g., Ollama, LocalAI, OnPrem.LLM, etc.)
"""
# 1) Create an Extractor
extractor = Extractor()
# 2) Attach our chosen DocumentLoader (Docling or MarkItDown)
extractor.load_document_loader(document_loader)
# 3) Configure your local LLM
# For Ollama, you might do:
os.environ["API_BASE"] = "http://localhost:11434" # Replace with your local endpoint
extractor.load_llm("ollama/phi4") # or "ollama/llama3.3" or your local model
# 4) Attach extractor to each classification
TEST_CLASSIFICATIONS[0].extractor = extractor
TEST_CLASSIFICATIONS[1].extractor = extractor
# 5) Build the Process
process = Process()
process.load_document_loader(document_loader)
return process
def run_local_idp_workflow():
"""
Demonstrates loading, classifying, splitting, and extracting
a multi-page document with a local LLM.
"""
# Initialize the process
process = setup_local_process()
# (Optional) You can use ImageSplitter(model="ollama/moondream:v2") for the split
process.load_splitter(TextSplitter(model="ollama/phi4"))
# 1) Load the file
# 2) Split into sub-documents with EAGER strategy
# 3) Classify each sub-document with our TEST_CLASSIFICATIONS
# 4) Extract fields based on the matched contract (Invoice or DriverLicense)
result = (
process
.load_file(MULTI_PAGE_DOC_PATH)
.split(TEST_CLASSIFICATIONS, strategy=SplittingStrategy.LAZY)
.extract(completion_strategy=CompletionStrategy.PAGINATE)
)
# 'result' is a list of extracted objects (InvoiceContract or DriverLicense)
for item in result:
# Print or store each extracted data model
if isinstance(item, InvoiceContract):
print("[Extracted Invoice]")
print(f"Number: {item.invoice_number}")
print(f"Date: {item.invoice_date}")
print(f"Total: {item.total_amount}")
elif isinstance(item, DriverLicense):
print("[Extracted Driver License]")
print(f"Name: {item.name}, Age: {item.age}")
print(f"License #: {item.license_number}")
# For a quick test, just call run_local_idp_workflow()
if __name__ == "__main__":
run_local_idp_workflow()
七、性能优化与安全考量
在将上述方案投入生产环境前，还需考虑性能优化与安全合规问题。
量化与显存优化：对于本地部署，模型量化（Quantization）是提升推理速度的关键手段。使用 GGUF 格式的模型配合 Ollama，可以在保持较高精度的同时显著降低显存占用。建议根据硬件配置选择 4-bit 或 8-bit 量化版本，平衡速度与精度。
错误处理与重试机制：在网络波动或模型服务不稳定时，应增加重试逻辑。在 ExtractThinker 的调用链中，可以封装异步重试装饰器，确保关键步骤不因临时故障而中断。
数据隐私与合规：本方案的核心价值在于数据不出域。所有文档解析、OCR 识别及 LLM 推理均在本地完成，不经过第三方云服务。这对于金融、医疗等强监管行业尤为重要。建议在部署时配置防火墙规则，限制本地模型服务的访问来源，防止未授权调用。
八、总结
通过将 ExtractThinker 与本地 LLM（如 Ollama、LocalAI）以及灵活的文档加载器（Docling 或 MarkItDown）相结合，企业能够构建一个安全、高效的本地文档智能处理工作流。在监管要求严格、强调数据隐私和最小化外部调用的场景下，这一技术栈为企业提供了强大的文档处理能力，同时确保数据在内部安全存储和处理，有效解决了银行及金融机构等在利用 LLMs 技术时面临的隐私和合规性难题。