从红薯喊我来折腾 AI 至今已经四个月了，很感激 Gitee AI 团队在这个过程中给与的支持与帮助，也是基于 Gitee AI 团队给我的强大信心，我们联合兄弟单位申报的国家卫健委《2024年医学工程科研项目》顺利通过审批，拿到了立项通知书。
我们的项目是一个围绕医疗设备和医用耗材开展 AI 使用探索的一个应用，涉及到 AI 方面的业务流程，主要就是需要利用 RAG+LLM 的功能，给临床提供指定型号的设备或耗材的精准指导。为此，我们选择了 Dify 做为我们的 LLM 应用开发平台。
Dify 是一款开源的大语言模型（LLM）应用开发平台。它融合了后端即服务（Backend as Service）和 LLMOps 的理念，使开发者可以快速搭建生产级的生成式 AI 应用。该平台提供了非常便捷和强大的流程编排能力，节省了我们很多工作研发开发工作。但当我们真正投入具体的业务研发中时，发现 Dify 的 RAG 体系，并不能满足实际需要，即便是它已经在最新版本中开放了 API 调用外部 RAG 的功能。
业务需求分析
在临床工作中，我们会有 L 个产品种类，每个产品种类下可能会有 M 个企业，每个企业又会有 N 个产品型号，不同的型号功能不同。在 Dify 现有的知识库体系下，我只能进行大分类的知识库归类，例如监护仪下就是所有品牌的监护仪，呼吸机下就是所有品牌的呼吸机。
这就造成了两个很严重的后果，一是搜索 A 品牌的机器却召回了 B 品牌的说明；二是搜索同品牌下 A 型号的内容却召回了 B 型号的。如此张冠李戴，显然是不符合医疗工作在精准度方面的要求。因此，我们需要针对具体型号的产品做精准内容的召回。
业务功能实现
Dify 的外部 RAG 并非良配
从业务流程上看，我们只需要输入关键词，输出召回内容即可。但细细分析，其实是经过输入关键词→特征提取→向量召回→重排→LLM处理这样的一系列操作。这里必须要给Dify一个大点赞，内置的流程编排器真的是很方便，模型服务提供商也非常全面,但在 RAG 上能力还是会稍微弱了一些。外部知识库的 API 结构和流程，看起来很不错，真正用起来实为鸡肋。
解锁新的 RAG 召回姿势
为了实现每次搜索只在限定范围内进行 RAG，经过研究，向量数据库选用 Zilliz（其实和 Milvus 大差不差，只是我懒得折腾服务器搭建）。Zilliz提供了 RESTful API，可以直接通过 API 来进行召回，Gitee AI 提供 Embedding 服务，而 Dify 有一个 HTTP 调用的节点。于是乎，一个完美的工作流就出来了：
通过 Http 节点，首先调用 Gitee AI 的特征抽取服务，获得的结果丢给 Zilliz 召回指定区块的内容。如此即可不做认可多余开发，就实现个性化的知识召回。
召回质量测试
我们根据临床常见的问题，准备了100个知识库相关的问题进行测试，最终得到的结果如下：
显而易见，通过自定义编排的向量召回流程，我们可以通过极低的实施成本，就可以得到非常高精度的召回质量。
为什么是Gitee AI
不可否认，选择 Gitee AI 是多少掺杂了一些兄弟感情在里面的，但从长远来看，成本、服务、可靠性都是必须要考虑的因素，毕竟做的可都是单位的事儿。也试过了 Dify 提供的各类模型服务平台，但我认为最省心的还是 Gitee AI。
可能有人会说 Gitee AI 的模型数量不多，但我想和各位基友说一句，服务稳定可靠比数量多更重要。 Gitee AI 没有莫名其妙的风控和莫名其妙的限流，这一点很给力。而且，你要的姿势这里都有（LLM、TEXT EMBEDDING、RERANK、SPEECH2TEXT、TTS）。
关于服务，还需要特别表扬一下 Gitee AI 团队的鼎力支持，当我将这一想法告知 Gitee AI 的开发人员后，我建议他们开发了一个 Dify 工具，可以方便我们用工具来调取 Gitee AI 的服务，经过几天的准备，这些哥弟真的做出来了。
而这个工具已经更新到了 Dify 最新版本中，欢迎各位看官使用体验。
