知识库 on Kalend's Blog

知识库搭完就完了？加上这两招，效率翻倍

Fri, 29 May 2026 10:00:00 +0800

备选标题①：别再用 RAG 从零搜了！3 步搭出互联知识库 + 接入 AI 助手备选标题②：99% 的人卡在"知识库能搜"就停了——你还能再做两步备选标题③：知识库入门容易精通难：两个进阶玩法效率直接翻倍

上篇我们用 MemPalace + ChromaDB + Ollama 搭好了基础知识库。安装、嵌入、搜索、定时扫描，一条龙跑通。

但说实话，能搜只是起点。

搜索是"每次从零发现"，你问一次它找一次，找不到就是找不到。知识之间的关系？没有。知识的沉淀和演化？也没有。

今天讲两个进阶玩法，直接把知识库从"能用"拉到"好用"：

第一，LLM Wiki 互联知识库。

第二，接入 AI 助手，让记忆自动流转。

一、LLM Wiki：从"搜文档"到"用知识"

传统 RAG 的致命问题

每次提问，RAG 都要重新检索、重新理解、重新组织答案。同一个知识点问了十遍，它就检索了十遍，没有任何积累。

这就像每次考试都从头翻课本，从不做笔记。

LLM Wiki 的思路不一样：一次编译知识，持续更新，互联引用。

它源自 Karpathy 的 LLM Wiki 模式，用互联的 Markdown 文件构建一个持久化的知识网络。

三层架构

LLM Wiki 的核心是三层分离：

Layer 1：raw/ —— 不可变原始资料。

放文章、论文、对话记录等原材料。

一旦放进去就不改，作为知识源头。

Layer 2：Wiki Pages —— AI 拥有的知识页面。

这是核心产出层。

包含实体页、概念页、对比页、查询页。

每个页面都是经过消化的结构化知识。

Layer 3：SCHEMA.md —— 结构规则和标签分类法。

定义整个 wiki 的域配置、标签体系、页面阈值。

是整个系统的"宪法"。

三层分离的好处：原始数据不动，知识页面持续演化，规则独立维护。

实操：5 分钟搭骨架

先创建目录结构：

1

mkdir -p ~/wiki/{raw/{articles,papers,transcripts,assets},entities,concepts,comparisons,queries}

创建 SCHEMA.md：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


# Wiki Schema

## Domain
AI Engineering & Knowledge Management

## Taxonomy Tags
- #architecture
- #embedding
- #retrieval
- #integration
- #rag
- #vector-db
- #workflow

## Page Thresholds
- entity_min_references: 2
- concept_min_sections: 3
- comparison_min_axes: 3
- query_max_age_days: 90

## Naming Convention
- lowercase-with-hyphens.md

创建 index.md（导航中心）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# Wiki Index

## Entities
<!-- entities listed here -->

## Concepts
<!-- concepts listed here -->

## Comparisons
<!-- comparisons listed here -->

## Queries
<!-- queries listed here -->

创建 log.md（操作日志）：

1
2
3
4


# Wiki Log

| Date | Action | Target | Notes |
|------|--------|--------|-------|

完成。这就是一个完整的 LLM Wiki 骨架。

三个核心操作

LLM Wiki 围绕三个操作展开：

Ingest（摄入）：把原材料变成知识。

流程是：捕获原始源 → 讨论要点 → 检查已有页面 → 创建或更新页面 → 更新导航。

不是简单存文件，而是消化、提取、关联、索引一条龙。

Query（查询）：基于已有知识回答。

关键区别：查完之后，有价值的答案会写回 wiki。知识越用越丰富。

Lint（检查）：保持知识库健康。

检测孤儿页面、断裂链接、索引完整性等六类问题。超过 100 个页面后，不跑 Lint 就是给自己埋雷。

Obsidian 兼容

LLM Wiki 原生兼容 Obsidian。[[页面名]] 的 wikilinks 语法直接可用。

Graph View 可以可视化知识网络。

把 ~/wiki 当作 Vault 打开就行，零迁移成本。

二、接入 AI 助手：让知识自动流转

知识库搭好了，但每次手动查还是很累。

更合理的做法是：把知识库变成 AI 助手的长期记忆，对话时自动存取。

方式 A：MemoryProvider 深度集成（推荐）

MemPalace 直接作为 AI 助手框架的 memory provider，对话时自动同步记忆。

在框架配置文件中设置：

1
2
3
4
5
6
7
8


memory:
 memory_enabled: true
 user_profile_enabled: true
 memory_char_limit: 2200
 user_char_limit: 1375
 provider: mempalace
 nudge_interval: 10
 flush_min_turns: 6

再创建 mempalace.json 配置自动提取：

1
2
3
4


{
 "auto_extract": true,
 "extract_model": "glm-4-flash"
}

这里 extract_model 用轻量模型做记忆提取，成本极低。

配置完成后，框架自动注册 6 个工具：

mempalace_recall（语义搜索）、mempalace_store（精准存储）、mempalace_knowledge（查询知识图谱）。

mempalace_kg_add（添加三元组）。

mempalace_kg_invalidate（标记过期）、mempalace_status（记忆总览）。

三个自动钩子

集成后，三个钩子自动工作：

sync_turn() —— 每轮对话结束，自动把消息持久化到 MemPalace。你不用手动存。

on_memory_write() —— 框架内置记忆写入时，自动镜像到 MemPalace。双写，不丢。

on_session_end() —— 对话结束时，自动提取三类记忆：Persona、Episodic、Instruction。提取完直接存入，下次对话自动加载。

去重机制：新记忆与已有记忆做 cosine similarity，超过 0.92 视为重复，跳过存储。防止记忆膨胀。

方式 B：MCP Server（备选）

如果框架不支持 MemoryProvider，可以用 MCP 协议接入：

1
2
3
4


mcp_servers:
 mempalace:
 command: python
 args: ["-m", "mempalace.mcp_server"]

功能一样，但没有自动钩子方便，适合过渡。

三、多实例隔离：别让并发写炸了你的数据库

同时跑多个 Agent（主助手 + OpenClaw 定时挖掘 + 其他实验），它们都写同一个 ChromaDB，迟早出问题。

ChromaDB 不是为高并发写入设计的。多进程同时写，数据损坏只是时间问题。

解决方案：每个 Agent 用独立的 MemPalace 实例。

实例	路径	使用者
主实例	`~/.mempalace/palace/`	AI 助手主程序
第二实例	`~/.mempalace/palace-openclaw/`	OpenClaw 定时挖掘
第三实例	`~/.mempalace/palace-yuan/`	其他 Agent

路径不同，ChromaDB 实例不同，互不干扰。

OpenClaw 定时挖掘脚本示例：

1
2
3
4
5
6


#!/bin/bash

PALACE_DB="/root/.mempalace/palace-openclaw"
PALACE_PATH="/root/.openclaw/workspace-main"

mempalace --palace "$PALACE_DB" mine "$PALACE_PATH" --limit 500

然后配置定时执行。用 OpenClaw 自己的 cron，不要用系统 crontab。

踩坑清单

1. ChromaDB 并发写必挂。 多 Agent 共享一个实例是"能跑"但"迟早崩"。老老实实隔离。

2. 记忆提取模型别用大模型。 extract_model 用轻量模型就够了。用大模型做提取，成本是收益的十倍。

3. LLM Wiki 的 Lint 别偷懒。 知识库超过 100 个页面后，孤儿页面和矛盾内容会越来越多。

4. wiki 路径别用中文。 文件名和目录名都用英文加连字符。中文路径在 wikilinks 中会出奇怪问题。

5. MemPalace 去重阈值 0.92 不要调低。 调到 0.85 以下，相似但不同的记忆会被误判为重复丢弃。宁可多存，不可误删。

6. flush_min_turns 别设太大。 设成 20 的话，对话在第 15 轮断了，那 15 轮的记忆都没存。建议 6-8 轮。

总结

上篇解决了"知识库能存能搜"。

这篇解决了两个更关键的问题：

第一，知识库能互联、能演化。LLM Wiki 的三层架构让知识从"孤立文档"变成"互联网络"，越用越丰富。

第二，知识库能和 AI 助手自动协同。MemPalace 作为 MemoryProvider，对话即存储，查询即回忆，全程自动化。

加上多实例隔离，多 Agent 并行也不会打架。

三步走：基础搭建 → 互联知识库 → AI 助手集成。到这步，你的知识库系统才算真正完成。

3个命令搭知识库：你的笔记终于能"搜懂意思"了

Fri, 29 May 2026 07:36:00 +0800

我搭了个跑在自己机器上的知识库，能自动扫描文件、语义搜索、定时更新，全程零 API 费用。

之前试过关键词搜索笔记，搜"AI怎么记住对话"，0 结果。换成语义搜索，秒命中。下面是完整搭建过程，每一步都能直接复制执行。

为什么你需要一个知识库

笔记越积越多，Ctrl+F 搜不到东西了。关键词匹配只认字面，不认意思。

“AI怎么记住之前的对话"搜不到"记忆系统架构”，但语义上是一回事。这就是关键词搜索的致命缺陷。

第一步：装 MemPalace（5分钟）

MemPalace 是本地优先的 AI 记忆系统，底层用 ChromaDB 存向量数据。

1
2
3
4
5


# 一行安装
pip install mempalace

# 验证
mempalace status

输出类似这样说明成功：

1
2
3


Palace Status:
 Drawers filed: 0
 Total memories: 0

安装完自动创建 ~/.mempalace/ 目录。默认嵌入模型是 all-MiniLM-L6-v2（英文模型，384维），后面会换成中文模型。

第二步：装 Ollama + 中文嵌入模型（10分钟）

默认英文模型对中文命中率约 50%。换成中文模型，实测 100%。

1
2
3
4
5
6
7
8


# 1. 装 Ollama（本地推理引擎）
curl -fsSL https://ollama.com/install.sh | sh

# 2. 启动服务
ollama serve &

# 3. 拉中文嵌入模型（约4.7GB）
ollama pull qwen3-embedding

验证 Ollama 在跑：

1
2


curl http://localhost:11434/api/embeddings \
 -d '{"model":"qwen3-embedding","prompt":"测试中文嵌入"}'

返回一个 4096 维浮点数组就对了。

踩坑提醒： Ollama 嵌入 API 用 prompt 字段，不是 input。ChromaDB 自带的 Ollama 适配器用错了字段，后面会说怎么绕过。

第三步：初始化知识库（3分钟）

编辑 ~/.mempalace/config.json：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


{
 "palace_path": "/root/.mempalace/palace",
 "collection_name": "mempalace_drawers",
 "topic_wings": [
 "project",
 "technical",
 "personal",
 "creative",
 "work"
 ]
}

topic_wings 是知识分区，相当于书架分类标签。按需修改。

写初始化脚本 init_palace.py：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


#!/usr/bin/env python3
"""用 Qwen3 中文嵌入模型初始化 MemPalace 向量集合"""
import chromadb
import requests

class Qwen3Embedding:
 """绕过 ChromaDB Ollama 适配器的 prompt/input bug"""
 def __init__(self, url="http://localhost:11434", model="qwen3-embedding"):
 self.url = url
 self.model = model

 def __call__(self, texts):
 embeddings = []
 for t in texts:
 r = requests.post(
 f"{self.url}/api/embeddings",
 json={"model": self.model, "prompt": t},
 timeout=60
 )
 embeddings.append(r.json()["embedding"])
 return embeddings

client = chromadb.PersistentClient(path="/root/.mempalace/palace")
ef = Qwen3Embedding()

collection = client.get_or_create_collection(
 name="mempalace_drawers",
 embedding_function=ef,
 metadata={"hnsw:space": "cosine"}
)

print(f"集合已就绪，当前 {collection.count()} 条记录")

运行：

1

python3 init_palace.py

关键： 如果之前用默认模型创建过集合（384维），必须删掉重建。Qwen3 是 4096 维，维度不同会报错。

1
2
3
4
5
6
7
8
9


# 重建（会清空已有数据）
python3 -c "
import chromadb
client = chromadb.PersistentClient(path='/root/.mempalace/palace')
for c in client.list_collections():
 client.delete_collection(c.name)
 print(f'已删除: {c.name}')
"
# 然后重新运行 init_palace.py

第四步：存入第一条知识（2分钟）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


#!/usr/bin/env python3
"""存入一条知识并验证"""
import chromadb
import hashlib
import time
import requests

client = chromadb.PersistentClient(path="/root/.mempalace/palace")
col = client.get_collection("mempalace_drawers")

text = "AI 助手的记忆系统分四层：热记忆（每轮注入）→ 用户画像 → 知识库按需检索 → 会话历史搜索"
wing = "technical"
room = "memory-architecture"

resp = requests.post("http://localhost:11434/api/embeddings",
 json={"model": "qwen3-embedding", "prompt": text}, timeout=60)
embedding = resp.json()["embedding"]

doc_id = hashlib.md5(text.encode()).hexdigest()[:16]
col.add(
 ids=[doc_id],
 embeddings=[embedding],
 documents=[text],
 metadatas=[{
 "wing": wing,
 "room": room,
 "timestamp": time.strftime("%Y-%m-%dT%H:%M:%S")
 }]
)

print(f"已存入: {text[:50]}...")
print(f"总条数: {col.count()}")

第五步：验证语义搜索（2分钟）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


#!/usr/bin/env python3
"""语义搜索测试"""
import chromadb
import requests

client = chromadb.PersistentClient(path="/root/.mempalace/palace")
col = client.get_collection("mempalace_drawers")

query = "AI 怎么记住之前的对话？"

resp = requests.post("http://localhost:11434/api/embeddings",
 json={"model": "qwen3-embedding", "prompt": query}, timeout=60)
query_embedding = resp.json()["embedding"]

results = col.query(query_embeddings=[query_embedding], n_results=3)

for i, doc in enumerate(results["documents"][0]):
 dist = results["distances"][0][i]
 wing = results["metadatas"][0][i].get("wing", "?")
 print(f"[{dist:.3f}] ({wing}) {doc[:80]}...")

实测效果对比：

搜索问题	关键词匹配	语义搜索
“AI怎么记住之前的对话”	0 结果	命中"四层记忆架构"
“怎么防止模型忘东西”	0 结果	命中记忆管理策略
“中文向量模型哪个好”	0 结果	命中嵌入模型对比

第六步：自动扫描入库（核心）

写一个脚本扫描你的笔记/文档目录，自动切片 + 向量化 + 入库。

保存为 auto_index.sh：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68


#!/bin/bash
set -e

DOCS_DIR="${1:-$HOME/notes}"
PALACE_PATH="$HOME/.mempalace/palace"
LOG_FILE="$HOME/.mempalace/logs/index_$(date +%Y%m%d).log"

mkdir -p "$(dirname "$LOG_FILE")"

log() { echo "[$(date '+%H:%M:%S')] $1" | tee -a "$LOG_FILE"; }

log "开始扫描: $DOCS_DIR"

if command -v mempalace &>/dev/null; then
 mempalace mine "$DOCS_DIR" --limit 500 >> "$LOG_FILE" 2>&1
 log "MemPalace mine 完成"
else
 python3 << 'PYEOF'
import os, hashlib, time, requests, chromadb

DOCS_DIR = os.environ.get("DOCS_DIR", os.path.expanduser("~/notes"))
client = chromadb.PersistentClient(path=os.path.expanduser("~/.mempalace/palace"))
col = client.get_collection("mempalace_drawers")
existing_ids = set(col.get()["ids"]) if col.count() > 0 else set()

def embed(text):
 r = requests.post("http://localhost:11434/api/embeddings",
 json={"model": "qwen3-embedding", "prompt": text[:500]}, timeout=120)
 return r.json()["embedding"]

added = 0
for root, dirs, files in os.walk(DOCS_DIR):
 dirs[:] = [d for d in dirs if not d.startswith(".")]
 for f in files:
 if not f.endswith((".md", ".txt", ".py", ".yaml", ".json")):
 continue
 fpath = os.path.join(root, f)
 try:
 content = open(fpath, "r", errors="ignore").read()
 except:
 continue
 if len(content) < 50:
 continue

 chunks = [content[i:i+500] for i in range(0, len(content), 500)]
 for chunk in chunks:
 doc_id = hashlib.md5(chunk.encode()).hexdigest()[:16]
 if doc_id in existing_ids:
 continue

 try:
 vec = embed(chunk)
 col.add(ids=[doc_id], embeddings=[vec], documents=[chunk],
 metadatas=[{"source": fpath, "wing": "docs",
 "timestamp": time.strftime("%Y-%m-%dT%H:%M:%S")}])
 existing_ids.add(doc_id)
 added += 1
 except Exception as e:
 print(f" 错误 {fpath}: {e}")

print(f"新增 {added} 条，总计 {col.count()} 条")
PYEOF
 log "Python 扫描完成"
fi

if command -v mempalace &>/dev/null; then
 mempalace status 2>&1 | head -10 | tee -a "$LOG_FILE"
fi

1
2


chmod +x auto_index.sh
./auto_index.sh ~/notes

CPU 推理每条约 20 秒，100 个文件大约 30 分钟。有 GPU 会快很多。

第七步：定时自动更新（2分钟）

让知识库每天自动扫描新增文件：

1
2
3
4
5


# 编辑 crontab
crontab -e

# 添加这行：每天凌晨3点自动更新
0 3 * * * ~/auto_index.sh ~/notes >> ~/.mempalace/logs/cron.log 2>&1

或者用 MemPalace 自带的命令：

1

0 3 * * * mempalace mine ~/notes --limit 500 >> ~/.mempalace/logs/cron.log 2>&1

第八步：接入 AI 助手（可选）

如果你用 AI 助手框架，可以把 MemPalace 作为记忆后端：

1
2
3
4
5
6


# AI 助手框架配置文件
memory:
 memory_enabled: true
 provider: mempalace
 memory_char_limit: 2200
 flush_min_turns: 6

这样对话中产生的关键信息会自动存入知识库，下次对话时能通过语义搜索找回。

踩坑清单（必看）

坑	症状	解决方案
嵌入模型 API 字段错误	返回空向量，ChromaDB 报 IndexError	用 `prompt` 不用 `input`
换嵌入模型后维度冲突	报 dimension mismatch	必须删旧集合重建
ChromaDB 并发写损坏	数据库报 file is not a database	不同进程用不同目录
CPU 推理太慢	几百条数据跑几小时	批量跑用 batch_size=5
中文搜索命中率低	all-MiniLM-L6-v2 只有50%命中	换 Qwen3-Embedding
Ollama 服务没启动	嵌入请求超时	`ollama serve` 或设自启
切片太粗	搜索命中但信息不精确	500字左右切一片

成本核算

项目	数据
磁盘占用	Ollama 模型约4.7GB + ChromaDB 约10MB/千条
内存占用	Ollama 常驻约150MB（CPU模式）
API 费用	0（全部本地）
首次搭建时间	约30分钟
日常维护	零（定时任务自动跑）

我给AI建了个全自动知识库：每周自动从对话中提炼知识点

Tue, 26 May 2026 23:00:00 +0800

和AI聊了几百轮，发现最有价值的知识全散落在聊天记录里。下次遇到类似问题，还得重新问一遍。

这不是工具推荐，是我自己搭的一套系统。用了一年，从零长到23个知识页面，全是AI自己从对话里提炼出来的。

先说结论：把AI当知识管理员，比当聊天机器人有用得多。

一、为什么要自动化知识库

我每天和AI助手聊天，聊技术、聊工具、聊踩坑经验。

这些对话里藏着大量可复用的知识点：某个工具的配置方法、某个问题的解决方案、某个概念的清晰解释。

但问题是——它们全在聊天记录里。

想找的时候翻不到，找到了也不确定是最新的。

更关键的是，下次遇到类似问题，我又得重新描述一遍背景，重新问一遍。

所以我想要一个系统：自动扫描对话，自动提炼知识点，自动写入知识库。

不是什么Notion模板，不是Obsidian手动整理。

是真正的全自动——我正常聊天，知识库自动生长。

二、方案：LLM Wiki 规范 + 定时扫描

我的方案基于Karpathy提出的LLM Wiki规范。

核心思路：用Markdown文件存知识，用双向链接把知识点串成图谱，用AI定时扫描对话来增量更新。

整个知识库就是一个文件夹，长这样：

1
2
3
4
5
6
7
8
9


wiki/
 entities/ # 实体页（工具、人物、项目）
 concepts/ # 概念页（方法论、架构、工作流）
 comparisons/ # 对比页（方案选型）
 queries/ # 查询页（常见问题）
 raw/ # 原始素材（对话摘要）
 SCHEMA.md # 规范定义
 index.md # 全局索引
 log.md # 操作日志

每个页面都有统一的frontmatter格式：

1
2
3
4
5
6
7
8
9


---
title: 页面标题
created: 2026-05-14
updated: 2026-05-25
type: entity | concept | comparison | query
tags: [ai, tools, open-source]
sources: [raw/articles/xxx.md]
confidence: high | medium | low
---

用[[wikilinks]]语法在页面间建立双向链接。

比如opencode页面引用了understand-anything，后者又引用了hermes-agent。

这些链接自动形成知识图谱，不用手动维护。

三、扫描脚本：从对话中挖知识点

核心是一个Python脚本，每周自动扫描最近7天的AI对话记录。

它的逻辑很简单：

第一步：扫描会话数据库，找到最近有实质内容的对话。

筛选标准：消息数≥5条，标题非空，时间在7天内。

第二步：用关键词匹配分类。我定义了8个类别：

1
2


AI/模型 | 工具/Agent | 数据库 | OSINT
DevOps | 编程 | 写作 | 记忆/知识库

每条匹配规则是多个关键词用管道符连接。

比如"ai|llm|模型|训练|推理"都归到AI类。

第三步：过滤掉已有页面覆盖的内容，输出候选清单。

第四步：LLM Agent拿到候选清单，判断是否值得入库。

不是什么都记。有两个硬性门槛：

同一个知识点出现2次以上，或者来自1个高质量核心来源。

这样避免了把闲聊当知识的问题。

四、自动化流程：定时任务配置

我把扫描脚本配成了定时任务，每周日上午11点自动运行。

流程是四步：

扫描脚本输出候选 → LLM判断是否值得入库 → 创建或更新wiki页面 → 追加操作日志

目前已经跑了5轮自动入库，产生了这些内容：

实体页13个：hermes-agent、mempalace、opencode、obsidian、karpathy等。

概念页5个：双向链接、知识库工作流、五层记忆架构、MySQL大表DDL方案、被动验证方法论。

最有价值的是交叉引用。

opencode → understand-anything → hermes-agent → openclaw

这条引用链，把四个工具的定位和关系串了起来。

下次我需要对比它们，直接看知识库就行。

五、设计思考：为什么不用Notion

很多人会问：为什么不直接用Notion？或者Obsidian的插件？

三个原因：

第一，数据主权。我的知识库是本地Markdown文件，git管理。

不依赖任何云服务，不会因为某天服务下线就丢数据。

第二，增量构建。不是一次性搭好架子然后手动填充。

是每周自动从对话中生长，越用越丰富。

我正常使用AI，知识库自动变厚。

第三，AI做苦力。扫描、分类、提取、格式化，全部自动化。

我只做最终决策——这个东西值不值得记。

当然也有代价：没有Notion那么漂亮的界面，没有协作功能。

但知识库的本质是"能找到"，不是"好看"。

六、一个真实页面长什么样

拿hermes-agent这个实体页举例：

开头是frontmatter，包含标题、日期、类型、标签、来源、置信度。

然后是正文：概述、核心架构（配置层级表格）、Profile隔离系统、Skill系统、五层记忆架构、多平台网关。

最后是相关页面链接：nous-research、llm-wiki、obsidian、mempalace。

每个链接都能跳转，形成知识网络。

整个页面从创建到现在更新了3次，每次都是自动扫描触发的。

不是手动维护的"死"文档，而是跟着我的使用持续进化的"活"知识。

回看log.md的操作记录，5次自动入库覆盖了完全不同的领域：

从MySQL大表DDL方案到OSINT被动验证方法论。

这正是自动化的价值——它不会只记你"觉得重要"的东西。

而是记录你"实际在用"的东西。

如果你也在大量使用AI工具，强烈建议搭一个自己的知识库。

不需要复杂，一个文件夹 + 一个扫描脚本就够了。

关键不是工具选型，而是让知识自动沉淀。

手动整理的知识库，最后都会变成没人维护的死文档。

只有自动化的，才能活下来。

关注 varkm，一起学习，一起成长

下一篇讲怎么给这个知识库加上语义搜索，让它从"能找到"变成"能联想"

我给AI知识库加了"联想大脑"：从关键词搜索到语义理解

Tue, 26 May 2026 22:00:00 +0800

我的 wiki 里有 27 个页面，涵盖 Hermes、Obsidian、MySQL 等十几个主题。

搜"AI怎么记住之前的对话"——0 结果。

明明写了，为什么搜不到？

因为那篇 wiki 叫"五层记忆架构"，标题里没有"对话"“记住"这些词。

再来一个。搜"有没有能自动理解项目的工具”。

还是 0。wiki 里写的是"Understand Anything"，英文名。

第三个。搜"知识库怎么同步"。

0。wiki 里用的是"knowledge-base-workflow"。

三次搜索，三次翻车。不是 wiki 没写，是我用的词跟标题对不上。

现有 wiki-scan.py 用正则匹配：ai|llm|模型 这类关键词去打标签。

这种方案有个硬伤：同义词、近义词、描述性语句一律匹配不到。

关键词搜索只认字面，不懂意思。你脑子里想的跟标题不一样，就搜不到。

这是关键词搜索的天花板：它能找字，但不能找意思。

Embedding：给每段话算一个"语义坐标"

Embedding 模型的能力就一件事：把文本变成一组数字（向量）。

意思相近的文本，向量距离就近。意思无关的，距离远。

不需要懂线性代数。想象每段话都有自己的"语义指纹"。指纹越像，内容越相关。

专业说法叫"余弦相似度"——两个向量的夹角越小，内容越像。

但你不关心数学，只关心结果：输入一个问题，返回最相关的几段文字。

“AI怎么记住之前的对话"和"五层记忆架构"这两个短语，字面完全不同。

但语义指纹很接近——都在说"AI的记忆机制”。

这就是 Embedding 解决的核心问题：跨越字面，匹配语义。

“有没有能自动理解项目的工具"和"Understand Anything"也一样。

一个中文描述，一个英文专有名词，但语义空间里它们是邻居。

我用的本地模型是 qwen3-embedding，4.7GB，跑在 Ollama 上。

不调云 API，数据不出本机。对于个人知识库来说完全够用。

技术选型还有 nomic-embed-text 和 bge-m3，后面踩坑段会说差异。

动手：三步给 Wiki 接上向量引擎

向量数据库选 ChromaDB，轻量，Python 几行搞定。

版本是 1.5.8，pip install chromadb 直接装。

第一步：扫描 wiki 文件 + 分段切片

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


import glob

def load_wiki_chunks(wiki_dir, chunk_size=500):
 """扫描 wiki 目录，按固定字数切片"""
 chunks = []
 for f in glob.glob(f"{wiki_dir}/**/*.md", recursive=True):
 text = open(f, encoding="utf-8").read()
 # 按 chunk_size 字符切，保留来源信息
 for i in range(0, len(text), chunk_size):
 chunks.append({
 "text": text[i:i+chunk_size],
 "source": f,
 })
 return chunks

27 个 md 文件，500 字符切片，大约生成 80 个 chunk。

每个 chunk 都带着 source 元数据，搜索命中后可以直接跳到原文。

第二步：Embedding 向量化 + 存入 ChromaDB

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


import chromadb
from chromadb.utils.embedding_functions import (
 OllamaEmbeddingFunction,
)

ef = OllamaEmbeddingFunction(
 model_name="qwen3-embedding",
 url="http://localhost:11434/api/embed",
)

client = chromadb.PersistentClient(path="./wiki_chroma")
col = client.get_or_create_collection(
 "wiki",
 embedding_function=ef,
)

chunks = load_wiki_chunks("/root/wiki")
col.add(
 documents=[c["text"] for c in chunks],
 metadatas=[{"source": c["source"]} for c in chunks],
 ids=[f"chunk_{i}" for i in range(len(chunks))],
)

PersistentClient 把索引存到本地目录，重启不丢数据。

每个 chunk 附带 metadata 记录来源文件，方便溯源。

整个入库过程在我的机器上跑完不到 30 秒。

第三步：语义查询

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


results = col.query(
 query_texts=["AI怎么记住之前的对话"],
 n_results=3,
)
for doc, meta in zip(
 results["documents"][0],
 results["metadatas"][0],
):
 print(meta["source"], "→", doc[:80])
# 命中 memory-layered-architecture.md ✅

三步搞定。从安装到跑通，不超过 10 分钟。

效果对比：搜同一个问题

三组实测，关键词搜索 vs 语义搜索：

查询	关键词结果	语义搜索结果
“怎么防止模型记不住东西”	0 条	命中 memory-layered-architecture
“大表加字段怎么办”	命中 gh-ost	同时命中 gh-ost + mysql-big-table-ddl
“类似 Notion 的本地工具”	命中 obsidian	额外关联 bidirectional-links

第一组最典型。关键词完全匹配不到，语义搜索直接命中。

因为"防止记不住"和"五层记忆架构"在语义空间里是近邻。

第二组说明语义搜索不会丢掉关键词能找到的内容。

gh-ost 关键词能找到，语义也能找到，还额外关联了同主题的另一个页面。

这是语义搜索的加分项：不只补齐关键词的盲区，还能发现你可能没想到的关联。

第三组体现了"联想"能力。

用户想找的不只是工具名称，还有工具背后的核心理念（双向链接）。

Obsidian 的核心卖点就是 bidirectional-links，语义搜索自动把这个关联挖了出来。

从"能找到"到"能联想”，这是质变，不是量变。

让索引自动更新

wiki 内容会增长，索引也得跟上。用 cronjob 定时增量更新：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


existing = set(
 m["source"] for m in col.get()["metadatas"]
)
new_chunks = [
 c for c in load_wiki_chunks("/root/wiki")
 if c["source"] not in existing
]
if new_chunks:
 col.add(
 documents=[c["text"] for c in new_chunks],
 metadatas=[{"source": c["source"]} for c in new_chunks],
 ids=[
 f"chunk_{len(existing)+i}"
 for i in range(len(new_chunks))
 ],
 )
 print(f"新增 {len(new_chunks)} 个 chunk")

新页面入库时自动切片 + 向量化，零手动操作。

和 Hermes 的联动更进一层：搜索结果注入对话上下文。

Agent 回答问题时自动从 wiki 检索相关知识，不用每次手动查。

这个联动让知识库从"被动存档"变成"主动辅助"。

踩坑记录

三个坑，踩过了才知道。

模型选择：通用 embedding 模型对中文效果差。

nomic-embed-text 是好模型，但主要针对英文。中文查询经常跑偏。

搜"怎么防止模型记不住东西"，它返回的是跟"模型训练"相关的内容。

换成 qwen3-embedding 后，中文语义理解提升明显。

如果你的 wiki 主要是中文，选中文优化模型。这是效果差距最大的一个选择。

切片粒度：500 字符是经验值，不是万能解。

太粗（>1000）会丢细节。搜"五层记忆架构的第三层"可能匹配不到具体段落。

因为第三层的描述被淹没在一大段文字里，向量被平均掉了。

太细（<200）会丢上下文。返回的片段短到看不懂在说什么。

建议从 500 开始，根据实际搜索效果调整。

索引体积：27 个页面、80 个 chunk，ChromaDB 索引只有几 MB。

不需要百万级向量库的方案。个人知识库，ChromaDB 完全够用。

不要过度工程化，够用就好。

关键词搜索是"翻字典"——你得知道精确的词。

语义搜索是"问懂行的人"——描述个大概就能找到。

给知识库加上这层能力，从"能找到"到"能联想"，区别很大。

而这个升级，只需要一个 embedding 模型 + 一个向量数据库，本地就能跑。