雪原寻光
Lv.1用文字保存技术成长的坐标，关注技术学习与数字生活，记录知识体系搭建、踩坑过程复盘和真实实践中的思考；不追求堆砌概念，只记录验证过的经验。这里不卖焦虑，只分享方法和真实经验。
发表的评论
这个问题我也踩过坑，说下我的做法。核心思路是把“检索”和“对话状态”解耦，历史对话不直接进检索query，而是先做一轮轻量的指代消解，比如把“那B方案呢”改写成“B方案的成本”，再拿改写后的query去独立检索，这样语义不会被上一轮的检索结果带偏。上一轮的检索结果我一般只保留top1到top2的摘要放进context，而且明确标注是“上一轮参考”，不是本轮证据，模型就不容易混着用。另外我加了个小判
写得挺好，建议补充一些性能数据。
写得挺好，建议补充一些性能数据。
有没有更详细的教程推荐？
这个思路不错，收藏了。
刚入门，这个对我帮助很大。
刚入门，这个对我帮助很大。
这个思路不错，收藏了。
有没有更详细的教程推荐？
刚入门，这个对我帮助很大。
这个思路不错，收藏了。
检索回来太多确实头疼，我一般会先加一层rerank，用bge-reranker或者cohere的接口重排一下，只留top3到top4，通常效果比直接砍数量好很多。另外你试试把chunk做小一点但保留重叠，比如256token加50token overlap，这样即使多召回几个也不容易爆。摘要压缩我踩过坑，细节丢得厉害，不如直接换个16k上下文的模型来得省心。
试试在 tool 里包一层 torchrun 脚本，rank 和 world_size 让 torchrun 自己注入，别手动传环境变量。
A10跑AWQ的7B不该这么慢，检查下是不是没开连续批处理或者采样参数设太重了。
我拿Llama3-8B做过类似的中文问答，rank=16其实不算小，答非所问更可能是数据质量或训练轮数的问题。个人经验是rank跟数据量关系挺大，几千条数据用8到16就够了，几万条再往上加。rank=64以上小数据集上确实容易过拟合，验证loss会先降后升。另外alpha一般设成rank的两倍，这个别忽略，比单纯调rank影响还明显。
我也遇到过这种情况，感觉是模型在偷懒省token。后来我把需求拆成小块，比如先让它只写去重，再单独问填充空值，最后拼起来，成功率就高多了。另外给它一个具体的列名和数据样例，比泛泛说“异常值处理”管用得多。你可以试试先让它输出伪代码，再让它根据伪代码补全，有时候能绕过这个占位符的毛病。
两个都用过，说点真实感受。Milvus功能确实全，分布式那块做得成熟，但部署复杂度真的劝退，光是etcd、pulsar、minio那一堆依赖就够折腾半天，小团队用单机版还凑合，一旦要上集群运维成本直接起飞。Qdrant就轻量太多了，Rust写的性能很猛，单机跑起来基本零配置，过滤查询这块我个人觉得比Milvus顺手，payload索引做得挺灵活。不过Qdrant的坑在于分布式版本起步晚，大规模集群
公司线上是TF就别折腾了，部署稳才是王道，训练用PyTorch导出ONNX再转也行。
简历场景下固定长度切分确实容易把一段经历切碎，建议先改成按段落或按项目条目切，这个改动成本最低但收益往往最大。bge-large-zh本身不算差，先别急着换模型，可以拿几个badcase看看是不是切分导致语义断了。rerank对中文长文档提升挺明显的，尤其top5混进不相关内容这种情况，加个bge-reranker能压下去不少。另外简历问答可以考虑在query里带上岗位或技能关键词，单纯语义检索对
Cursor跨文件重构是真香，Copilot补全快但老API坑过我好几次，最后我留了Cursor。