山海寻光记

这问题太真实了，我让Agent写嵌套循环也经常绕进去，感觉它对边界条件的理解就是靠猜。 不如试试让Agent先把伪代码和预期输出写出来，确认逻辑没问题再让它转成Python，比直接生成靠谱点。

5000条数据微调7B其实有点少，尤其客服问答这种意图和话术都高度重复的场景，模型很容易偷懒学会套模板。你试试把学习率调低点，比如5e-5以下，或者换下LoRA的rank值，我之前调参时也遇到过loss卡住，后来发现是数据集里长尾问题太多，把那些重复率高的样本去重后效果立竿见影。另外验证集上的“答非所问”可能不是loss的问题，而是训练时没有加入对话历史上下文，模型根本不知道用户在问啥。

few-shot别贪多，3个足矣，案例顺序按难度排，效果比模板本身更吃数据分布。

我一般会先花几十秒把项目里关键的组件路径和命名规则直接贴进prompt，比如“我们用的是src/components下的BaseTable，不要引antd的Table”，这样它跑偏的概率会低很多。角色设定那招我也试过，确实有点用，但更核心的是你得把“不要做什么”也写清楚，光说“用hooks”它可能理解成class也行。另外如果项目里有现成的类似页面，直接把那个文件的代码片段丢给它当参考，比描述半天

说实话你这问题我太有共鸣了，调Agent就像抽盲盒，同一套Prompt今天好用明天就抽风。我后来发现关键不在“多详细”，而在“怎么结构化”——比如把“提取决策”拆成“谁在什么时间点对什么事拍了板”，再把“待办”限定成“负责人+截止日期+动作动词”的组合，模型就老实多了。你试过用分隔符把指令和输入内容明确隔开吗？有时候不是它不懂，是上下文里闲聊和正文糊在一起，模型自己都分不清边界。另外few-sho

3060 12G跑SDXL确实紧巴，但没到完全跑不动的地步。我之前的经验是把batch size锁死1，然后offload和slicing都开，再配合--opt-split-attention，虽然慢但至少不爆显存。你试试把分辨率降到768以下，或者直接用SDXL-Turbo，速度能快好几倍，画质损失其实不大。另外你提到的TensorRT，如果只是做推理，提升确实明显，但微调的话就别指望了。你报错

同感，最近也在调RAG的few-shot，试了一圈下来感觉你说的这两个坑都踩过。前一种写法确实容易让模型“偷懒”——它可能觉得示例里直接给答案就行，反而把检索到的上下文当成了噪声。后一种写法我试过，但发现换批文档后示例里的chunk风格变了（比如有的文档是表格、有的是长段落），模型反而容易混乱，甚至开始模仿示例里的语气而不是回答用户问题。 我后来折中试了个方案：在示例里把query和检索结果都放