用RAG打造私有知识库：LLM Wiki实战指南

要说为什么做 llm_wiki，其实是因为我自己的资料库已经乱到忍无可忍了。Markdown 文件散落在各个目录，印象笔记里的内容多年没整理，浏览器书签收藏了上百篇“以后再看”的文章，真到用的时候一个都搜不出来。传统 wiki 的检索是关键词匹配，你记得原文里有个什么词才能搜到，但很多时候你只记得“那篇文章大概讲过模型量化的事情，好像是关于显存优化的”，这种模糊需求传统搜索毫无办法。后来我把大语言模型（LLM）和 wiki 体系结合起来，给自己的知识库配了一个会用自然语言对话的 AI 助手——这就是 llm_wiki 项目的由来。

简单说，llm_wiki 干的事情就是：你像聊天一样问它“我为啥量化后推理变慢了”，它会在你自己的知识库里找到真正相关的内容，然后整理成一段有依据的回答，并且告诉你结论是从哪些文档里来的。这套东西既能跑在本地，也能用云端大模型 API，适合 AI 工程学习者、知识管理重度用户，或者想给团队搭一个私有知识问答系统的人。这篇内容我会把从技术选型、原理拆解到完整代码实现和常见坑位全部摊开讲，照着做你也能拥有一个属于自己的 LLM 知识库。

1. 项目解读与整体架构设计

1.1 llm_wiki 到底是什么

从字面上拆，llm_wiki 就是“大语言模型 + Wiki”的组合体。但这里有个需要澄清的点：它并不是让你做一个像维基百科那样的在线百科网站，而是“把你的私有知识库变成能聊天、能问答、能溯源的系统”。Wiki 在这里代表的是一种结构化、可长期维护的知识沉淀方式，LLM 则充当那个“理解你问题、读懂你文档、组织答案”的智能层。

我见过不少团队做过类似的内部知识库，最常见的失败模式是：搞了个很重的平台，录入内容要靠专人维护，最后大家还是习惯去问聊天软件。llm_wiki 的定位正好相反——底层知识依然是你熟悉的 Markdown 文件，文件就是 wiki 页面，你完全可以用任何编辑器维护内容；上层用 RAG（Retrieval-Augmented Generation，检索增强生成）技术把大模型接进来。维护成本和体验收益解耦，内容该怎么样还怎么样，只是查询方式彻底变了。

整个项目跑起来之后，你得到的不只是一个“搜索引擎”，而是一个真正读过你所有笔记的助手。你问它“上次那个线上事故最后怎么解决的”，它不只是给你甩一堆链接，而是把事故原因、处理过程、最终结论糅合成一段人话，然后告诉你这些结论出自哪些笔记。这个体验，传统 wiki 给不了。

1.2 核心需求池与技术选型思路

在动手写代码之前，我先把需求列了一个清单，所有技术选型都是围绕这些需求来的：

• 数据必须是本地优先，文件格式用 Markdown，方便 Git 版本管理，也方便自己随时改
• 检索要能处理“语义相似”而不是单纯关键词匹配，这决定了必须引入 Embedding 向量化
• 生成答案要支持本地推理和云端 API 两种模式，方便在不同机器上切换
• 项目本身要轻，不能一上来就引入一堆中间件，个人电脑也能跑得动
• 查询结果必须带引用来源，不然 AI 一本正经地胡说八道会害死人

这几条需求落下来，技术栈基本就清晰了。Embedding 模型我用的是 BGE-M3 系列，里面对中文支持很好；向量存储早期试过 Chroma，后来数据量上来之后换成了 Milvus；推理侧本地用 Ollama 跑 Qwen 系列模型，云端留了 OpenAI 兼容接口。整个编排代码没上 LangChain 这类框架，直接用 Python 手写，代码量不大反而更容易排查问题。

我强烈建议读者第一版也用手写方式。LangChain 抽象层级太多，出了问题你根本分不清是 Embedding 的问题、向量库的问题还是 Chain 内部的问题。手写 200 行代码，每个环节你都知道在干什么。

1.3 方案对比：为什么没选传统搜索引擎或现成知识库

做一个知识库问答系统其实有几条路。第一条是直接用 Elasticsearch 的关键词搜索，配合 ik 分词器做中文支持。这条路实现简单，但问题很明显——搜索“怎么优化显存”搜不到你笔记里“降低显存占用”的内容，因为词汇对不上。这也是传统 wiki 最大的痛点。

第二条是直接用大模型做长文本对话，把所有文档一股脑塞进上下文窗口。这条路对 token 消耗太严重，而且 GPT-4 级别的上下文窗口也就几十万字，资料稍微多点就放不下，更别提很多开源本地模型窗口更小。更关键的是，大模型本身会“编造”内容，没有了检索过程的约束，回答的准确性完全不可控。

第三条就是 RAG，也就是现在的 llm_wiki 方案。先通过语义检索召回最相关的文档片段，再把片段作为参考材料拼到提示词里让模型总结回答。这样模型只需在给定的片段里理解归纳，不需要凭空生成专业知识，答案基本都有依据。而且向量检索快，十万篇文档也能在几百毫秒内完成召回。权衡之后，RAG 是唯一能在“资料量、回答质量、资源消耗、可追溯性”四个维度上同时兼顾的方案。

2. 核心技术链路：从文档到问答的完整原理

2.1 RAG 为什么能解决“大模型不懂我的文档”

很多人第一次接触大模型知识库都会有个疑问：为什么不直接拿我所有的笔记去微调一个模型？答案是没必要，也不划算。微调的本质是改变模型的行为模式和知识边界，成本高、周期长，而且每次文档更新都要重新训练。我们大部分私有知识是事实型信息，不需要通过调整模型权重来记住，只需要在“提问时”把相关内容临时提供给它即可——这就像考试开卷，你只需要知道去书的哪一页找答案就行。

RAG 的全流程可以拆成两条线。离线索引线：把 wiki 里的 Markdown 文档切分成若干片段，每个片段用 Embedding 模型转成向量，再把向量和原文一起存入向量数据库。在线问答线：提问进来之后，同样用 Embedding 模型把问题转成向量，去向量库里做相似度检索，取回最相关的 Top-K 片段，最后把这些片段和用户问题一起组织成 Prompt 交给大模型，让它基于这些片段生成最后答案。

两条线的核心都是 Embedding——这种技术能把文本映射成一个几百几千维的浮点数组，语义相近的文本在向量空间里距离也越近。比如“如何降低显存占用”和“显存优化方案”这两句话字面完全不同，但向量距离很近，所以语义检索就能把它们关联起来。

2.2 文档加载与切片：最容易被低估的环节

整个 RAG 链路里，我认为切片策略对最终问答质量的影响能占到 60% 以上，但很多教程都一带而过。切片太大了，比如直接把整个 wiki 页面作为一片，向量化之后语义被稀释，检索时精度会下降；切片太小了，比如一句话一片，又容易丢失上下文信息，模型看了一段孤立的话根本不知道在说什么。

我最后采用的方案是“层级切片”：优先按 Markdown 的标题层级切，一级标题下的内容是一个大块，大块里再按段落和字符数联合切分。具体参数是主块最大 800 字符，重叠 100 字符。重叠这个操作很重要，它可以避免一句话被从中间截断导致语义不完整。另外我记录了每个块对应的标题路径，这样在后面生成引用来源时可以直接显示出“来自哪篇文章的哪个章节”。

这里要补充一个我踩过的坑：代码块和表格如果被拦腰切断，检索回来就是一堆垃圾。因此切片器要聪明一点，尽量让代码块和表格整体保留在同一个块里，宁可块长一些也不要切断。这个逻辑在实现时其实就是判断当前字符是不是在代码围栏内，情况允许就延迟切分点。

2.3 向量化与相似度计算：数学在背后做了什么

Embedding 模型会把文本转换成一个固定维度的向量。我的选择是 BGE-M3，输出 1024 维向量，支持中文效果也不错。向量化之后，检索的核心操作就是计算查询向量和库中所有向量的相似度，常用的是余弦相似度：两个向量夹角越接近 0，相似度越高，也就是语义越接近。

实际实现时当然不会真的遍历所有向量做全量计算，那样十万篇文档每秒只能查几次。向量数据库会建立 ANN（近似最近邻）索引，常见的有 HNSW、IVF 等。HNSW 是一种多层图结构，查询时先在图的上层粗粒度找方向，再往下层精确定位，速度比暴力计算快几个数量级。代价是索引构建需要时间和内存，但对个人知识库这种量级来说完全不是问题。

我自己实测的数据是：把 3000 多个文本块写入 Milvus，构建 HNSW 索引耗时不到 3 秒；查询耗时一般在 30 毫秒到 80 毫秒之间。这个量级的延迟对问答体验来说完全感知不到。不过如果你的数据量到了百万级，那就要认真调 HNSW 的 efConstruction 和 M 参数了，这些后续在图索引那节再细讲。

2.4 提示词组织与答案溯源：让模型学会“只说自己知道的”

检索拿到了相关片段，最后一步是生成。这一步的关键是提示词设计。我的系统提示词严格规定：你只能依据检索到的资料片段回答问题，如果资料中没有相关信息，就明确说“知识库中没有相关内容”，禁止编造。同时要求回答以“根据知识库中的资料”作为开头，并且每次回答末尾按引用的文档标题列出参考来源。

这里有一个细节：多个片段拼接进 Prompt 时，需要告诉模型哪段来自哪个文档。我通常在每段前面加一个类似[来源: filename.md#section]的元信息行。这样模型在回答时更容易把内容和来源对应起来，生成出来的引用也更准确。如果你只是把一堆文本拼接起来，模型可能会乱配来源——它分不清这段话到底是哪篇文章里的。

上下文窗口也要提前估算。如果每篇笔记切出来 800 字符的块，Top-K 设置 6 那就大约是 4800 字符的参考内容，加上问题本身和系统提示词，总输入大概在 1500 token 左右。本地 7B 模型的窗口普遍有 8K 到 32K，完全能覆盖；云端模型更不用说。但要注意，参考内容越多，模型的回答质量不一定越好——太多不相关内容反而会干扰判断。所以 Top-K 一般在 4 到 8 之间比较合适。

3. 手把手实现 llm_wiki：完整实操流程

3.1 环境准备与依赖安装

我默认大家用的是 Linux 或 macOS 环境，Windows 的话建议先装 WSL2，因为有些 Python 的向量计算库在原生 Windows 上编译会遇到各种问题。首先是创建虚拟环境，Python 版本要求 3.10 以上：

mkdir llm_wiki && cd llm_wiki python3 -m venv .venv source .venv/bin/activate

接下来安装核心依赖。我先把所以依赖列出来，说明一下各自作用：

pip install pymilvus==2.4.9 pip install sentence-transformers==3.0.1 pip install openai==1.40.0 pip install markdown==3.7 pip install python-frontmatter==1.1.0 pip install gradio==4.44.1 pip install tiktoken==0.7.0

pymilvus 是向量数据库客户端，sentence-transformers 用来加载 Embedding 模型，openai 库负责调大模型接口，markdown 和 python-frontmatter 用于解析 wiki 文档，gradio 用来快速做 Web 界面，tiktoken 则是为了估算 token 数量防止超限。另外如果你打算用 Ollama 跑本地模型，记得先去官网装好 Ollama 运行时，再拉一个推理模型，比如ollama pull qwen2.5:7b。

3.2 准备种子数据：Wiki 目录结构与 Markdown 规范

llm_wiki 的知识来源是某个固定目录下的 Markdown 文件。我建议目录结构设计成下面这样：

wiki_data/ ├── 01-大模型基础/ │ ├── transformer结构.md │ └── 注意力机制.md ├── 02-工程实践/ │ ├── 显存优化指南.md │ ├── 推理加速方案.md └── 03-团队规范/ └── 代码评审流程.md

目录按数字编号是为了排序稳定。每个 Markdown 文件头部还可以加 YAML front-matter，用来标注作者、标签、创建时间等元信息，后面构建索引时可以直接读取。比如工程实践那篇文章开头可能是：

--- title: 显存优化指南 tags: [推理, 显存, 性能调优] created: 2025-01-10 --- # 显存优化指南 ## 背景 在 7B 模型推理过程中，显存占用过高会导致 OOM...

这种规范不会影响普通阅读习惯，但能让索引阶段获得更多结构化信息。如果你的 wiki 里已经有海量文件没有 front-matter，也不用补，解析器里做容错就行，缺失元数据不影响主流程。

3.3 构建索引：从 Markdown 文件到向量库

索引构建是整个项目的地基，我把核心代码拆成几个函数。首先是文档加载与解析：

import os from pathlib import Path import frontmatter from markdown import markdown from bs4 import BeautifulSoup def load_markdown_files(root_dir: str) -> list[dict]: docs = [] for path in Path(root_dir).rglob("*.md"): with open(path, encoding="utf-8") as f: post = frontmatter.load(f) # 转 HTML 后去标签，方便做文本清理，同时保留原始 Markdown 文本用于展示 html = markdown(post.content, extensions=["fenced_code", "tables"]) soup = BeautifulSoup(html, "html.parser") text = soup.get_text(separator="\n") docs.append({ "title": post.get("title", path.stem), "path": str(path), "content": text, "raw": post.content, "tags": post.get("tags", []), }) return docs

这个函数的目的是把目录下所有 Markdown 文件统一解析成字典。用 frontmatter 库读取头部元数据，用 markdown 库把正文转成 HTML 再去标签，是为了让后续切片时拿到干净的文本。注意我这里同时保留了原始 Markdown（raw字段），后面检索显示时我们可以选择展示原文或者纯文本。

切片部分我用了递归按标题切分的策略：

import re def split_by_headings(text: str, max_chunk_size: int = 800, overlap: int = 100): lines = text.split("\n") chunks = [] current_chunk = {"heading": "", "content": []} current_chars = 0 for line in lines: heading_match = re.match(r"^(#{1,4})\s+(.+)$", line) if heading_match: if current_chunk["content"] and current_chars > 0: chunks.append({ "heading": current_chunk["heading"], "content": "\n".join(current_chunk["content"]), "char_count": current_chars, }) current_chunk = { "heading": heading_match.group(2), "content": [line], } current_chars = len(line) else: current_chunk["content"].append(line) current_chars += len(line) + 1 # 超过阈值时检查当前块是否在代码块外，安全则切分 if current_chars >= max_chunk_size and not inside_code_block(current_chunk["content"]): chunks.append({ "heading": current_chunk["heading"], "content": "\n".join(current_chunk["content"]), "char_count": current_chars, }) current_chunk = {"heading": current_chunk["heading"], "content": []} current_chars = 0 if current_chunk["content"]: chunks.append({ "heading": current_chunk["heading"], "content": "\n".join(current_chunk["content"]), "char_count": current_chars, }) # 对超长块做二次硬切分 final_chunks = [] for chunk in chunks: if chunk["char_count"] > max_chunk_size * 1.5: final_chunks.extend(hard_split(chunk, max_chunk_size, overlap)) else: final_chunks.append(chunk) return final_chunks

这里有个 inside_code_block 函数要简单说明，实际上就是遍历已有行数统计代码围栏 ``` 的奇偶数量，如果奇数说明目前在代码块内，延迟切分。这个细节直接决定代码类碎片能不能被完整切出，值得多写几行。最后的 hard_split 是兜底逻辑，负责处理一段没有标题的长文，直接按字符数硬切并带上重叠。

向量化和写入向量库的代码相对简单：

from sentence_transformers import SentenceTransformer from pymilvus import MilvusClient, DataType model = SentenceTransformer("BAAI/bge-m3") client = MilvusClient("llm_wiki_milvus.db") if not client.has_collection("wiki_chunks"): client.create_collection( collection_name="wiki_chunks", dimension=1024, primary_field_name="id", vector_field_name="vector", metric_type="COSINE", ) docs = load_markdown_files("wiki_data") records = [] for idx, doc in enumerate(docs): chunks = split_by_headings(doc["content"]) for cidx, chunk in enumerate(chunks): chunk_text = f"{doc['title']}\n{chunk['heading']}\n{chunk['content']}" vector = model.encode(chunk_text).tolist() records.append({ "id": len(records), "title": doc["title"], "path": doc["path"], "heading": chunk["heading"], "content": chunk["content"], "vector": vector, }) client.insert(collection_name="wiki_chunks", data=records) print(f"Inserted {len(records)} chunks")

这里一个细节值得注意：我把文档标题、章节标题、正文内容拼接在一起喂给 Embedding 模型，而不是只编码正文。因为标题往往是内容的强语义概括，带着标题向量化可以让相似的主题聚得更近，搜索“显存优化”时更容易命中那篇文档。这是一个不花一分钱就能提升检索精度的技巧。

3.4 检索问答：查询接口与 Prompt 设计

索引建好了，接下来做查询接口。第一步是把用户的问题向量化，去向量库查相似块，然后把命中的块组装成 Prompt：

from openai import OpenAI def search_wiki(query: str, top_k: int = 6) -> list[dict]: q_vector = model.encode(query).tolist() results = client.search( collection_name="wiki_chunks", data=[q_vector], limit=top_k, output_fields=["title", "heading", "content", "path"], ) hits = [] for hit in results[0]: entity = hit["entity"] hits.append({ "title": entity["title"], "heading": entity["heading"], "content": entity["content"], "path": entity["path"], "score": hit["distance"], }) return hits def build_prompt(query: str, hits: list[dict]) -> str: context = "" for i, hit in enumerate(hits): context += f"[来源{i+1}: {hit['title']} - {hit['heading']}]\n{hit['content']}\n\n" return f"""你是一个基于个人知识库的问答助手。请根据下面提供的参考内容回答用户的问题。 要求： 1. 只能依据参考内容回答，禁止使用外部知识或编造内容。 2. 如果参考内容中没有相关信息，请明确回答“知识库中未找到相关内容”。 3. 回答时在句子末尾或段落后的括号中注明来源编号，例如[来源1]。 4. 使用简洁、专业的中文回答。 参考内容： {context} 用户问题：{query} """

我为了兼容不同的大模型后端，OpenAI 客户端的 base_url 和 api_key 是从环境变量里读的。既然要用 Ollama 本地接口，就设置：

export OPENAI_BASE_URL=http://localhost:11434/v1 export OPENAI_API_KEY=ollama

然后在代码里client = OpenAI()就能直接调用本地模型。这套做法非常实用，因为代码完全不用改，换云端模型的时候只需要改环境变量和模型名。

完整问答函数长这样：

def ask_llm_wiki(query: str, top_k: int = 6) -> tuple[str, list[dict]]: hits = search_wiki(query, top_k=top_k) if not hits: return "知识库中未找到相关内容。", [] prompt = build_prompt(query, hits) response = client.chat.completions.create( model="qwen2.5:7b", messages=[{"role": "user", "content": prompt}], temperature=0.3, max_tokens=1024, ) answer = response.choices[0].message.content return answer, hits

温度设置成 0.3 是有讲究的。问答场景需要确定性输出，温度太高模型容易自由发挥编造内容，温度太低回答会比较死板。0.3 是我反复测试后觉得比较合适的点：既能正常组织语言，也不会天马行空。另外 max_tokens 给到 1024，个人知识库的问题一般不需要更长的答案，太长反而显得啰嗦。

3.5 快速做一个可交互的 Web 界面

命令行体验终究差一点，所以我用 Gradio 套了一个极简界面，让整个东西看起来像个正经产品：

import gradio as gr def chat_ui(message, history): answer, hits = ask_llm_wiki(message) refs = "\n".join([f"- [{h['title']}]({h['path']})" for h in hits]) return f"{answer}\n\n**参考来源：**\n{refs}" gr.ChatInterface( fn=chat_ui, title="llm_wiki - 个人知识库问答", description="基于 RAG 的个人 Wiki 智能问答系统", ).launch(server_name="0.0.0.0", server_port=7860)

启动之后浏览器打开http://localhost:7860，就能像用 ChatGPT 一样跟自己的知识库聊天了。这里我把参考来源以 Markdown 链接的形式展示在答案下方，用户点过去就能直接看到 wiki 原文，这比单纯给一个编号更有用。如果团队内部使用，可以把 server_name 改成内网 IP，让同事也能访问，甚至加一层简单的认证。

3.6 效果测试：一次完整的问答之旅

为了验证系统的真实效果，我放了一个测试问题进去：“如何降低推理显存占用”。检索阶段返回了三个高相关的片段，分别是显存优化指南里的“背景”章节、工程实践中“量化方案”章节以及“批处理策略”章节。模型给出的回答是：

根据知识库中的资料，降低推理显存占用可以从以下几个方面入手：第一，使用量化技术将模型权重从 FP16 压缩到 INT8 或 INT4，显著减少显存占用；第二，合理设置 batch size，避免过大的批处理导致显存峰值过高；第三，采用梯度检查点或激活值重计算技术减少中间激活的存储消耗[来源2][来源3]。

这个回答把三个文档的内容自然地融合在了一起，并且正确标注了来源。这让我确认 RAG 链路整体是通的。你要知道最怕的结果是模型只回答某一片段内容或者自己编造，这时候你就要检查检索召回、提示词、模型温度这几个环节了。

4. 踩坑实录与优化经验

4.1 常见问题速查表

这个项目从零跑到稳定，我前前后后踩了不少坑。把最有代表性的一些问题和排查思路整理在下面，方便大家对照排查：

4.2 检索质量调优的心得

调优检索质量有一个基本思路：先查“错在哪一层”。如果问题明明在知识库里但没召回，那是切片或向量化的问题；如果召回了但回答得不好，那是提示词或生成参数的问题。

我在实践中发现两个非常有效的调优手段。第一个是“查询改写”。用户的问题通常很口语化，比如“为啥我模型跑起来那么慢”，直接拿去向量检索效果不如把它改写成“模型推理速度慢的原因和优化”。可以用一个轻量模型先改写问题再检索，实测命中率能有明显提升。第二个是“重排序”。向量检索召回 Top 50，再用一个 Cross-Encoder 模型逐一计算每个候选与问题的相关性打分，取最高的 Top 6。Cross-Encoder 比 Bi-Encoder 精确得多，只是速度慢，所以适合做精排。BGE 官方就提供了对应的 reranker 模型，可以直接套用。

4.3 关于模型和成本的选择建议

很多人问我到底是本地模型好还是云端 API 好。我的回答是：分阶段。首次跑通项目、调试代码的时候，用云端 API 最省心，不用折腾环境，速度又快；等系统稳定了，再根据你的隐私要求决定是否迁移到本地模型。如果知识库里包含客户信息、个人隐私等敏感内容，那就直接上本地模型，比如 Qwen2.5-7B 或者 Llama-3-8B，配一张 24G 显存的显卡足够用。如果只是个人笔记，用云端 API 成本也不高，正常问答频率一个月几十块钱够了，关键是每次只传相关片段而不是整个文档，省很多 token。

不过用本地模型要注意：7B 模型的理解能力和总结能力跟 GPT-4 级别的还是有差距，尤其在长文本归纳和多步推理上。如果你发现答案质量不满意，一个高效的做法是在不改变架构的前提下换更大参数的模型，比如 14B 或 32B 版本，而不是去改代码。

4.4 为什么我最后放弃了 LangChain

说实话，我最初是用 LangChain 写第一版的，代码确实短——加载器、切片器、向量库、对话链都是现成组件，二三十行就拼完了。但真正用起来就发现问题：一是版本更新太频繁，每个小版本都可能改 API，网上搜到的代码很可能跑不了；二是抽象层级导致问题排查困难，比如检索结果不理想，你很难确定是哪一步出了问题，要层层 breakpoint；三是过度封装导致自定义逻辑难做，比如我要加“代码块不切断”的切片逻辑，在 LangChain 里反而要绕很多弯。

手写的好处是每一步都在掌控之中，出了问题能直接定位。等到以后真的要上生产、需要大规模调度的时候再引入框架也不迟。对于 llm_wiki 这种中轻量项目，手写百来行代码是性价比最高的选择。

5. llm_wiki 的扩展方向：从个人笔记到团队知识中台

项目跑通之后，很多人会想能不能让它更进一步。这里我分享几个我认为有价值的扩展方向。

第一个方向是增加标注与反馈机制。在问答界面加点赞/点踩按钮，记录用户的反馈数据，后续就可以分析哪些问题总是回答不好，针对性优化切片策略或补全文档。别小看这个功能，它能让一个 demo 变成可持续改进的系统。

第二个方向是引入多模态支持。现在的版本只处理 Markdown 文本，但很多知识其实藏在 PDF、图片里。如果 wiki 里经常放架构图截图，可以考虑接入视觉语言模型，或者在知识库层面先把图片上的文字提取出来再做向量化。

第三个方向是自动化索引流水线。用 Git 钩子或者定时任务扫描 wiki 目录，检测到 Markdown 文件变更后自动增量更新向量库。这一步做完，llm_wiki 就能像一个真正的“活”知识库，永远跟你的最新笔记保持同步。

我自己做过的最大一次扩展是把个人版改成了团队版，加了文档权限控制和简单的 tag 过滤。因为检索时可以根据当前用户的可视范围过滤文档集合，这对于存储多个客户项目的资料非常有价值。具体实现也不复杂，就是在向量检索之前加一层过滤表达式，Milvus 原生支持带表达式的 search。

回到最初的体验，我现在的日常工作流已经离不开这个系统了。写方案前先问一下自己的 wiki，开会前快速查一下之前的项目总结，那份从 2023 年攒到现在的几百篇技术笔记终于不再是数据孤岛。如果你也有一大堆精心整理但根本搜不出来的文档，我建议你花一个周末把 llm_wiki 搭起来。它不需要昂贵的服务器，核心代码也就几百行，但它会改变你管理知识的习惯。