持续研究数字化实践笔记

2000条确实少了点，LoRA rank8也偏低，试试把rank加到16、学习率调成1e-4看看。 数据量太小，模型容易学飞，先加大数据量到5000+，或者试试冻结更多层只训顶层。

说实话7B模型做agent确实容易在工具调用这块翻车，输出格式不稳是常态，不是你的工作流问题。我之前用8B模型也踩过这坑，后来直接换Qwen2.5-72B的量化版才稳下来，但4090跑起来有点吃力。你既然图隐私，不妨试试vLLM部署加严格的grammar约束，强制JSON输出能解决大部分解析失败。另外LangGraph里给工具调用加个超时重试机制，别让模型无限卡住，至少能让流程跑完。

试试把few-shot精简到1个，系统提示只留核心规则，其他塞进动态变量按需注入，能省不少。 模板别整太全，按任务拆成小块，用的时候再拼，比一个万能模板省得多。

说实话bge-large-zh-v1.5在短文本上确实有点钝，尤其你这种同义改写场景，它更多吃字面重合而不是语义等价。我试过把chunk从512砍到256，配合滑动窗口重叠50%，召回准确率能上来一点，但代价是索引体积变大，8G显存跑bge-m3确实悬，不过可以试试量化版或者用ONNX跑CPU推理，速度慢点但至少不爆显存。 query改写这块我觉得是刚需，别指望embedding模型自己理解“违

这问题我踩过一模一样的坑，你大概率不是prompt拼接的问题，是HuggingFace的model.generate()在内部把整个输入序列都包进了计算图，哪怕你设了torch.no_grad()，只要没在生成前手动把梯度关干净，历史token的中间激活值就会一直挂在显存里。我之前自己写Agent的时候，每轮对话完都得把当前轮的输出和prompt整体重新编码一遍，但真正吃显存的是之前所有轮次的KV

说实话我之前也被这个问题卡过，后来换成LangGraph的StateGraph把工具状态塞进graph的state里，用checkpointer做持久化，并发冲突基本就没了。不过如果是轻量场景，其实不用全局变量，搞个连接池管理AgentExecutor实例，按用户维度或者token维度去绑定，比每次重建要省事。带状态的工具我建议单独抽出来做服务，别跟着Agent生命周期走，这样就算并发也不怕状态污

这问题我之前也踩过，商品图去重真不是单纯靠向量相似度就能搞定的。CLIP提取的特征偏向语义，对颜色、纹理这种细节不敏感，所以同款不同色被判重复很正常。建议你试试把特征提取和图像预处理结合起来，比如先做颜色归一化或者加个边缘检测，再送进模型。另外你说的准确率问题，与其调阈值，不如考虑用多个特征加权融合，或者搞个二分类模型专门过滤误判。 还有，向量维度高不是主要矛盾，Milvus本身对高维支持挺好，