Dify 平台知识库实战｜基于excel 格式的问答调优

处理Excel格式的知识库，如何才能在问答调优上做到最好？这个问题可能困扰了不少人。今天就来详细拆解一下，基于Dify平台，用实际的测试数据把整条链路走通。

先说结论：影响问答效果最大的变量，往往不是模型本身，而是文本分块的策略。其次是embedding模型的选择。

接下来，从平台配置、测试逻辑、到具体的优化方案，一步步来看。

一、Dify 平台信息

使用的智能体平台框架是 Dify（官网：https://dify.ai/）。这部分是知识库的基础配置，每一项都会直接影响后续的检索效果。

1-分段配置

分块最大长度设为500 tokens，重叠长度50 tokens。

2-embedding 模型

这次测试主要选择了通过ollama安装的nomic-embed-text。Dify里还配置了另外两个embedding服务：Cohere和minimax的embo-01 API。

不同内容类型对embedding模型的要求差异很大。文本、表格、代码，各有各的侧重。选择建议倒也不复杂：

• 通用应用：OpenAI的text-embedding-3-large、Cohere embed v3这类模型是稳妥的选择。
• 专业领域：BGE、GTE等开源模型在垂直领域能通过微调提升效果，值得一试。
• 混合索引策略：关键词索引加向量索引的双重方案，往往比单一索引效果更好。
• 维度陷阱：1356维与512维在很多应用场景下差异并不明显，但成本却能差出3倍。不必盲目追求高维度。

3-检索设置

这次配置了混合检索模式，兼容全文检索和向量检索的优势。相比单一检索，混合模式能在性能和效果之间取得更好的平衡。

混合检索的权重上，语义权重占比70%，关键词权重占比30%。

Rerank模型选择的是Cohere的rerank-v3.5。Top K配置为5——根据行业经验，3到5个片段是最佳区间，片段多了容易引入噪音。Score阈值设为0.5，低于这个值不会被召回。

二、测试逻辑

1-模型对比设置

同时对比三大模型的能力：deepseek v3、deepseek-r1的API，以及一个本地化部署的deepseek蒸馏qwen 14b模型。这样就能直观看出不同规模和版本的模型差异。

三、测试结果-excel 多 sheet

1-测试 excel 情况说明

测试用的是Excel表格，包含两个sheet，结构是非结构化的。表格内容是两个小家电的抖音视频拍摄脚本：一个是佐料机，另一个是高压植物奶机。分别对应《sheet1-佐料机抖音好物种草》和《sheet2 -高压植物奶机》。

2-分块效果

测试中一个很重要的经验是：Excel格式的文本块，需要先测一下一行内容最大需要多少tokens。分块最大长度至少要大于单行文本长度。

来看看分块的实际效果。Excel的切分逻辑是一行一个文本块。有意思的是，虽然人类理解表格时会把表头和内容结合起来看，但Dify在处理Excel数据分块时，500 tokens的文本块，切分结果就是一行记录一个文本块。同时，每个文本块都会带上第一行的信息——"佐料机抖音好物种草"。

比如看到的第一个文本块："佐料机抖音好物种草":"切入点";"None":"可以绞肉、剥蒜，还能绞干、湿料，终于找到大小碗兼备的绞肉机了..."

第二个文本块："佐料机抖音好物种草":"参考视频";"None":"https://www.douyin.com/video/..."

第三个文本块："佐料机抖音好物种草":"主要卖点";"None":"大小碗好处"..."

第四个文本块："佐料机抖音好物种草":"准备清单";"None":"猪肉三份，蒜头..."

那么，切换不同分块最大长度会影响什么？答案很直接：分块超过表格单行的token数量，无论如何增加分块tokens数，Dify都会按照换行符来切分文本块，结果依然是保持一行一个文本块。500 tokens的切分结果如此，2000 tokens的结果也一样。

但把tokens调小就会有不同影响。设成分块最大长度50 tokens，一行数据就被切成了6个块。

接下来是不同问题类型的问答效果对比。这里设计了两种类型：简单单一问题的问答，和复杂且需要推理的问题问答。

简单单一问题问答

问题：佐料机的卖点是什么？

先看思维推理模型的对比。控制变量下，参数规模14b的本地模型表现如何？耗时12.28秒，回答正确。满血版API模型耗时35.6秒，回答内容与14b小模型差不多，但对佐料机卖点的精髓理解得更透彻。相比之下，deepseek-chat（v3版本）的回答则比较正式，包含1到3个要点的总结，用时17.78秒。

复杂推理问题问答

问题：总结佐料机拍摄脚本的运镜特点

这里有一个关键细节。设置知识库的Top K时只选了3块，也就是知识库检索时只会找回3个超过阈值的知识块。结果检索到的是第5、6、10块，其中只有第10块有实际内容——关于近平角度的一个分镜信息。巧妇难为无米之炊，原材料有限，三个模型都编不出有效总结。

怎么优化？把Top K调整成10试试。理论上，佐料机的知识块7到28都是与运镜有关的内容，应该能命中10个。这次命中的知识块增加到了4块（19、20、23、24），有效信息块增加到4个，回答的信息确实丰富了很多。

这就很清晰了：Excel格式的知识库，在分块索引时会遇到内容与表头信息不一致的问题。一个比较实用的优化方案，是把Excel内容调整成JSON格式，再塞到知识库里做正常的索引和命中参考。

四、知识库文件优化

1-excel 表格转化成 json 结构

为了实现更好的文本理解效果，把Excel表格切换成如下的JSON结构，存储在一个txt文件里：

• 标题、"切入點"、"参考视频"等基本信息作为第一层键值。
• "演员"、"准备清单"等作为子对象。
• "分镜内容"以数组形式存储，每个分镜包含序号、景别与角度、时长、畫面简述、拍摄方式、台词等字段。

2-json格式问答效果测试

用同一个问题测试分块召回效果。知识块召回的是第1、3、5、6块。因为JSON格式内的文本块包含2到3个分镜，所以这次召回的4个知识块涵盖了4到5个、9到13个分镜内容。回答的质量自然比前面几次好太多了。

五、更换 embedding 模型

这次对比三个embedding模型：通过ollama安装的nomic-embed-text、Cohere的embed-multilingual-v3.0、minimax的embo-01。

切换位置在Dify的配置界面。同一个问题、同一个大模型，三种不同embedding模型的效果差异如何？

1-deepseek-r1 蒸馏模型14b版本

• nomic-embed-text：总结为"固定镜头为主，近景与俯视角度展示细节，多角度切换，特写镜头聚焦，连贯性展示流程"。
• minimax的embo-01：总结为"固定镜头，近景和平视角度，上移镜头，画面后期推进"。
• Cohere的embed-multilingual-v3.0：总结得最详细，包括景别角度、拍摄方式、画面简述、台词等，并具体到每个镜头的运镜方式。

2-deepseek-V3 模型

• chat+nomic-embed-text：总结为固定镜头为主、近景与俯视角度、多角度切换、特写镜头、连贯性。
• minimax的embo-01：总结为定镜拍摄、近景与俯视角度、平视角度、上移镜头、画面后期推进。
• Cohere的embed-multilingual-v3.0：总结为近景和平视、俯视角度，固定镜头，特写镜头展示操作过程。

3-deepseek-r1 模型

• reasoner+nomic-embed-text：总结为固定镜头为主、近景与特写主导、对比式构图，并具体举例了"定"拍摄方式、"近景+俯拍"、"近景+平视"以及"特俯"视角。
• minimax的embo-01：总结为"以定镜为主"、"近景与俯视结合"、"少量动态运镜"。
• Cohere的embed-multilingual-v3.0：总结为"景别以近景为主"、"角度以俯视为核心"、"固定机位强调稳定性"。

六、结论

从测试结果来看，直接决定问答效果的最大因素，是文本分段的大小。这是一个基础问题，但往往容易被忽略。

其次，embedding模型的选择也会显著影响文本的召回质量。不同模型在不同场景下的表现差异客观存在，需要根据实际业务场景来做选择。

最后，数据处理方式同样关键。Excel格式直接导入会遇到分块与表头不匹配的问题，转换为JSON等结构化格式能显著提升检索效率。说到底，知识库的质量，很大程度上取决于输入数据的组织方式。