从红薯喊我来折腾 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 召回指定区块的内容。如此即可不做认可多余开发，就实现个性化的知识召回。
粤ICP备14082021号
免费POC，
零成本试错
