持续迭代低代码修炼册

base版做对话本来就难，5000条混合数据量也偏少，建议先看看数据里中英文比例和回复质量。

我遇到过类似情况，后来发现光靠测试反馈循环不够，得让Agent在生成patch前先显式列出受影响的调用链和边界条件，相当于强制它“想清楚再动手”。另外“自信地犯错”很大程度是模型对上下文理解不够深，可以试试把相关文件的依赖关系用图结构喂给它，比纯文本拼接效果好不少。沙箱环境确实要重一点，但更关键的是测试用例本身得能覆盖Agent容易漏的那些交叉场景，不然反馈信号就是噪声。

正样本只有一个的话，InfoNCE确实更合适，因为它天然就是在做“从一堆候选里把正例捞出来”这件事，比纯交叉熵更能压出相对排序。我之前试过listwise的softmax交叉熵配温度系数，效果比pointwise好不少，你可以先把batch内的负例利用起来。冻结层的话不用全冻，一般冻底层embedding+前几层就够，顶层还是让它学排序信号。要是数据量不大，LoRA微调比全参更稳，通用能力基本不会

刚入门，这个对我帮助很大。

群晖上跑Docker最容易踩这个坑，先确认一下容器是不是绑定了127.0.0.1，SSE模式如果监听地址写的是localhost，那端口映射出去也没用，得改成0.0.0.0。我之前也是本机curl通、别的设备超时，折腾半天才发现是bind address的问题。另外群晖自带防火墙默认会拦非本地网段，去控制面板里看一眼有没有放行8899。

这块建议先查检索命中率，再排查温度参数和上下文拼接，幻觉兜底可以加引用溯源。

加个cross-encoder做rerank，再在prompt里明确说只依据相关段落回答，效果会好很多。

Windows下spawn确实坑，每个worker都要重新import主模块，如果你预处理写在`__main__`外面或者用了全局变量，每个epoch都在重复拷贝，内存和启动开销直接爆炸。我建议把albumentations的transform定义成可序列化的类或者放到单独模块里，再试试`persistent_workers=True`配合`prefetch_factor`，能明显减少worker

200多篇博客其实不算多，问题大概率出在分块上。技术博客本身结构就松，按固定字数切很容易把一段完整逻辑拆散，建议试试按标题层级或者语义切，overlap别设太大，10%到15%就够了。你说的先关键词过滤再向量检索这个思路挺对的，尤其查具体API名或者版本号时，纯向量很容易跑偏，加一层BM25混合召回会稳很多。另外embedding模型也值得看看，OpenAI那个对中文技术内容其实一般，换个bge或

显存涨这么多不太正常，检查下是不是没包住auto_wrap，或者LoRA层没被FSDP管到，参数其实还是全量复制了。

你拿PyTorch写代码调确实显得绕，但MCP真正有用的地方是当工具不是你自己写的时候，比如团队里有人封装好了推理服务，你不想让LLM直接碰代码和密钥，只暴露一个受控接口。GPU常驻这块，一般是MCP服务器连到已有的推理服务上，模型本身不跑在MCP进程里，并发靠后端队列或批处理扛。我见过落地的场景是多个Agent共享同一套工具权限，走MCP统一鉴权和审计，而不是每个模型自己拼代码。

7B模型原生function calling确实不稳，建议直接上支持tool call的微调版或者换14B，省得跟parser死磕。

Cursor里把tab补全的触发延迟调高一点会好很多，我现在设的300ms，基本能让我把思路捋完再决定要不要接受。Claude Desktop那边倒是没找到类似MCP层面的权重参数，它更像是直接吃模型输出，不太好细调。你可以试试在rules里写清楚“不要跨文件补全”，我这么干之后跳文件的毛病少了大半。

说实话chunk这块真没啥银弹，我试过按句子边界切比固定token数靠谱得多，尤其合同这种条款分明的，用500-800字符加30%重叠再配合metadata过滤效果比纯调参好。你不如先看看bad case是召回漏了还是排序不对，有时候问题压根不在chunk上。长报告和聊天记录肯定要分开策略，前者按章节语义切，后者直接按对话轮次分就行。

500条代码数据做LoRA确实有点极限，但更可疑的是你那个“instruction: xxx\noutput: xxx”的裸格式。7B模型对输入结构的敏感度比想象中高，尤其代码生成这种任务，它需要清晰的上下文边界和输出起始信号，你至少得加上“### Instruction:”和“### Response:”这种分隔标记，不然模型容易把指令和代码混在一起学，loss震荡很正常。 另外3e-4的学习

预处理真得做，不然模型光猜格式就够呛，嵌套JSON多塞点错误恢复例子特管用。

你这情况大概率是chunk切碎+重排没做好，prompt只是背锅的，先试试把召回提到10再过滤一遍。

纯靠prompt约束确实容易翻车，我试过在system里写“禁止推理”结果它照样脑补。后来发现关键是把检索到的chunk先做一层处理，比如把不相关的段落直接删掉，只留最相关的两三段，再在prompt里要求它逐句标注引用来源，效果会稳很多。你可以试试在每段前面加编号，然后在回答里强制它写“根据[3]的内容……”，这样就算编也能看出来是哪段出的问题。另外温度调低点也有用，0.1左右基本不会自己发挥。

建议看下不同卡间数据shuffle是否一致，DDP下没设seed的话每个进程数据顺序不同会加剧震荡。

试试先按API功能模块拆文档，再把“订单”和“库存回滚”这种强关联片段绑到一个块里，别光靠embedding硬匹配。