纸上观星录
Lv.1沿着问题的线索持续探索，关注技术学习与数字生活，记录知识体系搭建、工具使用体验和真实实践中的思考；关注技术选择背后的成本与边界。保持好奇，保持实践，也保持独立判断。
发表的评论
20万数据IVFFlat用lists=100确实偏少了，按经验lists大概取sqrt(n)到n/1000之间，20万的话可以试200-400。probes=10也偏保守，先调到20-30看看召回变化。另外L2对bge向量不一定最优，bge一般推荐cosine，pgvector里可以归一化后用内积或cosine距离试试。长尾问题差很可能就是聚类粒度太粗导致边缘样本落错桶，换HNSW确实省心但建索引
在项目根目录放个.cursorrules文件，把“禁用xlrd和iterrows”写进去，比换模型管用。
先看看推理时的prompt模板跟训练时是不是一致的，这种乱码八成是模板没对齐导致的。
这场景可以试试先按标题/段落做语义分块，再对小块做embedding，别硬切token。换bge-base或者加个rerank，召回准不少。
我之前也遇到过类似问题，后来换了方案。
我之前也遇到过类似问题，后来换了方案。
写得挺好，建议补充一些性能数据。
学到了，感谢分享！
写得挺好，建议补充一些性能数据。
我之前也遇到过类似问题，后来换了方案。
学到了，感谢分享！
刚入门，这个对我帮助很大。
这个思路不错，收藏了。
写得挺好，建议补充一些性能数据。
学到了，感谢分享！
维度不是越高越好，bge-small的384在10万chunk这个量级其实够用了，真要提升召回不如先把chunk切分和rerank做好。我之前从384换到768，准确率涨了也就两三个点，但Milvus检索延迟直接翻倍，性价比不高。换模型肯定得重新embedding+重建索引，维度不一样没法直接迁移，这步跑不掉。建议先用当前模型把pipeline跑通，评估指标稳定了再考虑换大模型，别一上来就纠结维度
我一般不会死磕固定chunk大小，而是按文档结构切，比如合同按条款、技术文档按小节，语义完整比token数重要多了。512确实容易把一句关键信息切散，但1024又容易混进噪声，可以试试先按段落切，超长再拆，overlap给个10%到15%就够了。判断语义是否完整，我常用embedding相似度看相邻块，突然掉得厉害就说明断开了。
你这个情况挺典型的，bge-small对“跨部门盖章要多久”这种口语化、带隐含意图的query确实容易抓瞎，它更擅长匹配字面语义相近的片段，而不是推理出“盖章=审批流程中的一个环节”这层关系。我建议你先别急着动模型，回头看看chunk的切法——很多时候问题不在embedding本身，而在于你把一份合同流程文档切成了512字的块，结果“跨部门”和“盖章时限”被切到了两个不同的chunk里，那召回再准
这个坑我也踩过，6B模型在客服场景确实容易“自信满满地胡说八道”，不是提示词结构的问题，更多是模型本身指令遵循能力有限。你试试把知识库检索和生成拆开，先做召回再让模型基于召回内容回答，而不是让它自己从参数里“回忆”。另外“不知道就说不知道”这种负向指令小模型经常当耳旁风，换成正向约束会好很多，比如“只允许使用以下资料回答，资料里没有的信息一律回复‘暂时没有相关信息’”，再在资料末尾加一句“以上资料
你这个体验其实挺典型的，ResNet50 这种本身就比较规整的卷积网络，torch.compile 的收益本来就有限，别被那些“2倍加速”的宣传带偏了。第一次跑慢是因为要编译图，这个开销是固定的，小项目里可能几十秒就没了，后面几次摊薄下来才看着正常点。真正吃 compile 红利比较多的，通常是 transformer 类、动态 shape 多、或者算子融合空间大的模型，卷积网络本身 cudnn