导读 :随着智慧医疗的深入发展,非结构化电子病历(EMR)的深度语义挖掘成为提升临床决策与科研效率的关键。本项目针对三甲医院专科病历,开展高质量数据集建设。主要内容包括:利用命名实体识别(NER)与知识图谱抽取技术实现语义解析,基于SNOMED CT进行医学术语标准化,并执行严格的隐私脱敏清洗;同时结合RLHF微调技术优化大模型表现。旨在构建标准化、规模化的医疗大模型语料库,赋能精准医疗,推动医疗人工智能从通用向专科化演进。


一、问题出在哪:数据有了,但用不了

1.1 非结构化的"数据沼泽"

先来看一个典型的三甲医院数据现状。

HIS(医院信息系统)里有挂号、处方、收费的结构化数据,相对整齐;但EMR(电子病历)里的核心内容——主诉、现病史、体格检查、出院小结——绝大部分是自由文本,没有统一格式,没有编码规范,完全依赖医生个人书写习惯。

同一个"高血压",可能被写成:高血压病、原发性高血压、HTN、血压偏高、血压控制不佳……这些写法在临床上语义等价,但对机器而言是完全不同的字符串。如果没有与SNOMED CT、ICD-10等国际标准术语集的映射,数据就无法跨科室、跨医院使用,更谈不上支撑AI推理。

更麻烦的是多模态异构问题:影像报告可能是Word文档、打印扫描件、或嵌入DICOM文件里的附注文字;检验单既有结构化的数值,也有人工填写的备注;手术记录可能来自三个不同厂商的系统,字段名称完全不同。

这种状态的数据,不是"质量差",而是"格式上不可用"。 在喂给模型之前,需要经历一整套繁重的工程处理才能变成可训练的语料。

1.2 隐私保护与数据利用的真实矛盾

还有一个更敏感的问题:患者隐私。

《个人信息保护法》《数据安全法》《健康医疗数据安全指南》(GB/T 39725-2020)明确规定,患者的个人健康信息(PHI)属于敏感个人信息,必须依法处理。HIPAA的"安全港"原则则定义了18类必须脱敏的标识符,包括姓名、身份证号、出生日期、家庭住址、病案号、联系方式、生物特征等。

传统的脱敏方式——替换关键字段——在结构化数据上还好操作,但在自由文本里根本不够用。医生在病程记录里可能写:"患者是某某机关工作人员,其妻子也曾因同类疾病就诊……"这段文字里没有任何明确的"姓名"字段,但同样包含了可识别信息,传统规则引擎根本识别不了。

如果脱敏做得不彻底,数据就不合规,不能开放;如果脱敏做得过重,医学语义被破坏了,数据就没有训练价值。在这个两难之间找到工程路径,是整个项目的前提条件。

1.3 通用大模型的"医疗幻觉"

这个问题值得单独说。

GPT-4、Claude等通用大模型在医疗问答测试中表现可观,能通过美国执照医师考试,看起来"懂医学"。但在真实临床场景里,这些模型有一个系统性风险:它们的训练数据里,高质量的专科临床病历极度匮乏。

结果是,模型在回答"患者同时服用华法林和阿司匹林,剂量如何调整"这类问题时,可能给出听起来合理但实际上危险的建议。它引用的是互联网上散落的医学科普或学术摘要,而不是真正经过临床验证、符合诊疗规范的知识体系。

修复这个问题,根本路径只有一条:用真实的、高质量的专科病历数据,对基础模型进行专科化微调(Fine-tuning)和对齐(Alignment)。 而这条路的起点,就是本文要拆解的这类项目。


二、项目框架:数据治理-语义解析-模型对齐三段论

这类项目的本质,是把医院里"沉睡"的临床数据,变成可以驱动专科大模型的高质量语料。整个链路分三个核心阶段:

第一段:数据治理——解决"能不能用"的问题,核心是隐私脱敏和数据清洗。

第二段:语义解析——解决"懂不懂"的问题,核心是把非结构化文本变成结构化知识。

第三段:模型对齐——解决"专不专"的问题,核心是用高质量数据集对基础模型进行微调。

这三段缺一不可,顺序不能乱。数据治理不到位,后面的语义解析做出来的知识包含患者隐私,不合规;语义解析不到位,给模型的训练数据是低质量的,微调反而损害基础能力。

量化目标

该方案设定了可验收的量化指标:

指标维度 目标值
病历脱敏准确率 ≥ 99.9%
NER命名实体识别F1值 ≥ 90%
术语标准化映射率(SNOMED CT/ICD-10) ≥ 95%
知识图谱规模 ≥ 100万三元组
图谱检索响应时延 ≤ 200ms
微调后模型专科知识覆盖度 ≥ 95%
逻辑推理准确率提升(vs. 基础模型) ≥ 30%
临床建议合规率 ≥ 90%
病历书写时长缩短 ≥ 20%

三、数据接入:把"活水"引进来

3.1 异构系统对接:三类核心数据源

医院内部的数据来源至少涉及三类核心系统:

HIS系统(医院信息系统):挂号、医嘱、处方等结构化数据,通过只读副本(Read-Only Replica)+ JDBC协议接入,避免影响生产库I/O。

EMR系统(电子病历系统):病程记录、出院小结等文书数据,通过HL7 CDA R2协议进行XML格式封装,把非结构化文本转为半结构化数据。

PACS系统(影像归档和通信系统):影像元数据和诊断报告通过DICOM 3.0协议接口获取,大容量影像文件通过NAS挂载路径实现离线索引同步。

整个接入过程有一个硬性约束:对生产系统的CPU性能冲击必须控制在3%以内。 这不是技术理想,而是医院运营的现实要求——任何数据采集工作不能影响正常的临床系统运行。

3.2 实时增量+定时全量:两条采集通路

为同时满足数据时效性和历史完整性,方案采用"双轨采集"策略:

实时增量通路:基于Kafka分布式消息队列,利用Canal组件实时解析数据库Binlog日志,将病历更新、检查状态变更等事件以JSON流形式推送至Kafka Topic。要求单条消息延迟控制在500ms以内,通过3副本+Acks=all机制保障QPS达5000以上时数据零丢失。

定时全量通路:基于DataX的批量抽取任务,通过自定义Reader插件对接业务库,执行分片并行抽取,带宽占用限制在50MB/s,用于每日零点的全量数据对账和拉链表更新。

两条通路分工明确:Kafka捕捉临床动态变化(用于实时质控和危急值告警),DataX保障底层数据的绝对准确性(用于历史数据回溯和统计)。

3.3 数据湖四层架构:ODS→DWD→DWS→ADS

数据落入数据湖后,经历四个处理层级,每层有明确的质量门控:

ODS层(原始贴源层):遵循"不清洗、不转换、全覆盖"原则,仅添加ODS_LOAD_TIME与ODS_SOURCE_SYSTEM等审计字段,完整保留原始快照。依托Hudi构建近实时湖仓底座,单节点并发写入吞吐量上限1.2GB/s。

DWD层(标准明细层):执行脱敏清洗与规范化。数据脱敏遵循GB/T 35273-2020,调用KMS密钥管理服务对敏感字段执行哈希处理或掩码覆盖。同时集成NLP组件执行分词和NER,提取症状、药物等原子实体以扁平化宽表存储。质量控制方面,若脏数据占比超过5%,自动拦截批次并触发复核工单。

DWS层(主题汇总层):面向大模型提供主题化结构化特征,以患者、医生、疾病为维度做跨周期指标聚合,同时执行特征向量化——清洗后的数据输入Embedding编码器生成高维向量,存储于向量数据库。

ADS层(应用数据层):直接对接大模型微调任务,将数据转化为JSONL格式指令对,经"机审+人审"双重校验后产出SFT指令集和RLHF偏好数据集。每个发布的数据集分配唯一版本号,记录数据量、类别分布、标注准确率等元数据。


四、隐私脱敏:18类敏感信息的工程级处理

4.1 脱敏引擎的双轨架构

脱敏是整个项目合规性的基石。方案采用"高性能规则引擎+大模型NER校验"的串联双轨架构:

第一轨:规则引擎主要处理结构化和半结构化数据,基于正则表达式匹配库,对身份证号、手机号、日期等具备强特征格式的字段高速过滤,处理延迟稳定在5ms/KB以内。

第二轨:大模型NER校验处理非结构化的自由文本,部署经过50G医疗专业语料微调的Transformer模型,通过注意力机制捕获文本上下文特征,精准区分"王医生"与"王患者"等角色差异,识别出隐藏在描述性文字中的亲属姓名、家庭住址片段或具有唯一性的社会关系描述。

两轨结合,解决了传统规则引擎在处理自然语言时的语义缺失问题。脱敏后的数据集需经过重标识风险评估,确保K-匿名度(K-anonymity)指标≥5,即任何个体被重新识别的概率低于预设阈值。

4.2 18类PHI的差异化脱敏策略

根据HIPAA"安全港"原则,系统识别并锁定了18类必须处理的敏感标识符,并针对不同类型采用差异化算法:

不可逆哈希替换:适用于身份证号、病案号等强索引字段。采用加盐哈希(Salted Hash)算法,动态盐值由全局安全模块管理,结合SHA-256进行单向映射。这样既保证同一患者在不同系统间的关联性,又阻断了彩虹表逆向破解。

泛化与掩码:适用于地理位置、日期、年龄等字段。精确出生日期泛化为年份,详细住址保留至区县级别。特别注意89岁以上高龄患者的处理——这类样本稀少,存在唯一性暴露风险,统一标注为"90+"。

姓名的特殊处理:结合字典匹配+NER识别,采用"姓氏保留/名字随机置换"策略,在维持病历文本连贯性的同时消除直接识别性。

最小必要原则贯穿始终:若业务场景仅需统计科室接诊量,引擎直接剔除所有PHI字段;在多中心临床研究场景下,通过动态令牌(Tokenization)生成临时标识符,研究人员只能接触脱敏后的二次数据集。

系统还设计了定期逆向还原压力测试——主动用攻击方法测试脱敏算法的鲁棒性,确保算法的安全边界持续有效。


五、语义解析:让机器"读懂"病历

5.1 多模态病历的结构化解析

病历的格式本身就是一个工程挑战。

文本型病历(XML/Word/电子PDF):相对简单,通过DOM解析器和OOXML流提取技术,直接获取底层结构化标签与文本流,节点覆盖率要求99.9%以上,处理吞吐量100份/秒以上。

影像型病历(扫描件/图片PDF):复杂得多,需要经过图像增强(高斯滤波去噪、Otsu自适应二值化、仿射变换纠偏)→ 深度学习版面分析(LayoutLMv3架构,融合图像块、文本词元和二维位置嵌入,自动识别页眉、正文、表格、签名区等逻辑区域)→ 医疗专用OCR(字符识别率≥98.5%,内置3万+医学词汇)→ 语义映射的完整流水线,处理吞吐量5份/秒以上。

解析的最终产出是符合临床信息模型(OMOP或CDISC)的标准化JSON对象——从异构原始文件到标准化数据资产的完整转化。

5.2 命名实体识别:RoBERTa-wwm + BiLSTM + CRF

这是整个语义解析的核心算法模块。

为什么选择这个组合架构而不是直接用通用大模型?因为这三个组件解决的是不同层面的问题:

RoBERTa-wwm(预训练语言模型,带全词掩码)作为编码层,提取全局语义。全词掩码技术能够识别"急性心肌梗死"作为一个完整语义单元,避免字符级拆分导致的语义碎片化。其生成的动态字向量融入了复杂上下文语义,为后续特征增强提供高维表征。

BiLSTM(双向长短期记忆网络)作为特征增强层,捕捉长距离上下文依赖。临床病历中实体的判定高度依赖上下文——区分"头痛"属于症状描述还是主诉内容,需结合前置动词或后置修饰语。BiLSTM通过前向和后向隐层状态序列的拼接,全面反映字符在句中的语义定位。

CRF(条件随机场)作为解码层,处理标签序列的逻辑约束。医学NER的标签输出必须遵循BIO/BIOES规范(“I-Drug"不可直接紧随"B-Disease”),CRF通过学习标签间转移概率矩阵,对预测序列进行全局最优解搜索,自动修正逻辑错误的标签组合。

实体标签体系定义了五个一级维度:

  • 疾病(Disease):如"2型糖尿病"、“非小细胞肺癌”
  • 症状(Symptom):如"持续性钝痛"、“双下肢水肿”
  • 药品(Drug):如"盐酸二甲双胍"、“阿司匹林肠溶片”
  • 手术操作(Procedure):如"腹腔镜下胆囊切除术"、“冠状动脉造影”
  • 解剖部位(Anatomy):如"左心室壁"、“L4-L5椎间盘”

推理加速方面,为满足单条文本解析延迟<50ms的SLA,系统采用三层策略:

  1. TensorRT FP16半精度量化,推理速度提升2-3倍
  2. 知识蒸馏(Knowledge Distillation),将教师模型知识迁移至参数量减少60%的轻量学生模型
  3. 动态批处理(Dynamic Batching),将多条短请求合并为单一Batch并行计算,高并发场景吞吐量上限达8000 QPS以上

5.3 实体关系抽取:从"词"到"知识"

NER只是第一步——知道有哪些实体。真正有价值的,是实体之间的关系

关系抽取(RE)模块采用基于RoBERTa-Medical + GlobalPointer的端到端联合抽取架构,将关系抽取转化为首尾实体对的矩阵识别问题,能同时识别实体边界和关系类型,解决了传统流水线模式在处理实体重叠和关系交叉时的缺陷。

系统构建了包含24类核心医疗关系的Schema,覆盖禁忌、适应症、副作用、病因学等维度。例如,在处理"患者长期服用阿司匹林以预防心肌梗死"这一文本时,模型通过注意力矩阵精准锁定"阿司匹林(药物)"与"心肌梗死(疾病)"之间的"预防/治疗"关系。

置信度阈值设定τ>0.85——低于此阈值的抽取结果自动进入人工复核队列,而不是直接丢弃,避免低频但重要关系的损失。

训练阶段还融入了SNOMED-CT、ICD-10的嵌入向量,增强模型对医学常识的理解,使其在面对长尾或罕见病关系时依然能通过语义相似度进行逻辑推理。

5.4 患者纵向时间线:从静态知识到动态轨迹

单次就诊的知识是静态的,真正有临床价值的是患者的纵向诊疗轨迹

医疗事件抽取模块定义了入院、手术、用药调整、检查检验、出院、随访等核心事件类型,每个事件挂载时间戳、执行主体、结果状态等元数据。

时间信息的处理是个难点:病历里的时间往往是相对时间——“术后三天”、“一周前”——需要基于入院基准时间,通过正则文法与语义偏移规则自动换算为标准ISO 8601格式。

当同一事件在门诊志、住院志、出院小结中被多次提及且描述不一致时(这种情况极为常见),系统采用基于证据优先级的加权算法:手术记录置信权重最高,其次为病程记录和体格检查,从多源证据中提取最接近临床事实的版本。

单篇病历的事件抽取耗时控制在200ms以内,支撑万级并发的实时处理。

5.5 术语标准化:消除"同义异名"的根本方法

语义解析的最后一公里,是术语标准化——把各种写法的临床描述统一映射到SNOMED CT、ICD-10或LOINC等国际标准术语集。

这是构建知识图谱和跨机构数据互通的基础。没有术语标准化,不同医院的数据永远无法合并分析,多中心临床研究也就无从谈起。

方案利用双向Transformer编码器提取临床概念特征,结合预建立的标准术语映射表,实现非标准表达的自动归一化,目标映射率≥95%。输出层还配置了逻辑校验机制,根据医学常识对提取结果进行边界检查:心率数值是否在生理可能范围内、诊断结果与科室信息是否匹配等。


六、知识图谱:把结构化知识"连"起来

命名实体和关系三元组,是知识图谱的原材料。把这些原材料组装成一个能够支撑推理的知识网络,需要专门的图谱构建工程。

方案采用**"向量+图"双引擎存储架构**:

  • Milvus向量数据库:负责高维向量索引,支持Top-K语义相似度检索,用于RAG(检索增强生成)场景下的知识召回
  • Neo4j图数据库(5.x版本):原生图存储引擎,Cypher查询语言支持毫秒级五层以上关联路径检索,存储实体-关系-属性三元组,用于知识推理和关系链查询

两个引擎分工明确:Milvus处理"语义上相似的是什么",Neo4j处理"它们之间有什么关系"。

知识图谱规模目标:≥100万三元组,覆盖疾病-症状、药物-适应症/禁忌症、手术-并发症等核心医疗知识维度,为模型的推理提供事实性约束,从机制上降低幻觉率。

图谱的价值不仅在于存储,更在于事实约束:当模型回答某个用药建议时,知识图谱可以实时校验模型的输出与图谱中的药物禁忌关系是否冲突,一旦检测到矛盾即触发修正。这种"锚定现实"的机制,是解决医疗大模型幻觉问题的核心路径之一。


七、人工标注工作台:人机协同的精度保障

数据治理和语义解析可以大量自动化,但有一个环节绕不过去:专家标注

机器提取的知识,需要临床专家确认;RLHF训练需要的偏好数据(“哪个方案更好”),必须由真实的临床医生来判断。这是任何自动化流程都无法完全替代的。

7.1 标注工作台的技术设计

工作台采用B/S架构,前端基于Vue 3.0,核心标注区域使用Canvas+SVG混合渲染引擎,解决处理超5万字超长医学文献时传统DOM操作的卡顿问题,确保4K高分屏下交互延迟低于16ms。

针对国产化办公环境,工作台完成了对统信UOS、银河麒麟V10系统以及奇安信、红莲花浏览器的深度调优,支持WebGL硬件加速。

后端通过Nginx长连接负载均衡+WebSocket协议实现标注状态的毫秒级同步,支持多名专家同时对同一份文档进行并发标注,不产生数据冲突。

7.2 预标注减负:把人工从重复劳动中解放

为降低专家的初始工作量,工作台集成了基于Transformer的医学预训练模型构建自动化预标注链路:

  1. NER模块扫描原始语料,识别症状、疾病、手术、药物、检查等12类核心实体,利用指针网络(Pointer Network)算法精确定位实体起止偏移量
  2. 关系预抽取模块同步识别实体对的语义关联
  3. 系统仅将置信度>0.85的预标注结果推送至前端,专家通过单键点击完成"确认"或"纠偏"

实验数据显示,预标注链路将单篇病历的平均标注时长缩短50%以上。专家进入工作台时面对的是已初步结构化的草案,而不是一张白纸,大幅降低了认知负荷。

7.3 SFT指令集与RLHF偏好数据集的生产

标注工作台最终产出两类核心训练数据:

SFT(监督微调)指令集:结构为"(instruction, input, output)"三元组,覆盖医学问答、病历摘要生成、诊断推理等任务类型。质量要求为专家审核通过率≥98%。

RLHF(基于人类反馈的强化学习)偏好数据集:医生对同一问题的多个不同回答进行排序——“哪个更符合临床规范?”"哪个更安全?"这种偏好排序数据不只包含医学结论,更固化了临床思维的推理路径和决策权重。这类数据的价值极高,是让模型"说话有分寸、不乱开药方"的关键。


八、数据集管理:资产化而非文件化

项目产出的数据集不是一堆文件,而是可管理、可版本控制、可检索的数字资产。

8.1 千万级检索:Elasticsearch的医疗专属优化

数据集检索依托Elasticsearch分布式架构,分词层集成IK Analyzer并加载定制化医学词典,覆盖GB/T 14396-2016及ICD-10标准,确保"急性心肌梗死"、"Ⅱ型糖尿病"等复合术语的倒排索引构建精度。

物理层采用5主分片+1副本配置,结合NVMe SSD的高IOPS特性,将复杂检索平均响应时延控制在100ms以内,支撑QPS>1000的并发查询。

多条件筛选通过布尔查询(Bool Query)模型实现,年龄、就诊日期、检验值等结构化字段强制启用Filter Context触发Bitset缓存,规避相关性评分计算,降低CPU负载。

8.2 版本控制:借鉴Git理念管理数据演进

数据集版本控制借鉴Git设计理念,采用元数据驱动(Metadata-Driven)的不可变数据管理。每次Commit生成Manifest清单文件(记录Parquet文件路径、Checksum及时间戳),不物理覆盖原始数据,确保数据血缘完整可追溯。

科研人员可从Master分支创建独立Branch进行数据清洗或特征工程实验;Merge操作触发时自动执行Schema一致性校验;若实验偏离预期,通过元数据指针偏移实现秒级回滚,将数据集恢复至任意历史时间点。

版本控制深度集成质量监控——Merge操作前,质量规则引擎自动执行空值率、逻辑一致性等12项维度检测,仅通过质控阈值的变更才允许合入主线。

8.3 开放共享:标准化API服务

平台数据开放层基于OpenAPI 3.0规范构建RESTful接口,提供JSON、JSONL、CSV多格式导出。大数据量导出通过异步任务队列+预签名URL(Pre-signed URL)技术实现,规避长连接对网关资源的损耗。

授权体系采用OAuth 2.0客户端凭证模式(Client Credentials Grant),权限控制引入细粒度属性访问控制(ABAC),将授权维度从API端点下钻至数据集和字段级,确保研究人员只能访问其被授权的数据范围。

计费审计模块记录调用方标识、响应耗时、下行流量等维度,通过分析流量趋势识别爬虫攻击或数据泄露风险,一旦检测到异常波动,联动网关执行动态限流。


九、技术底座:算力配置与部署架构

支撑这套系统运行,需要匹配的硬件架构。方案的算力配置分两类:

训练集群:选用H800或昇腾910B加速芯片,单节点配置8张显卡,由NVLink或HCCS高速互连,单节点算力达到PFLOPS量级,支撑千亿级参数规模的模型迭代。共16台训练机。

推理业务集群:侧重高并发处理,双路64核处理器,核存比1:4,保障API网关与逻辑推理的低延迟响应。共32台业务机。

存储层:Ceph分布式架构,12台存储节点,高性能全闪存池(NVMe SSD)承载训练数据与模型权重,机械硬盘池(SATA HDD)负责非结构化日志及历史备份数据。

网络:GPU集群内部采用胖树(Fat-Tree)拓扑+RoCE v2协议构建无损RDMA网络,400G带宽,降低大模型分布式训练中的参数同步延迟。

大模型推理引擎选用vLLM,其PagedAttention算法借鉴操作系统虚拟内存管理机制,将显存中的KV Cache进行非连续分页存储,彻底解决长文本生成过程中的显存碎片化问题,单卡并发处理能力提升2-4倍。配合Continuous Batching技术和FP8量化方案,在维持模型精度的同时降低显存占用。


十、这件事做完之后,医院手里有什么

经历了数据治理、语义解析、知识图谱构建、人工标注、模型微调这一整套流程,医院最终得到的不只是一个"会答题的模型",而是一套完整的数字资产体系。

结构化专科知识库:原来沉睡在自由文本里的临床知识,变成了可检索、可计算、可推理的结构化知识图谱,包含百万级三元组,覆盖药物-疾病-手术-症状的完整关联网络。

高质量专科语料库:经过脱敏、清洗、标注的千万级训练样本,是医疗大模型微调的核心原料。这份语料库本身就是医院最具价值的数字资产之一,可以持续积累、持续迭代。

专科化微调模型:逻辑推理准确率比通用基础模型提升30%以上,专科知识覆盖度95%,临床建议合规率90%——这不是一个"可以回答医学问题"的chatbot,而是一个真正理解专科临床逻辑的推理引擎。

标准化数据治理体系:这套脱敏规则、清洗标准、质量稽核机制、版本控制系统,可以复用到未来的任何AI项目。医院从此拥有了把原始数据转化为AI燃料的能力,而不是每次都从零开始。


总结:数据不是问题,治理才是问题

把这篇文章拆解的内容放在一起,会发现一个共同的主线:医疗AI的瓶颈从来不是算法,而是数据治理能力。

算法层面,RoBERTa、Transformer、RLHF这些技术已经足够成熟,没有什么不可逾越的障碍。真正的硬仗,在于:

  • 怎么把散落在十几个异构系统里的数据统一接入,而不影响生产
  • 怎么在保护患者隐私的前提下,最大程度保留医学语义
  • 怎么让机器读懂"急性心肌梗死陈旧性病变"这类复杂表达,并映射到国际标准编码
  • 怎么用有限的专家资源,高效完成高质量的偏好标注
  • 怎么让这些工作的产出不是一次性的文件,而是可持续积累的数字资产

这些问题的答案,不在任何一篇论文里,而在医院信息化团队、临床医生、数据工程师、AI研究团队之间的深度协同里。

医疗AI的真正门槛,是跨专业的系统工程能力——这比任何单一算法的突破,都要难,也都要更有价值。

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_01.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_02.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_03.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_04.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_05.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_06.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_07.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_08.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_09.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_10.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_11.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_12.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_13.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_14.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_15.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_16.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_17.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_18.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_19.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_20.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_21.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_22.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_23.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_24.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_25.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_26.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_27.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_28.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_29.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_30.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_31.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_32.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_33.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_34.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_35.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_36.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_37.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_38.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_39.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_40.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_41.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_42.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_43.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_44.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_45.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_46.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_47.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_48.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_49.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_50.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_51.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_52.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_53.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_54.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_55.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_56.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_57.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_58.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_59.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_60.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_61.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_62.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_63.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_64.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_65.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_66.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_67.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_68.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_69.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_70.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_71.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_72.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_73.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_74.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_75.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_76.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_77.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_78.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_79.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_80.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_81.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_82.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_83.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_84.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_85.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_86.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_87.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_88.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_89.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_90.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_91.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_92.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_93.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_94.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_95.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_96.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_97.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_98.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_99.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_100.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_101.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_102.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_103.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_104.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_105.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_106.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_107.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_108.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_109.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_110.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_111.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_112.png

三甲医院专科电子病历(EMR)语义解析与自然语言大模型高质量数据集详细设计方案_113.png

Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐