ARTICLE DETAIL

资讯详情

深耕编程入门与网站建设的一线实战洞察。

Medical Benchmark

Medical Benchmark HealthBench设计动机1.其他旧bench只能证明答案对了但范围窄、不代表实际 workflow而且已经趋于饱和2.一个 reference answer 不足以评价长回答需要拆分成更细的多个评价指标3.旧bench只能回答A模型比B模型强但没有具体的归因和边界探索具体工作1.输入单轮/多轮对话输出完整的回复并非平均十几轮的长对话大多还是短几轮2.每题 2–48 个行为标准满足拿全部分可负不满足拿0分不做reference-answer matching而是判断一组应该出现/不应该出现的行为总体指标在五个维度Axis数量占比测什么Completeness39%应该包含的信息有没有遗漏Accuracy33%医学事实是否正确Context awareness16%是否理解用户环境、角色是否该追问Communication quality8%清晰度、结构、语言难度是否合适Instruction following4%是否按格式/任务要求完成3.对话场景Theme数量比例核心能力Global health1,09721.9%地区/资源/疾病谱适配Responding under uncertainty1,07121.4%不确定性表达和处理Expertise-tailored communication91918.4%对医生/普通用户调整表达Context seeking59411.9%是否知道需要补充什么信息Emergency referrals4829.6%是否正确进行急诊升级Health data tasks4779.5%clinical data/documentation 类任务Response depth3607.2%回答长度/深度是否恰当4.数据来源从医生设计场景、故意问LLM容易犯错的问题、互联网高频搜索问题等地方让LLM生成场景conversation5.防止模型快速饱和bench用多个先进模型评测筛出比较hard的题目6.worst-at-k对同一问题采样多次把其中最差的一条回答作为这组结果然后算整体 benchmark score避免模型偶尔出现危险答案可能的缺点1.每条rubric只有met / not met太粗粒度了2.每条 conversation 在最终平均里基本等权但这意味着“回答感冒常识不够完整”和“漏掉急性心梗 emergency referral”的严重度无法被很好区分3.39% criterion 都是 completeness会让写得多的模型例如o3得到更多分4.虽然说自己有多轮对话的输入但实际上还是让大模型看对话最后生成下一条response无法测评”模型追问了正确问题以后下一轮会不会用好用户答案“5.没做EHR这些更真实的医疗方向MedAgentBench设计动机真正有应用价值的 AI 应该从 chatbot 走向 agentclinician 给一个高层目标 → agent 自己规划 → 调 EHR/FHIR API → 查/改病历 → 返回任务执行结果具体工作1.多轮、条件化 tool trajectory2.使用FHIR作为环境接口方便与真实世界的EHR对接3.病理背景是来源于真实的患者4.把与患者提问相关的系统信息放到context中而不是随着query一起给出更模拟真实系统5.七大类任务broad category一个典型任务Patient information retrieval根据姓名DOB 找 MRNLab result retrieval查过去 24h 最新 MgPatient data aggregation算过去 24h 平均血糖Recording patient data写入 BP 118/77Test ordering查 HbA1c如果 1 年则重新下单Referral ordering开 orthopedics referral并填写文本Medication ordering查 K按规则算补钾剂量并开药6.9个FHIR functions每个agent必须严格输出GET从EHR中查询病历、POST向EHR写东西、finish任务做完答案提交之一可能的缺点1.一个agent可能调用正确的tool得到了正确回答但因为输出格式问题拿0分2.比起真实的EHR场景少了很多功能和信息3.由于FHIR环境启动很久如果真的执行了POST会修改EHR的信息导致每题需要重置环境。因此agent做出POST动作后只是去验证一下它发的json格式和内容符合吗
返回列表