企业官网建设流程全解析

如果你手里有一堆文档、笔记、碎片信息，又恰好听过大模型（LLM）这个词，那“llm_wiki”这个组合很可能已经在你的收藏夹里出现过。它不是什么高深产品，而是把大语言模型和Wiki知识库绑在一起的一种玩法：用LLM帮你读文档、找关联、答问题，用Wiki帮你沉淀和管理这些内容。我自己的笔记体系就是从这个组合开始的，从Obsidian插件到自建RAG管道都折腾过一遍，这篇就把完整思路、工具对比、实操步骤和踩坑记录都摊开讲清楚。

1. 为什么非要把LLM和Wiki放在一起

1.1 传统Wiki解决不了的两个问题

Wiki类知识库最核心的价值是“链接”和“结构”。你写一篇文章，顺手把相关概念、来源、案例用双链串起来，时间久了会形成一张巨大的知识网络。这个模式在个人笔记、团队文档里都验证过，稳定性极高。

但它有两个绕不开的短板。

第一个是入口太笨重。你知道库里可能有某个知识点，但关键词想不起来，或者这个概念在文章里被用了个口语化表达，传统搜索只能靠字面匹配，搜不到就是搜不到。我自己的笔记本里有大量截图、网页摘录和随手心得，很多内容我当时记下来时没想好标签，三个月后再去找，基本靠缘分。

第二个是沉淀靠人力。一个健康的Wiki需要有人定期整理、补链接、写摘要、做MOC（内容地图）。这个工作量长期压在个人身上，很快就会放弃。大多数人写了几十篇笔记之后就进入“只存不看”状态，知识库成了数字垃圾桶。

1.2 LLM补上的是“语义”和“生成”这两层能力

LLM（大语言模型）解决的恰恰是这两件事。它可以做语义检索：你问“本地数据库性能优化”，它能匹配到一篇标题叫“SQLite调优踩坑记录”的笔记，因为语义相似。它也能做内容生成：给几篇相关笔记，让它总结一份要点、写一段综述、甚至生成一份问答条目，都能输出质量不错的结果。

这个组合的逻辑其实不复杂：

• Wiki负责存储结构：文章、标签、双链、目录关系。
• LLM负责理解连接：把非结构化查询映射到结构化内容，再把内容总结成人能直接使用的答案。

两者叠加，一个静态的“知识仓库”就变成了一个能对话、能自动整理、能主动关联的“知识办公桌”。

1.3 我的个人场景：为什么需要llm_wiki

我平时的信息来源很杂：技术文档、论文摘要、图书划线、视频笔记、会议录音转文字。这些内容最大的特点就是“有关系但分散”。以前我用了一个多月的常规双链维护，依然觉得自己在“为整理而整理”。后来试了LLM辅助，才真正缓解了这个问题。

具体做法是：所有原始内容先丢进库，让LLM做两件事——提取核心概念，找到相关已有条目，如果发现有强关联但没建链的地方，它会建议我补一个链接。这个动作把“维护成本最高的一环”变成了半自动。配合问答式查询，旧笔记被重新翻出来利用的频率明显提高了。

我身边做研究、写方案、管团队的人，也都在用类似思路管理自己的信息资产。所以“llm_wiki”不是某个具体软件，而是一套方法论，具体工具可以随你的技术条件换。

2. 工具选型解析：从轻量插件到自建RAG

2.1 四种主流方案的横向对比

聊方案之前先说结论：没有“最好”，只有“合不合适”。你的技术背景、隐私要求、预算和内容规模，直接决定了该走哪条路。

我把目前社区里比较常用的方案分成四类，各有各的适用场景。

我自己是先从方案一入门的，后来内容涨到几千篇，插件方案的响应和精度跟不上了，才切到方案四。如果你现在就几十篇文档，完全没有必要上来就搞服务集群，用插件最快。

2.2 为什么我不推荐一上来就自建RAG

自建RAG（检索增强生成）这个方向，社区里讨论度非常高，尤其是LangChain、LlamaIndex出现之后，似乎人人都在搭自己的知识库问答机器人。但这里有个很大的误区：RAG的核心难点不在于代码，而在于数据质量、分块策略、Embedding模型和评测闭环。

很多新手上来就用默认配置把PDF全文塞进去，结果问什么问题都答非所问。原因通常不在LLM，而在切分太粗暴——比如把一个表格从中间切断，把代码和注释拆开，或者把两篇主题不同的文章塞进一个块。这些问题需要你反复调试才能解决，而调试又需要你理解整个管道里每个环节的实际作用。

所以我的建议是：先用现成工具跑通流程，感受到底哪些环节对结果影响大，再考虑自己写管道。插件方案就是很好的学习工具，它把分块、向量化、检索、生成的各个环节封装好了，你只需要换模型、调参数，就能直观看到变化。

2.3 模型端和推理端：你需要知道的基本分工

“llm_wiki”领域里经常看到“模型端”和“推理端”的说法。这两个词本质上描述了LLM服务的两个部分：

• 模型端：指训练好的大模型本体，比如开源社区的Llama、Qwen、ChatGLM系列，或者闭源的GPT-4o、Claude等。它们决定了理解能力、生成质量和知识覆盖范围。
• 推理端：指运行模型、对外提供接口的环境和框架，比如本地部署的Ollama、vLLM，或者云端的API服务。

实际操作时，你可以把模型端和推理端分开选。比如，你的库是中文为主，那么本地推理端部署一个Qwen模型效果可能比用英文为主的模型更好；如果你的机器内存不够，就用云端API。注意不要混为一谈，很多配置问题都是因为“模型文件下载了，但推理框架没配对”造成的。

我对个人知识库的建议是：优先用云端API做问答，本地部署做Embedding。问答模型要求高，本地小模型在复杂总结时明显力不从心；而Embedding模型相对轻量，本地跑效果已经足够，而且能防止文档内容外传。

3. 实操过程：5分钟跑通Obsidian版LLM Wiki

3.1 环境准备与依赖安装

以Obsidian为例，这是目前把知识库和LLM结合得最顺手的笔记工具。它能跑LLM相关插件，同时保留你熟悉的双链、标签、图谱功能。

你需要准备的环境非常简单：

• Obsidian（桌面端，最新版即可）
• 一个可用的LLM API Key（OpenAI格式即可，也可以指向Ollama本地接口）
• 两块磁盘空间（用于索引缓存、模型下载等，看你用不用本地Embedding）

安装插件时，在Obsidian的设置–第三方插件–关闭安全模式，然后浏览社区插件，搜索“Smart Connections”和“Obsidian Copilot”这两个插件，一键安装。如果网络不行，也可以去GitHub下载插件包手动放进.obsidian/plugins目录。这一步不需要写任何代码。

3.2 核心配置：把LLM接进知识库

安装完插件后，最关键的一步是配置模型接口。Smart Connections这类插件默认支持多种模型服务，你需要在插件设置里选择：

• 服务商：OpenAI、Google Gemini、Anthropic、Ollama等。
• API Base：如果你用本地Ollama，就填http://localhost:11434/v1，如果你用云端，填官方地址或你的代理网关。
• API Key：云端服务填密钥，本地服务随便填一个占位符即可。

我第一次配Ollama时就卡在这：以为要填密钥，结果只需要填URL，然后把Api Key留空或填“ollama”，就通了。

然后设置Embedding模型。Smart Connections会为每篇笔记生成向量表示，用于语义关联和相似检索。它默认可以用OpenAI的Embedding接口，也可以选本地模型库。我建议数据量小（几千篇内）且注重隐私的话，本地Embedding更稳妥，速度也不慢。

这里有一个容易被忽略的细节：不同Embedding模型的向量维度不同，如果你之后切换Embedding模型，需要重新对全库生成索引，否则会报维度不匹配。插件的设置里一般有“Rebuild Index”按钮，切模型后务必点一下。

3.3 建立知识库结构：MOC、标签与双链配合

LLM插件可以降低知识库的维护成本，但它不能替代知识库的基础结构。你需要保持这几个习惯：

• 每篇笔记要有明确的标题，最好是名词短语，不要用日期或“新建笔记”。
• 建立MOC（Map of Content），比如“数据库笔记总览”“自动驾驶学习路径”等MOC页面，用来汇总各类主题的入口。
• 保留手动双链的习惯，LLM建议的关联可以作参考，但重要链接需要你肉眼确认。

我在实践中的具体做法是：每周一天集中处理原始笔记，先让Smart Connections给全库做一个相关文件推荐，它会按相似度列出当前笔记最相关的10篇。我逐条看推荐原因，确实有价值的就手动加上链接，有疑问的则打开原文查看。这个流程把过去需要大量阅读的“找关系”环节压缩到了半小时内。

配合Obsidian Copilot插件，还可以把对话面板直接嵌入笔记编辑区。选中任意一段文字，在对话框里输入“解释这段内容”，它会基于当前笔记上下文给出解释。这个功能平时写笔记时随手可用，不需要切换窗口。

3.4 用问答的方式从库里找资料

配置完成后，最直观的体验就是问答式检索。原先我在笔记库里找一个具体参数，可能要在搜索结果里翻十分钟；现在直接在Copilot对话框问：“我之前记录的xx框架的缓存策略是什么？”它会根据语义匹配到相关笔记，然后结合笔记内容生成一段回答。

这个过程的原理并不神秘：插件先把你的问题转成向量，然后在笔记向量库里做相似度检索，找出Top K相关块，把“问题+检索到的块”拼成Prompt，发给LLM生成最终回答。你可以通过调节Top K参数来改变“参考范围”。K值太小容易漏内容，太大则会把不相关的信息掺进来。我个人习惯设置在5到10之间，具体看你的笔记粒度。

注意，这套问答是基于已有笔记内容，不是让模型凭空回答。所以如果你的笔记里本来没有这个内容，它也不会编造出来（至少理论上不会）。实际操作中，模型仍然可能脑补一些貌似合理的推断，这是所有RAG系统都要警惕的幻觉问题。我的经验是：在对话框下方勾选“显示引用来源”，每次回答后点开来源看是不是真的出自自己的笔记，如果是则采信，如果不是，删掉重问或者补充关键词。

4. 进阶玩法：自建RAG管道，打造个人Wiki问答系统

4.1 什么时候需要自建管道

插件方案用到后期，可能会遇到三个瓶颈：

• 内容量大了之后，每次检索响应越来越慢，插件界面也容易卡。
• 插件封装的检索逻辑简单，不能做混合检索（关键词+向量）、重排序、过滤等高级操作。
• 你想在自有服务里对多个知识库、多用户做访问控制，插件做不到。

这之后就可以考虑自建RAG管道。功能层面，它和插件方案核心一致，都是“向量化–检索–生成”，但你可以完全掌控每一层。

4.2 数据准备：清洗与切分决定上限

很多RAG项目失败的教训我把它们归为一句：数据清洗的优先级永远高于模型选择。你的PDF可能包含页眉页脚、乱码表格、扫描图片；你的网页抓取内容可能带了大量导航链接；你的Markdown笔记可能有代码块、公式、列表嵌套。如果不处理，检索阶段就会有一堆噪声块被召回。

清洗之后是切分。切分策略没有银弹，但有几个原则可以参考：

• 尽量保持语义完整性：表格、代码块、引用不要被拦腰截断。
• 切分粒度根据用途定：做摘要可以块大一点（500~800字），做问答块小一点（200~400字）效果好。
• 重叠窗口（overlap）可以缓解边界断裂：比如每块200字，相邻块重叠50字。

我用的切分工具主要是LlamaIndex的SentenceSplitter，它会根据句子边界切分，尽量避免切断句子。同时自定义了分隔符，保证代码块和表格能完整保留。

4.3 向量化与索引构建实战（含代码）

接下来是向量化。如果你用的是Mac或者有NVIDIA显卡的Linux机器，推荐本地跑Embedding模型，比如BAAI/bge-m3或Qwen3-Embedding。在Python里用sentence-transformers加载并生成向量，代码很简单：

from sentence_transformers import SentenceTransformer model = SentenceTransformer("BAAI/bge-m3") sentences = ["第一段笔记内容", "第二段笔记内容"] embeddings = model.encode(sentences, normalize_embeddings=True) print(embeddings.shape)

注意批量编码时加normalize_embeddings=True，这样向量内积就是余弦相似度，计算快捷语义一致。

向量库我常用chromadb或milvus-lite。个人库用chromadb就够了，它的persistent_client可以直接落盘，伴随的add接口传documents、ids、embeddings即可。

import chromadb client = chromadb.PersistentClient(path="./wiki_db") collection = client.get_or_create_collection("my_wiki") collection.add( documents=chunked_texts, ids=[str(i) for i in range(len(chunked_texts))], embeddings=embeddings.tolist() )

检索的时候，用同一个Embedding模型给问题编码，然后query接口取Top K：

query_embedding = model.encode([query], normalize_embeddings=True) results = collection.query(query_embeddings=query_embedding.tolist(), n_results=5)

这里有个实操心得：很多库默认的检索距离度量是L2，但如果你把Embedding做了归一化，用余弦距离或内积排序是等价的。如果你换了Embedding模型没有重新归一化，排序效果会打折。

4.4 把检索结果交给LLM生成

检索完成后，把命中的文本块拼接进Prompt模板，再交给LLM回答。你可以用OpenAI SDK，也可以接Ollama的OpenAI兼容接口。

一个常用的模板结构是：

根据以下知识库内容回答问题。如果知识库中没有相关信息，请明确回答“知识库中未找到相关信息”，不要编造。 知识库内容： {context} 问题：{question}

这个模板的价值在于约束模型不要幻觉。当然它不能完全杜绝，但能显著降低乱答的概率。

完整生成代码：

from openai import OpenAI client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama") resp = client.chat.completions.create( model="qwen2.5:7b", messages=[ {"role": "system", "content": "你是一个严谨的知识库助手，只依据提供的资料回答。"}, {"role": "user", "content": prompt} ], temperature=0.3 ) print(resp.choices[0].message.content)

temperature调到0.2~0.4比较合适，太低显得机械，太高容易发散。如果库里相关内容很硬核，可以更激进一点用0.1。

4.5 垂域数据的特殊处理

如果你要做的Wiki是特定行业，比如法律、医疗、金融，数据准备颗粒度还要再细。以我做过的一个工程类知识库为例，我们处理的标准、规范类文档，必须先拆出章、条、款层级，再根据条号做切分和关联。否则模型检索到一条规范时，无法明确引用到具体条款。

垂域场景里，同义词替换和术语归一化也很重要。直接把“数据库”和“DB”混在一起，向量检索效果差，因为Embedding模型天然不认识缩写。你可以先做术语表，在清洗阶段把缩写统一展开，或者建一个同义词映射在检索时自动扩展。

另一个细节是，垂域数据往往有大量表格。直接把表格转成Markdown再切分，容易把横向关系打散。我的方案是：对于关键表格，额外生成一段文字摘要，作为独立的“表格解读块”入库。检索时即使原文表格块被截断，摘要块也能兜底。

4.6 性能优化与缓存策略

自建管道跑起来之后，最先遇到的问题是响应慢。常见瓶颈有三个：

• Embedding生成：批量文档入库时可以离线批量跑，但单条问题也走这个模型就需要优化。
• 向量检索：几万条块的线性扫描开销不小，但chromadb默认用近似最近邻已经足够快，真正慢的是把embedding从CPU往GPU搬的环节。
• LLM推理：本地小模型生成速度如果不够，可以引入缓存机制，对相同或相似问题直接返回历史结果。

我的缓存策略很简单：把问题和答案存到SQLite里，问题先做归一化去空格、小写，然后查表，命中就直接返回。实测命中率大概30%左右，能省不少API费用。

还有一个建议：不要在同一个进程里反复加载Embedding模型，改为启动一个常驻服务，通过HTTP接口传递文本，返回向量。我用Flask包了一个极简服务，一行代码调用，省去每次初始化模型的耗时。

5. 常见问题与排查技巧实录

5.1 问题速查表

这几个问题，我几乎每周都会在社区看到有人问，自己也全部踩过。

5.2 切分参数到底怎么调

切分是RAG里最容易反复调也最容易懵的地方。我给一个可以当起点的参数组合：

• 块大小（chunk_size）：300~500字符（中文可以按字计，英文按token）。
• 重叠（overlap）：50~100字符。
• 分隔符：优先用段落、标题、列表项，不要用无意义的换行。

然后在自己的知识库上做一个评测：选5-10个你觉得最可能被搜到的问题，跑一遍检索，看返回块是否真的对应答案所在位置。如果答案块老是靠后或者根本不出现，说明分块里可能把关键上下文隔开了，需要调大重叠或者改用滑动窗口。

我在一次调优中，发现某篇笔记的答案片段被一个代码块从中间切开，导致检索时无法正确召回。后来我把“代码块”提前识别并整体保留，不参与切分，问题就解决了。

5.3 线上数据流对RAG的影响

如果你是在动态Wiki上做RAG，内容会不断更新，这时候要考虑“更新后多久能被检索到”。最简单的做法是每天凌晨跑一次增量索引，把今天新增和修改的笔记向量化入底库。但要注意：旧版本内容在向量库里也会残留，如果原文档被删了，向量库里却没有同步删除，检索时你会突然看到一条不存在的引用链接。

我的处理办法是在每条向量里额外存一个元数据字段，标记文档路径和修改时间。增量更新时，先按路径删除旧向量，再重新添加。这比全量重建省很多时间。

5.4 成本控制：个人知识库别乱烧钱

用云端API跑问答和Embedding，如果内容量巨大，费用容易失控。我自己的习惯是：

• Embedding全部走本地小模型，既不花钱也保护隐私。
• 问答模型如果不追求极致效果，用本地7B~14B模型足够。生成质量在知识库场景下差距没有想象中那么大。
• 只有需要高难度推理或者长文总结时，才切到API大模型。

本地Qwen或ChatGLM这类7B~14B模型，在语义理解和中文知识整理上已经比两年前的模型强了太多。日常问答足够，还能免费用。我目前的主力问答是在本地跑，API只是备用方案。

5.5 额外分享一个独门细节：双链接库对检索的加成

传统RAG管道只关注文本块的向量相似度，忽略了笔记间的双链关系。我在实践里发现，如果把双链信息也纳入检索——比如先向量检索Top N，然后把与N中任一笔记直接相邻的笔记也追加进候选集——再让LLM综合回答，效果会好很多。因为Wiki的链接本身就是人类整理过的高质量语义关系，和向量相似度互补。

这个功能插件方案里Smart Connections部分实现了（它的“related notes”会参考双链），如果你自建管道，可以自己加一个图遍历步骤。代价是检索时延会增加几十毫秒，但准确率提升相当明显。

6. 从llm_wiki走向更智能的Agent式管理

6.1 从问答到自动维护

当Wiki积累到一定程度，你会发现单纯的问答只是第一层。真正让知识库保持活性的是自动维护能力，也就是让LLM不只回答问题，还能主动整理体系。比如：

• 自动提取新文档摘要，生成“摘要字段”并挂到对应MOC。
• 对过期笔记打上“待更新”标签。
• 定期扫描未打标签的笔记，把高相似度条目聚到一起，建议合并或建立关联。

这些都可以用开源框架做一个调度脚本。思路是：每天定时把新增笔记丢给LLM，让它输出结构化建议（JOSN格式），然后脚本根据建议写回笔记元数据。我用一个简单的Python脚本实现了“新增笔记摘要自动生成”和“相似笔记去重建议”两个能力，私库的整洁度有了明显提升。

6.2 Autonomous Agents在知识库里的价值

热搜词里经常看到“LLM Powered Autonomous Agents”的讨论。放到Wiki场景，我的理解是：一个自动化Agent可以承担“知识库管理员”的职责，它根据你的使用习惯，主动去发现内容缺口、提出关联建议、生成读后报告。

听起来很酷，但落地时要克制。Agent能力再强，它也只是基于已有文本做推断。如果放任它自动写入内容，很容易把编造的总结混进原始笔记，污染后续所有检索。我的原则是：Agent可以生成建议，但写入操作必须人工确认。在自动化流程里加一个“human in the loop”确认节点，可以避免很多信息灾难。

6.3 如何规划下一步

看到这里，你应该对“llm_wiki”有了一个比较全面的了解。如果你想动手做，我的建议是：

• 第一次使用，从Obsidian插件开始，搭一个能聊天的知识库。
• 跑两周后，记录问答过程中哪些回答让你满意、哪些完全不对，分析是检索问题还是模型问题。
• 如果确认插件不够用，再考虑自建RAG。自建时先把数据清洗做好，再选模型。
• 别一上来就追求Agent自动化，先把基础问答做到“十问七对”，再谈自动整理。

我个人在实际操作中的体会是，llm_wiki的价值不在于技术多炫，而在于它真正把“积累”和“使用”连接起来了。以前整理笔记是负担，现在整理笔记变成了一种可被模型消化、可被检索利用的投资。知识库不再是放在那里吃灰的收藏夹，而是一个越用越聪明的工作台。

最后再分享一个小技巧：在你第一次配置好Smart Connections或自建管道之后，先用库里的十篇核心文章做一轮“自问自答”测试，把答案和原文对照着看。这个过程会花一下午，但能让你极度清楚自己的库哪里强、哪里弱，比看十篇教程都管用。方法很简单——选一篇文章，问它“这篇文章的核心结论是什么”，然后看模型是不是真的从文章里提取的，还是自己瞎编的。多测几篇，你对llm_wiki的掌控感就完全不一样了。