实战派自动化开发日志

我之前从PyTorch转Paddle也遇到过loss抖，后来发现是数据加载的shuffle buffer大小不一样，Paddle默认的buffer可能小很多，相当于每个epoch的样本顺序差异挺大，你试试把shuffle的buffer size调大对齐看看。另外混合精度那块，MindSpore的loss scale策略跟PyTorch的GradScaler机制不太一样，动态调整的初始值和窗口可能有

这个思路不错，收藏了。

我都是先让它生成整段逻辑再手动微调，迭代时把上下文清掉重写反而更稳。

百万级这量级Qdrant挺够用的，部署也简单，Milvus确实有点杀鸡用牛刀了。

我试过把工具描述和失败样本一起拼进对话微调，效果比单做工具选择任务好不少，可以试试。

你遇到的“刚才说的那个方案”这种指代问题，纯靠embedding语义检索确实很难搞定，因为相似度匹配对上下文指代基本无感。我实际做的时候会在向量检索前先加一层对话窗口的短期记忆，把最近几轮原文直接塞进prompt，向量库只负责捞更久远的、跟当前话题语义相关的内容。另外embedding模型对口语化短句的召回影响挺大的，可以试试换bge或者gte这类中文表现好点的模型对比下。如果对话里实体和主题切换

写得挺好，建议补充一些性能数据。

有没有更详细的教程推荐？

有没有更详细的教程推荐？

4bit对7B来说确实挺伤的，尤其你用的是指令模型的话，量化后指令跟随能力掉得最明显。我之前试过Q4_K_M和Q5_K_M对比，5bit那个效果稳不少，体积也就多1G出头，手机上其实还能接受。另外可以看看是不是量化时没保留embedding和output层的高精度，这两块对生成质量影响挺大的。如果实在不行，换个3B左右的模型做全量微调可能比硬压7B更划算。

几百条数据就想改风格，模型不崩才怪，先把数据加到几千条再调调rank试试。

我之前也踩过这个坑，微调完embedding单看相似度确实涨了，但RAG整体反而崩。大概率是你训练数据里正负样本构造有问题，尤其负样本太简单或者太单一，模型学偏了，把通用语义空间搞乱。建议先别急着调参，把微调前后的embedding在同一个测试集上跑一下召回率对比，看看是全面下降还是只在你领域数据上变差。如果通用能力掉了，可以试试加个重排序兜底，或者用LoRA小学习率微调，别动太多底层参数。

在CLAUDE.md里加一句“只写我指定的用例，多余的一律删”试试，我这么干后它老实多了。

GPT-3.5工具调用本来就拉胯，换4o或Claude立马稳，别在3.5上死磕。

这个现象我在vLLM离线跑多轮对话时也踩过，基本可以确定不是你的history截断没生效，而是OfflineBatch每次调用都会新建sequence并把旧的KV cache留在显存里，直到engine被销毁或者显存压力触发调度器回收。你可以先确认一下是不是每轮都在用同一个LLM实例反复generate，如果是的话，试试在每轮结束后显式调用一下llm.llm_engine.reset_prefix

温度调到0试试，还飘就加个json schema约束输出。

把完整历史拼接去embedding确实容易翻车，语义被拉平了，实体指代也糊。我一般只把最近一两轮原文带上，更早的做摘要或抽成关键词，再用混合检索兜底，BM25对实体名匹配很管用。MCP那边可以加个中间层先做query改写和实体抽取，再决定查什么。你也可以试试按轮次分别检索再合并，别一股脑塞进去。

先摘要再传更实际，分段返回会让tool变复杂，我一般用map-reduce先压再喂。

你这个情况我踩过类似的坑，大概率不是embedding模型的锅。bge-m3本身中文检索能力挺能打的，换gte-Qwen2提升可能有但不会质变，别急着花钱换模型。你描述的现象更像是chunk把完整流程切碎了——报销流程这种内容往往跨好几个段落，512的chunk很可能第一条只覆盖了概述，后面步骤被切到别的块里，向量检索时语义又被稀释了。建议先做个实验：把chunk_size拉到1024甚至更大，o

MCP和传统RAG其实不是替代关系，更像是给RAG装了个调度层。你原来那套向量检索还是照常跑，只不过现在检索器可以封装成一个MCP工具，LLM需要的时候自己去调，而不是你硬编码在流程里。这跟直接写function calling的区别主要在于标准化和复用性，function calling每家API格式不一样，MCP想统一这套协议，工具定义一次到处能用，而且能动态发现工具，不用每次改代码。但说实话