尧图网站建设 
智能化工大模型 3.0 Pro 最近出现在公开的行业发布信息中合作方涉及大连化物所、科大讯飞和阿里云。只看新闻很容易把它当成一次普通的大模型发布如果放到石化、精细化工、材料工厂的现场去看这个方向真正要解决的问题并不是“能不能回答专业问题”而是“如何让模型在知识高度私有、错误代价极高、数据质量参差不齐的行业里做到答案可追溯、结果可信赖”。这篇文章会把视角从发布会拉回到真实工程。先解释智能化工大模型为什么要走“行业知识库 RAG 行业模型”的路线再用一个最小可运行的化工知识助手作为示例最后讨论微调、GPU 部署、模型评估和上线检查清单。内容更适合正在做化工行业数字化、AI 应用开发和大模型落地选型的读者整体技术链路同样可以迁移到能源、材料、医药等知识密集型行业。1. 先回答一个问题智能化工大模型到底要解决什么1.1 从合作分工看这不是一个“聊天模型”公开信息并没有披露智能化工大模型 3.0 Pro 的完整技术细节但从这次合作方构成可以看出这类产品的形态。科研院所通常负责行业知识梳理、实验数据验证和业务场景定义语音与人工智能服务商提供语言模型基座、行业 SFT 经验和应用系统能力云厂商提供算力资源、模型服务平台、数据存储与推理优化工具。这种合作结构解决的不只是“有没有大模型”的问题而是把三类能力拼成一条可落地的链条行业数据从哪来、怎么清洗、怎么验证模型底座如何针对化工语料调整模型训练完成后部署在哪里推理成本如何控制API 如何接入现有工厂系统。所以智能化工大模型 3.0 Pro 更接近一个“行业解决方案”而不是一个纯文本生成接口。对大多数企业来说关注的重点应该是它提供了哪些知识能力、如何接入现有业务系统、是否支持企业私有化部署以及回答结果能不能追溯到原始资料。具体产品化路径要以官方公布为准但下面讨论的工程结构基本是一致的。1.2 化工场景对通用模型提出了四层挑战化工生产场景和通用办公场景最大的区别是一个问题被答错后果不会停留在聊天框里。气体泄漏后的处置顺序、物料相容性判断、工艺参数调整、设备联锁条件这些问题的答案不仅要求概念正确还对温度、压力、介质、装置状态和现场预案高度敏感。模型如果不知道这些边界条件很容易把“理论上可能”说成“现场可行”。可以把化工场景的难点拆成四层难点实际表现对方案的要求私有知识密度高工艺包、操作规程、事故复盘通常是企业内网资料公开语料里没有必须支持企业自己的知识库检索和增量更新错误容忍度低一个不存在的温度范围可能造成误操作风险回答需要给出依据不允许模型自由发挥专业术语状态敏感同一物质在不同温度和压力下行为可能完全不同问题需要能够关联条件字段不能只看字面相似数据格式复杂大量知识藏在 PDF、扫描件、设备手册和旧系统里需要先做数据抽取、条目化、版本管理再喂给模型通用大模型在开放领域表现再好到了化工企业私域数据面前也会失效因为最关键的信息并没有出现在它的训练语料里。行业大模型的价值不在于把模型做大而在于用行业知识、业务规则和部署机制把模型约束在正确的轨道上。2. 化工大模型落地的第一步知识工程与 RAG2.1 行业数据要先分类再决定要不要进模型很多项目一开始最容易犯的错误是把所有文档堆到一个大模型里指望模型自己“学会”。实际工程里不是所有资料都适合做生成式问答也不是所有资料都应该进入向量数据库。第一步应该是数据分类。可以把化工企业常见的知识源分成几类知识类型典型来源建议处理方式安全与应急处置知识化学品安全说明书、应急处置卡按“场景 动作 注意事项”条目化操作规程与作业标准SOP 文件、岗位操作法按工序或步骤拆分保留版本号设备与仪表知识设备手册、检修记录按设备型号建立文档索引工艺知识工艺卡片、设计说明注意保密边界尽量做权限隔离历史问题库事故复盘、变更记录、异常分析先脱敏再结构化合规与环保要求排放标准、监测规范保留法规名称和发布机构方便追溯分类的目标不是把所有资料都塞进向量库而是先确定每个场景要用哪些知识源。安全知识问答可以使用 RAG实时工艺控制建议则由确定性程序完成不应让大模型直接输出控制动作。2.2 用结构化条目代替整篇文档是知识库最划算的起点处理化工文档时尽量把知识拆成“结构化条目”而不是把整篇 PDF 原文放进检索库。原因有三个大模型对短而清晰的知识片段更稳定检索时可以按字段命中比如先按“介质名称”再按“场景类型”匹配每条内容可以记录来源、适用范围和更新时间方便追溯。下面是一个演示用的知识条目 JSON 结构。注意这是为了展示字段设计思路不是真实处置建议。{ id: demo-safety-001, source: 演示用储罐区泄漏处置卡, type: safety, title: 储罐区泄漏应急处置要点演示, keywords: [储罐, 泄漏, 应急处置, 介质不明], content: 发生泄漏后应先确认泄漏介质并疏散无关人员处置人员按照现场预案佩戴对应的呼吸防护装备避免在未确认介质的情况下盲目靠近或直接关闭阀门。具体技术参数和装备型号以现场处置卡为准。, effective_scope: 仅用于技术示例不构成正式处置建议, updated_at: 2025-01-01 }在这个示例里source记录原始出处keywords帮助词典匹配effective_scope限制知识的适用边界。生产环境中还应该增加department字段表示知识归属部门增加reviewer字段记录审核人。这样做的好处是即使模型回答“根据演示处置卡”人工也能快速回到原始材料核对。2.3 先建 RAG想清楚什么时候才需要微调对多数化工企业来说第一个场景不应该直接进入大模型微调而是先建设 RAG 系统。RAG 全称是 Retrieval-Augmented Generation即检索增强生成。它的核心思路是用户提问后系统先从企业知识库中检索出最相关的文档片段再把问题和片段一起交给大模型生成答案。这样做的好处是模型不需要记住企业私有知识只需要学会“阅读资料并回答”。比如企业更新了一张应急处置卡RAG 系统只需要把新知识条目录入索引下次查询就能用上新内容而微调则需要准备一批训练数据、重新训练并验证更新成本明显更高。因此RAG 更适合知识频繁更新、答案必须可追溯的化工场景。注意不要只看原型能不能启动要看检索召回的片段是否真的对应用户问题。RAG 系统的效果上限通常由召回质量决定而不是由生成模型决定。3. 一个最小可运行的化工知识助手原型3.1 原型目录与技术栈下面示例只解决一个问题给定一段知识库 JSON系统能把用户提问映射到最相关的知识条目并拼装一个大模型可用的上下文。技术栈选择尽量轻量sentence-transformers生成文本向量中文 embedding 模型这里使用 BGE 系列中文模型作为演示faiss-cpu向量检索FastAPI uvicorn提供 APIrequests调用本地或云端的大模型接口。原型目录结构如下chem_demo/ ├── data/ │ └── knowledge.json ├── ingest.py ├── app.py └── requirements.txtdata/knowledge.json存放第 2.2 节格式的知识条目ingest.py负责把知识条目向量化并写入索引app.py提供查询接口。实际项目中可能需要增加数据清洗服务但最小示例能把链路跑清楚。3.2 写入知识库并构建向量索引下面的ingest.py会把每条知识组装成一句完整文本然后编码成向量并写入 faiss 索引。faiss 使用余弦相似度注意向量写入前做归一化。import json import faiss import numpy as np from sentence_transformers import SentenceTransformer def load_knowledge(pathdata/knowledge.json): with open(path, r, encodingutf-8) as f: docs json.load(f) texts [] for item in docs: text ( f标题{item.get(title, )}\n f类型{item.get(type, )}\n f内容{item.get(content, )} ) texts.append(text) return docs, texts def build_index(pathdata/knowledge.json, model_nameBAAI/bge-small-zh-v1.5): docs, texts load_knowledge(path) model SentenceTransformer(model_name) embeddings model.encode(texts, normalize_embeddingsTrue) dim embeddings.shape[1] index faiss.IndexFlatIP(dim) index.add(np.asarray(embeddings, dtypefloat32)) faiss.write_index(index, data/knowledge.index) with open(data/docs_meta.json, w, encodingutf-8) as f: json.dump(docs, f, ensure_asciiFalse, indent2) print(findex size: {len(docs)}, dim: {dim}) if __name__ __main__: build_index()这段代码有两个关键点。第一normalize_embeddingsTrue表示向量长度归一为 1这样 faiss 的IndexFlatIP内积近似等于余弦相似度。第二docs和向量索引分开保存查询时通过docs_meta.json还原原文信息避免向量库返回一堆无法读取的数字。注意如果你使用的 embedding 模型要求 query 加特定前缀编码问题时要按照模型卡要求拼前缀。不同版本的中文 embedding 模型行为不同落地前先做离线效果对比。3.3 查询、检索与生成app.py暴露一个/ask接口。接口先把用户问题编码成向量再从 faiss 中检索最接近的知识条目最后把“问题 检索到的知识片段”一起发给大模型。为了演示方便大模型接口默认使用 OpenAI 兼容协议这样既可对接本地 vLLM 服务也可以对接部分云平台服务。import json import os import faiss import numpy as np import requests from fastapi import FastAPI from pydantic import BaseModel from sentence_transformers import SentenceTransformer DATA_DIR data EMBEDDING_MODEL os.getenv(EMBEDDING_MODEL, BAAI/bge-small-zh-v1.5) API_BASE os.getenv(API_BASE, ) API_KEY os.getenv(API_KEY, ) CHAT_MODEL os.getenv(CHAT_MODEL, chem-assist) app FastAPI() index faiss.read_index(os.path.join(DATA_DIR, knowledge.index)) with open(os.path.join(DATA_DIR, docs_meta.json), r, encodingutf-8) as f: docs_meta json.load(f) embedder SentenceTransformer(EMBEDDING_MODEL) class AskRequest(BaseModel): question: str top_k: int 3 def search(query: str, top_k: int 3): query_vec embedder.encode([query], normalize_embeddingsTrue) scores, ids index.search(np.asarray(query_vec, dtypefloat32), top_k) hits [] for score, idx in zip(scores[0], ids[0]): if idx 0: continue hits.append((docs_meta[idx], float(score))) return hits def call_llm(messages): url API_BASE.rstrip(/) /chat/completions headers {Content-Type: application/json} if API_KEY: headers[Authorization] fBearer {API_KEY} payload { model: CHAT_MODEL, messages: messages, temperature: 0.1, } resp requests.post(url, jsonpayload, headersheaders, timeout30) resp.raise_for_status() return resp.json()[choices][0][message][content] def build_prompt(question: str, hits): context \n\n.join( [f来源{item.get(source, )}\n内容{item.get(content, )} for item, _ in hits] ) system_prompt ( 你是化工行业知识助手。 回答只能来自参考资料。 如果资料不足以回答问题请直接回答‘当前资料无法确认’。 不要补充任何没有出处的工艺参数。 ) user_prompt ( f问题{question}\n\n f参考资料\n{context} ) return [ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ] app.post(/ask) def ask(req: AskRequest): hits search(req.question, req.top_k) if not API_BASE: answer 未配置 API_BASE仅展示检索命中片段供调试。 else: messages build_prompt(req.question, hits) answer call_llm(messages) return { question: req.question, answer: answer, references: [ { source: item.get(source, ), score: score, } for item, score in hits ], }生产实现时不要把 API_BASE 和 API_KEY 写死应该通过环境变量、KMS 或配置中心注入。云平台的大模型服务通常也提供类似的 OpenAI 兼容接口但鉴权头、模型名和 endpoint 可能不一致接入前先参考官方文档确认。3.4 运行验证与预期输出先在本地安装依赖pip install sentence-transformers faiss-cpu fastapi uvicorn requests然后写入知识库python ingest.py预期看到类似输出index size: 3, dim: 768启动 APIuvicorn app:app --host 0.0.0.0 --port 8000再用 curl 测试curl -X POST http://127.0.0.1:8000/ask \ -H Content-Type: application/json \ -d {question: 储罐发生泄漏后处置人员要注意什么, top_k: 2}在没有配置 API_BASE 时接口会返回检索结果便于先确认召回是否准确。预期返回的references应该包含与应急处置知识条目相关的内容并且分数高于其他不相关内容。如果返回的不是预期条目说明知识条目的表述方式或 embedding 模型选择需要调整。4. 行业底座选择开放 API、开源模型私有化还是微调4.1 三条技术路线对比模型底座的选择直接影响智能化工大模型这类应用的成本、合规和效果。通常不能一上来就回答“要不要微调”而要区分三层决策使用 API、私有化部署开源模型、还是微调行业模型。路线优点劣势适用场景通用大模型 API接入快、不需要 GPU 运维私有知识覆盖差、文档外传存在合规风险公开知识整理、非敏感场景体验行业大模型 API内置行业语料开发量少企业私域数据仍需导入和权限管理标准化工知识问答、批量文档处理后接入开源模型 RAG数据不出内网、可控性强需要 GPU 资源和推理优化投入数据保密要求高的生产环境开源模型 微调能改变模型表达风格和专业口径需要高质量训练数据、验证成本高已有大量历史问答对且 RAG 效果不足时智能化工大模型 3.0 Pro 的发布意味着“行业 API”已经是一个可选的底座形态。但对单个工厂来说选用行业 API 前仍然要确认行业知识库是否覆盖自己企业的工艺路线回答是否支持绑定企业私有知识以及在断网、弱网条件下是否仍有兜底方案。4.2 判断是否需要微调不要先微调再看效果RAG 已经能解决大部分“模型不知道企业私有知识”的问题。真正需要微调的场景通常有以下特征已有成规模的“问题 - 标准回答”历史数据比如客服对话、专家答疑记录模型读资料后仍然无法遵循特定回答口径比如必须使用企业统一术语希望模型从“一个文本生成器”稳定成“一个企业问答客服”回答格式要求非常固定例如必须输出 JSON 结构字段名不能变。如果只是为了补充知识优先扩库而不是微调。微调会把知识的“记忆”固化进参数一旦知识过时就要重新训练。RAG 的知识更新只需要更新索引成本低很多。4.3 需要微调时化工语料如何准备微调数据量没有绝对标准。关键不是堆数量而是保证每个问答对都有来源、都有审核状态。常见数据格式如下{ instruction: 储罐区介质不明泄漏时处置人员第一步应该做什么, output: 应先确认泄漏介质并疏散无关人员随后按现场预案佩戴对应的防护装备。具体操作以现场处置卡为准。, reference_doc: demo-safety-001, difficulty: basic }准备数据时要注意三点。第一不要把企业未脱敏的内部事故报告直接用于微调外部模型涉及型号、人员、客户信息的字段都要先做脱敏处理。第二训练集、验证集、测试集要按知识主题分开避免用同一来源的数据既训练又验证。第三高温高压工艺、安全处置相关的问答要单独抽出来做人工审核不能只依赖自动指标。5. 从演示到生产GPU 选型、vLLM 部署与推理优化5.1 生产推理方式先要回答两个问题原型跑通后下一个问题是模型服务部署在哪里。需要先回答两点企业数据能否调用外部云 API团队有没有能力运维 GPU 推理服务。如果数据敏感度很高就选择私有化部署。以下以 vLLM 为例展示如何把一个开源模型部署成 OpenAI 兼容的本地推理服务。vLLM 的优势是吞吐高、支持 PagedAttention 和 Prefix Caching适合并行请求较多的生产场景。5.2 vLLM 部署大模型的最小启动配置部署命令如下。模型路径应该指向提前下载好的本地路径不要在生产环境启动时临时下载大文件。vllm serve /data/models/qwen2.5-14b-instruct-awq \ --served-model-name chem-assist \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 2 \ --port 8000参数含义如下参数作用调优建议/data/models/...模型权重所在目录生产环境应固定版本不要用latest目录--served-model-name对外暴露的模型名上层调用方使用这个名字改名后无需改业务代码--max-model-len最大上下文长度超过实际需求会造成显存浪费先按最长问题估算--gpu-memory-utilization允许占用的显存比例过低会频繁调度过高会影响同卡其他进程--tensor-parallel-size张量并行 GPU 数量模型超过单卡显存时开启多卡间通信要求高--port服务端口建议通过内网网关暴露不要直接开公网如果希望通过 Docker 部署并分配 GPU 资源可以使用 docker compose。镜像 tag 需要提前锁定线上不要使用浮动latestservices: chem-model: image: vllm/vllm-openai:v0.6.3 command: [--model, /models/qwen2.5-14b-instruct-awq, --served-model-name, chem-assist] ports: - 8000:8000 volumes: - /data/models:/models deploy: resources: reservations: devices: - driver: nvidia count: 2 capabilities: [gpu] environment: - NVIDIA_VISIBLE_DEVICES0,1使用 docker compose 的deploy.resources可以限制容器可用的 GPU 数量避免多个模型服务抢占显存。这里的版本号是示例真实项目要以你验证过的镜像版本为准。5.3 GPU 选型建议要看模型量级和并发很多人会直接问“ 智能化工大模型落地：知识库+RAG驱动的工程实践
智能化工大模型 3.0 Pro 最近出现在公开的行业发布信息中合作方涉及大连化物所、科大讯飞和阿里云。只看新闻很容易把它当成一次普通的大模型发布如果放到石化、精细化工、材料工厂的现场去看这个方向真正要解决的问题并不是“能不能回答专业问题”而是“如何让模型在知识高度私有、错误代价极高、数据质量参差不齐的行业里做到答案可追溯、结果可信赖”。这篇文章会把视角从发布会拉回到真实工程。先解释智能化工大模型为什么要走“行业知识库 RAG 行业模型”的路线再用一个最小可运行的化工知识助手作为示例最后讨论微调、GPU 部署、模型评估和上线检查清单。内容更适合正在做化工行业数字化、AI 应用开发和大模型落地选型的读者整体技术链路同样可以迁移到能源、材料、医药等知识密集型行业。1. 先回答一个问题智能化工大模型到底要解决什么1.1 从合作分工看这不是一个“聊天模型”公开信息并没有披露智能化工大模型 3.0 Pro 的完整技术细节但从这次合作方构成可以看出这类产品的形态。科研院所通常负责行业知识梳理、实验数据验证和业务场景定义语音与人工智能服务商提供语言模型基座、行业 SFT 经验和应用系统能力云厂商提供算力资源、模型服务平台、数据存储与推理优化工具。这种合作结构解决的不只是“有没有大模型”的问题而是把三类能力拼成一条可落地的链条行业数据从哪来、怎么清洗、怎么验证模型底座如何针对化工语料调整模型训练完成后部署在哪里推理成本如何控制API 如何接入现有工厂系统。所以智能化工大模型 3.0 Pro 更接近一个“行业解决方案”而不是一个纯文本生成接口。对大多数企业来说关注的重点应该是它提供了哪些知识能力、如何接入现有业务系统、是否支持企业私有化部署以及回答结果能不能追溯到原始资料。具体产品化路径要以官方公布为准但下面讨论的工程结构基本是一致的。1.2 化工场景对通用模型提出了四层挑战化工生产场景和通用办公场景最大的区别是一个问题被答错后果不会停留在聊天框里。气体泄漏后的处置顺序、物料相容性判断、工艺参数调整、设备联锁条件这些问题的答案不仅要求概念正确还对温度、压力、介质、装置状态和现场预案高度敏感。模型如果不知道这些边界条件很容易把“理论上可能”说成“现场可行”。可以把化工场景的难点拆成四层难点实际表现对方案的要求私有知识密度高工艺包、操作规程、事故复盘通常是企业内网资料公开语料里没有必须支持企业自己的知识库检索和增量更新错误容忍度低一个不存在的温度范围可能造成误操作风险回答需要给出依据不允许模型自由发挥专业术语状态敏感同一物质在不同温度和压力下行为可能完全不同问题需要能够关联条件字段不能只看字面相似数据格式复杂大量知识藏在 PDF、扫描件、设备手册和旧系统里需要先做数据抽取、条目化、版本管理再喂给模型通用大模型在开放领域表现再好到了化工企业私域数据面前也会失效因为最关键的信息并没有出现在它的训练语料里。行业大模型的价值不在于把模型做大而在于用行业知识、业务规则和部署机制把模型约束在正确的轨道上。2. 化工大模型落地的第一步知识工程与 RAG2.1 行业数据要先分类再决定要不要进模型很多项目一开始最容易犯的错误是把所有文档堆到一个大模型里指望模型自己“学会”。实际工程里不是所有资料都适合做生成式问答也不是所有资料都应该进入向量数据库。第一步应该是数据分类。可以把化工企业常见的知识源分成几类知识类型典型来源建议处理方式安全与应急处置知识化学品安全说明书、应急处置卡按“场景 动作 注意事项”条目化操作规程与作业标准SOP 文件、岗位操作法按工序或步骤拆分保留版本号设备与仪表知识设备手册、检修记录按设备型号建立文档索引工艺知识工艺卡片、设计说明注意保密边界尽量做权限隔离历史问题库事故复盘、变更记录、异常分析先脱敏再结构化合规与环保要求排放标准、监测规范保留法规名称和发布机构方便追溯分类的目标不是把所有资料都塞进向量库而是先确定每个场景要用哪些知识源。安全知识问答可以使用 RAG实时工艺控制建议则由确定性程序完成不应让大模型直接输出控制动作。2.2 用结构化条目代替整篇文档是知识库最划算的起点处理化工文档时尽量把知识拆成“结构化条目”而不是把整篇 PDF 原文放进检索库。原因有三个大模型对短而清晰的知识片段更稳定检索时可以按字段命中比如先按“介质名称”再按“场景类型”匹配每条内容可以记录来源、适用范围和更新时间方便追溯。下面是一个演示用的知识条目 JSON 结构。注意这是为了展示字段设计思路不是真实处置建议。{ id: demo-safety-001, source: 演示用储罐区泄漏处置卡, type: safety, title: 储罐区泄漏应急处置要点演示, keywords: [储罐, 泄漏, 应急处置, 介质不明], content: 发生泄漏后应先确认泄漏介质并疏散无关人员处置人员按照现场预案佩戴对应的呼吸防护装备避免在未确认介质的情况下盲目靠近或直接关闭阀门。具体技术参数和装备型号以现场处置卡为准。, effective_scope: 仅用于技术示例不构成正式处置建议, updated_at: 2025-01-01 }在这个示例里source记录原始出处keywords帮助词典匹配effective_scope限制知识的适用边界。生产环境中还应该增加department字段表示知识归属部门增加reviewer字段记录审核人。这样做的好处是即使模型回答“根据演示处置卡”人工也能快速回到原始材料核对。2.3 先建 RAG想清楚什么时候才需要微调对多数化工企业来说第一个场景不应该直接进入大模型微调而是先建设 RAG 系统。RAG 全称是 Retrieval-Augmented Generation即检索增强生成。它的核心思路是用户提问后系统先从企业知识库中检索出最相关的文档片段再把问题和片段一起交给大模型生成答案。这样做的好处是模型不需要记住企业私有知识只需要学会“阅读资料并回答”。比如企业更新了一张应急处置卡RAG 系统只需要把新知识条目录入索引下次查询就能用上新内容而微调则需要准备一批训练数据、重新训练并验证更新成本明显更高。因此RAG 更适合知识频繁更新、答案必须可追溯的化工场景。注意不要只看原型能不能启动要看检索召回的片段是否真的对应用户问题。RAG 系统的效果上限通常由召回质量决定而不是由生成模型决定。3. 一个最小可运行的化工知识助手原型3.1 原型目录与技术栈下面示例只解决一个问题给定一段知识库 JSON系统能把用户提问映射到最相关的知识条目并拼装一个大模型可用的上下文。技术栈选择尽量轻量sentence-transformers生成文本向量中文 embedding 模型这里使用 BGE 系列中文模型作为演示faiss-cpu向量检索FastAPI uvicorn提供 APIrequests调用本地或云端的大模型接口。原型目录结构如下chem_demo/ ├── data/ │ └── knowledge.json ├── ingest.py ├── app.py └── requirements.txtdata/knowledge.json存放第 2.2 节格式的知识条目ingest.py负责把知识条目向量化并写入索引app.py提供查询接口。实际项目中可能需要增加数据清洗服务但最小示例能把链路跑清楚。3.2 写入知识库并构建向量索引下面的ingest.py会把每条知识组装成一句完整文本然后编码成向量并写入 faiss 索引。faiss 使用余弦相似度注意向量写入前做归一化。import json import faiss import numpy as np from sentence_transformers import SentenceTransformer def load_knowledge(pathdata/knowledge.json): with open(path, r, encodingutf-8) as f: docs json.load(f) texts [] for item in docs: text ( f标题{item.get(title, )}\n f类型{item.get(type, )}\n f内容{item.get(content, )} ) texts.append(text) return docs, texts def build_index(pathdata/knowledge.json, model_nameBAAI/bge-small-zh-v1.5): docs, texts load_knowledge(path) model SentenceTransformer(model_name) embeddings model.encode(texts, normalize_embeddingsTrue) dim embeddings.shape[1] index faiss.IndexFlatIP(dim) index.add(np.asarray(embeddings, dtypefloat32)) faiss.write_index(index, data/knowledge.index) with open(data/docs_meta.json, w, encodingutf-8) as f: json.dump(docs, f, ensure_asciiFalse, indent2) print(findex size: {len(docs)}, dim: {dim}) if __name__ __main__: build_index()这段代码有两个关键点。第一normalize_embeddingsTrue表示向量长度归一为 1这样 faiss 的IndexFlatIP内积近似等于余弦相似度。第二docs和向量索引分开保存查询时通过docs_meta.json还原原文信息避免向量库返回一堆无法读取的数字。注意如果你使用的 embedding 模型要求 query 加特定前缀编码问题时要按照模型卡要求拼前缀。不同版本的中文 embedding 模型行为不同落地前先做离线效果对比。3.3 查询、检索与生成app.py暴露一个/ask接口。接口先把用户问题编码成向量再从 faiss 中检索最接近的知识条目最后把“问题 检索到的知识片段”一起发给大模型。为了演示方便大模型接口默认使用 OpenAI 兼容协议这样既可对接本地 vLLM 服务也可以对接部分云平台服务。import json import os import faiss import numpy as np import requests from fastapi import FastAPI from pydantic import BaseModel from sentence_transformers import SentenceTransformer DATA_DIR data EMBEDDING_MODEL os.getenv(EMBEDDING_MODEL, BAAI/bge-small-zh-v1.5) API_BASE os.getenv(API_BASE, ) API_KEY os.getenv(API_KEY, ) CHAT_MODEL os.getenv(CHAT_MODEL, chem-assist) app FastAPI() index faiss.read_index(os.path.join(DATA_DIR, knowledge.index)) with open(os.path.join(DATA_DIR, docs_meta.json), r, encodingutf-8) as f: docs_meta json.load(f) embedder SentenceTransformer(EMBEDDING_MODEL) class AskRequest(BaseModel): question: str top_k: int 3 def search(query: str, top_k: int 3): query_vec embedder.encode([query], normalize_embeddingsTrue) scores, ids index.search(np.asarray(query_vec, dtypefloat32), top_k) hits [] for score, idx in zip(scores[0], ids[0]): if idx 0: continue hits.append((docs_meta[idx], float(score))) return hits def call_llm(messages): url API_BASE.rstrip(/) /chat/completions headers {Content-Type: application/json} if API_KEY: headers[Authorization] fBearer {API_KEY} payload { model: CHAT_MODEL, messages: messages, temperature: 0.1, } resp requests.post(url, jsonpayload, headersheaders, timeout30) resp.raise_for_status() return resp.json()[choices][0][message][content] def build_prompt(question: str, hits): context \n\n.join( [f来源{item.get(source, )}\n内容{item.get(content, )} for item, _ in hits] ) system_prompt ( 你是化工行业知识助手。 回答只能来自参考资料。 如果资料不足以回答问题请直接回答‘当前资料无法确认’。 不要补充任何没有出处的工艺参数。 ) user_prompt ( f问题{question}\n\n f参考资料\n{context} ) return [ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ] app.post(/ask) def ask(req: AskRequest): hits search(req.question, req.top_k) if not API_BASE: answer 未配置 API_BASE仅展示检索命中片段供调试。 else: messages build_prompt(req.question, hits) answer call_llm(messages) return { question: req.question, answer: answer, references: [ { source: item.get(source, ), score: score, } for item, score in hits ], }生产实现时不要把 API_BASE 和 API_KEY 写死应该通过环境变量、KMS 或配置中心注入。云平台的大模型服务通常也提供类似的 OpenAI 兼容接口但鉴权头、模型名和 endpoint 可能不一致接入前先参考官方文档确认。3.4 运行验证与预期输出先在本地安装依赖pip install sentence-transformers faiss-cpu fastapi uvicorn requests然后写入知识库python ingest.py预期看到类似输出index size: 3, dim: 768启动 APIuvicorn app:app --host 0.0.0.0 --port 8000再用 curl 测试curl -X POST http://127.0.0.1:8000/ask \ -H Content-Type: application/json \ -d {question: 储罐发生泄漏后处置人员要注意什么, top_k: 2}在没有配置 API_BASE 时接口会返回检索结果便于先确认召回是否准确。预期返回的references应该包含与应急处置知识条目相关的内容并且分数高于其他不相关内容。如果返回的不是预期条目说明知识条目的表述方式或 embedding 模型选择需要调整。4. 行业底座选择开放 API、开源模型私有化还是微调4.1 三条技术路线对比模型底座的选择直接影响智能化工大模型这类应用的成本、合规和效果。通常不能一上来就回答“要不要微调”而要区分三层决策使用 API、私有化部署开源模型、还是微调行业模型。路线优点劣势适用场景通用大模型 API接入快、不需要 GPU 运维私有知识覆盖差、文档外传存在合规风险公开知识整理、非敏感场景体验行业大模型 API内置行业语料开发量少企业私域数据仍需导入和权限管理标准化工知识问答、批量文档处理后接入开源模型 RAG数据不出内网、可控性强需要 GPU 资源和推理优化投入数据保密要求高的生产环境开源模型 微调能改变模型表达风格和专业口径需要高质量训练数据、验证成本高已有大量历史问答对且 RAG 效果不足时智能化工大模型 3.0 Pro 的发布意味着“行业 API”已经是一个可选的底座形态。但对单个工厂来说选用行业 API 前仍然要确认行业知识库是否覆盖自己企业的工艺路线回答是否支持绑定企业私有知识以及在断网、弱网条件下是否仍有兜底方案。4.2 判断是否需要微调不要先微调再看效果RAG 已经能解决大部分“模型不知道企业私有知识”的问题。真正需要微调的场景通常有以下特征已有成规模的“问题 - 标准回答”历史数据比如客服对话、专家答疑记录模型读资料后仍然无法遵循特定回答口径比如必须使用企业统一术语希望模型从“一个文本生成器”稳定成“一个企业问答客服”回答格式要求非常固定例如必须输出 JSON 结构字段名不能变。如果只是为了补充知识优先扩库而不是微调。微调会把知识的“记忆”固化进参数一旦知识过时就要重新训练。RAG 的知识更新只需要更新索引成本低很多。4.3 需要微调时化工语料如何准备微调数据量没有绝对标准。关键不是堆数量而是保证每个问答对都有来源、都有审核状态。常见数据格式如下{ instruction: 储罐区介质不明泄漏时处置人员第一步应该做什么, output: 应先确认泄漏介质并疏散无关人员随后按现场预案佩戴对应的防护装备。具体操作以现场处置卡为准。, reference_doc: demo-safety-001, difficulty: basic }准备数据时要注意三点。第一不要把企业未脱敏的内部事故报告直接用于微调外部模型涉及型号、人员、客户信息的字段都要先做脱敏处理。第二训练集、验证集、测试集要按知识主题分开避免用同一来源的数据既训练又验证。第三高温高压工艺、安全处置相关的问答要单独抽出来做人工审核不能只依赖自动指标。5. 从演示到生产GPU 选型、vLLM 部署与推理优化5.1 生产推理方式先要回答两个问题原型跑通后下一个问题是模型服务部署在哪里。需要先回答两点企业数据能否调用外部云 API团队有没有能力运维 GPU 推理服务。如果数据敏感度很高就选择私有化部署。以下以 vLLM 为例展示如何把一个开源模型部署成 OpenAI 兼容的本地推理服务。vLLM 的优势是吞吐高、支持 PagedAttention 和 Prefix Caching适合并行请求较多的生产场景。5.2 vLLM 部署大模型的最小启动配置部署命令如下。模型路径应该指向提前下载好的本地路径不要在生产环境启动时临时下载大文件。vllm serve /data/models/qwen2.5-14b-instruct-awq \ --served-model-name chem-assist \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 2 \ --port 8000参数含义如下参数作用调优建议/data/models/...模型权重所在目录生产环境应固定版本不要用latest目录--served-model-name对外暴露的模型名上层调用方使用这个名字改名后无需改业务代码--max-model-len最大上下文长度超过实际需求会造成显存浪费先按最长问题估算--gpu-memory-utilization允许占用的显存比例过低会频繁调度过高会影响同卡其他进程--tensor-parallel-size张量并行 GPU 数量模型超过单卡显存时开启多卡间通信要求高--port服务端口建议通过内网网关暴露不要直接开公网如果希望通过 Docker 部署并分配 GPU 资源可以使用 docker compose。镜像 tag 需要提前锁定线上不要使用浮动latestservices: chem-model: image: vllm/vllm-openai:v0.6.3 command: [--model, /models/qwen2.5-14b-instruct-awq, --served-model-name, chem-assist] ports: - 8000:8000 volumes: - /data/models:/models deploy: resources: reservations: devices: - driver: nvidia count: 2 capabilities: [gpu] environment: - NVIDIA_VISIBLE_DEVICES0,1使用 docker compose 的deploy.resources可以限制容器可用的 GPU 数量避免多个模型服务抢占显存。这里的版本号是示例真实项目要以你验证过的镜像版本为准。5.3 GPU 选型建议要看模型量级和并发很多人会直接问“