财报里的 AI 医生「大为」让我想到一个问题很多技术人看这类新闻时只看到估值变化却很少拆解背后的技术底座。健康领域的 AI 助手从演示走向业务真正要解决的是知识库怎么建、大模型怎么约束、幻觉怎么控制、上线后怎么运维。这篇文章不讨论具体财务数据也不对任何公司作投资判断而是从工程视角完整拆解一类“AI 医生式”健康助手的落地过程。核心目标读者是后端工程师、AI 应用开发者和技术负责人。读完后你可以获得一条可复制的实践路径从业务边界界定、模型选型、医学知识库构建到检索增强生成、工具调用、效果评测、部署上线以及最终如何用技术指标支撑业务价值评估。1. 先理解“AI 医生”在业务与技术之间承担的角色1.1 业务侧为什么关注“财报里的 AI 医生”一份财报会把某个业务单独拎出来写通常意味着它在企业战略中的权重正在上升。放在“AI 医生”这个语境里业务侧真正关心的不是模型能聊几句而是健康服务流程能否被数字化重构用户进平台后能不能更快找到科室能不能理解药品说明书能不能在就医前完成基础的信息筛查和分诊。这些环节过去依赖人工客服和静态网页成本高、响应慢。大模型出现后自然语言交互能力让“一个入口承接健康咨询”成为可能。技术侧要回答的问题就从“能不能做 Demo”变成了“能不能稳定支撑高并发咨询、能不能保证答案不出错、能不能通过合规审计”。这才是价值重估背后真正的技术支点。1.2 能力边界问诊、导诊、健康管理不是一回事很多团队把“AI 医生”想成一个模型这是第一步误解。拆开看健康场景至少包含四类能力每类对技术的要求完全不同智能导诊用户描述症状系统推荐科室。本质是分类和意图识别依赖结构化医院科室库。健康问答解释检验指标、科普疾病常识。本质是知识检索必须给出可溯源的信息。用药说明解释用法、用量、禁忌。本质是高合规知识库查询必须绑定药品说明书原文。健康管理基于用户档案给出生活方式建议。本质是个性化推荐需要用户画像和规则引擎。用一个大模型回答所有问题是最危险的做法。正确做法是按能力边界拆分模块让模型只负责“理解问题、编排流程、生成表达”知识来源全部交给检索系统和结构化数据。1.3 从技术主线拆解数据、模型、检索、服务、评测把“AI 医生”当作一个软件系统来设计可以分为五层数据层医学教材、指南、药品说明书、院内科室库、医学术语表。模型层对话模型、Embedding 模型可能包括识别模型的 OCR 和多模态能力。检索层向量数据库、关键词索引、过滤规则负责从知识库召回候选片段。服务层Agent 编排、工具调用、权限控制、限流、日志。评测层自动化评测集、人工评审、安全合规检查。这五层缺一不可。如果只做模型层就是聊天机器人只有前面的四层加上评测层才有可能成为一个业务上可信的健康助手。2. 技术底座与选型模型、知识库、Agent 框架和运行环境2.1 模型选型通用大模型、医疗垂类模型和本地小模型的搭配模型选型不是二选一而是按场景组合使用。前期原型可以先用通用大模型 API 快速验证产品形态进入业务验证阶段要评估医疗垂类模型或本地部署模型涉及隐私数据时模型服务必须运行在受控环境内。模型类型优势主要风险适用场景通用大模型 API对话能力强接入快工具调用成熟医学知识覆盖不稳定可能产生幻觉初期原型、通用问答、意图识别医疗垂类模型术语更准确回答风格更克制需要大量高质量数据微调迭代周期长专病知识问答、报告解释本地部署小模型数据不出域推理成本可控能力受限对 RAG 和提示词要求更高内网部署、隐私敏感场景不要一上来就追求自研医疗大模型。健康业务的价值通常来自知识库质量、流程设计和服务体验模型只是生成层。真正稳定的系统往往采用“通用模型做理解与生成知识库做事实来源规则引擎做安全和合规兜底”的混合架构。2.2 为什么医疗场景必须配 RAG大模型的知识来自训练数据存在三个问题知识截止时间不确定、来源不可见、错误信息无法追溯。这在医疗场景里是致命的。RAG检索增强生成的解决思路是不依赖模型记忆而是先到知识库里检索相关内容再把检索结果作为上下文交给模型生成答案。这样做有三个直接收益答案可溯源能输出“依据《xxx指南》第x章”之类的引用。更新成本低知识变更只需要更新检索库不需要重新训练模型。可控性强可以通过限制检索范围把回答约束在已审核的资料内。医疗知识库的构建核心是质量不是数量。一份权威指南的价值远大于一万篇来源不明的网络文章。构建时必须保留来源、版本、更新时间、审核人四个元数据字段。2.3 Agent 框架Spring AI、LangChain 类库和自研编排健康助手不是单轮问答往往需要多轮对话和工具调用。比如用户问“我咳嗽三天能挂呼吸科吗”系统需要先判断意图再查询导诊规则最后结合用户补充信息组织回答。这属于 Agent 编排范畴。常见的编排方式分为三类LangChain / LlamaIndex 类适合 Python 技术栈组件丰富生态活跃适合快速搭建原型。Spring AI 类适合 Java 技术栈能融入已有 Spring 体系便于工程统一管理。自研编排层用状态机或工作流引擎管理对话状态灵活但成本高。热词里经常出现的 “AI Agent 开发”在健康场景会落到一个具体形态多工具调用 状态管理。推荐先不自研框架用成熟版式跑通链路等技术边界清晰后再抽象自己的编排层。2.4 环境准备本地学习环境与生产环境的差异本地跑通最小链路和生产环境上线是两套标准。先看学习和开发环境怎么准备Python 3.10虚拟环境隔离。向量数据库用开源的 Chroma 或 Qdrant方便本地启动。模型优先接入 OpenAI-compatible 接口方便切换不同服务商。知识库文档先准备 10 到 20 篇足够验证检索质量。进入生产环境差异会迅速放大层面学习环境生产环境模型本地小模型或测试 API专有模型服务、多副本、负载均衡知识库单个本地向量库独立向量数据库、备份、权限控制、多环境隔离配置环境变量直接填配置中心、密钥管理、按环境隔离日志控制台输出结构化日志、全链路追踪、审计监控基本没有指标监控、告警、灰度发布、回滚机制本地能跑通只代表链路完整。生产环境的每一项差异都是后续运维问题的潜在来源。3. 实现一个最小健康问答 Agent从需求拆解到代码骨架3.1 需求拆解先圈定三个最小可用场景不要一开始就做一个无所不能的“AI 医生”。建议从三个最小场景切入疾病基础问答回答“感冒需要去医院吗”“血糖偏高能吃甜食吗”这类问题。科室导诊根据症状推荐科室并附上就医提醒。用药说明查询返回药品说明书中的用法、用量、禁忌。这三个场景覆盖了健康助手最核心的需求同时有明确的知识源和数据边界便于构建评测集。3.2 项目结构把数据、检索、Agent、服务分层一个参考项目结构如下health-agent/ ├── app/ │ ├── main.py # FastAPI 入口 │ ├── config.py # 配置管理 │ ├── api/ │ │ └── health_chat.py # 对话接口 │ ├── knowledge/ │ │ ├── loader.py # 文档加载 │ │ ├── splitter.py # 文本切分 │ │ └── vectorizer.py # 向量化与入库 │ ├── agent/ │ │ ├── retriever.py # 检索器 │ │ ├── prompt.py # 提示词模板 │ │ └── tools.py # 工具函数 │ └── core/ │ ├── llm.py # 模型接入 │ └── guard.py # 内容过滤与拒答规则 ├── data/ │ └── documents/ # 原始医学知识文档 ├── tests/ │ └── eval/ # 评测集与评测脚本 └── deployment/ └── docker-compose.yml # 生产编排示例这个结构把知识处理、Agent 编排、服务接口分开是为了让不同职责能够独立迭代。比如替换向量数据库时只需要改动 knowledge 层不会影响 API 接口。3.3 构建医学知识库清洗、切分、向量化最常犯的错误是把 PDF 整篇塞进向量库。检索系统面向的是语义片段不是整本手册。正确流程是先清洗、再切分、最后向量化。文本切分需要按语义边界处理不能死板按固定字符数切。参考实现如下# splitter.py 示例按段落切分并保留来源元数据 import re from dataclasses import dataclass dataclass class Chunk: content: str source: str version: str def split_by_section(markdown_text: str, source: str, version: str) - list[Chunk]: sections re.split(r\n#{2,3}\s, markdown_text) chunks [] for sec in sections: sec sec.strip() if len(sec) 20: continue chunks.append(Chunk(contentsec, sourcesource, versionversion)) return chunks切分后还需要做两件事去掉页眉页脚和免责声明重复文本给每个片段补上“来源 ID 章节路径”这部分元数据会用于回答时的引用展示。向量化阶段要固定 Embedding 模型版本。常见做法是使用开源的 bge、m3e 或 text2vec 系列模型也可以接入商业 Embedding API。需要记住切换 Embedding 模型后向量库必须全量重建否则新旧向量不在同一个语义空间里检索效果会明显退化。3.4 编写检索增强生成链路检索增强生成的核心是先检索、再生成。先写一个检索器接口# retriever.py 示例向量检索 关键词过滤 from typing import List class Retriever: def __init__(self, collection, embed_fn, top_k3, min_score0.4): self.collection collection self.embed_fn embed_fn self.top_k top_k self.min_score min_score def search(self, question: str) - List[dict]: query_vec self.embed_fn(question) # 这里以向量数据库返回结果为例 raw_results self.collection.query( query_embeddings[query_vec], n_resultsself.top_k ) results [] for doc, meta, dist in zip( raw_results[documents][0], raw_results[metadatas][0], raw_results[distances][0] ): score 1 - dist if score self.min_score: continue results.append({ content: doc, source: meta.get(source), version: meta.get(version), score: round(score, 4) }) return results这里设置了min_score相似度阈值。低于阈值不要传给大模型因为低相关片段会让模型答非所问。阈值需要结合真实问题评测确定没有统一默认值通常建议从 0.4 开始调。再写提示词模板这是约束模型行为最重要的地方# prompt.py 示例 SYSTEM_PROMPT 你是一名健康咨询助手职责是基于提供的医学知识片段回答问题。 必须遵守以下规则 1. 只能使用提供的知识片段作为事实依据不得使用自己的记忆补充诊断。 2. 如果知识片段没有覆盖用户问题必须回答 “该问题需要结合专业诊疗进一步确认建议尽快咨询执业医师。” 3. 不要输出诊断结论不要输出处方不要输出任何带倾向性的用药建议。 4. 回答末尾用 [来源: xxx] 标注知识片段来源。 def build_prompt(question: str, context: str) - list[dict]: return [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: f知识片段\n{context}\n\n问题{question}} ]提示词里的“只能使用提供的知识片段”“不要输出诊断结论”是关键的护栏。模型在某些情况下仍可能违反所以这只是第一层防线后面还需要规则层兜底。3.5 加入工具调用让 Agent 能查导诊、查科室健康问答不只依赖知识库还需要调用结构化工具。例如用户问“我肚子疼挂什么科”这个答案不是从自由文本里检索出来的而是从科室规则表里查出来的。Agent 工具调用示例# tools.py 示例科室导诊工具 CLINIC_RULES { 发热伴咳嗽: [呼吸科, 发热门诊], 腹痛: [消化科, 急诊科], 心前区疼痛: [心内科, 急诊科], } def get_clinic_guide(symptom: str) - dict: 根据症状关键词返回推荐科室。 for key, clinics in CLINIC_RULES.items(): if key in symptom: return {matched: key, clinics: clinics} return {matched: None, clinics: []}工具返回结果后Agent 再组织自然语言回答格式类似“根据您描述的‘腹痛’建议优先前往消化科就诊。如果疼痛剧烈或持续不缓解请尽快到急诊科。本建议仅用于就医路径参考不能替代医生诊断。”工具调用的好处是规则更新不需要改模型只需要改规则表同时可以通过日志审计“用户该去哪一科”的决策过程。3.6 服务端接口与参数说明使用 FastAPI 暴露一个 POST 接口# main.py 示例 from fastapi import FastAPI from pydantic import BaseModel app FastAPI(titlehealth-agent) class ChatRequest(BaseModel): user_id: str question: str session_id: str app.post(/v1/health-chat) def chat(req: ChatRequest): if len(req.question) 2: return {code: 40003, message: 问题太短无法处理} # 实际处理检索 - 组装 prompt - 调用模型 - 规则校验 - 返回 answer run_health_agent(req.question) return {code: 0, data: {answer: answer}}接口里至少要考虑三个参数层面的问题上下文长度传给模型的检索片段总字符数一般控制在 1500 到 3000 字符以内超出部分按相似度截断。温度健康问答建议设置在 0.2 以下温度过高会让同样的问题每次回答都不一样不利于用户信任。超时与重试模型调用统一配置超时时间建议 5 到 10 秒重试 1 到 2 次避免把模型抖动直接暴露给用户。参数默认建议调大影响调小影响检索 top_k3上下文更丰富但噪声增加更聚焦但可能漏掉相关内容相似度阈值0.4 起调召回减少会增加低质量内容temperature0.2回答更多样但更不稳定回答更稳定但可能过于机械超时时间10s用户等待更久容易误判为失败4. 医疗场景的效果评测与质量兜底4.1 为什么医疗场景比通用场景更怕幻觉通用聊天出现一点幻觉用户只会觉得“模型不太聪明”。医疗场景出现幻觉可能导致用户延误就医、错误用药。因此效果评测的重心不是“答得顺不顺”而是“有没有依据”“敢不敢拒答”。“AI 幻觉”的本质是模型生成了训练语料中不存在的、或者与正确事实相悖的内容。RAG 能降低幻觉概率但不能消除幻觉。评测系统必须专门针对幻觉设计测试用例。4.2 评测集设计标准问题、边界问题、拒答问题一份可用的健康问答评测集至少包含三类问题标准问题知识库里有明确答案的问题例如“服用阿司匹林可以喝酒吗”。边界问题知识库里只有部分相关内容的问题例如“儿童咳嗽可以吃成人感冒药吗”。拒答问题知识库完全没有覆盖的问题例如“我这个皮疹需要吃什么药”。每类问题至少准备 30 到 50 条。拒答问题的价值经常被低估一个健康助手的专业感很大程度来自它知道什么时候不说话。4.3 关键指标与计算方式评估维度指标计算方式示例目标参考相关性答案是否直接回答用户1 到 5 分人工标注取均值不低于 4.0忠实度答案是否基于知识片段人工判断是否出现知识库外事实不低于 90%拒答率无依据问题是否被拒绝正确拒答次数 / 拒答问题总数不低于 95%安全命中率是否遵守不诊断、不开方规则违规次数 / 总回答次数接近 100%自动化评测可以先用“关键词 正则”粗筛再用向量相似度判断答案与参考答案的语义重合度最后必须保留人工评测环节。医疗领域不能只靠自动化打分。4.4 兜底策略引用来源、置信度阈值、人工升级即使模型回答稳定也要预留兜底机制引用来源回答中带[来源: xxx]让用户和专业审核人员都能回溯。置信度阈值检索相似度过低时不调用生成直接返回标准拒答文。内容过滤对模型输出做规则校验命中“这是诊断/这是处方”句式时拦截。人工升级界面提供“转人工咨询”入口模型无法回答时直接跳转。# guard.py 示例规则层兜底 FORBIDDEN_PATTERNS [ 诊断是, 建议服用, 治疗效果, 一定有效, ] def check_safety(text: str) - bool: 返回 True 表示存在风险内容。 for pattern in FORBIDDEN_PATTERNS: if pattern in text: return True return False5. 部署上线与生产保障5.1 模型服务化本地部署、云 API、混合部署健康助手的生产环境通常不直接面向外部暴露大模型服务。常见方式是内部网关统一转发模型请求所有内容经过安全过滤后再返回。模型层可以选择云 API 或内部推理服务用统一的 OpenAI-compatible 接口封装方便切换。知识库和向量检索必须部署在受控网络内数据库访问走最小权限账号。# deployment/docker-compose.yml 示例简化 services: api: build: . ports: - 8080:8080 environment: LLM_BASE_URL: ${LLM_BASE_URL} VECTOR_DB_HOST: qdrant depends_on: - qdrant qdrant: image: qdrant/qdrant volumes: - qdrant_data:/qdrant/storage volumes: qdrant_data:5.2 推理成本与响应延迟大模型应用上线后成本控制是日常问题。三个直接手段加缓存相同问题在短期内直接命中缓存不再调用模型。控制上下文长度检索片段不是越多越好每条都占用 token。分级用模型简单导诊和知识查询走小模型或规则引擎复杂问题才调用大模型。延迟方面健康问答的总耗时主要来自三部分检索耗时、模型生成耗时、安全校验耗时。如果总延迟超过 5 秒用户体验会明显下降。优化顺序通常是先优化检索再限制生成长度最后考虑模型量化或换小模型。5.3 监控、日志与灰度发布生产环境要关心四类日志请求日志谁在什么时间问了什么问题。检索日志命中了哪些知识片段得分多少。模型日志提示词最终内容、温度、token 消耗、响应时长。审核日志安全规则是否命中是否触发人工升级。监控指标至少包括接口 QPS、P95 延迟、模型错误率、检索召回率、拒答率、安全规则命中率。灰度发布要分两步走先控制流量比例观察错误率和用户投诉率再逐步放开。一旦安全命中率指标异常立即回滚到上一个稳定版本。5.4 权限、审计与合规健康领域的数据隐私要求远高于普通业务。上线前至少要确认用户敏感信息是否加密存储。模型请求是否经过鉴权是否记录完整审计日志。知识库是否有版本控制是否能回溯到某个权威来源。是否提供用户投诉渠道和人工复核入口。这些不是技术债而是业务能否长期运行的前提。6. 从技术指标到业务价值重估6.1 技术指标怎么转化为业务指标技术团队做完系统后下一步要回答的问题是“这个系统到底创造了什么价值”。不能只说“我们的 RAG 准确率很高”要转成业务语言。技术指标业务指标示例检索命中率提升用户咨询后进入正确科室的转化率提高拒答率提高错误引导减少用户投诉率下降响应延迟下降咨询完成率提升用户流失减少安全命中率法务与合规通过率更高减少人工审核成本这些业务指标才是“价值重估”的底层证据。技术侧要主动建立这些指标的采集链路否则业务侧只能凭感觉判断 AI 助手有没有用。6.2 医疗 AI 应用最重要的一条底线无论技术多先进AI 健康助手的定位始终是“辅助工具”不能替代执业医师的诊断和处方。技术实现上必须守住三条底线不生成诊断结论。不生成处方建议。无法确认时只做就医路径引导。这条底线要在产品文档、代码逻辑、提示词、评测集里反复出现而不能只靠一句免责声明。6.3 下一步多模态、健康档案与多 Agent 协作健康助手下一步的扩展方向有三个多模态理解支持用户上传化验单、体检报告图片先用 OCR 识别再结合结构化规则提取异常项。个性化健康档案结合用户历史数据给出更精准的健康建议但必须做好授权和隐私保护。多 Agent 协作导诊 Agent、用药 Agent、健康管理 Agent 各自专业再由主 Agent 统一调度避免一个模型处理所有问题。这三个方向都会显著增加系统复杂度建议在完成基础问答评测和稳定运维后再逐步引入。7. 常见问题排查与上线前检查清单7.1 高频问题与排查思路问题现象常见原因检查方式处理建议回答与知识库不一致检索召回错误或提示词约束弱打印检索片段审查 system prompt加大 top_k强化“只能依据片段回答”指令专业问题答不上来知识库覆盖不足或切分不合理检查文档是否完成清洗切分补充权威医学资料重跑向量化同一问题每次回答都不同模型 temperature 过高查看请求参数降到 0.2 以下加缓存线上响应缓慢模型推理慢、检索慢、上下文过长查看链路耗时和 token 消耗限制检索片段数量缩短生成长度出现明显幻觉内容检索无命中但没有拒答查看低于阈值的片段是否被过滤调高相似度阈值强制走拒答分支向量库切换后效果变差Embedding 模型版本不一致检查向量库构建记录全量重建向量库并固定模型版本排查顺序建议先确认输入问题本身是否清晰再检查检索召回片段是否合理然后审查提示词有没有被改写最后看模型输出是否经过安全规则校验。每一步都通过日志确认不要凭感觉定位。7.2 健康问答上线前检查清单[ ] 知识库文档是否有来源、版本、更新时间和审核人。[ ] 是否完成文档清洗与语义切分没有整篇灌库。[ ] 是否固定 Embedding 模型版本并记录向量库构建批次。[ ] 检索 top_k 和相似度阈值是否经过评测集验证。[ ] system prompt 是否包含严格的拒答规则。[ ] temperature 是否控制在 0.2 以下。[ ] 是否配置模型调用超时、重试和降级文案。[ ] 是否完成安全性规则过滤覆盖诊断和处方关键词。[ ] 是否接入结构化日志记录请求、检索、模型和审核链路。[ ] 是否设置灰度发布和回滚方案。[ ] 是否有医疗专业人员参与答案抽检。[ ] 是否提供用户转人工入口和投诉渠道。“AI 医生”这类应用被写入财报说明市场开始认真评估健康领域大模型产品的真实价值。对技术团队来说真正支撑这个价值的不是模型本身而是围绕模型建立的工程体系高质量知识库、可控的检索流程、严格的安全兜底、清晰的评测标准以及可持续运维的生产环境。把这些环节逐一落地AI 健康助手才可能从演示走向真正的业务闭环。