RAG项目用Milvus还是Weaviate？求过来人给点建议

我们去年也是类似场景，几十万中文文档，最后选了Milvus。部署确实重一点，但用docker-compose跑单机也还好，关键是中文混合检索得靠它自带的稀疏向量，配合BM25效果比纯语义强不少。Weaviate之前试过，中文分词那套内置的确实不太行，还得自己接分词器，折腾。你们要是人力有限，可以看看Milvus的Lite版本先验证，后面再上集群。

几十万篇文档这个量级，ChromaDB确实扛不住，换掉是对的。我之前有个类似的项目，中文知识库+混合检索，Milvus和Weaviate都试过。Milvus的混合检索要自己搭sparse vector，配合BM25还得额外做，链路比较长但可控性强，中文分词用jieba或者HanLP都能接。Weaviate内置了BM25和vector的hybrid search，开箱即用这点很香，但它的中文tokenizer确实拉胯，默认那个tokenization对中文基本等于按字切，效果一般，得自己在schema里配tokenization或者走自定义模块。部署这块Milvus standalone用docker compose其实也没那么恐怖，真正重的是集群版，中小团队用standalone加etcd和minio三个容器就够了。如果你们团队运维人力有限，又急着上线，Weaviate可能更快，但要接受中文检索效果打折扣，后面rerank能补一部分。另外可以看看Qdrant，混合检索和中文支持介于两者之间，部署也轻，我们最后是迁到它上面去的。

我们去年也是类似场景，几十万中文文档，最后选了Milvus。部署确实要花点功夫，但用docker compose其实还好，主要是etcd和minio这些依赖得理清楚。中文混合检索我们是在应用层做的，向量召回后再用BM25补关键词，效果比纯向量稳不少。Weaviate的混合检索内置得更好，但中文分词这块确实得自己折腾，如果团队人手紧张可以再权衡下。

写得挺好，建议补充一些性能数据。

有没有更详细的教程推荐？

几十万篇中文文档还带混合检索，Weaviate自带BM25+向量融合，开箱即用，省得自己拼ES。Milvus要上混合检索得自己搞稀疏向量或者外挂ES，部署和运维成本对中小团队不太友好。你既然后面还要接rerank，建议先用Weaviate跑通链路，等量级再涨再考虑Milvus的分布式。不过中文分词这块两边都得自己配，别指望默认效果。