简介以能源行业大模型落地为主题的实践分享PPT适合关注数据治理、AI底座建设的企业管理者与数字化转型从业者。内容依托云鼎科技项目案例围绕“数据底座AI底座”整体架构系统讲解数据标准、数据质量、数据安全及湖仓一体化数据治理体系并展示视觉大模型、图网络、多模态、自然语言处理等在智慧矿山、智慧选煤、电力新能源等场景的典型应用。资源压缩包共1个pptx文件约12.62MB图文并茂、体系完整可直接用于内部培训、方案汇报或行业调研参考。目前已有69人学习下载。通过PPT可快速理解能源行业大模型从数据采集、治理到智能化应用的端到端路径掌握矿区、工厂、电厂等细分场景的落地思路和关键经验其中包含数据标准体系、模型参数调优、多模态融合决策等关键知识点。1. 能源行业的数据治理正在从“填表”变成“读文档”能源行业从来不缺数据——SCADA、DCS、AIoT传感器、设备台账、检修工单、地质报告、碳核查表每套系统都在产生TB级记录。但真正到了统计口径对齐、指标归因、合规审计的时候数据团队往往要花一半时间在“对齐同一台设备的不同叫法”上SIS里叫“#1汽轮机”ERP里叫“1号机”EAM里叫“TURBINE-01”三个系统一合并数据质量马上崩。传统数据治理靠的是主数据管理MDM加正则表达式清洗本质是“事先定义规则、事后匹配规则”规则对结构化表格有效遇到非结构化文档、图表、现场记录就失灵。大模型介入后的变化在于治理对象从“字段”升级到了“语义”。LLM可以读PDF、识别实体、推断同义词、生成质量规则甚至可以帮你把报表层缺失的口径描述补出来——这不是把数据治理流程加班而是改变了“先定标准再清洗数据”的固定路径。本文讲的是把大模型作为数据治理流水线里的一个可复用组件而不是单独挂一个聊天窗口覆盖实体对齐、非结构化抽取、质量规则生成、对话式BI和领域问答这几类可落地场景。适合正在做能源行业数据中台、数据资产入表、或尝试用LLM替代部分人工数据运维的人。2. 为什么能源行业的数据治理先要从表结构走向非结构化数据2.1 传统治理的三大硬约束字段、口径、生命周期能源行业数据治理的困难点不在于数据量而在于“多源异构”极其严重。以发电企业为例生产实时数据来自数千个测点的时序库经营数据在财务和ERP系统里设备铭牌在EAM里而检修报告、试验报告是PDF和扫描件。传统数据治理平台的元数据采集、数据血缘解析、质量规则校验基本都围绕结构化表展开。一张维度表、一张事实表、一个枚举字典按规范维护主数据代码这是老办法的核心。这套办法在三个地方会卡住。第一字段口径不统一不同系统对“发电量”的定义有“毛发电量”“上网电量”“等效可用系数修正后的发电量”靠人工维护口径字典一个集团几千个指标维护成本极高。第二非结构化数据进不了湖仓检修工单、巡检记录、设备点检表里的异常描述、故障代码、处理措施这些信息当前只能以文件形式挂在系统里无法被SQL直接查询。第三数据质量规则生硬传统规则是“字段非空、值域检查、枚举合法性”但对“设备名称字段里出现错别字但不违反长度校验”这类语义型问题毫无办法。2.2 大模型在数据治理中扮演的角色“语义算子”而不是“另一个系统”把大模型放进数据治理流水线时最实用的定位是把它当作一组“语义算子”跟传统的校验规则、ETL任务编排在一起而不是另起一个完整的数据治理平台。常见做法是保留原有的元数据仓库、数据血缘、质量评分框架只把最消耗人力的环节替换成LLM调用如“判断两个设备名是否指向同一实体”“抽取检修报告中的故障部件和处置措施”“基于表结构自动生成质量规则”。这样设计的理由是可控性。数据治理涉及审计不能用一个随机性很强的LLM直接替代规则引擎的结果否则出了问题无法解释。合理的方案是LLM生成候选规则或结果经过置信度过滤后写入人工审批队列审批通过才进入生产规则库。也就是说LLM在这个场景里做的是“辅助治理者加速决策”而不是“自动治理”。这一定位贯穿整个工程的选型和参数调整。2.2.1 没必要一开始就微调开源大模型在能源行业的数据治理项目里很多人上来就问要不要微调一个13B或70B模型建议先不要。治理场景的典型任务是实体对齐、信息抽取、规则生成任务面不窄但结构性强基座模型只要具备指令跟随和中文理解能力配合好的Prompt和少量示例few-shot就能达到生产可用真正难的是把抽取结果结构化成治理平台要的JSON Schema。真正需要微调的时机是你的行业术语体系太特殊或者召回需要大量私有术语的实体边界后面第4章再展开。3. 落地路径把大模型嵌入能源数据治理流水线的代码与参数3.1 实体对齐一份可以“抄作业”的LLM清洗脚本先从最常碰到的痛处动手设备主数据对齐。下面是调用LLM接口判断两个设备名称是否指向同一物理实体的最小实现。注意这里的接口是OpenAI兼容协议本地部署的vLLM、FastChat以及云上通义、智谱等多种服务都支持这种调用格式。import json from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, # 本地兼容服务生产建议走网关打日志和限流 api_keyEMPTY ) def judge_entity_alias(name_a: str, name_b: str) - dict: prompt f 你是能源行业数据治理助手。判断下表中的两条设备记录是否指向同一个物理实体。 规则只看是否同一实体的不同叫法不比较位置、编号、容量等属性。 A: {name_a} B: {name_b} 输出JSON格式 {{is_same: true, confidence: 0.95, reason: 简短说明}} resp client.chat.completions.create( modelqwen2.5-14b-instruct, messages[{role: user, content: prompt}], temperature0.0, response_format{type: json_object}, max_tokens128, ) return json.loads(resp.choices[0].message.content) if __name__ __main__: print(judge_entity_alias(#1汽轮机, 1号机))这段代码的逻辑说明把待比对的设备名拼进Prompt强制模型输出JSON并指定confidence字段置信度可用于后续设置阈值。关键参数有三个temperature固定为0避免随机波动response_format限制成JSON以便直接解析max_tokens给128足够输出结构化结果而不会浪费算力。实际生产时建议把结果写入一张中间表如ai_entity_pairs批量跑完后转入人工审批流。3.2 非结构化数据治理巡检记录和检修报告的“文档转表格”非结构化数据治理在能源行业长期是空白区域。一张两页的变压器试验报告内容含温升数据、油色谱检测记录、结论文字想把它归入数据资产传统做法是人手录入。常见做法是“版面解析 LLM抽取”两步先用OCR或PDF解析库提取文本内容和表格坐标再把文本按表格切片送入LLM要求按预定义Schema抽出字段。选型上解析层用PyMuPDF或国内的PaddleOCR抽取层用LLM不要指望LLM直接读PDF。具体策略见表。非结构化数据类型解析层方案LLM抽取任务输出目标PDF检修报告PyMuPDF/OCR保留页码和段落位置抽取故障代码、部件、处置措施、工时修复记录结构化表手写点检表OCR 置信度过滤抽取日期、设备位号、异常描述点检明细表试验报告表格识版控制台输出行式数据抽取试验项目、数值、结论试验台账合同与验收文档段落标题识别抽取双方主体、金额、验收条件合同要素表3.2.1 抽取提示词的核心结构给Schema再加三个反例写抽取Prompt时比“请抽取以下字段”更可靠的写法是给出字段枚举值、单位要求、以及反例。比如“处理措施”字段必须从固定枚举里选禁止口语化动词如‘修了修了’。反例要放在正例之后模型更容易学到禁用边界。针对能源行业单位换算是高发错误建议在Prompt中显式声明“所有电能量统一换算为MWh所有长度统一换算为米”。请从以下检修记录文本中抽取字段严格输出JSON {device_code: 设备位号, fault_code: 故障代码, measure: 处理措施, work_hours: 工时(小时)} 要求 1. 故障代码只需枚举值未出现则输出null。 2. 处理措施对应枚举[更换, 修复, 调整, 清洗, 润滑]不在枚举内则取最接近项。 3. 工时必须为数字不带中文“小时”。 4. 若文本中设备位号为手写体且不确定device_code输出最可能的同时confidence设为0.5。 反例 输入: 轴承磨损严重现场修了一下花了大概3个小时 错误输出: {device_code: 轴承, fault_code: null, measure: 修了一下, work_hours: 3小时左右} 正确输出: {device_code: null, fault_code: null, measure: 修复, work_hours: 3}反例的价值在于把隐含规则显性化大模型在抽取时倾向于“忠实原文”如果提示词只写了“处理措施”而不给枚举和反例输出很可能是无法入数据库的散文。值域的合法性校验不能完全交给LLM抽取结果再经一层规则校验枚举匹配、数值范围是常见兜底。3.3 让LLM生成数据质量规则并把规则落库数据质量规则的传统写法是手动在平台界面配置字段非空、唯一性校验、值域阈值。前提是你已经知道哪个字段该设什么规则但集团级数据湖有几十万张表人工逐表配置永远滞后。让LLM根据元数据和采样数据生成候选规则可以大幅压缩这个gap。注意生成规则的结果不能直接生效要经过一个“规则预评审”步骤。LLM生成的是描述性规则和算子参数建议由DBA确认后落入规则引擎这才是生产可用的闭环。{ goal: 检测发电量字段的异常突变值, table: ods.dwd_gen_asset, field: gross_gen_mwh, generated_rules: [ { rule_type: 绝对值区间, sql_fragment: gross_gen_mwh between 0 and 15000, severity: ERROR, comment: 单台机组小时上网电量超过15000MWh不合理对照装机容量换算 }, { rule_type: 波动率告警, sql_fragment: abs(gross_gen_mwh - lag(gross_gen_mwh, 1) over (partition by asset_code order by ts)) 5000, severity: WARNING, comment: 小时级突增超过5000MWh通常是倍率或单位错误 } ] }这段JSON的设计意图规则分成ERROR和WARNING两档前一档进生产告警后一档只发提示避免波动率误杀正常启停。SQL片段保留标准方言片段便于接入Drools、Apache Griffin等规则引擎也可以直接拽进调度系统执行。4. 能源AI应用实践的两条主线对话式BI与知识问答的工程取舍4.1 Text2SQL在能源行业最优解Schema压缩 检索增强而不是裸写SQL人工智能应用在能源数据平台上最常被问到的两个需求一是运营驾驶舱对话式报表对话式BI二是基于制度文档的非结构化知识问答。第一线实践者最容易踩的坑是觉得大模型能写SQL就把整库Schema直接丢给模型。实际上一张宽表几十上百个字段Prompt很容易超出上下文窗口或者模型被无关字段干扰。常见做法是把字段列表压缩成“字段名:业务释义枚举样例”的短描述再用关键词检索召回相关表最后把召回结果和用户问题送进LLM生成SQL。可用表元数据仅展示字段子集 - fact_power_generation: 发电量事实表 - asset_code: 机组编号如GF01, GF02 - ts: 统计时间格式yyyy-MM-dd HH:mm:ss - gross_gen_mwh: 毛发电量单位MWh - net_gen_mwh: 上网电量单位MWh - coal_cons_t: 耗煤量单位吨 明确要求 你的回答只输出可执行的PostgreSQL SQL不要输出解释。 若问题存在歧义例如未指定时间粒度默认按“日”聚合。在给模型限定可用表集合与实际字段字典之后正确率会显著提升。真实项目里还必须叠加SQL白名单检查识别输出的SQL是否有跨库未授权查询、有无ORDER BY导致内存溢出的风险这一步不要省。能源行业每条业务线都有独立库表权限边界模型不知道需要外层拦截。4.2 行业知识问答RAG里的chunk切分和召回参数知识问答是能源领域制度文档数字化最直接的需求——调度规程、操作票制度、安全生产法、应急响应预案都属于非结构化数据治理的结果再利用。RAG落地时一个总被低估的参数是chunk_size。电力规程往往带大量条款编号和嵌套列表切短了割裂上下文切长了embedding向量不聚焦。经验值是法规类文档按章节切条款较独立时可以宽松到800-1200字运行规程类文档按操作步骤块切每块不超过500字。检索时用混合检索BM25加向量召回。top_k不算大前12个chunk进LLM就够用超过后噪音明显增加。另外能源文本有大量公式和特殊符号处理时保留原格式即可不要强行转纯文本否则“±”“≤”这些符号全丢下游回答会被带偏。4.2.1 vLLM部署大模型的推荐参数如果选择本地部署LoRA微调过的行业基座模型vLLM是当前的主流方案。实测中建议按以下参数启动服务兼顾吞吐与显存利用率vllm serve /models/energy-llama-13b \ --served-model-name energy-llama \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --quantization awq \ --tensor-parallel-size 2 \ --enable-prefix-caching \ --max-num-seqs 16参数含义逐一说明max-model-len不建议顶满8K上下文够治理场景使用顶得太高会显著拉低batch并发gpu-memory-utilization留0.15给采样和调度调成0.95容易OOMquantization awq是显存不足时降级到4bit的常用选择准确率损失在抽取类任务上可接受enable-prefix-caching对同一表单反复查询同一组指令能明显加速。这里要特别提醒若发现每token延迟高于300ms先看是不是tensor-parallel-size配的和GPU数量不一致或者KV cache命中率太低。4.3 什么时候可以微调微调不是收藏夹里的摆设而是特定场景才需要走的通道。判断标准不是“数据量大”而是“领域术语歧义是否无法用Prompt解决”。如果一个词在不同业务场景下有不同意义而模型总部分无法自我消歧——例如“热备用”在运行规程和继保规程里的含义差异靠RAG提示词不解决根本问题需要收集指令微调数据。推荐用LoRA而非全参微调用Llama-Factory这类平台整理数据集学习率在1e-4到2e-4区间epoch只跑2到3个防止灾难性遗忘。微调后要专门跑一组“通用治理能力回归集”验证文本抽取和实体对齐能力没有下降。5. 上线前别急着演示先做三轮结果验证大模型在数据治理和AI应用里的产物每个都要经历“质量检验”直接进入生产系统是事故前置。我给三个可执行步骤从松到严层层逼近。第一轮是规则回归。把历史两年内的已知数据问题如设备名重复、检修记录缺字段整理成一份回归测试集用pytest包装跑通治理流水线后校验返回结果的数量和命中率。回归集不能只存“正确期望输出”还必须放进三个“反例”比如“两个名称其实是两台不同机组但型号相同”专门用来暴露LLM的过拟合判断。回归测试类型输入样例期望输出判定规则正例1号机 / #1机组sametrue, conf0.8字段精确匹配反例1号机(火电) / 1号机组(风电)samefalse, conf0.7字段精确匹配边界例1号机 / 1号机组 新增预留位号sametrue, conf 0.5-0.8转人工审核第二轮是“结果血缘可回看”。每次LLM批量运行后把原始输入、Prompt版本、模型版本、输出结果、置信度全部写入结果表保留指针指向模型日志。一旦发现上线后某个抽取结果错误可以立即回溯是哪次模型升级或Prompt改动导致的。第三轮是人工抽检的职业画像。在治理平台上建一个轻量审核队列按比例抽样权重偏向“置信度在0.4到0.8之间”的结果因为高置信度和低置信度反而好判断灰色地带才是规则盲区。抽检用双人背靠背标注不一致的样本单独汇总作为下一轮Prompt修正的输入这样做可以把迭代改成带目标的过程。本文还有配套的精品资源点击获取 大模型重塑能源数据治理：实体对齐、非结构化抽取与质量规则生成
简介以能源行业大模型落地为主题的实践分享PPT适合关注数据治理、AI底座建设的企业管理者与数字化转型从业者。内容依托云鼎科技项目案例围绕“数据底座AI底座”整体架构系统讲解数据标准、数据质量、数据安全及湖仓一体化数据治理体系并展示视觉大模型、图网络、多模态、自然语言处理等在智慧矿山、智慧选煤、电力新能源等场景的典型应用。资源压缩包共1个pptx文件约12.62MB图文并茂、体系完整可直接用于内部培训、方案汇报或行业调研参考。目前已有69人学习下载。通过PPT可快速理解能源行业大模型从数据采集、治理到智能化应用的端到端路径掌握矿区、工厂、电厂等细分场景的落地思路和关键经验其中包含数据标准体系、模型参数调优、多模态融合决策等关键知识点。1. 能源行业的数据治理正在从“填表”变成“读文档”能源行业从来不缺数据——SCADA、DCS、AIoT传感器、设备台账、检修工单、地质报告、碳核查表每套系统都在产生TB级记录。但真正到了统计口径对齐、指标归因、合规审计的时候数据团队往往要花一半时间在“对齐同一台设备的不同叫法”上SIS里叫“#1汽轮机”ERP里叫“1号机”EAM里叫“TURBINE-01”三个系统一合并数据质量马上崩。传统数据治理靠的是主数据管理MDM加正则表达式清洗本质是“事先定义规则、事后匹配规则”规则对结构化表格有效遇到非结构化文档、图表、现场记录就失灵。大模型介入后的变化在于治理对象从“字段”升级到了“语义”。LLM可以读PDF、识别实体、推断同义词、生成质量规则甚至可以帮你把报表层缺失的口径描述补出来——这不是把数据治理流程加班而是改变了“先定标准再清洗数据”的固定路径。本文讲的是把大模型作为数据治理流水线里的一个可复用组件而不是单独挂一个聊天窗口覆盖实体对齐、非结构化抽取、质量规则生成、对话式BI和领域问答这几类可落地场景。适合正在做能源行业数据中台、数据资产入表、或尝试用LLM替代部分人工数据运维的人。2. 为什么能源行业的数据治理先要从表结构走向非结构化数据2.1 传统治理的三大硬约束字段、口径、生命周期能源行业数据治理的困难点不在于数据量而在于“多源异构”极其严重。以发电企业为例生产实时数据来自数千个测点的时序库经营数据在财务和ERP系统里设备铭牌在EAM里而检修报告、试验报告是PDF和扫描件。传统数据治理平台的元数据采集、数据血缘解析、质量规则校验基本都围绕结构化表展开。一张维度表、一张事实表、一个枚举字典按规范维护主数据代码这是老办法的核心。这套办法在三个地方会卡住。第一字段口径不统一不同系统对“发电量”的定义有“毛发电量”“上网电量”“等效可用系数修正后的发电量”靠人工维护口径字典一个集团几千个指标维护成本极高。第二非结构化数据进不了湖仓检修工单、巡检记录、设备点检表里的异常描述、故障代码、处理措施这些信息当前只能以文件形式挂在系统里无法被SQL直接查询。第三数据质量规则生硬传统规则是“字段非空、值域检查、枚举合法性”但对“设备名称字段里出现错别字但不违反长度校验”这类语义型问题毫无办法。2.2 大模型在数据治理中扮演的角色“语义算子”而不是“另一个系统”把大模型放进数据治理流水线时最实用的定位是把它当作一组“语义算子”跟传统的校验规则、ETL任务编排在一起而不是另起一个完整的数据治理平台。常见做法是保留原有的元数据仓库、数据血缘、质量评分框架只把最消耗人力的环节替换成LLM调用如“判断两个设备名是否指向同一实体”“抽取检修报告中的故障部件和处置措施”“基于表结构自动生成质量规则”。这样设计的理由是可控性。数据治理涉及审计不能用一个随机性很强的LLM直接替代规则引擎的结果否则出了问题无法解释。合理的方案是LLM生成候选规则或结果经过置信度过滤后写入人工审批队列审批通过才进入生产规则库。也就是说LLM在这个场景里做的是“辅助治理者加速决策”而不是“自动治理”。这一定位贯穿整个工程的选型和参数调整。2.2.1 没必要一开始就微调开源大模型在能源行业的数据治理项目里很多人上来就问要不要微调一个13B或70B模型建议先不要。治理场景的典型任务是实体对齐、信息抽取、规则生成任务面不窄但结构性强基座模型只要具备指令跟随和中文理解能力配合好的Prompt和少量示例few-shot就能达到生产可用真正难的是把抽取结果结构化成治理平台要的JSON Schema。真正需要微调的时机是你的行业术语体系太特殊或者召回需要大量私有术语的实体边界后面第4章再展开。3. 落地路径把大模型嵌入能源数据治理流水线的代码与参数3.1 实体对齐一份可以“抄作业”的LLM清洗脚本先从最常碰到的痛处动手设备主数据对齐。下面是调用LLM接口判断两个设备名称是否指向同一物理实体的最小实现。注意这里的接口是OpenAI兼容协议本地部署的vLLM、FastChat以及云上通义、智谱等多种服务都支持这种调用格式。import json from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, # 本地兼容服务生产建议走网关打日志和限流 api_keyEMPTY ) def judge_entity_alias(name_a: str, name_b: str) - dict: prompt f 你是能源行业数据治理助手。判断下表中的两条设备记录是否指向同一个物理实体。 规则只看是否同一实体的不同叫法不比较位置、编号、容量等属性。 A: {name_a} B: {name_b} 输出JSON格式 {{is_same: true, confidence: 0.95, reason: 简短说明}} resp client.chat.completions.create( modelqwen2.5-14b-instruct, messages[{role: user, content: prompt}], temperature0.0, response_format{type: json_object}, max_tokens128, ) return json.loads(resp.choices[0].message.content) if __name__ __main__: print(judge_entity_alias(#1汽轮机, 1号机))这段代码的逻辑说明把待比对的设备名拼进Prompt强制模型输出JSON并指定confidence字段置信度可用于后续设置阈值。关键参数有三个temperature固定为0避免随机波动response_format限制成JSON以便直接解析max_tokens给128足够输出结构化结果而不会浪费算力。实际生产时建议把结果写入一张中间表如ai_entity_pairs批量跑完后转入人工审批流。3.2 非结构化数据治理巡检记录和检修报告的“文档转表格”非结构化数据治理在能源行业长期是空白区域。一张两页的变压器试验报告内容含温升数据、油色谱检测记录、结论文字想把它归入数据资产传统做法是人手录入。常见做法是“版面解析 LLM抽取”两步先用OCR或PDF解析库提取文本内容和表格坐标再把文本按表格切片送入LLM要求按预定义Schema抽出字段。选型上解析层用PyMuPDF或国内的PaddleOCR抽取层用LLM不要指望LLM直接读PDF。具体策略见表。非结构化数据类型解析层方案LLM抽取任务输出目标PDF检修报告PyMuPDF/OCR保留页码和段落位置抽取故障代码、部件、处置措施、工时修复记录结构化表手写点检表OCR 置信度过滤抽取日期、设备位号、异常描述点检明细表试验报告表格识版控制台输出行式数据抽取试验项目、数值、结论试验台账合同与验收文档段落标题识别抽取双方主体、金额、验收条件合同要素表3.2.1 抽取提示词的核心结构给Schema再加三个反例写抽取Prompt时比“请抽取以下字段”更可靠的写法是给出字段枚举值、单位要求、以及反例。比如“处理措施”字段必须从固定枚举里选禁止口语化动词如‘修了修了’。反例要放在正例之后模型更容易学到禁用边界。针对能源行业单位换算是高发错误建议在Prompt中显式声明“所有电能量统一换算为MWh所有长度统一换算为米”。请从以下检修记录文本中抽取字段严格输出JSON {device_code: 设备位号, fault_code: 故障代码, measure: 处理措施, work_hours: 工时(小时)} 要求 1. 故障代码只需枚举值未出现则输出null。 2. 处理措施对应枚举[更换, 修复, 调整, 清洗, 润滑]不在枚举内则取最接近项。 3. 工时必须为数字不带中文“小时”。 4. 若文本中设备位号为手写体且不确定device_code输出最可能的同时confidence设为0.5。 反例 输入: 轴承磨损严重现场修了一下花了大概3个小时 错误输出: {device_code: 轴承, fault_code: null, measure: 修了一下, work_hours: 3小时左右} 正确输出: {device_code: null, fault_code: null, measure: 修复, work_hours: 3}反例的价值在于把隐含规则显性化大模型在抽取时倾向于“忠实原文”如果提示词只写了“处理措施”而不给枚举和反例输出很可能是无法入数据库的散文。值域的合法性校验不能完全交给LLM抽取结果再经一层规则校验枚举匹配、数值范围是常见兜底。3.3 让LLM生成数据质量规则并把规则落库数据质量规则的传统写法是手动在平台界面配置字段非空、唯一性校验、值域阈值。前提是你已经知道哪个字段该设什么规则但集团级数据湖有几十万张表人工逐表配置永远滞后。让LLM根据元数据和采样数据生成候选规则可以大幅压缩这个gap。注意生成规则的结果不能直接生效要经过一个“规则预评审”步骤。LLM生成的是描述性规则和算子参数建议由DBA确认后落入规则引擎这才是生产可用的闭环。{ goal: 检测发电量字段的异常突变值, table: ods.dwd_gen_asset, field: gross_gen_mwh, generated_rules: [ { rule_type: 绝对值区间, sql_fragment: gross_gen_mwh between 0 and 15000, severity: ERROR, comment: 单台机组小时上网电量超过15000MWh不合理对照装机容量换算 }, { rule_type: 波动率告警, sql_fragment: abs(gross_gen_mwh - lag(gross_gen_mwh, 1) over (partition by asset_code order by ts)) 5000, severity: WARNING, comment: 小时级突增超过5000MWh通常是倍率或单位错误 } ] }这段JSON的设计意图规则分成ERROR和WARNING两档前一档进生产告警后一档只发提示避免波动率误杀正常启停。SQL片段保留标准方言片段便于接入Drools、Apache Griffin等规则引擎也可以直接拽进调度系统执行。4. 能源AI应用实践的两条主线对话式BI与知识问答的工程取舍4.1 Text2SQL在能源行业最优解Schema压缩 检索增强而不是裸写SQL人工智能应用在能源数据平台上最常被问到的两个需求一是运营驾驶舱对话式报表对话式BI二是基于制度文档的非结构化知识问答。第一线实践者最容易踩的坑是觉得大模型能写SQL就把整库Schema直接丢给模型。实际上一张宽表几十上百个字段Prompt很容易超出上下文窗口或者模型被无关字段干扰。常见做法是把字段列表压缩成“字段名:业务释义枚举样例”的短描述再用关键词检索召回相关表最后把召回结果和用户问题送进LLM生成SQL。可用表元数据仅展示字段子集 - fact_power_generation: 发电量事实表 - asset_code: 机组编号如GF01, GF02 - ts: 统计时间格式yyyy-MM-dd HH:mm:ss - gross_gen_mwh: 毛发电量单位MWh - net_gen_mwh: 上网电量单位MWh - coal_cons_t: 耗煤量单位吨 明确要求 你的回答只输出可执行的PostgreSQL SQL不要输出解释。 若问题存在歧义例如未指定时间粒度默认按“日”聚合。在给模型限定可用表集合与实际字段字典之后正确率会显著提升。真实项目里还必须叠加SQL白名单检查识别输出的SQL是否有跨库未授权查询、有无ORDER BY导致内存溢出的风险这一步不要省。能源行业每条业务线都有独立库表权限边界模型不知道需要外层拦截。4.2 行业知识问答RAG里的chunk切分和召回参数知识问答是能源领域制度文档数字化最直接的需求——调度规程、操作票制度、安全生产法、应急响应预案都属于非结构化数据治理的结果再利用。RAG落地时一个总被低估的参数是chunk_size。电力规程往往带大量条款编号和嵌套列表切短了割裂上下文切长了embedding向量不聚焦。经验值是法规类文档按章节切条款较独立时可以宽松到800-1200字运行规程类文档按操作步骤块切每块不超过500字。检索时用混合检索BM25加向量召回。top_k不算大前12个chunk进LLM就够用超过后噪音明显增加。另外能源文本有大量公式和特殊符号处理时保留原格式即可不要强行转纯文本否则“±”“≤”这些符号全丢下游回答会被带偏。4.2.1 vLLM部署大模型的推荐参数如果选择本地部署LoRA微调过的行业基座模型vLLM是当前的主流方案。实测中建议按以下参数启动服务兼顾吞吐与显存利用率vllm serve /models/energy-llama-13b \ --served-model-name energy-llama \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --quantization awq \ --tensor-parallel-size 2 \ --enable-prefix-caching \ --max-num-seqs 16参数含义逐一说明max-model-len不建议顶满8K上下文够治理场景使用顶得太高会显著拉低batch并发gpu-memory-utilization留0.15给采样和调度调成0.95容易OOMquantization awq是显存不足时降级到4bit的常用选择准确率损失在抽取类任务上可接受enable-prefix-caching对同一表单反复查询同一组指令能明显加速。这里要特别提醒若发现每token延迟高于300ms先看是不是tensor-parallel-size配的和GPU数量不一致或者KV cache命中率太低。4.3 什么时候可以微调微调不是收藏夹里的摆设而是特定场景才需要走的通道。判断标准不是“数据量大”而是“领域术语歧义是否无法用Prompt解决”。如果一个词在不同业务场景下有不同意义而模型总部分无法自我消歧——例如“热备用”在运行规程和继保规程里的含义差异靠RAG提示词不解决根本问题需要收集指令微调数据。推荐用LoRA而非全参微调用Llama-Factory这类平台整理数据集学习率在1e-4到2e-4区间epoch只跑2到3个防止灾难性遗忘。微调后要专门跑一组“通用治理能力回归集”验证文本抽取和实体对齐能力没有下降。5. 上线前别急着演示先做三轮结果验证大模型在数据治理和AI应用里的产物每个都要经历“质量检验”直接进入生产系统是事故前置。我给三个可执行步骤从松到严层层逼近。第一轮是规则回归。把历史两年内的已知数据问题如设备名重复、检修记录缺字段整理成一份回归测试集用pytest包装跑通治理流水线后校验返回结果的数量和命中率。回归集不能只存“正确期望输出”还必须放进三个“反例”比如“两个名称其实是两台不同机组但型号相同”专门用来暴露LLM的过拟合判断。回归测试类型输入样例期望输出判定规则正例1号机 / #1机组sametrue, conf0.8字段精确匹配反例1号机(火电) / 1号机组(风电)samefalse, conf0.7字段精确匹配边界例1号机 / 1号机组 新增预留位号sametrue, conf 0.5-0.8转人工审核第二轮是“结果血缘可回看”。每次LLM批量运行后把原始输入、Prompt版本、模型版本、输出结果、置信度全部写入结果表保留指针指向模型日志。一旦发现上线后某个抽取结果错误可以立即回溯是哪次模型升级或Prompt改动导致的。第三轮是人工抽检的职业画像。在治理平台上建一个轻量审核队列按比例抽样权重偏向“置信度在0.4到0.8之间”的结果因为高置信度和低置信度反而好判断灰色地带才是规则盲区。抽检用双人背靠背标注不一致的样本单独汇总作为下一轮Prompt修正的输入这样做可以把迭代改成带目标的过程。本文还有配套的精品资源点击获取