Repository navigation
ES milvus能否设置成可选组件 #1
Description
- ES milvus能否设置成可选组件
- 不同类型的记忆能否配置哪些提取或不提取
Activity
ES 既可以做关键词检索，又可以进行向量化检索。为啥不都用ES。
ES 既可以做关键词检索，又可以进行向量化检索。为啥不都用ES。
ES并不是个专业的向量数据库，是基于倒排索引机制上构建的向量搜索能力，性能、灵活性都不如milvus。这个项目也没有历史包袱，所以选用性能最好的
相对应的 舍 就是需要存储2遍对吧
相对应的 舍 就是需要存储2遍对吧
向量化后的数据不论用ES还是milvus都得存，但有些公共数据是需要存储2遍。但存储效率不是当前技术选型的首要考虑
我有另一个方面的想法。就是从membase，然后构造多层次的mem系统，整个token开销，会很高。尤其构造多层的记忆系统，进行多type管理。
就是这个成本对于普通的游客用户来说是不是太大了，哪怕使用便宜的模型
或许感觉mem也可以用于 某个领域持续性的追踪，这种tob的可能 整个迁移逻辑我个人感觉挺平滑
我有另一个方面的想法。就是从membase，然后构造多层次的mem系统，整个token开销，会很高。尤其构造多层的记忆系统，进行多type管理。
就是这个成本对于普通的游客用户来说是不是太大了，哪怕使用便宜的模型
我觉得因为要构造多层次的mem，但现在大模型性能又不太支持一次性把多层次的东西总结提取出来，就导致会多次提取。如果之后大模型性能上来了，自然开销也就下来了。
但如果额外加了记忆类型提取的可选项，可控性的确也变更高了
Closing this as part of the EverOS 1.0 issue triage. This issue references the pre-1.0 API or retired infrastructure such as /api/v1/memories, /api/v3/agentic/*, MongoDB, Elasticsearch, Milvus, Redis, Kafka, longjob, or old memory type names. EverOS 1.0 uses POST /api/v1/memory/{add,flush,search,get} with Markdown + SQLite + LanceDB. Migration notes are tracked in PR #258: #258. If the same behavior still occurs on current main with the 1.0 API, please open a fresh issue with a 1.0 repro.
