罕见病智能体：用检索增强与多轮对话打破认知壁垒

1. 先聊聊一个反常识的现状：搜索引擎治不好“不知道病名”的问题

我所在的团队做AI医疗产品已经有两年多，常见病问诊、体检报告解读、慢病随访这些方向都试过。真正让我意识到“认知壁垒”这四个字有多重的，是一次很普通的线上义诊。当时我们接进来的用户里有位家长，拿着孩子的检查报告在医院里来回转，儿科看过了，内分泌科看过了，神内科也看过了，最后才有人提醒他，这种情况应该去遗传咨询门诊。这位家长在搜索框里输入的词是“孩子长得慢、发育落后”，但他不知道，这样的症状组合在罕见病文献里对应着一个明确的疾病方向。不是没有信息，而是不知道该搜什么。

这就是罕见病患者与信息服务之间最根本的矛盾：所有搜索工具、科普文章、导诊产品，默认用户已经知道自己要找什么。但罕见病的真实路径恰恰相反，大多数患者和家属在最初几年连病名都不知道，他们手里只有症状碎片，比如“反复发烧”“肌肉没力气”“皮肤特别薄”。面对这些碎片，通用搜索引擎能给出的答案只会是常见病解释，而儿科、内分泌科、神经内科各自的科室科普又只在各自的框架里打转，没人替用户做跨科室、跨症状的拼图。

这种困境放大之后，就是我们常说的“诊断之旅”：从第一个症状出现到最终确诊，往往要经历很长时间，期间被误诊为常见病、做一堆重复检查、在不同科室之间被转来转去。患者数量少、区域分散、基层医生接触少，这些因素叠加在一起，让罕见病在公众认知里显得“好像不常见”。但实际上，把数千种罕见病累加在一起，对应的患者群体并不小。

我们团队当时讨论了很久，最后决定做一个反常规的产品方向：不服务“已经知道病名的人”，而是服务“只有症状、没有答案的人”。这个项目内部代号就叫“千病智能体”，目标很直白——把患者从“一堆模糊症状”带到“一个可以行动的方向”，而不是替医生确诊。做完之后我最大的感受是，打破认知壁垒这件事，不是写几篇科普就能解决的，它需要一套能把知识、语言、行动路径串起来的产品机制。

1.1 把“不知道病名”拆开看：认知壁垒其实有三层

第一层是患者认知壁垒。大多数人一辈子不会接触罕见病这个词，即使接触了，也觉得跟自己无关。当孩子或自己出现奇怪症状时，第一反应仍然是对着常见病查资料，查来查去对不上号，就开始焦虑，怀疑是不是自己描述不清楚，或者去了不够好的医院。这个阶段最痛苦，因为信息世界明明那么大，你却找不到一个可以切入的入口。

第二层是医生认知壁垒，尤其基层医生。不是说医生水平不够，而是罕见病单病种发生率太低，一个全科医生可能整个职业生涯都碰不到一例，要求他记住所有罕见病的早期特征并不现实。更麻烦的是，部分罕见病的早期症状和常见病高度重叠，比如肌无力会被当成疲劳、发育迟缓会被当成营养不良，只有朝向特定方向做检查，才有机会发现问题。

第三层是社会认知壁垒，也是最被低估的。疾病罕见，意味着对应的社会支持也罕见：没有多少人理解患者的处境，病友组织分散，可用的康复资源、教育支持、心理援助信息都难以整合。患者即便确诊了，也可能不知道自己能获得哪些帮助。所以“认知壁垒”从来不是一个单纯的知识问题，它是知识、语言、资源、路径四条线同时断裂的结果。

1.2 智能体能带来的三个改变：追问、翻译、给路径

传统信息产品解决不了这个问题的原因，在于它们默认用户能精确表达需求。千病智能体的切入点，是用多轮对话把模糊描述一步步追问成结构化信息。用户说“孩子走路有点奇怪”，系统不会直接给一个疾病列表，而是追问：是经常摔倒，还是步态不对称？从什么时候开始？有没有伴随其他症状？这些追问本身就是在帮用户完成“科学生病描述”这件事。

第二层改变是翻译。权威的罕见病指南、诊断共识、专家文章，本质上都是写给专业人员看的，满是肌电图、基因突变位点、代谢指标这些词。患者家属第一次看到这种材料，大概率是崩溃的。智能体需要做的事，是把指南语言翻译成普通家庭能看懂的表述，同时保留关键信息不变形。这里的翻译不是简单的“换个说法”，而是要把握详略、顺序和提醒强度。

第三层改变是给路径。信息给得再多，用户真正需要的是“我下一步该做什么”。是该继续观察，还是去某个方向的科室？需要准备哪些既往检查资料？是否建议做基因检测？这些问题在科普文章里通常是分散的，但智能体可以在一次会话里，把“症状—疑问—检查方向—就医科室—就诊准备”串成一条清晰路径。这个“给路径”的动作，才是从“打破认知”到“改变行动”的关键一跳。

2. 千病智能体到底怎么搭：知识层、认知层、交互层的分工逻辑

确定方向之后，团队里讨论最多的问题不是“大模型能不能做到”，而是“怎么让这件事可控”。罕见病信息一旦出错，后果不是闹笑话，而是可能让用户延误就医、过度恐慌、甚至被引导到错误的治疗方向。所以架构设计从一开始就不是“让大模型自由发挥”，而是把系统拆成相互约束的三层：知识层管事实，认知层管推理，交互层管表达。

2.1 知识层、认知层、交互层的具体分工

知识层的核心是一套结构化的罕见病知识库，包含疾病基本定义、别名、症状标签、遗传模式、诊断路径、常用检查方向、推荐就诊科室等。这一层的数据不是让模型自己记住，而是单独存储，在每次回答时实时调用。为什么这么做？因为罕见病知识更新速度快，新的研究、新的临床共识不断出现，如果把知识固定在模型参数里，每次更新都要重新训练，成本高且不可控。

认知层的职责是“基于知识层内容做推理”。我们没有让基础大模型直接面对用户问题，而是在中间加了一道检索增强（RAG）机制。用户的提问进来后，先转换为检索条件，从知识库中召回相关的疾病条目和文献片段，再把这些召回内容一起交给大模型组织语言。这样模型不用凭记忆作答，而是像工作人员拿到资料后再写答复，大幅降低了编造风险。

交互层则负责对话节奏、追问逻辑和话术控制。同一个医学问题，不同情绪状态下的用户需要不同的回复语气；同一个知识点，第一次提问和深挖细节时也应采用不同的展开方式。交互层还承担“何时转人工”的判断，如果用户情绪激烈、涉及紧急症状或连续追问同一话题，产品会主动提示就诊线，不硬聊。

这三层看起来简单，实际开发中最大的坎在知识层，因为罕见病数据太稀碎了。但先搭知识层有个额外好处：每一层都可以独立测试。知识层可以单独抽检某个疾病的字段是否完整，认知层可以单独做问答评测，交互层可以单独看追问逻辑是否自然，不至于最后把所有问题都堆积到大模型上。

2.2 为什么选“检索增强”而不是直接微调模型

用基础大模型直接跑，最省事，但有两个问题过不了关。第一是语料太少，罕见病相关的高质量中文语料，满打满算可能只有几百万字，这点量拿去微调大模型，相当于用一小锅水去泡一大袋茶叶，味没泡出来，还容易过拟合，模型会把少量样本里的噪声当成规律。第二是审计要求，医疗场景需要回答必须有据可查，检索增强的好处是每次回复都能追溯到具体知识条目，出问题可以反向复盘。

检索增强的基本流程是：用户提问 → 拆解关键实体 → 检索知识库 → 召回候选条目 → 按相关度排序 → 截断超出上下文的部分 → 拼进提示词 → 让模型生成回答。听起来不复杂，但细节里全是坑。比如用户说“肌无力”，知识库里的疾病可能用“进行性肌无力”“近端肌无力”“肌肉萎缩”等不同标签，如果做不好同义词映射，检索召回结果就残缺。我们后来在知识层加了专门的别名表，把常见口语表达、历史病名、英文缩写都映射到标准字段上，才把召回率提上去。这个工作没有太多技术含量，但极其磨人。

2.3 多智能体分工：患者档案、知识检索、医学复核、话术控制

“千病智能体”之所以叫智能体而不叫“问答机器人”，是因为它内部不是单个大模型包打天下，而是由多个小智能体协作。我们内部划分了四个角色：患者画像、知识检索、医学复核、话术控制。

患者画像智能体负责从对话中提取结构化信息，它会记录患病对象是成人还是儿童、症状首发时间、是否做过基因检测、家族中是否有类似情况，但并不存储姓名等实名信息。知识检索智能体拿到画像后，去知识库捞取匹配的疾病条目和文献片段。医学复核智能体最苦，它要将检索结果与用户问题做一致性校验，如果检索到的疾病和用户描述的症状明显对不上，就要求重检，而不是硬答。话术控制智能体最后出场，负责组织回复的措辞格式、提示风险等级、控制回复长度。

这套分工的代价是每次回答都要多次调用模型，延迟会高一些，还会增加成本。但好处是职责清楚，每个智能体都有自己的失败模式，可以单独优化。比如知识检索召回不全，问题一定出在知识库标签或别名表上；如果医学复核频繁拦截，说明检索阈值太宽或者知识库本身存在冲突条目。对我们这种小团队来说，这种可诊断性比单纯追求对话流畅重要得多。

3. 知识底座是最难的部分：稀疏数据下的“逆向补全”与置信度分级

项目启动后，我们花在“让系统更聪明”上的时间远没有花在“让知识库更可信”上的时间多。罕见病的知识建设跟常见病完全是两种打法。常见病资料多、共识多、教材多，随便整理一下就是一个不错的库。罕见病不一样，很多病种在中文互联网上可能只有几篇文献、几个病友分享帖、一两段医院科室介绍，数据稀碎到让人怀疑是不是选错了赛道。

3.1 知识Schema：先定义“一种病”要存哪些字段

知识库不能是简单的一堆文档丢进去，必须设计一套统一的结构化字段。我们最后定下的Schema包含十几项核心字段：标准病名、别名与曾用名、症状关键词（分常见与少见）、发病机制简述、常见分型、遗传模式、诊断路径（从什么科室切入）、推荐检查方向、需要排除的相似疾病、疾病自然史（大致发展过程）、现有干预方式、高危警示症状、患者资源信息（病友组织、援助渠道等）。

这套字段设计不是拍脑袋想出来的。它对应的是患者从“最初症状”到“确诊后生活”的完整旅程。字段之间的关系也很重要，比如“诊断路径”字段要和“推荐检查方向”联动，才能回答“我应该挂哪个科、做什么准备”这类落地问题。我们把每条知识都当作一个独立的对象来维护，而不是当作文章段落存在，这样后续检索、更新、权限控制都好做。

3.2 逆向补全：从“答不上来”里挖知识缺口

知识库冷启动时，我们只收录了几十种相对“不那么罕见”的罕见病，数据主要来自公开指南、教科书和综述。但很快发现，仅靠专家来补全所有病种根本不现实，精力不够，优先级也难判断。后来我们换了一个思路：既然用户是带着真实问题来的，不如让用户的提问来告诉我们缺什么。

具体做法是搭建“答不上来”漏斗。每次智能体无法召回有效知识、或者检索结果与问题明显不匹配，系统就会把这条对话记录匿名化后丢进一个待办池。每周我们集中过一次池子，按问题出现的频次排序，高频问题优先补知识。如果某个疾病已经有知识条目，但用户提问角度很新（比如问某种罕见病的职业选择注意事项），就给这条疾病知识增加新的字段。这个方法我们内部叫“逆向补全”，效果出乎意料的好，因为用户提出的问题永远比设计者能想象的问题更多样，也更贴近真实需求场景。

3.3 置信度分级：不把个案报道当指南用

知识库里同一个疾病，不同来源的说法的可信度差异极大。权威指南推荐的诊疗路径和一篇孤立的个案报道之间，差距不是一点半点。如果智能体不加区分地混着讲，短期看不出问题，长期一定会出事。所以我们给每条知识条目都打了一个置信度标签，不同等级对应不同的回答策略。

低置信度数据的处理是最敏感的。我们内部定了一条铁律：低置信度内容永远不能作为“建议”的起点，最多只能作为“需要和医生进一步确认”的提示。比如某位病友分享过某种辅助锻炼方法有效，智能体不会直接说“你可以试试这种锻炼”，而会说“有患者互助群体提到过类似方法，但这缺乏系统研究，请主要参考主治医生的意见”。这条规则看似保守，实际上保护了用户，也保护了产品本身。

4. 实测中最磨人的两个关卡：幻觉拦截和多轮追问控场

知识库建起来之后，系统跑的是半真实场景测试。团队内部员工把身边朋友的真实困惑拿进来聊，目的就是让系统在可控范围内承受“恶劣输入”。这个阶段暴露出的问题比想象中多，最磨人的两个关卡，一个是幻觉拦截，一个是多轮追问失焦。

4.1 幻觉卡关：模型脑补了一个不存在的“检查项目”

第一次严重事故发生在一次内部测试里。有人问“孩子X染色体片段重复，有没有必要做某某检查”，系统在回答中一本正经地推荐了一个听起来很专业的检查组合，但我们核对了知识库，发现这个“检查组合”根本不存在，是模型在提示词里看到一些检查项目后，自己重新组合拼出来的。用户如果信了，去做了一个不存在的检查，后果想想都后怕。

更隐蔽的是另一种幻觉：模型把来自两个不同疾病的知识混在一起说。比如知识库里有疾病A的遗传模式，有疾病B的发病年龄，模型在回答疾病A的问题时，把疾病B的字段也勾进来了。这种幻觉单看每一句都像是真的，但合起来就是错的。我们花了很长时间才意识到，幻觉拦截不能靠提示词喊话“你要诚实”，必须做成多层机制。

4.2 拦截策略：检索阈值 + 自检提示词 + 人工抽检

我们的第一层防线是检索相关度阈值。知识检索模块会给每条召回片段打分，低于分数线的直接扔掉，不给模型利用的机会。这个阈值不能设得太高，否则召回内容太少，模型没料可用；也不能太低，否则模型会抓到大量不相关字段，增加混淆概率。我们反复调，最后定在了一个比较保守的数值，宁可不答，也不乱答。

第二层防线是自检提示词。每次生成回答之前，系统会额外执行一次校验任务：把“检索到的知识片段”和“将要输出的回答草稿”放在一起，让模型自己逐句检查是否有片段之外新增的信息。这一步听起来有点绕，但实测效果很好，能拦掉一部分实体拼接型幻觉。关键是要在提示词里把规则写死，不能留“酌情发挥”的空间。下面是我们当时用的一个简化版自检模板：

你是一名医学信息核查员。 你将收到两段内容：A为知识库片段，B为待发布的回答草稿。 请逐句检查B中每个事实性陈述是否能在A中找到直接依据。 如果B中出现了A中不存在的检查项目、药物名称、发病率数字或治疗结论， 请将对应句子标记为“无依据”，并返回核查不通过。 只有当所有事实陈述都有A的直接依据时，才返回核查通过。

第三层防线是人工抽检。我们每周随机抽取一段时间的对话记录，逐条检查回答是否存在事实错误，按严重程度分级记录。这个工作没有算法，纯靠医学编辑的耐心，但它是整个拦截链路里兜底的一环，也是我们对外宣传时敢说“系统有内容风控”的底气所在。

4.3 多轮追问失焦：用户被淹没在症状信息里

幻觉问题靠多层拦截解决之后，另一个问题浮出水面：用户跟智能体聊着聊着，就跑偏了。比如用户最初说“孩子走路有点奇怪”，系统按照症状澄清流程追问，但用户被追问几轮之后，自己也说不清了，开始讲一堆生活背景、家庭压力、求医过程，反而把最核心的症状线索淹没掉了。对话越长，系统越难判断该往哪个方向收敛。

我们后来总结出一套三阶段对话控场策略。第一阶段是症状澄清，用最多三轮追问，把核心症状、起病时间、发展趋势这“三要素”抓到。第二阶段是知识科普，基于已抓到的要素给用户看匹配的疾病科普信息。第三阶段是行动指引，告诉用户在哪里可以找什么方向的医生、需要带哪些资料、有什么高危体征要警惕。每一阶段结束时，系统都会用一句话概括当前结论，比如“我现在掌握的情况是：孩子5岁，步态不对称3个月，没有明显外伤史，家族里没有类似情况”，然后问用户“以上描述对吗”。这一句复述极其重要，它给了用户纠错的机会，也让系统在长对话中有了可以依托的锚点。

5. 上线前后的踩坑记录：审核规则、预期管理与隐私合规

系统在内部跑了两轮迭代后，我们觉得可以放出去做小范围公测了。公测阶段虽然规模不大，但踩的坑一点不少。技术问题反而好解决，最难的是规则制定和用户预期管理。医疗产品跟普通工具不一样，一个含糊的措辞就可能引发用户的错误决策，所以上线前我们专门花了两周时间，把“什么能答、什么不能答、怎么理解边界”一条条写清楚。

5.1 内容审核：哪些问题一律不答

我们列了一个“绝对不答清单”，不是技术能力达不到，而是从合规和伦理角度不该答。第一类是确诊结论，任何“我认为你这就是某某病”的句式都不能出现，哪怕知识库检索结果非常匹配也不行，系统只能说“你的症状与某类疾病存在相似之处，需要专科医生进一步排查”。第二类是处方建议，罕见病用药往往涉及超说明书用法，个体差异极大，智能体没有资格参与这类判断。第三类是试验性疗法评价，比如某些在研药物或海外尚未引进的治疗方案，系统只提示用户“可以咨询专业医生并了解正规入组渠道”，不做有效性与安全性评价。

还有一类更容易被忽视：危象征兆识别。如果用户描述中出现严重呼吸困难、高热伴意识模糊、急性肢体偏瘫这类情况，系统不管正在聊什么话题，都会立刻中断当前回答，优先提示立即就医。这个优先级规则直接写在交互层的最顶层，不参与任何普通对话的推理流程，保证任何时候都能被触发。

5.2 用户预期管理：把“不能确诊”写进产品边界

公测初期有一批用户把智能体当成了“线上确诊工具”，上来就甩一堆检查报告问“我这是不是某某病”。我们起初以为只要回答得足够谨慎就没事，后来发现用户并不在意回答里的措辞，他们只想要一个确定性结论。如果得不到，就会反复追问、换种问法继续问，甚至把系统逼到回答边缘。

问题不在模型，在产品没有在对话开头把预期讲清楚。后来我们增加了一个开场机制：新用户首次进入对话时，会看到一段固定提示，明确说明“这是一个罕见病知识科普与就诊路径辅助工具，不能替代医生诊断”。同时，系统首次检测到用户寻求确诊结论时，会自动插入一次标准话术：“我需要特别说明，我无法给出诊断，我只能根据你的描述整理相关信息，帮助你更有准备地就医。”这段提示之后，用户如果继续纠缠确诊类问题，系统会重复提示一次，之后不再回应用户的变体问法，而是引导用户提供更多症状信息，把对话拽回知识科普的轨道。这个措施上线后，用户流失率没有明显上升，反而降低了后续投诉。

5.3 隐私与未成年人保护：数据边界画清之后反而更好做

罕见病对话内容的敏感度比普通健康咨询更高。一个非常具体的罕见病症状描述，加上用户所在城市、年龄段，很可能推断出用户的真实身份。所以我们从架构上就把隐私边界画死了：系统默认不收集姓名、身份证号、联系方式、详细家庭住址。用户如果输入这类信息，系统会提示“请您不要在对话中透露个人实名信息”，但仍然会继续提供知识帮助，不会因此拒绝服务。

未成年人相关的对话尤其谨慎。大多数罕见病起病于儿童期，咨询者往往是家长。我们的做法是：涉及未成年人的咨询，统一假设操作者为监护人，如果对话中明确出现求助者是未成年人本人，系统会提醒相关内容需由监护人陪同理解。对话数据默认保留三十天后匿名化删除，不做模型训练，除非用户主动勾选“同意用于产品优化”且经过脱敏处理。这些设置听起来都是成本，但它在实际运作中帮我们挡住了很多不必要的麻烦。

6. 项目结束后我的几点保留意见

产品做了大半年，公测数据比我想象的要好，但我也比刚开始时更谨慎。团队里有人问我，这算不算是“让罕见病不再罕见”了。我的回答是，让罕见病“不再罕见”的关键不是让所有人都听说过某个病名，而是让患者不再独自面对从症状到确诊的漫漫长路。一个智能体在这条路上能做的，只是把其中一小段走得更稳。

6.1 我为什么反对用“准确率”来考核这个智能体

很多同行见面就问“你们回答准确率多少”，这个问题听起来专业，实际上很容易误导。罕见病场景里的“准确率”很难定义：用户问十句话，可能只有一句涉及某个确定性事实，其余都是主观感受、情绪表达和模糊描述。用传统问答的准确率指标来考核，只会诱导团队去回答“更安全的问题”，回避“更难但更有价值的问题”。

我更看重的指标是“行动转化率”：一次对话结束后，用户是否知道了下一步该做什么，是否理解了医生建议中某个关键术语，是否消除了某个明显误解。我们内部统计过，公测用户里，有相当比例的会话以“建议就诊”或“建议进一步检查”收尾，而且这些用户中的大部分确实进行了后续动作。这个结果比模型答得是否流畅更让我安心。

6.2 关于认知壁垒，我现在更看重“行动转化率”

做这个项目之前，我以为认知壁垒主要是“信息量不够”。做了之后才发现，信息其实一直在那里，只是它分布零散、语言晦涩、路径不明。患者家属真正需要的，不是更多更全的资料，而是有人帮他们把碎片信息拼起来、翻译成能懂的表述、并明确告诉他下一步该往哪里走。这也是为什么我认为智能体比单纯的知识库或科普文章更合适做这件事——知识库是静态的，科普文章也是静态的，而认知突破的过程是动态的，它需要对话、需要追问、需要反复确认。

6.3 后续可以继续做的事：从服务患者延伸到服务基层医生

项目当前的形态主要面向患者端，但我觉得更深的价值在基层医生端。基层医生面临的困境是：他们知道症状但不熟悉罕见病数据库，遇到奇怪病例时缺乏“该往哪个方向查”的提示。如果智能体能把知识库能力封装成一个“辅助鉴别”工具，嵌入到基层医生的日常诊疗流程中，可能比直接面向患者的社会影响力更大。

当然这个方向牵扯到的权限、合规和医疗责任问题会比患者端复杂得多，我没有把握短期内能落地。而且面向医生的产品必须接受更严苛的循证检验，数据要经过内行专家的逐条审核，误报的代价也完全不是一个量级。目前我只是在积累这方面的认知，不急着动手。做这种项目的过程中我的体会是，聪明的方法会满大街都是，真正稀缺的是对用户处境的理解，愿意慢下来把知识底座打牢、把边界画清楚。罕见病服务这条路注定不快，但走扎实一点，总归能让更多人早点少走一段弯路。