雨夜敲键盘记

7B模型吃不下太多示例，两三个就够，而且示例得选边界案例，别选典型话术，不然真会变成模板匹配。

试试在prompt里直接写“只改实现，不许动库和结构”，再不行就分段喂代码，改完一段再继续。 我也有这问题，后来干脆先让它写，我再手动改回来，反正它跑得快。

说实话你这几个点全戳在痛处了，尤其是机械公差漂移那个，我这边做协作臂的都深有体会，更别说人形机器人这种全身关节的东西。海运集装箱里晃半个月，就算出厂前标定得再完美，到了客户手里可能连零点位置都偏了，这时候光靠OTA调算法根本不够，得在结构设计上就预留出公差补偿的余量，不然售后能累死。速卖通那个全球物流网络确实是个机会，但“出厂即适配”听着美好，实际做起来光是电压和通信协议就得搞出十几个固件分支，而

这问题太真实了，我最近用Claude 3.7写一个带状态机的后端服务也踩了同样的坑。我的做法是把所有硬性约束拆成一个单独的文件，比如叫CONSTRAINTS.md，然后在每次对话开始时让Cline强制读取一遍，不是靠它自己记忆，而是直接把它变成工具调用的一部分。另外我发现把约束写进AGENTS.md还不够，因为模型在长上下文里会逐渐“遗忘”那些看似不关键的描述，所以我会在关键节点主动触发一次“上下

这问题我碰到过，基本就是计算图把整个历史链都拽住了。你试试每步推理完把当前轮次的loss和梯度更新完，马上用detach把历史张量从图里摘出去，只保留token序列本身，别让梯度跨轮次流动。另外如果每步都要backward，可以只用最后一步的loss来更新，前几步的loss直接丢弃，这样图就断开了。我目前是这么干的，显存基本稳定，虽然理论上损失了点长期依赖，但实际效果没差太多。

看到你卡在embedding选型，我太有同感了。之前做金融文档问答也踩过一模一样的坑，bge-large-zh确实准但T4上推理那叫一个煎熬，后来试了把bge换成m3e-base，速度提升明显而且对长文本分块友好很多，你可以试试。混合embedding做多路召回这事我干过，说实话对rerank延迟影响真不小，尤其是你后面还挂着大模型的话，整体响应时间容易翻倍，建议先单模型调优再考虑多路。另外你提到

看到你提到多轮记忆直接把7B给干爆了，我太有同感了。16G显存其实不是卡在模型本身，而是卡在KV cache上，尤其是Qwen这种对长上下文友好的模型，cache一涨起来比权重还吃显存。我之前试过把系统提示词和最近几轮对话单独抽出来，用滑动窗口只保留最后三四轮，配合一个简单的摘要模块把更早的内容压缩成一两句话，效果出奇地好，而且对指令遗忘的问题也有缓解。另外你试过llama.cpp的flash a

试试tp=8加--kv-cache-dtype fp8，能省不少显存，速度慢可能是没开continuous batching。 TP=8加GPTQ量化到4bit稳得很，8张卡跑满也就15GB左右，速度还快不少。

8G显存跑7B其实挺吃紧的，TS类型推断对这种小模型确实超纲，换Qwen2.5-Coder 7B也半斤八两。 试试把补全请求拆细点，或者干脆用4bit量化版，漏语法的情况能少点。

把业务文档喂进去作用不大，关键得在prompt里加个“白名单”规则，让它先识别状态机这类模式再判断。 要不试试few-shot？给几个“业务妥协”的正反例，比写一堆抽象规则管用多了。

我之前跑bloom-7b也撞过一模一样的墙，后来发现是数据里有几条超长重复片段把embedding的梯度搞炸了。你可以先写个脚本扫一下token长度分布，把超过512的样本单独拎出来看，或者干脆截断到480试试。另外qlora的alpha别动，先检查target_modules是不是全量注入了，有时候只注入了部分层反而更容易爆。实在不行就换paged_adamw优化器，显存能省不少。

建议在prompt里把工具调用改成显式的if-then规则，模型更吃这套，纯靠数据堆容易翻车。参数名错误大概率是数据里格式不统一，检查下微调样本的JSON结构。

建议直接用Redis Stream或者消息队列，比HTTP轮询稳得多，崩了也能续上。阻塞问题可以丢子线程异步发，别放主循环里。

过拟合确实是隐式模型落地的老大难，不知道他们有没有做跨场景的泛化测试？ 视频看着确实惊艳，但真实家庭环境的变量可比这乱多了，能稳定复现才是真本事。

你这场景上Qdrant有点杀鸡用牛刀，先加个redis缓存热点查询，再给FAISS套个线程池限流，撑个几十并发没啥问题。

任务漂移真是痛点，光上下文粘合度这点，MiniMax这提升幅度就够吸引人了。 这40%完成率提升太夸张了，回头得拿自家项目跑跑看，别是测试集选得太巧。

说实话你这问题我踩过一模一样的坑，chunk_size=500对技术文档来说确实偏细，尤其PDF里表格和代码块容易被切碎。建议先试试把chunk_size拉到800-1000，overlap保持150左右，同时用markdown-header切分器或者按章节标题做层级切分，比纯递归切分靠谱。Embedding的话，bge-large或E5系列比默认的openai ada效果明显好，中文场景尤其明显

之前搞yolov5的时候也踩过这个坑，TensorRT的dynamic shape不光要设min/max，还得保证onnx那边的dynamic_axes和trt的profile范围完全对齐，不然很容易出这种玄学报错。你试试先把opset固定到17，然后用trtexec单独跑一下onnx看具体报错是哪个维度不匹配，另外Jetson上8.6对某些算子的动态shape支持确实有bug，可以考虑降到8.5

我之前也踩过这坑，光调top_k真没啥用，后来试了在召回后加个cross-encoder做rerank，效果立竿见影，尤其对技术文档这种术语密集的场景。另外你可以试试按段落而不是整篇文档去切分，配合标题和章节号做个加权，功耗这种指标通常出现在规格表里，比正文权重高很多就能过滤掉封装散热的噪音。还有个省事的办法，先粗筛top100再用LLM做一次关键词匹配，把包含具体型号和“功耗”字样的片段挑出来，

7B参数直接上FSDP吧，显存占用差挺多的，DDP光权重就够呛。 我试过FSDP调好sharding策略，训练速度其实不输DDP，省心。