Feature Request: 建议保留/恢复一个可迁移的开源 vector backend 支持（如 Qdrant）

[gjuoun]

Qdrant/OpenGauss 支持已在 PR #3872 "Remove qdrant and opengauss vector backends" 中被移除 ，该 PR 描述为空，未附带移除理由说明。）

我理解你们团队内部的考虑 ，但是这个决定基本上杀死了用户部署其他云的可能性，也减少了 OpenViking 本身的扩展性，这可能促使企业级用户寻找别的选项，毕竟每家都有自己业务绑定的云，不可能都用火山。

个人建议至少要维持一个可供移植的开源选项，如 Qdrant。

建议你们内部可以斟酌一下，毕竟刚开始维护一下也不是什么难事，这也适合和社区长期互动。多云和多 backend 的可迁移性需要社区一起来维护，这有益于 OpenViking 的长期成长。毕竟现在开源和闭源的记忆系统和文档检索工具也很多，想要大家开始用的话，社区口碑决定一切

我个人也用 OpenViking 搭建自己的本地知识库，本地的 OKF 文档结构搭配的很好，这是个很好的设计。

如果需要，个人也愿意一起参与共建第一版 working integration（Qdrant backend）

[qin-ctx]

感谢建议，移除的背景是这两个backend在合入后长时间没有继续维护适配，并和当前的使用方式有较大出入，综合考虑我们选择移除，我们欢迎开发者贡献并参与维护。

另外由于我们内部有一个话题群讨论，导致pr body没有写清楚，我们后续会严格检查pr描述，再次感谢建议

[qin-ctx]

可以参考 英伟达 cuvs的接入，目前会有开发者持续维护，比如性能优化或功能适配

[qin-ctx]

Qdrant/OpenGauss 支持已在 PR #3872 "Remove qdrant and opengauss vector backends" 中被移除 ，该 PR 描述为空，未附带移除理由说明。）

我理解你们团队内部的考虑 ，但是这个决定基本上杀死了用户部署其他云的可能性，也减少了 OpenViking 本身的扩展性，这可能促使企业级用户寻找别的选项，毕竟每家都有自己业务绑定的云，不可能都用火山。

个人建议至少要维持一个可供移植的开源选项，如 Qdrant。

建议你们内部可以斟酌一下，毕竟刚开始维护一下也不是什么难事，这也适合和社区长期互动。多云和多 backend 的可迁移性需要社区一起来维护，这有益于 OpenViking 的长期成长。毕竟现在开源和闭源的记忆系统和文档检索工具也很多，想要大家开始用的话，社区口碑决定一切

我个人也用 OpenViking 搭建自己的本地知识库，本地的 OKF 文档结构搭配的很好，这是个很好的设计。

如果需要，个人也愿意一起参与共建第一版 working integration（Qdrant backend）

欢迎参与开发贡献，对于backend的需求是适配上层ov的用法，比如 目录路径的过滤筛选，多tag枚举过滤等