尧图网站建设 尧图网络
  • 首页
  • 关于我们
  • 服务项目
  • 案例展示
  • 建站流程
  • 资讯中心
  • 联系我们
首页/资讯中心/详情

医学大模型微调前的数据处理

医学大模型微调前的数据处理
📅 发布时间:2026/6/20 16:30:02

由于医学行业的特殊性,不同病的病理和发病情况的特殊性,大模型是无法替代医生进行就诊的,即使是不同的病对应不同的病理和发病情况相关药物治疗的量和疗程都是无法固定的,同时由于医学内容太多,太多的病同时都有不同的病理,同时医学领域中大模型的幻觉后果是非常严重的,这里需要严格处理同时需要数据量稍大一点,因此这里的微调主要是想做一个通用医学知识的医学大模型微调,更着重于为人们进行医学知识的科普和健康生活规划以及为用户"预诊"可能的疾病然后引导用户线下就医而非直接根据用户提供的信息告诉用户你得的什么病该怎么吃药,首先我们要用垂直领域的数据进行LORA微调1.需要对格式进行处理:将自由文本处理为ChatML文本,2:需要对文本的内容进行处理,需要保证我们训练数据的质量以及不能有一些垃圾甚至是恶意不好的内容。3.(由于医学领域数据的特殊性处理需要更加严谨和小心)得到处理后的数据我们还需要评估和人工复核(此文仅为个人的一些想法,更多的可以参考相关医学大模型论文中的内容和一些其他的方法进行优化和升级)(详细代码请见代码仓):

首先是我代码中的预处理代码的架构:

┌──────────────────────────┐
│ 原始医学文本 │
│ │
└───────────┬──────────────┘
│
▼
┌──────────────────────────┐
│ Block 解析模块 │
│ parse_blocks() │
│ │
│ ┌─ Description │
│ └─ Dialogue │
└───────────┬──────────────┘
│
▼
┌──────────────────────────┐
│ 结构化对话构建模块 │
│ convert_record() │
│ │
│ ├─ 系统提示 system │
│ ├─ 描述 → QA 转换 │
│ │ convert_description │
│ └─ 对话解析 parse_dialog │
└───────────┬──────────────┘
│
▼
┌──────────────────────────┐
│ ChatML 数据 │
│ [{"role","content"}...] │
└───────────┬──────────────┘
│
▼
┌──────────────────────────┐
│ 规则级去重 │
│ hash_dedup() │
│ (MD5 文本完全一致) │
└───────────┬──────────────┘
│
▼
┌──────────────────────────┐
│ 语义级去重(核心难点) │
│ semantic_deduplicate() │
│ │
│ ├─ 向量编码 │
│ │ SentenceTransformer │
│ ├─ 分批处理 BATCH │
│ ├─ 滑窗 WINDOW │
│ ├─ FAISS 相似度搜索 │
│ └─ 阈值过滤 SIM ≥ 0.97 │
└───────────┬──────────────┘
│
▼
┌──────────────────────────┐
│ 高质量医学对话数据集 │
│ medical_data.jsonl │
└──────────────────────────┘
这里我主要是用正则表达式去除了文本中杂糅的内容,同时把文本转化成chatml格式,然后对原始文件进行了预处理首先是MD5哈希对文本中完全重复的内容进行去除,然后用语义相似度去重(这里由于医学数据的特殊性我选择了比较高的阈值:由于病人的发病情况可能类似但是可能病理不同(比如病人发烧的温度可能一个38度一个39度),对这部分数据数据应该进行保留,这里需要去除的内容是语义上完全相同的陈述:比如病人说:我头有点晕和我感觉我有点头晕这类陈述)同时由于数据的庞大,我利用分批处理和每次选择该位置前2000作为滑动窗口防止漏掉重复的内容,并利用Faiss相似度搜索进行去重。

比较好的点:分批处理和滑动窗口去重,考虑阈值问题

接下来就是对生成的内容进行过滤和评估,并进行人工校验,这是我的架构。

┌─────────────────────────────────────┐
│ 数据输入层 │
│ ChatML / JSONL 对话数据 │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ Stage 1:规则过滤层 │
│ - 长度合法性 │
│ - 垃圾文本 / 隐私 / 链接 │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ Stage 2:医学风险识别层 │
│ - SAFE / CAUTION / RESTRICT / CRISIS │
│ - 基于规则的风险信号检测 │
└─────────────────────────────────────┘
│ │ │
│ │ └──▶ CRISIS → 人工兜底
│ │
│ └──▶ RESTRICT → 安全回复改写 → 不可训练集
│
▼
┌─────────────────────────────────────┐
│ Stage 3:语言质量评估层 │
│ - 困惑度(PPL) │
│ - 低质量 / 噪声文本剔除 │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ Stage 4:数据分流层 │
│ - 可训练数据 │
│ - 不可训练但可留存 │
│ - 高危人工复查 │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ 统计 & 评估报告层 │
│ - 各阶段命中率 │
│ - PPL 分布 │
│ - 人工成本评估依据 │
└─────────────────────────────────────┘

一开始我的想法是常规做法:

1.规则过滤(对文本长度小于5和大于1000的去除,由于数据来源可能有网络爬虫和我们用大模型得到的数据:可能有垃圾信息比如邮箱,可能有密码和身份证信息,所以也用正则表达式进行去除)

2.有害内容检测

3.PPL困惑度检测

但是后面我思考了一下这样是单一且片面的,没有考虑到医学的特殊性,比如可能用户会有失血过多,文本中可能会有死亡这类词,这样很容易被识别为有害内容,所以这样做是不对的,这样生成的数据会让大模型觉得外面的世界是安全的,对于用户的回答可能无法很好地起到预诊和引导就医的作用。

所以这里的操作我加入了医学风险识别层,处理比较严格同时加入人工审核模块以及将标签中为CAUTION和RESTRICT的内容用日志保留以便人工复核,我们将CAUTION和RESTRICT的内容替换为引导就医内容(这部分内容可能涉及引导用户用药和自我救治,但是前面由于不同病不同病理是很繁杂的,大模型只能辅助就诊不能越俎代庖地为用户就诊)这样一方面可以防止疏漏另一方面还可以对我们便签中为CAUTION和RESTRICT的内容进行复核。以下为我的架构

┌─────────────────────────────────────┐
│ 数据输入层 │
│ ChatML / JSONL 对话数据 │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ Stage 1:规则过滤层 │
│ - 长度合法性 │
│ - 垃圾文本 / 隐私 / 链接 │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ Stage 2:医学风险识别层 │
│ - SAFE / CAUTION / RESTRICT / CRISIS │
│ - 基于规则的风险信号检测 │
└─────────────────────────────────────┘
│ │ │
│ │ └──▶ CRISIS → 人工兜底
│ │
│ └──▶ RESTRICT → 安全回复改写 → 不可训练集
│
▼
┌─────────────────────────────────────┐
│ Stage 3:语言质量评估层 │
│ - 困惑度(PPL) │
│ - 低质量 / 噪声文本剔除 │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ Stage 4:数据分流层 │
│ - 可训练数据 │
│ - 不可训练但可留存 │
│ - 高危人工复查 │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ 统计 & 评估报告层 │
│ - 各阶段命中率 │
│ - PPL 分布 │
│ - 人工成本评估依据 │
└─────────────────────────────────────┘

相关新闻

  • 国产加密算法支持:SM2/SM3/SM4在通信层的应用
  • 《人--件》读书笔记2
  • g2o::make_uniqueBlockSolverType(g2o::make_uniqueLinearSolverType()));报错

最新新闻

  • 2026哈尔滨汽车烧机油维修哪家好?全等级故障修复门店汇总 - 资讯速览
  • 【Verilog】从入门到实践:八个核心数字电路设计实例解析
  • 量化交易进阶(一)DMI指标参数调优与多股票回测实战
  • 如何设计一个分布式 ID 生成系统?
  • Kuramoto振子模型:从同步现象到复杂网络模拟的Python实现
  • 从零搭建TSN测试环境:基于NXP LS1028A的gPTP同步与Qbv调度实战

日新闻

  • 信任的进化:技术实现详解——如何用JavaScript构建博弈论模拟器
  • Terrakube自定义工作流:如何集成OPA、Infracost等工具扩展IaC能力
  • grunt-concurrent快速入门:5分钟学会并行运行Grunt任务

周新闻

  • 3步解锁iOS设备:applera1n激活锁绕过完全指南
  • 39 2026 人工智能证书终极盘点,普通人选 AI 证书可以从这些方向入手
  • Redis 暴露公网有多危险?从端口检查到补救步骤

月新闻

  • 【总结】入门篇:50句话让你记住架构核心概念
  • WeChatMsg技术方案解析:实现Mac微信数据自主管理的完整解决方案
  • WeChatMsg:革新性微信数据备份方案,打造你的专属数字记忆库

关于尧图

  • 公司简介
  • 团队介绍
  • 企业文化
  • 荣誉资质

服务项目

  • 定制开发
  • 电商建站
  • UI 设计
  • 运维服务

快速链接

  • 案例展示
  • 建站流程
  • 常见问题
  • 资讯中心

联系方式

  • 📍北京市朝阳区互联网产业园 A 座 10 层
  • 📞400-888-8888
  • ✉️contact@rkmt.cn
  • 🕐周一至周日 9:00-21:00

© 2024 北京尧图网络科技有限公司 版权所有 | 京 ICP 备 XXXXXXXX 号