向量模型的配置
在 Nvidia A10 等机器上，基于 Ollama、xinference 等中间件部署向量模型，目前向量模型的选型暂定为 bge-m3、bge-reranker-v2-m3；然后在 dify 内引入即可。
Dify 写入 Milvus 原理
基于配置的向量模型，通过特定的中间件 SDK 或是标准的 OpenAPI，Dify 将文档数据实时写入到 Milvus 中存储，并用于后续的检索。
知识检索节点
用于引入 RAG。在 Dify 知识库模块配置好文档的检索等参数后，直接在如下的知识库中引入即可。
元数据过滤。基础维度的数据过滤，默认的元数据在已导入的知识库中配置，如此知识索引节点便可引入元数据。
知识库的配置&Milvus 向量存储
知识库的配置，直接决定了 Miluv 向量的存储，即配置好了知识库，Dify 通过预先配置的模型提供商中的 Text Embedding 模型与 Reranker 模型，以及相应的 OpenAPI 或中间件特定 SDK 接口（譬如 Mivlus 有自己的 client sdk）。
如上导入完文档后，Dify 就会生成知识库，同时会将文档转换为 Embedding，并写入到 Milvus 的 Collection 内。
默认是单数据库多 Collection。与传统关系型数据库的对应关系是，Milvus 库->Mysql 库，Milvus Collection-> Mysql Table。
而在 Dify 的知识库内不断的导入文件，则是往当前的 Collection 内写入数据。
LLM 的协同
什么是 LLM 的协同，这个协同严格来说，是指 Prompt 的组装；即 RAG 检索的内容与预设的 prompt 组装成最终的 Prompt，作为提示词输入到 LLM 中返回响应，但这里就存在两个问题：
RAG 检索到的不太相关的文档，对 LLM 的输出反而会产生影响。 并不是所有 RAG 检索到的内容，都需要送入到 LLM 中，这种情况下反而会误导 LLM，应该降低无效 RAG 的调用率。
对于第一个问题，解决方案如下：
在 RAG 的配置中，根据检索得分（score）过滤不相关的内容，在 LLM 中，只有 RAG 检索到的高分文档，才引入到 LLM 中作为上下文。
但有个不足，需要处理好预设 Prompt 在 RAG 上下文为空时的提示词。
总的来说，通过 score 限定只有强相关的文档才会被引入到预设 Prompt 中，避免对 LLM 不必要的影响与误导。
第二个问题的场景最典型的是：
query：你是谁？
RAG 文档检索：我是 xxxx。
基于 RAG 的 Prompt 可能就会被 RAG 文档的内容误导，即使此时 RAG 的文档得分很高，其实对于这类问题，应该是由 LLM 自己来回答，而不用每次调用 RAG 检索一遍文档。
因此第二个问题最核心的点是在：避免每次都调用 RAG。而这也是传统 RAG 的弊端。
解决方案一般是如下两个：
基于 Prompt 指导，LLM 自行判断。这也是最常见的方式 Agentic RAG。比较麻烦，不知道 Dify 能否原生的支持；否则的话，就只能用 HTTP 接口调用的方式了。
RAG query 的优化
示例如下：
query："我觉得活着没意思，我想跳桥。"。
RAG 检索（embedding）：
RAG 检索（embedding+reranker）：
即便 RAG 检索引入了语义相关性，但受限于 query，还是有很大的阻碍。
解决方案
query 改写，即引入 LLM 将 query 改写摘要并分类。 标记文档数据，结合上面一点，使得 query 能够更准确的挂靠上文档。
对于这种方案，不仅仅是增强了向量检索的准确度，而且在减少向量调用率上也是非常有用的，即定义某些类别的 query 不需要查询 RAG，而是直接走 LLM。
总结与解决方案
RAG 的引入不是一蹴而就，虽然期间会有很多的问题，如上也阐述了一些；但归根来说，只要将文档数据标记好，并整理好每段的内容长度，再导入向量中。同时改写 query，使得文档的命中率更高，同时避免无谓的 RAG 的调用。
