1. 项目缘起与整体设计思路1.1 为什么要在医院场景下做垂域大模型先说说这个项目的出发点。大型三甲医院的网络环境和一般企业、互联网公司完全不是一个量级的东西。我参与过几个医疗信息化项目最直观的感受就是医院网络是一个“高复杂度、高耦合、高合规要求”的三高环境。门诊、住院、检验、影像、手术、药品、财务、科研几十上百套业务系统跑在同一张网上中间还夹着大量医疗设备CT、MRI、监护仪、输液泵这些设备很多跑的还是老旧的嵌入式系统补丁打不了、agent装不上。通用大模型在这个场景下能干什么你问它“医院网络怎么防勒索”它能给你背出一堆教科书式的答案但具体到“某台影像归档系统为什么在凌晨三点和备份服务器之间产生异常流量”它就抓瞎了。原因很简单通用模型没有医疗业务的上下文不知道PACS的DICOM协议长什么样不知道HIS的数据库表结构更不知道医院里“业务连续性”这四个字的分量——门诊停摆一小时背后是几百号病人堵在走廊里。所以这个项目的核心命题就一句话把网络安全领域的专业知识和医院业务的领域知识一起灌进一个垂域大模型里让它能看懂医院网络里到底发生了什么并且给出可执行的判断。1.2 整体架构的选型考量我们最终确定的架构是“基座模型 领域微调 检索增强 工具调用”的四层结构。为什么这么设计我逐个说。基座模型的选择上我们没有一上来就追求参数最大的。原因很实际医院内网是物理隔离的模型必须能私有化部署推理成本要可控。我们对比了几个开源基座最终选了一个中等参数规模、中文能力扎实、支持长上下文的版本。参数太大推理延迟高安全运营人员等一个告警分析等三十秒体验就崩了参数太小领域知识灌不进去微调效果差。这个平衡点是我们拿真实告警数据反复测出来的。领域微调解决的是“懂行话”的问题。我们收集了医院安全运营团队过去几年的工单记录、告警处置日志、应急预案文档还有医疗行业的安全标准文本构建了一个几万条规模的指令微调数据集。这里有个坑不能直接把原始日志丢进去日志里全是IP、端口、设备型号模型学不到通用规律。我们做了一层抽象把“某台设备在某个时间段产生了某种类型的异常流量”这种模式提取出来再配上处置结论这样模型学到的是判断逻辑而不是死记硬背。检索增强解决的是“知识更新”的问题。安全威胁天天变微调不可能天天做。我们把最新的漏洞库、威胁情报、医院内部的资产台账、网络拓扑说明全部做成向量索引模型回答前先去检索相关片段再基于片段生成答案。这样既保证了时效性又避免了模型胡编。工具调用解决的是“动手能力”的问题。模型不能只会说还得能查。我们给它接了几个内部API查资产信息的、查历史告警的、查当前网络流量的。模型判断需要更多信息时可以主动调用这些工具拿到结果再继续分析。这一步是整个项目从“玩具”变成“工具”的关键。1.3 和通用方案的本质区别很多人会问直接用通用大模型加个提示词不就行了我实测下来的结论是不行差得远。通用模型对医院网络的理解停留在“医院网络很重要要好好保护”这种层面。你给它一段真实的NetFlow数据它连哪个是PACS服务器、哪个是办公终端都分不清。垂域模型的价值在于它知道影像科室的流量特征是什么样知道凌晨批量传输大概率是备份任务而不是攻击知道门诊高峰期任何网络抖动都必须优先保业务而不是先隔离。这个区别本质上就是“有领域常识”和“没有领域常识”的区别。而领域常识恰恰是医院安全运营中最值钱的东西。2. 核心细节解析与实操要点2.1 数据准备医院安全语料怎么攒数据是这个项目的地基地基不牢后面全白搭。我按数据来源分几类说。第一类是结构化日志。防火墙、IDS、终端防护、流量分析平台这些设备每天产生海量日志。但原始日志不能直接用需要做归一化。我们定义了一套统一的字段规范把不同厂商的日志映射到同一套schema上时间、源IP、目的IP、源端口、目的端口、协议、事件类型、严重级别、原始载荷摘要。这一步工作量巨大但值得。归一化之后模型看到的是一致的数据格式学习效率高很多。第二类是半结构化工单。安全运营人员处理告警时填的工单里面有处置描述、判断依据、最终结论。这些文本是宝贵的“人类判断”数据。我们做的是把工单和对应的原始告警关联起来形成“输入-输出”对。这里要注意脱敏患者信息、医护人员个人信息绝对不能进训练集。第三类是知识文档。包括医院网络拓扑说明、资产清单、应急预案、等保测评报告、医疗行业安全规范。这些文档我们做了分块和向量化用于检索增强。分块策略上我们按语义段落切每块控制在500到800字重叠100字保证检索时不会丢上下文。第四类是模拟数据。真实攻击数据在医院环境里是稀缺的我们搭建了一个仿真环境用攻击模拟工具生成了一些典型攻击场景的流量和日志比如横向移动、数据外传、勒索软件加密行为。这些数据补充了真实数据的不足。注意所有数据在进入训练流程前必须经过严格的脱敏和合规审查。医院数据涉及患者隐私任何环节都不能掉以轻心。我们专门设了一个数据合规岗每一批数据都要签字确认才能流转。2.2 微调策略怎么让模型学会“医院思维”微调不是把数据丢进去跑一遍就完事。我们踩过的坑这里详细说。指令数据的构造上我们采用了“场景描述 问题 思考过程 最终答案”的四段式结构。思考过程这一项很关键它让模型学会一步步推理而不是直接蹦答案。比如一个告警分析样本思考过程会写“首先看源IP属于影像科室网段目的IP是备份服务器时间是凌晨两点符合备份窗口流量特征是大量小包可能是DICOM传输。综合判断为正常备份行为建议观察而非阻断。”这种推理链模型学多了之后遇到新告警也能自己走一遍类似流程。训练参数的设置上我们用了LoRA低秩适配而不是全量微调。原因有两个一是全量微调成本太高二是LoRA可以针对不同任务训练多个适配器灵活切换。学习率我们设的是1e-4batch size根据显存调整训练轮数控制在3到5轮。轮数太多会过拟合模型会把训练集里的具体IP都背下来泛化能力反而下降。评估集的构建上我们留出了20%的数据作为验证集另外还专门构造了一个“对抗测试集”里面是一些容易混淆的样本比如“看起来像攻击的正常业务”和“看起来像正常业务的攻击”。这个测试集最能检验模型是不是真的学到了领域知识而不是在背答案。2.3 检索增强的工程实现检索增强这块我们用的是向量数据库加关键词检索的混合方案。纯向量检索有时候会漏掉一些关键术语比如具体的CVE编号这时候关键词检索就能补上。向量化模型的选择上我们试了几个中文embedding模型最终选了一个在安全领域文本上表现较好的。评估标准很简单拿一批安全问题看检索出来的文档是不是相关。这个没有捷径就是人工标注一批测试query然后算召回率和准确率。检索策略上我们做了两层第一层是粗排用向量相似度召回Top 50第二层是精排用一个小的交叉编码器对Top 50重新打分选出Top 5送给大模型。这样既保证了速度又保证了精度。上下文拼接上我们把检索到的文档片段和用户问题拼在一起但要注意长度控制。太长了模型处理慢太短了信息不够。我们的经验是检索片段总长度控制在2000字以内加上系统提示词和用户问题总输入不超过模型上下文窗口的70%留出空间给模型生成。2.4 工具调用的接口设计工具调用这块核心是让模型知道“什么时候该调工具”和“怎么调”。我们定义了几个工具query_asset_info查资产、query_alert_history查历史告警、query_network_flow查实时流量、query_vulnerability查漏洞信息。每个工具都有明确的描述和参数说明模型根据当前对话上下文决定是否调用。这里有个细节工具调用的结果不能直接丢给用户模型需要把结果消化后再组织语言输出。我们训练模型时专门加了一批“工具调用后总结”的样本让模型学会把原始数据转化成人类可读的分析结论。实操心得工具调用的失败处理很重要。如果API超时或者返回空模型不能卡死要有降级策略。我们的做法是工具调用失败时模型基于已有信息给出一个“信息不足建议人工核查”的回复而不是胡编一个结果。3. 实操过程与核心环节实现3.1 环境搭建与基座部署整个系统部署在医院内网的GPU服务器上物理隔离不连外网。硬件配置上我们用了两张推理卡显存够跑中等参数模型。操作系统是Linux推理框架用的是支持量化推理的那套方案把模型量化到INT8推理速度提升明显精度损失在可接受范围内。部署步骤大致如下先装驱动和推理框架然后拉取基座模型权重做量化转换再加载LoRA适配器。这里要注意版本兼容性推理框架和模型权重的版本必须匹配不然会报各种奇怪的错误。我们第一次部署时就因为版本不匹配折腾了大半天。服务化方面我们用了一个轻量级的API框架把模型封装成HTTP接口供上层应用调用。接口设计上支持流式输出这样安全运营人员能看到模型“边想边说”体验更好。3.2 微调训练全流程训练流程我按步骤拆开说。第一步数据清洗。把原始日志里的噪声去掉比如重复告警、测试数据、明显的误报。这一步用规则加人工抽检结合的方式做。第二步数据标注。把清洗后的数据整理成指令格式每条样本包含场景描述、问题、思考过程、答案。标注工作量很大我们前后投入了几个月时间边标边迭代标注规范。第三步数据划分。按时间划分而不是随机划分。为什么因为安全威胁有时序性随机划分会导致训练集和验证集有信息泄露。按时间划分用早期数据训练后期数据验证更能反映模型在真实场景下的表现。第四步训练配置。LoRA的秩设为8alpha设为16dropout 0.1。优化器用AdamW学习率1e-4warmup比例0.03。这些参数是反复实验调出来的不一定最优但稳定可用。第五步训练监控。我们盯着训练loss和验证loss如果验证loss开始上升就说明过拟合了要早停。另外还监控生成样本的质量每隔一定步数就抽样看模型输出确保没有跑偏。第六步模型合并与导出。训练完成后把LoRA权重合并回基座模型导出成推理格式。这一步要注意精度合并时用fp16导出时再量化。3.3 检索库的构建与更新检索库的构建分三步文档收集、分块向量化、索引构建。文档收集上我们把医院内部的资产台账、网络拓扑、安全策略、应急预案全部整理成Markdown格式方便后续处理。外部知识方面收集了公开的漏洞库、威胁情报摘要、安全最佳实践文档。分块向量化上用前面说的分块策略切分然后调embedding接口生成向量。这里要注意embedding模型和检索时的query编码必须用同一个模型不然向量空间不一致检索结果会乱。索引构建上我们用了支持混合检索的向量数据库同时建了向量索引和关键词索引。更新策略上每周做一次增量更新把新的漏洞和情报加进去。全量重建成本高增量更新够用。3.4 工具接口的开发与联调工具接口开发本身不复杂就是几个REST API。复杂的是和模型的联调。模型调用工具时输出的是一个结构化的JSON包含工具名和参数。我们的服务端解析这个JSON调用对应API把结果返回给模型。这里有个坑模型有时候会输出格式不对的JSON比如多了个逗号或者少了引号。我们的处理方式是加一层容错解析解析失败时给模型返回一个错误提示让它重新生成。联调阶段我们构造了一批测试用例覆盖各种工具调用场景单工具调用、多工具连续调用、工具调用失败、工具返回空结果。每个场景都验证模型的反应是否符合预期。实操心得工具调用的超时设置很关键。我们设的是5秒超过就返回超时错误。为什么是5秒因为安全运营人员等10秒以上就会觉得系统卡了体验直线下降。5秒是个平衡点大部分查询能在5秒内返回。3.5 效果评估与迭代评估分自动评估和人工评估两块。自动评估上我们用了几个指标告警分类准确率、处置建议采纳率、工具调用成功率、平均响应时间。这些指标每周统计一次画成趋势图看模型是在进步还是退步。人工评估上让安全运营团队实际用收集反馈。反馈分三类模型判断对的、判断错的、判断不全的。错的和不全的样本我们分析原因是数据问题还是模型问题然后针对性改进。迭代节奏上我们保持每两周一个小版本每月一个大版本。小版本主要是修bug和调提示词大版本才动模型和检索库。这样既保证了迭代速度又不会太频繁导致不稳定。4. 常见问题与排查技巧实录4.1 模型输出不稳定怎么办这是最常见的问题。同一个问题问两次答案不一样。原因通常是解码策略的问题。我们的解决方案是把temperature调低设到0.1到0.3之间同时用top-p采样p设0.9。这样输出稳定很多又不会太死板。另一个原因是检索结果不稳定。如果每次检索到的文档片段不一样模型基于不同上下文答案自然不一样。我们的做法是对检索结果做缓存同一个query在短时间内命中缓存保证上下文一致。4.2 模型胡编乱造怎么治大模型幻觉是通病。在医院安全场景下胡编一个不存在的漏洞或者错误的处置建议后果可能很严重。我们的治理手段有三层第一层是检索增强让模型基于真实文档回答而不是凭记忆第二层是提示词约束在系统提示里明确写“如果信息不足请回答‘需要更多信息’不要猜测”第三层是后置校验对模型输出的关键信息如CVE编号、IP地址、端口号做格式和存在性校验校验不通过就拦截。实测下来这三层组合能把幻觉率压到很低但做不到零。所以我们的定位始终是“辅助分析”最终决策还是由人来做。4.3 推理速度慢怎么优化推理速度慢的原因通常有几个模型太大、量化不够、并发太高、硬件瓶颈。我们的优化路径是先做量化INT8量化后速度提升明显然后做请求批处理把多个并发请求合并成一个batch推理吞吐量上去了再然后做缓存常见问题的答案缓存起来直接返回最后才是考虑换硬件。顺序很重要先软后硬性价比高。4.4 领域知识更新不及时怎么破安全威胁天天变模型知识更新是个持续挑战。我们的做法是微调负责“思维方式”检索负责“具体知识”。新出现的漏洞和攻击手法通过更新检索库来覆盖不需要重新微调模型。只有当出现全新的攻击范式模型的理解框架跟不上了才考虑重新微调。检索库的更新我们做成了半自动的新漏洞信息公开后自动抓取摘要人工审核后入库。这样既保证了时效又保证了质量。4.5 常见问题速查表问题现象可能原因排查方向解决手段模型回答与问题无关检索结果不相关检查embedding模型和检索query调整检索策略加关键词过滤模型输出格式错乱提示词不清晰检查系统提示词明确输出格式要求加示例工具调用失败API超时或参数错误查看服务端日志加超时重试加参数校验推理延迟高并发高或模型大监控GPU利用率和队列长度量化、批处理、加缓存模型判断偏差大训练数据分布不均分析评估集错误样本补充稀缺场景数据重新微调检索不到相关内容索引未更新或分块不合理检查索引更新记录和分块策略增量更新索引调整分块大小避坑技巧每次模型更新或检索库更新后一定要跑一遍回归测试集。我们有一次更新检索库不小心把一批旧文档删了导致模型对某些历史攻击手法的回答质量下降。回归测试能及时发现这类问题。5. 落地效果与个人体会这套系统在医院内网跑了一段时间实际效果我客观说几句。好的方面安全运营人员的告警处理效率有提升尤其是那些需要查资产、查历史、查漏洞的重复性工作模型能帮着快速定位。新入职的安全分析师上手更快因为模型能给出推理过程相当于一个随时在线的“老师傅”。不足的方面模型对全新攻击手法的判断还是弱毕竟训练数据里没有。另外模型对业务影响的理解还不够细腻有时候会建议隔离某台设备但没考虑到这台设备正在支撑门诊业务。这类建议需要人工把关。我个人最大的体会是垂域大模型的价值不在于替代人而在于把领域专家的经验沉淀下来让更多人能快速达到及格线以上的判断水平。医院安全运营最缺的不是工具是懂医院业务又懂安全的人。这个模型某种程度上是在补这个缺口。后续可以扩展的方向一是接入更多业务系统的上下文让模型对“业务影响”的判断更准二是做多模态把网络拓扑图、流量图也纳入理解范围三是做主动巡检让模型定期扫描内网主动发现异常而不是等着人来问。最后分享一个小技巧训练垂域模型时不要追求一步到位。先做一个能跑通的最小版本哪怕效果一般先让业务方用起来收集真实反馈再迭代。我们第一版模型效果其实挺糙的但正是那些真实使用中的吐槽和需求指引了后续的优化方向。闭门造车永远造不出好用的东西。
