云端萤火虫守护服务器

我一开始也纠结过这个，后来直接上了Chroma，本地跑起来确实省心，几行代码就能存能查。但用久了发现它更适合原型阶段，数据量一上来性能就有点跟不上了。如果你只是先跑通流程验证想法，Chroma完全够用，等真有规模了再换Milvus也不迟。Pinecone省事但要花钱，看你能不能接受托管成本了。

几十万条文档Chroma其实也能扛，但并发一上来就容易跪，我之前项目就是先用Chroma后来迁的Qdrant，迁移成本没想象中高，主要是重跑embedding费时间。Milvus那套etcd加minio确实重，小团队维护起来心累，除非你QPS要求很高不然Qdrant够用了。bge-m3和OpenAI的差距没传说中那么大，中文场景bge-m3甚至更稳，OpenAI胜在省事不用自己部署，预算够就无所谓

维度不是越高越好，关键看你的数据量级和检索场景，几千篇文档256维够用，几万篇再考虑升级模型。 别光看召回率，试试调分块大小和检索topk，说不定256维也能救回来。

并发才5个就十几秒不太正常，先看看是不是CPU喂不饱或者pipeline并行没开，量化倒不急。 你试试把vLLM的调度策略调成抢占式，再查下是不是显存碎片化严重，有时候换TGI确实能救回来。

这问题太典型了，LangChain的AgentExecutor在工具间传递上下文确实容易“断片”，本质上是它只把当前工具的输出塞给下一步，之前的结果得靠你自己拼进prompt。我之前也踩过这坑，后来干脆不用它自带的memory，改成自己维护一个全局的上下文dict，每次工具返回后手动把关键信息追加进去再传给下一个工具。另外你试试把工具的描述写清楚点，让Agent知道该把哪个结果作为中间变量存下来，

我之前也踩过这个坑，中文和英文不一样，递归分割器默认按标点和长度切，遇到引号、书名号就很容易把法规条款拆断。后来我改成按段落先粗切，再用jieba或LAC做句子边界识别，最后按语义完整度合并，chunk_size反而不用卡太死。separators我一般把顿号、分号、右括号都加进去，优先级比句号低一点。另外可以试试chinese-text-splitter这个库，专门处理中文长句和引用关系，比硬调