知识库与记忆

大部分「知识库」失败，不是因为模型不够聪明，而是因为它压根没读到该读的那几段。 把整本手册塞进对话框，模型会在噪声里挑最像的一段编一个答案；把它切成块、算成向量、按问题捞回来， 它才可能指着原文说「第三章第十条是这么写的」。

这一页讲清两件事：向量检索是怎么工作的，以及记忆为什么要分层。 不讲概念，只讲我们自己在跑的那套东西。

计小规 · 已交付论衡 · 内测本站同源

一、差别不在模型，在「检索」

同样一个问题，两种做法：

做法	实际发生的事	结果
把整本手册贴给模型	上下文里 90% 是无关章节，模型在噪声里找「最像」的段落	答得像，但找不到原文；追问一句就露馅
先检索、再生成	只把最相关的 6 段交给模型，每段带编号和出处	答案短、有据、点一下回到原文那一节

差别不在换哪个大模型，而在有没有一层检索。这层检索就是通常说的 RAG（Retrieval-Augmented Generation，检索增强生成）。

二、它到底怎么跑：四步

01

切块

把文档按标题和段落切成 300–700 字的块。切太碎丢上下文，切太整又稀释相似度。条款类文档按「第X章 / 第X条」切，引用才能精确到条款。

02

向量化

每块算成一串数字（本文用 bge-m3，1024 维）。意思相近的句子，数字也相近——这样「报销怎么走」能捞到写着「费用核销流程」的那一段。

03

检索

问题同样算成向量，和库里每一块比相似度，取最高的几块。中文再加一路「二元词命中」加权——纯向量对型号、条款号、金额不敏感，双路才稳。

04

生成

把这几块连同编号交给大模型，要求「只依据资料、每条结论带编号」。没检索到就明说没有，不拿常识兜。

一句实话：这四步里，第 1 步和第 3 步决定成败，第 4 步只是把话说顺。换更贵的大模型，救不了一个切坏的库。

三、记忆为什么要分层

「记忆」不是把所有聊天记录堆在一个库里。真那么做，检索会越来越慢、越来越脏，最后答出来的东西自相矛盾。

业界比较稳的分法是四层（来自 CoALA 认知架构，Letta / Mem0 都在用）：

层	装什么	活多久	我们的落点
工作记忆	当前这一轮的上下文窗口	一次对话	最近 4 轮对话 + 本轮检索到的资料
情景记忆	发生过什么：谁在什么时候问了什么	数周到数月	会话与消息表，按会话隔离，可删
语义记忆	稳定的事实与偏好：身份、关注点、口径	长期	用户私有记忆，向量检索，本人可见可删
程序记忆	该怎么做事：话术规则、回答边界	版本化	系统提示词，随版本发布，不随对话漂移

再加上一层公共知识（单位的制度、论文、官网内容），它不是"某个人的记忆"，但对所有提问者都成立——这一层就是上面第一、二节讲的检索库。

为什么必须分开存： 四层的生命周期、存储方式、检索方式都不一样。混在一起，就会出现「把上个月的一句玩笑当成永久偏好」这类错误——而且它会一直影响以后的每一次回答。

还有两件容易被忽略的事

• 遗忘是功能，不是缺陷。 只增不删的记忆会越来越慢、越来越矛盾。过期的事实要降权，被新事实推翻的旧结论要失效，而不是堆着。
• 写入要经过授权。 记忆里存的是用户说过的话，属于个人信息。我们的口径是：本人可见、可增、可删、可清空；后台只看聚合统计，不看对话正文。

四、选型：为什么不用专门的向量数据库

2026 年能选的开源方案不少，但「好」不等于「适合你这台机器」。我们的实际约束是：一台 2 核 2G 的服务器，已经有 PostgreSQL，语料不到一千块。

方案	定位	最低资源	向量存储	我们的判断
PostgreSQL + 向量列（本页方案）	复用现有库	沿用现有 PG	数组列 + 应用层余弦	选它：零新增容器、零新增备份、事务与权限同一套
FastGPT	中文知识库问答	2C4G	pgvector + MongoDB	交付给客户的「中型」方案：界面化切片、可视化调试
RAGFlow	复杂文档解析	4C8G 起（实际 16G 更稳）	Elasticsearch / Infinity	遇到扫描件、复杂表格时的前置解析器，不做主库
Dify	LLM 应用平台	2C4G 起（推荐 8G）	Qdrant / Weaviate / pgvector	能力最全但容器多，小机器容易 OOM
AnythingLLM	私有知识库	2G	LanceDB / Chroma	桌面端开箱即用，适合个人，不适合对外服务
Milvus / Qdrant	专用向量库	独立服务	自建索引	十万块以上再考虑；现在上是给自己找运维

三条理由，说得再直白一点：

1. 量不够大。 官网 85 篇正文切完是 616 块，一次全量比对在 Node 里是毫秒级。上专用向量库，等于给自行车装飞机引擎。
2. 栈已经在了。 检索要的是事务、权限、备份、审计，这些 PostgreSQL 全都现成。多引一个数据库，就多一套备份、多一个会挂的服务、多一个半夜要起来看的告警。
3. 能平滑长大。 语料涨到十万块级别，把 Postgres 镜像换成带 pgvector 的官方镜像、加一个 HNSW 索引即可，pgdata 卷兼容，应用接口不用改。

什么时候该换：单次检索超过 200ms、或语料过 10 万块、或需要多路召回 + 重排。到那时候再换，是升级；现在换，是负债。

五、现在在跑的

库	规模	状态
官网自身	85 篇正文 / 616 块，向量检索 + 出处回链	分块与索引脚本就绪；接上网关即可开放问答
计小规 · 规章制度	446 篇制度 / 3509 条知识块 / 30 个部门	已交付上线（江苏第二师范学院办事大厅）
论衡 · 论文库	多格式拖入、按章节感知分块、出处到页码	内测中

三个库共用同一套底座：分块、向量化、双路检索、出处回链、权限与审计。差异是配置，不是代码。

六、三种交付形态

形态	适合	交什么
轻量内嵌	官网 / 内部系统里加一个问答入口，语料几千块	一个检索服务 + 前端悬浮窗，复用你现有的数据库
中型平台	单位要自己传文档、自己切片、自己调	FastGPT 一套（pgvector），配好切片策略与话术
重型解析	大量扫描件、复杂表格、影印 PDF	RAGFlow 做前置解析，高质量切片导入上面两种

我们不建议一上来就上重型：先把「答案有没有出处」这件事做对，再谈解析多复杂的版式。

七、常见问题

会不会编？ 不按「大模型常识」作答：系统提示词要求只依据检索到的原文，每条结论带来源编号；库里没有就回「未找到相关内容」并指路人工。检索不到时不调用模型——省一次费用，也断掉它自由发挥的机会。

数据能不能不出内网？ 可以。向量检索是本地推理（bge-m3 量化后约 24MB，无需 API Key）；生成模型可切到本地部署，整条链路不依赖公网。政务、文博场景常按这种方式落地。

文件更新了怎么办？ 重新索引即可。内容指纹没变的文档直接跳过，不重复花向量费用；旧块先删后写，不会留下对不上的孤儿段落。

谁能看到我的提问？ 会话按账号（或匿名会话键）隔离，跨账号不可见；后台只看标题与聚合统计，不看对话正文。记忆本人可删、可清空。

上线要多久？ 有现成语料的情况下，导入 + 建索引约 2 分钟（视体量），当天可交付。

想把它用在你的单位？

• 交付咨询：联系我们——说清行业与语料体量，我们回可行性与排期。
• 看现成产品：知识库问答——计小规与论衡的交付口径。
• 合作模式：合作体系——代理、分销与联合交付。

口径说明：本页规模数字来自本站索引脚本实测（2026-11-09）与计小规线上公开接口；不写形容词，不承诺未交付的能力。