从刷热点到技术决策：构建一套 Medical AI 技术雷达

每天都有新的模型、论文、开源项目和 AI 产品出现。真正的问题早已不是“信息够不够”，而是：

哪些变化与我们正在做的产品有关？哪些值得投入时间验证？哪些只是短暂的热度？

受“三个三”提出的七层 AI 信息源方法启发，我进一步把这套思路改造成一套面向医学 AI 产品研发的技术雷达。它不追求收集更多内容，而是把分散信号变成可以核实、比较和执行的技术决策。

原始思路参考：想比别人更早发现 AI 热点？让 GPT-6 Astra 每天扫这 7 个信息源。

需要特别说明：这套流程与某一个模型无关。GPT-6 Astra、其他云端模型或本地模型都可以充当分析引擎，真正决定质量的是信息源、证据规则、评分方法和人工审核。

为什么普通 AI 资讯流不够用

普通资讯聚合通常会产生三个问题：

1. 只有摘要，没有证据。 模型把二手报道重新组织了一遍，但没有追溯原始公告、论文或代码。
2. 只有热度，没有场景。 一个项目在 GitHub 很受关注，不代表它能解决检查推荐、影像报告生成或报告质控中的问题。
3. 只有推荐，没有验证。 系统说“值得关注”，却不说明需要什么数据、算力、时间和评测指标。

因此，技术雷达的最终输出不应该是“今日十大新闻”，而应该是一张带证据的决策表。

四层信息雷达

第一层：政策与标准

重点监测国家卫健委、国家医保局、国家药监局、国家标准与行业标准，以及医学影像互认、影像云、医保支付和数据合规相关政策。

这一层回答：

• 政策或标准发生了什么变化；
• 会影响哪些医院流程或信息系统；
• 对检查项目命名、编码和跨院互认有什么要求；
• 哪些条款需要进一步确认。

第二层：医学研究

来源包括 PubMed、arXiv、medRxiv、重要医学会议、研究机构和模型官方技术报告。

这一层不只摘录论文结论，还需要记录：

• 研究任务与目标人群；
• 数据集规模、机构数量和数据分布；
• 对照组、评价指标与置信区间；
• 是否存在外部验证；
• 是否可以迁移到中文医疗场景。

预印本、同行评议论文和厂商技术报告必须明确区分，不能混在同一个证据等级中。

第三层：模型与工程

重点关注 GitHub、Hugging Face、模型官方博客、Release、Issue 和开发框架更新。

GitHub Trending 可以用于发现信号，但不能作为采用依据。每个候选项目还要继续检查：

• 最近一次提交和发布版本；
• Issue 响应速度与未解决问题；
• 许可证及商业使用限制；
• 部署所需算力；
• 是否提供可复现的评测与示例；
• 是否能接入现有 RAG、Agent 或模型服务体系。

第四层：产品与真实需求

Hacker News、Reddit、Product Hunt、国内开发社区和内容平台适合发现使用体验、失败案例和潜在需求。

这些内容的价值是“提出问题”，而不是“证明结论”。个人叙述、产品宣传和社区评价都需要回到官方资料或实际测试中验证。

从信息流到决策流

系统应按以下流程处理每条信号：

1. 采集：保存标题、时间、来源和原始链接。
2. 归一化：统一模型、机构、项目和版本名称。
3. 去重聚类：将同一事件的多篇报道合并。
4. 来源回溯：优先定位官方公告、论文、代码仓库或政策原文。
5. 证据分级：区分已确认事实、作者观点、社区说法和模型推断。
6. 场景映射：映射到检查推荐、标准化、RAG、报告生成、报告质控等产品模块。
7. 评分排序：决定忽略、观察、调研、PoC 或进入产品路线图。
8. 人工审核：涉及医疗结论、政策解释和产品决策的内容必须由人确认。

可以为每条信号计算一个简单的优先级：

优先级 = 0.25 × 业务相关性 + 0.20 × 证据强度 + 0.20 × 落地可行性 + 0.15 × 潜在影响 + 0.10 × 紧迫性 − 0.10 × 验证成本 − 0.10 × 风险

其中：

• R：与当前业务的相关性；
• E：证据强度；
• F：落地可行性；
• M：潜在影响；
• U：紧迫性；
• C：验证成本；
• Risk：合规、临床和工程风险。

评分不是为了替代判断，而是让判断标准保持一致。

面向 Medical AI 的场景映射

技术信号	可能关联场景	最小验证
新的医学 Embedding 模型	检查推荐、标准匹配、知识检索	固定测试集比较 Recall@K、nDCG
新的长上下文模型	报告生成、病历摘要	测试关键信息遗漏、结构化 JSON 成功率
新的多模态医疗模型	影像解读、图文问答	用脱敏样本做准确性与稳定性评测
新的 Agent/RAG 框架	医生助手、证据链生成	测试工具调用成功率、引用准确率与 P95 延迟
新政策或行业标准	编码、互认、医保映射	形成影响清单并与现行数据模型逐项比对

每个高优先级主题都必须回答一个问题：

它能替代现有流程中的哪一步，需要什么数据和算力，证据是否充分，能否在两小时内完成第一次最小验证？

最终输出应该长什么样

每天或每周的结果不再是一组链接，而是一张结构化选题与决策表：

• 发生了什么；
• 最初来源在哪里；
• 当前证据等级；
• 与哪个产品模块相关；
• 对业务可能产生什么影响；
• 验证需要的数据、算力与时间；
• 建议采取什么行动；
• 哪些信息仍需核实。

最值得继续研究的三个主题，还应给出排序理由和明确的下一步。

落地时最容易踩的坑

无法读取时让模型补写

正确做法是标记“无法获取”，并记录缺失原因。任何无法追溯原始来源的内容，都不能进入“已确认事实”。

把热度当成价值

Stars、点赞和榜单排名只说明关注度，不能证明临床有效性、工程稳定性或合规性。

一开始就追求全自动

更稳妥的路径是先手工运行一到两周，记录被删除的无关内容、错误来源和评分偏差，再固化规则与定时任务。

医学结论缺少人工审核

系统可以发现信号、整理证据和提出验证建议，但不能自动形成临床结论。面向公众发布时，还需要避免把研究结果表述成诊疗建议。

分阶段建设

第一阶段：可用

先接入政策、论文、GitHub 与模型官方来源，每周形成一张决策表，并建立来源、证据、场景和行动四个核心字段。

第二阶段：可验证

加入自动去重、证据分级、场景映射和 PoC 模板；对高优先级项目自动生成最小评测方案。

第三阶段：可积累

把历史判断、验证结果和最终决策沉淀成知识库，让系统逐步学习：

• 哪类项目通常值得测试；
• 哪些来源经常失真；
• 哪些指标对医学 AI 产品真正重要；
• 过去为什么采用或放弃某项技术。

写在最后

技术雷达不是另一个信息聚合器，而是一套持续缩短“发现—理解—验证—决策”距离的机制。

对于医学 AI 团队，真正的优势不是比别人多看几十条新闻，而是更早识别与业务相关的变化，更快完成一次可靠的小验证，并把每次判断沉淀为下一次决策可以复用的知识。