因为我自己也在因为我自己在做一个类似的知识库的问答的产品，之前也分享过一些 RAG 的基础知识，大家感兴趣可以看下。
目前 RAG 已经逐步成为大模型从聊天工具转向个人助理的基石，今天分享下 阿福在 RAG 场景下的一些创新性产品设计。
我之前有个类似场景的产品，也还在艰难探索中。但是只有 RAG 真正能够基于企业内部的场景，解决各种随时可见的公司内部专业术语等，做出准确的解答，才有真正的价值。
快速介绍一下阿福
简单说一下阿福，阿福就是支付宝推出的健康类的大模型产品，然后主要解决的就是医疗类的相关功能。针对 RAG 板块，你针对健康类/医疗类的所有的问题都可以咨询他。
目前用户数也非常的庞大，在 AI 类 app 中 26 年 1 月份，日活 600 万，排名第八，是个非常恐怖的存在了。从应用的场景上来说，一个纯医疗类的垂类场景的产品，能够做到跟通用类的是一个程度，本身就非常非常牛逼了，他给我们在 AI 场景的实际落地中非常多的可借鉴经验。
我从我自己的项目经验做一下解读，看看如何通过产品设计，做出一个智能度与用户诉求相匹配的产品 。
undefined
进入正题
阿福 RAG 需要解决的是个什么问题？
1、用户表达能力有限，难以一次性表达清楚自己的疑问；
2、知识库非常繁杂，夹杂大量专有名词，知识库本身就是有着非常高的门槛；
3、对于准确性要求非常高，是解决具体问题的，对于错误回答、答非所问容忍度很低；
4、时效敏感，是属于实时交流产品，对于等待时长容忍度有限
从实时 RAG 知识库问答的角度来说，阿福这就是一个地狱场景：知识库高度垂直、非标、用户表达能力有限、准确性要求高、时效容忍度低无法嫁接太多策略。
一、意图引导
这部分是最亮眼的部分，也是给我最大启发的部分。如何让一个普通不懂医疗的用户通过这一个产品，获得最终的诊断结果。
这个就要求阿福实际就能够做到像门诊医生一样，逐步追问，引导用户不断补充信息，排查其他症状，确定用户最终的真实的病症。
1.1 点选形式的可选候选项
当你提出一个问题以后，通过知识库以及当前用户提供的信息去提供候选选项，可以让用户通过点券的方式快速地补充信息。同时兼容异常场景，允许用户二次修改与补充。
添加图片注释，不超过 140 字（可选）
- • 点选的形式其实在侧面上解决了表达一致性的问题，避免用户专有名词的录入不一致，导致后续生成有问题。
- • 另外点选的形式还可以去激发跟引导用户去思考与表达，避免用户的片面性表达。
说起来简单，但是实际的落地会比这个难很多。从我最近实际推进的项目上，给大家分享一下：
候选项的准确性
如何保证候选选项的准确性？ 这个其实比我们大部分人想象的要更加的困难。
大模型本身就是一个概率模型，如果直接使用大模型，直接需要从知库中获取内容，然后总结出来可对应的候选选项。大模型会存在幻觉问题与不一致的问题，针对 bad case 的干预也会很麻烦，响应时效决定了我们无法加太多的策略上去。
如果换一个思路，就是提前去维护好这种候选选项。那么它的运营的工作量也是非常非常巨大的，特别是对于阿里的这种医疗类的各种症状千奇百怪。
猜测可能大概率是基于知识库提前调用更加强大、更复杂的 Agent 流程，提前给知识库生成了候选选项，后续命中知识库后，直接选择性使用。 当然这个是我的推测，实际不一定这么处理的。
1.2 追问先后顺序的把握
那当用户的答是非常模糊的时候，那你到底应该先问什么问题，理论上，你需要由浅入深地去做追问。但这个也会非常非常难，什么叫浅，什么叫深？基于用户表达，现在可能有 20 种情况，应该选让用户确认哪些病症？
如果直接使用大模型，大模型可能会在用户刚提问的时候就问一些非常细节的问题，然后用户就觉得你猜的这个太不准确了，然后用户的粘性就下降了，用户就流失了。
我们自己尝试的时候，把他定义为追问层级，人工维护或者大模型实时生成，也就会有上面说的候选项类似问题。实际生产场景建议提前维护追问的层级信息，供后续大模型直接使用。
二、知识检索与召回
这种专有知识库，在召回的时候，用户表达稍微有点偏差，检索的效果就很差。大模型本身又是基于检索结果进行回答，导致一旦检索错误，大模型就开始幻觉严重，答非所问。
基于这种问题，可以尝试探索 RAG 的各个细分方向，例如 graph RAG、阿里开源的 kag 、light RAG 等各个方向，目前这块还没有通用的解决方案，具体 RAG 的检索相关内容可以参考我之前的一些分享。
三、多模态的引入
文字的表达信息密度很低，其实完美的方案是支持图像上传，我觉得阿福做得比较好的是针对有一些人图片拍摄不规范，他做了一个引导页。
但是对于我们很多人来说。并没有可复制性，因为训练一个，或者是说微调一个自己的多模态大模型成本以及要求的规范数据量都太大了。如果通用的模型能够基本解决大家的问题的话，可以引入多模态，如果目前通用模型效果比较差的话，建议还是等一下。
添加图片注释，不超过 140 字（可选）
四、时效性要求
4.1 生成中的交互设计
虽然最终的准确性应该是与你的交互设计没什么关系，但是如果你的视效设计很差，用户在使用过程中就就走了，解答率或者用户的粘性就很差
阿福这里的话，一共做了两个个是动态实时显示检索的过程，包括检索的一些知识库以及思考过程以及答案的流式输出，增强用户的信赖度以及降低用户等待的焦虑感。
添加图片注释，不超过 140 字（可选）
4.2 追问深度的把握
这个也是大模型很头疼的事情，需要追问的时候乱给答案，在需要给答案的时候要一直追问，导致用户的体感很差。
在生成追问的时候，你也可以直接跳过补充追问的内容，直接进行答案生成，从而避免一直在被追问，无法获得答案。
添加图片注释，不超过 140 字（可选）
在一些初步能够给出答案的场景，直接给出初步答案，同时引导用户补充信息，这个感觉就是一个天才的设计，我们之前就卡在这里，一直纠结灰度提问的时候，到底应该走追问还是问答，很难准确度与答案生成的速度，阿福的这个方案，很好的解决了这个问题。
添加图片注释，不超过 140 字（可选）
五、高准确性诉求下的解法
5.1 样式设计以及专有名词的设计
虽然大模型生成的基本也是 md 格式，但是做了样式的深度定制，看着就非常舒服，另外针对医疗的专有名词，可以直接显示并且查看，进一步加强用户的信赖度，并且也给用户做自行判断的一个通路。
同时在检索过程中，有时候也会显示检索的内容标题，进一步提升权威度，加强用户的信心。
5.2 转人工的设计
针对高准确性要求，还是引入了人工进行一个兜底。但是，我觉得他的产品方案设计得挺好的。他并不是说，你觉得 AI 有问题需要转人工进行解答，而是另外一个思路就是本次 AI 诊断的记录由人工进行复核，然后人工复核完成以后再通知你。这样的表达方式，让用户对于阿福的信赖度更高。
总结
总结下来，阿福通过自己创新的产品的设计，点选形式的信息补充、
在当前大模型的能力之下，就给用户提供一个真正面向 C 端的医疗问答工具，非常的厉害。
如果续如果还有一些其他发现的亮点，再跟大家分享。也欢迎大家留言自己发现的亮点，一起交流学习。
