产品观察室

直接在项目里建个requirements.txt，把版本号写死，它基本就不会乱推了。 我都是这么干的，比在注释里喊话管用多了。

这问题我太有同感了，Cursor的Composer就像个热情过头的实习生，你让它端杯水，它能顺手给你泡杯咖啡再配块饼干。我后来发现一个笨办法挺管用：在项目根目录放一个AGENTS.md文件，把“禁止添加未要求的功能”写成第一条铁律，它至少会收敛一点。另外你试试把prompt改成否定句式加具体理由，比如“不要预览图，因为后端会返回压缩后的URL”，它理解上下文后就不那么爱自由发挥了。还有就是别用Co

试试在项目根目录放个AGENTS.md，把禁止事项写进去，比prompt管用多了。

我们组是Milvus重度用户，2.x版本稳定性确实比1.x好多了，但集群部署那套配置是真的折磨人，尤其是etcd和pulsar的资源占用，小团队慎选。Qdrant我们只在POC里试过，Rust写的就是轻快，但社区生态和中文资料明显少一截，遇到问题翻GitHub issue效率有点低。还有个感受是Milvus的索引参数对召回率影响特别大，不调好会莫名丢数据，建议你们先拿自己的数据集跑个benchma

5000条数据跑10个epoch，loss都0.3了还这样，八成是过拟合了，LoRA在这种小数据集上特别容易把噪声学进去。rank8 alpha16这个组合其实挺常规的，要不先试试把学习率降到5e-5或者3e-5，然后early stopping盯一下验证集表现。全量微调不一定更好，数据量不够反而更容易崩，我建议你先拿一小部分数据做一下领域内评估，看看是不是业务术语本身就没对齐。 另外你确认过原

你这场景直接上Milvus吧，几十万中文文档加混合检索，Weaviate那中文分词真能急死人。

说实话，微调LLM对RAG检索准确率的影响本来就很小，因为检索靠的是embedding的相似度，跟生成模型关系不大。你这种情况，重点应该放在优化chunk切分和重排上，比如试试调小chunk size或者加个reranker。另外，如果真要微调，建议在数据里混入检索到的错误片段和正确答案的对比，让模型学会忽略噪声，单纯用问答对效果确实有限。你LoRA参数没啥问题，但3个epoch可能不够，或者数据