Dify 知识库相关备忘
2025-03-13 tech llm dify 10 mins 12 图 3528 字
在上一篇文章讲了 Dify 如何安装和简单运行,这一篇接着往下记录,主要是知识库相关的只言片语,参考了官方手册和论坛上的一些讨论。因为现在刚开始接触,可能不够准确,以后会增量更新。
背景
Dify 是一个 LLMOps 服务, 涵盖了大语言模型(如GPT系列)开发、部署、维护和优化的一整套实践和流程。可以大幅简化大模型应用的开发,涉及到模型训练、部署、监控、更新、安全性和合规性等方面。
基于 Dify 可以在不需要太多开发的情况下,快速搭建一个大模型应用。应用中可以调用 Dify 中内置的大量基础能力,比如知识库检索 RAG,大模型调用。通过可插拔式的组合构建大模型应用。
使用 LLMOps 平台前的开发过程:
- 数据准备:手动收集和预处理数据,可能涉及到复杂的数据清洗和标注工作,需要编写较多代码。
- Prompt Engineering:开发者只能通过调用 API 或 Playground 进行 Prompt 编写和调试,缺乏实时反馈和可视化调试。
- 嵌入和上下文管理:手动处理长上下文的嵌入和存储,难以优化和扩展,需要不少编程工作,熟悉模型嵌入和向量数据库等技术。
- 应用监控与维护:手动收集和分析性能数据,可能无法实时发现和处理问题,甚至可能没有日志记录。
- 模型微调:自行处理微调数据准备和训练过程,可能导致效率低下,需要编写更多代码。
- 系统和运营:需要技术人员参与或花费成本开发管理后台,增加开发和维护成本,缺乏多人协同和对非技术人员的友好支持。
一个典型的应用如下所示:
简单的 Dify RAG 模块化结构如下所示:
一、分段和清洗
在 RAG 的生产级应用中,为了获得更好的数据召回效果,需要对多源数据进行预处理和清洗,即 ETL (extract, transform, load)。为了增强非结构化/半结构化数据的预处理能力,Dify 支持了可选的 ETL 方案:Dify ETL 和 Unstructured ETL 。Unstructured 能够高效地提取并转换你的数据为干净的数据用于后续的步骤。Dify 各版本的 ETL 方案选择:
SaaS 版不可选,默认使用 Unstructured ETL;
社区版可选,默认使用 Dify ETL ,可通过环境变量开启 Unstructured ETL;
文件解析支持格式的差异:
Dify ETL Unstructured ETL txt、markdown、md、pdf、html、htm、xlsx、xls、docx、csv
txt、markdown、md、pdf、html、htm、xlsx、xls、docx、csv、eml、msg、pptx、ppt、xml、epub
不同的 ETL 方案在文件提取效果的方面也会存在差异,想了解更多关于 Unstructured ETL 的数据处理方式,请参考官方文档。 https://docs.unstructured.io/open-source/core-functionality/partitioning
1.1 分段
由于大语言模型的上下文窗口有限,无法一次性处理和传输整个知识库的内容,因此需要对文档中的长文本分段为内容块。
LLM 能否精准地回答出知识库中的内容,关键在于知识库对内容块的检索与召回效果。类似于在手册中查找关键章节即可快速得到答案,而无需逐字逐句分析整个文档。经过分段后,知识库能够基于用户问题,采用分段 TopK 召回模式,召回与问题高度相关的内容块,补全关键信息从而提高回答的精准性。
在进行问题与内容块的语义匹配时,合理的分段大小非常关键,它能够帮助模型准确地找到与问题最相关的内容,减少噪音信息。过大或过小的分段都可能影响召回的效果。
针对 1.0.0 版本的 Dify,一开始创建知识库时候可以选择通用和父子分段两种模式。
与通用模式相比,父子模式采用双层分段结构来平衡检索的精确度和上下文信息,让精准匹配与全面的上下文信息二者兼得。
这两种模式选定后,后期管理知识库时不可以再修改,单个文档可以针对某个模式下的细节调整(但不可以由父子分段改为通用分段或反过来调整):
1.2清洗
为了保证文本召回的效果,通常需要在将数据录入知识库之前便对其进行清理。例如,文本内容中存在无意义的字符或者空行可能会影响问题回复的质量,需要对其清洗。Dify 已内置的自动清洗策略,详细说明请参考 ETL。
二、索引
2.1 Embedding 模型
Embedding 嵌入是一种将离散型变量(如单词、句子或者整个文档)转化为连续的向量表示的技术。它可以将高维数据(如单词、短语或图像)映射到低维空间,提供一种紧凑且有效的表示方式。这种表示不仅减少了数据的维度,还保留了重要的语义信息,使得后续的内容检索更加高效。
Embedding 模型是一种专门用于将文本向量化的大语言模型,它擅长将文本转换为密集的数值向量,有效捕捉语义信息。
如需了解更多,请参考:《Dify:Embedding 技术与 Dify 知识库设计/规划》。https://mp.weixin.qq.com/s/vmY_CUmETo2IpEBf1nEGLQ
不知道为什么
shaw/dmeta-embedding-zh
添加不进来,nomic-embed-text
是可以的。先不管他了。
2.2 检索设置
知识库在接收到用户查询问题后,按照预设的检索方式在已有的文档内查找相关内容,提取出高度相关的信息片段供语言模型生成高质量答案。
-
向量检索
- TopK 筛选:挑选出与用户查询最相关的文本段落。系统会根据所选模型的上下文窗口大小自动调整选取的段落数量。
- Score 阈值设置:确定文本段落筛选的相似度门槛,即仅召回分数超过设定值的文本段落。
- Rerank 重排序模型:将使用第三方 Rerank 模型再一次重排序由向量检索召回的内容分段,提升输出的质量。启用重排序模型后,TopK 和 Score 阈值的设置仅适用于重排序阶段
-
全文检索
索引文档中的所有词汇,从而允许用户查询任意词汇,并返回包含这些词汇的文本片段。
-
混合检索
向量检索和全文检索在召回测试中有着不同的表现:
- 向量检索基于语义理解,能够找到与查询语义相近的文本,即使查询词与文档中的词汇不完全匹配,也可能得到相关的结果;
- 全文检索主要依赖于关键字的匹配,适用于简短字符的匹配,并倾向于匹配低频词汇。
通过结合多个检索系统,混合检索策略实现了不同检索技术之间的相互补充。
2.3 Rerank
Rerank 重排序模型通过计算候选文档集合与用户查询的语义契合度,进而对这些文档进行基于语义的重新排序,以此提升排序的准确性。该过程涉及对用户查询与每份候选文档之间的相关性分数进行计算,并按照相关性分数从高到低对文档列表进行排序。常见的重排序模型包括:Cohere rerank、bge-reranker 等。重排序通常被置于搜索流程的最终阶段,它特别适用于整合并优化来自不同检索系统的搜索结果。
三、召回测试与优化
完成文档的上传和索引后,我们需要对知识库进行召回测试,以确保能够准确地从知识库中检索出与查询相关的信息。
召回测试可以在App中测试,也可以在知识库中测试。在APP中可以加入多个知识库进行测试。
四、其他
知识库请求频率限制
知识库请求频率限制,指一个工作区在知识库中每分钟可执行的最大操作数。这些操作包括数据集创建、文档管理,以及在应用或工作流中的知识库查询。
工具
工具可以扩展 LLM 的能力,比如联网搜索、科学计算或绘制图片,赋予并增强了 LLM 连接外部世界的能力。Dify 提供了两种工具类型:第一方工具和自定义工具。
参考资料
- Dify中文手册 https://docs.Dify.ai/zh-hans
- 易迟:Github 上 Star 数最多的大模型应用基础服务 Dify 深度解读(一)
- 易迟:Dify框架增强:RAG 能力提升探索与实践
- 易迟:深入 Dify 源码,洞察 Dify RAG 切片机制实现细节
- 你的大模型应用表现真的好吗?借助 Dify + Langfuse 一探究竟
- 基于Dify开发的多模态大模型应用-智能铭牌识别(附代码)
- Dify 零代码 AI 应用开发:快速入门与实战
- 指定分段模式 - Dify 手册
- Dify.AI 用户直面会总结:Embedding 技术与 Dify 数据集设计/规划
- Dify 知识库构建并知识检索