知识库 · 产品说明

志睿源（重庆）软件有限公司 ｜ 更新于 2026-10-18 ｜ 状态：进行中

这是什么

把写过的文章，变成一棵能回答问题的树。

站里积累了几百篇技术文档、产品说明和每日记录。按目录翻能看，但遇到具体问题时仍然要一篇篇点开找。知识库做的是另一件事：把这些文章按标题结构挂成一棵树，再用问答的方式直接给答案，答案下面挂着它引用的原文。

不是搜索引擎的替代品，是「先给你答案，再让你查证」的那一层。

解决什么问题

三个具体场景：

1. 文档多了，目录就不够用。 六百篇以后，靠分类和翻页找东西的效率会掉得很厉害——你记得写过，但不记得在哪。
2. 同一个问题被反复问。 每次回答都要重新翻资料，答完就散，形成不了积累。
3. 历史记录的价值被浪费。 每天写的进展日志里有大量真实细节（怎么排的、为什么这么选），它们躺在时间线里，只有按日期找的人才会看到。

现在做到哪一步

三条链路已经上线：

• 问答：站内「问一问」页面，配合公众号菜单入口。答案逐字输出，检索到的原文作为参考块挂在下面。
• 文章管理：微信侧的管理页，作者自己维护自己的文章；同一份文件不会被全站共用一条记录。
• 知识树：十四个主题根，由程序按标题结构和内容自动挂载、定时维护；管理员只看不改——因为树是派生数据，人工改完最多一刻钟就会被自动逻辑重新理解一遍。

为什么不用向量库

这是这个项目里最反常识的一个决定。

常识做法是上向量库：文章切片、算向量、相似检索。问题在于成本——向量检索要内存、要算力，而这个系统跑在一台小内存服务器上，跑不起重排模型，也跑不起逐层调用大模型的方案（单次查询二十秒级，而且每次结果可能不同，没法复现）。

最后选的是另一种组合：

• 三通道粗排：全文检索 + 规则匹配 + 树裁剪，先用便宜的路径把候选缩小；
• 大模型只做精排：在几十个候选里挑出真正相关的几段，做它擅长的判断，不做它不擅长的穷举。

这套组合把一次问答的整体耗时压到了原来的十分之一左右。瓶颈本来就不在数据库（查询是毫秒级的），而在大模型的多次串行调用——把辅助任务换成轻量直答模型，比优化数据库有效得多。

规模

• 文章：九百多篇
• 知识树：十四个主题根，一万四千多个节点
• 章节摘要：六千四百多条，全量生成
• 挂树方式：规则占六成、大模型占三成半、人工只介入半成

两个设计上的取舍

权限不挂在树上。 树本身不带权限，用户查询时实时反查他能看哪些文章。这样树可以随便重建、重新挂载，权限不会跟着漂。

私密文章对检索不可见，必须是「查不到」而不是「不显示」。 敏感内容在入库那一步就清出索引，而不是查到之后再过滤——后者只要有一处漏了过滤，就等于没保护。

接下来

检索质量还在调。当前最明显的问题不是速度，是「概览类问题」和「深入类问题」用了同一套链路：问「最近一周都写了什么」和问「这件事具体怎么做的」，需要的答案形态完全不同。已经在做意图分流，还会继续做。

本文不涉及部署拓扑、账号体系与安全防护细节；涉及内部敏感内容的部分一律不展开。