企业官网建设流程全解析

1. 从"电子墓地"到"可对话大脑"：这个项目想解决什么问题

先说一个我观察到的普遍现象：绝大多数人的 Wiki 知识库，最后都变成了"电子墓地"。

搭建的时候雄心壮志，目录分好了、模板建好了、双链也打了，坚持写了两周，之后就是偶尔往里面扔几篇文章。等到真需要找某个资料的时候，要么用目录一层一层翻，翻到第三层就放弃；要么用搜索框一搜，出来一堆不相关的页面，或者干脆搜不到——因为你当时写的时候用的措辞，和现在想的时候用的措辞，根本不是同一个词。

我自己就是这个状态的深度用户。Obsidian 里攒了快两千个 Markdown 文件，有技术笔记、工作复盘、读书摘录、会议记录，散落在二十多个文件夹里。说实话，这些内容单拎出来每一篇质量都不差，但它们之间是割裂的。我明明写过某个问题的解决方案，三个月后遇到同样的问题，我还是会重新查一遍资料重新解决，因为"搜不到"等于"不存在"。

这就是llm_wiki这个项目最初的出发点：能不能用大模型 LLM，把一个静态的 Wiki 仓库，变成一个能直接对话的动态知识大脑？

不是简单地做那种"ChatGPT 套壳 + 向量数据库"的玩具 Demo，而是真正把 Wiki 的组织方式、Markdown 的内容结构、检索增强生成（RAG）的技术链路、模型调用的参数策略全部打通，让知识库从一个"存储系统"升级成一个"回答系统"。

这篇文章我会完整复盘这个项目的搭建设计思路，覆盖数据组织规范、RAG 检索链路的实现细节、Dify 平台里的 LLM 参数设置、以及我实测过程中踩过的几个关键坑。不管你是想搭个人 Wiki 的知识库问答，还是想在团队内部做文档智能检索，这篇文章的思路和代码配置都可以直接参考。

2. 架构设计与技术选型：为什么是 Obsidian + Dify + RAG 这条路线

2.1 整体架构：四层结构各司其职

我最终落地的架构分成四层，每一层解决一个独立的问题：

这个选型组合我在正式写代码前对比了好几轮。最初考虑过纯代码方案，也就是自己写 Python 脚本调用 LangChain 或者 LlamaIndex，把 Obsidian 的 Markdown 文件解析、切分、向量化，然后用 FastAPI 暴露一个问答接口。这套方案的好处是灵活，但坏处是维护成本高，而且知识库更新后，索引和问答逻辑都要管，一个人忙不过来。

后来折中了一下：中间态用 Dify，两端自己控制。内容层用 Obsidian 保证写作体验，模型层自己管理 API Key 和模型切换策略，中间的解析、切分、向量化、检索、重排、上下文组装这些脏活累活，全部交给 Dify 的工作流来处理。这样即使我不在家，想往 Wiki 里加一篇新文章，也只需要把 Markdown 同步到指定文件夹，Dify 会自动更新索引，不用我手动跑脚本。

2.2 为什么坚决不微调，而是走 RAG 路线

很多人一听说"要用 LLM 做知识库"，第一反应就是"那我微调一个模型吧"。这个思路我不能说错，但在我这个场景下，它是一个典型的过度设计。

微调的本质，是修改模型的权重，让模型"记住"某种固定格式或者某种特定的行为习惯。它适合的场景是：你想让模型学会某种稳定的输出风格，比如"把技术交底书改写成周报语气"，或者"从病历中抽取结构化字段"，这些任务的规则相对固定，训练数据量几百到几千条就够了。

但 Wiki 知识库的场景完全相反。Wiki 的内容是高频更新的动态数据，今天你刚把一篇文章放进去，明天可能就过时了；微调一次模型的时间成本和金钱成本，足够你写好几十篇文章。更麻烦的是，微调之后模型回答问题时是"凭记忆"在输出，它会一本正经地胡说八道，把三个月前的内容和现在的知识搅在一起，还不会告诉你它说的依据是什么。

RAG（检索增强生成）的思路就很直接：你问问题的时候，我先去向量数据库里检索相关的文档片段，把候选片段连同问题一起拼进 Prompt，让模型只根据这些材料作答。这样模型的输出严格受限于你喂给它的资料，知识库里没有的内容它不会瞎编，知识库更新了它下次检索到的就是新内容。用一句话概括：微调是让模型"记住"，RAG 是让模型"查得到"。知识库这种以"准确、可溯源"为首要目标的场景，RAG 是更稳妥的路线。

2.3 模型选型的实际权衡：API 模型和本地小模型双轨跑

模型层，我的策略是"双轨制"：日常问答走云端 API 大模型，隐私数据或者离线环境走本地部署的小模型。

云端 API 我主要用的是综合能力强的商用模型，比如 GPT 系列、Claude 系列，以及性价比高的国产模型。选择依据很简单：需要阅读理解复杂表格、代码片段和长文档时，模型上下文窗口要大，推理能力要强；知识库问答对创造性的要求不高，但对"忠实于原文"的要求很高，所以我不追求那种花哨的文风，追求的是稳定和忠实。

本地小模型我备了一个 Qwen 系列的中等尺寸模型和一个轻量级的国产 Embedding 模型，专门处理离线环境下的索引和检索。实测下来，本地 7B~14B 级别的模型，在"根据给定文档内容回答中文问题"这种直白的任务上，效果完全够用；只有遇到那种需要综合多篇文档信息才能回答的复杂问题时，云端大模型的优势才会明显体现出来。

这里有个细节经验：同一个知识库，如果模型换了，回答质量会有肉眼可见的差异。不是越贵的模型越好，而是不同模型的"指令遵循能力"差别很大。有的模型你让它"只根据材料回答"它偏要捎带自己的知识，有的模型则会很规矩地跟着指令走。所以实际项目中，我建议在 Dify 里把提示词和模型绑定之后，用同一组测试问题跑一遍不同模型的输出，再决定用哪个，不要凭感觉选。

3. Wiki 知识库的数据组织：检索效果好坏，从这里就决定了

3.1 目录结构和文件命名规范

RAG 链路里有个反直觉的事实：决定检索质量的最大因素，不是模型选得多好，而是原始文档的组织质量。

如果你 Wiki 里的文章是随手写、随手存，章节标题随意，关键词混乱，那再强的 Embedding 模型也救不回来。我重新整理了整个 Obsidian 库的目录结构，原则只有一条：按主题领域划分顶层目录，每个目录内部保持语义内聚。

wiki/ ├── 01-work/ # 工作相关：项目记录、会议纪要、技术方案 ├── 02-coding/ # 编程技术：语言笔记、框架踩坑、代码片段 ├── 03-reading/ # 读书笔记与资料摘录 ├── 04-life/ # 生活记录、设备管理、攻略 ├── 05-meta/ # 关于知识库本身的知识：使用规范、模板 ├── 99-inbox/ # 临时收集，定期归档 └── attachments/ # 图片等附件统一存放

文件命名规范也做了硬性要求：YYYY-MM-DD-主题slug.md。比如2026-01-18-dify-llm-settings.md。这个格式的好处是，即使脱离目录直接在全局搜索里看结果，也能从文件名获取时间信息和主题信息，避免出现那种"新建文档 15.md"的灾难现场。

3.2 Frontmatter 元数据：给检索系统装上"路标"

聊到 Wiki 数据组织，绝对不能跳过 YAML Frontmatter。它是 Markdown 文件开头的结构化元数据区，用三根短横线包起来。很多人觉得这玩意儿是 Obsidian 插件才需要的，跟 RAG 没关系，大错特错——对检索系统来说，结构化元数据相当于给向量索引额外加了一层"路标"。

我在每一篇 Wiki 文件里都强制维护这样一组 Frontmatter 字段：

--- title: "Dify 中 LLM 模型的配置参数详解" aliases: ["Dify设置", "LLM参数配置"] tags: [AI, LLM, RAG, Dify] topic: 知识库技术 status: done created: 2026-01-18 updated: 2026-01-20 summary: 总结了 Dify 工作流中知识库问答的模型选择、温度参数和提示词设计 source: 自实践总结 ---

这些字段对后续检索的价值非常大。举个例子，tags字段在纯文本检索时代作用有限，但在语义检索时代，它可以作为元数据过滤条件——用户问"Dify 怎么配置模型"，可以先通过标签过滤掉完全无关领域的文档，再做向量相似度计算，检索精度能提高不少。summary字段更是直接可以当作 Embedding 的候补文本，如果原文太长，用摘要向量做粗筛，再回到全文做精排，效果很稳。

3.3 Obsidian 环境设置与写作习惯的调整

既然内容层选型是 Obsidian，它的环境配置直接影响后续的数据管道处理。

我维护了一份全库统一的模板，所有新建笔记都通过 Templater 插件生成，保证 Frontmatter 字段一致性。同时开启 Obsidian 的"严格换行"和"每行一句"习惯——这个看起来很小的习惯，对后面的文本切分非常关键。因为 RAG 管道在切分 Markdown 时，最怕的就是那种整篇文章只有一个大段的文件，切分器会把语义相关的句子和无关内容强行拼在一个块里，检索出来全是噪音。

链接图谱我保留，但明确区分了两种链接的用途：概念型双链（指同一篇笔记在不同语境下反复被引用）和导航型链接（纯粹是目录式的跳转）。只有前者才会影响知识之间的语义关联，后者则尽量收敛，避免给检索系统制造"看起来相关但实际上没内容"的假象。

提示：如果你用的是 Obsidian 自带的同步或者 iCloud 同步，要注意给.obsidian配置目录设置好忽略规则，避免把插件配置也同步到知识库处理管道里，否则解析 Markdown 时会有大量无效文件干扰索引构建。

4. 从 Markdown 到可检索的向量库：RAG 链路的核心实现细节

4.1 文档解析与切分策略：为什么"一切了之"必翻车

知识库里的文档要进入检索链路，第一步是解析和切分。这个环节我踩过最大的坑就是盲目按固定字符数切分。

早期版本我用的是固定字符切分：每 1000 个字符切一块，块与块之间重叠 200 字符。看起来没什么问题，但实际跑起来发现召回结果里经常出现"半截话"——一个完整的技术结论被拦腰斩断，上一块最后一句是"所以解决方案是"，下一块开头是"调整超参数为 learning_rate=1e-4"，检索时这两块经常只召回其中一块，模型拿到的上下文不完整，回答起来自然就东拼西凑。

后来我把切分策略改成了按 Markdown 结构切分 + Parent-Child 块结构。具体做法是：

1. 先用解析器识别 Markdown 的标题层级，按##和###为边界切分正文，保证一个语义块不被截断。
2. 表格单独处理，不跟着上下文一起切。Markdown 表格一旦被拦腰切开，向量化之后语义几乎完全丢失，所以我把整个表格作为一个独立的块处理。
3. 代码块优先保持完整，尤其是那种几十行的配置示例。
4. 建立 Parent-Child 映射：每个大章节是 Parent 块，章节内提取出的关键段落是 Child 块。检索时在 Child 层做匹配，召回后把对应的 Parent 块内容一起送进 Prompt。这样既保证检索命中率高，又保证模型能看到完整的上下文。

切分的参数上，我实际使用的策略是 chunk_size=800~1200 token（视文档类型浮动），重叠系数 10%~15%。为什么不是 0？因为有些句子跨越切分边界时，语义就会被截断；少量重叠能保证边界处的语义连续性。为什么不是 30% 以上？因为重叠过高会导致向量库体积膨胀，检索时的重复内容还会干扰重排效果，性价比很低。

4.2 Embedding 模型的选择与向量库配置

Embedding 是把文本转成向量的模型，它决定了"语义相近"这个判断的基准。我在这个项目里先后试过好几款模型，最后长期保留的是两个：

• 中文场景主用bge-m3系列，它对中文长文本的处理能力很强，而且支持 8192 token 的输入长度，对技术文档这种长段落场景特别友好。它输出的向量维度是 1024 维。
• 跨语言和英文场景用 OpenAI 的text-embedding-3-small，维度 1536。

如果你用 Dify 自带的向量化配置，需要注意：知识库创建时选了哪个 Embedding 模型，这个索引就和它的维度绑定死了。中途换模型，必须重建知识库索引，否则相似度计算会因为维度不匹配直接报错。这个细节我后面踩坑部分会详细说。

向量数据库我选的是 Dify 内置的 Weaviate 作为主力。选它的原因很简单：Dify 社区版默认集成的方案里，Weaviate 对中等规模（几万条向量）的应用场景稳定性很好，Docker Compose 一键拉起，资源占用也还在可接受范围内。如果你的 Wiki 文本量特别大，比如超过 50 万个块，那可以考虑换 Qdrant 或者 Milvus，但那种规模对个人项目来说属于少数情况。

4.3 Dify 里的 LLM 设置：我在实际项目中填写的参数

热词列表里有"dify里的llm怎么设置"，说明很多人折腾 Dify 时都在这一步卡住过。Dify 的知识库问答应用里，LLM 设置分散在两个地方：一个是"编排"页面的模型参数，另一个是知识库检索配置。我实际使用的设置如下：

模型参数部分：

很多人问为什么 temperature 和 top_p 要同时调低。这两个参数虽然都控制随机性，但作用位置不同。temperature改变的是概率分布的"平滑程度"，top_p控制的是采样时只考虑概率最高的前多少比例的 token。只调 temperature 不调 top_p，模型的输出可能还是会飘；两者一起调低，输出的确定性才足够高。我自己测试的时候，temperature 从 0.7 降到 0.2，回答内容中"编造细节"的情况明显减少，几乎全部回答都能在原文里找到对应依据。

知识库检索部分：

• 召回模式选择混合检索：向量检索负责语义匹配，全文检索负责关键词精确匹配，两者结果做融合排序。纯向量检索有一个盲区：当用户的问题包含精确术语（比如报错代码、函数名）时，关键词匹配往往比语义匹配更准。
• 召回数量设为 4~6 个块。这个值很关键：太少，关键信息可能漏掉；太多，无关内容会稀释模型的注意力，而且把大量上下文塞进 Prompt 会让响应变慢、费用变高。
• Rerank 重排必须开启。首轮检索返回的结果按向量相似度排序，但向量相似度不等于真实相关性；重排模型会综合查询和文档的深层语义关系重新排序，把最相关的内容顶到前面。我用的是 Dify 内置的重排模型，效果提升非常明显。

提示词部分：

Dify 默认给知识库问答写好的提示词，我不会直接用，而是改成了这样：

你是我的知识库助手。严格根据【上下文】中的资料回答问题。 要求： 1. 如果资料中有明确答案，请基于资料直接回答，并在回答末尾按编号列出引用来源。 2. 如果资料中没有明确答案，直接说明"知识库中未找到相关内容"，禁止自行编造。 3. 不要复述问题，直接给出结论。 4. 回答语言与提问语言保持一致。 上下文： {{context}} 问题： {{query}}

这个提示词看起来简单，但每一句都有目的。第 2 条"禁止编造"是知识库问答的红线，不加这句话模型很容易会用自己的知识去补全答案；第 4 条"回答语言与提问语言保持一致"是个很实际的细节，不加的话英文模型有时会用英文回答中文问题，体验很割裂。

5. 实测踩坑记录：这些坑不踩一遍真的不知道

5.1 文档切分不当导致召回失败的完整排查链路

这个坑是项目上线初期遇到的最头疼的问题，值得单独说一下完整的排查链路。

现象是这样的：我问知识库"服务启动失败时应该检查哪些配置项"，结果返回的回答驴唇不对马嘴，引用的内容全是无关的杂讯。查看 Dify 的检索日志后发现，召回的内容里确实有包含"启动失败"关键词的块，但那个块是从一篇长文中间截出来的，只包含问题描述，不包含解决方案部分，真正的答案在后面的另一个块里，没被召回。

排查过程是这样的：我先确认了索引数据是最新的（排除了同步问题），然后在 Dify 里手动触发检索，查看召回结果，发现召回的块确实只有问题没有答案。接着检查切分逻辑，发现问题出在"块与块之间的内容被硬切开了"。我当时的切分参数是 1000 字符硬切，解决方案写在"排查步骤第 3 步"，而第 3 步恰好跨到了下一个块里，单独看上一块的结尾没有任何信息量。

修复方案我上面已经讲了，就是改成按 Markdown 结构切分 + Parent-Child 映射。这里再补充一个验证技巧：修完之后，我会拿 20 个典型问答对做回归测试，专门验证每个问答对的答案内容是否在 Top-5 召回结果里。如果答案内容不在，就说明切分策略或者检索参数还有问题。这个测试集我一直维护着，每次改动知识库处理流程都会跑一遍。

5.2 Embedding 维度不一致：换模型不重建索引的惨痛教训

有一次我为了对比新出的一个 Embedding 模型的效果，直接在 Dify 知识库设置里换了模型，然后兴高采烈地跑去测试问答。结果一问问题，直接报错，提示向量维度不匹配。我愣了半天才反应过来：之前创建的知识库索引，向量的维度是旧模型的 768 维，换了新模型之后输出成了 1024 维，数据库里存在两批不同维度的向量，相似度计算当然没法做。

这个问题的本质是：向量索引一旦创建，背后的维度结构就和当时的 Embedding 模型锁死了。它不是简单的"换个模型继续跑"的事，而是需要删除整个知识库、重新导入文档、重新做 Embedding、重新构建索引。

Dify 里切换模型后，虽然没有强制提示必须重建索引，但 UI 上如果你仔细看，会有一个"请重建知识库索引"的提示文案。我第一次用的时候真没注意这个细节，就这么硬踩过去了。现在我的习惯是：任何 Embedding 模型的切换，一律先建一个测试知识库，导入 5~10 篇典型文档，跑通之后再切到正式知识库上。

5.3 上下文塞满与引用溯源：回答"有货"但"不可信"的问题

刚开始跑通全链路时，我遇到了另一个体验上的问题：回答的内容确实是对了，但用户（我自己）不知道怎么验证它。因为 Dify 默认设置下，回答下方没有展示引用的具体文档片段，我只看到一段生成出来的话，不知道它是从哪篇文档里来的。这对于知识库问答场景来说很危险——模型的输出再准，也要能溯源才能让人信任。

解决方案是把知识库检索结果里的"引用归属"信息通过 Dify 的变量节点传给前端展示。Dify 的知识库检索节点会返回每个块的 metadata，包括文件名、章节标题、原文内容等，把这些信息组装成引用列表输出，用户点一下就能看到"这段话出自哪篇笔记的哪个章节"。这个改动看起来不大，但使用体验完全是两个量级。

与之相关的一个参数取舍是召回数量。理论上召回数量越多，模型越有可能看到完整信息，但实际测试下来，召回 10 个块和召回 5 个块的回答准确率几乎没有区别，反而因为上下文里混入了太多低相关度的块，模型偶尔会被带偏。而且 Prompt 变长之后，接口延迟明显增加。所以我最终把召回数量定在 5 个块、Rerank 之后再取 Top 3~4 个块进入 Prompt。这个数值不是绝对的，但值得作为你调参的起点。

6. 后续扩展方向：从"能问"到"能干活"

6.1 接入 Agent：Wiki 从"回答问题"升级为"执行任务"

知识库问答上线稳定之后，我开始琢磨一个更进阶的方向——让 Wiki 从"能回答"变成"能干活"。

具体来说，现在知识库里沉淀了大量 SOP 文档、配置手册和排障流程，但这些内容目前只能被动地被检索出来回答用户问题。如果接入 LLM Agent 的能力，就可以让模型基于 Wiki 中的内容去主动执行任务。比如从部署文档中抽取关键步骤，自动生成一份操作工单；或者根据排障手册里的判定逻辑，自动判断错误日志属于哪类故障，并给出对应的修复命令。

这个方向对应的就是热词里多次出现的 "LLM Agent" 和 "LLM powered autonomous agents"。我的规划是：把知识库作为 Agent 的工具层，通过函数调用的方式暴露检索接口，让 Agent 在规划阶段自主决定"什么时候需要查 Wiki、查哪部分内容"。和纯粹的知识库问答相比，多了一层任务拆解和行动能力，但也多了一重风险控制的要求——Agent 自主执行的动作必须有清晰的边界，不能让它拿着 Wiki 里的内容就去改生产配置。现阶段我建议以"生成建议方案 + 人工确认执行"的半自动模式为主，等跑熟了再考虑全自动。

6.2 垂直领域数据和 QA 语料的准备方法

说到垂域 LLM 落地，"垂域 LLM 数据准备"是所有人绕不开的话题。我现在的 Wiki 里积累的 2000 多篇技术笔记，本身就是一份质量不错的垂域语料，但直接用于微调还远远不够。我准备给它加一层"提质"处理：

• 用大模型批量从 Wiki 文档中生成问答对（用我自己维护的脚本配合模型批量完成），生成后再人工抽检，过滤掉生成质量差的部分。
• 针对高频场景，把 Wiki 里的零散记录整理成结构化的"标准操作手册"，保证每篇文档有完整的背景、操作、验证三个环节。
• 定期给 Wiki 做死链检测和过期内容标注，避免旧文档污染模型输出。

这些整理好的 QA 语料，既可以用来评测当前 RAG 链路的效果，也可以作为未来微调的数据储备。我的建议是：不要在项目一开始就奔着微调去准备数据，而是让知识库先跑起来，积累 3~6 个月真实问答记录，再做数据清洗和标注，这样生成的数据更贴近真实使用场景，质量比凭空想象出来的更好。

6.3 LLM 学习路线的映射：把 Wiki 变成一套完整的成长系统

最后说一个偏个人向、但我觉得非常有价值的扩展：把llm_wiki本身做成一套 LLM 学习路线。

互联网上关于大语言模型的资料非常杂，公众号文章、付费课程、开源教程、论文解读，散落在各个平台。我的想法是，在 Wiki 里专门开一个子库，按照"基础原理 → 关键技术 → 工程实践 → 前沿方向"的脉络整理学习材料，每篇材料都写清楚：这篇讲的是什么、适合什么阶段的人读、和知识库中哪些其他文章存在关联。

这样 Wiki 不但能回答"Dify 里的 LLM 怎么设置"这种具体问题，还能回答"我该按什么顺序学习 RAG""Transformer 的注意力机制怎么理解"这类学习路径问题。甚至可以通过 Agent 根据用户的当前基础，动态生成个性化学习计划。这算是把静态的知识管理，和动态的学习引导结合起来了，也是我觉得llm_wiki这个项目最有意思的长期价值。

回到最开始那个问题——知识库怎么避免变成"电子墓地"？我的答案很简单：给知识库装上"对话接口"，让它在里面有东西可讲的基础上，变成随时能应答的助手。搭建llm_wiki的过程中，我自己对 RAG 的理解、对数据组织重要性的体会，都比之前只看文档时深了好几倍。如果你也有一堆尘封的笔记和文档，不妨按这个思路试一把，先拿 50 篇文档搭个最小闭环跑通，再慢慢往里加内容。你会发现，"搜不到"这个困扰你很久的问题，其实换一种方式提问就解决了。