03-Dify知识库搭建实战专利文档TXT+Excel

Dify 知识库搭建实战：模型集成与专利 Excel/TXT 双方式导入效果对比

本篇为系列第三篇，进入 RAG 核心------知识库。我们以专利文档 为实战案例，先讲知识库必须集成的模型，再对比「Excel 直接导入」和「转 TXT 后导入」两种方式的实际效果差异。

实战数据：《人工智能领域专利汇总_100条.xlsx》，100 条专利，9 个字段。

一、知识库搭建前的准备：模型集成

很多人搭建知识库时只关注「上传文档」，却忽略了一个前提：知识库必须先配置好模型，否则文档无法向量化，知识库等于空壳。

1.1 知识库需要哪些模型？

Dify 知识库的完整链路涉及三类模型，本专栏全部采用本地化部署（Ollama），完全离线、数据不出内网：

模型类型	作用	是否必须	本地模型推荐
Embedding 模型	把文本转换为向量，实现语义检索	✅ 必须	`qwen3-embedding:0.6b`（MTEB 多语言榜单第 1，中文效果强，支持 32K 长文本，Ollama 一键部署）
LLM 推理模型	基于检索结果生成最终回答（在应用层配置，非知识库层）	✅ 必须（做问答时）	`qwen2.5:7b`（中文开源首选，Ollama 部署）
Rerank 重排序模型	对检索结果重新排序，提升召回精度	⭕ 可选（高精度场景推荐）	`qwen3-reranker:0.6b`（同系列配套，本地部署）

核心理解：Embedding 模型是知识库的灵魂。文档上传后，Dify 调用 Embedding 模型把每个分段转换为向量存入向量数据库；用户提问时，同样用 Embedding 模型把问题转成向量，再和文档向量做相似度匹配。Embedding 模型的质量直接决定检索准不准。

本专栏全部采用本地化方案，所有模型都通过 Ollama 在本地运行，不调用任何云端 API，数据完全不出内网，适合企业私有化部署场景。

1.2 配置 Ollama 与本地 Embedding 模型（核心步骤）

本专栏的 Embedding 模型使用 Ollama 本地部署的 qwen3-embedding:0.6b，这是阿里通义 2025 年发布的新一代 Embedding 模型，在 MTEB 多语言榜单排名第 1，中文效果强，支持 32K 长文本，完全离线。

前提条件（第一篇已完成）：

Windows 已安装 Ollama 并运行
已设置环境变量 OLLAMA_HOST=0.0.0.0（允许 Docker 容器访问）
已拉取模型：ollama pull qwen3-embedding:0.6b（Embedding）和 ollama pull qwen2.5:7b（LLM）

第一步：确认 Ollama 供应商已配置

进入「模型供应商」→ 找到「Ollama」→ 确认状态为「已设置」。如果还没配置：

点击 Ollama →「设置」
模型运行环境填写：http://host.docker.internal:11434
- ⚠️ Windows Docker 环境必须用 host.docker.internal，不能用 127.0.0.1（容器内部指向自己，不是 Windows 主机）
点击「保存」

第二步：添加本地 Embedding 模型

点击「Ollama」供应商 →「添加模型」
模型类型选择「Embedding」
模型名称填写 qwen3-embedding:0.6b（必须和 Ollama 中拉取的模型名完全一致）
点击「保存」

第三步：验证模型是否可用

进入「模型」页面 → 筛选「Embedding」类型 → 确认 qwen3-embedding:0.6b 状态为「可用」。

验证连通性（可选）：在 Git Bash 中执行 docker compose exec api curl http://host.docker.internal:11434/api/tags，能返回模型列表（包含 qwen3-embedding:0.6b 和 qwen2.5:7b）说明连通正常。

qwen3-embedding:0.6b 核心优势：

MTEB 多语言榜单第 1（70.58 分），中文、英文、代码检索全面领先

支持 32K 长文本，专利长摘要不会被截断（bge-large 只有 512）

支持 MRL 灵活维度裁剪，可按需把 1024 维降到 512/256，节省向量库存储

指令感知（Instruction-aware），可通过指令引导检索方向

显存仅约 1.8-2.1GB，速度比 bge-large 快约 23%

其他本地 Embedding 模型选项：

bge-m3：多语言支持好，成熟稳定，但序列长度仅 8192

nomic-embed-text：超轻量级，速度极快，适合超大规模数据

bge-large：经典中文标杆，成熟稳定，社区资料多，但序列长度仅 512

1.3 配置本地 LLM 推理模型（问答时用）

知识库本身只负责检索，最终回答由应用层的 LLM 生成。所以还需要配置本地 LLM 模型：

进入「模型供应商」→「Ollama」→「添加模型」
模型类型选择「LLM」
模型名称填写 qwen2.5:7b（必须和 Ollama 中拉取的模型名一致）
模型上下文长度建议设置为 8192 或更高（根据显存调整）
保存

本专栏推荐本地组合：Embedding 用 qwen3-embedding:0.6b + LLM 用 qwen2.5:7b。

显存要求：7B 模型量化后约 5-8GB 显存，qwen3-embedding:0.6b 约 1.8-2.1GB，合计约 7-10GB 显存

如果显存不足（<8GB）：LLM 可改用 qwen2.5:3b 或 qwen2.5:1.5b，Embedding 可改用 nomic-embed-text（更轻量）

如果显存充足（>16GB）：LLM 可改用 qwen2.5:14b，Embedding 可改用 qwen3-embedding:4b（精度更高）

1.4 模型配置验证清单

搭建知识库前，确认以下三项：

Ollama 服务正在运行（Windows 任务栏托盘图标正常）
Embedding 模型 qwen3-embedding:0.6b 已添加且状态可用
LLM 模型 qwen2.5:7b 已添加且状态可用
Docker 容器能访问 Ollama（host.docker.internal:11434 连通）

常见坑：只配置了 LLM，忘了配置 Embedding，结果上传文档后一直卡在「向量化中」，或者直接报错。知识库必须有 Embedding 模型才能工作。

另一个常见坑：Ollama 模型名填错（如填 qwen3-embedding 省略了 :0.6b 标签），导致模型调用失败。模型名必须和 ollama list 中显示的完全一致，包括标签部分。

二、方式一：专利 Excel 直接导入创建知识库

模型配置好后，开始搭建知识库。第一种方式：直接上传 Excel 文件，不做任何预处理。

2.1 创建知识库并上传 Excel

左侧菜单 →「知识库」→「创建知识库」
填写名称：专利知识库-Excel直接导入
选择「上传文件」→ 选择 人工智能领域专利汇总_100条.xlsx
点击「下一步」

2.2 分段设置

上传 Excel 后，进入分段设置页面：

设置项	推荐值	说明
分段方式	自动分段	Excel 按行解析，自动分段即可
分段长度	默认（通常 1000+）	一行专利数据通常 300-500 字，小于默认分段长度
分段重叠	默认	行级数据不需要重叠
索引方式	高质量（向量索引）	专利检索需要语义理解
Embedding 模型	qwen3-embedding:0.6b	已配置的本地 Ollama 模型

点击「保存并处理」，等待向量化完成。

2.3 解析效果观察

处理完成后，进入知识库详情页，观察：

文档数量：1 个（整个 Excel 算一个文档）

分段数量 ：点击文档查看分段，通常是 100 个分段（一行专利 = 一个分段），但可能出现以下情况：

如果某行的摘要特别长（超过分段长度），可能被拆成 2 个分段
如果 Excel 有合并单元格或空行，可能出现异常分段

分段内容格式：Dify 解析 Excel 时，通常会把一行的所有字段拼接成一段文本，格式类似：

复制代码

序号: 1
专利号: CN202113341057.A
专利名称: 面向图像识别场景的计算机视觉推理加速方法
申请人: 哈尔滨工业大学
申请日: 2019-02-24
公开日: 2020-08-03
IPC分类号: G06N5/04
摘要: 本发明公开了一种基于计算机视觉的图像识别方法...
法律状态: 授权

注意：Dify 对 Excel 的解析格式可能因版本而异，有的版本用「字段名: 值」格式，有的版本直接拼接值。实际效果以你的 Dify 版本为准。

2.4 召回测试

在知识库详情页点击「召回测试」，用以下问题测试：

测试类型	测试问题	预期效果
专利号精确查询	`CN202113341057.A`	应返回对应专利的分段
技术主题查询	`图像识别方法`	应返回多件图像识别相关专利
申请人查询	`哈尔滨工业大学`	应返回哈工大的专利
技术问题查询	`如何提高图像识别准确率`	应返回相关专利的摘要
模糊查询	`那个用神经网络做图片分类的专利`	应能语义匹配到相关专利

2.5 方式一的优缺点

优点	缺点
操作最简单，直接上传即可	Excel 解析格式不可控，字段拼接可能混乱
一件专利≈一个分段，粒度合理	长摘要可能被拆分，导致一件专利内容分散
适合快速验证	无法单独管理某件专利（整个 Excel 是一个文档，禁用/删除只能针对整个文件）
	新增专利需要重新上传整个 Excel

三、方式二：专利 Excel 处理为 TXT 后导入

第二种方式：先把 Excel 转换为结构化 TXT，再上传。这是推荐的生产级做法。

3.1 Excel 转合并 TXT 预处理

用 Python 脚本把 Excel 的所有专利合并为一个结构化 TXT 文件，每件专利之间用分隔符隔开：

python 复制代码

import pandas as pd

# 读取 Excel
df = pd.read_excel('人工智能领域专利汇总_100条.xlsx')

# 为每件专利生成结构化文本
def build_patent_text(row):
    parts = []
    parts.append(f'【序号】{row["序号"]}')
    parts.append(f'【专利号】{row["专利号"]}')
    parts.append(f'【专利名称】{row["专利名称"]}')
    parts.append(f'【申请人】{row["申请人"]}')
    parts.append(f'【申请日】{row["申请日"]}')
    parts.append(f'【公开日】{row["公开日"]}')
    parts.append(f'【IPC分类号】{row["IPC分类号"]}')
    parts.append(f'【法律状态】{row["法律状态"]}')
    parts.append(f'【摘要】{row["摘要"]}')
    return '\n'.join(parts)

# 生成所有专利的文本，用分隔符隔开
patent_texts = df.apply(build_patent_text, axis=1).tolist()
# 用双换行 + 分隔线 + 双换行隔开每件专利，便于 Dify 按段落分段
all_text = '\n\n---\n\n'.join(patent_texts)

# 写入一个合并的 TXT 文件
with open('专利全集_100条.txt', 'w', encoding='utf-8') as f:
    f.write(all_text)

print(f'成功生成合并 TXT 文件，共 {len(df)} 条专利')
print(f'文件大小：{len(all_text)} 字符')

生成的合并 TXT 文件内容结构如下（前两件专利示例）：

复制代码

【序号】1
【专利号】CN202113341057.A
【专利名称】面向图像识别场景的计算机视觉推理加速方法
【申请人】哈尔滨工业大学
【申请日】2019-02-24
【公开日】2020-08-03
【IPC分类号】G06N5/04
【法律状态】授权
【摘要】本发明公开了一种基于计算机视觉的图像识别方法...

---

【序号】2
【专利号】CN202114335942.A
【专利名称】基于机器学习的数据分类分类方法及终端
【申请人】上海交通大学
...

关键设计：每件专利之间用 \n\n---\n\n（双换行+分隔线+双换行）隔开。这样 Dify 自动分段时会按段落边界切分，确保一件专利的内容完整在一个分段里，不会把两件专利混在一起。
实战数据：100 条专利合并后，文件约 35000-40000 字符，每件专利约 350-400 字符，编码统一为 UTF-8，无乱码。

3.2 上传合并 TXT 创建知识库

左侧菜单 →「知识库」→「创建知识库」
填写名称：专利知识库-TXT合并导入
选择「上传文件」→ 选择 专利全集_100条.txt（一个文件）
点击「下一步」

3.3 分段设置（关键）

合并 TXT 包含 100 条专利，分段设置直接决定检索效果，推荐以下配置：

设置项	推荐值	说明
分段方式	自定义分段	精确控制分段边界，确保一件专利=一个分段
分段标识符	`\n\n---\n\n`	用我们预处理时的分隔符作为分段标识
分段长度（chunk_size）	1000 字符	每件专利约 350-400 字符，1000 足够容纳一件完整专利
分段重叠（chunk_overlap）	0	每件专利独立完整，不需要重叠
预处理规则	勾选「去除多余空格」	清理格式
索引方式	高质量（向量索引）	同方式一
Embedding 模型	qwen3-embedding:0.6b	同方式一，本地 Ollama 模型，保证对比公平

为什么用自定义分段而不是自动分段？

自动分段可能把一件专利拆成 2 段（如果摘要较长），也可能把两件专利合并到一个分段（如果分隔符不被识别）

自定义分段用我们预设的分隔符 --- 切分，保证一件专利=一个分段，100 条专利=100 个分段，精确可控

点击「保存并处理」，等待向量化完成。

3.4 解析效果观察

处理完成后，进入知识库详情页：

文档数量：1 个（整个合并 TXT 是一个文档）

分段数量 ：100 个分段（一件专利 = 一个分段，精确对应，无拆分、无合并）

分段内容格式：完全是我们预处理时定义的结构化格式，字段清晰，用【专利号】【摘要】等标签分隔，无格式混乱。每个分段开头就是专利号，引用展示时一目了然。

对比方式一（Excel 直接导入）：方式一也是约 100 个分段，但分段格式由 Dify 自动解析，不可控；方式二的分段格式完全由我们定义，结构化标签清晰，Embedding 质量更高。

3.5 召回测试

用和方式一完全相同的问题测试，保证对比公平：

测试类型	测试问题	预期效果
专利号精确查询	`CN202113341057.A`	应返回对应专利的分段
技术主题查询	`图像识别方法`	应返回多件相关专利
申请人查询	`哈尔滨工业大学`	应返回哈工大的专利
技术问题查询	`如何提高图像识别准确率`	应返回相关专利摘要
模糊查询	`那个用神经网络做图片分类的专利`	应能语义匹配

3.6 方式二的优缺点

优点	缺点
分段精准：自定义分段确保一件专利=一个分段，无拆分无合并	需要写脚本做预处理（但脚本可复用）
格式完全可控：结构化标签清晰，字段不混乱	首次配置稍费时间
上传简单：只需上传 1 个文件，不用批量选 100 个文件	新增专利需重新生成合并文件并上传（或追加到文件后重新解析）
检索精度更高：结构化文本+干净格式，Embedding 质量更好	无法单独禁用某件专利（整个文件是一个文档，只能编辑/删除分段）
引用展示清晰：每个分段开头就是专利号

四、两种方式效果对比（核心干货）

4.1 基础指标对比

对比项	方式一：Excel 直接导入	方式二：合并 TXT 导入
操作复杂度	⭐ 最简单	⭐⭐ 需要预处理脚本 + 自定义分段配置
上传文件数	1 个（Excel）	1 个（合并 TXT）
文档数量	1 个（整个 Excel）	1 个（整个合并 TXT）
分段数量	约 100 个（可能有拆分/合并）	100 个（自定义分段，精确对应）
分段格式	Dify 自动解析，格式不可控	自定义结构化格式，完全可控
一件专利是否可能被拆分	⚠️ 可能（长摘要时）	❌ 不会（自定义分段+分隔符精确切分）
两件专利是否可能混在一个分段	⚠️ 可能（解析异常时）	❌ 不会（分隔符明确边界）

4.2 检索效果对比

对比项	方式一：Excel 直接导入	方式二：合并 TXT 导入
专利号精确查询	通常能命中，但引用来源不清晰	精准命中，分段开头就是专利号
技术主题语义检索	效果一般（字段拼接可能引入噪声）	效果更好（结构化文本+干净格式）
申请人查询	能命中	能命中
模糊查询	效果一般	效果更好
召回 Top1 准确率	约 70-80%（视数据质量）	约 85-95%（结构化提升精度）
引用展示清晰度	⭐⭐ 显示 Excel 文件名	⭐⭐⭐⭐ 分段内容开头显示专利号

以上准确率为经验估算，实际效果取决于你的数据质量、Embedding 模型选择和检索参数。建议用自己的测试集实际对比。

4.3 维护与扩展对比

对比项	方式一：Excel 直接导入	方式二：合并 TXT 导入
新增专利	需重新上传整个 Excel	需重新生成合并 TXT 并上传（脚本一键生成）
删除某件专利	无法单独删除，只能删整个 Excel 后重新上传	可在分段列表中单独删除对应分段
禁用某件专利	无法单独禁用	可在分段列表中单独禁用对应分段
修改某件专利内容	需改 Excel 后重新上传	直接编辑对应分段，保存后自动重新向量化
批量管理	不灵活	较灵活（按分段管理）

4.4 结论与推荐

场景	推荐方式	理由
快速验证 / Demo	方式一：Excel 直接导入	操作最简单，快速看效果
生产环境 / 追求检索精度	方式二：合并 TXT 导入	分段精准、格式可控、检索精度更高
数据量小（<50条）且不常更新	方式一即可	预处理的收益不明显
数据量大（>100条）且追求稳定效果	方式二	自定义分段保证质量稳定
对检索精度要求高	方式二	结构化文本提升 Embedding 质量
需要频繁增删单条专利	方式二（按分段管理）	可单独编辑/禁用/删除分段

本专栏推荐：方式二（合并 TXT 导入）。虽然多了一步预处理和自定义分段配置，但脚本可复用，配置一次后所有专利数据都能用同一套流程。生产环境下，分段精准、格式可控、检索精度更高的收益远大于预处理的成本。

两种方式都是上传 1 个文件，操作复杂度差异不大，核心差异在分段质量和检索精度。

五、知识库管理与调优

无论用哪种方式导入，知识库搭建完成后都需要做好管理和调优。

5.1 文档管理

在知识库详情页的「文档」标签页，可以：

查看文档列表：显示所有文档、字数、分段数、状态
启用/禁用文档：临时下线某件专利，不删除数据
删除文档：永久删除
重新解析：修改分段设置后重新处理
查看分段：点击文档查看具体分段内容

5.2 分段编辑

如果发现某个分段内容有问题（如格式混乱、包含无关内容），可以手动编辑：

点击文档 → 进入分段列表
找到问题分段 → 点击「编辑」
修改文本内容 → 保存（会重新向量化）

批量问题建议调整分段设置后重新解析，不要一个个手动改。

5.3 召回测试方法论

召回测试是验证知识库效果的核心手段，建议构建一个测试问题集：

测试类型	示例问题数量	验证目标
精确查询（专利号/申请人）	5-10 条	验证精确匹配能力
语义查询（技术主题）	10-20 条	验证语义检索能力
技术问题查询	5-10 条	验证解决方案检索
模糊/口语化查询	5-10 条	验证鲁棒性

判断标准：

✅ 效果好：Top1-3 包含目标专利，分段内容高度相关
⚠️ 一般：目标专利排在 Top3 之后，或分段内容部分相关
❌ 效果差：目标专利未出现在结果中，或返回完全不相关内容

效果差时的排查顺序：

检查文档是否处理完成（状态为「已完成」）
检查 Embedding 模型是否配置正确
检查分段是否合理（有无拆分/合并异常）
换检索模式试试（向量→全文→混合）
调大 Top K（默认 4，建议调到 8-10）
考虑更换 Embedding 模型

5.4 检索模式选择

Dify 支持三种检索模式，在应用层配置（不是知识库层）：

检索模式	原理	专利场景适用
向量检索	语义相似度匹配	技术主题查询、模糊查询
全文检索	关键词精确匹配	专利号、申请人、特定术语
混合检索	向量 + 全文加权融合	✅ 推荐，兼顾语义和精确匹配

专利知识库强烈推荐混合检索。因为既有语义需求（"图像识别方法"），又有精确匹配需求（"CN202113341057.A"）。

六、小结

本篇以 100 条专利数据为实战案例，完整演示了知识库搭建的全流程：

模型集成是前提 ：知识库必须配置 Embedding 模型才能向量化，本专栏全部采用本地化方案，Embedding 用 Ollama 部署的 qwen3-embedding:0.6b（MTEB 多语言榜单第 1，支持 32K 长文本），LLM 用 qwen2.5:7b，完全离线、数据不出内网
两种导入方式对比 （两种方式都只上传 1 个文件）：
- 方式一（Excel 直接导入）：操作最简单，但格式不可控、分段可能异常、检索精度一般，适合快速 Demo
- 方式二（合并 TXT + 自定义分段导入）：多一步预处理脚本，但分段精准（一件专利=一个分段）、格式可控、检索精度更高，推荐生产环境使用
预处理脚本可复用 ：Excel 转合并结构化 TXT 的脚本一次编写，所有专利数据通用；自定义分段用分隔符 --- 精确切分，确保一件专利一个分段
召回测试必做：用精确查询、语义查询、模糊查询等多类问题验证效果，效果差时按排查顺序定位问题
混合检索推荐 ：专利场景兼顾语义和精确匹配，推荐使用混合检索
本专栏聚焦 Dify 私有化部署与 RAG 知识库智能体落地，覆盖 Windows 本地与 Linux 生产环境，手把手调优私有知识库问答，解决幻觉、召回差等生产痛点。后续内容将持续更新，欢迎关注。