这两年医疗 AI 的讨论热度一直很高但大多数演示还停留在“上传一张 CT 图片模型输出一段诊断建议”这种离线场景。真正落到线上问诊系统时输入从静态图片变成了一路连续的视频流模型要一边听患者说话、一边观察面色和肢体动作、一边检索医学知识还要在医生和患者都在等待的几秒内给出有参考价值的提示工程复杂度完全不是一个量级。本文围绕“Towards Expert-level Medical AI for Real-time Video Consultations”这个方向从工程落地视角拆解实时视频问诊中的 Medical AI 系统先讲清楚它解决的问题和技术边界再给出一个可运行的辅助问诊原型包含语音识别、视频帧分析、医学推理和知识检索的完整实现思路最后整理实时场景下的延迟排查、评测方法和合规建议。适合正在做医疗 AI 应用、语音视频系统集成或大模型落地的开发者参考。1. 实时视频问诊中的 Medical AI 是什么1.1 从离线诊断到实时视频问诊在传统的 AI 辅助诊断流程里系统通常接收一张医学影像或一段文本主诉经过模型推理后输出结论。这种模式有几个明显特点输入是静态的、任务边界清晰、推理时间可以放宽到秒级甚至分钟级。而实时视频问诊完全不同。医生和患者通过音视频连线沟通AI 系统需要同时处理三路信息音频信息患者的主诉、病史、用药情况以及语气、语速等非语言信息视频信息患者的面色、精神状态、皮肤表现、呼吸频率等可见体征文本信息医生可能同时查看患者的历史病历、检查报告、过敏史等结构化数据。这意味着 Medical AI 不再是“单模型单输入”而是一套多模态实时计算引擎。视频流从摄像头到 AI 服务端的延迟、语音转写的实时性、大模型推理的响应时间、知识检索的命中率都会直接影响线上体验。这也是“专家级”这个目标背后真正的难点。1.2 Medical AI 的定位辅助还是替代这里必须明确一个边界当前医疗 AI 产品的定位是“辅助决策”而不是“替代医生”。尤其在实时视频问诊场景中AI 的价值更多体现在四个方面信息结构化自动把医患对话整理成主诉、现病史、既往史等结构化字段实时提醒在医生可能遗漏关键问题、或患者描述与常见病程不匹配时给出提醒知识增强基于患者当前描述实时检索药品说明、指南要点、相似病例文书自动生成问诊结束后自动生成病历草稿和随访计划减少医生打字负担。系统输出的是“参考信息”最终决策权和法律责任都在医生身上。这个定位不仅决定产品设计也决定技术实现比如提示词约束、权限控制、日志审计都需要围绕“辅助”来设计。1.3 本文的讨论范围本文不讨论如何从零训练一个医学大模型而是聚焦在工程集成层把语音识别、视频帧理解、医学大模型推理、知识检索这些成熟组件串成一套实时视频问诊辅助系统。换句话说假设底层 ASR 模型、LLM 接口已经具备基础能力重要的是如何让它们在真实问诊链路中稳定、低延迟、安全地协同工作。2. 系统整体架构与核心模块2.1 一条完整的实时视频问诊链路先看端到端的数据流。以浏览器问诊为例前端采集摄像头和麦克风数据通过 WebRTC 推流到媒体服务器媒体服务器一方面把音视频转发给医生端另一方面把音频和视频帧旁路给 AI 分析服务。AI 分析的中间结果通过 WebSocket 推送给医生端页面以提示卡片的形式呈现。这条链路可以拆成五个环节采集端浏览器或 App负责音视频采集、编解码、弱网处理传输层WebRTC/SFU负责低延迟推流、转发、录制AI 接入层把音视频流转成 ASR 和视频帧分析能处理的格式医学推理层结合转写文本、视频描述、历史病历和知识检索结果生成辅助结论反馈与审计层把结果推送给医生端并记录完整的分析过程和依据。这五个环节中AI 接入层和医学推理层是文章重点因为大多数实时问诊工程问题都出现在这里。2.2 各模块职责拆分音视频接入模块接收 WebRTC 轨道或拉流地址音频送入 ASR视频按策略抽帧。这个模块要保证低延迟和资源可控不能为了一帧画面等太久。语音识别模块ASR实时把医生和患者的对话转成文字同时输出说话人标记和时间戳。中文医疗场景中专业术语多、口语化明显ASR 需要加载医学词汇表。视频理解模块对面部、皮肤、精神状态进行基础分析。注意这里不建议直接让模型做复杂诊断而是做“可见体征提取”例如面色是否苍白、是否出汗、精神状态是否萎靡再把这些观察作为文本提供给推理层。医学推理模块核心是 LLM 调用输入包括转写文本、视频观察结果、RAG 检索到的医学知识输出结构化建议例如鉴别诊断方向、需要补充的追问、风险预警等。知识检索模块RAG为 LLM 提供外部知识解决模型知识陈旧和幻觉问题。常见做法是把药品说明书、临床指南、疾病科普语料向量化后存入向量数据库推理前做相似度检索。会话管理模块维护问诊上下文包括历史对话、患者基本信息、医生标记信息控制进入 LLM 的上下文长度同时负责把中间结果缓存起来避免重复转写和重复检索。2.3 实时性与准确性的矛盾实时视频问诊对延迟的敏感度远高于普通聊天机器人。医生问完一个问题如果 AI 提示要 10 秒后才出现体验就很差。但医学场景又要求准确不能为了快而输出没有检索依据的结论。工程上权衡的策略是分层处理。把“实时性要求高、计算简单”的任务放在前面比如 ASR把“准确性要求高、计算量大”的任务放在后面并且使用异步推送。例如转写完成后立即把文本推给医生端展示同时后台并行完成知识检索和 LLM 推理推理结果出来后再推送第二张卡片这样用户感知到的延迟会被摊薄。3. 环境准备与项目结构3.1 运行环境本文示例在以下环境中验证通过供参考操作系统Ubuntu 22.04 / macOS 13Python3.10 或以上依赖管理pip virtualenvASR 模型faster-whisper使用 small 或 medium 模型LLM 接口OpenAI 兼容接口也可换成其他兼容服务其他ffmpeg用于音频格式处理、Redis可选用于会话缓存如果你的服务器没有 GPUASR 和向量模型可以切到 CPU 推理速度会慢一些建议把模型量化为 int8或者只跑 small 版本。3.2 Python 依赖pip install fastapi uvicorn websockets faster-whisper openai numpy opencv-python sentence-transformers faiss-cpu python-multipartfastapi和uvicorn用来搭建 WebSocket 服务和 HTTP 接口faster-whisper负责语音实时转写openai用来调用大模型接口opencv-python负责视频帧读取和基础图像处理sentence-transformers和faiss-cpu用来做医学知识检索numpy作为向量计算基础库。3.3 项目目录结构medical-ai-video/ ├── main.py # FastAPI 入口WebSocket 服务 ├── asr_service.py # 语音识别模块 ├── video_analyzer.py # 视频帧分析模块 ├── medical_engine.py # 医学推理模块 ├── rag_service.py # 知识检索模块 ├── prompt_templates.py # 提示词和 JSON 输出格式定义 ├── requirements.txt ├── data/ │ └── medical_kb/ # 医学知识文本 └── logs/这里把功能拆成独立文件方便后续扩展。如果团队更大按服务拆分部署更合理这个稍后在工程化章节展开。4. 核心能力拆解4.1 实时语音识别ASR 模块设计实时语音识别的关键不是“转写准”而是“边说话边出结果”。一次性把整段音频送过去识别延迟无法接受。更常见的做法是分片转写把音频流切成 2-5 秒的片段配合语音活动检测VAD判断说话开始和结束有语音才识别没语音就丢掉。下面是一个基于 faster-whisper 的代码示例# 文件路径asr_service.py from faster_whisper import WhisperModel import numpy as np class ASRService: def __init__(self, model_size: str small, device: str auto): # 使用 int8 量化可以显著降低显存占用和推理延迟 self.model WhisperModel( model_size, devicedevice, compute_typeint8 ) def transcribe(self, audio_bytes: bytes, language: str zh): 输入 PCM 音频字节返回转写文本和片段信息 # faster-whisper 支持直接读取二进制缓冲区 segments, info self.model.transcribe( audio_bytes, languagelanguage, vad_filterTrue, # 过滤静音减少无效识别 beam_size1, # 实时场景用 beam1 降低延迟 without_timestampsFalse ) text_parts [] ts_parts [] for segment in segments: text_parts.append(segment.text) ts_parts.append({ start: segment.start, end: segment.end, text: segment.text }) return { text: .join(text_parts), segments: ts_parts }代码里有两个关键参数需要说明。vad_filterTrue会过滤掉没有语音的片段在问诊场景中特别有用。医生和患者不会一直说话中间会有停顿如果没有 VADwhisper 会把停顿误识别成无意义的语气词甚至产生幻觉文本。beam_size1是实时识别的常用策略。beam size 越大识别越准但解码时间越长。在实时链路里通常先用 beam1 快速出结果后续如果有需要再对答案做二次校验。医疗场景中如果对准确率要求较高可以改成 beam5但要做好延迟增加的心理准备。4.2 视频帧理解从抽帧到可见体征提取实时视频流不能每帧都送进模型会造成极大的计算浪费同时也没有必要。工程上通常按固定间隔抽帧例如每 3-5 秒抽一帧再用轻量模型做分析。# 文件路径video_analyzer.py import cv2 import base64 import numpy as np class VideoAnalyzer: def __init__(self): # 这里用 opencv 做人脸检测实际项目可换成更轻量的模型 self.face_cascade cv2.CascadeClassifier( cv2.data.haarcascades haarcascade_frontalface_default.xml ) def analyze_frame(self, frame_bgr: np.ndarray): 输入一帧 BGR 图像输出基础观察结果 gray cv2.cvtColor(frame_bgr, cv2.COLOR_BGR2GRAY) faces self.face_cascade.detectMultiScale( gray, scaleFactor1.1, minNeighbors5, minSize(80, 80) ) result { has_face: len(faces) 0, face_count: len(faces), image_quality_ok: True, luminance: float(np.mean(gray)), observation: None } if not result[has_face]: result[image_quality_ok] False result[observation] 未检测到人脸请提醒患者正对摄像头 return result avg_lum result[luminance] if avg_lum 50: result[image_quality_ok] False result[observation] 画面偏暗可见体征难以判断 elif avg_lum 200: result[image_quality_ok] False result[observation] 画面过亮可能存在过度曝光 # 简化示例真正生产环境可以用多模态模型生成文本描述 result[observation] result[observation] or 视频画面质量正常可进一步分析 return result视频模块的核心思路是“质量判断”和“体征提取”分离。先判断当前帧是否适合分析比如有没有人脸、曝光是否正常、是否模糊只有质量合格的帧才进入下一步。这里的“下一步”建议接入多模态模型把图像转成文字描述例如“面色苍白精神状态不佳嘴唇干燥”。因为后续医学推理层的 LLM 主要处理文本统一转成文本能让推理层保持简单。多模态模型可以直接用 OpenAI 兼容的图像输入接口也可以委托给专门的视觉模型服务。def frame_to_base64(frame_bgr: np.ndarray) - str: _, buffer cv2.imencode(.jpg, frame_bgr, [cv2.IMWRITE_JPEG_QUALITY, 80]) return base64.b64encode(buffer).decode(utf-8)这一段代码把帧压缩成 JPEG 再转 base64是为了传给多模态模型接口时节省带宽。编码质量设为 80 左右比较合适太低会影响模型判断太高会增加传输耗时。4.3 医学推理引擎提示词与结构化输出医学推理引擎是整套系统的“大脑”。它负责把 ASR 转写文本、视频观察结果、RAG 检索到的医学知识拼装成提示词调用 LLM 生成结构化输出。核心设计要点有两个任务边界清晰、输出格式固定。任务边界清晰指的是让模型做“信息整理和参考建议”而不是让它给出确定性诊断。比如提示词里明确要求“输出鉴别诊断方向”而不是“确诊疾病”。输出格式固定则通过 JSON Schema 约束方便系统下游解析和展示。下面是一个简化版的医学推理引擎# 文件路径medical_engine.py import json from openai import OpenAI class MedicalEngine: def __init__(self, api_key: str, base_url: str None, model: str gpt-4o-mini): self.client OpenAI(api_keyapi_key, base_urlbase_url) self.model model def generate_suggestions( self, dialogue_text: str, video_observation: str, knowledge_texts: list[str], patient_info: dict | None None ) - dict: # 拼装系统提示词 system_prompt 你是一名资深全科医生的 AI 助理在实时视频问诊中为医生提供参考信息。 你的任务包括 1. 提取患者的主诉、现病史、既往史、用药史 2. 总结视频观察到的可见体征 3. 基于检索到的医学知识给出鉴别诊断方向 4. 标记需要医生重点关注的风险信息。 注意 - 你只提供辅助参考不能做出最终诊断 - 如果信息不足明确列出需要补充的问题 - 所有输出必须使用 JSON 格式。 user_content { dialogue: dialogue_text, video_observation: video_observation, knowledge: knowledge_texts, patient_info: patient_info or {} } response self.client.chat.completions.create( modelself.model, response_format{type: json_object}, messages[ {role: system, content: system_prompt}, {role: user, content: json.dumps(user_content, ensure_asciiFalse)} ], temperature0.2, max_tokens1024 ) raw response.choices[0].message.content return json.loads(raw)温度设置为 0.2目的是减少随机性让模型在医学场景下更稳定。如果在实际测试中发现输出仍然不稳定可以进一步使用结构化输出功能甚至把候选答案限定在预设枚举值里。要注意的是这个模块是容易出问题的地方。LLM 返回的 JSON 偶尔会有格式错误、多出注释、或者字段缺失。生产环境一定要加一层解析兜底解析失败时标记为“暂不展示 AI 建议”而不是让异常直接抛到前端。4.4 RAG 知识检索让模型有据可依医学 LLM 单独使用会有两个问题专业知识更新不及时以及可能对不熟悉的药物或疾病产生幻觉。RAG检索增强生成是对抗幻觉的常用手段。思路很简单提前把权威的药品说明书、医学指南等文本切块计算向量后存入 FAISS 索引推理前用当前对话内容去检索最相关的文本块把这些文本块作为参考注入 LLM 提示词。# 文件路径rag_service.py from sentence_transformers import SentenceTransformer import faiss import numpy as np import os class RAGService: def __init__(self, kb_dir: str data/medical_kb): self.encoder SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) self.kb_dir kb_dir self.chunks [] self.index None self._build_index() def _build_index(self): 遍历知识库目录中的文本文件切块并建立向量索引 texts [] for root, _, files in os.walk(self.kb_dir): for fname in files: if not fname.endswith(.txt): continue path os.path.join(root, fname) with open(path, r, encodingutf-8) as f: content f.read() # 简单按段落切块生产环境可以按语义切块 for para in content.split(\n\n): para para.strip() if len(para) 20: texts.append(para) if not texts: return self.chunks texts embeddings self.encoder.encode(texts, normalize_embeddingsTrue) dim embeddings.shape[1] self.index faiss.IndexFlatIP(dim) self.index.add(np.asarray(embeddings, dtypenp.float32)) def search(self, query: str, top_k: int 3): if not self.index: return [] q_vec self.encoder.encode([query], normalize_embeddingsTrue) scores, indices self.index.search(np.asarray(q_vec, dtypenp.float32), top_k) results [] for score, idx in zip(scores[0], indices[0]): if idx len(self.chunks): results.append({ text: self.chunks[idx], score: float(score) }) return results示例中使用了多语言向量模型因为问诊对话可能是中英文混合。知识库文件切块时不能切得太碎否则语义会不完整也不能一整个文件作为一条记录否则检索精度会下降而且会把大量无关信息塞进 LLM 上下文。通常控制在 200-500 字之间。检索结果里带上相似度分数方便判断检索质量。如果分数低于阈值说明知识库没有相关内容可以考虑不注入检索结果直接让推理引擎基于对话内容输出提示并在前端标注“未检索到相关指南”。5. 实战案例搭建实时视频问诊辅助原型5.1 设计思路下面用 FastAPI 搭建一个可运行的简化原型。考虑到完整 WebRTC 信令和媒体服务器实现比较复杂原型采用“浏览器采集音视频 → 通过 WebSocket 推流 → 服务端做 AI 分析”的方式重点演示 AI 侧的处理逻辑。浏览器端每 3 秒推送一次音频字节和视频帧服务端分别调用 ASR 和视频分析模块再把结果送入医学推理引擎最终返回 JSON 提示卡片。# 文件路径main.py import asyncio import json import base64 import numpy as np import cv2 from fastapi import FastAPI, WebSocket from asr_service import ASRService from video_analyzer import VideoAnalyzer from medical_engine import MedicalEngine from rag_service import RAGService app FastAPI() asr ASRService(model_sizesmall, deviceauto) video_analyzer VideoAnalyzer() rag RAGService() engine MedicalEngine( api_keyyour-api-key, base_urlNone, # 本地或自建服务请填写实际地址 modelyour-model-name ) app.websocket(/ws/analyze) async def websocket_analyze(ws: WebSocket): await ws.accept() dialogue_buffer [] try: while True: message await ws.receive_text() data json.loads(message) if data[type] audio: # 音频是 base64 编码的 PCM 字节 audio_bytes base64.b64decode(data[data]) loop asyncio.get_event_loop() asr_result await loop.run_in_executor( None, asr.transcribe, audio_bytes ) if asr_result[text]: dialogue_buffer.append(asr_result[text]) await ws.send_text(json.dumps({ type: transcript, data: asr_result[text] }, ensure_asciiFalse)) elif data[type] video: # 视频是 base64 编码的 JPEG 帧 frame_bytes base64.b64decode(data[data]) frame cv2.imdecode( np.frombuffer(frame_bytes, dtypenp.uint8), cv2.IMREAD_COLOR ) v_result video_analyzer.analyze_frame(frame) # 如果画面质量合格才做多模态分析 if v_result[image_quality_ok]: # 这里省略多模态接口调用可以传入 frame 给视觉模型 pass elif data[type] trigger_ai: # 前端通知可以生成阶段性建议 dialogue_text .join(dialogue_buffer[-20:]) knowledge rag.search(dialogue_text, top_k3) video_obs 视频画面正常无特殊发现 suggestions engine.generate_suggestions( dialogue_textdialogue_text, video_observationvideo_obs, knowledge_texts[item[text] for item in knowledge] ) await ws.send_text(json.dumps({ type: suggestion, data: suggestions }, ensure_asciiFalse)) except Exception as e: print(fWebSocket 连接异常: {e}) finally: await ws.close()5.2 前端推送脚本为了让原型可以直接验证我也写了一个简单的 Python 客户端模拟浏览器推送音频和视频数据。实际项目中这段逻辑会放在浏览器里采集麦克风和摄像头数据后推送到服务端。# 文件路径client_simulator.py import asyncio import json import base64 import cv2 import soundfile as sf import numpy as np import websockets async def send_samples(uri: str): # 读取一段预录音频 audio_data, sr sf.read(sample.wav, dtypeint16) # 读取视频帧 cap cv2.VideoCapture(sample_video.mp4) async with websockets.connect(uri) as ws: # 发送音频片段模拟实时语音流 chunk_size sr * 3 # 3 秒一个片段 for i in range(0, len(audio_data), chunk_size): chunk audio_data[i:i chunk_size] payload base64.b64encode(chunk.tobytes()).decode(utf-8) await ws.send(json.dumps({type: audio, data: payload})) # 发送视频帧 while True: ret, frame cap.read() if not ret: break _, frame_enc cv2.imencode(.jpg, frame) payload base64.b64encode(frame_enc.tobytes()).decode(utf-8) await ws.send(json.dumps({type: video, data: payload})) # 触发 AI 推理 await ws.send(json.dumps({type: trigger_ai, data: })) # 接收返回结果 async for response in ws: print(response) asyncio.run(send_samples(ws://localhost:8000/ws/analyze))5.3 启动与验证在项目根目录启动服务uvicorn main:app --host 0.0.0.0 --port 8000然后运行客户端模拟器python client_simulator.py预期你会看到三类输出transcriptASR 转写出来的文本suggestion医学推理引擎给出的 JSON 建议视频质量相关提示。如果 ASR 返回空文本说明音频格式或采样率不对需要检查客户端发送的 PCM 数据是否与服务端模型期望的采样率一致。faster-whisper 支持 16kHz 单声道音频如果采集到的是 48kHz需要先重采样。5.4 结果说明这个原型虽然简化了 WebRTC 传输但 AI 侧的核心链路已经完整音频转写、视频帧质量判断、知识检索、LLM 推理、WebSocket 返回。把它迁移到真实视频问诊系统时只需要把“WebSocket 接收音视频”替换成“从媒体服务器读取音视频轨道”AI 逻辑可以完整复用。6. 从“能用”到“专家级”评测与优化6.1 离线医学基准评测评估一个医疗 AI 系统是否“专家级”不能只看演示效果需要回到标准数据集上对比。常见的医学基准包括 MedQA、CMB 等用于衡量模型的医学知识水平。工业界在推进医疗大模型时通常会做一批科室级评测集覆盖内科、外科、儿科、皮肤科等。针对实时视频问诊还应该单独构建多模态评测集给出一段视频片段和对话转写序列要求系统输出主诉、现病史、鉴别方向、风险提示然后由医生标注对比。评测指标上推荐使用字段级 F1而不是只看整体准确率。因为系统输出是结构化 JSON主诉提取对不对、鉴别诊断方向是否合理、风险标记是否命中这些字段要分开评估。这样定位问题也更清楚是 ASR 出错了还是检索不相关还是推理逻辑有问题。6.2 在线实时指标离线评测解决“模型能力”问题在线指标解决“体验质量”问题。在实时视频问诊场景中建议至少监控四类指标ASR 转写时延从音频输入到文本输出的时间目标小于 1.5 秒端到端提示时延从医生触发 AI 到前端展示建议卡片的时间目标小于 5 秒AI 建议采纳率医生在问诊中实际采纳或引用了多少条 AI 提示用户满意度患者和医生对问诊过程的主观评分。其中“建议采纳率”特别重要。它直接反映 AI 是否有用如果一个系统产出的提示医生从来不用准确率再高也是自嗨。6.3 延迟预算拆解端到端 5 秒的目标不是随便定的。把它拆开看每部分都要卡得很紧环节延迟预算音频分片与传输500msASR 转写1.5s触发推理与上下文组装300msRAG 检索300msLLM 推理1.5s - 2.5s结果回传与渲染200ms如果 LLM 推理是主要瓶颈可以考虑流式输出先让前端展示文本片段最后再回填结构化 JSON。如果检索耗时长则要检查向量索引规模、编码模型推理速度必要时改成服务端预计算加缓存。7. 常见问题与排查思路7.1 ASR 转写文本乱码或为空现象客户端推入音频后返回的文本是乱码或空。常见原因音频格式不对whisper 期望 16kHz 单声道 PCM而客户端发的是 48kHz 或双声道音频字节没有去除 WAV 文件头VAD 过滤掉了所有声音可能由于音频本身太轻或噪音太大。解决思路先用 ffprobe 查看音频采样率和通道数统一在客户端重采样到 16kHz单声道临时关闭vad_filter测试确认是识别问题还是 VAD 误过滤。ffprobe -show_streams sample.wav | grep -E sample_rate|channels7.2 LLM 输出 JSON 解析失败现象json.loads抛异常推荐结果为null。常见原因大模型返回了 Markdown 代码块包裹的 JSON返回内容中夹杂了解释性文字输出长度超过max_tokens被截断。解决思路解析前先做内容清洗例如去除 json 标记设置response_format{type: json_object}解析失败时进入兜底分支直接展示原始文本不要中断问诊流程。7.3 视频帧模糊或无法提取特征现象视频分析模块频繁提示“未检测到人脸”或“画面质量差”。常见原因网络分辨率过低实际帧尺寸只有 320x240光线太暗或背光抽帧时机正好在画面切换过渡帧。解决思路在客户端限制最小分辨率抽帧前做基础质量评估丢弃清晰度低的帧连续多帧失败时提示患者调整摄像头或光线。7.4 音频和视频不同步现象转写文本已经出来但对应的视频观察结果滞后。常见原因音频和视频走了两条独立的处理链路没有共享时间戳网络拥塞导致视频帧排队。解决思路在推流端给每一段音频和每一帧视频打上同步时钟戳服务端按时间戳对齐后再送 AI 分析如果无法对齐宁可丢弃过期的视频帧也不能让推理等待太久。7.5 合规顾虑现象项目准备上线但合规评审提出多个无法回答的问题。常见原因不清楚音视频数据存储在哪里、保存多久、谁能访问没有告知患者 AI 正在参与辅助分析缺少完整的审计日志无法追溯每一次 AI 建议的依据。解决思路数据加密存储按最小权限原则设置访问控制在问诊前增加 AI 辅助说明和用户授权使用脱敏后的数据来训练或评测模型避免直接用真实问诊数据记录每次 AI 建议的输入、输出、检索来源和模型版本方便事后审计。8. 工程化与合规建议8.1 服务拆分与部署原型把多个 AI 模块放在同一个进程里方便演示。生产环境建议按职责拆分部署至少拆成三组服务网关与媒体服务负责 WebRTC、音视频转发、录制AI 分析服务负责 ASR、视频分析、RAG 检索这些模块计算密集需要独立扩缩容推理服务负责大模型调用需要根据请求量做 QPS 控制。不同服务使用不同的资源规格。ASR 需要 GPU 或者较强的 CPU视频分析可以混部向量检索用内存型实例大模型推理则要看采用的部署方式。不要把所有服务塞进一个容器否则一个模块的高负载会影响整条链路。8.2 敏感信息处理医疗音视频属于个人敏感信息工程上必须遵守“最小收集”原则。建议做到视频流默认不落盘只在需要质控时经过授权后录制音频转写文本存储前先做去标识化例如去掉姓名、身份证号等模型调用日志只保留脱敏文本不保留原始音视频外部 LLM API 调用前对文本做脱敏处理避免把患者隐私发送到外部服务。如果业务涉及数据传输和存储还需要考虑本地化部署方案把数据留在受控区域内并做访问审批留痕。8.3 医生兜底与人工复核机制不管 AI 建议看起来多准确最终必须保留医生确认环节。产品设计上建议做到AI 建议卡片不直接写“诊断结果”而写“参考方向”医生端有“采纳”“忽略”“标记错误”三个操作用于反馈 AI 质量对高危风险提示UI 上使用不同颜色强调并提醒医生确认但不能阻断问诊流程定期抽检 AI 建议和医生最终病历的一致性发现系统性问题后回炉优化模型或知识库。把医生标记为“错误”的样本收集起来是最有价值的评测数据。这类数据反映了模型在真实场景中的短板比任何公开数据集都更能指导迭代。8.4 日志与审计医疗 AI 系统的审计要求比普通系统严格。每次 AI 推理建议都建议记录以下字段{ session_id: 问诊会话ID, request_time: 2025-01-01T10:00:00Z, input: { dialogue_text: 脱敏后的对话文本, video_observation: 视频观察结果, kbs: [知识库条目ID列表] }, output: 模型输出的 JSON 提示, model_version: v1.2.0, latency_ms: 3210 }审计日志不能只记录最后输出还要记录检索用到了哪些知识库条目方便追溯 AI 建议的依据。模型版本也要记录因为大模型服务端经常更新同一个问题在不同版本下可能有不同回答没有版本信息问题排查会非常困难。9. 总结与下一步实践方向从技术角度看“专家级医疗 AI 实时视频问诊”本质上不是一个单一模型问题而是一个多模态实时系统工程。本文拆解了音视频接入、语音识别、视频帧理解、知识检索、医学推理、结果反馈这六层链路并给出了一个可直接运行的辅助问诊原型。核心代码可以迁移到真实 WebRTC 问诊系统重点不在代码本身而在链路协作方式ASR 实时出文本、RAG 提供依据、LLM 做结构化推理、医生做最终决策。如果要在真实项目中继续深入建议按这个顺序推进先上线“转写 结构化病历摘要”让医生减少打字负担再加入“RAG 知识提示”提升回答的权威性最后再逐步加入多模态视频体征分析并且每一步都建立医生反馈闭环。风险上优先关注数据合规、模型幻觉和延迟体验这三块不过关医学准确率再高也很难真正落地。下一阶段值得关注的方向是端侧小模型与云端大模型的协同例如用端侧 ASR 做低延迟转写、云端 LLM 做深度推理以及基于视频连续帧的行为分析而不只是逐帧图片判断。希望这篇文章能帮你在实时医疗 AI 的工程落地上少踩一些坑。如果对你有帮助可以收藏备用实战中遇到具体问题也欢迎在评论区交流。 实时视频问诊中的医疗AI：多模态引擎与工程落地
这两年医疗 AI 的讨论热度一直很高但大多数演示还停留在“上传一张 CT 图片模型输出一段诊断建议”这种离线场景。真正落到线上问诊系统时输入从静态图片变成了一路连续的视频流模型要一边听患者说话、一边观察面色和肢体动作、一边检索医学知识还要在医生和患者都在等待的几秒内给出有参考价值的提示工程复杂度完全不是一个量级。本文围绕“Towards Expert-level Medical AI for Real-time Video Consultations”这个方向从工程落地视角拆解实时视频问诊中的 Medical AI 系统先讲清楚它解决的问题和技术边界再给出一个可运行的辅助问诊原型包含语音识别、视频帧分析、医学推理和知识检索的完整实现思路最后整理实时场景下的延迟排查、评测方法和合规建议。适合正在做医疗 AI 应用、语音视频系统集成或大模型落地的开发者参考。1. 实时视频问诊中的 Medical AI 是什么1.1 从离线诊断到实时视频问诊在传统的 AI 辅助诊断流程里系统通常接收一张医学影像或一段文本主诉经过模型推理后输出结论。这种模式有几个明显特点输入是静态的、任务边界清晰、推理时间可以放宽到秒级甚至分钟级。而实时视频问诊完全不同。医生和患者通过音视频连线沟通AI 系统需要同时处理三路信息音频信息患者的主诉、病史、用药情况以及语气、语速等非语言信息视频信息患者的面色、精神状态、皮肤表现、呼吸频率等可见体征文本信息医生可能同时查看患者的历史病历、检查报告、过敏史等结构化数据。这意味着 Medical AI 不再是“单模型单输入”而是一套多模态实时计算引擎。视频流从摄像头到 AI 服务端的延迟、语音转写的实时性、大模型推理的响应时间、知识检索的命中率都会直接影响线上体验。这也是“专家级”这个目标背后真正的难点。1.2 Medical AI 的定位辅助还是替代这里必须明确一个边界当前医疗 AI 产品的定位是“辅助决策”而不是“替代医生”。尤其在实时视频问诊场景中AI 的价值更多体现在四个方面信息结构化自动把医患对话整理成主诉、现病史、既往史等结构化字段实时提醒在医生可能遗漏关键问题、或患者描述与常见病程不匹配时给出提醒知识增强基于患者当前描述实时检索药品说明、指南要点、相似病例文书自动生成问诊结束后自动生成病历草稿和随访计划减少医生打字负担。系统输出的是“参考信息”最终决策权和法律责任都在医生身上。这个定位不仅决定产品设计也决定技术实现比如提示词约束、权限控制、日志审计都需要围绕“辅助”来设计。1.3 本文的讨论范围本文不讨论如何从零训练一个医学大模型而是聚焦在工程集成层把语音识别、视频帧理解、医学大模型推理、知识检索这些成熟组件串成一套实时视频问诊辅助系统。换句话说假设底层 ASR 模型、LLM 接口已经具备基础能力重要的是如何让它们在真实问诊链路中稳定、低延迟、安全地协同工作。2. 系统整体架构与核心模块2.1 一条完整的实时视频问诊链路先看端到端的数据流。以浏览器问诊为例前端采集摄像头和麦克风数据通过 WebRTC 推流到媒体服务器媒体服务器一方面把音视频转发给医生端另一方面把音频和视频帧旁路给 AI 分析服务。AI 分析的中间结果通过 WebSocket 推送给医生端页面以提示卡片的形式呈现。这条链路可以拆成五个环节采集端浏览器或 App负责音视频采集、编解码、弱网处理传输层WebRTC/SFU负责低延迟推流、转发、录制AI 接入层把音视频流转成 ASR 和视频帧分析能处理的格式医学推理层结合转写文本、视频描述、历史病历和知识检索结果生成辅助结论反馈与审计层把结果推送给医生端并记录完整的分析过程和依据。这五个环节中AI 接入层和医学推理层是文章重点因为大多数实时问诊工程问题都出现在这里。2.2 各模块职责拆分音视频接入模块接收 WebRTC 轨道或拉流地址音频送入 ASR视频按策略抽帧。这个模块要保证低延迟和资源可控不能为了一帧画面等太久。语音识别模块ASR实时把医生和患者的对话转成文字同时输出说话人标记和时间戳。中文医疗场景中专业术语多、口语化明显ASR 需要加载医学词汇表。视频理解模块对面部、皮肤、精神状态进行基础分析。注意这里不建议直接让模型做复杂诊断而是做“可见体征提取”例如面色是否苍白、是否出汗、精神状态是否萎靡再把这些观察作为文本提供给推理层。医学推理模块核心是 LLM 调用输入包括转写文本、视频观察结果、RAG 检索到的医学知识输出结构化建议例如鉴别诊断方向、需要补充的追问、风险预警等。知识检索模块RAG为 LLM 提供外部知识解决模型知识陈旧和幻觉问题。常见做法是把药品说明书、临床指南、疾病科普语料向量化后存入向量数据库推理前做相似度检索。会话管理模块维护问诊上下文包括历史对话、患者基本信息、医生标记信息控制进入 LLM 的上下文长度同时负责把中间结果缓存起来避免重复转写和重复检索。2.3 实时性与准确性的矛盾实时视频问诊对延迟的敏感度远高于普通聊天机器人。医生问完一个问题如果 AI 提示要 10 秒后才出现体验就很差。但医学场景又要求准确不能为了快而输出没有检索依据的结论。工程上权衡的策略是分层处理。把“实时性要求高、计算简单”的任务放在前面比如 ASR把“准确性要求高、计算量大”的任务放在后面并且使用异步推送。例如转写完成后立即把文本推给医生端展示同时后台并行完成知识检索和 LLM 推理推理结果出来后再推送第二张卡片这样用户感知到的延迟会被摊薄。3. 环境准备与项目结构3.1 运行环境本文示例在以下环境中验证通过供参考操作系统Ubuntu 22.04 / macOS 13Python3.10 或以上依赖管理pip virtualenvASR 模型faster-whisper使用 small 或 medium 模型LLM 接口OpenAI 兼容接口也可换成其他兼容服务其他ffmpeg用于音频格式处理、Redis可选用于会话缓存如果你的服务器没有 GPUASR 和向量模型可以切到 CPU 推理速度会慢一些建议把模型量化为 int8或者只跑 small 版本。3.2 Python 依赖pip install fastapi uvicorn websockets faster-whisper openai numpy opencv-python sentence-transformers faiss-cpu python-multipartfastapi和uvicorn用来搭建 WebSocket 服务和 HTTP 接口faster-whisper负责语音实时转写openai用来调用大模型接口opencv-python负责视频帧读取和基础图像处理sentence-transformers和faiss-cpu用来做医学知识检索numpy作为向量计算基础库。3.3 项目目录结构medical-ai-video/ ├── main.py # FastAPI 入口WebSocket 服务 ├── asr_service.py # 语音识别模块 ├── video_analyzer.py # 视频帧分析模块 ├── medical_engine.py # 医学推理模块 ├── rag_service.py # 知识检索模块 ├── prompt_templates.py # 提示词和 JSON 输出格式定义 ├── requirements.txt ├── data/ │ └── medical_kb/ # 医学知识文本 └── logs/这里把功能拆成独立文件方便后续扩展。如果团队更大按服务拆分部署更合理这个稍后在工程化章节展开。4. 核心能力拆解4.1 实时语音识别ASR 模块设计实时语音识别的关键不是“转写准”而是“边说话边出结果”。一次性把整段音频送过去识别延迟无法接受。更常见的做法是分片转写把音频流切成 2-5 秒的片段配合语音活动检测VAD判断说话开始和结束有语音才识别没语音就丢掉。下面是一个基于 faster-whisper 的代码示例# 文件路径asr_service.py from faster_whisper import WhisperModel import numpy as np class ASRService: def __init__(self, model_size: str small, device: str auto): # 使用 int8 量化可以显著降低显存占用和推理延迟 self.model WhisperModel( model_size, devicedevice, compute_typeint8 ) def transcribe(self, audio_bytes: bytes, language: str zh): 输入 PCM 音频字节返回转写文本和片段信息 # faster-whisper 支持直接读取二进制缓冲区 segments, info self.model.transcribe( audio_bytes, languagelanguage, vad_filterTrue, # 过滤静音减少无效识别 beam_size1, # 实时场景用 beam1 降低延迟 without_timestampsFalse ) text_parts [] ts_parts [] for segment in segments: text_parts.append(segment.text) ts_parts.append({ start: segment.start, end: segment.end, text: segment.text }) return { text: .join(text_parts), segments: ts_parts }代码里有两个关键参数需要说明。vad_filterTrue会过滤掉没有语音的片段在问诊场景中特别有用。医生和患者不会一直说话中间会有停顿如果没有 VADwhisper 会把停顿误识别成无意义的语气词甚至产生幻觉文本。beam_size1是实时识别的常用策略。beam size 越大识别越准但解码时间越长。在实时链路里通常先用 beam1 快速出结果后续如果有需要再对答案做二次校验。医疗场景中如果对准确率要求较高可以改成 beam5但要做好延迟增加的心理准备。4.2 视频帧理解从抽帧到可见体征提取实时视频流不能每帧都送进模型会造成极大的计算浪费同时也没有必要。工程上通常按固定间隔抽帧例如每 3-5 秒抽一帧再用轻量模型做分析。# 文件路径video_analyzer.py import cv2 import base64 import numpy as np class VideoAnalyzer: def __init__(self): # 这里用 opencv 做人脸检测实际项目可换成更轻量的模型 self.face_cascade cv2.CascadeClassifier( cv2.data.haarcascades haarcascade_frontalface_default.xml ) def analyze_frame(self, frame_bgr: np.ndarray): 输入一帧 BGR 图像输出基础观察结果 gray cv2.cvtColor(frame_bgr, cv2.COLOR_BGR2GRAY) faces self.face_cascade.detectMultiScale( gray, scaleFactor1.1, minNeighbors5, minSize(80, 80) ) result { has_face: len(faces) 0, face_count: len(faces), image_quality_ok: True, luminance: float(np.mean(gray)), observation: None } if not result[has_face]: result[image_quality_ok] False result[observation] 未检测到人脸请提醒患者正对摄像头 return result avg_lum result[luminance] if avg_lum 50: result[image_quality_ok] False result[observation] 画面偏暗可见体征难以判断 elif avg_lum 200: result[image_quality_ok] False result[observation] 画面过亮可能存在过度曝光 # 简化示例真正生产环境可以用多模态模型生成文本描述 result[observation] result[observation] or 视频画面质量正常可进一步分析 return result视频模块的核心思路是“质量判断”和“体征提取”分离。先判断当前帧是否适合分析比如有没有人脸、曝光是否正常、是否模糊只有质量合格的帧才进入下一步。这里的“下一步”建议接入多模态模型把图像转成文字描述例如“面色苍白精神状态不佳嘴唇干燥”。因为后续医学推理层的 LLM 主要处理文本统一转成文本能让推理层保持简单。多模态模型可以直接用 OpenAI 兼容的图像输入接口也可以委托给专门的视觉模型服务。def frame_to_base64(frame_bgr: np.ndarray) - str: _, buffer cv2.imencode(.jpg, frame_bgr, [cv2.IMWRITE_JPEG_QUALITY, 80]) return base64.b64encode(buffer).decode(utf-8)这一段代码把帧压缩成 JPEG 再转 base64是为了传给多模态模型接口时节省带宽。编码质量设为 80 左右比较合适太低会影响模型判断太高会增加传输耗时。4.3 医学推理引擎提示词与结构化输出医学推理引擎是整套系统的“大脑”。它负责把 ASR 转写文本、视频观察结果、RAG 检索到的医学知识拼装成提示词调用 LLM 生成结构化输出。核心设计要点有两个任务边界清晰、输出格式固定。任务边界清晰指的是让模型做“信息整理和参考建议”而不是让它给出确定性诊断。比如提示词里明确要求“输出鉴别诊断方向”而不是“确诊疾病”。输出格式固定则通过 JSON Schema 约束方便系统下游解析和展示。下面是一个简化版的医学推理引擎# 文件路径medical_engine.py import json from openai import OpenAI class MedicalEngine: def __init__(self, api_key: str, base_url: str None, model: str gpt-4o-mini): self.client OpenAI(api_keyapi_key, base_urlbase_url) self.model model def generate_suggestions( self, dialogue_text: str, video_observation: str, knowledge_texts: list[str], patient_info: dict | None None ) - dict: # 拼装系统提示词 system_prompt 你是一名资深全科医生的 AI 助理在实时视频问诊中为医生提供参考信息。 你的任务包括 1. 提取患者的主诉、现病史、既往史、用药史 2. 总结视频观察到的可见体征 3. 基于检索到的医学知识给出鉴别诊断方向 4. 标记需要医生重点关注的风险信息。 注意 - 你只提供辅助参考不能做出最终诊断 - 如果信息不足明确列出需要补充的问题 - 所有输出必须使用 JSON 格式。 user_content { dialogue: dialogue_text, video_observation: video_observation, knowledge: knowledge_texts, patient_info: patient_info or {} } response self.client.chat.completions.create( modelself.model, response_format{type: json_object}, messages[ {role: system, content: system_prompt}, {role: user, content: json.dumps(user_content, ensure_asciiFalse)} ], temperature0.2, max_tokens1024 ) raw response.choices[0].message.content return json.loads(raw)温度设置为 0.2目的是减少随机性让模型在医学场景下更稳定。如果在实际测试中发现输出仍然不稳定可以进一步使用结构化输出功能甚至把候选答案限定在预设枚举值里。要注意的是这个模块是容易出问题的地方。LLM 返回的 JSON 偶尔会有格式错误、多出注释、或者字段缺失。生产环境一定要加一层解析兜底解析失败时标记为“暂不展示 AI 建议”而不是让异常直接抛到前端。4.4 RAG 知识检索让模型有据可依医学 LLM 单独使用会有两个问题专业知识更新不及时以及可能对不熟悉的药物或疾病产生幻觉。RAG检索增强生成是对抗幻觉的常用手段。思路很简单提前把权威的药品说明书、医学指南等文本切块计算向量后存入 FAISS 索引推理前用当前对话内容去检索最相关的文本块把这些文本块作为参考注入 LLM 提示词。# 文件路径rag_service.py from sentence_transformers import SentenceTransformer import faiss import numpy as np import os class RAGService: def __init__(self, kb_dir: str data/medical_kb): self.encoder SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) self.kb_dir kb_dir self.chunks [] self.index None self._build_index() def _build_index(self): 遍历知识库目录中的文本文件切块并建立向量索引 texts [] for root, _, files in os.walk(self.kb_dir): for fname in files: if not fname.endswith(.txt): continue path os.path.join(root, fname) with open(path, r, encodingutf-8) as f: content f.read() # 简单按段落切块生产环境可以按语义切块 for para in content.split(\n\n): para para.strip() if len(para) 20: texts.append(para) if not texts: return self.chunks texts embeddings self.encoder.encode(texts, normalize_embeddingsTrue) dim embeddings.shape[1] self.index faiss.IndexFlatIP(dim) self.index.add(np.asarray(embeddings, dtypenp.float32)) def search(self, query: str, top_k: int 3): if not self.index: return [] q_vec self.encoder.encode([query], normalize_embeddingsTrue) scores, indices self.index.search(np.asarray(q_vec, dtypenp.float32), top_k) results [] for score, idx in zip(scores[0], indices[0]): if idx len(self.chunks): results.append({ text: self.chunks[idx], score: float(score) }) return results示例中使用了多语言向量模型因为问诊对话可能是中英文混合。知识库文件切块时不能切得太碎否则语义会不完整也不能一整个文件作为一条记录否则检索精度会下降而且会把大量无关信息塞进 LLM 上下文。通常控制在 200-500 字之间。检索结果里带上相似度分数方便判断检索质量。如果分数低于阈值说明知识库没有相关内容可以考虑不注入检索结果直接让推理引擎基于对话内容输出提示并在前端标注“未检索到相关指南”。5. 实战案例搭建实时视频问诊辅助原型5.1 设计思路下面用 FastAPI 搭建一个可运行的简化原型。考虑到完整 WebRTC 信令和媒体服务器实现比较复杂原型采用“浏览器采集音视频 → 通过 WebSocket 推流 → 服务端做 AI 分析”的方式重点演示 AI 侧的处理逻辑。浏览器端每 3 秒推送一次音频字节和视频帧服务端分别调用 ASR 和视频分析模块再把结果送入医学推理引擎最终返回 JSON 提示卡片。# 文件路径main.py import asyncio import json import base64 import numpy as np import cv2 from fastapi import FastAPI, WebSocket from asr_service import ASRService from video_analyzer import VideoAnalyzer from medical_engine import MedicalEngine from rag_service import RAGService app FastAPI() asr ASRService(model_sizesmall, deviceauto) video_analyzer VideoAnalyzer() rag RAGService() engine MedicalEngine( api_keyyour-api-key, base_urlNone, # 本地或自建服务请填写实际地址 modelyour-model-name ) app.websocket(/ws/analyze) async def websocket_analyze(ws: WebSocket): await ws.accept() dialogue_buffer [] try: while True: message await ws.receive_text() data json.loads(message) if data[type] audio: # 音频是 base64 编码的 PCM 字节 audio_bytes base64.b64decode(data[data]) loop asyncio.get_event_loop() asr_result await loop.run_in_executor( None, asr.transcribe, audio_bytes ) if asr_result[text]: dialogue_buffer.append(asr_result[text]) await ws.send_text(json.dumps({ type: transcript, data: asr_result[text] }, ensure_asciiFalse)) elif data[type] video: # 视频是 base64 编码的 JPEG 帧 frame_bytes base64.b64decode(data[data]) frame cv2.imdecode( np.frombuffer(frame_bytes, dtypenp.uint8), cv2.IMREAD_COLOR ) v_result video_analyzer.analyze_frame(frame) # 如果画面质量合格才做多模态分析 if v_result[image_quality_ok]: # 这里省略多模态接口调用可以传入 frame 给视觉模型 pass elif data[type] trigger_ai: # 前端通知可以生成阶段性建议 dialogue_text .join(dialogue_buffer[-20:]) knowledge rag.search(dialogue_text, top_k3) video_obs 视频画面正常无特殊发现 suggestions engine.generate_suggestions( dialogue_textdialogue_text, video_observationvideo_obs, knowledge_texts[item[text] for item in knowledge] ) await ws.send_text(json.dumps({ type: suggestion, data: suggestions }, ensure_asciiFalse)) except Exception as e: print(fWebSocket 连接异常: {e}) finally: await ws.close()5.2 前端推送脚本为了让原型可以直接验证我也写了一个简单的 Python 客户端模拟浏览器推送音频和视频数据。实际项目中这段逻辑会放在浏览器里采集麦克风和摄像头数据后推送到服务端。# 文件路径client_simulator.py import asyncio import json import base64 import cv2 import soundfile as sf import numpy as np import websockets async def send_samples(uri: str): # 读取一段预录音频 audio_data, sr sf.read(sample.wav, dtypeint16) # 读取视频帧 cap cv2.VideoCapture(sample_video.mp4) async with websockets.connect(uri) as ws: # 发送音频片段模拟实时语音流 chunk_size sr * 3 # 3 秒一个片段 for i in range(0, len(audio_data), chunk_size): chunk audio_data[i:i chunk_size] payload base64.b64encode(chunk.tobytes()).decode(utf-8) await ws.send(json.dumps({type: audio, data: payload})) # 发送视频帧 while True: ret, frame cap.read() if not ret: break _, frame_enc cv2.imencode(.jpg, frame) payload base64.b64encode(frame_enc.tobytes()).decode(utf-8) await ws.send(json.dumps({type: video, data: payload})) # 触发 AI 推理 await ws.send(json.dumps({type: trigger_ai, data: })) # 接收返回结果 async for response in ws: print(response) asyncio.run(send_samples(ws://localhost:8000/ws/analyze))5.3 启动与验证在项目根目录启动服务uvicorn main:app --host 0.0.0.0 --port 8000然后运行客户端模拟器python client_simulator.py预期你会看到三类输出transcriptASR 转写出来的文本suggestion医学推理引擎给出的 JSON 建议视频质量相关提示。如果 ASR 返回空文本说明音频格式或采样率不对需要检查客户端发送的 PCM 数据是否与服务端模型期望的采样率一致。faster-whisper 支持 16kHz 单声道音频如果采集到的是 48kHz需要先重采样。5.4 结果说明这个原型虽然简化了 WebRTC 传输但 AI 侧的核心链路已经完整音频转写、视频帧质量判断、知识检索、LLM 推理、WebSocket 返回。把它迁移到真实视频问诊系统时只需要把“WebSocket 接收音视频”替换成“从媒体服务器读取音视频轨道”AI 逻辑可以完整复用。6. 从“能用”到“专家级”评测与优化6.1 离线医学基准评测评估一个医疗 AI 系统是否“专家级”不能只看演示效果需要回到标准数据集上对比。常见的医学基准包括 MedQA、CMB 等用于衡量模型的医学知识水平。工业界在推进医疗大模型时通常会做一批科室级评测集覆盖内科、外科、儿科、皮肤科等。针对实时视频问诊还应该单独构建多模态评测集给出一段视频片段和对话转写序列要求系统输出主诉、现病史、鉴别方向、风险提示然后由医生标注对比。评测指标上推荐使用字段级 F1而不是只看整体准确率。因为系统输出是结构化 JSON主诉提取对不对、鉴别诊断方向是否合理、风险标记是否命中这些字段要分开评估。这样定位问题也更清楚是 ASR 出错了还是检索不相关还是推理逻辑有问题。6.2 在线实时指标离线评测解决“模型能力”问题在线指标解决“体验质量”问题。在实时视频问诊场景中建议至少监控四类指标ASR 转写时延从音频输入到文本输出的时间目标小于 1.5 秒端到端提示时延从医生触发 AI 到前端展示建议卡片的时间目标小于 5 秒AI 建议采纳率医生在问诊中实际采纳或引用了多少条 AI 提示用户满意度患者和医生对问诊过程的主观评分。其中“建议采纳率”特别重要。它直接反映 AI 是否有用如果一个系统产出的提示医生从来不用准确率再高也是自嗨。6.3 延迟预算拆解端到端 5 秒的目标不是随便定的。把它拆开看每部分都要卡得很紧环节延迟预算音频分片与传输500msASR 转写1.5s触发推理与上下文组装300msRAG 检索300msLLM 推理1.5s - 2.5s结果回传与渲染200ms如果 LLM 推理是主要瓶颈可以考虑流式输出先让前端展示文本片段最后再回填结构化 JSON。如果检索耗时长则要检查向量索引规模、编码模型推理速度必要时改成服务端预计算加缓存。7. 常见问题与排查思路7.1 ASR 转写文本乱码或为空现象客户端推入音频后返回的文本是乱码或空。常见原因音频格式不对whisper 期望 16kHz 单声道 PCM而客户端发的是 48kHz 或双声道音频字节没有去除 WAV 文件头VAD 过滤掉了所有声音可能由于音频本身太轻或噪音太大。解决思路先用 ffprobe 查看音频采样率和通道数统一在客户端重采样到 16kHz单声道临时关闭vad_filter测试确认是识别问题还是 VAD 误过滤。ffprobe -show_streams sample.wav | grep -E sample_rate|channels7.2 LLM 输出 JSON 解析失败现象json.loads抛异常推荐结果为null。常见原因大模型返回了 Markdown 代码块包裹的 JSON返回内容中夹杂了解释性文字输出长度超过max_tokens被截断。解决思路解析前先做内容清洗例如去除 json 标记设置response_format{type: json_object}解析失败时进入兜底分支直接展示原始文本不要中断问诊流程。7.3 视频帧模糊或无法提取特征现象视频分析模块频繁提示“未检测到人脸”或“画面质量差”。常见原因网络分辨率过低实际帧尺寸只有 320x240光线太暗或背光抽帧时机正好在画面切换过渡帧。解决思路在客户端限制最小分辨率抽帧前做基础质量评估丢弃清晰度低的帧连续多帧失败时提示患者调整摄像头或光线。7.4 音频和视频不同步现象转写文本已经出来但对应的视频观察结果滞后。常见原因音频和视频走了两条独立的处理链路没有共享时间戳网络拥塞导致视频帧排队。解决思路在推流端给每一段音频和每一帧视频打上同步时钟戳服务端按时间戳对齐后再送 AI 分析如果无法对齐宁可丢弃过期的视频帧也不能让推理等待太久。7.5 合规顾虑现象项目准备上线但合规评审提出多个无法回答的问题。常见原因不清楚音视频数据存储在哪里、保存多久、谁能访问没有告知患者 AI 正在参与辅助分析缺少完整的审计日志无法追溯每一次 AI 建议的依据。解决思路数据加密存储按最小权限原则设置访问控制在问诊前增加 AI 辅助说明和用户授权使用脱敏后的数据来训练或评测模型避免直接用真实问诊数据记录每次 AI 建议的输入、输出、检索来源和模型版本方便事后审计。8. 工程化与合规建议8.1 服务拆分与部署原型把多个 AI 模块放在同一个进程里方便演示。生产环境建议按职责拆分部署至少拆成三组服务网关与媒体服务负责 WebRTC、音视频转发、录制AI 分析服务负责 ASR、视频分析、RAG 检索这些模块计算密集需要独立扩缩容推理服务负责大模型调用需要根据请求量做 QPS 控制。不同服务使用不同的资源规格。ASR 需要 GPU 或者较强的 CPU视频分析可以混部向量检索用内存型实例大模型推理则要看采用的部署方式。不要把所有服务塞进一个容器否则一个模块的高负载会影响整条链路。8.2 敏感信息处理医疗音视频属于个人敏感信息工程上必须遵守“最小收集”原则。建议做到视频流默认不落盘只在需要质控时经过授权后录制音频转写文本存储前先做去标识化例如去掉姓名、身份证号等模型调用日志只保留脱敏文本不保留原始音视频外部 LLM API 调用前对文本做脱敏处理避免把患者隐私发送到外部服务。如果业务涉及数据传输和存储还需要考虑本地化部署方案把数据留在受控区域内并做访问审批留痕。8.3 医生兜底与人工复核机制不管 AI 建议看起来多准确最终必须保留医生确认环节。产品设计上建议做到AI 建议卡片不直接写“诊断结果”而写“参考方向”医生端有“采纳”“忽略”“标记错误”三个操作用于反馈 AI 质量对高危风险提示UI 上使用不同颜色强调并提醒医生确认但不能阻断问诊流程定期抽检 AI 建议和医生最终病历的一致性发现系统性问题后回炉优化模型或知识库。把医生标记为“错误”的样本收集起来是最有价值的评测数据。这类数据反映了模型在真实场景中的短板比任何公开数据集都更能指导迭代。8.4 日志与审计医疗 AI 系统的审计要求比普通系统严格。每次 AI 推理建议都建议记录以下字段{ session_id: 问诊会话ID, request_time: 2025-01-01T10:00:00Z, input: { dialogue_text: 脱敏后的对话文本, video_observation: 视频观察结果, kbs: [知识库条目ID列表] }, output: 模型输出的 JSON 提示, model_version: v1.2.0, latency_ms: 3210 }审计日志不能只记录最后输出还要记录检索用到了哪些知识库条目方便追溯 AI 建议的依据。模型版本也要记录因为大模型服务端经常更新同一个问题在不同版本下可能有不同回答没有版本信息问题排查会非常困难。9. 总结与下一步实践方向从技术角度看“专家级医疗 AI 实时视频问诊”本质上不是一个单一模型问题而是一个多模态实时系统工程。本文拆解了音视频接入、语音识别、视频帧理解、知识检索、医学推理、结果反馈这六层链路并给出了一个可直接运行的辅助问诊原型。核心代码可以迁移到真实 WebRTC 问诊系统重点不在代码本身而在链路协作方式ASR 实时出文本、RAG 提供依据、LLM 做结构化推理、医生做最终决策。如果要在真实项目中继续深入建议按这个顺序推进先上线“转写 结构化病历摘要”让医生减少打字负担再加入“RAG 知识提示”提升回答的权威性最后再逐步加入多模态视频体征分析并且每一步都建立医生反馈闭环。风险上优先关注数据合规、模型幻觉和延迟体验这三块不过关医学准确率再高也很难真正落地。下一阶段值得关注的方向是端侧小模型与云端大模型的协同例如用端侧 ASR 做低延迟转写、云端 LLM 做深度推理以及基于视频连续帧的行为分析而不只是逐帧图片判断。希望这篇文章能帮你在实时医疗 AI 的工程落地上少踩一些坑。如果对你有帮助可以收藏备用实战中遇到具体问题也欢迎在评论区交流。