先编译再检索：一个不用 embedding 的开源知识库

市面上大多数「知识库问答」工具的套路都差不多：把文档切块、算 embedding 、塞进向量库，提问时按相似度召回若干碎片喂给 LLM 。KaaS 做了两个和主流不太一样的选择：

1. 先编译再检索：不直接对原始碎片做 RAG 。先用 LLM 把散乱内容编译成一篇篇结构化的 Markdown Wiki 文章，再在这上面做检索。


2. 不用 embedding：检索阶段没有向量库、没有相似度计算。文章目录直接喂给 LLM ，让它像人翻目录一样选页、读全文。

这篇讲整套系统的骨架和几个关键取舍，单个机制的细节留给后续文章。

解决什么问题

KaaS 最初是我们内部的一个工具。知识散落在文档、会议、邮件里，每当有人转岗或离开，他积累的上下文就跟着走了，接手的人要花几周重新拼凑。

我们要的是让散乱输入沉淀成可读、可编辑、能长期演进的知识资产：人能直接打开读的 Markdown ，而不是黑盒向量库。这也定了架构的走向：编译质量第一，检索只是编译产物之上的一层薄导航。

带来了什么价值

对使用者来说，KaaS 的价值集中在几点：

• 散乱的笔记、文档、会议记录被编译成分类清晰、带溯源的 Markdown Wiki ，能长期积累复用。


• 用自然语言提问，拿到带引用的回答，同一个问题不用反复被问第二遍。


• 产出是纯 Markdown：可读、可 git 版本管理、可手改。AI 生成、人工校准，质量随用随涨。


• 部署轻，docker compose up 或 CLI 一键启动，默认 SQLite ，无向量库重依赖。


• 通过 MCP 的 ask 工具，Claude Code 、Codex 、openclaw 都能把这套 Wiki 当知识源直接查询。


• 对接任意 OpenAI-compatible 端点，可以全本地跑，数据不出境。

怎么做到的

整体架构

三层分工：

存储默认 SQLite （零依赖，go run 即可跑），存任务队列和编译状态；检索走纯 LLM 迭代，不依赖任何嵌入模型。

检索不用 embedding ，让 LLM 直接翻目录

这是 KaaS 和 naive RAG 的关键差别。编译阶段会维护一份 master-index.md 作为全量文章目录（标题加摘要）。检索时不做向量召回，而是把这份目录连同问题一起喂给 LLM ，让它选出最相关的文章路径，再把选中的文章整篇读进来做回答上下文。

核心就三步：

store = KBStore(kb_dir, read_only=True)

catalog = store.existing_articles()          # 1. 读 master-index 目录

if not catalog:

    return []

meta_by_path = {a.path: a for a in catalog}

selected = _select_relevant(catalog, query, model, max_select=max_articles)  # 2. LLM 选页

return _read_selected(store, meta_by_path, selected)                         # 3. 读全文

LLM 选页就是一段结构化 prompt ，让模型从目录里挑路径并返回 {"paths": [...]}；选中的页整篇读入，仅按 MAX_ARTICLE_CHARS = 12_000 截断以控制 prompt 预算。全流程没有一处 import 向量库或 embedding 模型。

这套方案能成立，是因为编译已经把噪声去掉了：进入检索的是结构化、去重后的文章，目录里的标题和摘要足以让 LLM 导航。好处是部署轻，不需要 chromadb / sentence-transformers / pytorch 这些重依赖，镜像小、无需预下载模型。代价是：只靠目录摘要导航，一篇文章如果只在正文深处才和问题相关、标题摘要里没体现，就可能选不到。这个「 body-depth 召回」缺口是否值得引入向量检索，留待后续按价值评估。

编译流水线：Extract → Classify → Write → Index

检索能这么轻，前提是编译够重。KaaS 的编译是一条 4 阶段流水线：

• Extract：从原始文本提取概念、实体、决策、行动项


• Classify：把提取结果映射到已有文章，或标记为新建


• Write：创建/合并 Markdown 文章


• Index：更新 Markdown 索引（ master-index / topic-index ）

服务端把 Classify→Write→Index 编排成一条带并发和 SSE 进度的流水线。工程难点在去噪（单个 LLM 调用卡死不能拖垮整批）和去重（并行分组不能各自「发明」同名文章），这两点在系列首篇《 4 阶段编译流水线：先编译再检索，如何去噪去重》里已经展开，这里不再重复。

接进任意 AI agent：一个 ask tool 的 MCP 设计

编译好的 Wiki 不只给自家 Web UI 用，还能被任意支持 Model Context Protocol 的 agent （ Claude Code / Codex / openclaw ）当成可问答的知识源。KaaS 的 MCP server 只暴露一个 ask 工具：

@mcp.tool()

def ask(query: str, paths: list[str] | None = None, model: str | None = None) -> dict:

它不重写检索逻辑，而是直接复用 chat core （run_server_chat_http）：跑一遍 LLM 迭代检索，再让 LLM 生成带内联 [Title](path) 引用的答案。MCP 的 tools/call 是请求/响应式的，chat core 是流式的，所以 ask 用一个 collector 把流事件收集成完整答案再返回。

两种传输：stdio （默认，agent 本地 spawn kb-ai mcp，自包含）和 streamable-http 。远程场景由 Go 后端在 /mcp 原生服务，保持 :8080 单一对外 origin 。

小结

KaaS 的核心做法是把成本压在编译阶段：编译时做足去噪、去重、结构化，检索就能很轻，不用 embedding ，只让 LLM 翻目录读全文。也因为产出是 Markdown ，它能用 git 管理、手动编辑、被任意 agent 当知识源接入。

几个实现选择也遵循同一个思路：能简单就不复杂。检索用 LLM 迭代翻目录，没有额外堆一个向量库。

后续每篇会钻进一个机制：编译流水线的去噪去重（已发布）、为什么敢不用 embedding 、Worker 并发与故障恢复、ask tool 的 MCP 设计。代码都是公开的，感兴趣可以直接翻 GitHub 仓库。

致谢

KaaS 的核心思路受 Andrej Karpathy 的 「 LLM Wiki 」 gist 启发：把知识编译成一个持续演进、相互链接的 Wiki ，随时间沉淀复用，省掉每次提问都对原始数据重跑 RAG 的老路。感谢他把这个模式讲清楚了。

项目地址

https://github.com/bybit-exchange/kaas

欢迎使用 KaaS 并 star 支持我们！