这篇文章是《关于hippocratic.ai和glass.health的产品讨论》的后续实践篇，在早期的文章中，笔者讨论了产品思路和可能的技术实现。产品功能的亮点是：患者模拟。

这是笔者非常感兴趣的地方，区别于以往的在线问诊类产品，《医疗视角: 智能问答产品事》中更加关注医生模拟，希望通过算法的能力能够辅助甚至代替医生完成一些具体工作（讨论是否要代替医生，这是一个相当无趣且没有意义的问题），这里关注的是患者模拟，希望利用大模型的能力模拟患者完成和人类医生的对话。

医生资源昂贵且稀少，因此讨论能否“机器换人”？换个角度，具体特定特点的真实患者似乎也并不多，因此“机器换人”的讨论仍旧有意义。应用的场景包括但不限于：年轻医生可以通过和模拟病人的对话，

• 提升医患对话的能力

• 医生能力培训和考核

• ......

  除此之外，这也是个性化思路的一个具体实践场景，该方向明星产品如character.ai，同时具有心理咨询机器人的一些味道，总之非常对味。

之前的文章中，可能的技术实现思路如下：

这篇文章正是对上述问题的一个具体实践。为了保持实践的整体一致性，笔者设定的场景是：一个带着宝宝的妈妈和一个儿科医生的医患对话中，通过大模型模拟这位妈妈。

上述思路中，可以通过设计prompt实现不同角色的模拟构建，这里分别采用openai的api和chatglm2-6b作为模型服务。

openai模型用来扮演医生，简单设计的prompt为，“假设你是一个儿科医生，我是一个宝宝的妈妈来就诊。开始我们的对话：”，效果如下：

首先，也许是openai的服务后端做了针对医疗问题的特殊处理，导致似乎模型对于假扮医生是抗拒的。典型的表述，“作为医生，我不能为您的宝宝开处方药”，进一步这句话自身存在事实性错误。其次，模型的回答过于严谨受约束，回答的风格和医患对话流程中的实际风格存在不一致。猜测与指令微调阶段的QA构造范式有关，本质上是一种数据偏置。

chatglm2的模型的效果如下：

经过优化的chatglm2在医生模拟这件事情上似乎做的相对较好。其中典型的表现是第二轮的回答，“宝宝发烧3天了，而且有呕吐的症状，这让妈妈很担心。”，之后就是追问“可以给宝宝多喝水吗？...”，既有上下文的利用，又有符合实际情况的推理，同时辅助合理的追问，在效果上符合预期。但是，也存在废话较多，语境不一致的问题，比如第三个轮次的回答。

openai模型用来扮演患者，简单设计的prompt为，“假设你是一个宝宝的妈妈，宝宝刚满月过几天，经常一边吃，一边拉，好像吃坏肚子了，也好像着凉了。现在你带着宝宝来找医生就诊。医生问：宝宝腹泻几天了？你答：”，效果如下：

整体的对话流程看上去相对流畅，并不像扮演医生那样的抗拒。但是也存在显著的问题，比如第三个轮次的回答，暴露了模型只是在扮演患者的事实，尤其是这句，“请提供更多相关信息...”。

chatglm2的效果如下：

整体上的回答看上去比较流畅，不过现实中似乎并不会存在每次回答均比较长的宝妈，存在一些废话。

自己的模型专注在患者模型的问题上，由于是快速思路验证，整体上采用主流的技术方案，也就是基于chatglm+sft的方案，微调方式采用ptuning，笔者尚未做过lora/ptuning等各种peft方案的具体比较，感兴趣的读者可以自行展开。为了完成模型训练，首先需要有一个医患对话的数据，可以从好大夫等互联网问诊平台上爬取，笔者选用的是ccl2021的医患对话的数据集（儿科），约2000个真实对话数据。这也就是为什么上文中也采用儿科的场景。

为了完成模型训练，考虑到上下文的拆解，2000个真实对话数据将进一步扩充得到最终的训练数据集，约为10倍。关键参数如下：

LR=1e-2PRE_SEQ_LEN=128python3 main.py \--do_train \--train_file $CHAT_TRAIN_DATA \--validation_file $CHAT_VAL_DATA \--prompt_column prompt \--response_column response \--history_column history \--overwrite_cache \--model_name_or_path ../THUDM/chatglm-6b\--output_dir $CHECKPOINT_NAME \--overwrite_output_dir \--max_source_length 1024 \--max_target_length 64 \--per_device_train_batch_size 16 \--per_device_eval_batch_size 32 \--gradient_accumulation_steps 8 \--predict_with_generate \--max_steps 5000 \--logging_steps 300 \--save_steps 625 \--learning_rate $LR \--pre_seq_len $PRE_SEQ_LEN

实际构造的训练数据格式如下：

针对患者模拟的场景，自己训练的模型的对话效果如下：

对话1-较短上下文长度

在较短的上下文场景下，整体上看模型能够回答的比较流畅。特别是第二个轮次的回答，“之前...现在”的转折回答。但是比之基于openai和chatglm2的回答，模型扮演的宝妈似乎比较冷淡，回答简单扼要。同时并没有转折或者追问等，体验上没有拉齐真实对话场景。

对话2-较短上下文长度

对话2中的回答整体上看相对流畅。有正面回答同时也有内容补充。

对话3-较长上下文长度

在较短上下文中，模型只能理解就近轮次的问答流程，多数时候表现出来就是一问一答。整体上的体验比较生硬，这对于产品的场景定位而言，这样的效果无法达到预期。对话3是显著增加上下文长度的结果。第一个回答中，有现象描述，有追问。第三个回答中，有追问，有自己理解的潜在诊疗方法，同时不存在事实性的错误。整体上的体验显著优于较短上下文。

还有一些存在问题的对话：

对话4-较短上下文

这里典型的问题是“大便次数是每天34次”。这里的“34”可能是表达“3，4”次，问题的来源可能是多种，比如训练数据中实际情况下，会用“34”表示“3，4”，也有可能模型现阶段只学到了这里是一个数据，具体是什么数据的量级，并不确定。第二个轮次，补充回答和问题语义不一致。第三轮回答中，存在事实性错误。这是一个对话过程中表现出来的显著模式，前半句和问题在语义上能够保持一致，但是回答的句内内容存在不一致。

对话5-较短上下文

这位模拟的宝妈心很大，宝宝已经咳嗽一周了，还大方的说，“没去”。

对话6-较长上下文

“橘子”?并不是“辛辣刺激性”的东西，这里存在事实性的错误。至于是怎么引入的，可能的一种场景是，实际对话中，宝妈否认了吃辛辣刺激性的东西，但是补充说，吃了一些非辛辣刺激性的东西，比如橘子?。由此confuse模型认为橘子?是辛辣刺激性的东西。第三个回答就完全是不符合答案预期。

整体上看，虽然仍旧存在大量的细节没有去做优化，但是已经能够得出一个基本结论，这件事情在技术上具备实际的可行性。进一步地扩展，可以做病种维度，科室维度等的延伸。在功能的横向拓展上，可以整合医生考试培训类的产品等，最终延伸至模拟医学的大方向上。

关于大模型的价值讨论，自己的一个观点是，热度总会回落到一个较低点，但是回落到的较低点只要比上一轮热度回落的较低点高，就会带来实际的价值。高度差也就是大模型真正带来的价值区间。个人判断，目前社区所处的位置大概如图所示，相比最热的时候已经过去了，但还处于继续下落的区间，尚未到底，这其实也是给大模型应用开发者的时间窗口。