慢热云原生玩家手记

4bit下loss偏高挺正常的，尤其QLoRA对7B这种规模本来就有精度损失，可以先试试把lora的rank调到16或者32，再配合bf16混合精度看看。DeepSpeed的话两张卡上Stage 2主要是省点梯度显存，但你这瓶颈在前向激活值，不如开gradient checkpointing，能省不少。实在不行换1.8B确实更友好，先把流程跑通再升级模型，不然光调参就够折腾了。

我之前做的时候也卡在这块，后来发现重排救不了检索的命，关键还是得看召回阶段是不是真的把“相关”和“相似”分开了。你换chunk size和hybrid search没太大用，很可能是因为bge-m3对领域内近义术语的区分度确实不够，尤其当知识库里大量段落都围绕同一概念展开时，向量空间里它们本来就挤在一起。我后来试了个笨办法，就是给每个chunk加一个“意图标签”或者“操作对象”的元数据，检索时先按

试试在召回后加个重排，或者把top-k调小到5，让LLM只聚焦最相关的几段，效果会稳很多。 我一般是直接过滤掉相似度低于阈值的，再让LLM自己挑重点，比硬塞一堆强。

我试过在prompt里加“如果加额外功能请先问我”，但发现得把这句话放在最前面才管用，放后面就会被忽略。还有个土办法，就是故意把环境写得很简陋，比如“只能用标准库，没有任何第三方包”来限制它。 另外它加进度条和日志可能跟任务描述里的某些词触发有关，你试试把需求写得特别干巴，比如“读文件，算平均值，打印结果”，别用“处理”“分析”这种模糊词。 最靠谱的还是让它先输出计划，你确认了再写代码，多一步

你这问题其实挺典型的，核心不是“该不该用RAG”，而是“怎么用RAG做记忆”。纯靠语义相似度去匹配“刚才说的那个方案”，embedding天然会丢失指代消解信息，召回乱是正常的。实际项目里我会在向量检索基础上加一层结构，比如给每条记忆打上session_id、时间戳、甚至对话轮次标签，检索时先过滤再排序，或者用LLM对原始query做一步指代消解再查。另外embedding模型也得选对，比如bge