WeKnora向量数据库配置实战：从pgvector起步到Elasticsearch扩容的一套完整清单

WeKnora向量数据库配置实战：从pgvector起步到Elasticsearch扩容的一套完整清单

【免费下载链接】WeKnoraOpen-source LLM knowledge platform: turn raw documents into a queryable RAG, an autonomous reasoning agent, and a self-maintaining Wiki.项目地址: https://gitcode.com/GitHub_Trending/we/WeKnora

把几份 PDF、几十个网页丢进知识库，让检索结果又快又准——这是很多团队上手 WeKnora 的第一个目标。而真正决定这个目标能走多远的，往往是那个藏在后台、却决定了每一次问答响应速度的组件：向量数据库。

WeKnora 作为开源的 LLM 知识平台，把文档解析、向量化、混合检索和 Agent 推理串成了一条完整链路，其中向量库负责存储和召回"语义相近"的文本片段。好消息是，它支持 PostgreSQL（pgvector）、Elasticsearch、OpenSearch、Milvus、Qdrant、腾讯云 VectorDB 等多种后端，坏消息是——选择太多，反而不知道该从哪个开始。

这篇文章不打算罗列所有特性，而是用一套"从零到扩容"的实操清单，带你走一遍真实的选择与迁移过程。

一、先看清向量库在 WeKnora 里扮演什么角色

在动手配置之前，值得花一分钟理解向量库在整个系统中的位置。知识从上传到被问答命中，大致经过三段：

也就是说，向量库既是写入的终点，也是读取的起点。WeKnora 用环境变量RETRIEVE_DRIVER决定启动哪些检索引擎驱动，多个驱动用逗号分隔即可并行启用：

RETRIEVE_DRIVER=postgres,elasticsearch_v8

这意味着你完全可以让新旧引擎共存一段时间——这正是后面平滑迁移的基础。WeKnora 的整体架构可以在docs/images/architecture.png中看到，向量存储层正是与文档处理、RAG 引擎并列的核心模块。

二、先别急着选型，做一次"场景自检"

配置本身只需要几分钟，真正花时间的往往是"选错后端后返工"。所以在写任何配置之前，先用下面三个问题对号入座：

① 你的数据量级大概在哪？

• 十万级 chunk 以内：PostgreSQL + pgvector 完全够用，少一套组件就是少一份运维负担。
• 百万级往上，或预期一年内翻几倍：直接考虑 Elasticsearch 这类分布式方案。

② 团队更熟悉哪套技术栈？

• 以 SQL 为主、已经有 PostgreSQL 在跑业务库：从 pgvector 起步几乎零成本，向量表和业务表还能做关联查询。
• 已有 Elasticsearch 集群或专门的搜索团队：直接用它做向量库，关键词检索能力也是加分项。

③ 对检索时延和并发的要求高吗？

• 内部工具、原型验证、几十人使用：pgvector 的响应足够。
• 对外提供问答服务、高并发查询、需要复杂过滤聚合：Elasticsearch 更稳。

把这三点想清楚，选择范围其实就缩小了大半。WeKnora 在启动时默认使用postgres驱动，也就是说，如果你不刻意改动，系统会直接复用应用默认的 PostgreSQL 连接。

三、起步路线：用 pgvector 把第一个知识库跑起来

对于大多数团队，我的建议是从 PostgreSQL 开始，理由很简单：默认支持、配置最少、和现有业务数据同库管理。

第一步：确认环境变量

在.env或 docker-compose 中，保持以下设置即可让 WeKnora 使用 pgvector：

DB_DRIVER=postgres DB_HOST=your-postgres-host DB_PORT=5432 DB_USER=postgres DB_PASSWORD=your_password DB_NAME=weknora RETRIEVE_DRIVER=postgres

第二步：理解"默认连接"

PostgreSQL 驱动的特殊之处在于，它支持use_default_connection模式——直接复用应用的主数据库连接，连额外的连接串都不用配。只有在向量库和业务库分离时，才需要显式提供addr、username、password。

这套逻辑在初始化配置界面里也能直观看到：模型、Embedding 服务、检索存储都在同一个向导中完成，docs/images/config.png展示的就是这个初始化页面。

第三步：留意 embedding 维度

有一个新手最容易忽略的细节：pgvector 的索引和 embedding 模型的维度是绑定的。比如 bge-m3 这类 1024 维模型，WeKnora 会在启动时自动为其创建 HNSW 索引；如果你换了其他维度的模型，就需要按实际维度单独调整索引，否则检索性能会明显退化。

四、扩容路线：切换到 Elasticsearch 的三个动作

当数据量涨上来、pgvector 的检索时延开始爬坡时，就该考虑第二套方案了。Elasticsearch 在 WeKnora 中同时承担向量检索和关键词检索，一个引擎搞定两种召回方式。

动作一：注册驱动并配置连接

RETRIEVE_DRIVER=postgres,elasticsearch_v8 ELASTICSEARCH_ADDR=http://your-es-host:9200 ELASTICSEARCH_USERNAME=elastic ELASTICSEARCH_PASSWORD=your_password ELASTICSEARCH_INDEX=weknora_vectors

动作二：在界面里测试连通性

驱动注册后，你还可以在设置 → 向量库页面手动新增 Elasticsearch 引擎，填写地址和凭据后先点"测试连接"。这一步很值得做——它能提前暴露网络不通、认证失败、SSRF 白名单拦截等问题，而不会在正式建知识库时才报错。

动作三：把知识库绑定到新引擎

WeKnora 的知识库可以显式绑定某个向量存储。新建知识库时指定vector_store_id指向 Elasticsearch 存储，即可让新数据直接走新引擎，老知识库继续留在 pgvector 上。这个"按库绑定"的模型，是后续平滑迁移的关键设计。

五、迁移不是搬家，而是四步"切流"

很多人在迁移时犯的错，是把整个过程当成"导出 → 导入 → 删旧库"的一次性搬家。真正稳妥的做法是切流，分四步走：

第 1 步：影子写入。新起一个绑定 Elasticsearch 的知识库，把一小批样本文档传进去，先让新引擎"跑起来"。

第 2 步：双轨比对。新旧两套并行运行，用同一组测试问题分别查询，对比召回结果和响应耗时。这一阶段通常持续几天到一周，目的是积累足够的对照数据。

第 3 步：逐库切换。把核心知识库一个个解绑、重新绑定到 Elasticsearch。注意 WeKnora 有绑定保护机制：只要还有知识库绑定在某个向量存储上，删除该存储就会被拒绝，所以切换顺序应该是"先绑新的，再删旧的"。

第 4 步：验证收尾。全部切换后，用第 2 步的同一组问题做回归对比，确认准确率没有明显下降、时延符合预期，再考虑下线 pgvector 驱动。

六、三处最容易翻车的细节

迁移过程中，下面三个坑是我见过被踩得最多的，提前知道能省不少排查时间：

① 索引构建期的 IO 波动。大批量数据写入新引擎时，HNSW/ANN 索引构建会占额外的磁盘 IO，检索时延可能短暂升高。这属于正常现象，别急着回滚，等索引构建完成再评估。

② 凭据和索引字段创建后不可修改。WeKnora 的向量存储创建后，engine_type、连接配置、索引配置都是只读的，只能改显示名。写错地址的唯一出路是删掉重建，所以创建前务必先"测试连接"。

③ 删除有保护，解绑要先行。只要还有活跃知识库绑定在存储上，删除请求就会返回 400，错误信息里会明确告诉你还剩几个知识库需要解绑。这虽然多了一步操作，但能防止误删导致线上检索大面积失效。

七、迁移是否成功？用三个指标说话

最后，用一套可量化的标准来收尾，而不是凭感觉判断"好像变快了"：

记住一个原则：向量数据库的选型从来不是一锤定音。数据在增长，团队在变化，今天用 pgvector 起步、明年切到 Elasticsearch，甚至同时挂多个引擎做混合检索，都是被 WeKnora 明确支持的路。把配置能力握在手里，比纠结"哪个最好"重要得多。

如果你的场景比这更复杂——比如要接入 Milvus、OpenSearch 或腾讯云 VectorDB，实现思路完全一致：注册驱动、配置连接、测试连通、绑定知识库。这套清单，够你走完从第一次配置到平滑扩容的全过程了。

【免费下载链接】WeKnoraOpen-source LLM knowledge platform: turn raw documents into a queryable RAG, an autonomous reasoning agent, and a self-maintaining Wiki.项目地址: https://gitcode.com/GitHub_Trending/we/WeKnora