简介这是一份由南京审计大学工程审计学院团队编写的DeepSeek大模型行业应用指南面向工程审计业务人员、高校师生及AI技术爱好者定位为工程审计智能化转型的参考手册。指南从工程审计面临的数据爆炸、场景复杂、标准多元等挑战出发系统阐述DeepSeek在审计场景中的核心价值与基本原理详细梳理智能问答、文本生成、数据分析等主要功能同时针对在线使用与本地部署分别给出可操作流程涵盖官网注册、Ollama安装、deepseek-r1:8b模型下载、AnythingLLM配置等关键步骤。第4章聚焦工程审计提示词工程展示如何通过设计提示词完成审计知识扩展与具体任务落地。资源为单份PDF文档压缩包大小3.67MB下载后可直接查阅完整目录与正文。目前已有98人学习适合希望系统掌握大模型赋能工程审计路径的中高级读者。1. 工程审计的文档型痛点DeepSeek 拿来解决什么工程结算审核的晚上你大概率翻过这样的合同结算清单和竣工图对不上签证事由在合同里找不到依据翻几十页纸只为了确认下浮率按哪一条执行。传统审计工具能汇总 Excel、能算清差价却很难把合同、签证这类自然语言文本变成可对照、可检索、可追溯的结构化结论。DeepSeek 这类大模型正好补上这一块把工程审计里最耗时的文本阅读与比对变成结构化提取和辅助判断。本文不套玄学只讲工程审计场景里 DeepSeek 的落地路径先选型走 API、内网私有化还是本地部署再拆任务针对合同抽取、条款比对、指标分析、底稿生成分别设计提示词然后用 RAG 把定额库和制度文件接进来最后讲让输出可信的 5 个坑。适合正在做结算审核、造价审计的工程师也适合想在审计信息化里真正接入大模型的建设者。2. 落地前先选型API、内网私有化还是本地部署数据边界决定一切2.1 为什么工程审计团队会把 DeepSeek 排在第一梯队工程审计的原始材料几乎全是中文长文本合同条款、签证单、变更说明、结算书、会议纪要。这些文本和通用文档不一样里面全是结算方式、暂估价、下浮率、索赔时效这类专业概念而且条款之间经常互相引用段落逻辑嵌套很深。DeepSeek 在中文长文本理解和抽取上的表现在开源大模型梯队里属于第一档这正好卡在工程审计的核心需求上。第二个理由是部署生态。DeepSeek 开放权重意味着可以脱离外部 API 独立运行这在工程审计行业很关键。标底、控制价、结算审核底稿这些数据很多单位连发邮件都要走审批更不用说把合同文本传给外部大模型服务。开源权重加 OpenAI 兼容接口让团队既能内网部署又不改变调用方式迁移成本很低。第三个理由是性价比。API 按 token 计费在同类大模型里属于对长文本很友好的档位后期如果要内网部署vLLM、Ollama 这些推理框架都能直接加载它的权重。对审计团队来说不需要一开始就买卡先用 API 验证效果再决定是否内网部署是风险最低的路径。选型阶段最忌讳的不是选错模型而是没想清楚数据边界就先把数据送出去了。2.2 先回答一个问题审计底稿能不能出域工程审计数据不只是「合同金额」这么简单。一份结算审核材料里往往包含标底、控制价、结算送审价、审减额、内部复核意见甚至还有甲方和咨询单位之间的往来沟通记录。这些材料一旦出了企业信息边界即使只是临时调用外部 API也存在泄露风险。所以选型顺序不应该是「哪个模型效果好用哪个」而应该是「数据能到哪模型就用到哪」。数据完全不能出域内网私有化部署是唯一答案模型权重、向量库、调用日志全部放在企业内网。只是跑流程验证、用的是公开合同样本或虚构测试数据可以直接走 API但也要做脱敏约定。暂时没有 GPU 资源又不想走 API用本地量化小模型做功能演示可以但演示结果不能当审计结论用。我一般会建议团队先画一张数据流转图原始 PDF 从哪来、文本抽到哪、谁调用了模型、结果落到哪、日志谁在看。把这条链画清楚选型就完成了一大半。表 2-1 三种落地形态对比形态数据边界起步成本输出质量适合阶段API 直连数据出境需脱敏低高流程验证、公开材料分析企业大模型私有化部署数据不出域中高GPU 服务器高正式审计数据、常态化使用本地量化小模型数据不出域低中演示、个人学习、离线验证2.3 内网部署的起步命令vLLM 加载 DeepSeek 权重如果确认要内网部署常见做法是 vLLM 起一个 OpenAI 兼容服务。下面这条命令把 DeepSeek 权重加载进显存对外提供一个标准 HTTP 接口# /data/models/deepseek-v3 是存放 DeepSeek 权重文件的目录 # tensor-parallel-size 按 GPU 数量和显存设置4 表示 4 卡张量并行 vllm serve /data/models/deepseek-v3 \ --dtype bfloat16 \ --tensor-parallel-size 4 \ --max-model-len 65536 \ --served-model-name ds-audit \ --port 8000命令里的max-model-len控制模型能接收的最大 token 数。工程审计常见做法是设到 64K 以内因为单次抽取任务通常只需要几千到一万 token开得过大显存占用和首字延迟都会明显上升。served-model-name是自己给服务起的名字后面 API 调用时要用这个名字指定模型。服务起来之后用 curl 验证一次最简调用curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model:ds-audit,messages:[{role:user,content:把这句话里的合同编号提取出来}],temperature:0}能返回正常 JSON 就说明部署通了。本地部署 DeepSeek 的形式不只 vLLM 一种Ollama 也可以但审计场景要批量处理 PDF 抽取和并发调用vLLM 的吞吐和兼容性更稳。2.4 还没上 GPU 时先用 API 把流程跑通如果团队的目标是先看清大模型能不能解决审计问题不用一上来就买卡。先用 API 把端到端流程跑通但要做好三个动作否则后面迁到内网要返工API Key 放到环境变量里不要写死在代码中写一个脱敏函数把项目名称、公司名、金额批量替换成占位符每次调用都把输入、输出、耗时写入日志方便后续追溯和分析失败案例。脱敏函数不用写得多复杂能把最敏感的几个字段遮住就行import re def mask_audit_text(text: str) - str: # 金额统一替换成占位符避免明细金额泄漏 text re.sub(r[0-9](?:[.,][0-9])?(?:万元|元), [金额], text) # 标段编号替换成占位符 text re.sub(r第[一二三四五六七八九十0-9]标段, [标段], text) return text这个阶段的目的不是输出多准而是让团队理解大模型在工程审计里的能力边界。等内网服务就绪代码里只需要把base_url换成内网 vLLM 地址模型名换成ds-audit其余调用逻辑全部不用改。3. 拆解审计任务与提示词工程把合同、清单、签证变成结构化结论3.1 先把任务分成四类抽取、比对、指标、底稿工程审计里问「大模型能不能审结算」是问不出来的因为这不是一个任务而是四类任务的组合。我在项目里习惯这样拆文本抽取合同要素、清单描述、签证理由、变更事由从自然语言里抽出结构化字段。条文比对签证单和合同条款是否冲突、两份合同对同一事项的约定是否一致输出不一致点。指标分析同一标段不同期、不同标段之间的单方造价、材料单价、钢含量离散度给出异常提醒。文档生成审计问题描述、工作底稿初稿、审定表附注把分析结论转成可落底稿的文字。四类任务对模型参数的控制完全不同。抽取任务温度要低输出要严格按字段来比对任务同样低温但每条结论必须带条款依据指标分析要先把口径写清楚不然模型会把含税价和不含税价混在一起算底稿生成可以给模型多一点表述空间但必须留复核位。这里要拦一下「大模型微调」的冲动。工程审计领域的标注数据少且贵大多数团队手里只有几十份已审项目远不够微调一个模型。常见做法是先用提示词工程和 RAG 解决 80% 的问题等攒到几千条带审计结论的问答对再考虑微调否则大概率翻车。3.2 最小可跑的合同条款抽取DeepSeek API 如何调用工程审计里最刚需的场景是把一份合同变成结构化字段方便后续跟清单、结算书对撞。DeepSeek API 的调用方式和 OpenAI 接口兼容用 OpenAI SDK 就能直接调import json import os from openai import OpenAI client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlos.getenv(DEEPSEEK_BASE_URL, https://api.deepseek.com) ) system_prompt 你是工程审计助手。 请从合同文本中抽取下列字段只输出 JSON 结算方式、合同金额、下浮率、暂估价、计价依据、争议解决方式。 若合同中未提及某字段填写 null不要编造。 contract open(sample_contract.txt, encodingutf-8).read() resp client.chat.completions.create( modeldeepseek-chat, temperature0.1, response_format{type: json_object}, messages[ {role: system, content: system_prompt}, {role: user, content: f合同文本如下\n{contract[:3000]}} ] ) print(resp.choices[0].message.content)temperature0.1是关键参数。审计抽取要求稳定输出同一个合同抽十次结果不能有差异温度越低输出越稳但也不要设成 0留一点随机性反而能避免解码阶段卡在某些概率边界上。response_format{type: json_object}强制模型输出 JSON后续json.loads转成字典就能直接入库。modeldeepseek-chat是 API 对话模型的通用名称切换到内网部署时这个参数要改成ds-audit并把base_url指向内网地址。代码里contract[:3000]是验证阶段刻意截断输入方便排查提示词问题整本合同的切块处理在 3.4 节讲。正常返回会是这样一份 JSON{ 结算方式: 固定单价, 合同金额: 35862114.5, 下浮率: 3.2%, 暂估价: 1280000.0, 计价依据: 《建设工程工程量清单计价规范》, 争议解决方式: 向项目所在地人民法院起诉 }金额字段统一转成浮点数后续做审减计算、指标比对才能直接用。3.3 few-shot 示例怎么给审计术语要对齐第一次跑抽取模型经常会输出「下浮比例」而不是「下浮率」或者把「固定单价」理解成「固定总价」。这不是模型笨而是审计口径和模型训练语料里的通用口径不一致。解决办法是在提示词里塞几个 few-shot 示例把术语和格式对齐。sample 示例1 合同文本结算价按中标价乘以1-3.2%不再调整。 输出{结算方式:固定总价下浮,下浮率:3.2%} 示例2 合同文本最终费用按实际完成工程量乘以固定单价结算。 输出{结算方式:固定单价,下浮率:null} 现在抽取 user_prompt sample contract[:3000]示例要满足三个特征字段口径和审计底稿完全一致缺失字段写null而不是省略每个示例控制在两三句话以内不要让示例本身变成干扰。示例不要从模型生成结果里挑最好来自已复核项目的真实底稿改写版字段口径才靠得住。3.4 长合同怎么处理大模型上下文长度不是无限文本量DeepSeek 的上下文长度在同类大模型里属于能打的但工程审计合同动辄几十页上百页直接把整本合同塞进去有两个问题一是 token 成本高二是注意力会被稀释前 20 页的内容记住得多后面的结算与支付条款反而被忽略。常见做法是按合同章节切块处理。把「专用条款」「结算与支付」「违约责任」这些章节拆开每块保留页码和条款号分别抽取最后合并。合并时遇到字段冲突按「专用条款优先于通用条款」的原则覆盖。def split_contract_by_headings(text, headings): chunks [] for i, heading in enumerate(headings): start text.find(heading) end text.find(headings[i 1]) if i 1 len(headings) else len(text) if start ! -1: chunks.append((heading, text[start:end])) return chunks切分后每块控制在 3000 到 5000 字抽取准确率明显比一次性喂全文高。切块切得好不好直接决定后面所有下游任务的准确率这条经验在多个项目里反复验证过。4. 用 RAG 把定额库和制度文件接进 DeepSeek切分、检索与引用设计4.1 审计知识库装什么定额、规范、合同范本、历史底稿大模型训练时没见过你手里的这份合同范本也不知道你们公司审计底稿的内部格式要求。它知道的是通用知识而审计需要的恰恰是项目级、企业级的专属知识。RAG 解决的就是这个问题把审计知识先切好、存好模型回答前先检索相关段落再基于检索结果生成答案。工程审计知识库通常装五类东西表 4-1 审计知识库内容清单知识类型来源格式常见用途清单计价规范PDF、Word结算方式、综合单价口径定额库说明PDF、Excel子目含义、工作内容、单位合同范本Word条款比对、矛盾点提示公司审计制度Word、PDF底稿格式、审计程序要求已审案例脱敏Excel、Word审减线索、表述模板4.2 PDF 切分与向量化表格不能毁在第一步工程审计材料一半以上是 PDF而 PDF 里最麻烦的是表格。直接extract_text()抽表格文本经常把多行表头抽成一串乱字数字和单位错位。我一般会先把表格单独提取出来转成 Markdown 表格再拼回正文里import pdfplumber chunks [] with pdfplumber.open(audit_material.pdf) as pdf: for page_no, page in enumerate(pdf.pages, start1): text page.extract_text() or tables page.extract_tables() for table in tables: md_table \n.join( | | .join( cell.replace(\n, ) if cell else for cell in row ) | for row in table ) text \n\n[表格]\n md_table chunks.append({ page: page_no, text: text })extract_tables()会把线框表格转换成嵌套列表每一行再拼成 Markdown 表格。空单元格保留成空串不能跳过否则整列数据会前移错位。page页码必须保留后面检索结果要能跳回 PDF 原文审计复核全靠这个页码。切块长度一般按 800 到 1500 字一块跨页的段落不需要额外合并因为检索时是按块匹配的块与块之间内容重复一点没有关系。4.3 检索增强先召回相关条款再交给 DeepSeek知识库建好后查询流程是先向量检索、再喂给模型。向量库可以用 Chroma 这类本地库不需要额外起服务import chromadb client chromadb.PersistentClient(path./audit_kb) collection client.get_or_create_collection( nameaudit_rules, metadata{hnsw:space: cosine} ) collection.upsert( ids[fp{chunk[page]}-{idx} for idx, chunk in enumerate(chunks)], documents[chunk[text] for chunk in chunks], metadatas[{page: chunk[page]} for chunk in chunks] ) res collection.query( query_texts[固定单价合同 结算 下浮率], n_results5 ) print(res[documents])metadata{hnsw:space: cosine}把距离度量设为余弦相似度长句子检索比 L2 距离更稳。n_results5不是固定最优值工程审计宁可取 5 到 8 条让模型综合判断也不要只取 1 条否则答案容易被单条材料带偏。如果团队不想自己写向量检索这层也可以用 Dify 这类上层工具编排知识库核心流程仍然是切分、向量化、检索增强这三步。4.4 引用设计模型输出必须带依据不能给裸结论RAG 接好之后如果提示词不约束引用模型还是会自己编。工程审计对输出有一个死要求每条结论都必须能定位到原文。所以提示词里必须写明引用格式请结合【检索材料】回答每条结论都必须引用来源。 引用格式条款原文 页码 章节号。 若检索材料里没有依据直接写未找到依据禁止编造。这是整个提示词工程里最值得抄的一段话。加上这段约束后模型回答的格式会变成「结论 依据 页码」三段式。如果材料里确实没有依据模型会输出「未找到依据」而不是硬编一条。审计员复核时只需要翻到对应页码几秒钟就能确认对错。5. 不走样的输出才敢用工程审计落地 DeepSeek 的 5 个高频坑这一章写的全是实际跑审计大模型时踩过的坑。提示词写得再漂亮这五个问题不处理输出也没人敢用。5.1 黑匣子幻觉模型把定额子目编号编得头头是道现象让模型判断某个签证是否套用了正确的定额子目它给出「定额 D3-214」这样具体的编号核对后查无此子目。原因造价类术语在模型训练语料里大量出现模型知道「定额子目」长什么样但它的本质是语言模型不是数据库语言上合理的编号并不保证真实存在。解决把定额库做成 RAG提示词强制「只依据材料找不到就写未找到」。同时要求输出带「依据原文 页码」。这两个约束叠上去模型能编的幻觉空间会被压缩到很小。5.2 超长合同一次喂进去上下文长度变长了不等于注意力管得住现象把 80 页合同一次性丢给模型前 20 页的内容抽取得很准后面付款条款、违约责任全被忽略。原因大模型上下文长度只是「能接收」的文本量不代表「能专注」的文本量。文本越长注意力越分散合同后半段的关键条款被淹没。解决按标题分块抽取每块 3000 到 5000 字分别抽取再合并。多调用几次、多合并一次比一次塞进整本合同可靠得多。5.3 PDF 表格抽出来全是乱的现象extract_text()抽出来的单价表数字和单位错位有的单元格直接空了单价金额对不上。原因很多审计 PDF 是从计价软件导出的表头跨行、备注列为空、表格线断裂文本抽取逻辑抓不到坐标关系。解决表格优先用extract_tables()而不是extract_text()空单元格保留空串扫描件表格走 OCR 管线对齐坐标后再结构化。关键金额列在抽取后还要做一次规则校验比如用正则检查金额字段是否为合法数字这样能拦截大部分错位。5.4 脱敏不是替换公司名和金额就够了现象把项目名称、公司名替换掉后调用外部 API结果对方模型反推出项目所在区域和标段内部经济数据仍然暴露。原因工程审计数据的背景空间很小。项目地点、工期、材料品牌、标段编号、金额区间组合起来足以定位到具体项目。单纯替换公司名和金额挡不住交叉定位。解决API 阶段只跑公开材料或纯虚构测试数据正式结算数据一律走内网部署。脱敏规则要覆盖项目名称、地点、标段、金额区间、材料品牌并且脱敏后的字段不能再相互关联定位。5.5 结论没有追溯性AI 说是就是审计底稿没法写现象模型输出「该签证不符合合同约定」复核人翻半天也找不到它引用的条款在哪一页。原因输出时没把依据设计进去模型给了一个裸结论。结论再准审计底稿里也没法写「AI 说的」。解决把引用当作输出结构的一部分每条结论必须带「条款原文 页码 章节号」。下游页面按引用跳转原文对照复核效率能提升一大截。6. 让 DeepSeek 直接产出审计底稿初稿JSON 约束与复核闭环6.1 用 JSON 结构卡住输出模型自由发挥越少越好当 DeepSeek 的输出要进入审计底稿流程时就不能再让它随意生成自然语言了。我会在提示词里指定输出结构再在代码里加一道 JSON Schema 校验import json import jsonschema schema { type: object, properties: { 审计问题: {type: string}, 涉及条款: {type: string}, 影响金额: {type: [number, null]}, 审计建议: {type: string} }, required: [审计问题, 涉及条款, 影响金额, 审计建议] } content json.loads(resp.choices[0].message.content) jsonschema.validate(instancecontent, schemaschema) print(content)response_format{type: json_object}保证模型输出是 JSON 对象jsonschema.validate保证字段齐全、类型正确。校验失败时把原始返回写入日志不要直接报错打断整条审计流水线而是让下一次调用重试。6.2 复核闭环AI 产出初稿审计员做终稿大模型在工程审计里的定位应该是「助理」不是「审定人」。不同输出类型对自动化和复核的要求完全不同我一般按下面这张表定权责输出类型自动化程度复核要求合同要素抽取字段可自动入临时库人工抽查金额字段重点核对签证与结算比对建议生成初稿必须逐条复核原文审计底稿文字生成初稿必须经审计员签发审定表审定金额禁止自动填数必须人工计算确认我自己最开始做这类工具有个习惯看到模型输出很流畅就忍不住想把结果直接写进底稿。后来吃过一次亏模型把下浮率的基数写反了输出却特别通顺差点把审减额算错。之后我给自己定了一条规矩凡是模型产出的数字都要能在原始合同或结算书里指出出处才允许落底稿。把这条规矩写进提示词、写进接口、写进复核流程比换一个大模型更管用。希望帮到你。本文还有配套的精品资源点击获取