ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif; white-space: normal; padding: 0px; font-size: 22px; display: table; margin: 30px auto 8px;">业务需求分析ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif; white-space: normal; padding-top: 8px; padding-bottom: 8px; line-height: 26px; color: rgb(74, 74, 74);">在临床工作中,我们会有 L 个产品种类,每个产品种类下可能会有 M 个企业,每个企业又会有 N 个产品型号,不同的型号功能不同。在 Dify 现有的知识库体系下,我只能进行大分类的知识库归类,例如监护仪下就是所有品牌的监护仪,呼吸机下就是所有品牌的呼吸机。ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif; white-space: normal; padding-top: 8px; padding-bottom: 8px; line-height: 26px; color: rgb(74, 74, 74);">这就造成了两个很严重的后果,一是搜索 A 品牌的机器却召回了 B 品牌的说明;二是搜索同品牌下 A 型号的内容却召回了 B 型号的。如此张冠李戴,显然是不符合医疗工作在精准度方面的要求。因此,我们需要针对具体型号的产品做精准内容的召回。ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif; white-space: normal; padding: 0px; font-size: 22px; display: table; margin: 30px auto 8px;">业务功能实现ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif; white-space: normal; padding: 0px; font-size: 20px; display: table; margin: 30px auto 16px;">Dify 的外部 RAG 并非良配
从业务流程上看,我们只需要输入关键词,输出召回内容即可。但细细分析,其实是经过输入关键词→特征提取→向量召回→重排→LLM处理这样的一系列操作。这里必须要给Dify一个大点赞,内置的流程编排器真的是很方便,模型服务提供商也非常全面,但在 RAG 上能力还是会稍微弱了一些。外部知识库的 API 结构和流程,看起来很不错,真正用起来实为鸡肋。
解锁新的 RAG 召回姿势
为了实现每次搜索只在限定范围内进行 RAG,经过研究,向量数据库选用 Zilliz(其实和 Milvus 大差不差,只是我懒得折腾服务器搭建)。Zilliz提供了 RESTful API,可以直接通过 API 来进行召回,Gitee AI 提供 Embedding 服务,而 Dify 有一个 HTTP 调用的节点。于是乎,一个完美的工作流就出来了:
通过 Http 节点,首先调用 Gitee AI 的特征抽取服务,获得的结果丢给 Zilliz 召回指定区块的内容。如此即可不做认可多余开发,就实现个性化的知识召回。