简介这份《2024网信自主创新调研报告》PDF面向关注AI技术演进的科技从业者、研究人员及企业管理者聚焦非Transformer架构与算法变革趋势。报告系统梳理了LFMLiquid Foundation Model等新型模型的兴起以及DeepSeek在辅助诊断、病理分析、靶点发现等医疗与制药场景的落地实践并深入探讨少量SFT数据叠加多轮强化学习如何提升模型性能、降低内存与算力开销为AI向终端设备延伸提供路径。资源包内含1个PDF文件大小约31.73MB结构完整、便于通读与检索。目前已有62人学习下载。读者可借此把握从技术能力驱动转向需求应用驱动的行业拐点理解非Transformer架构的多样性方向评估AI在医疗、健康管理、机器人等领域的商业化潜力与挑战适合作为技术选型与趋势研判的参考读本。1. 从一份调研报告看 AI 落地为什么 2025 年被称为算法变革元年2025 年被不少从业者称为人工智能元年这个说法背后不是营销话术而是训练范式和部署逻辑同时发生了位移。我最近把《2024网信自主创新调研报告》完整拆了一遍它讨论的核心不是某个模型跑分多高而是 AI 技术怎么从“堆算力”转向“拼算法效率”以及这种转向对医疗、制药、健康管理、机器人这些具体行业意味着什么。报告里反复出现的关键词是算法变革、LFM 模型、低参数量部署和需求应用驱动这几个词串起来其实就是一条从技术能力到行业落地的完整链路。如果你是从业者带着“这份报告能不能帮我判断技术选型”“非 Transformer 架构到底靠不靠谱”“低参数量模型能不能真跑在终端上”这类问题来的那它的价值在于提供了一套可对照的行业坐标系而不是一份泛泛的趋势综述。它适合 AI 应用开发者、技术选型负责人、医疗 AI 产品经理以及想搞清楚大模型下一阶段往哪走的研究人员。下面我按“报告讲了什么 → 怎么用来指导落地 → 哪些地方容易踩坑”的顺序把这份资源拆开讲。2. 算法变革的底层逻辑从 SFT 加 RL 到 LFM 架构选型2.1 少量 SFT 数据加多轮强化学习到底改了什么报告里提到 DeepSeek-R1 采用了一种重新设计的训练流程少量 SFT 数据配合多轮强化学习。这个组合之所以值得单独拿出来说是因为它直接挑战了“数据越多越好、算力越大越好”的传统路径。SFT 负责给模型一个基础的行为框架RL 负责在框架内做精细的策略优化。传统做法往往依赖海量标注数据做监督微调成本高、周期长而且容易过拟合到标注分布上。少量 SFT 加多轮 RL 的思路是用少量高质量样本定方向再用强化学习让模型自己探索更优解。从工程角度看这意味着两件事。第一数据准备的成本结构变了你不再需要几万条标注样本才能启动一个垂直领域微调几百到几千条高质量样本配合合理的奖励设计就可能跑出可用效果。第二训练流程的复杂度从数据侧转移到了奖励函数设计和 RL 调参上这部分目前没有标准答案需要根据业务目标反复试。报告还提到 R1-zero 完全基于 RL 训练没有使用监督训练或人类反馈。这个方向更激进它验证的是模型能否通过自我学习提升性能。对一线开发者来说完全 RL 路线目前更适合做研究验证生产环境里更稳妥的做法还是少量 SFT 加多轮 RL 的混合方案。2.2 LFM 模型为什么值得关注非 Transformer 架构的工程意义报告把 LFMLiquid Foundation Model作为非 Transformer 架构的代表单独提出来说它的性能超越了同等规模的 Transformer 模型。这个信息对做端侧部署的人尤其重要。Transformer 架构的注意力机制在推理时对内存和算力的占用是随序列长度平方增长的这在云端不是大问题但放到终端设备上就是硬约束。LFM 这类非 Transformer 架构的核心优势在于推理效率它用不同的状态更新机制替代了全注意力计算在保持性能的同时把资源占用压下来。选型时怎么判断该不该考虑非 Transformer 路线我一般会看三个条件目标设备的内存是否低于 8GB、推理延迟要求是否在 100ms 以内、任务是否以序列建模为主。如果三个条件都满足LFM 类架构值得做一轮对比测试。如果任务涉及复杂的多模态对齐或长上下文推理Transformer 生态目前还是更成熟的选择。报告没有给出 LFM 的具体参数量级和推理框架这部分需要结合具体模型的开源实现来验证。2.3 低参数量模型与终端部署的参数边界报告提到 2025 年大模型开始分化为高参数量和低参数量两极低参数量模型为本地化部署到 AI 终端提供了可能。这个判断的工程含义是模型压缩和蒸馏技术已经能把可用性能塞进更小的参数空间里。但“低参数量”不是一个固定数字它取决于任务复杂度。我整理了一个粗略的对照表方便做部署前的预判任务类型建议参数量级典型终端内存占用推理框架倾向文本分类/意图识别0.5B 以下1-2GBONNX Runtime / TFLite轻量问答/摘要1B-3B2-4GBllama.cpp / MNN辅助诊断/报告解读3B-7B4-8GBTensorRT-LLM / vLLM复杂推理/多轮对话7B 以上8GB 以上云端部署为主这张表不是绝对标准但能帮你快速判断一个低参数量模型是否值得往终端上搬。报告里提到的医疗 AI 场景比如辅助诊断和病理分析通常落在 3B-7B 这个区间再低可能影响准确性再高则终端扛不住。3. 从报告到落地医疗 AI 与制药场景的接入路径3.1 辅助诊断和病理分析的模型接入步骤报告提到多家医疗相关企业接入了大模型技术用于辅助诊断、病理分析、健康管理。如果你在类似场景做技术接入常见的落地路径分四步。第一步是任务拆解把“辅助诊断”拆成结构化信息抽取、鉴别诊断建议、报告生成三个子任务每个子任务对模型能力的要求不同。第二步是数据准备医疗场景的数据脱敏和标注规范比通用场景严格得多通常需要和业务方一起定义标注 schema。第三步是模型选型结构化抽取用低参数量模型即可鉴别诊断建议需要更高参数量或 RAG 增强。第四步是评估医疗场景不能只看准确率还要看召回率和可解释性。下面是一个用 Python 做医疗文本结构化抽取的示例展示低参数量模型在终端侧的基本调用逻辑# 医疗文本结构化抽取示例从病历文本中提取关键字段 # 适用于 1B-3B 参数量级的本地模型通过 ONNX Runtime 加载 import onnxruntime as ort import numpy as np from transformers import AutoTokenizer # 加载本地模型和分词器模型路径根据实际部署位置调整 model_path ./models/medical_extract_1b.onnx tokenizer AutoTokenizer.from_pretrained(./models/medical_extract_1b) # 创建推理会话医疗终端通常只有 CPU所以用 CPUExecutionProvider session ort.InferenceSession(model_path, providers[CPUExecutionProvider]) def extract_medical_fields(text: str) - dict: 从病历文本中抽取症状、诊断、用药三个字段 # 输入编码max_length 控制在 512 以内以降低终端内存峰值 inputs tokenizer(text, return_tensorsnp, max_length512, truncationTrue) # ONNX 推理需要指定输入名不同模型导出时名称可能不同 ort_inputs { input_ids: inputs[input_ids].astype(np.int64), attention_mask: inputs[attention_mask].astype(np.int64), } # 输出通常是序列标注 logits取 argmax 得到标签序列 logits session.run(None, ort_inputs)[0] predictions np.argmax(logits, axis-1)[0] # 将标签映射回字段label_map 需要和训练时保持一致 label_map {0: O, 1: B-SYMPTOM, 2: I-SYMPTOM, 3: B-DIAGNOSIS, 4: I-DIAGNOSIS, 5: B-DRUG, 6: I-DRUG} tokens tokenizer.convert_ids_to_tokens(inputs[input_ids][0]) result {symptom: [], diagnosis: [], drug: []} current None for token, pred in zip(tokens, predictions): label label_map.get(pred, O) if label.startswith(B-): current label[2:].lower() result[current].append(token) elif label.startswith(I-) and current: result[current].append(token) else: current None # 合并子词并清理特殊 token for key in result: result[key] .join(result[key]).replace(##, ).strip() return result # 调用示例 sample 患者主诉头痛发热三天初步诊断为上呼吸道感染给予布洛芬退热 print(extract_medical_fields(sample))这段代码的逻辑说明模型加载部分用 ONNX Runtime 是为了在无 GPU 的医疗终端上跑推理CPUExecutionProvider 是默认选择。输入编码把 max_length 限制在 512是因为终端内存有限长文本需要先做分段再逐段推理。输出解析部分用的是 BIO 标注体系这是医疗文本抽取里最常见的序列标注格式。参数方面label_map 必须和训练时的标签体系完全一致否则解析结果会错位max_length 根据终端内存调整4GB 内存设备建议不超过 256。3.2 AI 制药场景的靶点发现流程与数据接口报告提到 AI 制药研发中大模型被用于加速靶点发现等流程。靶点发现的核心任务是从海量组学数据中筛选出有潜在成药价值的靶点传统流程依赖专家经验和统计方法周期长。大模型接入后常见的做法是用模型做文献挖掘和知识图谱补全把非结构化的研究文献转成结构化的靶点-疾病-化合物关系再结合图算法做排序。落地时需要注意数据接口的标准化。制药场景的数据源通常包括内部实验数据、公开数据库和文献库格式差异大。我一般会先定义一个统一的实体 schema把靶点、疾病、化合物、通路四类实体和它们之间的关系固定下来再用模型做抽取和归一化。评估环节不能只看模型 loss要看最终筛选出的候选靶点有多少通过了湿实验验证这个反馈周期很长所以前期的小规模验证很重要。3.3 健康管理报告解读的提示词设计报告提到大模型被用于 AI 解读报告的运营。这个场景的技术门槛相对低但对输出稳定性要求高。健康管理报告解读的典型任务是输入一份体检报告的结构化数据输出一段通俗易懂的解读和建议。提示词设计上我一般会把任务拆成“异常项识别 → 风险分级 → 建议生成”三步每一步用独立的提示词模板避免模型在一次生成里同时做太多判断导致遗漏。一个实用的技巧是给模型提供参考范围表。体检指标的正常范围因性别、年龄而异如果不在提示词里显式给出模型容易用通用范围做判断导致误报。把参考范围作为结构化输入的一部分传给模型能显著降低假阳性率。输出格式上建议用 JSON 约束方便后续系统做二次处理和展示。4. 避坑与排查接入大模型时最容易翻车的五个地方4.1 现象模型在测试集上表现好上线后准确率骤降原因通常是数据分布偏移。测试集和线上数据的采集方式、时间窗口、人群构成不一致模型在测试集上过拟合了。医疗场景尤其明显不同科室、不同地区的病历书写习惯差异很大。解决方式是建立线上数据回流机制定期用新数据做评估发现偏移后做增量微调或提示词调整。不要指望一次训练管半年。4.2 现象终端部署后推理延迟超过预期原因可能是模型参数量虽然低但推理框架没有做量化优化或者输入序列长度没有做限制。ONNX 模型如果不做 INT8 量化推理速度可能只有量化后的三分之一。解决方式是先做量化再部署同时把 max_length 控制在任务所需的最小值。另外检查是否误用了 GPUExecutionProvider 但设备没有 GPU这会导致回退到 CPU 时额外开销。4.3 现象强化学习训练过程中奖励不升反降原因通常是奖励函数设计有漏洞模型找到了“刷奖励”的捷径而不是真正学到目标行为。比如奖励函数只惩罚错误答案模型可能学会输出模糊表述来规避惩罚。解决方式是在奖励函数里加入多样性约束和格式约束同时监控模型输出的分布变化。多轮 RL 的轮数不是越多越好一般 3-5 轮后收益递减继续训练反而可能不稳定。4.4 现象非 Transformer 架构模型在微调时 loss 震荡严重原因可能是学习率设置不匹配。LFM 类架构的状态更新机制和 Transformer 不同对学习率的敏感度也不一样。直接套用 Transformer 的学习率配置容易导致训练不稳定。解决方式是从更小的学习率开始做 warmup观察前 100 步的 loss 曲线再决定是否放大。另外检查序列长度是否超过了模型设计的上限超长序列在非 Transformer 架构里可能引发数值不稳定。4.5 现象医疗场景输出被业务方认为“不可解释”原因是大模型的黑盒特性。医疗从业者需要知道模型为什么给出某个建议而不是只看到一个结论。解决方式是在输出里附带证据链比如引用的文献片段、相似病例、指标异常的具体数值。RAG 架构在这方面比纯生成模型更有优势因为检索到的文档可以作为解释依据。如果业务方要求更高可以考虑用规则引擎做后处理把模型输出映射到可解释的决策路径上。5. 进阶技巧用报告里的趋势判断做技术选型验证报告里有一个判断值得单独拿出来做验证AI 技术正从技术能力驱动向需求应用驱动转型。这个判断落到技术选型上意味着评估模型时不能只看 benchmark 分数要看它在具体业务场景里的端到端表现。我一般会用一个三步验证法来做这件事。第一步是定义业务指标。比如辅助诊断场景业务指标可能是“医生采纳率”而不是“诊断准确率”。第二步是构造小规模真实测试集从线上历史数据里抽 200-500 条覆盖典型和边界情况。第三步是对比测试把候选模型和当前方案放在同一测试集上跑看业务指标的差异。下面是一个做对比测试的脚本框架用来批量跑模型并统计业务指标# 模型对比测试框架批量推理并统计业务指标 # 适用于在选定测试集上对比多个候选模型的表现 import json import time from pathlib import Path def load_test_set(path: str) - list: 加载测试集每条包含输入文本和期望输出 with open(path, r, encodingutf-8) as f: return [json.loads(line) for line in f] def run_model(model_fn, test_set: list) - dict: 对单个模型跑完整测试集返回指标统计 results [] total_latency 0 for item in test_set: start time.time() output model_fn(item[input]) latency time.time() - start total_latency latency # 这里用简单的字符串匹配做示例实际场景需要更细的评估逻辑 correct item[expected] in output results.append({correct: correct, latency: latency}) accuracy sum(r[correct] for r in results) / len(results) avg_latency total_latency / len(results) return {accuracy: accuracy, avg_latency: avg_latency, total: len(results)} def compare_models(models: dict, test_set: list) - None: 对比多个模型输出对比表格 print(f{模型:20} {准确率:10} {平均延迟(ms):15}) print(- * 45) for name, fn in models.items(): metrics run_model(fn, test_set) print(f{name:20} {metrics[accuracy]:10.2%} {metrics[avg_latency]*1000:15.1f}) # 使用示例定义两个候选模型的推理函数 # models {当前方案: current_model_fn, 候选模型A: candidate_a_fn} # test_set load_test_set(./test_set.jsonl) # compare_models(models, test_set)这段脚本的关键参数说明test_set 的规模建议控制在 200-500 条太少统计不显著太多跑一轮时间成本高。latency 统计的是单条推理时间实际部署还要考虑并发和批处理的影响。accuracy 的计算逻辑需要根据业务场景替换医疗场景建议用召回率优先的评估方式。验证完之后如果候选模型在业务指标上确实有提升再考虑做更大规模的灰度测试。如果提升不明显不要因为 benchmark 分数高就强行切换需求应用驱动的核心是业务效果说话。从那以后我每次做技术选型都会先跑一轮小规模业务验证再决定要不要深入这个习惯帮我省了不少返工时间。希望帮到你。本文还有配套的精品资源点击获取