市面上大多数「知识库问答」工具的套路都差不多把文档切块、算 embedding、塞进向量库提问时按相似度召回若干碎片喂给 LLM。KaaS 做了两个和主流不太一样的选择先编译再检索不直接对原始碎片做 RAG。先用 LLM 把散乱内容编译成一篇篇结构化的 Markdown Wiki 文章再在这上面做检索。不用 embedding检索阶段没有向量库、没有相似度计算。文章目录直接喂给 LLM让它像人翻目录一样选页、读全文。这篇讲整套系统的骨架和几个关键取舍单个机制的细节留给后续文章。解决什么问题KaaS 最初是我们内部的一个工具。知识散落在文档、会议、邮件里每当有人转岗或离开他积累的上下文就跟着走了接手的人要花几周重新拼凑。我们要的是让散乱输入沉淀成可读、可编辑、能长期演进的知识资产人能直接打开读的 Markdown而不是黑盒向量库。这也定了架构的走向编译质量第一检索只是编译产物之上的一层薄导航。带来了什么价值对使用者来说KaaS 的价值集中在几点散乱的笔记、文档、会议记录被编译成分类清晰、带溯源的 Markdown Wiki能长期积累复用。用自然语言提问拿到带引用的回答同一个问题不用反复被问第二遍。产出是纯 Markdown可读、可 git 版本管理、可手改。AI 生成、人工校准质量随用随涨。部署轻docker compose up或 CLI 一键启动默认 SQLite无向量库重依赖。通过 MCP 的ask工具Claude Code、Codex、openclaw 都能把这套 Wiki 当知识源直接查询。对接任意 OpenAI-compatible 端点可以全本地跑数据不出境。怎么做到的整体架构三层分工层技术职责Web UIReact Vite shadcn/uiChat / Submit / Wiki / Status 四个页面Go Backend标准库net/httpREST/SSE API、Worker Pool、任务队列、MCP 端点Python AI 引擎kb-aiuv编译流水线、LLM 迭代检索、Chat存储默认 SQLite零依赖go run即可跑存任务队列和编译状态检索走纯 LLM 迭代不依赖任何嵌入模型。检索不用 embedding让 LLM 直接翻目录这是 KaaS 和 naive RAG 的关键差别。编译阶段会维护一份master-index.md作为全量文章目录标题加摘要。检索时不做向量召回而是把这份目录连同问题一起喂给 LLM让它选出最相关的文章路径再把选中的文章整篇读进来做回答上下文。核心就三步storeKBStore(kb_dir,read_onlyTrue)catalogstore.existing_articles()# 1. 读 master-index 目录ifnotcatalog:return[]meta_by_path{a.path:aforaincatalog}selected_select_relevant(catalog,query,model,max_selectmax_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一个asktool 的 MCP 设计编译好的 Wiki 不只给自家 Web UI 用还能被任意支持 Model Context Protocol 的 agentClaude Code / Codex / openclaw当成可问答的知识源。KaaS 的 MCP server 只暴露一个ask工具mcp.tool()defask(query:str,paths:list[str]|NoneNone,model:str|NoneNone)-dict:它不重写检索逻辑而是直接复用 chat corerun_server_chat_http跑一遍 LLM 迭代检索再让 LLM 生成带内联[Title](path)引用的答案。MCP 的tools/call是请求/响应式的chat core 是流式的所以ask用一个 collector 把流事件收集成完整答案再返回。两种传输stdio默认agent 本地 spawnkb-ai mcp自包含和 streamable-http。远程场景由 Go 后端在/mcp原生服务保持:8080单一对外 origin。小结KaaS 的核心做法是把成本压在编译阶段编译时做足去噪、去重、结构化检索就能很轻不用 embedding只让 LLM 翻目录读全文。也因为产出是 Markdown它能用 git 管理、手动编辑、被任意 agent 当知识源接入。几个实现选择也遵循同一个思路能简单就不复杂。检索用 LLM 迭代翻目录没有额外堆一个向量库。后续每篇会钻进一个机制编译流水线的去噪去重已发布、为什么敢不用 embedding、Worker 并发与故障恢复、asktool 的 MCP 设计。代码都是公开的感兴趣可以直接翻 GitHub 仓库。致谢KaaS 的核心思路受 Andrej Karpathy 的 「LLM Wiki」gist 启发把知识编译成一个持续演进、相互链接的 Wiki随时间沉淀复用省掉每次提问都对原始数据重跑 RAG 的老路。感谢他把这个模式讲清楚了。项目地址https://github.com/bybit-exchange/kaas欢迎使用 KaaS 并 star 支持我们
