ARTICLE · 1296494
一堆 Office 文件,怎么变成能查的本地知识库?我做了个开源技能自建知识库 skill v4.0 已发布
一堆 Office 文件,怎么变成能查的本地知识库?我做了个开源技能自建知识库 skill v4.0 已发布仓库址: https://github.com/furoute/workshop/tree/main/skills/self-hosted-kb 配套技能：Everything 文件检索：https://github.com/furoute/workshop/tree/main/skills/everything-http-search 先说问题手里攒了几十 GB 的 Office/PDF：方案、合同、通知书、月报……想找个东西，只能靠文件名和记忆。文件名起得再规范，也回答不了"那个项目的中标金额是多少""XX 方案里怎么处理运维"这种问题。市面上的知识库方案要么上云（数据得交出去），要么要搭一堆服务。我要的东西很小：文件留在自己硬盘上，查得到原文、点得开原件，问问题时模型能带着出处回答。就这么点需求，愣是得自己搭一条链路。所以做了个 skill：自建知识库（self-hosted-kb），一次完整实践记录，MIT 开源。不是产品，是"照着做就能跑通"的工作手册。链路：七步 + 双路检索核心一句话：文件原位只读，索引和向量另起一套，查的时候双路召回再融合。七步流程（只读在前，动手在后）：全量探针（只读）：清单 + 魔数嗅探，四类分诊（正常 / 格式伪装 / 损坏 / 加密占用）SHA-256 去重（只读）：精确重复只认哈希，同名同大小都不算分层抽样试读（只读）：按目录 × 年代 × 大小抽 400–500 个，试读前后全量重算 SHA 必须 0 变化——证明自己没改文件自动分诊三堆（只标注）：有用 / 垃圾 / 待定；待定按"文件族"聚合，几万行没人看得下去批量裁决（只标注）：28 条规则，每族给终态建实体卡：五类实体、十五个 YAML 字段 + 九段正文；证据分级不能抬、金额口径写死呈现层（可选）：Obsidian 里 index + 属性视图 + 问答页，给人看检索层两条腿：FTS5（关键词）：型号、编号、金额、日期，字面精确向量（语义）："这个事怎么办"这类模糊问法RRF 按名次融合：两路都靠前的最靠前规模实测：最大一档 37,782 个文件 / 27.7 GB → 清点去重后 2,066 个 / 10.7 GB；40 万个块、950 MB 索引。调优：库里有，模型说没有最值钱的一段：有次用户问个东西，明明录进过库，模型答"没找到"，但直接查 FTS5，10 条精准命中。不是没数据，是被埋了。根因两个：
FTS5 默认 trigram 分词，中文两字词全废。 trigram 按 3 字符滑窗建索引，中文"合同""预算"这种两字词根本凑不出完整三元组——实测 11 个两字词查询，11 个全 0 命中。改法：jieba 切词 + unicode61，入库前先分词再喂给 FTS5。教训：中文语料上分词策略比索引结构重要一个数量级。 一份超大 Excel 顶 130 份 PDF。 某份表抽出正文切出 5 万块，全库平均每份文档才 365 字/块——不管问什么，这份表的块都在候选池里，把该出现的文档挤到后面。这是"检索污染"不是"检索不准"，修的方向不是调分，是让大文档别霸榜。五项修法：块数降权、表格密度降权、每文档上限 20、目录路径证据、词项 60 压到 12。 修前后：延迟 96–203 ms → 24–96 ms（反快了，候选池从几千条缩到几百条）；三组原先答不上的问题全部命中正确文档。 心法一句话：不是"让对的答案分数更高"，而是"让错的答案没机会进候选池"。 Everything：找文件是另一层，别跟检索混了 问"有没有 X 这个文件"根本不需要向量化——Everything 读 NTFS 主文件表，几十万文件毫秒级定位，零 token。顺序应该是： 问"有没有 X" → Everything（毫秒、零成本） 问"X 讲了什么" → 知识库检索（切块 + 向量） 80% 的"找文件"场景根本不需要向量化。配套 skill 已独立发布：走 HTTP API，一行 curl 就能查；开机自启 + 静默托盘 + HTTP 常开一次配好。注意：Windows + NTFS 方案，Linux/macOS 那边用 grep/find。 在线 vs 本地模型：瓶颈在检索层，不在模型层 同一条检索链路换两种模型作答：云端 DeepSeek API vs 本地 Ollama qwen3.5:9b（RTX 4060 Laptop，全程拔网线）。 速度：云端 0.7–1.1 s 稳；本地 0.9–4.1 s 抖动大 质量：理解、总结、读方案基本打平；但本地小模型两个硬伤：多位数乘法会算错、表格挤成一行后状态张冠李戴；信息不足时云端更倾向说"不确定"，本地更倾向脑补 关键发现：检索没给对材料的题两边都答不出来，换更大的模型也没用——变不出没进候选池的文档。优化方向是召回质量，不是换更大模型 一个实操坑：qwen3.5 默认开 thinking，思维链把 num_predict 吃满，answer 是空的，必须显式关掉 数据边界（诚实话） 准确口径：数据不整体外流，但查询时命中的片段和问题会出网。 不出网：原始语料、40 万个块、950 MB 索引、向量——全部在自己硬盘上 会出网：查询时被选中的 top-k 片段 + 用户提的问题，送云端模型做理解和组织 查技术手册无所谓；查客户名单、报价、合同条款，那几段确实出网了——敏感语料要不要进库得先判断 要彻底不出网，唯一的路是本地模型（慢 5–10 倍、中文弱一档） 怎么用 这不是 SaaS，没有一键安装包。正确用法：把 skill 文件夹交给你的 agent，让它照着 SKILL.md 做： SKILL.md 是写给智能体照着做的工作手册，不是给人看的说明书；配套脚本、references、架构图都在目录里。另有 Everything 技能： 诚实边界 一次完整实践记录，不是通用产品；换一批语料就得重新调参 Windows + NTFS 是 Everything 那层的前提；老 Office 格式（.doc/.xls/.ppt 等）当前脚本不尝试解析，只查得到文件名 动手能力是前置条件：要自己跑脚本、建索引、排障 示例数据已脱敏，个人配置请自行替换 最后 做这个的初衷很简单：文件是自己的，检索也该是自己的。云端知识库再方便，数据出去了就是出去了；本地这条链路跑通之后，查得到、点得开、说得出处，就够了。 欢迎试用，有问题直接去仓库提 issue。 顺带一提：这套实践不是一个人闷头做的，是六个 AI agent 跨三台机器协作跑出来的——分工、审稿、合入走的都是 ACP-lite（Agent Connect Personal），一个文件信箱式的开源互联方案：
