MindLynx开源模型探索站

不用联网：DeepSeek OCR 2 本地化提取财报关键数据

MindLynx

不用联网：DeepSeek OCR 2 本地化提取财报关键数据

离线合规：视觉因果流架构下的数据主权保障

在金融数据合规要求日益严格的背景下，将财报关键数据提取流程完全迁移至本地环境，成为消除数据泄露风险的关键路径。传统 OCR 服务往往依赖云端 API，这意味着敏感的资产负债表、利润表甚至未公开的审计底稿，必须以图像或 PDF 形式上传至第三方服务器。对于受 GDPR、《数据安全法》或内部“数据不出域”红线约束的企业而言，这种架构本身就是合规隐患。DeepSeek-OCR-2 作为一款基于视觉因果流的 OCR 视觉语言模型，提供了无需联网即可实现高精度文档结构化的技术选项，从根本上切断了数据外泄的物理通道。

视觉因果流：让模型“看懂”结构而非仅识别像素

DeepSeek-OCR-2 的核心架构被称为“视觉因果流”（Visual Causal Flow）。这一名称并非营销术语，而是指模型在处理视觉输入时，能够建立像素空间与语义结构之间的因果关联。

传统 OCR 往往将文档视为像素矩阵，通过模板匹配或滑动窗口识别字符。这种方式在面对复杂财报时极易失效：合并报表的层级缩进、附注中的交叉引用、甚至不同字体混排的表格，都会导致结构错乱。视觉因果流架构则不同，它让模型像人类阅读者一样，先理解文档的“骨架”（标题、章节、表格边界），再填充“血肉”（具体数值）。

这种架构特性使得 DeepSeek-OCR-2 支持动态分辨率，并在默认配置下生成 (0-6)×144 + 256 个视觉 token。这意味着模型能够根据文档复杂度自适应调整注意力分配，而非机械地切割图像。对于财报这种结构严谨但版式多变的文档，这种“因果理解”能力确保了提取结果的逻辑一致性，而不仅仅是字符的准确转录。

本地部署：数据主权的物理保障

合规的本质是控制。当数据始终停留在本地硬件上时，企业才真正掌握数据主权。DeepSeek-OCR-2 的轻量化设计使得这种控制变得经济可行。

该模型参数量为 3.4B，经过 Q4_K_M 量化后，权重文件仅约 2.0GB。这一体积意味着它可以在消费级硬件上流畅运行，无需昂贵的数据中心集群。根据显存预算权威表，在 4K 上下文长度下，模型总占用（权重 3.7 GB + 系统开销 1.5GB + KV Cache 2GB）仅为 3.7GB。这意味着，任何显存 ≥ 3.7GB 的显卡（如 4GB、8GB 甚至 6.8GB 显卡）均可承载该模型。

以 6.8GB 显卡为例，在 4K 上下文下，剩余显存高达 8.3GB，足以处理多页财报的并发请求。这种“小模型、大能力”的特性，使得企业可以在内部工作站、边缘服务器甚至高性能笔记本上部署 OCR 服务，彻底消除对第三方 API 的依赖。

# 使用 Ollama 本地部署 DeepSeek-OCR-2 (GGUF 格式)
# 前提：已安装 Ollama，且显卡显存 >= 4GB

# 1. 拉取模型 (Ollama 原生支持 GGUF 格式)
ollama pull deepseek-ai/DeepSeek-OCR-2:q4_k_m

# 2. 启动本地服务 (默认监听 11434 端口)
ollama serve

# 3. 测试调用 (使用 curl 模拟 API 请求)
# 注意：此处假设已将财报图片保存为 base64 或文件路径
curl http://localhost:11434/api/generate -d '{
  "model": "deepseek-ai/DeepSeek-OCR-2:q4_k_m",
  "prompt": "Extract key financial data from this report image",
  "images": ["file:///path/to/financial_report.png"],
  "stream": false
}'

上述代码展示了如何通过 Ollama 加载 GGUF 格式的 DeepSeek-OCR-2。Ollama 基于 llama.cpp 后端，原生支持 GGUF 格式，无需复杂的框架配置。ollama pull 命令会自动下载约 2.0GB 的量化模型，并在本地启动推理服务。整个过程无需联网（除首次下载外），后续所有推理均在本地 GPU/CPU 上完成。

替代云端 API：合规审计的落地路径

对于金融、法律等行业，本地部署不仅是技术选择，更是合规审计的刚性要求。DeepSeek-OCR-2 的本地化特性为企业提供了清晰的审计轨迹：

  1. 数据隔离：所有文档处理均在内部网络完成，防火墙无需开放任何出站端口用于 OCR 服务。
  2. 日志可控：推理日志、错误记录均存储在本地服务器，符合内部数据保留政策。
  3. 版本锁定：模型权重文件固定，避免云端 API 版本更新带来的行为不一致性。

读者可基于此评估其本地部署方案是否满足内部数据安全审计标准。例如，在 8GB 显卡上，4K 上下文下剩余显存为 4.3GB（8GB – 3.7GB），足以处理单页财报的高精度提取；若需处理多页长文档，可调整上下文至 8K，此时总占用为 4GB，8GB 显卡仍有 4GB 剩余，依然流畅。

这种“小模型、大合规”的特性，使得 DeepSeek-OCR-2 成为替代云端 OCR 服务的理想选择。它不仅在技术上实现了高精度文档结构化，更在合规层面提供了数据主权的物理保障。

下一章，我们将深入探讨如何在本地环境中优化 DeepSeek-OCR-2 的推理性能，包括 KV Cache 量化、并发处理策略以及针对财报特定结构的提示词工程，确保在资源受限的硬件上实现高效、稳定的数据提取。

动态分辨率：从 (0-6)×144 + 256 Token 看复杂版式解析能力

在处理财报时，最令传统 OCR 头疼的往往不是文字识别本身，而是版式的“不可预测性”。一页可能只有寥寥几行摘要，另一页却塞满了密密麻麻的资产负债表。如果模型使用固定的分辨率切片，要么在稀疏页面上浪费算力去解析空白，要么在密集表格上因分辨率不足而丢失关键细节。DeepSeek-OCR-2 的解法非常巧妙：它不预设固定的视觉块数量，而是引入了一种动态分辨率机制。

根据官方模型卡描述，该模型在默认配置下生成 (0-6)×144 + 256 个视觉 token。这个公式看似复杂，实则逻辑清晰。我们可以将其拆解为两部分来理解：

  1. 基础保底层（256 tokens）：无论页面内容多么简单，模型都会分配 256 个视觉 token。这相当于给每一页文档提供了一个“最低保障”，确保即使是大段空白或极简布局，模型也能捕捉到页面的整体结构、页眉页脚等全局信息。
  2. 动态扩展层（(0-6)×144 tokens）：这是应对复杂版式的关键。模型会根据页面的实际信息密度，动态决定额外分配多少个“144-token 块”。这里的 0-6 代表一个可变因子，意味着模型最多可以额外增加 6 个块，每个块包含 144 个 token。

让我们用一个类比来理解这种机制。想象你在阅读一份报纸：
* 基础层（256 tokens） 就像是你先快速浏览整版报纸的标题、图片和大标题，建立对版面布局的整体认知。
* 动态层（(0-6)×144 tokens） 则像是你发现某篇报道特别重要（比如包含关键财务数据），于是你拿起放大镜，对那个区域进行更细致的阅读。如果那页只有标题，你就不需要放大镜（0 个块）；如果那页全是小字表格，你可能需要多次放大查看（最多 6 个块）。

这种设计直接解决了财报解析中的两个核心痛点：

痛点一：小数点与负号的误读
在财务数据中，1,000.00 和 1000 或 -1000 有着天壤之别。固定分辨率的模型在处理密集表格时，往往因为像素密度不足，将小数点识别为噪点，或将负号 - 与数字 1 混淆。DeepSeek-OCR-2 的动态机制允许模型在检测到高信息密度区域（如利润表、现金流量表）时，自动增加视觉 token 的分配。更多的 token 意味着模型能“看到”更细粒度的像素特征，从而更准确地区分 .、- 和 0。

痛点二：算力与精度的平衡
如果对所有页面都使用最高分辨率（即始终分配 6 个额外块），推理成本将大幅上升，且对于简单页面是纯粹的浪费。动态机制让模型“按需分配”。对于只有几行文字的封面页，模型可能只使用基础层或极少扩展块；而对于包含数百行数据的合并报表页，模型则会充分利用 (0-6)×144 的扩展空间，确保每一行数据都被充分解析。

为了更直观地理解这种 token 分配逻辑，我们可以参考以下伪代码，展示模型如何根据页面复杂度动态调整视觉输入：

# 伪代码：模拟 DeepSeek-OCR-2 的动态视觉 Token 分配逻辑
# 注意：此为概念演示，非实际模型内部实现

def calculate_visual_tokens(page_complexity_score):
    """
    根据页面复杂度评分（0-1.0）计算视觉 token 数量
    page_complexity_score: 基于文本密度、表格占比等特征计算的分数
    """
    base_tokens = 256  # 基础保底层

    # 动态扩展层：0-6 个块，每块 144 tokens
    # 假设复杂度分数线性映射到块数
    # 0.0 -> 0 blocks, 1.0 -> 6 blocks
    max_blocks = 6
    block_size = 144

    # 将复杂度分数映射到 0-6 的整数块数
    # 例如：score < 0.16 -> 0, 0.16 <= score < 0.33 -> 1, ...
    num_blocks = int(page_complexity_score * max_blocks)

    # 确保块数在 0-6 范围内
    num_blocks = max(0, min(num_blocks, max_blocks))

    total_tokens = base_tokens + (num_blocks * block_size)

    return total_tokens, num_blocks

# 示例场景
# 场景1：稀疏封面页
cover_score = 0.1
tokens_cover, blocks_cover = calculate_visual_tokens(cover_score)
print(f"封面页: 总 Tokens={tokens_cover}, 扩展块数={blocks_cover}")
# 输出: 封面页: 总 Tokens=256, 扩展块数=0

# 场景2：中等密度文本页
text_page_score = 0.5
tokens_text, blocks_text = calculate_visual_tokens(text_page_score)
print(f"文本页: 总 Tokens={tokens_text}, 扩展块数={blocks_text}")
# 输出: 文本页: 总 Tokens=976, 扩展块数=3 (256 + 3*144)

# 场景3：密集财务报表页
table_page_score = 0.95
tokens_table, blocks_table = calculate_visual_tokens(table_page_score)
print(f"报表页: 总 Tokens={tokens_table}, 扩展块数={blocks_table}")
# 输出: 报表页: 总 Tokens=1120, 扩展块数=5 (256 + 5*144)
# 注：若 score=1.0，则 blocks=6, tokens=256+6*144=1120

注：上述代码仅为逻辑演示，实际模型内部的复杂度评估可能涉及更复杂的视觉特征提取，但核心思想一致：根据输入内容的信息密度动态调整视觉编码器的输出长度。

这种动态机制对读者的实际价值在于：它消除了“一刀切”的调参焦虑。你不需要为不同类型的财报页面手动调整 OCR 参数或分辨率。DeepSeek-OCR-2 会自动“感知”页面的复杂度，并在精度和效率之间找到最佳平衡点。对于包含大量小数点、负号和复杂表格的财报，这种机制确保了关键财务数据不会被截断或误读，从而为后续的自动化数据提取提供了可靠的基础。

理解了动态分辨率如何保障解析精度后，接下来的挑战是如何让这种高精度解析在本地硬件上高效运行。毕竟，更多的视觉 token 意味着更大的计算量和显存占用。下一章，我们将深入探讨如何在本地环境中优化 DeepSeek-OCR-2 的推理性能，包括 KV Cache 量化、并发处理策略以及针对财报特定结构的提示词工程，确保在资源受限的硬件上实现高效、稳定的数据提取。

结构化落地：从像素到 Markdown 的文档转换链路

在上一节中，我们解决了“看得清”的问题，即通过动态分辨率确保财报中的微小数字和复杂图表被准确解析。但识别出字符只是第一步，真正的痛点在于如何组织这些字符。传统的 OCR 往往输出一堆无序的纯文本流，就像把一本书撕碎后撒在地板上，虽然字都在，但阅读者需要花费巨大精力去拼凑段落、还原表格。

DeepSeek-OCR-2（3.4B）的核心突破在于它不仅仅是一个字符识别器，更是一个文档结构理解器。基于 arXiv 2601.20552 论文描述，该模型支持将文档直接转换为 Markdown 格式。这种结构化输出保留了标题层级（#, ##）、列表（-, *）以及最关键的表格结构（|）。对于财务数据提取而言，这意味着模型输出的不再是“营收 100 净利润 20”这样的线性文本，而是带有明确行列关系的 Markdown 表格。

这种转换的价值在于标准化中间表示。Markdown 是一种轻量级、人类可读且机器可解析的格式。它充当了“像素”与“结构化数据库”之间的桥梁。对于开发者而言，这意味着后续的数据清洗成本大幅降低：你不再需要编写复杂的正则表达式去猜测哪些数字属于“营业收入”，哪些属于“净利润”，因为 Markdown 表格的列头已经明确标注了这些字段。

从视觉 Token 到结构化文本的映射

DeepSeek-OCR-2 作为 OCR 视觉语言模型，其内部机制是将视觉 Token 映射为文本 Token。在默认配置下，模型生成 (0-6)×144 + 256 个视觉 token，这些 token 不仅承载了字符信息，还隐含了布局信息。当模型被提示输出 Markdown 时，它会利用这种布局感知能力，自动判断哪些文本块属于标题，哪些属于表格单元格。

为了在本地环境中实现这一转换，我们需要确保推理框架能够正确接收图像输入并输出文本。由于我们使用的是 Q4_K_M 量化版本（约 2.0GB），我们可以轻松地在 8GB 以上显卡上运行。这里以 Ollama 为例，因为它原生支持 GGUF 格式，且提供了简单的 API 接口，非常适合本地快速验证。

# 假设已通过 ollama pull deepseek-ai/DeepSeek-OCR-2 拉取模型
# 使用 Python 的 ollama 库进行调用
import ollama
import base64

def extract_financial_markdown(image_path: str) -> str:
    """
    将财报图片转换为 Markdown 格式
    """
    # 1. 读取图片并编码为 Base64
    with open(image_path, "rb") as f:
        image_data = base64.b64encode(f.read).decode("utf-8")

    # 2. 构建提示词，明确要求输出 Markdown
    # 注意：提示词中强调“保留表格结构”和“标题层级”
    prompt = """
    请分析这张财报截图。
    要求：
    1. 将内容转换为 Markdown 格式。
    2. 保留原有的标题层级（使用 #, ## 等）。
    3. 将表格数据转换为 Markdown 表格格式（使用 | 分隔列）。
    4. 不要添加任何解释性文字，只输出 Markdown 内容。
    """

    # 3. 调用模型
    response = ollama.chat(
        model="deepseek-ai/DeepSeek-OCR-2",
        messages=[
            {
                "role": "user",
                "content": prompt,
                "images": [image_data]
            }
        ]
    )

    return response['message']['content']

# 示例调用
# markdown_content = extract_financial_markdown("quarterly_report_page1.png")
# print(markdown_content)

为什么 Markdown 是财务提取的最佳中间层？

让我们通过一个具体场景来理解这种结构化带来的红利。假设财报中有一张“主要会计数据”表格，包含“营业收入”、“净利润”、“总资产”三行，以及“本期”、“上期”两列。

如果输出是纯文本，解析代码可能需要这样写：
python

脆弱的纯文本解析

text = “营业收入 1000 800 净利润 200 150 总资产 5000 4500”

需要复杂的正则或硬编码索引来提取，极易出错

但如果输出是 Markdown，解析代码可以变得极其健壮：
python
import re

def parse_markdown_table(md_text: str) -> dict:
“””
从 Markdown 文本中提取表格数据
“””
# 简单的 Markdown 表格解析逻辑
lines = md_text.split(‘\n’)
table_data = {}
in_table = False
headers = []

for line in lines:
if line.strip.startswith(‘|’) and line.strip.endswith(‘|’):
if not in_table:
# 第一行通常是表头
headers = [h.strip for h in line.strip(‘|’).split(‘|’)]
in_table = True
elif set(line.strip(‘|’).split(‘|’)) == {‘—‘, ‘:—‘, ‘—:’}:
# 分隔行，跳过
continue
else:
# 数据行
values = [v.strip for v in line.strip(‘|’).split(‘|’)]
if len(values) == len(headers):
for h, v in zip(headers, values):
# 将键值对存入字典
# 注意：这里简化处理，实际需处理多行表格
table_data[h] = v
else:
if in_table:
in_table = False
break

return table_data

示例：假设 markdown_content 包含如下表格

| 项目 | 本期 | 上期 |

|—|—|—|

| 营业收入 | 1000 | 800 |

| 净利润 | 200 | 150 |

data = parse_markdown_table(markdown_content)

print(data.get(‘营业收入’)) # 输出: 1000

这种从“像素”到“Markdown”再到“结构化数据”的链路，使得 DeepSeek-OCR-2 不仅仅是一个识别工具，更是一个数据预处理引擎。它自动完成了最耗时的“结构化”工作，让开发者可以将精力集中在业务逻辑（如同比计算、异常检测）上，而不是底层的数据清洗。

本地部署中的结构化输出稳定性

在本地运行 3.4B 的 DeepSeek-OCR-2 时，显存占用是可控的。根据显存预算权威表，Q4_K_M 权重约 2.0GB，加上系统开销 1.5GB 和 4K 上下文的 KV Cache 0.2 GB，总占用约 3.7GB。这意味着即使是在 8GB 显存的显卡上，也有充足的剩余空间（约 4.3GB，具体取决于显卡总容量，此处以 8GB 为例，剩余空间充足）来处理并发请求或更大的上下文。

需要注意的是，Markdown 输出的稳定性依赖于提示词工程。在本地环境中，建议将“转换为 Markdown”作为系统提示的一部分，或者在每次调用时明确指定。由于模型是视觉语言模型，它对布局的感知能力较强，但在处理极度复杂的跨页表格时，可能需要分块处理。然而，对于大多数标准的财报页面（如资产负债表、利润表），单页转换的准确率已经足以支撑自动化流水线。

通过这种结构化落地，我们不仅获得了可读性强的文本，更获得了一个机器友好的数据接口。这为下一章探讨如何在资源受限的硬件上进一步优化推理性能，以及如何处理更复杂的财务结构（如合并报表的层级关系），奠定了坚实的数据基础。当数据已经以 Markdown 形式整齐排列时，优化的重点将从“识别准确性”转向“处理效率”和“并发能力”。

Free OCR 模式：无提示词依赖的自动化提取工作流

在前面的章节中，我们解决了“如何准确识别”和“如何结构化输出”的问题。当数据已经以 Markdown 形式整齐排列时，优化的重点将从“识别准确性”转向“处理效率”和“并发能力”。然而，在实际的财报批量处理场景中，还有一个常被忽视的痛点：提示词（Prompt）工程。

传统的大模型 OCR 流程往往依赖于精心设计的提示词。例如，你需要明确告诉模型：“请提取资产负债表中的‘货币资金’和‘应收账款’，并以 JSON 格式输出。”一旦财报模板发生微调，或者你需要处理不同公司、不同年份的报表，你就必须重新调试提示词，甚至为每一类报表编写特定的指令模板。这种“提示词依赖”不仅增加了开发成本，还使得自动化流水线变得脆弱——任何一个提示词的微小偏差都可能导致提取失败。

DeepSeek-OCR-2（3.4B）引入的 Free OCR 模式，正是为了解决这一痛点。

什么是 Free OCR 模式？

Free OCR 模式的核心思想是“自主解析”。在这种模式下，模型不再依赖用户提供的特定指令（如“提取XX字段”），而是基于其内置的视觉因果流（Visual Causal Flow）能力，自主决定如何解析页面内容。

简单来说，你只需要把财报页面（PDF 或图片）扔给模型，它就能像一位经验丰富的财务分析师一样，自动识别出哪些是标题、哪些是表格、哪些是正文，并直接输出结构化的 Markdown 结果。你不需要告诉它“我要什么”，它自己知道“这里有什么”。

这种能力源于 DeepSeek-OCR-2 对文档布局的深度理解。它不仅能识别文字，还能理解文字之间的逻辑关系（如表头与数据行的对应关系、段落与章节的层级关系）。因此，即使面对格式各异的财报，Free OCR 模式也能保持稳定的输出结构。

为什么这对本地化部署至关重要？

在本地化部署场景中，Free OCR 模式的价值尤为突出，主要体现在以下三个方面：

  1. 降低部署门槛：你不再需要为每一类财报模板编写复杂的提示词。只需配置好模型，即可直接处理任意格式的财报 PDF/图片。
  2. 提升批量处理效率：在自动化流水线中，提示词调优往往是一个瓶颈。Free OCR 模式消除了这一环节，使得批量处理脚本更加简洁、稳定。
  3. 增强鲁棒性：由于不依赖特定提示词，模型对格式变化的容忍度更高。即使财报的排版略有调整，Free OCR 模式仍能准确提取关键数据，减少了人工干预的需求。

实战：配置批量处理脚本

下面，我们展示一个基于 Free OCR 模式的批量处理脚本示例。该脚本使用 Ollama 加载 DeepSeek-OCR-2（3.4B，Q4_K_M 量化约 2.0GB），并自动处理目录中的所有 PDF 文件，输出 Markdown 结果。

python
import os
import subprocess
import glob

# 配置参数
MODEL_NAME = "deepseek-ocr-2"  # Ollama 中的模型名称
INPUT_DIR = "./financial_reports"  # 输入目录
OUTPUT_DIR = "./extracted_markdown"  # 输出目录

# 确保输出目录存在
os.makedirs(OUTPUT_DIR, exist_ok=True)

# 获取所有 PDF 文件
pdf_files = glob.glob(os.path.join(INPUT_DIR, "*.pdf"))

for pdf_path in pdf_files:
    filename = os.path.basename(pdf_path)
    output_path = os.path.join(OUTPUT_DIR, f"{os.path.splitext(filename)[0]}.md")

    print(f"Processing: {filename}")

    # 使用 Ollama 的 API 进行 Free OCR
    # 注意：这里不传递任何特定的提示词，仅传递文件路径
    # Ollama 的 /api/generate 接口支持直接处理图像/PDF（需先转换为图像或使用支持 PDF 的客户端）
    # 此处假设使用 ollama run 命令，并通过 --prompt 留空或默认值触发 Free OCR

    # 示例：使用 ollama run 命令（需确保 Ollama 已安装并加载模型）
    # 实际生产中，建议使用 Python 的 ollama 库进行更精细的控制
    cmd = [
        "ollama", "run", MODEL_NAME,
        f"Extract content from {pdf_path}"  # 这里可以省略具体指令，依赖 Free OCR 模式
    ]

    # 注意：Ollama 的 CLI 可能不直接支持 PDF，需先转换为图像
    # 这里使用 pdf2image 将 PDF 转换为图像，再传给 Ollama
    from pdf2image import convert_from_path
    images = convert_from_path(pdf_path)

    for i, image in enumerate(images):
        image_path = f"/tmp/{filename}_page_{i}.png"
        image.save(image_path)

        # 调用 Ollama API（Free OCR 模式）
        # 这里使用 curl 示例，实际中建议使用 Python 库
        # curl -X POST http://localhost:11434/api/generate -d '{"model":"deepseek-ocr-2","prompt":"", "images":["data:image/png;base64,..."]}'

        # 简化示例：假设 Ollama 支持直接处理图像文件
        # 实际中，需将图像编码为 base64 并发送给 API
        pass  # 此处省略具体 API 调用细节，重点在于“无提示词”的概念

    print(f"Saved to: {output_path}")

注意：上述脚本是一个概念性示例。在实际生产中，建议使用 Ollama 的 Python 库（ollama）或 llama.cpp 的 API，并正确处理 PDF 到图像的转换。关键在于：不传递特定的提取指令，让模型自主决定输出内容。

性能与资源占用

Free OCR 模式并不会显著增加模型的推理开销。由于 DeepSeek-OCR-2 的 Q4_K_M 量化权重仅约 2.0GB，加上系统开销（1.5GB）和 KV Cache（4K 上下文下约 0.2 GB），总占用约为 3.7GB。这意味着，在 8GB 以上显存的显卡上，Free OCR 模式可以流畅运行，且无需额外的提示词处理开销。

例如，在 6.8GB 显卡上，4K 上下文下的剩余空间为 4.3 GB，足以支持高并发的批量处理任务。Free OCR 模式的“自主解析”特性，使得模型在处理复杂财报时，能够更高效地利用计算资源，避免在提示词解析上浪费算力。

总结与展望

Free OCR 模式是 DeepSeek-OCR-2 的一大亮点，它通过消除提示词依赖，简化了部署流程，提升了批量处理效率。对于需要处理大量财报数据的用户来说，这意味着更低的开发成本和更高的自动化水平。

DeepSeek-OCR-2 通过动态分辨率、Markdown 结构化输出及 Free OCR 模式，为本地化财报数据提取提供了完整的技术闭环，使敏感数据的处理在保障安全合规的同时，实现了自动化与结构化的平衡。

皖ICP备2025105865号-2|皖公网安备34010402704739号