简介这是一份面向毕业设计或课程作业场景的中文医学因果关系抽取完整研究资料基于Python与Django实现后台数据处理与Web展示围绕BioCreative中文医学文本数据集采用多任务关系抽取与功能识别联合学习并给出朴素贝叶斯、词袋模型、交叉验证、F1评估等具体实验方案。压缩包共236个文件核心类型为30个py源码、31个pyc编译文件以及33个js、20个css、11个html等Web前端资源另含75个gif过程演示与png、jpg图片素材整体约3.48MB目录结构清晰适合需要快速搭建医学NLP毕业设计或复现抽取算法的学习者。目前已有60人浏览学习。资料内除论文、开题报告和答辩PPT外还包含完整Django工程骨架、SQL数据文件、Markdown说明等从数据清理、分词、去停用词、词性标注到特征提取、模型训练与交叉验证评估逐一给出可执行思路能帮助读者少走弯路快速产出可演示的毕设系统。无论是用于论文复现、系统演示还是开题拓展都具有较高参考价值。1. 医学因果关系抽取为什么值得用 Django 包一层医学文本里的因果关系和通用领域的因为…所以…完全是两回事同一句话里药物与不良反应、疾病与并发症、检查指标与病变趋势往往同时出现且实体边界模糊。比如长期服用阿司匹林可能导致胃黏膜损伤抽取系统要做的不只是找出阿司匹林和胃黏膜损伤两个实体还要判断二者之间是因果关系而非单纯的共现关系。这个任务落到工程上从数据标注到模型训练再到结果展示是一个完整的链路而不是一段能跑通的脚本。选择 Django 作为展示层不是因为模型推理需要 Web 框架而是因为医学因果抽取的结果需要被验证、被标注、被反复查看。一个纯 Python 脚本只能输出一个 JSON而 Django 能把原始文本、标注结果、置信度、证据片段全部组织成可交互的界面。对有论文和开题报告需求的课题来说这套工程化呈现本身就是研究工作的一部分。本文面向的是具备 Python 基础的 NLP 工程师或医学信息方向的开发者目标是让你从 0 到 1 搭起一套能训练、能评估、能演示的医学因果关系抽取系统并把这套能力封装进 Django 项目中。2. 因果关系抽取的技术选型从规则到序列标注的路径2.1 医学因果的特殊性决定了模型输入的形态通用因果抽取可以用句法依存分析找导致、引发、造成这类触发词但在医学文本里这条路很快会遇到瓶颈。医学文本中因果关系经常是隐式的比如糖尿病患者出现视网膜病变这里没有显式触发词糖尿病和视网膜病变之间靠语义关联而非句法信号。因此纯粹的规则匹配只能覆盖约四成的情况剩余六成需要模型学习。我一般会把任务定义成端到端的序列标注问题对输入的句子模型输出每个 token 的 BIO 标签其中因果实体用Cause和Effect两类标记。相比关系分类方案先抽实体再判断关系联合抽取的好处是避免错误传播代价是标签体系更复杂。医学领域还有一个特殊点实体中出现嵌套和修饰词的情况比通用领域多重度慢性阻塞性肺疾病要被整体识别为一个 effect 实体而不是拆成三个词分别标注。2.2 BiLSTM-CRF 仍是最稳妥的基准方案对于 5 万到 10 万规模的医学标注语料BiLSTM-CRF 依然是最值得优先实现的模型。它不依赖预训练模型的巨大显存训练速度快而且 CRF 层能显式建模标签之间的转移约束这在因果抽取里非常关键——比如B-Cause后面不允许直接跟I-Effect这类约束是软标签如 softmax 输出难以天然保证的。用 PyTorch 实现时我的做法是用nn.utils.rnn.pack_padded_sequence处理变长序列再通过CRF类torchcrf 或自实现计算损失。一个常见的坑是 Batch 内的 padding 会污染注意力计算所以 attention 矩阵的 mask 必须单独构造不能直接用pad_padding_mask代替。如果显存有限隐藏层维度设为 256、embedding 维度 128 即可达到标准水平。2.3 医学实体识别的词典与模型融合策略纯模型的问题在于医学实体中大量专有名词在训练集中出现频率低模型容易学成字符组合模式而不是真正的实体边界。常见做法是引入外部词典做词边界约束。我把医学词典的匹配结果作为特征拼接到 embedding 后面而不是走词典优先的硬规则——硬规则在词典覆盖不到的地方会直接断掉模型判断。具体操作上使用HanLP或LTP的分词结果作为词边界特征。在字符级输入的基础上拼接词级特征可以让模型区分结肠癌和结肠在因果角色上的差异。这里需要注意医学分词的选择直接影响模型表现我建议使用pkuseg配合医学领域模型因为通用分词的边界切分比如把胃黏膜损伤切成胃/黏膜/损伤对抽取任务是有害的。3. 基于 Python 构建标注与训练的最小实现3.1 标注数据的格式转换与类定义在训练之前需要把原始医学文本转换成模型可读的形式。我的方案是采用BIO三段式标注B-Cause表示因果触发实体开头I-Cause表示实体内部O表示无关 tokenEffect 同理。下面是一个句子级别的数据处理代码。# data_loader.py import json import torch from torch.utils.data import Dataset class MedicalCausalDataset(Dataset): def __init__(self, file_path, max_len128): self.samples self._load(file_path) self.max_len max_len self.vocab self._build_vocab() def _load(self, file_path): samples [] with open(file_path, r, encodingutf-8) as f: for line in f: line line.strip() if not line: continue obj json.loads(line) samples.append({ text: obj[text], labels: obj[labels] # [O, B-Cause, I-Cause, ..., O] }) return samples def _build_vocab(self): vocab {[PAD]: 0, [UNK]: 1, [CLS]: 2, [SEP]: 3} for sample in self.samples: for ch in sample[text]: if ch not in vocab: vocab[ch] len(vocab) return vocab这段代码的核心是_build_vocab动态构建字符表。因为医学文本含大量特殊符号如化学式上标、单位符号固定词表会丢失这些 token。max_len128是处理长句子时的截断策略超过部分直接删除而不是截取末尾因为医学因果关系往往出现在句子前 60% 的位置。3.2 标签到 ID 的映射与 batch 组装标签转换成 ID 时必须保持映射的一致性这里最容易出错的是重复调用enumerate导致映射漂移。我采用固定字典的方式避免训练和推理时标签顺序不一致。LABEL2ID { O: 0, B-Cause: 1, I-Cause: 2, B-Effect: 3, I-Effect: 4 } ID2LABEL {v: k for k, v in LABEL2ID.items()} def collate_fn(batch): texts [] label_ids [] for item in batch: text item[text][:128] labels item[labels][:128] texts.append(text) label_ids.append([LABEL2ID.get(l, 0) for l in labels]) # 转 tensor 时会自动 padpadding 的 loss 用 mask 消掉 texts_tensor torch.tensor( [[vocab.get(ch, 1) for ch in t] for t in texts] ) labels_tensor torch.tensor(label_ids) mask (texts_tensor ! 0).to(torch.uint8) return texts_tensor, labels_tensor, maskmask的构造是标准操作texts_tensor ! 0把 padding 位置标为 0后续计算 CRF loss 时只需对mask为 1 的位置做归一化。很多初学者忽略这一点导致 padding 位置参与 loss 计算模型收敛后指标虚高。3.3 训练循环中的三个关键参数训练循环的写法本身不复杂但以下几个参数对医学因果任务的影响很大。# train.py optimizer torch.optim.Adam(model.parameters(), lr1e-3) scheduler torch.optim.lr_scheduler.LinearLR( optimizer, start_factor1.0, end_factor0.1, total_iters10 ) criterion torch.nn.CrossEntropyLoss(ignore_index-100)lr1e-3在 BiLSTM-CRF 中不推荐一上来就用1e-5因为 CRF 层的梯度本身就依赖前向后向算法学习率过小会导致转移矩阵长时间不更新。ignore_index-100只在计算实体位置时算 losspadding 位置跳过这和 mask 的作用不同二者是互补的。LinearLR医学语料存在长尾实体后期用低学习率微调可以避免震荡。我常用的训练策略是前 3 个 epoch 保持 1e-3之后切换为余弦退火到 1e-5。实体 F1 基本能在 10 个 epoch 内稳定到 0.72 到 0.75继续训练没有明显收益反而会过拟合到训练集中的罕见实体上。4. Django 体系中封装推理与评估接口4.1 Django 项目的 MVT 结构与模型推理的位置Django 的 MVT 模式适合作为 NLP 模型的展示层但要注意一个架构决定模型对象不能每次请求都初始化一次。医学实体抽取模型动辄几百 MB重新加载一次需要 2 到 3 秒这会直接毁掉接口体验。常见做法是使用 Django 的AppConfig在服务启动时加载一次模型到内存中。# causal_app/apps.py import torch from django.apps import AppConfig class CausalConfig(AppConfig): default_auto_field django.db.models.BigAutoField name causal_app model None # 这里只声明占位 def ready(self): # ready() 在 Django 启动时只执行一次 from causal_app.inference import CausalExtractor CausalConfig.model CausalExtractor( model_pathmodels/bilstm_crf.pt, vocab_pathmodels/vocab.json )ready()是 Django 的生命周期钩子它会在runserver和gunicorn启动时都被调用。需要注意的是在ready()中做模型加载时如果数据库表还没准备好不要在里面执行任何 ORM 查询。把模型挂成类属性而不是生成一个单例对象这样在整个进程生命周期内不需要重复初始化。4.2 视图层实现文本输入-标注结果的响应式处理视图函数接收前端传来的文本调用模型进行推理返回结构化 JSON。这里最关键的是把模型输出的预测标签序列转回实体列表。# causal_app/views.py import json from django.http import JsonResponse from django.views.decorators.csrf import csrf_exempt from causal_app.apps import CausalConfig csrf_exempt def extract_causal(request): if request.method POST: try: data json.loads(request.body) text data.get(text, ) if not text: return JsonResponse({code: 400, msg: 文本不能为空}) # 从 AppConfig 中获取已加载的模型实例 extractor CausalConfig.model result extractor.predict(text) return JsonResponse({code: 0, data: result}) except Exception as e: return JsonResponse({code: 500, msg: str(e)}) return JsonResponse({code: 405, msg: 仅支持 POST 请求})extract_causal.predict(text)返回的result是一个字典结构包含cause_entities、effect_entities和confidence三个字段。在views.py里只做参数校验和异常捕获真正的模型调用全部下沉到inference.py中这样方便单元测试时 mock 掉模型推理过程。4.3 ORM 模型设计与历史查询记录对于论文课题单次抽取结果意义有限用户更希望保存历史文本和结果方便评估模型在不同医学文本上的表现。我的表设计如下。# causal_app/models.py from django.db import models class CausalRecord(models.Model): source_text models.TextField(verbose_name原始文本) cause_entities models.JSONField(verbose_name因果实体, defaultlist) effect_entities models.JSONField(verbose_name结果实体, defaultlist) confidence models.FloatField(verbose_name置信度, default0.0) created_at models.DateTimeField(auto_now_addTrue, verbose_name创建时间) class Meta: db_table causal_record ordering [-created_at]JSONField是 Django 3.1 之后内置的字段类型直接存储结构化的实体列表要比用TextField存字符串再二次解析优雅得多。ordering [-created_at]在后台管理界面和数据列表页都能直接按时间倒序展示不需要额外写视图逻辑。4.4 Django Admin 界面美化的常用配置如果你做的是毕设或有演示需求Django 默认的 Admin 样式比较朴素。不用引入复杂的前端框架通过重写ModelAdmin的几个属性就能有不错的效果。# causal_app/admin.py from django.contrib import admin from .models import CausalRecord admin.register(CausalRecord) class CausalRecordAdmin(admin.ModelAdmin): list_display (source_text, cause_entities, effect_entities, confidence, created_at) list_filter (confidence, created_at) search_fields (source_text,) readonly_fields (created_at,)search_fields设置为source_text后后台自动生成搜索框对中文文本的模糊查询效率尚可。需要注意JSONField里的内容不能直接作为list_display中的排序字段只能显示内容。如果数据量超过 10 万条建议把created_at加数据库索引否则后台列表页的默认排序会变慢。5. 系统调优与验证技巧让抽取结果更可信5.1 评估指标的选择与呈现方式医学因果抽取的评估不能只看整体准确率我习惯按实体类型拆分指标。因为Cause和Effect的出现频率差异很大以糖尿病为主题的文本中 Effect 实体可能三倍于 Cause 实体合并计算会产生虚高。在 Django 的模板中绘制一个简单的指标表格包含每个类别的精确率、召回率、F1 值。需要注意在测试集上做实体级评估时必须使用精确匹配预测实体边界和真实实体完全一致才算对不能使用 token 级准确率——后者会把胃黏膜损伤预测成胃黏膜也当作部分正确这对论文结果而言是站不住脚的。5.2 错误分析的下沉式查询当模型在某类样本上表现不稳时直接查看样本比调整模型更快。我给 Django 的 Admin 增加了一个error_case布尔字段标记哪些文本被人工复核为错误。通过django-admin的列表筛选功能可以快速过滤出高置信度但低正确率的样本这类样本往往是标注冲突需要修正的源头。5.3 批量推理接口与异步任务解耦当用户一次性粘贴几百条病历文本进行批量抽取时同步请求会阻塞 worker 导致超时。推荐把批量推理任务放入 Celery 中异步执行前端通过轮询任务状态接口获取结果。这一部分在论文中可以作为一个提升点描述但实际搭建时并不复杂把extract_causal函数包装成celery.task结果写入 Redis 或数据库表即可。如果课题周期紧张直接限制单次文本长度和条数不引入 Celery 也不影响整体架构完整性。5.4 一个实用的置信度校准技巧在很多医学场景下模型的概率输出直接当置信度用并不靠谱。我的办法是在验证集上做一个简单的温度缩放把模型输出 logits 除以一个温度系数通常在 1.5 到 3.0 之间再经过 softmax 得到校准后的概率。这样设置过滤阈值时——比如只保留置信度大于 0.7 的抽取结果——对应的精确率会稳定很多而不是像原始 softmax 那样在 0.9 附近依然混入大量噪声。这个技巧只需要在推理代码里加一行除法运算却能让演示系统的可靠性提升一个台阶。本文还有配套的精品资源点击获取
医学因果关系抽取系统实战：从BiLSTM-CRF模型到Django部署
简介这是一份面向毕业设计或课程作业场景的中文医学因果关系抽取完整研究资料基于Python与Django实现后台数据处理与Web展示围绕BioCreative中文医学文本数据集采用多任务关系抽取与功能识别联合学习并给出朴素贝叶斯、词袋模型、交叉验证、F1评估等具体实验方案。压缩包共236个文件核心类型为30个py源码、31个pyc编译文件以及33个js、20个css、11个html等Web前端资源另含75个gif过程演示与png、jpg图片素材整体约3.48MB目录结构清晰适合需要快速搭建医学NLP毕业设计或复现抽取算法的学习者。目前已有60人浏览学习。资料内除论文、开题报告和答辩PPT外还包含完整Django工程骨架、SQL数据文件、Markdown说明等从数据清理、分词、去停用词、词性标注到特征提取、模型训练与交叉验证评估逐一给出可执行思路能帮助读者少走弯路快速产出可演示的毕设系统。无论是用于论文复现、系统演示还是开题拓展都具有较高参考价值。1. 医学因果关系抽取为什么值得用 Django 包一层医学文本里的因果关系和通用领域的因为…所以…完全是两回事同一句话里药物与不良反应、疾病与并发症、检查指标与病变趋势往往同时出现且实体边界模糊。比如长期服用阿司匹林可能导致胃黏膜损伤抽取系统要做的不只是找出阿司匹林和胃黏膜损伤两个实体还要判断二者之间是因果关系而非单纯的共现关系。这个任务落到工程上从数据标注到模型训练再到结果展示是一个完整的链路而不是一段能跑通的脚本。选择 Django 作为展示层不是因为模型推理需要 Web 框架而是因为医学因果抽取的结果需要被验证、被标注、被反复查看。一个纯 Python 脚本只能输出一个 JSON而 Django 能把原始文本、标注结果、置信度、证据片段全部组织成可交互的界面。对有论文和开题报告需求的课题来说这套工程化呈现本身就是研究工作的一部分。本文面向的是具备 Python 基础的 NLP 工程师或医学信息方向的开发者目标是让你从 0 到 1 搭起一套能训练、能评估、能演示的医学因果关系抽取系统并把这套能力封装进 Django 项目中。2. 因果关系抽取的技术选型从规则到序列标注的路径2.1 医学因果的特殊性决定了模型输入的形态通用因果抽取可以用句法依存分析找导致、引发、造成这类触发词但在医学文本里这条路很快会遇到瓶颈。医学文本中因果关系经常是隐式的比如糖尿病患者出现视网膜病变这里没有显式触发词糖尿病和视网膜病变之间靠语义关联而非句法信号。因此纯粹的规则匹配只能覆盖约四成的情况剩余六成需要模型学习。我一般会把任务定义成端到端的序列标注问题对输入的句子模型输出每个 token 的 BIO 标签其中因果实体用Cause和Effect两类标记。相比关系分类方案先抽实体再判断关系联合抽取的好处是避免错误传播代价是标签体系更复杂。医学领域还有一个特殊点实体中出现嵌套和修饰词的情况比通用领域多重度慢性阻塞性肺疾病要被整体识别为一个 effect 实体而不是拆成三个词分别标注。2.2 BiLSTM-CRF 仍是最稳妥的基准方案对于 5 万到 10 万规模的医学标注语料BiLSTM-CRF 依然是最值得优先实现的模型。它不依赖预训练模型的巨大显存训练速度快而且 CRF 层能显式建模标签之间的转移约束这在因果抽取里非常关键——比如B-Cause后面不允许直接跟I-Effect这类约束是软标签如 softmax 输出难以天然保证的。用 PyTorch 实现时我的做法是用nn.utils.rnn.pack_padded_sequence处理变长序列再通过CRF类torchcrf 或自实现计算损失。一个常见的坑是 Batch 内的 padding 会污染注意力计算所以 attention 矩阵的 mask 必须单独构造不能直接用pad_padding_mask代替。如果显存有限隐藏层维度设为 256、embedding 维度 128 即可达到标准水平。2.3 医学实体识别的词典与模型融合策略纯模型的问题在于医学实体中大量专有名词在训练集中出现频率低模型容易学成字符组合模式而不是真正的实体边界。常见做法是引入外部词典做词边界约束。我把医学词典的匹配结果作为特征拼接到 embedding 后面而不是走词典优先的硬规则——硬规则在词典覆盖不到的地方会直接断掉模型判断。具体操作上使用HanLP或LTP的分词结果作为词边界特征。在字符级输入的基础上拼接词级特征可以让模型区分结肠癌和结肠在因果角色上的差异。这里需要注意医学分词的选择直接影响模型表现我建议使用pkuseg配合医学领域模型因为通用分词的边界切分比如把胃黏膜损伤切成胃/黏膜/损伤对抽取任务是有害的。3. 基于 Python 构建标注与训练的最小实现3.1 标注数据的格式转换与类定义在训练之前需要把原始医学文本转换成模型可读的形式。我的方案是采用BIO三段式标注B-Cause表示因果触发实体开头I-Cause表示实体内部O表示无关 tokenEffect 同理。下面是一个句子级别的数据处理代码。# data_loader.py import json import torch from torch.utils.data import Dataset class MedicalCausalDataset(Dataset): def __init__(self, file_path, max_len128): self.samples self._load(file_path) self.max_len max_len self.vocab self._build_vocab() def _load(self, file_path): samples [] with open(file_path, r, encodingutf-8) as f: for line in f: line line.strip() if not line: continue obj json.loads(line) samples.append({ text: obj[text], labels: obj[labels] # [O, B-Cause, I-Cause, ..., O] }) return samples def _build_vocab(self): vocab {[PAD]: 0, [UNK]: 1, [CLS]: 2, [SEP]: 3} for sample in self.samples: for ch in sample[text]: if ch not in vocab: vocab[ch] len(vocab) return vocab这段代码的核心是_build_vocab动态构建字符表。因为医学文本含大量特殊符号如化学式上标、单位符号固定词表会丢失这些 token。max_len128是处理长句子时的截断策略超过部分直接删除而不是截取末尾因为医学因果关系往往出现在句子前 60% 的位置。3.2 标签到 ID 的映射与 batch 组装标签转换成 ID 时必须保持映射的一致性这里最容易出错的是重复调用enumerate导致映射漂移。我采用固定字典的方式避免训练和推理时标签顺序不一致。LABEL2ID { O: 0, B-Cause: 1, I-Cause: 2, B-Effect: 3, I-Effect: 4 } ID2LABEL {v: k for k, v in LABEL2ID.items()} def collate_fn(batch): texts [] label_ids [] for item in batch: text item[text][:128] labels item[labels][:128] texts.append(text) label_ids.append([LABEL2ID.get(l, 0) for l in labels]) # 转 tensor 时会自动 padpadding 的 loss 用 mask 消掉 texts_tensor torch.tensor( [[vocab.get(ch, 1) for ch in t] for t in texts] ) labels_tensor torch.tensor(label_ids) mask (texts_tensor ! 0).to(torch.uint8) return texts_tensor, labels_tensor, maskmask的构造是标准操作texts_tensor ! 0把 padding 位置标为 0后续计算 CRF loss 时只需对mask为 1 的位置做归一化。很多初学者忽略这一点导致 padding 位置参与 loss 计算模型收敛后指标虚高。3.3 训练循环中的三个关键参数训练循环的写法本身不复杂但以下几个参数对医学因果任务的影响很大。# train.py optimizer torch.optim.Adam(model.parameters(), lr1e-3) scheduler torch.optim.lr_scheduler.LinearLR( optimizer, start_factor1.0, end_factor0.1, total_iters10 ) criterion torch.nn.CrossEntropyLoss(ignore_index-100)lr1e-3在 BiLSTM-CRF 中不推荐一上来就用1e-5因为 CRF 层的梯度本身就依赖前向后向算法学习率过小会导致转移矩阵长时间不更新。ignore_index-100只在计算实体位置时算 losspadding 位置跳过这和 mask 的作用不同二者是互补的。LinearLR医学语料存在长尾实体后期用低学习率微调可以避免震荡。我常用的训练策略是前 3 个 epoch 保持 1e-3之后切换为余弦退火到 1e-5。实体 F1 基本能在 10 个 epoch 内稳定到 0.72 到 0.75继续训练没有明显收益反而会过拟合到训练集中的罕见实体上。4. Django 体系中封装推理与评估接口4.1 Django 项目的 MVT 结构与模型推理的位置Django 的 MVT 模式适合作为 NLP 模型的展示层但要注意一个架构决定模型对象不能每次请求都初始化一次。医学实体抽取模型动辄几百 MB重新加载一次需要 2 到 3 秒这会直接毁掉接口体验。常见做法是使用 Django 的AppConfig在服务启动时加载一次模型到内存中。# causal_app/apps.py import torch from django.apps import AppConfig class CausalConfig(AppConfig): default_auto_field django.db.models.BigAutoField name causal_app model None # 这里只声明占位 def ready(self): # ready() 在 Django 启动时只执行一次 from causal_app.inference import CausalExtractor CausalConfig.model CausalExtractor( model_pathmodels/bilstm_crf.pt, vocab_pathmodels/vocab.json )ready()是 Django 的生命周期钩子它会在runserver和gunicorn启动时都被调用。需要注意的是在ready()中做模型加载时如果数据库表还没准备好不要在里面执行任何 ORM 查询。把模型挂成类属性而不是生成一个单例对象这样在整个进程生命周期内不需要重复初始化。4.2 视图层实现文本输入-标注结果的响应式处理视图函数接收前端传来的文本调用模型进行推理返回结构化 JSON。这里最关键的是把模型输出的预测标签序列转回实体列表。# causal_app/views.py import json from django.http import JsonResponse from django.views.decorators.csrf import csrf_exempt from causal_app.apps import CausalConfig csrf_exempt def extract_causal(request): if request.method POST: try: data json.loads(request.body) text data.get(text, ) if not text: return JsonResponse({code: 400, msg: 文本不能为空}) # 从 AppConfig 中获取已加载的模型实例 extractor CausalConfig.model result extractor.predict(text) return JsonResponse({code: 0, data: result}) except Exception as e: return JsonResponse({code: 500, msg: str(e)}) return JsonResponse({code: 405, msg: 仅支持 POST 请求})extract_causal.predict(text)返回的result是一个字典结构包含cause_entities、effect_entities和confidence三个字段。在views.py里只做参数校验和异常捕获真正的模型调用全部下沉到inference.py中这样方便单元测试时 mock 掉模型推理过程。4.3 ORM 模型设计与历史查询记录对于论文课题单次抽取结果意义有限用户更希望保存历史文本和结果方便评估模型在不同医学文本上的表现。我的表设计如下。# causal_app/models.py from django.db import models class CausalRecord(models.Model): source_text models.TextField(verbose_name原始文本) cause_entities models.JSONField(verbose_name因果实体, defaultlist) effect_entities models.JSONField(verbose_name结果实体, defaultlist) confidence models.FloatField(verbose_name置信度, default0.0) created_at models.DateTimeField(auto_now_addTrue, verbose_name创建时间) class Meta: db_table causal_record ordering [-created_at]JSONField是 Django 3.1 之后内置的字段类型直接存储结构化的实体列表要比用TextField存字符串再二次解析优雅得多。ordering [-created_at]在后台管理界面和数据列表页都能直接按时间倒序展示不需要额外写视图逻辑。4.4 Django Admin 界面美化的常用配置如果你做的是毕设或有演示需求Django 默认的 Admin 样式比较朴素。不用引入复杂的前端框架通过重写ModelAdmin的几个属性就能有不错的效果。# causal_app/admin.py from django.contrib import admin from .models import CausalRecord admin.register(CausalRecord) class CausalRecordAdmin(admin.ModelAdmin): list_display (source_text, cause_entities, effect_entities, confidence, created_at) list_filter (confidence, created_at) search_fields (source_text,) readonly_fields (created_at,)search_fields设置为source_text后后台自动生成搜索框对中文文本的模糊查询效率尚可。需要注意JSONField里的内容不能直接作为list_display中的排序字段只能显示内容。如果数据量超过 10 万条建议把created_at加数据库索引否则后台列表页的默认排序会变慢。5. 系统调优与验证技巧让抽取结果更可信5.1 评估指标的选择与呈现方式医学因果抽取的评估不能只看整体准确率我习惯按实体类型拆分指标。因为Cause和Effect的出现频率差异很大以糖尿病为主题的文本中 Effect 实体可能三倍于 Cause 实体合并计算会产生虚高。在 Django 的模板中绘制一个简单的指标表格包含每个类别的精确率、召回率、F1 值。需要注意在测试集上做实体级评估时必须使用精确匹配预测实体边界和真实实体完全一致才算对不能使用 token 级准确率——后者会把胃黏膜损伤预测成胃黏膜也当作部分正确这对论文结果而言是站不住脚的。5.2 错误分析的下沉式查询当模型在某类样本上表现不稳时直接查看样本比调整模型更快。我给 Django 的 Admin 增加了一个error_case布尔字段标记哪些文本被人工复核为错误。通过django-admin的列表筛选功能可以快速过滤出高置信度但低正确率的样本这类样本往往是标注冲突需要修正的源头。5.3 批量推理接口与异步任务解耦当用户一次性粘贴几百条病历文本进行批量抽取时同步请求会阻塞 worker 导致超时。推荐把批量推理任务放入 Celery 中异步执行前端通过轮询任务状态接口获取结果。这一部分在论文中可以作为一个提升点描述但实际搭建时并不复杂把extract_causal函数包装成celery.task结果写入 Redis 或数据库表即可。如果课题周期紧张直接限制单次文本长度和条数不引入 Celery 也不影响整体架构完整性。5.4 一个实用的置信度校准技巧在很多医学场景下模型的概率输出直接当置信度用并不靠谱。我的办法是在验证集上做一个简单的温度缩放把模型输出 logits 除以一个温度系数通常在 1.5 到 3.0 之间再经过 softmax 得到校准后的概率。这样设置过滤阈值时——比如只保留置信度大于 0.7 的抽取结果——对应的精确率会稳定很多而不是像原始 softmax 那样在 0.9 附近依然混入大量噪声。这个技巧只需要在推理代码里加一行除法运算却能让演示系统的可靠性提升一个台阶。本文还有配套的精品资源点击获取
