尧图网站建设 
简介电网大模型应用进展代码包整合了行业公开信息的要点以HTML页面形式呈现国网湖南电科院配网视觉大模型、国网与百度合作文心大模型、国网信通电力安监大模型、南网“大瓦特”跨模态大模型及国家能源集团能源通道大模型的落地情况也提及金融、汽车、政务等行业加速复制与中标项目激增的趋势。面向关注AI在能源电力领域应用的开发者、产品经理和行业研究人员可作为行业背景速览或汇报素材。压缩包共3个文件包含HTML说明页、inscode工程配置及gitignore辅助文件整体仅6KB内容集中、便于在线预览。目前已有157人学习适合快速了解大模型从试点走向核心业务场景的路径以及数据治理、逻辑推理优化、工程化适配等挑战为相关项目预研或方案设计提供参考。 电网大模型这个组合一年多前听着还像概念包装但从去年开始我在实际项目里陆续把设备故障诊断、规程问答、工单分析这些场景都跑通了。我的结论很明确电网行业是大模型最容易出实际效果的行业之一——因为电力系统沉淀了大量结构化数据、海量历史文本工单和极高的知识复用需求而大模型最擅长的事情恰好是把文本变成可检索、可调用的能力。这篇文章不聊概念只聊落地场景怎么切、模型怎么选、数据怎么喂、代码怎么写、坑怎么避。适合准备在电力行业引入大模型的技术负责人和一线开发也适合想了解工业大模型真实进展的人。1. 电网大模型在做什么先把需求切成能落地的块很多团队拿到大模型第一反应是“做个聊天机器人”但在电网这种生产型行业聊天机器人是价值最低的形态。真正能落地的是把大模型嵌进现有业务流程里替代原来靠人翻文档、凭经验判断的环节。1.1 三个最容易出效果的应用场景第一个是设备故障诊断与检修辅助。电网设备台账、试验报告、红外测温数据、历史故障记录散落在PMS系统里老师傅退休后这些经验就流失了。大模型能把设备履历和历史故障记录组织成知识库运维人员输入一串巡检编码或者设备编号模型就能返回同类故障的处置历史和检修建议。我们做过一个变压器诊断原型输入“220kV 1号主变油中乙炔超标”模型直接给出色谱分析结论、相关规程条款和近三年同类案例清单现场老师傅看了说“这比我翻系统快”。第二个是调度规程问答与操作辅助。调度规程、操作票、应急预案这些文档动辄几百页调度员值班时查一条规程要翻半天。我们把这些规程文档做成了RAG知识库调度员自然语言提问“线路过载5分钟按规程第一步该怎么处理”模型返回处理步骤并标注依据条文编号。关键点是不让模型自由发挥所有回答必须带出处这样调度员敢用领导也敢推。第三个是客服工单智能分类与摘要。95598工单每天几千条人工分类和填写摘要费时费力。微调后的大模型能自动抽取故障地点、停电范围、用户诉求、责任部门等要素生成结构化摘要。我们跑过一个地市供电公司的存量工单分类准确率从原来的规则引擎的82%提升到93%而且能识别出“频繁停电”“低电压”这类需要升级处理的关键信息。1.2 为什么这时候能落地能力、成本、数据都到位了前几年电网行业也试过知识图谱、专家系统效果都不理想核心原因是文本理解能力不够。大模型把这层天花板打破了开源模型的中文理解和指令跟随能力已经够用不需要等闭源模型。算力门槛也降到了可接受区间。Qwen2.5-7B量化后单张24GB显存的卡就能跑14B量化后单张40GB也能跑一个地市供电公司的信息化预算完全能覆盖。我们实际测试下来7B模型做工单抽取、文本分类这类中低难度任务效果和更大模型差距不大但成本低一个量级。数据条件也比想象中好。电网信息化搞了这么多年PMS2.0、OMS、D5000里面积累了大量高质量数据关键是怎么把这些数据改造成大模型能用的形式。这点我在第3节详细展开——数据加工才是整个项目里最费时间的活。2. 模型选型与本地部署先让模型能跑起来技术选型阶段最容易犯的错是追新追大。电网场景对数据安全要求高模型必须本地部署不能走公网API。所以选型的核心约束是在给定硬件条件下选一个效果够用、能稳定推理、团队能维护的开源模型。2.1 基座模型怎么选显存、量化、场景三要素我建议先按硬件确定参数量级再在同级别里挑效果好的。我们的经验是单张24GB显卡如RTX 3090/4090选7B-9B模型量化单张40GB以上选14B如果只有多张消费级卡优先考虑7B配合张量并行而不是硬上大模型。模型参数量量化后显存占用推荐场景Qwen2.5-7B-Instruct7BAWQ约6-7GB工单分类、要素抽取、常规问答Qwen2.5-14B-Instruct14BAWQ约10-12GB复杂诊断、多步推理、长文档理解glm-4-9b-chat9BAWQ约6GB中文长文本、对话类任务基座模型选Instruct/Chat版本别选Base版本否则还得自己做对齐没必要。量化优先选AWQ或GPTQ推理速度和效果平衡最好。GGUF主要用于Ollama这类CPU/GPU混合部署场景效果略降但在可接受范围。2.2 两种常用部署方式vLLM和Ollama的实战参数如果团队要对外提供服务、有一定并发需求直接用vLLM。它支持连续批处理GPU利用率高而且提供OpenAI兼容接口上层代码不用改。python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-7B-Instruct-AWQ \ --served-model-name qwen7b \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.85 \ --max-model-len 8192 \ --port 8000这里几个参数值得说明。gpu-memory-utilization设置成0.85而不是0.9以上是给CUDA context和偶发的显存碎片留余量生产环境我见过设0.95直接OOM的案例。max-model-len设8192对大部分电网文档够用超过这个长度的文档先切片再进模型不要无脑拉长上下文上下文越长推理越慢、显存占用越大。tensor-parallel-size只有一张卡就设1多卡再调大。如果是内部试点、就几个人用用Ollama更省事。一条命令就能跑起来ollama run qwen2.5:7b-instruct-q4_K_M需要调上下文长度时写一个ModelfileFROM qwen2.5:7b-instruct-q4_K_M PARAMETER temperature 0.2 PARAMETER num_ctx 8192然后ollama create qwen7b-ctx8k -f Modelfile再运行即可。实测下来Ollama在低并发下响应速度够用但单卡并发超过10路时延迟明显上升所以生产环境我最终还是切到了vLLM。3. 把关系数据库里的数据加工成大模型能读懂的文本这是整个项目里最脏最累但回报率最高的环节。电网大量数据存在关系数据库里表结构完整、字段规范但大模型不认识表它只认文本。数据加工本质上就是做一道“转译”把结构化的行和列变成模型能直接理解的自然语言段落。3.1 从表结构到文本一个设备台账的转换示例拿设备台账表举例原始数据长这样device_name,voltage_level,commission_date,last_maintenance,status,manufacturer,rated_capacity。直接让模型读这行记录它很难理解但转换成一段话就完全不一样了。我写了一个通用的转换函数核心思路是把字段名翻译成业务语言模板再填充值def build_device_context(row): return ( f设备名称{row[device_name]} f电压等级{row[voltage_level]} f投运日期{row[commission_date]} f最近检修日期{row[last_maintenance]} f当前运行状态{row[status]} f制造商{row[manufacturer]} f额定容量{row[rated_capacity]} MVA。 )这样每条设备记录就变成了一段完整的描述文本。再配合历史缺陷记录一起组装就能形成“设备画像”。比如某台变压器近三年有三次缺陷记录把缺陷类型、处理措施、结论追加到画像后面模型就能从这些历史数据里学到规律诊断新缺陷时参考价值很大。除了转成文本喂给模型还有一条路是让模型直接生成SQL查询数据库。也就是Text-to-SQL。这个方案更灵活但坑也多——模型生成的SQL偶尔会写错表名、加错过滤条件在电网这种生产系统上直接查库风险偏高。我目前的建议是读操作可以用Text-to-SQL辅助写操作千万别让模型直接碰。3.2 微调数据的准备几百条高质量指令就够了很多人被“大模型需要海量训练数据”这句话吓住了。实际上做业务微调几百到几千条高质量指令就能看到明显效果。我们做工单分类微调时从历史工单里人工筛选了大约800条每条构造“指令输入输出”三元组用LLaMA-Factory走了一遍LoRA微调。数据格式用alpaca格式就行[ { instruction: 请根据以下客户工单内容抽取故障地点、停电范围、用户诉求、责任部门四个要素并输出工单摘要。, input: 客户反映城北街道阳光小区3栋2单元今晚7点开始停电家中老人需要吸氧情绪激动要求尽快恢复供电。, output: 故障地点城北街道阳光小区3栋2单元停电范围阳光小区3栋用户诉求尽快恢复供电并关注老人吸氧需求责任部门城北供电所摘要客户反映阳光小区3栋2单元停电因有老人需吸氧情绪激动已安抚并派单城北供电所优先处理。 } ]做微调数据时有三个心得。第一样例要覆盖高频类型别追求全覆盖80%业务场景就够了剩下的靠RAG兜底第二输出格式要严格统一标点符号都要一样模型才知道格式是硬约束第三每条数据都要人工校验哪怕是从旧系统里批量生成的也要抽查训练集里有一条错误数据模型就能学会一个错误模式而且很难排查。4. 核心代码实现RAG问答链路的完整示例标题里带了[代码]这里我把一套最实用的RAG问答链路完整贴出来。这个链路我们用在规程问答和检修辅助两个场景里稳定跑了半年多。4.1 知识库构建与向量检索先建知识库。文档切块质量直接影响检索效果我试过固定长度切块和按章节切块最终用的是混合策略优先按章节标题切子章节再按300-500字切相邻块保留50-100字重叠防止答案被切断。向量化用bge-large-zh-v1.5中文效果比同尺寸的通用Embedding模型好一截单条文本编码速度也够快。from sentence_transformers import SentenceTransformer import faiss model SentenceTransformer(BAAI/bge-large-zh-v1.5) # chunks 是切好的文档块列表 vectors model.encode(chunks, normalize_embeddingsTrue) # 用内积索引配合归一化向量等价于余弦相似度 index faiss.IndexFlatIP(vectors.shape[1]) index.add(vectors) # 保存索引方便下次加载 faiss.write_index(index, grid_kb.index)这里解释一下为什么用IndexFlatIP而不是IndexIVFFlat。知识库量级在几万条以内时暴力检索的延迟完全可以接受毫秒级返回而IVF索引需要调nprobe参数调不好召回率反而下降。只有知识库超过十万条才值得上IVF或HNSW。检索函数很简单def retrieve(query, topk5): qv model.encode([query], normalize_embeddingsTrue) scores, idx index.search(qv, topk) return [chunks[i] for i in idx[0]]topk我习惯设5。太少了可能漏答案太多了上下文太长反而干扰模型判断5是一个平衡点。4.2 提示词模板与问答主链路检索到相关内容后组装提示词再调用本地vLLM服务。这里用OpenAI SDK因为vLLM的接口就是兼容OpenAI的代码以后切到其他模型服务也不用改。from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY # 本地服务不需要密钥占位即可 ) SYSTEM_PROMPT 你是一名电力系统运维专家请基于给定的资料回答用户问题。资料中未提到的内容请明确回答“资料中未找到相关信息”严禁编造。 def answer(query): contexts retrieve(query) context_text \n\n.join(f【资料{i1}】\n{c} for i, c in enumerate(contexts)) user_content f基于以下资料回答问题。 {context_text} 问题{query} 要求 1. 优先引用资料原文中的信息并标注来自哪份资料 2. 资料未覆盖的内容直接回答“资料中未找到相关信息” 3. 涉及操作步骤时按顺序分条列出 resp client.chat.completions.create( modelqwen7b, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_content} ], temperature0.2, max_tokens512, streamFalse ) return resp.choices[0].message.content代码看起来简单但有几个细节是踩坑踩出来的。temperature设0.2不要用默认的0.7。电网场景要求答案确定性强温度越高越容易出现“自由发挥”式回答。我们做过测试temperature0.7时同一问题问十次有三四次表述不一致降到0.2后基本稳定。提示词里明确要求“资料中未找到相关信息”时直接说明。这是对抗幻觉最便宜有效的手段比换模型有用。代码里没有做多轮对话历史管理因为很多电网问答场景其实是单轮检索问答。如果需要多轮追问把历史消息拼进messages数组即可但注意历史消息会占用上下文窗口超过6轮建议做截断或摘要压缩。5. 常见问题与排查记录都是实测踩过的坑从部署到上线我整理了一份高频问题速查表方便后来者排查。5.1 部署环节的典型问题问题一vLLM启动后显存占用直接打满请求一进来就OOM。排查后发现是gpu-memory-utilization设了0.95CUDA context一加载就爆了。解决办法是把该参数降到0.85同时检查是否多个进程在共用同一张卡。我们的教训是单卡跑一个服务就够了别想着一个卡跑两个模型。问题二请求并发一高单条响应时间从2秒涨到20秒。这不是模型变慢了是vLLM的连续批处理把请求挤到一起了。先在客户端做接口超时排查再用vllm serve的--max-num-seqs参数限制单批次请求数。我们最终设的是32响应时间稳定在3-5秒。问题三模型输出到一半突然截断。两个原因max_tokens设太小或者上下文超过max-model-len导致溢出。把max_tokens从256调到512解决大部分情况剩下的是因为单轮检索拼了太多资料进去压缩topk从5降到3能缓解。5.2 问答效果类问题和优化方向幻觉问题模型回答的内容在资料里根本找不到。这是使用体验最差的问题。我按优先级排查先确认检索是否真的命中了相关资料——打印检索结果看一眼很多“幻觉”其实是检索没召回模型在硬答再确认prompt里是否明确要求未知时拒绝回答最后把temperature调低。做完这三步实测幻觉率能降到5%以下。回答不稳定同样的问题两次回答不一样。排查temperature设置再确认模型是否被做了量化——GGUF Q4量化后输出随机性会比AWQ略大。对回答一致性要求高的场景建议用AWQ量化而不是GGUF。微调后模型变笨做了业务微调之后模型连通用的“你好”都不会回。这是灾难性遗忘。解决思路是微调数据里混入10%-20%的通用对话数据保持模型的通用能力。我们第一次微调就是纯业务数据结果模型能力明显退化后来加了通用数据混合训练才恢复。检索效果差问的问题和知识库内容匹配不上。先换Embedding模型试试bge系列通常比m3e好再优化切块策略太细的块语义不完整太粗的块噪声太多最后检查查询是否需要改写比如用户问“变压器油温高”可以加一步关键词扩展成“变压器 油温 过热 故障”让检索更容易命中。我把这些问题整理成一张速查表贴在这里症状可能原因处理建议显存OOM显存利用率设置过高降到0.85以下避免多进程共用响应慢单批请求数过大调低max-num-seqs输出截断max_tokens或上下文不足增大max_tokens压缩检索块幻觉明显检索召回不足或温度过高检查检索结果temperature降到0.2回答不一致温度过高或GGUF量化降低温度推荐AWQ量化微调后变笨纯业务数据导致遗忘混入10-20%通用数据最后再分享一个经验电网大模型项目不要一上来就搞微调。先做RAG用现成的文档和数据库把场景跑通让业务部门看到效果、提出真实需求然后再针对模型覆盖不了的场景做定向微调。这个顺序能省掉大量返工。我自己也是这么走过来的——第一个版本全靠检索和提示词工程撑起来微调是后面业务量上来才加的。先把链路跑通永远比一开始就追求完美重要。本文还有配套的精品资源点击获取 电网大模型落地实战：从RAG到微调的关键技术与避坑指南
简介电网大模型应用进展代码包整合了行业公开信息的要点以HTML页面形式呈现国网湖南电科院配网视觉大模型、国网与百度合作文心大模型、国网信通电力安监大模型、南网“大瓦特”跨模态大模型及国家能源集团能源通道大模型的落地情况也提及金融、汽车、政务等行业加速复制与中标项目激增的趋势。面向关注AI在能源电力领域应用的开发者、产品经理和行业研究人员可作为行业背景速览或汇报素材。压缩包共3个文件包含HTML说明页、inscode工程配置及gitignore辅助文件整体仅6KB内容集中、便于在线预览。目前已有157人学习适合快速了解大模型从试点走向核心业务场景的路径以及数据治理、逻辑推理优化、工程化适配等挑战为相关项目预研或方案设计提供参考。 电网大模型这个组合一年多前听着还像概念包装但从去年开始我在实际项目里陆续把设备故障诊断、规程问答、工单分析这些场景都跑通了。我的结论很明确电网行业是大模型最容易出实际效果的行业之一——因为电力系统沉淀了大量结构化数据、海量历史文本工单和极高的知识复用需求而大模型最擅长的事情恰好是把文本变成可检索、可调用的能力。这篇文章不聊概念只聊落地场景怎么切、模型怎么选、数据怎么喂、代码怎么写、坑怎么避。适合准备在电力行业引入大模型的技术负责人和一线开发也适合想了解工业大模型真实进展的人。1. 电网大模型在做什么先把需求切成能落地的块很多团队拿到大模型第一反应是“做个聊天机器人”但在电网这种生产型行业聊天机器人是价值最低的形态。真正能落地的是把大模型嵌进现有业务流程里替代原来靠人翻文档、凭经验判断的环节。1.1 三个最容易出效果的应用场景第一个是设备故障诊断与检修辅助。电网设备台账、试验报告、红外测温数据、历史故障记录散落在PMS系统里老师傅退休后这些经验就流失了。大模型能把设备履历和历史故障记录组织成知识库运维人员输入一串巡检编码或者设备编号模型就能返回同类故障的处置历史和检修建议。我们做过一个变压器诊断原型输入“220kV 1号主变油中乙炔超标”模型直接给出色谱分析结论、相关规程条款和近三年同类案例清单现场老师傅看了说“这比我翻系统快”。第二个是调度规程问答与操作辅助。调度规程、操作票、应急预案这些文档动辄几百页调度员值班时查一条规程要翻半天。我们把这些规程文档做成了RAG知识库调度员自然语言提问“线路过载5分钟按规程第一步该怎么处理”模型返回处理步骤并标注依据条文编号。关键点是不让模型自由发挥所有回答必须带出处这样调度员敢用领导也敢推。第三个是客服工单智能分类与摘要。95598工单每天几千条人工分类和填写摘要费时费力。微调后的大模型能自动抽取故障地点、停电范围、用户诉求、责任部门等要素生成结构化摘要。我们跑过一个地市供电公司的存量工单分类准确率从原来的规则引擎的82%提升到93%而且能识别出“频繁停电”“低电压”这类需要升级处理的关键信息。1.2 为什么这时候能落地能力、成本、数据都到位了前几年电网行业也试过知识图谱、专家系统效果都不理想核心原因是文本理解能力不够。大模型把这层天花板打破了开源模型的中文理解和指令跟随能力已经够用不需要等闭源模型。算力门槛也降到了可接受区间。Qwen2.5-7B量化后单张24GB显存的卡就能跑14B量化后单张40GB也能跑一个地市供电公司的信息化预算完全能覆盖。我们实际测试下来7B模型做工单抽取、文本分类这类中低难度任务效果和更大模型差距不大但成本低一个量级。数据条件也比想象中好。电网信息化搞了这么多年PMS2.0、OMS、D5000里面积累了大量高质量数据关键是怎么把这些数据改造成大模型能用的形式。这点我在第3节详细展开——数据加工才是整个项目里最费时间的活。2. 模型选型与本地部署先让模型能跑起来技术选型阶段最容易犯的错是追新追大。电网场景对数据安全要求高模型必须本地部署不能走公网API。所以选型的核心约束是在给定硬件条件下选一个效果够用、能稳定推理、团队能维护的开源模型。2.1 基座模型怎么选显存、量化、场景三要素我建议先按硬件确定参数量级再在同级别里挑效果好的。我们的经验是单张24GB显卡如RTX 3090/4090选7B-9B模型量化单张40GB以上选14B如果只有多张消费级卡优先考虑7B配合张量并行而不是硬上大模型。模型参数量量化后显存占用推荐场景Qwen2.5-7B-Instruct7BAWQ约6-7GB工单分类、要素抽取、常规问答Qwen2.5-14B-Instruct14BAWQ约10-12GB复杂诊断、多步推理、长文档理解glm-4-9b-chat9BAWQ约6GB中文长文本、对话类任务基座模型选Instruct/Chat版本别选Base版本否则还得自己做对齐没必要。量化优先选AWQ或GPTQ推理速度和效果平衡最好。GGUF主要用于Ollama这类CPU/GPU混合部署场景效果略降但在可接受范围。2.2 两种常用部署方式vLLM和Ollama的实战参数如果团队要对外提供服务、有一定并发需求直接用vLLM。它支持连续批处理GPU利用率高而且提供OpenAI兼容接口上层代码不用改。python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-7B-Instruct-AWQ \ --served-model-name qwen7b \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.85 \ --max-model-len 8192 \ --port 8000这里几个参数值得说明。gpu-memory-utilization设置成0.85而不是0.9以上是给CUDA context和偶发的显存碎片留余量生产环境我见过设0.95直接OOM的案例。max-model-len设8192对大部分电网文档够用超过这个长度的文档先切片再进模型不要无脑拉长上下文上下文越长推理越慢、显存占用越大。tensor-parallel-size只有一张卡就设1多卡再调大。如果是内部试点、就几个人用用Ollama更省事。一条命令就能跑起来ollama run qwen2.5:7b-instruct-q4_K_M需要调上下文长度时写一个ModelfileFROM qwen2.5:7b-instruct-q4_K_M PARAMETER temperature 0.2 PARAMETER num_ctx 8192然后ollama create qwen7b-ctx8k -f Modelfile再运行即可。实测下来Ollama在低并发下响应速度够用但单卡并发超过10路时延迟明显上升所以生产环境我最终还是切到了vLLM。3. 把关系数据库里的数据加工成大模型能读懂的文本这是整个项目里最脏最累但回报率最高的环节。电网大量数据存在关系数据库里表结构完整、字段规范但大模型不认识表它只认文本。数据加工本质上就是做一道“转译”把结构化的行和列变成模型能直接理解的自然语言段落。3.1 从表结构到文本一个设备台账的转换示例拿设备台账表举例原始数据长这样device_name,voltage_level,commission_date,last_maintenance,status,manufacturer,rated_capacity。直接让模型读这行记录它很难理解但转换成一段话就完全不一样了。我写了一个通用的转换函数核心思路是把字段名翻译成业务语言模板再填充值def build_device_context(row): return ( f设备名称{row[device_name]} f电压等级{row[voltage_level]} f投运日期{row[commission_date]} f最近检修日期{row[last_maintenance]} f当前运行状态{row[status]} f制造商{row[manufacturer]} f额定容量{row[rated_capacity]} MVA。 )这样每条设备记录就变成了一段完整的描述文本。再配合历史缺陷记录一起组装就能形成“设备画像”。比如某台变压器近三年有三次缺陷记录把缺陷类型、处理措施、结论追加到画像后面模型就能从这些历史数据里学到规律诊断新缺陷时参考价值很大。除了转成文本喂给模型还有一条路是让模型直接生成SQL查询数据库。也就是Text-to-SQL。这个方案更灵活但坑也多——模型生成的SQL偶尔会写错表名、加错过滤条件在电网这种生产系统上直接查库风险偏高。我目前的建议是读操作可以用Text-to-SQL辅助写操作千万别让模型直接碰。3.2 微调数据的准备几百条高质量指令就够了很多人被“大模型需要海量训练数据”这句话吓住了。实际上做业务微调几百到几千条高质量指令就能看到明显效果。我们做工单分类微调时从历史工单里人工筛选了大约800条每条构造“指令输入输出”三元组用LLaMA-Factory走了一遍LoRA微调。数据格式用alpaca格式就行[ { instruction: 请根据以下客户工单内容抽取故障地点、停电范围、用户诉求、责任部门四个要素并输出工单摘要。, input: 客户反映城北街道阳光小区3栋2单元今晚7点开始停电家中老人需要吸氧情绪激动要求尽快恢复供电。, output: 故障地点城北街道阳光小区3栋2单元停电范围阳光小区3栋用户诉求尽快恢复供电并关注老人吸氧需求责任部门城北供电所摘要客户反映阳光小区3栋2单元停电因有老人需吸氧情绪激动已安抚并派单城北供电所优先处理。 } ]做微调数据时有三个心得。第一样例要覆盖高频类型别追求全覆盖80%业务场景就够了剩下的靠RAG兜底第二输出格式要严格统一标点符号都要一样模型才知道格式是硬约束第三每条数据都要人工校验哪怕是从旧系统里批量生成的也要抽查训练集里有一条错误数据模型就能学会一个错误模式而且很难排查。4. 核心代码实现RAG问答链路的完整示例标题里带了[代码]这里我把一套最实用的RAG问答链路完整贴出来。这个链路我们用在规程问答和检修辅助两个场景里稳定跑了半年多。4.1 知识库构建与向量检索先建知识库。文档切块质量直接影响检索效果我试过固定长度切块和按章节切块最终用的是混合策略优先按章节标题切子章节再按300-500字切相邻块保留50-100字重叠防止答案被切断。向量化用bge-large-zh-v1.5中文效果比同尺寸的通用Embedding模型好一截单条文本编码速度也够快。from sentence_transformers import SentenceTransformer import faiss model SentenceTransformer(BAAI/bge-large-zh-v1.5) # chunks 是切好的文档块列表 vectors model.encode(chunks, normalize_embeddingsTrue) # 用内积索引配合归一化向量等价于余弦相似度 index faiss.IndexFlatIP(vectors.shape[1]) index.add(vectors) # 保存索引方便下次加载 faiss.write_index(index, grid_kb.index)这里解释一下为什么用IndexFlatIP而不是IndexIVFFlat。知识库量级在几万条以内时暴力检索的延迟完全可以接受毫秒级返回而IVF索引需要调nprobe参数调不好召回率反而下降。只有知识库超过十万条才值得上IVF或HNSW。检索函数很简单def retrieve(query, topk5): qv model.encode([query], normalize_embeddingsTrue) scores, idx index.search(qv, topk) return [chunks[i] for i in idx[0]]topk我习惯设5。太少了可能漏答案太多了上下文太长反而干扰模型判断5是一个平衡点。4.2 提示词模板与问答主链路检索到相关内容后组装提示词再调用本地vLLM服务。这里用OpenAI SDK因为vLLM的接口就是兼容OpenAI的代码以后切到其他模型服务也不用改。from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY # 本地服务不需要密钥占位即可 ) SYSTEM_PROMPT 你是一名电力系统运维专家请基于给定的资料回答用户问题。资料中未提到的内容请明确回答“资料中未找到相关信息”严禁编造。 def answer(query): contexts retrieve(query) context_text \n\n.join(f【资料{i1}】\n{c} for i, c in enumerate(contexts)) user_content f基于以下资料回答问题。 {context_text} 问题{query} 要求 1. 优先引用资料原文中的信息并标注来自哪份资料 2. 资料未覆盖的内容直接回答“资料中未找到相关信息” 3. 涉及操作步骤时按顺序分条列出 resp client.chat.completions.create( modelqwen7b, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_content} ], temperature0.2, max_tokens512, streamFalse ) return resp.choices[0].message.content代码看起来简单但有几个细节是踩坑踩出来的。temperature设0.2不要用默认的0.7。电网场景要求答案确定性强温度越高越容易出现“自由发挥”式回答。我们做过测试temperature0.7时同一问题问十次有三四次表述不一致降到0.2后基本稳定。提示词里明确要求“资料中未找到相关信息”时直接说明。这是对抗幻觉最便宜有效的手段比换模型有用。代码里没有做多轮对话历史管理因为很多电网问答场景其实是单轮检索问答。如果需要多轮追问把历史消息拼进messages数组即可但注意历史消息会占用上下文窗口超过6轮建议做截断或摘要压缩。5. 常见问题与排查记录都是实测踩过的坑从部署到上线我整理了一份高频问题速查表方便后来者排查。5.1 部署环节的典型问题问题一vLLM启动后显存占用直接打满请求一进来就OOM。排查后发现是gpu-memory-utilization设了0.95CUDA context一加载就爆了。解决办法是把该参数降到0.85同时检查是否多个进程在共用同一张卡。我们的教训是单卡跑一个服务就够了别想着一个卡跑两个模型。问题二请求并发一高单条响应时间从2秒涨到20秒。这不是模型变慢了是vLLM的连续批处理把请求挤到一起了。先在客户端做接口超时排查再用vllm serve的--max-num-seqs参数限制单批次请求数。我们最终设的是32响应时间稳定在3-5秒。问题三模型输出到一半突然截断。两个原因max_tokens设太小或者上下文超过max-model-len导致溢出。把max_tokens从256调到512解决大部分情况剩下的是因为单轮检索拼了太多资料进去压缩topk从5降到3能缓解。5.2 问答效果类问题和优化方向幻觉问题模型回答的内容在资料里根本找不到。这是使用体验最差的问题。我按优先级排查先确认检索是否真的命中了相关资料——打印检索结果看一眼很多“幻觉”其实是检索没召回模型在硬答再确认prompt里是否明确要求未知时拒绝回答最后把temperature调低。做完这三步实测幻觉率能降到5%以下。回答不稳定同样的问题两次回答不一样。排查temperature设置再确认模型是否被做了量化——GGUF Q4量化后输出随机性会比AWQ略大。对回答一致性要求高的场景建议用AWQ量化而不是GGUF。微调后模型变笨做了业务微调之后模型连通用的“你好”都不会回。这是灾难性遗忘。解决思路是微调数据里混入10%-20%的通用对话数据保持模型的通用能力。我们第一次微调就是纯业务数据结果模型能力明显退化后来加了通用数据混合训练才恢复。检索效果差问的问题和知识库内容匹配不上。先换Embedding模型试试bge系列通常比m3e好再优化切块策略太细的块语义不完整太粗的块噪声太多最后检查查询是否需要改写比如用户问“变压器油温高”可以加一步关键词扩展成“变压器 油温 过热 故障”让检索更容易命中。我把这些问题整理成一张速查表贴在这里症状可能原因处理建议显存OOM显存利用率设置过高降到0.85以下避免多进程共用响应慢单批请求数过大调低max-num-seqs输出截断max_tokens或上下文不足增大max_tokens压缩检索块幻觉明显检索召回不足或温度过高检查检索结果temperature降到0.2回答不一致温度过高或GGUF量化降低温度推荐AWQ量化微调后变笨纯业务数据导致遗忘混入10-20%通用数据最后再分享一个经验电网大模型项目不要一上来就搞微调。先做RAG用现成的文档和数据库把场景跑通让业务部门看到效果、提出真实需求然后再针对模型覆盖不了的场景做定向微调。这个顺序能省掉大量返工。我自己也是这么走过来的——第一个版本全靠检索和提示词工程撑起来微调是后面业务量上来才加的。先把链路跑通永远比一开始就追求完美重要。本文还有配套的精品资源点击获取