企业官网建设流程全解析

简介：面向企业 IT 管理者、知识管理系统负责人及具备 Python 与 AI 基础的技术人员，这份 Dify 智能知识库构建资料针对企业内部文档分散、检索难、问答不准的痛点，给出从零搭建完整知识管理闭环的落地方案。资源包共 1 个 PDF 文件，大小约 304KB，浓缩了环境配置、PDF/Word/Excel/HTML 多格式文档批量解析与向量化导入、智能问答工作流设计、知识库维护优化及企业级部署等核心内容。已有 460 人学习下载。读者可从中获得可直接套用的 Dify 客户端初始化代码、文档分类体系与检索增强配置思路，以及从元数据提取、混合检索到答案生成、质量验证的完整技术链路；结合示例实践，能有效支撑 Web、API、移动端等多种企业知识服务接入场景。

1. 企业内部文档堆成山，为什么问答系统答非所问

做过知识库项目的同行应该都有同感：企业里最不缺的就是文档，最缺的恰恰是能从文档里把答案准确捞出来的系统。技术部有操作手册，人事部有制度文件，销售部有产品彩页，财务部有报销规范——格式五花八门，PDF、Word、Excel、PPT、扫描件各占一头。很多团队第一步想到的是直接把这些文件扔给大模型去“阅读理解”，结果问“报销发票怎么贴”时，模型给出的答案是从某份三年前的制度草稿里编出来的，跟现行规定差了十万八千里。这套方案在当下企业知识管理场景里基本是走不通的。

基于Dify构建智能知识库，核心思路是把“文档处理”和“AI问答”拆成两个可独立优化的环节：前半段负责把多格式文档解析、清洗、切分、向量化，后半段负责在向量库里做检索，把命中片段连同原文上下文一起交给大模型组织答案。这个路线能解决三件事：让散落在个人电脑和共享盘里的文档变成统一可检索的知识资产，让问答结果带上出处和原文依据而不是模型凭空生成，以及让权限边界清晰的内部知识不至于被模型“自由发挥”带偏。

这篇文章适合正在选型或已经踩进自建知识库泥潭的工程师，也适合刚接到“把公司文档做成AI问答机器人”需求但不知道从哪下手的同学。文中涉及的环境变量、参数和排错手段都是我实际跑过的组合，照着配一般不会翻车，但版本差异确实存在，遇到报错时优先查日志而不是改代码。

2. Dify知识库的工作机制：先看明白再动手配置

2.1 从文档到向量：Dify内部发生了什么

Dify的知识库模块并不神秘，它本质上是一条“文档送入、向量出炉”的流水线。你上传一个PDF，系统先做文本提取，把每一页的内容拉出来；接着做清洗，去掉页眉页脚、重复空行和不可见字符；然后按预设的切分策略把长文本切成若干片段；每个片段经过Embedding模型变成向量，写入向量数据库。查询的时候，用户的问题也被Embedding成向量，系统通过相似度检索找出最相关的N个片段，连同问题一起丢给大模型生成答案。

这个流程里最容易被人忽略的是切分策略。文本切分决定了检索的粒度：片段太长，多个主题挤在同一个片段里，检索命中了但答案混杂；片段太短，上下文信息不完整，模型看不懂前因后果。我在某公司的模拟项目X里处理过一批设备操作手册，最初用固定长度512字符切分，结果“开机前检查液压油位”和“更换液压油滤芯”两个操作经常被切进同一个片段，用户问“液压油多久换一次”时，系统把开机检查步骤也带了出来，回答显得很啰嗦。

Dify内置了多种切分模式，包括固定长度切分和分隔符切分。分隔符切分适合结构化文档，比如有明确章节标题的操作手册；固定长度切分适合纯文本或排版混乱的文档。如果你拿不准，先用固定长度跑一遍，看检索结果里的片段内容是否完整，再决定要不要换成别的策略。Embedding模型的选型同样关键，后面单独展开。

2.2 Embedding模型选型：语义检索的上限由它决定

很多初学者把注意力全放在大模型上，觉得模型聪明就万事大吉，其实知识库的检索质量主要由Embedding模型决定。大模型只负责“把检索到的内容组织成通顺答案”，如果Embedding模型没把用户问题和文档片段映射到相近的向量空间，大模型再强也拿不到正确的原材料。

选Embedding模型我关注三个点：维度数、最大输入长度和语言适配性。维度数影响向量存储和计算成本，一般768维以上算够用；最大输入长度决定单次能编码多长的文本，超长文本会被截断，造成语义丢失；语言适配性则要看文档主体语言，处理中文文档建议优先考虑中文语料预训练过的模型。

在Dify的“模型供应商”页面里，你可以配置不止一家Embedding服务。我通常的配置方式是：主Embedding模型用中文效果好的那款，备用模型用通用型，两个都配上。万一主模型服务限流或报错，知识库的查询链路还能走备用模型降级，不至于整个问答服务断掉。这里有个细节：同一个知识库一旦用了某个Embedding模型建好索引，后续新增文档必须用同一个模型，否则新旧文档的向量不在同一空间里，检索结果会漂移。

提示：切换Embedding模型等于重建整个知识库索引。如果只是想在测试环境试用不同模型，建议新建一个知识库，不要直接在现有库上改配置。

2.3 企业内部部署的两个基础准备

Dify支持Docker Compose一键起服务，生产环境建议把PostgreSQL、Redis、Vector数据库和API服务分开部署，至少也要把数据目录挂载到宿主机持久化存储上。我在一开始尝试用默认配置跑了三周，某次升级容器后向量库数据全没了，因为容器重建时没有绑定数据卷，那一次丢了一个月的人工标注和文档预处理成果，血泪教训。

基础准备里常被忽略的是文档访问权限。你既然要给内部员工做问答系统，就得先想清楚谁能看到哪个知识库的内容。Dify的知识库权限模型是“应用级别”的，也就是知识库挂到哪个应用下、该应用对哪些用户可见，由应用管理来控制。如果你需要更细粒度的权限，比如“销售部只能查销售知识库但可以看公共制度库”，需要在前端做一层访问控制，Dify本身的内置权限模型覆盖不到这个粒度。

文件存储路径也需要提前规划。Dify默认把上传文档存在本地容器目录里，企业内部使用建议挂载到NAS或对象存储，一方面是容量可扩展，另一方面方便用脚本做文档的定期归档和备份。我见过某团队把知识库文档直接存在容器目录里，后来磁盘写满，Dify的健康检查开始报警，清理时才发现是历史上传的PDF占了几十GB空间。

# docker-compose.yaml 中关键数据卷配置示例 volumes: diface_data: postgres_data: redis_data: vector_store_data: services: api: volumes: - ./storage:/app/api/storage # 上传文档和缓存持久化 db: volumes: - postgres_data:/var/lib/postgresql/data redis: volumes: - redis_data:/data

这段配置的意义在于把Dify运行产生的所有关键数据都绑定到宿主机目录或命名卷上，避免容器重建导致数据丢失。storage目录存放的是用户上传的原始文档，PostgreSQL存应用配置和知识库元数据，Redis做缓存和任务队列，向量库数据单独一个卷。做容器迁移时，把这些卷整体复制过去就能恢复整个系统状态。

3. 多格式文档处理流水线：从上传到可检索的必经之路

3.1 PDF和Word的解析差异：你以为的文本可能根本不是文本

企业内部文档里PDF占比最高，但PDF恰恰是最难处理的格式。有些PDF是文字版，文本提取很顺利；有些是扫描件，本质上是一张张图片，必须OCR才能出文字；还有一种最隐蔽，文字层存在但编码混乱，常用的PDF解析库提取出来全是乱码。Word文档相对友好，Dify对docx格式支持得比较顺畅，但对老旧的doc格式兼容性较差，建议批量转成docx或PDF后再上传。

处理PDF的第一个决策点：要不要OCR。如果是扫描件或图片型PDF，必须在文档预处理阶段完成OCR，否则后续切分和向量化全部无效。Dify本身对OCR能力覆盖有限，我一般用独立的OCR服务先把扫描PDF转成带文字层的PDF或纯文本，再交给Dify处理。这么做虽然多一步，但能避免在Dify里反复试错。

# 用pdfplumber做PDF文本提取的快速检测示例 import pdfplumber def detect_pdf_text_layer(pdf_path): """检测PDF是否包含可提取的文本层""" with pdfplumber.open(pdf_path) as pdf: first_page = pdf.pages[0] text = first_page.extract_text() if text and len(text.strip()) > 20: return "text_pdf", text[:500] else: return "scanned_pdf", None result = detect_pdf_text_layer("sample_document.pdf") print(f"判定结果: {result[0]}") if result[1]: print(f"前500字: {result[1]}") else: print("该PDF无文本层，需要OCR")

这段脚本的作用是在上传前做一次PDF类型预检。我用它写了个定时扫描任务，每10分钟检查一次上传目录里的新文件，自动把扫描型PDF标记出来并送入OCR队列。逻辑很简单：第一页如果能提取到超过20个有效字符，判定为文字版PDF；否则判定为扫描件。这个阈值可以根据实际文档排版调整，有些扫描件页眉上带着页码数字，会被误判为文本层，需要多看几页再做结论。

Word文档的处理相对简单，但要注意一个坑：内嵌图片里的文字不会被提取。比如你在Word里用截图方式贴了一段系统操作界面的说明，提取出来只有图片没有文字，检索时这部分内容会丢失。Dify不会主动解析Word内嵌图片，需要把这类内容在源文档里就改写成文字，或者把截图另行整理成图片说明文档上传。

3.2 Excel和PPT的进库策略：不要让表格变成检索黑洞

Excel和PPT是知识库处理的另外一个难点。Excel表格如果整体作为一段文本切分，模型很难定位到具体行；如果按单元格拆碎，上下文又全丢了。我处理Excel文档的惯用方案是：非必要不进知识库——如果Excel的数据需要被问答覆盖，先用脚本把它转成Markdown表格或逐行带表头的文本描述，再上传。例如一个设备台账，转出来的文本格式是“设备编号：TK-001；设备名称：离心泵；安装位置：一号车间”，这种格式切割后每个片段都有完整语义。

PPT的处理逻辑跟Word类似，Dify会尝试提取每页幻灯片中的文本内容。问题在于PPT里的文字常被拆分到多个文本框里，提取顺序可能与视觉呈现顺序不一致，导致文本逻辑混乱。我在某次处理一份产品培训PPT时，提取出来的文本把标题和备注内容混在了一起，生成的问答答案前言不搭后语。解决方式是先用LibreOffice把PPT转成PDF，再走PDF流程，文本顺序会稳定很多。

# 用LibreOffice批量转换办公文档为PDF，统一入口处理 soffice --headless --convert-to pdf --outdir /data/upload/converted /data/upload/raw/*.pptx soffice --headless --convert-to pdf --outdir /data/upload/converted /data/upload/raw/*.doc

这条命令把PowerPoint和旧版Word批量转换为PDF。转换产物进入Dify时会被视为PDF处理，解析路径统一。注意LibreOffice对复杂版式的还原度不是百分之百，转换后需要抽查几页，确认文字没有错乱或丢失。我写了个对照脚本，转换后统计每页文本数量，低于阈值则认定为转换失败，触发人工检查。

3.3 ETL流程在Dify外部做还是内部做

Dify自带知识库的文档上传和预处理能力，但对批量导入、格式转换、质量检查这些前置步骤支持有限。我的经验是：把Dify当作知识库的“引擎”，把ETL放在外部管道里做，两边通过API对接。这样做的好处是，文档清洗规则可以沉淀成代码，换掉Dify也不影响预处理方案；坏处是多维护一套管道代码，导入链路变长。

外部ETL管道包括几个环节：文档接收、格式识别、文本提取、清洗、切分预检查、上传到Dify。文档接收可以监听共享目录或邮件附件；格式识别靠文件扩展名和MIME类型双重判断；文本提取用上面说的那些方法；清洗步骤去掉页眉页脚、统一换行符；切分预检查目的是防止把超大文档整体上传，导致Dify按特定策略切分后检索效果失控。

# 清洗函数示例：处理Dify上传前常见的文本噪音 import re def clean_text_for_kb(text): """清洗文档文本：去页眉页脚、压缩空行、修正错误换行""" # 移除常见页眉模式，例如 "第 X 页"、"公司内部资料" 等 text = re.sub(r'第\s*\d+\s*页', '', text) text = re.sub(r'公司内部资料[|丨].*', '', text) # 压缩多余空行为一个换行 text = re.sub(r'\n\s*\n+', '\n', text) # 修正英文单词间被错误拆行的情况 text = re.sub(r'-\n(?=[a-z])', '', text) # 清理不可见控制字符 text = re.sub(r'[\x00-\x1f\x7f]', '', text) return text.strip()

这个清洗函数能解决企业内部文档里的大量噪音。页眉页脚是所有知识库的共性敌人，公司制度文件每个页面都带着模板页眉，不洗掉会在切分时混进每个片段里，白白消耗向量库容量。还有个细节值得注意：文档里经常出现自动编号列表，比如“1.1.1 适用范围”，清洗时不能把这些编号去掉，它们是切分边界识别的关键锚点。

4. 把RAG配置调到最佳：Dify知识库问答的检索参数与提示词设计

4.1 检索参数三件套：TopK、Score阈值、rerank要不要开

Dify知识库应用在“上下文”设置里有一组检索参数：TopK、Score Threshold和Rerank开关。默认TopK是2到3，也就是取最相似的两个片段送给大模型。这个值不是越大越好——TopK过大会把不相关内容塞进上下文，模型可能捡了芝麻丢西瓜；过小又可能漏掉关键片段。我一般根据文档片段的切分大小来调：片段在200到400字之间时TopK设3比较稳妥；超过600字的长片段，TopK设2就够。

Score Threshold控制的是“多相似才算命中”。默认值往往是0.2到0.5之间，这个值很玄学，因为不同Embedding模型产出的相似度分数分布差异很大。我见过某Embedding模型对完全不相关的文本都能打出0.6以上的相似度，Threshold设0.3等于没有过滤。实际做法是：先设一个较低阈值，用测试问题跑一遍，打印出每个候选片段的相似度分数，再根据分数分布把阈值抬到“能把噪声挡在外面”的位置。

# 通过Dify API查询时返回相似度分数，用于确定Score Threshold curl -X POST 'http://your-dify-server/v1/datasets/{dataset_id}/retrieve' \ -H 'Authorization: Bearer {api_key}' \ -H 'Content-Type: application/json' \ -d '{ "query": "报销发票怎么贴", "retrieval_model": { "search_method": "semantic_search", "top_k": 5, "score_threshold": 0.1 } }'

先用低门槛跑出结果，观察分数分布。返回结果里会有类似similarity或score字段，把检索结果按分数从高到低排列，你会看到明显的“悬崖”位置——高分段和低分段之间有一个断层，Threshold就设在这个断层上方。这个方法比拍脑袋设0.5靠谱得多。

接下来是rerank。Dify支持接入rerank模型，在召回阶段先取较多候选片段，rerank模型重新排序后只保留最相关的。我强烈建议企业内部知识库开启rerank，因为它能有效解决“相似度分数高但语义不相关”的尴尬局面。比如用户问“报销流程需要几天”，语义检索可能召回“报销流程示意图”的图注文本，相似度不低但没用；rerank能重新评判相关性，把这个噪声压下去。

4.2 混检策略：关键词检索和语义检索的互补

Dify的检索模式有三种：向量检索、全文检索、混合检索。向量检索靠语义相似度，能处理同义表达，但对精确匹配不友好，比如文档里的设备编号“TK-001”写成“TK001”被查询时，向量可能匹配不到。全文检索走的是关键词倒排索引，精确匹配能力强，但查“如何申请调休”时，无法命中写了“休假申请流程”但没出现“调休”的文档。

混合检索把两种结果合并再排序，适合内部文档涵盖大量专有名词和编号的场景。开启混合检索后，Dify会对同一问题同时走两种检索路径，最终合理解析排序。我的经验是：企业内部制度类和FAQ类文档，混检效果明显优于纯语义检索；而技术手册类文档如果术语统一、表达规范，纯语义检索也够用，混检的召回量会大一些，引入的噪声需要靠Score Threshold来压。

混检模式下，Score Threshold的判断基线会漂移。因为全文检索部分可能没有分数或分数口径与语义检索不一致，统一的Threshold难以兼顾。我的做法是在混检模式下直接把Threshold设得很低或关闭，靠TopK和rerank来控制质量。简而言之：开启混检时，Threshold退居二线，TopK和rerank唱主角。

4.3 提示词里必须交代的三件事：格式、出处、拒答

Dify应用编排里的提示词是最后一次“兜底”机会。系统提示词写得好不好，直接决定答案的可用度。我一般要求提示词里明确三件事。第一，答案必须基于提供的上下文，上下文不足时只能回答说“根据现有资料无法回答”，禁止编造；第二，口语化提问要转成文档语境来答，比如“这玩意儿坏了找谁”要能对应到文档里的“故障报修流程”；第三，必须标注出处，标注到文档标题或章节名级别，方便提问者核实原文。

# Dify应用提示词模板（节选） SYSTEM_PROMPT = """你是企业内部知识库问答助手。请严格按照以下规则回答： 1. 只基于提供的文档上下文回答，不得使用自身知识补充技术细节。 2. 如果上下文不足以回答问题，明确回复“根据现有知识库资料无法回答”。 3. 回答末尾标注参考来源：[文档名称/章节名称]。 4. 使用简洁的书面语，避免口语化表达。 5. 问题涉及流程、规范时，先给出结论，再提供步骤细节。"""

这段提示词模板我用在多数内部知识库应用里。第2条是防止大模型幻觉的关键，第3条便于用户追溯原文，第5条是针对操作类问题的格式优化。实际效果里最明显的是第3条——加了出处之后，用户对答案的信任度提升很明显，从前“AI又在瞎说”的反馈少了很多。

提示词里还有一类容易忽视的内容：多轮对话的记忆管理。Dify默认会携带对话历史进入上下文，但历史过长会导致大模型分不清“当轮问题”和“历史问题”。我通常在提示词里加一句“仅回答用户最新的问题，历史消息仅作参考”，再配合Dify的会话消息清理策略，把存储的历史轮数控制在4到6轮。

4.4 知识库分段策略与查询改写：两个常被忽视的精度杠杆

文档切分粒度直接影响检索精度。Dify可选的“父子分段”模式值得尝试：父分段保留完整的章节内容，子分段切得更细用于精确匹配，检索时用子分段命中、父分段作为上下文送进大模型。这套机制对长章节文档很有效，避免细粒度命中但上下文不完整的问题。我处理过一份仪器操作规范，整章有2000多字，按子分段命中“校准温度范围”时，大模型拿到的上下文包含完整校准流程，回答细节就到位了。

查询改写是另一层优化。用户提问常常带口语、指代和上下文省略，比如在连续对话里问“那审批要几天”，单独看这句话没有主语。Dify的检索阶段不会自动理解指代。某个模拟项目中我在Dify前面加了一个查询改写服务：先用轻量模型把用户问题改写成独立完整的检索语句，再拿去查向量库。这样“那审批要几天”会被改写成“报销审批需要几个工作日完成”，检索召回率提升显而易见。

5. Dify知识库落地避坑：权限失效、解析翻车和召回漂移的排查记录

5.1 上传PDF后问答完全答不出来：只查了向量化状态没查文本提取质量

现象是某份30页的产品说明书，上传成功、切分显示正常、向量化完成，但用户问“产品保修期多久”时，系统总是回答“根据现有知识库资料无法回答”。我第一反应是向量化没成功，结果后台查询显示文档状态一切正常。

进一步排查发现，这份PDF在文本提取阶段就出了问题：Dify内置提取器对双层PDF（文字层+背景图片）的处理结果是每页只提取到少量碎片文字，切分后每个片段只有十几个字，语义信息不足以命中任何查询。解决方法是把这份PDF导出成纯文本后重新上传，并加上文本长度预检——凡是提取后平均每页少于50字的文档，一律标记并转走OCR流程。

5.2 同一个知识库换了Embedding模型后检索结果全面漂移

某次测试时，我把知识库的Embedding模型从A款切到B款，只改了配置没有重建索引。结果用户问的问题还能被检索到，但排序完全不对劲，N个候选片段里正确答案排到很后面，答出来的内容前言不搭后语。

原因是旧文档的向量由A模型生成，新查询的向量由B模型生成，两者分布不在同一空间，相似度分数失去可比性。后来我把知识库的Embedding模型作为不可变配置，切换模型前先导出全量文档，建新库重新导入。Dify的文档列表页面支持批量删除，配合API可以做全量重建，只是耗时较长，我把这个过程做成了夜间定时任务，白天跑增量更新，晚上跑一致性校验。

5.3 Rerank服务挂了导致整个知识库问答超时

某次知识库应用从下午开始响应时间从2秒涨到20秒，用户反馈系统“卡死了”。排查发现向量检索本身很快，但Rerank服务所在节点负载飙升，请求排队严重。Dify的Rerank是在检索完成后串行执行的，Rerank服务一旦延迟，整个问答链路的响应时间被拉长。

我把Rerank改成可降级架构：添加一个超时熔断，Rerank超过500毫秒未返回则自动跳过Rerank步骤，直接用语义检索结果。牺牲了一部分精度但保住了可用性，内部系统稳定性优先。同时也给Rerank服务加了单独的监控指标和告警阈值。

5.4 权限控制形同虚设：同一个应用下所有人都能查到全部知识库

项目X里运营团队和技术团队共用一个应用入口，但知识库权限应该隔离。测试发现技术团队账号在对话里能问到运营文档内容，底层的知识库“权限组”配置没有覆盖到应用会话级。Dify的知识库权限如果按“谁能访问这个应用”来控制，那么共用一个应用的所有人天然拥有该应用挂载的全部知识库权限。

解决方式调整为：按部门拆分Dify应用，每个部门各自挂自己知识库；涉及公共制度的文档单独建“公共知识库”，每个部门应用都挂载它。这一步改动的成本比想象中小，因为Dify应用本身可以复制，知识库的连接关系也可以批量配置。

5.5 文档更新后回答的还是旧内容：索引刷新时机没想清楚

一份制度文件在2024年7月修订后重新上传到知识库，但5分钟后用户提问，答案引用的还是旧条款。查看后台时发现新上传的文档还停留在“等待处理”状态，没有进入向量化队列。原因是该文档与旧文档文件名相同，Dify在系统里创建了一个新文档版本，但旧的向量索引没有被自动废除，检索时两类片段同时命中，旧片段排在前面导致答案过时。

收拾方法是：更新文档时先删除知识库里同名旧文档，再导入新文档。我通过Dify API封装了一个“文档替换”脚本，输入路径自动完成“删除旧文件-上传新文件-确认切分-确认向量化”四个步骤，更新文档不再依赖人工操作界面。

6. 用召回率评测驱动知识库迭代：建立你自己的验证集

知识库做得再多，没有一套评测手段就等于盲人摸象。我推荐每个知识库项目从第一天起就维护一个评测问题集，规模不用大，50到100条就够，但必须覆盖典型场景。问题集的构建方式是：从真实用户会话记录里抽取高频提问，针对每个问题标注标准答案文本和期望命中的文档或章节。建立评测集后，每次调整切分参数、换Embedding模型、改提示词，都跑一遍完整评测，对比召回率和答案得分。

评测解析很简单，写一个脚本循环调用Dify的检索API，记录命中片段、相似度分数和最终答案，再与标注结果比对。“命中期望文档”视为召回成功，“最终答案包含标准答案要点”视为回答正确。我有一次调整切分长度从500改到300，召回率从71%涨到82%，但回答完整率有所下降，因为片段变短导致上下文信息减少了。这类权衡如果不靠评测数据，光凭感觉是不可能发现的。

# 评测脚本核心逻辑示意 import json, requests eval_questions = json.load(open("eval_set.json")) for item in eval_questions: resp = requests.post( "http://your-dify-server/v1/apps/{app_id}/chat-messages", headers={"Authorization": "Bearer {api_key}"}, json={"query": item["question"], "response_mode": "blocking"} ) answer = resp.json().get("answer", "") # 判断期望文档是否被召回 hit = any(doc in answer for doc in item["expected_docs"]) # 判断答案是否包含标准要点 score = sum(1 for point in item["key_points"] if point in answer) / len(item["key_points"]) print(f"问题: {item['question']}") print(f"召回期望文档: {'是' if hit else '否'} | 回答得分: {score:.0%}")

这套评测的价值不止于调参。每次往知识库里加新文档时，跑一遍评测能立刻看出新文档是否干扰了旧问题的检索排序；某个类型的问题频繁丢分，说明切分策略对这个文档类型不适用，需要单独建子知识库并设置独立的检索参数。我后来把这个评测脚本接入了定时任务，每周跑一次，自动生成质量趋势报告，知识库的迭代从“感觉还行”变成了“有数可依”。

在企业内部落地对话式知识库，真正的难点不在于技术栈搭建，而在于持续维护。文档在更新，用户在提问，检索质量在下滑，这是常态。Dify把搭建的门槛压低了，但把评测、清洗和迭代做好仍然是工程师的必修功课。我的习惯是每个知识库项目都给自己留一套评测集和一份参数变更记录，这样无论过了多久，回来看一眼运行数据就能判断系统的健康状态，而不是打开后台凭感觉乱调参数。希望这些经验能帮你在企业知识管理这条路上走得顺一点。

本文还有配套的精品资源，点击获取