长期知识库怎么维护？WeKnora 维护机制拆解与Milvus 接入实测

WeKnora 的长期知识库维护机制

WeKnora 有三大主要能力：RAG 问答、ReAct Agent 和 Wiki。单看问答和 Agent，和现在不少开源知识库框架大同小异。它比较特别的一点，是入库后的知识并不是只读的。

文档导入以后，参与检索的 chunk 可以直接编辑，也可以查看历史版本、做 diff 和回滚。修改 chunk 后，WeKnora 会重新建立对应的索引。

这是在维护长期运行知识库时比较重要的一个设计：生产里“常会出现某个段落过期了、解析结果切错了、一个 chunk 里混入了错误信息。重新跑整个文档当然可以，但如果真正需要修的只是其中一小段，更合理的操作是定位、修改、重新索引，而且要知道之前是什么。

Wiki 模式则会从原始文档生成互相链接的 Markdown 页面和知识图谱。页面同样保留 revision history，支持行级 diff、手动修改和回滚。

这样一来，自动生成的内容有问题时，可以直接定位到具体页面或 chunk 修改；人工修订以后，原来的版本仍然保留。

多人维护时，WeKnora 还提供 Workspace RBAC、异步任务和 Langfuse tracing，把权限、后台任务和调用追踪也放进了同一套系统。这些都是一个作为企业级产品的关键设计。

向量数据库切换时机与评估指标

长期维护解决之后，第二个问题是底层数据库的选型如何跟随业务发展周期做更新？

WeKnora 没有把向量存储写死。默认环境配置是 RETRIEVE_DRIVER=postgres，同时支持 Milvus、Elasticsearch、OpenSearch、Qdrant、Weaviate、Doris、Tencent VectorDB 等后端。每家在源码 retriever/ 下有独立实现，含仓储、过滤、测试，是代码级实现。

其中，Milvus 从 WeKnora 0.3.x 开始已经进入正式支持列表。

有多个后端可选的好处，是不需要在项目一开始就把检索架构定死，给了我们很大的架构灵活性。

如果团队已经熟悉 PostgreSQL 或 Elasticsearch，前期完全可以继续沿用现有基础设施。后面数据和请求量上来，再看现有后端是否还能满足要求。

通常来说，等到知识库从几万块涨到百万级，pgvector 单机的检索延迟和写入吞吐会扛不住，这时候就需要分布式扩展、独立扩缩容、资源隔离，Milvus会是一个比较好的选择。

实践中，我们可以重点观察下面几项指标：

• p95 / p99 检索延迟是否已经接近业务 SLA；
• 持续导入是否明显影响在线查询；
• 索引构建和重建窗口是否还能接受；
• 向量检索是否需要和事务数据库做资源隔离；
• 检索服务是否需要独立扩缩容。

WeKnora 切换 Milvus 实测四类卡点

这次测试主要确认两件事：第一，WeKnora 所谓的 vector store 可插拔表现究竟如何；第二，把一个正常运行的 WeKnora 接到外部 Milvus，需要处理哪些额外状态。

这次测试环境：macOS（Apple Silicon）+ Docker，外部 Milvus 2.6.x，本机 Ollama 跑 qwen3.5:4b 和 nomic-embed-text（768 维）。

核心配置如下（SSRF_WHITELIST_EXTRA 和这次 Docker 容器访问宿主机 Milvus 的网络拓扑有关，其他环境不一定需要相同配置。）：

RETRIEVE_DRIVER=milvus
MILVUS_ADDRESS=127.0.0.1:19530
MILVUS_METRIC_TYPE=IP
SSRF_WHITELIST_EXTRA=...,127.0.0.1:19530,host.docker.internal

配置本身很简单。但为了确认不是连上 Milvus 就算成功，我继续跑了完整全流程：先导入文档，确认向量确实写进 Milvus；再发起问答，看检索和引用是不是从这批数据返回；最后重传、删除文档，检查旧 chunk 会不会继续被搜到。

沿着这条链路跑下来，一共遇到四个卡点。

第一，换 embedding 维度，WeKnora 会直接换一套 collection

我用的是 768 维 nomic-embed-text，WeKnora 最后创建出来的 collection 是：

weknora_embeddings_768

这是 WeKnora Milvus adapter 的设计：它会把 embedding 维度放进 collection 名。

这就导致，如果后面换成另一个维度的 embedding model，已有知识需要重新生成 embedding，对应的 Milvus collection 也会跟着变化，并重建索引。

第二，文档进入处理流程，不代表索引已经可以查询

第一次并发导入文档后，我马上开始查询，其中一部分请求报错：

there is no vector index on field: [content_sparse]

WeKnora 接 Milvus 时同时会建 dense 和 sparse retrieval 所需要的字段和索引。这次测试里，查询已经发出来了，但 content_sparse 的 index 还没有准备好。

等文档状态变成 completed 后再查，检索恢复正常。

这是WeKnora 和 Milvus 初始化阶段的时序问题。在使用时要注意，批量导入以后，要等文档处理完成再开始查，不要文件刚上传就马上发查询。

第三，LLM推理流假超时

问答测试时，Milvus 已经正常返回了检索结果，但页面一直没有最终答案，看起来像请求超时。最后发现问题来自于 qwen3.5:4b 的 thinking。它会先生成比较多 thinking token，客户端还在等最终输出，所以页面看起来像卡住了。

对应配置在 config.yaml：

conversation:
  summary:
    thinking: false

关掉以后，问答正常返回。

第四，删除文件后，旧 chunk 不会同步退出检索

我修改模型配置后重新上传了测试文档，并删除旧版本。删除操作完成以后马上再查，旧 chunk 还会短暂出现在结果里。过一段时间再查，旧数据才消失。

这里可能至少有两层状态：WeKnora 自己要处理文档删除、chunk 清理和重新索引；Milvus 这边，刚发生的写入和删除什么时候能被查询看到，又和 consistency 设置有关，不同设置会影响最新数据对查询的可见性。

如果业务要求“删完马上不能搜到”，就要针对这两项做完整的优化。

最终，10 份测试文档全部写入 Milvus 的 768 维 collection。文档写入、向量检索、答案生成和 citation 都能正常完成，引用可以回到对应的原始文档。

多向量库并行支持与渐进式迁移

前面验证的是把一个知识库放到 Milvus 后，整条 RAG 链路能不能正常工作。

已经在生产运行的系统还会遇到另一个问题：如果现在已经有很多知识库放在 PostgreSQL 上，要不要一次全部搬到 Milvus？

逐步迁移可能是一个更稳妥的方案。

WeKnora 支持把 VectorStore 作为独立资源管理。创建知识库时可以指定 vector_store_id，不同知识库可以绑定不同的向量存储；一次查询覆盖多个知识库时，再分别到对应的 store 检索并合并结果。

这意味着 PostgreSQL 和 Milvus 可以在同一个 WeKnora 部署中并存。

例如，原来的 KB A、B、C 可以继续使用 PostgreSQL，新建的 KB D、E 则显式绑定到 Milvus。先用少量真实知识库把导入、索引、检索、引用、内容更新和删除等完整链路跑通，再扩大 Milvus 的使用范围。

JOTO 企业落地观察

• 企业部署向量数据库时，若初期选用 pgvector，后期需升级为 Milvus 等分布式方案，WeKnora 的 VectorStore 插拔设计可避免架构重写，但需关注 embedding 维度变更触发的 collection 重建成本，这对知识库版本管理和灰度发布提出明确要求。
• 这类系统的取舍在于：是否接受「chunk 级别可编辑」带来的元数据复杂度。WeKnora 将 chunk 与 Wiki 页面均纳入 revision history，虽提升了长期维护能力，但也意味着企业需配套建设相应的变更审批、审计与回滚 SOP，不能仅依赖技术自动性。
• RAG 知识工程中，多向量库并行能力并非单纯为扩容而设，更是支撑知识分域治理的关键——例如合规敏感知识走 Milvus（强一致性+资源隔离），常规知识留 pgvector（轻量+事务耦合），WeKnora 的 vector_store_id 绑定机制为此类混合策略提供了落地基础。
• AI 安全治理视角下，WeKnora 的 chunk 回滚与 Wiki 行级 diff 构成了事实上的知识溯源链。当发生误检或幻觉引用时，企业可快速定位到具体 chunk 版本及修改人，但该能力的有效性高度依赖于团队是否严格执行编辑留痕规范，而非仅靠工具支持。