在Nvidia A10等显卡上部署向量模型，通常会借助Ollama或xinference这类中间件工具。目前主流的向量模型选型基本锁定在bge-m3和bge-reranker-v2-m3两个。完成配置后，在Dify平台中直接接入即可投入使用。
Dify向Milvus写入数据的运作机制
核心原理并不复杂。基于已配置完成的向量模型，Dify会通过中间件SDK或标准OpenAPI接口，将文档数据实时写入Milvus。这些数据存储后，主要用于后续的相似度检索与召回。
知识检索节点详解
谈到RAG（检索增强生成），就离不开知识检索这一关键节点。在Dify的知识库模块中，首先配置好文档的检索参数，随后在流程中直接引用该节点即可。
元数据过滤。实现起来并不困难，基础维度的数据过滤可通过默认元数据完成——在已导入的知识库中预先配置好元数据，知识索引节点即可引用这些过滤条件。
知识库配置与Milvus向量存储
知识库的配置方式直接决定了Milvus中向量的存储策略。换句话说，只要知识库配置完成，Dify就会根据预设的模型供应商（包括Text Embedding模型和Reranker模型），通过相应的OpenAPI或中间件专用SDK接口（Milvus自身提供Client SDK）完成整个向量化与存储流程。
文档导入完成后，Dify会生成对应的知识库，同时将文档转化为Embedding向量，并写入Milvus的Collection（集合）中。默认配置下，一个数据库对应多个Collection。与传统关系型数据库类比：Milvus的数据库相当于MySQL的数据库，而Milvus的Collection则相当于MySQL的表。
因此，在Dify的知识库中持续导入文件，本质上就是在不断向当前Collection追加数据。
与LLM的协同工作
首先明确什么是LLM的“协同”。严格来说，这指的是Prompt（提示词）的组装过程——RAG检索到的内容与预设的Prompt拼接在一起，最终形成一个完整的提示词，输入给LLM生成回答。但这一环节存在两个棘手问题：
- RAG检索出的文档若与问题关联度不高，反而会误导LLM，影响输出质量。
- 更重要的是，并非所有RAG检索到的内容都需要一股脑儿塞给LLM。有时强行输入反而适得其反。正确的做法是减少无效RAG的调用频率。
第一个问题的解决方案相对明确：
在RAG配置中，根据检索得分（score）过滤掉不相关的部分。只有得分较高的文档才被允许进入LLM的上下文。
这里有一个小细节需要注意：当RAG上下文为空时，预设Prompt的处理逻辑需要设计周全，否则LLM可能无法正常回应。总体而言，核心策略就是：利用score构建一道防火墙，确保只有强相关的文档才能进入预设Prompt，从而减少对LLM的干扰。
第二个问题的典型场景如下：
用户提问：“你是谁？”
RAG检索到的文档中写道：“我是xxxx。”
你看，即使RAG文档的得分很高，这种问题其实应该由LLM自身来回答，而不是每次都去文档库中翻找。问题的根源在于：避免每次都调用RAG，这正是传统RAG的一大弊端。
通常有两种解决思路：
- 依靠Prompt引导，让LLM自行判断是否调用RAG。这是最常见且最直接的做法。
- 引入Agentic RAG（智能体式RAG）。这种方式相对复杂，不确定Dify是否原生支持。若不支持，可能需要通过HTTP接口调用的方式实现。
RAG Query的优化策略
来看一个示例：
用户query：“我觉得活着没意思，我想跳桥。”
直接使用Embedding检索：
使用Embedding加上Reranker检索：
即便RAG已经引入了语义相关性，但Query本身过于模糊或带有强烈情绪，仍会严重限制检索的准确性。
解决方案：
- 进行Query改写。引入LLM，将原始Query进行改写、摘要甚至分类。
- 对文档数据进行标记。结合前一步，让改写后的Query能更精准地匹配到对应文档。
这一思路的好处不仅在于提升向量检索的准确度，在减少向量调用次数方面也很有价值——例如，可以定义某些类别的Query无需查询RAG，直接交给LLM处理即可。
总结与落地建议
RAG的实际落地并非一蹴而就，中间踩坑在所难免，上文也提到了不少常见问题。但归根结底，做好文档数据的标记、控制每段内容的长度，再导入向量库；同时优化Query改写，提高文档命中率，并避免无意义的RAG调用——把这些基础工作落实到位，RAG的效果就能显著提升。