将 14GB 扫描件、会计账套与合同协议,转化为支持自然语言查询、自动溯源至原始页码、并能主动识别审计疑点的 AI 审计助手 —— 数据全程不出本机。
某煤矿项目积累了大量审计资料,形式以扫描件 PDF、合同图片和会计账套导出表为主。人工查阅效率低、跨文档难以关联核对、疑点发现高度依赖个人经验。
| 痛点 | 现状 | 影响 |
|---|---|---|
| 资料查阅效率低 | 14GB 扫描件需逐页人工查阅 | 核查周期长、易遗漏 |
| 跨文档难以关联 | 合同条款与实际账目分散于不同文件 | 难以开展勾稽与交叉验证 |
| 疑点依赖经验 | 异常金额、关联交易凭经验判断 | 线索发现不全面 |
| 溯源难 | 结论要回到原始页码逐一核对 | 底稿引用费时 |
| 保密硬约束 | 审计资料不能上公有云 | 市面 SaaS 工具不可用 |
资料分三类:会计账套(电子表,金额精确)、合同协议(扫描件/图片)、月度凭证(海量扫描件)。处理策略各不相同。
| # | 特征 / 缺口 | 处理 |
|---|---|---|
| 1 | 账套是电子表,金额精确,无需 OCR | 直接转 MD |
| 2 | 合同是扫描件,需 OCR 且要保页码溯源 | Vision OCR |
| 3 | 月度凭证 2.4 万页,质量差、信息密度低 | 按需调阅原件 |
| 4 | 财务表格行列结构,纯文字 OCR 会拍平 | 表格单独识别 |
| 5 | 资料含个人信息与敏感金额 | 全程本地 |
初始方案基于 NVIDIA + RAGFlow 技术栈设计。部署平台调整为 Apple Silicon(Mac)后,存在两项架构层面的兼容性约束,需在方案设计阶段予以规避。
| 组件 | 选型 | 用途 | Apple Silicon 适配说明 |
|---|---|---|---|
| OCR 解析 | Apple Vision(ocrmac) | 扫描件文字识别 | 原生神经引擎加速,中文识别精度高,不依赖容器 |
| 表格识别 | PaddleOCR(PP-Structure) | 财务表格结构还原 | 规避纯文字 OCR 对表格行列结构的破坏 |
| RAG 平台 | Dify(开源) | 知识库 / 检索 / 编排 / 协作 | 提供 arm64 原生镜像 |
| 本地 LLM | Ollama + Qwen3.6 | 问答推理,数据不出网 | 原生 Metal 加速 |
| Embedding | Ollama + bge-m3 | 中文语义向量化 | 多语言模型,中文语义表现优异 |
| 硬件 | Mac M4 Pro · 48GB 统一内存 | 全流程承载 | 统一内存架构,显存容量充裕 |
五层架构:用户层 → 应用层 → 检索层 → 模型层 → 数据层。算力密集型任务(OCR、大模型)以原生进程运行于容器之外,Dify 在容器内承担编排职责。
这是 Mac 方案的核心:扫描件先用原生 OCR 转成带页码的结构化文本,再导入 Dify。纯文字走 Vision(快、中文好),财务表格走 PaddleOCR(结构准)。
===== 第 N 页 ===== 标记,溯源到页# 来源文件：账户共管协议
===== 第 1 页 =====
甲方：乙方公司（被合作煤矿）
乙方：甲方公司（生产经营方）
...
===== 第 2 页 =====
持卡人：共管账户持卡人
开户行：某商业银行支行
账号：6222 **** **** ****
...5 份 .xls 账套为会计软件直接导出的电子表,金额本已精确,无需 OCR —— 由脚本直接转换为 Markdown 表格入库,效率高且不引入识别误差。
从审计员一句话提问,到带页码引用的答案,系统内部的 6 步流水。
向量召回靠余弦相似度抓语义,关键词召回靠 BM25 抓关键术语(角色代称、金额量级、脱敏卡号),两路融合互补。
两路召回融合分数公式(拖动权重看融合分如何变化,以一个候选分块为例):
6222 **** **** ****、金额 约 1380 万元 这种关键串容易漏;BM25 关键词召回正好补上。审计场景里金额量级和关键账户极重要,所以两路都要。
| 参数 | 设定 | 原因 |
|---|---|---|
| 分段标识 | \n===== | 对齐 OCR 页码标记,每页独立成块,溯源准 |
| 最大分段 | 512 tokens | balance 上下文完整与检索精度 |
| 分段重叠 | 128 tokens | 避免关键信息被切在分块边界丢失 |
| 索引方式 | 高质量(bge-m3) | 中文语义向量化效果好 |
| 检索方式 | 混合检索 | 向量 + 关键词,精确数字不漏 |
以"替乙方公司代偿了哪些债务,总共多少钱?"为例,走完一次完整问答。
审计员: "替乙方公司代偿了哪些债务,总共多少钱?"| 路 | 命中分块 |
|---|---|
| 向量 | 代偿款利息计算明细 · 其他应收款-代偿款科目 · 合作合同代偿条款 |
| 关键词 | 命中"代偿""乙方公司""乙方法定代表人""环保处罚款"等术语 |
替乙方公司代偿款共 136 笔,合计约 1400 万元(其他应收款-代偿款科目)。
重点代偿事项:
| 事项 | 金额 | 备注 |
|------|---------|------|
| 环保处罚款 | 百万元级 | 2019-04-04,单笔较大 ⚠️ |
| 代偿乙方法定代表人借款/欠款 | 百万元级 | 乙方法定代表人 |
| 代偿工资款 | 数十万级 | |
| 代偿税款 | 数十万级 | |
⚠️ 核查建议:代偿是否有合同依据、能否收回、利息计算是否合理、
代付罚款的合规性。
来源:【代偿款利息计算明细】【明细账 其他应收款-代偿款】
注:涉及具体业务建议调阅对应记账凭证原件核实。基于账套结构化数据的初步扫描,系统已辅助梳理出 5 大核心疑点(金额均已按量级脱敏,涉及具体业务需调阅记账凭证核实)。
库存现金科目借贷方累计均为 亿元级。现金科目出现如此巨额流水不正常,疑似大额现金收付或将银行业务挂账现金科目。
核查方向:调阅大额现金收付凭证,核实资金真实流向与单据完整性。
总账单月大额中出现以个人名义记账的科目:"个人账户A" 2022 年 1 月借方 约 1380 万元(与当月库存现金发生额相互印证);"甲方法定代表人个人卡" 2022 年 7 月借方 约 960 万元。与合同"销售回款走共管账户持卡人个人账户共管"相互印证。
核查方向:个人卡走公司大额资金的合规性、是否存在账外资金、税务风险。
其他应收款-代偿款共 136 笔,合计 约 1400 万元。含付环保处罚款百万元级、代偿乙方法定代表人借款多笔百万元级、工资款数十万级、税款数十万级。
核查方向:代偿是否有合同依据、能否收回、利息计算是否合理。
财务费用借方累计、应付利息贷方累计均为 亿元级。项目利息负担极重。
核查方向:借款来源(是否关联方)、利率水平、利息计提依据。
其他应付款贷方累计为 亿元级,借方为千万级。
核查方向:挂账明细、是否含关联方往来或体外资金。
| 科目 | 借方合计 | 贷方合计 |
|---|---|---|
| 库存现金 | 亿元级 | 亿元级 |
| 财务费用 | 亿元级 | 亿元级 |
| 应付利息 | 千万级 | 亿元级 |
| 其他应付款 | 千万级 | 亿元级 |
| 主营业务收入 | 亿元级 | 亿元级 |
| 其他应收款 | 千万级 | 千万级 |
| 主营业务成本 | 千万级 | 千万级 |
当前已搭建完成的系统现状。
| 知识库 | 内容 | 文档数 |
|---|---|---|
| 煤矿账套数据 | 总账、明细账(309 科目)、科目余额表、科目汇总表、代偿款利息明细、审计线索清单 | 6 |
| 煤矿合同协议 | 合作合同、账户共管协议、三方协议(三方协议关系人)、乙方公司全部合同、审计报告、工程结算单、账户证明 | 8 |
为什么审计场景坚持本地部署,而不是用现成的云端大模型 API。
| 维度 | 本地(本方案) | 云端 API |
|---|---|---|
| 数据保密 | 资料不出本机 | 需上传到第三方 |
| 合规性 | 满足审计资料保密要求 | 敏感账套上云有风险 |
| 持续成本 | 电费极低,模型免费 | 按 token 计费 |
| 响应速度 | 本地推理,无网络往返 | 受网络与限流影响 |
| 复杂推理 | Qwen3.6 可满足需求 | 能力更强,可脱敏后选用 |
RAGFlow 官方仅提供 x86 架构镜像,未发布 arm64 版本。在 Apple Silicon 上部署需自行编译或借助 x86 指令集模拟,维护成本与运行效率均不理想。故选用 Dify —— 其官方提供 arm64 原生镜像,可在 Mac 上原生运行,并内置团队账号体系、知识库管理与应用编排能力。
Docker Desktop for Mac 不支持将 Apple GPU(Metal)透传至容器,容器内 OCR 只能依赖 CPU 运算,性能显著下降。因此 OCR 采用 Apple Vision 框架以原生进程运行,直接调用神经引擎与 GPU 加速,并原生支持简体中文。Docker 仅承载 Dify 编排服务,CPU 运算即可满足。
Apple Vision 输出为纯文字流,会破坏表格的行列结构 —— 这对财务数据是致命缺陷(金额与科目错位)。因此含表格的 PDF 改由 PaddleOCR 的 PP-Structure 进行表格识别,还原 HTML / Markdown 表格结构,确保金额与科目准确对应。
这些扫描件 OCR 质量较低、信息密度稀薄,全量入库性价比不高,且会稀释整体检索质量。处理策略为:会计账套(电子表,数据精确)与合同协议(关键条款)构建为高质量知识库;涉及具体月份凭证时,按页码调阅原件 —— 将算力资源集中于核心数据。
能,但需复核。系统提示词强制每个关键信息标注来源(如【账户共管协议 第2页】【明细账 1001库存现金】),金额给原文精确数字不推测,找不到就明说不编造。审计员按引用回原始资料核对即可。同时系统会提醒:扫描件 OCR 可能有误差,关键金额建议核对原件。
是。对话模型 Qwen3.6 与向量模型 bge-m3 均通过本地 Ollama 运行于本机,Dify 同样以本地 Docker 部署,向量库与数据库亦在本机。整条链路不向任何外部服务发送资料。仅当主动选择接入云端 API(可选项)时才存在数据外发,该选项默认关闭。
给这台 Mac 设固定内网 IP(路由器绑 MAC 地址),团队成员浏览器访问 http://<MacIP> 即可。Dify「设置 → 成员」里添加团队账号,分配管理员/编辑/普通成员角色。本地模型也可设为监听 0.0.0.0 供局域网调用。
无需重建。更换对话模型(如 Qwen 升级版本)仅需在 Dify 模型设置中修改模型名称,知识库无需变动。但更换 Embedding 模型必须重建知识库索引 —— 因向量维度与语义空间发生变化,原有向量不再兼容。
系统交付时,结构化数据、脚本、配置全部归甲方,构成可长期演进、可复用的数字资产。
| 层 | 选型 | 说明 |
|---|---|---|
| OCR(文字) | Apple Vision(ocrmac) | macOS 原生框架,神经引擎加速,原生中文,不依赖容器 |
| OCR(表格) | PaddleOCR PP-Structure | 还原财务表格行列结构 |
| RAG 平台 | Dify(开源) | arm64 原生镜像 · 知识库 / 检索 / 编排 / 团队 |
| LLM | Qwen3.6 | 本地 Ollama · Metal 加速 · 数据不出网 |
| Embedding | bge-m3 | 智源开源,中文语义 SOTA |
| 向量库 | Weaviate | Dify 默认,Docker 内 |
| 关系库 / 缓存 | PostgreSQL / Redis | Dify 元数据与队列 |
| 模型运行时 | Ollama(原生) | 无需 GPU toolkit,安装后即享 Metal 加速 |
| 部署 | Docker Compose | 仅 Dify,CPU 即可 |
| 硬件 | Mac M4 Pro · 48GB · macOS 26.2 | 统一内存即显存 |
日常怎么用、怎么加新资料、怎么备份。
· 煤炭销售回款按什么比例分配?(答:吨煤收益 80% 向债权人分配)
· 替乙方公司代偿了哪些债务,总共多少钱?
· 账户共管协议指定的持卡人是谁?卡号开户行?
· 个人账户A 2022 年 1 月那笔约 1380 万元是什么业务?
· 库存现金科目为什么有亿元级流水?脚本/convert_ledgers.py 跑转换脚本/ocr_contracts.py 的 TARGETS 跑 OCRimport_to_dify.py 文件列表,重跑导入,等索引完成后抽检# Dify 数据(知识库 + 向量库 + 配置)
cd ~/业务/煤炭/知识库构建/dify/docker
tar -czf ~/dify备份-$(date +%Y%m%d).tar.gz volumes/
# 结构化输出(重做 OCR 很费时)
tar -czf ~/输出备份-$(date +%Y%m%d).tar.gz ~/业务/煤炭/知识库构建/结构化输出/