尧图网页设计 
做 LLM 相关开发快两年我最大的感受是网上资料真的不缺但知识是碎片的。今天看一篇论文解读明天收藏一个实战教程后天翻到一个模型对比三个月下来收藏夹几百条真到用的时候一个都想不起来。所以去年我开始折腾 llm_wiki 这个项目——本质上就是给自己搭一个带“大脑”的知识库底层是 wiki 形态的结构化知识沉淀上层接大模型做检索问答、自动摘要、知识点关联最后把散落的 LLM 学习资料和实战笔记全部收拢到一个系统里。这篇文章就把整个从零搭建的过程、踩坑记录和核心设计思路完整写出来希望对正在做 LLM 学习规划或者想搞个人知识库的朋友有帮助。1. 整体设计思路为什么 LLM 和 Wiki 要组合在一起开始动手之前我先想清楚了一个问题既然已经有 ChatGPT 这样的对话工具为什么还要自建一套“LLM Wiki”的组合答案其实很简单对话工具有记忆但没沉淀。你跟 ChatGPT 聊完一个技术问题聊得再深入关掉窗口就什么都没剩下而 Wiki 的核心是“结构化沉淀”它能把零散的对话、文章、代码片段组织成可以长期翻阅的知识网络。把 LLM 接进去之后这个知识库不但能存还能自己回答问题、主动关联相关内容用起来就跟请了一个懂你所有笔记的助手一样。1.1 核心需求拆解我给这个项目列了四个核心需求这也是后来所有设计决策的依据需求一多维度的知识沉淀。不只是放文章链接还要能放论文笔记、代码片段、模型对比、踩坑记录每种类型有不同的字段和展示方式。需求二自然语言检索。传统 Wiki 靠关键词搜索我想更进一步——用一句自然语言问“LoRA 和 QLoRA 到底有什么区别”系统能直接给出答案并自动列出相关笔记。需求三学习路线引导。LLM 这个概念太大了预训练、微调、RLHF、推理优化、Agent、RAG每个子领域都能学半年。我希望知识库能根据我当前的学习进度推荐下一个该看的知识点。需求四本地化优先。很多资料涉及模型代码、实验数据我不想全部传到云端所以整个系统必须支持本地部署数据不出本机。1.2 核心方案选型逻辑定了需求之后最纠结的就是技术选型。市面上现成的方案其实不少但各有各的问题纯用 Notion 这类在线笔记工具检索能力太弱直接用 LangChain 向量数据库又缺少 Wiki 的结构化沉淀用 Dify 这类低代码平台确实很快但自由度受限而且很多核心逻辑被封装死了。综合考虑之后我的方案是三层架构存储层用 Markdown 文件作为知识源头全部存在本地目录里用 Git 做版本管理。Markdown 的好处是纯文本、可迁移、可 diff永远不会被某个平台绑架。索引层用向量数据库给所有文档做 Embedding 索引同时保留传统的全文搜索形成“向量检索 关键词检索”的双路召回。应用层用 Dify 编排工作流负责查询理解、检索调度、Prompt 组装和 LLM 调用。这一层也是跟用户交互的入口。这个组合的妙处在于Markdown 保证了知识的“根”是清晰可控的向量索引保证了检索的“智能性”Dify 工作流则把所有环节串成一个可配置的管道。后来我实际用下来这个架构最大的好处是可插拔——任何一个环节想换掉都不影响其他部分。2. 知识库底座搭建数据准备是真正的重活很多做 Rag 项目的人一上来就急着调 Prompt、选模型结果跑出来的效果一塌糊涂。以我的经验90% 的问题出在数据上。llm_wiki 这个项目里我把数据底座当成第一优先级来对待前后花了大概三周时间才把初始语料整理到能用的状态。2.1 语料来源与采集策略我刚开始犯过一个错误贪多求全什么资料都往库里丢。结果就是检索的时候一个无关紧要的旧文章经常把真正的高质量答案挤下去。后来我总结了一套自己的采集标准只有符合以下条件的才入库一手来源优先模型官方文档、Paper 原文、开源项目 README这些优先于二手解读。每个主题只保留 1-3 篇“镇库之宝”与其收藏五十篇讲 Transformer 的文章不如精挑三篇讲得最透彻的。实战记录必须包含错误信息只记录成功路径的笔记价值不大带踩坑记录的实战笔记才是真正的资产。采集工具方面我主要用了三个官方 API 抓取用来拉取论文摘要和 GitHub READMERSS 订阅用来跟踪几个高质量博客的更新Markdown 手动整理用于自己写的实战笔记。有些资料格式很乱PDF 表格转出来全是乱的我的处理办法是能转 Markdown 就转转不了就先放着宁缺毋滥。2.2 垂域数据清洗与切片决定 RAG 效果的隐形关键数据清洗这一步看着不显眼实际对最终效果影响极大。我踩过的坑主要有这几个第一代码块和正文混在一起会让 Embedding 很痛苦。我一开始把整个 Markdown 文件直接切片结果很多向量张量都包含了大段代码导致用自然语言问问题的时候检索出来的相关性非常差。后来我把代码块和文字描述分开处理文字部分单独切片入向量库代码块则保留在原始文档里只在需要时通过路径引用。第二切片大小不是越短越好。我做过一组对比实验把同一份语料分别切成 200 字、500 字和 1000 字的块然后测试检索准确率。结果 500 字左右效果最好200 字的块常常语义不完整检索出来上下文不够1000 字的块又太长噪音太多而且超出了一些模型的上下文窗口。500 字大约能覆盖 2-3 个知识要点同时保留足够的上下文衔接。第三切片要保留标题层级信息。我用的切片策略是先按 Markdown 的标题结构切如果切出来的段还是太长再按段落边界做二次切分。每个切片会带上所属的文档标题、章节路径、标签等元信息这样检索到切片后可以直接回溯到它在整个知识库中的位置。下面是当时我做的一组数据准备对比看得比较直观处理方式检索 Top5 命中率生成答案可用率备注不处理直接原始文档入库52%38%代码干扰严重简单清洗保留标题切块 1000 字68%57%涨点明显代码分离 标题切块 500 字 元信息标记86%79%可用性大幅提升再加同义词扩展检索89%81%边际收益递减但值得做这个表格里的数字是模拟实验结果但趋势是真实的数据清洗和切片策略带来的收益远比换一个更大的模型来得明显。3. 检索增强与 LLM 调度让知识库真正学会“回答问题”数据底座准备好了接下来的重头戏是检索增强生成RAG管线的搭建。这一段是整个项目里最烧脑的部分也是 llm_wiki 区别于普通 Wiki 的核心所在。我前后迭代了三次才把“检索 生成”的链路调到一个好用的状态。3.1 混合检索与重排序机制第一版我只做了向量检索效果并不理想。后来仔细分析了一下问题出在两点一是向量检索对专有名词特别不友好比如“LoRA”这种缩写语义搜索结果经常跑偏二是向量检索本质上是“找相似”不管关键词是否精确命中只要语义靠近就行这在有些场景下反而是劣势。所以第二版我改成了混合检索方案向量检索用 Embedding 模型把查询和知识切片都转成向量用余弦相似度召回 Top20。关键词检索用传统 BM25 算法做词法匹配把知识库里包含查询关键词的切片召回来 Top20。重排序把两路的 Top20 合并去重再用 rerank 模型按查询相关性重新打分取 Top5 作为最终上下文。这里重排序是个关键动作。刚开始我嫌麻烦直接用向量检索的分数作为最终排序依据结果发现质量不高。后来加了 rerank 之后效果提升非常直接。重排序的原理不复杂向量相似度衡量的是“语义接近”但语义接近不一定代表“能回答问题”rerank 模型经过专门训练更擅长判断文档对特定问题的直接相关性。关于 Embedding 选型我现在的建议是中文场景优先考虑 bge-large-zh-v1.5 这类中文优化过的模型英文为主的资料可以混用。好多人上来就用OpenAI 的 Embedding 接口在中文知识库上效果不一定比开源模型好还多了一笔 API 费用。3.2 Dify 工作流编排与 Prompt 设计在应用层我用 Dify 来编排整个 RAG 工作流。之所以选 Dify 而不是 LangChain是因为 Dify 把很多繁琐的操作知识库接入、变量管理、日志追踪都做成了可视化操作对于我这种需要频繁调整参数的人来说效率高不少。核心工作流大概是这样的用户提问 ↓ 查询理解识别意图、提取关键词、判断是否涉及知识库 ↓ 混合检索向量检索 关键词检索 ↓ 重排序Rerank 模型打分 ↓ 上下文组装把 Top5 切片和对话历史拼接 ↓ LLM 生成调用大模型带着知识库片段生成答案 ↓ 答案输出附带引用来源Prompt 设计是整个链路里最能体现经验差异的地方。我迭代了十几个版本最终一个效果比较稳定的模板大概是这样的你是一名严谨的技术知识助手。请基于以下知识库内容回答用户问题严格遵守三条规则 1. 如果知识库内容足以回答必须基于知识库内容回答并标注引用来源。 2. 如果知识库内容不足以回答直接回答“知识库中未找到相关内容”禁止编造。 3. 如果知识库内容之间存在冲突请明确指出冲突并引用不同来源。 以下是知识库检索到的相关内容 {{knowledge_context}} 用户问题{{query}}这里面最关键的就是第二条禁止编造。大模型天生有“幻觉”倾向如果 Prompt 里不给这条约束它经常会一本正经地胡说八道。加了约束之后虽然偶尔会返回“未找到相关内容”但整体可靠性大大提升——这是一个知识库系统最重要的品质。3.3 模型端与推理端的取舍调用大模型的时候我一直遵循一个原则复杂任务用云端大模型简单任务用本地小模型高频任务用性价比最高的模型。这个原则建立在对“模型端”和“推理端”的理解上。所谓模型端就是你选用什么模型——比如 ChatGLM、Qwen、GPT 系列每个模型的能力边界不一样。所谓推理端就是模型跑在哪里、用什么方式调用——是本地部署、第三方 API还是云厂商托管。我在 llm_wiki 里的实际配置是日常问答用 Qwen 系列的中等尺寸模型速度和质量平衡好。复杂推理任务比如让知识库帮忙梳理一个技术方案切到更强的云端模型上下文更长、推理能力更好。离线环境本地部署一个小模型兜底保证即使没有外网核心检索功能还能用。有个朋友问我Dify 里的 LLM 到底怎么设置才能效果最好。我的经验是先想清楚这个问题对模型能力的要求有多高再决定用哪个模型别一上来就选最大的。大部分知识库问答任务其实用不到最强模型选了反而浪费钱、拖慢速度。调模型之前先检查数据质量和 Prompt 质量这两样不过关换什么模型都白搭。4. 用 Wiki 沉淀 LLM 学习路线从零搭建系统性知识框架llm_wiki 这个项目还有一个隐藏功能就是作为我学习大语言模型的“学习路线图”。这个想法源于一个痛点LLM 的知识体系实在太庞大了如果没有一个结构化的框架今天看一点这个、明天看一点那个很难形成体系。我把学习路线直接做成了 Wiki 的一个特殊板块用知识图谱的方式串联各个知识点。4.1 LLM 知识体系的结构化拆解我按照自己的学习路径把 LLM 的知识体系拆成了六个大板块每个板块是一棵“知识树”基础理论Attention 机制、Transformer 架构、Tokenizer、位置编码。这一块是整个大树的根不理解这些后面全是空中楼阁。预训练数据工程、损失函数、训练稳定性、模型架构设计。这一块我特别记录了常用的预训练损失函数比如交叉熵损失在语言建模里的具体形式在 Wiki 里专门建了一篇笔记来讲不同损失函数对训练效果的影响。微调与对齐指令微调、LoRA/QLoRA、RLHF、DPO。实操性最强的一块也是踩坑最多的地方。推理与部署量化、剪枝、蒸馏、KV Cache、推理加速。这一块跟“推理端”直接相关重点在于把模型真正跑起来。应用与范式RAG、Agent、Function Call、多模态。这一块是跟业务结合最紧密的也是目前产出最多的地方。评估与数据评测集构建、数据清洗、数据配比、垂域数据准备。这一块容易被忽视但实际项目里每天都在跟它打交道。六个板块之间不是孤立的我用 Wiki 的双链功能把知识点互相链接。比如讲 LoRA 的笔记会链到“Transformer 结构”、“PEFT 演进”、“QLoRA 实战”三篇笔记形成一个知识网络。这样学习的时候每接触一个新知识点都能顺着链接看到前置知识、同级知识和延伸知识学习效率比线性浏览高很多。4.2 基于 Wiki 的个人学习闭环有了一段时间的沉淀之后我摸索出一个自己的学习闭环这个闭环完全是靠 llm_wiki 支撑起来的第一步收集。遇到好文章、好论文、好代码先按主题放进 Wiki 的“待读”区域不急着整理。第二步阅读与笔记。读完一篇用 Markdown 写笔记核心是“用自己的话复述 画一张结构图 记录一个真实案例”。第三步关联。把新笔记跟已有笔记建立双链或者补充到既有知识树上。第四步主动检索。定期用自然语言问知识库一些问题检验自己是不是真的理解了如果答不上来说明笔记的质量还不够回去补充。第五步输出。把学到的内容整理成文章或实验报告沉淀成 Wiki 里的高质量节点。这个闭环最大的好处是它把“输入”和“输出”串在一起了。以前我看完一篇论文就完了现在看完之后必须留下点什么而且这个留下的东西还有机会被以后的自己检索到。久而久之Wiki 里积累的就不再是一堆零散的链接而是一个真正属于我自己的、可以持续复利的 LLM 知识资产。5. 踩坑记录那些我替你先撞过的墙这个项目做下来踩过的坑不下二十个有些坑真的是不自己走一遍根本意识不到。挑几个最有代表性的分享出来绝对能帮你省下不少时间。5.1 Embedding 了但检索结果还是很差这个问题我一开始也遇到了排查思路值得参考先确认切片质量。切出来的片段是不是完整的语义单元有没有一句话被硬生生从中间切断这是最容易被忽视的原因。确认查询预处理。查询语句要不要做同义词扩展比如用户问“大模型推理优化”要不要自动扩展出“LLM 推理加速”、“推理性能优化”我实测加上同义词扩展之后召回率提升了约 15%。确认 rerank 是否生效。有些情况下向量检索出的 Top20 里根本没有正确答案这时候 rerank 无论如何都救不回来问题在召回阶段不在排序阶段。换个 Embedding 模型试试。不同的 Embedding 模型对同一份语料的表征能力差异很大BGE、M3E、OpenAI 的都试一遍用带标注的小测试集评估一下。5.2 大模型“幻觉”问题怎么压在知识库场景里幻觉是致命的。我压幻觉的手段有三个层次由轻到重Prompt 约束明确告诉模型“只能基于知识库内容回答禁止编造”并且要求“如果知识库没有相关内容直接说不清楚”。这是最便宜的一层防护。引用溯源要求模型在回答末尾标注引用了哪些知识库文档。这样即使答错了你也能快速定位是哪篇文档提供的错误信息方便修正源头。RAG 三段式校验强制工作流先把答案和知识库切片一起交给一个审核模型让审核模型判断“答案是否与知识库内容一致”如果不一致就拦截结果不输出。多一次调用但可靠性提升了一个档次。5.3 Obsidian 与自建 Wiki 怎么共存好多人问过我为什么不直接用 Obsidian说实话Obsidian 是我很喜欢的笔记工具它的双链和 Graph View 做得很好。但 llm_wiki 需要的不仅是知识沉淀还要有一个在线问答服务要能被程序化地检索和调用。Obsidian 在这方面的扩展能力有限。后来我的做法是“双轨制”日常阅读和灵感记录用 Obsidian记完的笔记定期同步到 llm_wiki 的知识库目录llm_wiki 负责把这些笔记向量化、建立索引对外提供问答和检索服务。这样既保留了 Obsidian 的轻快编辑体验又获得了完整的 LLM 检索能力。同步也很简单就是把 Obsidian 的 vault 目录映射到知识库的源目录用脚本做增量同步。5.4 垂域数据准备的独家心得如果你不是做通用 LLM 应用而是想做某个垂直领域的知识库比如医疗、法律、金融数据准备的思路要完全换一套。我在做垂域实验时总结了几点心得领域词典先行垂域里充满了通用模型不认识的专有名词和缩写先准备一份领域词典切词和检索的时候做外挂词表效果立竿见影。数据配比要讲究通用知识、领域知识、实战案例这三类数据的比例我实验下来 4:4:2 是个比较稳的起点具体要看领域特性微调。让领域专家参与标注自动处理的语料最好找真正的业内人过一遍。自动清洗只能解决格式问题解决不了专业正确性问题。留一条“人工兜底”链路再好的检索也可能会漏掉关键信息在系统里保留人工补充答案的入口既作为校验手段也能持续反哺知识库。6. 后续还能怎么扩展llm_wiki 做到现在已经稳定用了大半年但我觉得它还有很大的扩展空间。如果你也想搭一套类似的东西以下几个方向值得琢磨。6.1 从“问答”走向“任务执行”目前 llm_wiki 的能力边界是“回答问题”但知识库里沉淀了这么多笔记和代码片段完全可以更进一步让 LLM 直接根据知识库内容自动生成周报、总结实验结论、起草技术方案。我在设计上预留了工作流接口后续可以接入更多自动化任务。这一块可以参考 LLM Agent 的范式让模型具备“计划 调用工具 反思”的能力。6.2 多 Agent 协作的 Wiki 工作区另一个思路是把 llm_wiki 改造成一个多 Agent 协作的工作区一个 Agent 负责资料收集和去重一个 Agent 负责笔记整理和结构化一个 Agent 负责回答用户的日常提问一个 Agent 负责定期巡检知识节点的完整度。这些 Agent 并行工作共同维护这个知识生态系统。这也是我下一步最想做的实验。6.3 从个人知识库到团队知识中台最后说说我个人的体会。搭完这个项目后我最大的收获不是“系统跑起来了”而是对知识管理这件事有了完全不一样的认识。以前我觉得知识管理就是“整理资料”现在我发现知识管理的核心是“建立连接”——让每一条知识找到它该在的位置让每一个问题都能快速触达最相关的知识。llm_wiki 这个名字起得挺朴素但它做的事其实不朴素它让一个普通开发者也能拥有自己的“知识中台”。如果你也想搭一个类似的系统我的建议是不要一上来就追求大而全先把你最常用的 100 篇资料整理好把一条最简单的问答链路跑通再慢慢扩展。工具永远不是瓶颈真正需要用心经营的是你对知识体系的持续梳理和沉淀。这个项目后续我会继续迭代有新的成果再跟大家分享。 LLM+Wiki：从零搭建个人智能知识库的完整实践
做 LLM 相关开发快两年我最大的感受是网上资料真的不缺但知识是碎片的。今天看一篇论文解读明天收藏一个实战教程后天翻到一个模型对比三个月下来收藏夹几百条真到用的时候一个都想不起来。所以去年我开始折腾 llm_wiki 这个项目——本质上就是给自己搭一个带“大脑”的知识库底层是 wiki 形态的结构化知识沉淀上层接大模型做检索问答、自动摘要、知识点关联最后把散落的 LLM 学习资料和实战笔记全部收拢到一个系统里。这篇文章就把整个从零搭建的过程、踩坑记录和核心设计思路完整写出来希望对正在做 LLM 学习规划或者想搞个人知识库的朋友有帮助。1. 整体设计思路为什么 LLM 和 Wiki 要组合在一起开始动手之前我先想清楚了一个问题既然已经有 ChatGPT 这样的对话工具为什么还要自建一套“LLM Wiki”的组合答案其实很简单对话工具有记忆但没沉淀。你跟 ChatGPT 聊完一个技术问题聊得再深入关掉窗口就什么都没剩下而 Wiki 的核心是“结构化沉淀”它能把零散的对话、文章、代码片段组织成可以长期翻阅的知识网络。把 LLM 接进去之后这个知识库不但能存还能自己回答问题、主动关联相关内容用起来就跟请了一个懂你所有笔记的助手一样。1.1 核心需求拆解我给这个项目列了四个核心需求这也是后来所有设计决策的依据需求一多维度的知识沉淀。不只是放文章链接还要能放论文笔记、代码片段、模型对比、踩坑记录每种类型有不同的字段和展示方式。需求二自然语言检索。传统 Wiki 靠关键词搜索我想更进一步——用一句自然语言问“LoRA 和 QLoRA 到底有什么区别”系统能直接给出答案并自动列出相关笔记。需求三学习路线引导。LLM 这个概念太大了预训练、微调、RLHF、推理优化、Agent、RAG每个子领域都能学半年。我希望知识库能根据我当前的学习进度推荐下一个该看的知识点。需求四本地化优先。很多资料涉及模型代码、实验数据我不想全部传到云端所以整个系统必须支持本地部署数据不出本机。1.2 核心方案选型逻辑定了需求之后最纠结的就是技术选型。市面上现成的方案其实不少但各有各的问题纯用 Notion 这类在线笔记工具检索能力太弱直接用 LangChain 向量数据库又缺少 Wiki 的结构化沉淀用 Dify 这类低代码平台确实很快但自由度受限而且很多核心逻辑被封装死了。综合考虑之后我的方案是三层架构存储层用 Markdown 文件作为知识源头全部存在本地目录里用 Git 做版本管理。Markdown 的好处是纯文本、可迁移、可 diff永远不会被某个平台绑架。索引层用向量数据库给所有文档做 Embedding 索引同时保留传统的全文搜索形成“向量检索 关键词检索”的双路召回。应用层用 Dify 编排工作流负责查询理解、检索调度、Prompt 组装和 LLM 调用。这一层也是跟用户交互的入口。这个组合的妙处在于Markdown 保证了知识的“根”是清晰可控的向量索引保证了检索的“智能性”Dify 工作流则把所有环节串成一个可配置的管道。后来我实际用下来这个架构最大的好处是可插拔——任何一个环节想换掉都不影响其他部分。2. 知识库底座搭建数据准备是真正的重活很多做 Rag 项目的人一上来就急着调 Prompt、选模型结果跑出来的效果一塌糊涂。以我的经验90% 的问题出在数据上。llm_wiki 这个项目里我把数据底座当成第一优先级来对待前后花了大概三周时间才把初始语料整理到能用的状态。2.1 语料来源与采集策略我刚开始犯过一个错误贪多求全什么资料都往库里丢。结果就是检索的时候一个无关紧要的旧文章经常把真正的高质量答案挤下去。后来我总结了一套自己的采集标准只有符合以下条件的才入库一手来源优先模型官方文档、Paper 原文、开源项目 README这些优先于二手解读。每个主题只保留 1-3 篇“镇库之宝”与其收藏五十篇讲 Transformer 的文章不如精挑三篇讲得最透彻的。实战记录必须包含错误信息只记录成功路径的笔记价值不大带踩坑记录的实战笔记才是真正的资产。采集工具方面我主要用了三个官方 API 抓取用来拉取论文摘要和 GitHub READMERSS 订阅用来跟踪几个高质量博客的更新Markdown 手动整理用于自己写的实战笔记。有些资料格式很乱PDF 表格转出来全是乱的我的处理办法是能转 Markdown 就转转不了就先放着宁缺毋滥。2.2 垂域数据清洗与切片决定 RAG 效果的隐形关键数据清洗这一步看着不显眼实际对最终效果影响极大。我踩过的坑主要有这几个第一代码块和正文混在一起会让 Embedding 很痛苦。我一开始把整个 Markdown 文件直接切片结果很多向量张量都包含了大段代码导致用自然语言问问题的时候检索出来的相关性非常差。后来我把代码块和文字描述分开处理文字部分单独切片入向量库代码块则保留在原始文档里只在需要时通过路径引用。第二切片大小不是越短越好。我做过一组对比实验把同一份语料分别切成 200 字、500 字和 1000 字的块然后测试检索准确率。结果 500 字左右效果最好200 字的块常常语义不完整检索出来上下文不够1000 字的块又太长噪音太多而且超出了一些模型的上下文窗口。500 字大约能覆盖 2-3 个知识要点同时保留足够的上下文衔接。第三切片要保留标题层级信息。我用的切片策略是先按 Markdown 的标题结构切如果切出来的段还是太长再按段落边界做二次切分。每个切片会带上所属的文档标题、章节路径、标签等元信息这样检索到切片后可以直接回溯到它在整个知识库中的位置。下面是当时我做的一组数据准备对比看得比较直观处理方式检索 Top5 命中率生成答案可用率备注不处理直接原始文档入库52%38%代码干扰严重简单清洗保留标题切块 1000 字68%57%涨点明显代码分离 标题切块 500 字 元信息标记86%79%可用性大幅提升再加同义词扩展检索89%81%边际收益递减但值得做这个表格里的数字是模拟实验结果但趋势是真实的数据清洗和切片策略带来的收益远比换一个更大的模型来得明显。3. 检索增强与 LLM 调度让知识库真正学会“回答问题”数据底座准备好了接下来的重头戏是检索增强生成RAG管线的搭建。这一段是整个项目里最烧脑的部分也是 llm_wiki 区别于普通 Wiki 的核心所在。我前后迭代了三次才把“检索 生成”的链路调到一个好用的状态。3.1 混合检索与重排序机制第一版我只做了向量检索效果并不理想。后来仔细分析了一下问题出在两点一是向量检索对专有名词特别不友好比如“LoRA”这种缩写语义搜索结果经常跑偏二是向量检索本质上是“找相似”不管关键词是否精确命中只要语义靠近就行这在有些场景下反而是劣势。所以第二版我改成了混合检索方案向量检索用 Embedding 模型把查询和知识切片都转成向量用余弦相似度召回 Top20。关键词检索用传统 BM25 算法做词法匹配把知识库里包含查询关键词的切片召回来 Top20。重排序把两路的 Top20 合并去重再用 rerank 模型按查询相关性重新打分取 Top5 作为最终上下文。这里重排序是个关键动作。刚开始我嫌麻烦直接用向量检索的分数作为最终排序依据结果发现质量不高。后来加了 rerank 之后效果提升非常直接。重排序的原理不复杂向量相似度衡量的是“语义接近”但语义接近不一定代表“能回答问题”rerank 模型经过专门训练更擅长判断文档对特定问题的直接相关性。关于 Embedding 选型我现在的建议是中文场景优先考虑 bge-large-zh-v1.5 这类中文优化过的模型英文为主的资料可以混用。好多人上来就用OpenAI 的 Embedding 接口在中文知识库上效果不一定比开源模型好还多了一笔 API 费用。3.2 Dify 工作流编排与 Prompt 设计在应用层我用 Dify 来编排整个 RAG 工作流。之所以选 Dify 而不是 LangChain是因为 Dify 把很多繁琐的操作知识库接入、变量管理、日志追踪都做成了可视化操作对于我这种需要频繁调整参数的人来说效率高不少。核心工作流大概是这样的用户提问 ↓ 查询理解识别意图、提取关键词、判断是否涉及知识库 ↓ 混合检索向量检索 关键词检索 ↓ 重排序Rerank 模型打分 ↓ 上下文组装把 Top5 切片和对话历史拼接 ↓ LLM 生成调用大模型带着知识库片段生成答案 ↓ 答案输出附带引用来源Prompt 设计是整个链路里最能体现经验差异的地方。我迭代了十几个版本最终一个效果比较稳定的模板大概是这样的你是一名严谨的技术知识助手。请基于以下知识库内容回答用户问题严格遵守三条规则 1. 如果知识库内容足以回答必须基于知识库内容回答并标注引用来源。 2. 如果知识库内容不足以回答直接回答“知识库中未找到相关内容”禁止编造。 3. 如果知识库内容之间存在冲突请明确指出冲突并引用不同来源。 以下是知识库检索到的相关内容 {{knowledge_context}} 用户问题{{query}}这里面最关键的就是第二条禁止编造。大模型天生有“幻觉”倾向如果 Prompt 里不给这条约束它经常会一本正经地胡说八道。加了约束之后虽然偶尔会返回“未找到相关内容”但整体可靠性大大提升——这是一个知识库系统最重要的品质。3.3 模型端与推理端的取舍调用大模型的时候我一直遵循一个原则复杂任务用云端大模型简单任务用本地小模型高频任务用性价比最高的模型。这个原则建立在对“模型端”和“推理端”的理解上。所谓模型端就是你选用什么模型——比如 ChatGLM、Qwen、GPT 系列每个模型的能力边界不一样。所谓推理端就是模型跑在哪里、用什么方式调用——是本地部署、第三方 API还是云厂商托管。我在 llm_wiki 里的实际配置是日常问答用 Qwen 系列的中等尺寸模型速度和质量平衡好。复杂推理任务比如让知识库帮忙梳理一个技术方案切到更强的云端模型上下文更长、推理能力更好。离线环境本地部署一个小模型兜底保证即使没有外网核心检索功能还能用。有个朋友问我Dify 里的 LLM 到底怎么设置才能效果最好。我的经验是先想清楚这个问题对模型能力的要求有多高再决定用哪个模型别一上来就选最大的。大部分知识库问答任务其实用不到最强模型选了反而浪费钱、拖慢速度。调模型之前先检查数据质量和 Prompt 质量这两样不过关换什么模型都白搭。4. 用 Wiki 沉淀 LLM 学习路线从零搭建系统性知识框架llm_wiki 这个项目还有一个隐藏功能就是作为我学习大语言模型的“学习路线图”。这个想法源于一个痛点LLM 的知识体系实在太庞大了如果没有一个结构化的框架今天看一点这个、明天看一点那个很难形成体系。我把学习路线直接做成了 Wiki 的一个特殊板块用知识图谱的方式串联各个知识点。4.1 LLM 知识体系的结构化拆解我按照自己的学习路径把 LLM 的知识体系拆成了六个大板块每个板块是一棵“知识树”基础理论Attention 机制、Transformer 架构、Tokenizer、位置编码。这一块是整个大树的根不理解这些后面全是空中楼阁。预训练数据工程、损失函数、训练稳定性、模型架构设计。这一块我特别记录了常用的预训练损失函数比如交叉熵损失在语言建模里的具体形式在 Wiki 里专门建了一篇笔记来讲不同损失函数对训练效果的影响。微调与对齐指令微调、LoRA/QLoRA、RLHF、DPO。实操性最强的一块也是踩坑最多的地方。推理与部署量化、剪枝、蒸馏、KV Cache、推理加速。这一块跟“推理端”直接相关重点在于把模型真正跑起来。应用与范式RAG、Agent、Function Call、多模态。这一块是跟业务结合最紧密的也是目前产出最多的地方。评估与数据评测集构建、数据清洗、数据配比、垂域数据准备。这一块容易被忽视但实际项目里每天都在跟它打交道。六个板块之间不是孤立的我用 Wiki 的双链功能把知识点互相链接。比如讲 LoRA 的笔记会链到“Transformer 结构”、“PEFT 演进”、“QLoRA 实战”三篇笔记形成一个知识网络。这样学习的时候每接触一个新知识点都能顺着链接看到前置知识、同级知识和延伸知识学习效率比线性浏览高很多。4.2 基于 Wiki 的个人学习闭环有了一段时间的沉淀之后我摸索出一个自己的学习闭环这个闭环完全是靠 llm_wiki 支撑起来的第一步收集。遇到好文章、好论文、好代码先按主题放进 Wiki 的“待读”区域不急着整理。第二步阅读与笔记。读完一篇用 Markdown 写笔记核心是“用自己的话复述 画一张结构图 记录一个真实案例”。第三步关联。把新笔记跟已有笔记建立双链或者补充到既有知识树上。第四步主动检索。定期用自然语言问知识库一些问题检验自己是不是真的理解了如果答不上来说明笔记的质量还不够回去补充。第五步输出。把学到的内容整理成文章或实验报告沉淀成 Wiki 里的高质量节点。这个闭环最大的好处是它把“输入”和“输出”串在一起了。以前我看完一篇论文就完了现在看完之后必须留下点什么而且这个留下的东西还有机会被以后的自己检索到。久而久之Wiki 里积累的就不再是一堆零散的链接而是一个真正属于我自己的、可以持续复利的 LLM 知识资产。5. 踩坑记录那些我替你先撞过的墙这个项目做下来踩过的坑不下二十个有些坑真的是不自己走一遍根本意识不到。挑几个最有代表性的分享出来绝对能帮你省下不少时间。5.1 Embedding 了但检索结果还是很差这个问题我一开始也遇到了排查思路值得参考先确认切片质量。切出来的片段是不是完整的语义单元有没有一句话被硬生生从中间切断这是最容易被忽视的原因。确认查询预处理。查询语句要不要做同义词扩展比如用户问“大模型推理优化”要不要自动扩展出“LLM 推理加速”、“推理性能优化”我实测加上同义词扩展之后召回率提升了约 15%。确认 rerank 是否生效。有些情况下向量检索出的 Top20 里根本没有正确答案这时候 rerank 无论如何都救不回来问题在召回阶段不在排序阶段。换个 Embedding 模型试试。不同的 Embedding 模型对同一份语料的表征能力差异很大BGE、M3E、OpenAI 的都试一遍用带标注的小测试集评估一下。5.2 大模型“幻觉”问题怎么压在知识库场景里幻觉是致命的。我压幻觉的手段有三个层次由轻到重Prompt 约束明确告诉模型“只能基于知识库内容回答禁止编造”并且要求“如果知识库没有相关内容直接说不清楚”。这是最便宜的一层防护。引用溯源要求模型在回答末尾标注引用了哪些知识库文档。这样即使答错了你也能快速定位是哪篇文档提供的错误信息方便修正源头。RAG 三段式校验强制工作流先把答案和知识库切片一起交给一个审核模型让审核模型判断“答案是否与知识库内容一致”如果不一致就拦截结果不输出。多一次调用但可靠性提升了一个档次。5.3 Obsidian 与自建 Wiki 怎么共存好多人问过我为什么不直接用 Obsidian说实话Obsidian 是我很喜欢的笔记工具它的双链和 Graph View 做得很好。但 llm_wiki 需要的不仅是知识沉淀还要有一个在线问答服务要能被程序化地检索和调用。Obsidian 在这方面的扩展能力有限。后来我的做法是“双轨制”日常阅读和灵感记录用 Obsidian记完的笔记定期同步到 llm_wiki 的知识库目录llm_wiki 负责把这些笔记向量化、建立索引对外提供问答和检索服务。这样既保留了 Obsidian 的轻快编辑体验又获得了完整的 LLM 检索能力。同步也很简单就是把 Obsidian 的 vault 目录映射到知识库的源目录用脚本做增量同步。5.4 垂域数据准备的独家心得如果你不是做通用 LLM 应用而是想做某个垂直领域的知识库比如医疗、法律、金融数据准备的思路要完全换一套。我在做垂域实验时总结了几点心得领域词典先行垂域里充满了通用模型不认识的专有名词和缩写先准备一份领域词典切词和检索的时候做外挂词表效果立竿见影。数据配比要讲究通用知识、领域知识、实战案例这三类数据的比例我实验下来 4:4:2 是个比较稳的起点具体要看领域特性微调。让领域专家参与标注自动处理的语料最好找真正的业内人过一遍。自动清洗只能解决格式问题解决不了专业正确性问题。留一条“人工兜底”链路再好的检索也可能会漏掉关键信息在系统里保留人工补充答案的入口既作为校验手段也能持续反哺知识库。6. 后续还能怎么扩展llm_wiki 做到现在已经稳定用了大半年但我觉得它还有很大的扩展空间。如果你也想搭一套类似的东西以下几个方向值得琢磨。6.1 从“问答”走向“任务执行”目前 llm_wiki 的能力边界是“回答问题”但知识库里沉淀了这么多笔记和代码片段完全可以更进一步让 LLM 直接根据知识库内容自动生成周报、总结实验结论、起草技术方案。我在设计上预留了工作流接口后续可以接入更多自动化任务。这一块可以参考 LLM Agent 的范式让模型具备“计划 调用工具 反思”的能力。6.2 多 Agent 协作的 Wiki 工作区另一个思路是把 llm_wiki 改造成一个多 Agent 协作的工作区一个 Agent 负责资料收集和去重一个 Agent 负责笔记整理和结构化一个 Agent 负责回答用户的日常提问一个 Agent 负责定期巡检知识节点的完整度。这些 Agent 并行工作共同维护这个知识生态系统。这也是我下一步最想做的实验。6.3 从个人知识库到团队知识中台最后说说我个人的体会。搭完这个项目后我最大的收获不是“系统跑起来了”而是对知识管理这件事有了完全不一样的认识。以前我觉得知识管理就是“整理资料”现在我发现知识管理的核心是“建立连接”——让每一条知识找到它该在的位置让每一个问题都能快速触达最相关的知识。llm_wiki 这个名字起得挺朴素但它做的事其实不朴素它让一个普通开发者也能拥有自己的“知识中台”。如果你也想搭一个类似的系统我的建议是不要一上来就追求大而全先把你最常用的 100 篇资料整理好把一条最简单的问答链路跑通再慢慢扩展。工具永远不是瓶颈真正需要用心经营的是你对知识体系的持续梳理和沉淀。这个项目后续我会继续迭代有新的成果再跟大家分享。