银行和金融服务机构的内部审计一直是个“文档密度极高、证据要求极严、时间窗口极紧”的场景。我见过不少团队想用 AI workflow 来改造内部审计流程结果第一版方案都卡在同一个地方以为把审计资料丢给大模型就能自动产出审计底稿。实际上AI workflow 真正值得做的是另一件事——把审计人员花在通读文件、抽取关键信息、初步筛查风险点、整理证据引用上的时间压下来同时保证每一步处理都可回溯、可复核、可导出。这篇文章我从内部审计的原始场景出发拆一个适合银行和金融服务机构的 AI workflow 落地方案。内容包括流程骨架怎么设计、单条任务怎么跑通、批量任务怎么工程化、输出质量怎么验证、常见问题怎么排查。适合内部审计、合规、风险管理团队也适合正在做 AI Agent 和 workflow 设计的产品、技术同学。先说结论想在银行内部落地 AI 审计工作流最关键的不是模型能力而是流程中是否设置了人的复核节点、证据是否可追溯、以及每一步的输出是否稳定可复现。1. 内部审计的真实痛点决定了 AI workflow 的边界1.1 审计不是在“看报表”而是在做证据链管理很多人对内部审计的理解是“查账”“看报表”但真在银行或金融公司做过审计就会知道相当大一部分工作量是处理非结构化文档。一笔贷款审批要查什么信贷政策文件、客户尽调材料、审批意见书、放款条件清单、贷后检查记录。一个采购事项要查什么招标公告、评标记录、合同文本、供应商资质、付款审批单。一个员工费用报销要查什么发票、行程单、审批流截图、制度依据。这些材料分散在 OA 系统、影像平台、邮件附件、共享目录里格式有 PDF、Word、扫描件、Excel、图片很多扫描件甚至没有文字层。审计人员的时间主要花在两件事上第一通读这些材料找到和审计问题相关的关键段落第二把关键段落摘出来标注来源形成底稿。前者是体力活后者是证据链工作。AI workflow 能解决的是前者的大部分和后者的一小部分。这里要先给 AI 的作用定边界它适合做“识别、抽取、归类、初筛、起草”不适合做“判断、决策、定责”。审计结论必须由人来做AI 的价值是让做结论之前的信息准备变快、变整齐。1.2 AI workflow 能做什么不能做什么结合银行内部审计的常见场景AI workflow 可以承担的任务大致有四类文档分类与检索把几百份文件按业务类型、审计事项、时间范围自动归类审计人员输入问题直接定位到相关文件和相关段落。关键信息抽取从合同、审批单、制度文件中抽取金额、日期、审批人、授权层级、条款生效条件等结构化字段。风险线索初筛在交易流水、报销明细、审批记录中按预设规则做异常识别比如拆分报销、授权交叉、频率异常、金额接近阈值等。底稿素材生成把抽取结果、风险线索和文件引用整理成初稿格式供审计人员修改和补充。不适合做的事也要明确写下来。不要用模型直接生成“违规结论”不要在缺少原文引用的情况下输出“疑似问题”不要用 AI 替代抽样逻辑。金融服务机构的内部审计最终要面对监管检查所有结论都必须能追溯到原始证据。一旦流程里少了这一步前面做得再快都没用。2. 先设计审计工作流的骨架再谈选型2.1 从审计底稿的流向反推流程我见过不少团队是先选模型再想流程结果流程被模型能力带着走最后变成“有什么模型就做什么功能”。更稳妥的做法是反过来先看一份审计底稿是怎么产出的它需要哪些输入、经过哪些加工、产出什么结构再决定哪些环节交给 AI。一份典型的内部审计底稿通常包含以下信息审计事项名称和对应的审计程序抽样范围和抽样方法检查发现的事实描述相关证据的文件名、页码、原文引用初步风险评估和审计人员意见顺着这个结构往前推AI workflow 需要完成的是把一堆原始文件变成“文件清单 关键字段表 风险线索表 带引用的证据包”。只要这四个输出物是结构化、可校验的审计人员就能在此基础上快速完成底稿撰写和结论判断。2.2 五段式主流程采集、解析、分析、复核、出稿在银行内部落地我建议把流程切成五段每一段都有明确的输入输出而不是一个“大模型一口吞”的黑盒采集从 OA、影像系统、共享目录收集文件记录文件来源、上传时间、归属项目。解析统一转成可处理的文本。PDF 和 Word 直接提取文字扫描件走 OCR表格文件转成结构化数据。分析对文本做分类、抽取、规则匹配和风险初筛。这一步可以拆成多个小任务每个任务一个模型调用或一个规则模块。复核把所有 AI 输出送到人工复核台。审计人员逐条确认有问题直接修正系统记录修改痕迹。出稿根据复核通过的数据生成底稿素材和审计报告初稿。这五段里最容易被忽略的是“解析”和“复核”。很多 AI 审计项目效果不好不是因为模型不够智能而是文件解析阶段丢字、乱码、表格错位导致后面所有抽取和判断都建立在错误输入上。复核阶段如果不做AI 的“自信输出”会直接变成审计风险。2.3 安全和合规约束要前置银行和金融服务机构的数据安全要求决定了这个 workflow 不能按普通互联网应用的思路来搭。原始审计资料通常涉及客户信息、员工信息、交易明细属于高敏数据。在设计流程时有几条约束建议提前定好数据访问要按角色授权内部审计人员看到的范围和模型服务能访问的范围要按最小权限原则划分。如果使用外部大模型 API先确认数据是否允许出域。不允许的话就要走私有化部署或者本地模型方案。所有模型调用记录、输入输出日志、人工修改记录都要保留方便事后审计。涉及敏感字段先做脱敏或掩码处理再进入分析流程。这些约束看着麻烦但它们是审计工作流能不能真正上线的前提。技术团队如果一开始不考虑后面每次安全评审都会返工。3. 单条审计任务如何跑通最小可运行流程3.1 环境准备与依赖确认不管最终是团队内部工具还是产品化系统我都建议先用“最小可运行版本”验证流程。先跑通一条任务再处理复杂度。环境上一套通用的本地验证环境可以这样准备# Python 版本建议 3.10 以上 # 常用依赖文件解析、数据处理、日志 pip install pypdf pdfplumber python-docx openpyxl pip install pandas如果涉及扫描件 OCR可以根据你的环境选择 OCR 引擎。实测时要注意扫描件质量直接影响 OCR 结果倾斜、反光、印章遮挡都会造成文字识别错误。建议先用清晰扫描件做基准测试再测试低质量样本否则很难判断是 OCR 的问题还是后续模型的问题。模型服务这块有两种选择外部大模型 API接入快效果稳定但要确认数据合规和网络条件。本地部署开源模型数据不出域但需要 GPU 资源模型效果和推理速度要看机器配置。原始材料没有给出明确的部署规格落地时需要根据实际模型版本确认。一般来说本地跑一个 7B 到 14B 量级的模型建议准备 16GB 以上的显存如果内存只有 16GB 且没有独立 GPU就要把任务拆得更细或者改用 API 方案。3.2 输入准备的四个规范AI 审计工作流最怕“脏输入”。同样的文件人工看没问题模型处理可能就乱了。在进入流程之前建议对输入做四个检查格式统一把 PDF、扫描件、Word、Excel 统一转成中间文本格式并保留原始文件路径。编码正确中文文档要注意编码问题转出来的文本如果出现乱码先检查解析库和原始文件的字体嵌入情况。路径无特殊字符文件名和目录不要带空格、中文括号、emoji 等特殊字符否则在批量脚本里很容易出问题。文件来源留痕每个文件都要有唯一 ID 和来源信息方便后续输出引用。我第一次搭这种流程时就在文件名上踩过坑。几十个 PDF 文件名里带着中文全角括号解析脚本跑了一半报错排查了半天才发现是路径问题。后来统一改成“项目编号_文件类型_序号.pdf”的命名规范问题一下就少了。3.3 模型和提示词的选择在内部审计场景模型选择有三个原则抽取类任务优先用低温度温度参数放在 0.1 左右尽量减少随机性。审计抽取最怕同一份文件跑两次结果不一样。长文档优先看上下文长度合同、制度文件动辄几十页如果模型的上下文窗口不够就要做切分切分粒度要能保证关键条款不被人为截断。复杂推理任务用更强模型简单抽取用轻量模型不要把每一类任务都压在一个模型上成本和稳定性都要考虑。提示词设计上建议每个任务写清楚三件事输入是什么、输出结构是什么、遇到不确定内容时怎么处理。比如抽取审批金额时要求输出 JSON 格式{ task_id: 2025-AUDIT-001, file_name: loan_approval_20250312.pdf, extracted_fields: [ { field_name: loan_amount, field_value: 5000000, source_page: 3, source_text: 同意发放贷款人民币伍佰万元整 } ], uncertainty: 无 }这里的关键不是让模型“自由发挥”而是让输出结构化每一字段都带上原文引用页码。这样复核人员能快速核验后续生成底稿也能直接引用。3.4 成功标准怎么定单条任务跑通不等于流程可用。我建议用 10 到 20 份已经结案的审计样本做测试每份样本包含原文、已有底稿、已知结论。测试时要逐个核对文档能否被正确解析乱码率是否超过 1%。关键字段抽取的准确率是否达到人工复核能接受的水平。每个风险线索是否都带上了原文引用有没有凭空生成的内容。同一份文件跑两次输出差异是否在可接受范围内。如果这些指标不达标先不要急着扩批量回到解析、切分、提示词这几个环节去调。很多问题在单条任务阶段解决成本最低。4. 关键参数和判断标准别只看速度4.1 与输出质量直接相关的参数在审计场景这些参数对结果影响最大temperature建议 0 到 0.3。审计抽取和风险初筛是低随机性任务温度太高会出现同样的输入输出不一致。上下文窗口和切分大小切分大小建议根据文档类型调整。合同类按章节切审批单按整页切避免在句子中间截断。max_tokens输出长度要足够容纳结构化结果。如果返回内容被截断优先增加输出长度而不是压缩提示词。检索相关度阈值如果用了知识库检索相关度阈值太低会混入无关内容太高会漏掉关键信息。建议先用测试集跑一遍看阈值在哪个区间错误最少。这些参数没有通用的万能值。不同银行、不同审计事项文档风格差异很大。关键是建立“参数变更-输出质量”的对照记录每次调整都留痕。4.2 与成本、资源和稳定性相关的参数除了质量还要关注成本。大模型 API 一般按 token 或 credits 计费处理一份几十页的合同输入 token 可能上万。批量跑几十个审计事项费用会迅速积累。判断成本是否可控不要只看单次价格要看这几个指标单份文件的平均 token 消耗。每万条记录的风险初筛耗时。失败重试的比例。重试次数多说明输入或参数有问题不是在解决业务问题。并发和批量参数同样要留神。不要一上来就开最大并发。API 服务有速率限制本地部署有显存和内存约束。比如本地跑模型批量推理时显存占用会随 batch size 上升超过上限直接 OOM。建议先用小 batch 验证稳定性再逐步加大。4.3 怎么定义“审计结论可用”速度不是首要指标一致性、可追溯性、可复核性才是。我认为一条 AI 输出达到“可用”状态至少要满足四条所有事实性陈述都有原始文件引用能定位到具体页码或段落。风险提示是“线索”而非“结论”不预设某个行为一定违规。同一份输入重复执行关键结果基本一致允许的波动范围要提前说清楚。人工复核时能看到模型输出的完整推理依据而不是只给一个结论。如果做不到这四条输出再快也不能进正式底稿。这一点在银行内部尤其不能妥协。5. 从单任务到批量审计事项工程化才是关键5.1 批量任务的输入清单和输出命名单条任务跑通之后要处理的就不是一份文件而是几十个项目、上百份文件。批量场景下第一个要解决的是输入清单管理。我建议维护一份 CSV 或表格作为批处理的任务清单至少包含这些字段任务编号审计项目名称文件路径文件类型处理优先级状态待处理、处理中、成功、失败输出文件也要有规范命名。不要用模型输出临时文件名而是按“任务编号_处理阶段_结果类型.json”来存。比如2025-AUDIT-001_extract_result.json。这样后续拼接底稿和追溯证据都方便。5.2 失败重试、日志和断点续跑批量任务一定会遇到失败。文件解析失败、模型超时、权限不足、输出格式不对都可能发生。关键不是避免失败而是失败后能快速定位、恢复、继续。日志要记录四个信息处理到哪个文件、用了哪个参数、模型返回了什么、失败原因是什么。日志级别至少要有 info 和 error 两种方便排查。断点续跑也值得提前设计。一个审计项目几千份文件跑到一半中断是常见事。如果脚本没有记录已处理文件清单重跑就要全部再来。建议每处理完一份文件就把它的 ID 写入“已完成”清单重启任务时先读清单跳过已完成项。5.3 并发控制与资源调度批量任务的并发不是越大越好。外部 API 有配额限制本地模型有显存瓶颈磁盘 IO 也可能成为瓶颈。稳妥的推进方式是分步放大先用 1 个并发跑 10 份文件看耗时和错误率。再按 2 倍、3 倍逐步增加观察失败率和响应时间。找到成功率开始下降的临界点回退一档作为日常并发上限。如果任务量大建议再配置一个简单队列控制同时执行的任务数。队列的好处是某个任务卡住时不会拖垮整个批处理还能单独重试。6. 常见问题和排查链路6.1 输出内容不完整或明显错误这类问题的排查顺序我建议先看输入再看解析最后看模型原始文件是否完整PDF 是否加密、缺页、扫描倾斜。解析出的文本是否准确有没有乱码、表格错位、文字丢失。切分是否合理关键信息是不是被截断在片段之间。提示词是否明确输出结构要求是否清晰。模型输出是否被长度限制截断。这里最容易犯的错是直接改提示词。实际上大量“模型效果差”的问题根源在文件解析和切分阶段。先确认输入文本是干净的再调模型才有意义。6.2 证据缺失和引用不准确这是审计场景最致命的错误。模型输出看起来很有道理但引用的页码和原文对不上或者引用了不存在的内容也就是常说的 AI 幻觉。处理办法有三个层面在提示词里强制要求“不确定时标注 uncertainty不要编造引用”。在代码层面做校验模型输出的 source_text必须能在原始文本中找到对应片段找不到就标记为“引用校验失败”。在人工复核界面把引用段落高亮出来让审计人员一眼看到原文。不要轻信模型的自信输出。抽取结果必须经过“原文匹配”校验这是审计 workflow 和普通 AI 工具的底线区别。6.3 环境层面的排查顺序如果任务卡住、进程被杀、显存溢出按这个顺序排查看系统资源显存、内存、磁盘空间、CPU 占用。看日志和退出码确认是模型部署问题还是数据处理问题。确认依赖版本Python 版本、库版本、模型版本是否匹配。检查权限输入文件是否可读输出目录是否可写。检查路径有没有特殊字符、超长路径、挂载盘未生效。很多“程序跑不起来”的问题其实是环境和路径问题。把环境排清楚再判断是不是业务逻辑的问题。7. 边界、落地节奏和后续优化7.1 哪些情况不要硬上 AI workflowAI 审计工作流不是每个场景都适合。下面几种情况我建议先缓一缓原始文件质量极差扫描件模糊、表格复杂、书写体多OCR 都很难保证准确。审计事项涉及高度主观判断比如对管理层诚信度的评估不适合用模型生成初筛结论。团队没有能力维护模型输出质量和复核流程上线后很容易失控。数据合规问题没有确认清楚外部 API 和数据出境风险没有结论。在这些情况下先把数据处理规范做起来比上模型更有价值。AI workflow 是建立在干净数据之上的。7.2 上线前必须完成的验证清单如果你准备把 AI 审计 workflow 推给团队使用建议至少完成这些验证用历史结案项目做回测AI 抽取结果和人工底稿结论比对。做一次全流程演练从文件采集到出稿所有环节在真实数据上跑通。确认复核环节的职责和记录机制AI 输出的修改历史是否完整保留。明确事故兜底方案模型输出错误导致底稿出问题时由谁负责判断和纠正。建立模型升级和提示词变更的版本管理避免调整后结果无法回溯。这些不是额外工作而是内部审计工具能合规使用的必要条件。7.3 后续迭代方向等基础流程稳定了可以从这几个方向迭代把风险初筛的规则库沉淀成可配置项让审计人员自己调整阈值不用每次改代码。把人工复核的修正记录作为反馈数据持续优化抽取精度。增加抽样辅助能力基于历史数据和风险特征给出建议抽样范围但最终抽样决策仍由审计人员确认。把底稿生成和现有审计管理系统打通减少复制粘贴。我个人更建议先把单任务跑稳再考虑批量和接口。AI 在内部审计里的真正价值不是替代审计人员而是把审计人员从重复阅读和摘录中解放出来让他们把精力留给判断和沟通。这个过程不需要一步到位但每一步都要可追溯、可复核、可验证。
AI工作流重塑银行内部审计：流程设计、落地实践与风险控制
银行和金融服务机构的内部审计一直是个“文档密度极高、证据要求极严、时间窗口极紧”的场景。我见过不少团队想用 AI workflow 来改造内部审计流程结果第一版方案都卡在同一个地方以为把审计资料丢给大模型就能自动产出审计底稿。实际上AI workflow 真正值得做的是另一件事——把审计人员花在通读文件、抽取关键信息、初步筛查风险点、整理证据引用上的时间压下来同时保证每一步处理都可回溯、可复核、可导出。这篇文章我从内部审计的原始场景出发拆一个适合银行和金融服务机构的 AI workflow 落地方案。内容包括流程骨架怎么设计、单条任务怎么跑通、批量任务怎么工程化、输出质量怎么验证、常见问题怎么排查。适合内部审计、合规、风险管理团队也适合正在做 AI Agent 和 workflow 设计的产品、技术同学。先说结论想在银行内部落地 AI 审计工作流最关键的不是模型能力而是流程中是否设置了人的复核节点、证据是否可追溯、以及每一步的输出是否稳定可复现。1. 内部审计的真实痛点决定了 AI workflow 的边界1.1 审计不是在“看报表”而是在做证据链管理很多人对内部审计的理解是“查账”“看报表”但真在银行或金融公司做过审计就会知道相当大一部分工作量是处理非结构化文档。一笔贷款审批要查什么信贷政策文件、客户尽调材料、审批意见书、放款条件清单、贷后检查记录。一个采购事项要查什么招标公告、评标记录、合同文本、供应商资质、付款审批单。一个员工费用报销要查什么发票、行程单、审批流截图、制度依据。这些材料分散在 OA 系统、影像平台、邮件附件、共享目录里格式有 PDF、Word、扫描件、Excel、图片很多扫描件甚至没有文字层。审计人员的时间主要花在两件事上第一通读这些材料找到和审计问题相关的关键段落第二把关键段落摘出来标注来源形成底稿。前者是体力活后者是证据链工作。AI workflow 能解决的是前者的大部分和后者的一小部分。这里要先给 AI 的作用定边界它适合做“识别、抽取、归类、初筛、起草”不适合做“判断、决策、定责”。审计结论必须由人来做AI 的价值是让做结论之前的信息准备变快、变整齐。1.2 AI workflow 能做什么不能做什么结合银行内部审计的常见场景AI workflow 可以承担的任务大致有四类文档分类与检索把几百份文件按业务类型、审计事项、时间范围自动归类审计人员输入问题直接定位到相关文件和相关段落。关键信息抽取从合同、审批单、制度文件中抽取金额、日期、审批人、授权层级、条款生效条件等结构化字段。风险线索初筛在交易流水、报销明细、审批记录中按预设规则做异常识别比如拆分报销、授权交叉、频率异常、金额接近阈值等。底稿素材生成把抽取结果、风险线索和文件引用整理成初稿格式供审计人员修改和补充。不适合做的事也要明确写下来。不要用模型直接生成“违规结论”不要在缺少原文引用的情况下输出“疑似问题”不要用 AI 替代抽样逻辑。金融服务机构的内部审计最终要面对监管检查所有结论都必须能追溯到原始证据。一旦流程里少了这一步前面做得再快都没用。2. 先设计审计工作流的骨架再谈选型2.1 从审计底稿的流向反推流程我见过不少团队是先选模型再想流程结果流程被模型能力带着走最后变成“有什么模型就做什么功能”。更稳妥的做法是反过来先看一份审计底稿是怎么产出的它需要哪些输入、经过哪些加工、产出什么结构再决定哪些环节交给 AI。一份典型的内部审计底稿通常包含以下信息审计事项名称和对应的审计程序抽样范围和抽样方法检查发现的事实描述相关证据的文件名、页码、原文引用初步风险评估和审计人员意见顺着这个结构往前推AI workflow 需要完成的是把一堆原始文件变成“文件清单 关键字段表 风险线索表 带引用的证据包”。只要这四个输出物是结构化、可校验的审计人员就能在此基础上快速完成底稿撰写和结论判断。2.2 五段式主流程采集、解析、分析、复核、出稿在银行内部落地我建议把流程切成五段每一段都有明确的输入输出而不是一个“大模型一口吞”的黑盒采集从 OA、影像系统、共享目录收集文件记录文件来源、上传时间、归属项目。解析统一转成可处理的文本。PDF 和 Word 直接提取文字扫描件走 OCR表格文件转成结构化数据。分析对文本做分类、抽取、规则匹配和风险初筛。这一步可以拆成多个小任务每个任务一个模型调用或一个规则模块。复核把所有 AI 输出送到人工复核台。审计人员逐条确认有问题直接修正系统记录修改痕迹。出稿根据复核通过的数据生成底稿素材和审计报告初稿。这五段里最容易被忽略的是“解析”和“复核”。很多 AI 审计项目效果不好不是因为模型不够智能而是文件解析阶段丢字、乱码、表格错位导致后面所有抽取和判断都建立在错误输入上。复核阶段如果不做AI 的“自信输出”会直接变成审计风险。2.3 安全和合规约束要前置银行和金融服务机构的数据安全要求决定了这个 workflow 不能按普通互联网应用的思路来搭。原始审计资料通常涉及客户信息、员工信息、交易明细属于高敏数据。在设计流程时有几条约束建议提前定好数据访问要按角色授权内部审计人员看到的范围和模型服务能访问的范围要按最小权限原则划分。如果使用外部大模型 API先确认数据是否允许出域。不允许的话就要走私有化部署或者本地模型方案。所有模型调用记录、输入输出日志、人工修改记录都要保留方便事后审计。涉及敏感字段先做脱敏或掩码处理再进入分析流程。这些约束看着麻烦但它们是审计工作流能不能真正上线的前提。技术团队如果一开始不考虑后面每次安全评审都会返工。3. 单条审计任务如何跑通最小可运行流程3.1 环境准备与依赖确认不管最终是团队内部工具还是产品化系统我都建议先用“最小可运行版本”验证流程。先跑通一条任务再处理复杂度。环境上一套通用的本地验证环境可以这样准备# Python 版本建议 3.10 以上 # 常用依赖文件解析、数据处理、日志 pip install pypdf pdfplumber python-docx openpyxl pip install pandas如果涉及扫描件 OCR可以根据你的环境选择 OCR 引擎。实测时要注意扫描件质量直接影响 OCR 结果倾斜、反光、印章遮挡都会造成文字识别错误。建议先用清晰扫描件做基准测试再测试低质量样本否则很难判断是 OCR 的问题还是后续模型的问题。模型服务这块有两种选择外部大模型 API接入快效果稳定但要确认数据合规和网络条件。本地部署开源模型数据不出域但需要 GPU 资源模型效果和推理速度要看机器配置。原始材料没有给出明确的部署规格落地时需要根据实际模型版本确认。一般来说本地跑一个 7B 到 14B 量级的模型建议准备 16GB 以上的显存如果内存只有 16GB 且没有独立 GPU就要把任务拆得更细或者改用 API 方案。3.2 输入准备的四个规范AI 审计工作流最怕“脏输入”。同样的文件人工看没问题模型处理可能就乱了。在进入流程之前建议对输入做四个检查格式统一把 PDF、扫描件、Word、Excel 统一转成中间文本格式并保留原始文件路径。编码正确中文文档要注意编码问题转出来的文本如果出现乱码先检查解析库和原始文件的字体嵌入情况。路径无特殊字符文件名和目录不要带空格、中文括号、emoji 等特殊字符否则在批量脚本里很容易出问题。文件来源留痕每个文件都要有唯一 ID 和来源信息方便后续输出引用。我第一次搭这种流程时就在文件名上踩过坑。几十个 PDF 文件名里带着中文全角括号解析脚本跑了一半报错排查了半天才发现是路径问题。后来统一改成“项目编号_文件类型_序号.pdf”的命名规范问题一下就少了。3.3 模型和提示词的选择在内部审计场景模型选择有三个原则抽取类任务优先用低温度温度参数放在 0.1 左右尽量减少随机性。审计抽取最怕同一份文件跑两次结果不一样。长文档优先看上下文长度合同、制度文件动辄几十页如果模型的上下文窗口不够就要做切分切分粒度要能保证关键条款不被人为截断。复杂推理任务用更强模型简单抽取用轻量模型不要把每一类任务都压在一个模型上成本和稳定性都要考虑。提示词设计上建议每个任务写清楚三件事输入是什么、输出结构是什么、遇到不确定内容时怎么处理。比如抽取审批金额时要求输出 JSON 格式{ task_id: 2025-AUDIT-001, file_name: loan_approval_20250312.pdf, extracted_fields: [ { field_name: loan_amount, field_value: 5000000, source_page: 3, source_text: 同意发放贷款人民币伍佰万元整 } ], uncertainty: 无 }这里的关键不是让模型“自由发挥”而是让输出结构化每一字段都带上原文引用页码。这样复核人员能快速核验后续生成底稿也能直接引用。3.4 成功标准怎么定单条任务跑通不等于流程可用。我建议用 10 到 20 份已经结案的审计样本做测试每份样本包含原文、已有底稿、已知结论。测试时要逐个核对文档能否被正确解析乱码率是否超过 1%。关键字段抽取的准确率是否达到人工复核能接受的水平。每个风险线索是否都带上了原文引用有没有凭空生成的内容。同一份文件跑两次输出差异是否在可接受范围内。如果这些指标不达标先不要急着扩批量回到解析、切分、提示词这几个环节去调。很多问题在单条任务阶段解决成本最低。4. 关键参数和判断标准别只看速度4.1 与输出质量直接相关的参数在审计场景这些参数对结果影响最大temperature建议 0 到 0.3。审计抽取和风险初筛是低随机性任务温度太高会出现同样的输入输出不一致。上下文窗口和切分大小切分大小建议根据文档类型调整。合同类按章节切审批单按整页切避免在句子中间截断。max_tokens输出长度要足够容纳结构化结果。如果返回内容被截断优先增加输出长度而不是压缩提示词。检索相关度阈值如果用了知识库检索相关度阈值太低会混入无关内容太高会漏掉关键信息。建议先用测试集跑一遍看阈值在哪个区间错误最少。这些参数没有通用的万能值。不同银行、不同审计事项文档风格差异很大。关键是建立“参数变更-输出质量”的对照记录每次调整都留痕。4.2 与成本、资源和稳定性相关的参数除了质量还要关注成本。大模型 API 一般按 token 或 credits 计费处理一份几十页的合同输入 token 可能上万。批量跑几十个审计事项费用会迅速积累。判断成本是否可控不要只看单次价格要看这几个指标单份文件的平均 token 消耗。每万条记录的风险初筛耗时。失败重试的比例。重试次数多说明输入或参数有问题不是在解决业务问题。并发和批量参数同样要留神。不要一上来就开最大并发。API 服务有速率限制本地部署有显存和内存约束。比如本地跑模型批量推理时显存占用会随 batch size 上升超过上限直接 OOM。建议先用小 batch 验证稳定性再逐步加大。4.3 怎么定义“审计结论可用”速度不是首要指标一致性、可追溯性、可复核性才是。我认为一条 AI 输出达到“可用”状态至少要满足四条所有事实性陈述都有原始文件引用能定位到具体页码或段落。风险提示是“线索”而非“结论”不预设某个行为一定违规。同一份输入重复执行关键结果基本一致允许的波动范围要提前说清楚。人工复核时能看到模型输出的完整推理依据而不是只给一个结论。如果做不到这四条输出再快也不能进正式底稿。这一点在银行内部尤其不能妥协。5. 从单任务到批量审计事项工程化才是关键5.1 批量任务的输入清单和输出命名单条任务跑通之后要处理的就不是一份文件而是几十个项目、上百份文件。批量场景下第一个要解决的是输入清单管理。我建议维护一份 CSV 或表格作为批处理的任务清单至少包含这些字段任务编号审计项目名称文件路径文件类型处理优先级状态待处理、处理中、成功、失败输出文件也要有规范命名。不要用模型输出临时文件名而是按“任务编号_处理阶段_结果类型.json”来存。比如2025-AUDIT-001_extract_result.json。这样后续拼接底稿和追溯证据都方便。5.2 失败重试、日志和断点续跑批量任务一定会遇到失败。文件解析失败、模型超时、权限不足、输出格式不对都可能发生。关键不是避免失败而是失败后能快速定位、恢复、继续。日志要记录四个信息处理到哪个文件、用了哪个参数、模型返回了什么、失败原因是什么。日志级别至少要有 info 和 error 两种方便排查。断点续跑也值得提前设计。一个审计项目几千份文件跑到一半中断是常见事。如果脚本没有记录已处理文件清单重跑就要全部再来。建议每处理完一份文件就把它的 ID 写入“已完成”清单重启任务时先读清单跳过已完成项。5.3 并发控制与资源调度批量任务的并发不是越大越好。外部 API 有配额限制本地模型有显存瓶颈磁盘 IO 也可能成为瓶颈。稳妥的推进方式是分步放大先用 1 个并发跑 10 份文件看耗时和错误率。再按 2 倍、3 倍逐步增加观察失败率和响应时间。找到成功率开始下降的临界点回退一档作为日常并发上限。如果任务量大建议再配置一个简单队列控制同时执行的任务数。队列的好处是某个任务卡住时不会拖垮整个批处理还能单独重试。6. 常见问题和排查链路6.1 输出内容不完整或明显错误这类问题的排查顺序我建议先看输入再看解析最后看模型原始文件是否完整PDF 是否加密、缺页、扫描倾斜。解析出的文本是否准确有没有乱码、表格错位、文字丢失。切分是否合理关键信息是不是被截断在片段之间。提示词是否明确输出结构要求是否清晰。模型输出是否被长度限制截断。这里最容易犯的错是直接改提示词。实际上大量“模型效果差”的问题根源在文件解析和切分阶段。先确认输入文本是干净的再调模型才有意义。6.2 证据缺失和引用不准确这是审计场景最致命的错误。模型输出看起来很有道理但引用的页码和原文对不上或者引用了不存在的内容也就是常说的 AI 幻觉。处理办法有三个层面在提示词里强制要求“不确定时标注 uncertainty不要编造引用”。在代码层面做校验模型输出的 source_text必须能在原始文本中找到对应片段找不到就标记为“引用校验失败”。在人工复核界面把引用段落高亮出来让审计人员一眼看到原文。不要轻信模型的自信输出。抽取结果必须经过“原文匹配”校验这是审计 workflow 和普通 AI 工具的底线区别。6.3 环境层面的排查顺序如果任务卡住、进程被杀、显存溢出按这个顺序排查看系统资源显存、内存、磁盘空间、CPU 占用。看日志和退出码确认是模型部署问题还是数据处理问题。确认依赖版本Python 版本、库版本、模型版本是否匹配。检查权限输入文件是否可读输出目录是否可写。检查路径有没有特殊字符、超长路径、挂载盘未生效。很多“程序跑不起来”的问题其实是环境和路径问题。把环境排清楚再判断是不是业务逻辑的问题。7. 边界、落地节奏和后续优化7.1 哪些情况不要硬上 AI workflowAI 审计工作流不是每个场景都适合。下面几种情况我建议先缓一缓原始文件质量极差扫描件模糊、表格复杂、书写体多OCR 都很难保证准确。审计事项涉及高度主观判断比如对管理层诚信度的评估不适合用模型生成初筛结论。团队没有能力维护模型输出质量和复核流程上线后很容易失控。数据合规问题没有确认清楚外部 API 和数据出境风险没有结论。在这些情况下先把数据处理规范做起来比上模型更有价值。AI workflow 是建立在干净数据之上的。7.2 上线前必须完成的验证清单如果你准备把 AI 审计 workflow 推给团队使用建议至少完成这些验证用历史结案项目做回测AI 抽取结果和人工底稿结论比对。做一次全流程演练从文件采集到出稿所有环节在真实数据上跑通。确认复核环节的职责和记录机制AI 输出的修改历史是否完整保留。明确事故兜底方案模型输出错误导致底稿出问题时由谁负责判断和纠正。建立模型升级和提示词变更的版本管理避免调整后结果无法回溯。这些不是额外工作而是内部审计工具能合规使用的必要条件。7.3 后续迭代方向等基础流程稳定了可以从这几个方向迭代把风险初筛的规则库沉淀成可配置项让审计人员自己调整阈值不用每次改代码。把人工复核的修正记录作为反馈数据持续优化抽取精度。增加抽样辅助能力基于历史数据和风险特征给出建议抽样范围但最终抽样决策仍由审计人员确认。把底稿生成和现有审计管理系统打通减少复制粘贴。我个人更建议先把单任务跑稳再考虑批量和接口。AI 在内部审计里的真正价值不是替代审计人员而是把审计人员从重复阅读和摘录中解放出来让他们把精力留给判断和沟通。这个过程不需要一步到位但每一步都要可追溯、可复核、可验证。