深夜编程备忘录

用response_format参数直接锁死json，比在prompt里求它管用多了。

我踩过类似的坑，后来发现关键不是框架本身，而是任务定义太模糊了。如果每个节点该做什么、边界在哪没写清楚，模型只能靠猜，自然就反复横跳。我现在会把复杂分支拆成多个小决策点，每个点只让模型做二元选择，配合少量规则兜底，反而稳定不少。至于评测，可以先拿二十条真实case跑一遍，看失败模式是集中在工具选择还是流程控制，再判断值不值得继续投入。

我之前也踩过全文向量化的坑，检索出来的东西确实经常驴唇不对马嘴。后来改成存“事件单元”加元数据，比如一条记忆包含用户意图、时间戳、涉及实体和一句话摘要，向量只对摘要和实体做embedding，效果明显好很多。纯存标签太干，检索回来没法还原语境；纯存实体关系又太碎，Agent拼不出完整画面。我的做法是摘要负责语义召回，原始片段或关键句单独存payload里，命中后再拼回上下文。成本上不用什么都向量化

例子给俩就行，多了它准偷懒照抄，我一般直接砍到零样本反而更灵活。

这问题我也踩过坑，光靠堆few-shot真的会越调越僵，模型学的是格式而不是判断逻辑。建议外面套一层规则校验，比如对必填字段做个类型或词表检查，命中不了就强制置null。另外可以试试在prompt里加一句“主动声明不确定性”，很多模型其实有隐藏的拒答能力，只是默认不触发。表格和指代问题最好单独做预处理，拆成纯文本再喂给LLM，效果会稳很多。

eval只看loss肯定不够，生成质量才是王道，建议混点通用数据再试试。

我之前也踩过类似的坑，top-3不相关大概率不是向量库和生成模型的问题，而是chunk切完语义被截断了。建议你试试先按段落或标题切，而不是死磕固定chunk_size，overlap其实对长文档帮助有限。温度这块GPT-4o-mini我一般设0.1，Llama会调到0.3，但更关键的是在prompt里强制要求“只基于给定上下文回答”，不然模型确实容易放飞。嵌入模型的话，text-embedding

试试把chunk调到256再重叠64，bge对长文本切分敏感，query改写加个同义词扩展也有奇效。

8G显存跑7B其实挺吃紧的，补全质量受量化影响比模型本身还大，你可以试试Q4_K_M或者Q5的量化版本，先把prompt里加上当前文件的类型定义和最近几个函数签名，效果会明显不一样。Qwen2.5-Coder 7B在TS上确实比DeepSeek稳一点，但也就好一丢丢，想彻底解决括号问题不如直接用tabnine或者GitHub Copilot的免费版，本地模型玩个乐子就好。另外你那个prompt模板

这问题我也踩过坑。CoT真不是万能的，尤其客服场景里大部分是简单查询，硬要它“思考”反而给了模型自由发挥的空间去编中间逻辑。我的做法是只在用户问题明显包含多步推理时才动态追加“一步步想”的指令，平时就让它直接给答案，配合few-shot给几个简洁回答的示例效果会好很多。另外你可以试试把“给出推理过程”改成“内部思考，只输出最终结果”，能减少很多废话。

20万条数据IVFFlat的lists确实太粗了，试试lists=2000，probes调到30再看。

我跟你情况差不多，工具脚本随便让它写，但核心逻辑基本只拿它当高级补全用。最靠谱的套路是先让它给方案和单测，然后自己把单测跑一遍再review实现，不然它解释得再合理也容易在边界上翻车。

遇到这种问题我一般直接开个新对话或者单独建个文件让它只改指定区域，不然它老觉得自己是在做code review。另外你可以在系统提示里写死“不要动已有函数”，或者用git stash把改坏的部分藏起来再让它重试。不过说实话，Cursor对项目上下文的理解还是太激进，我后来干脆把核心代码标成只读，只给AI留一个接口文件的权限，不然真没法work。

这问题我太有同感了，bge-large在长文本上本来就不太敏感，512切块会把关键语义稀释掉。建议试试先做个粗召回，比如top50，然后拿query和每段做个轻量级关键词重合度打分，把得分低的直接砍掉，再上MMR，比单独靠向量相似度稳很多。另外LLM二次筛选我也试过，用小模型比如qwen-turbo批量判断相关性，成本低效果还行，但注意别让它直接给答案，只让它输出“相关/不相关”就行。

试试关掉amp混合精度，开启gradient_checkpointing，大概率能压住涨势。显存一直涨多半是计算图没释放，用torch.cuda.memory_summary抓一下最稳。

这问题我踩过坑，其实微调不是让模型记住新知识，而是教它怎么用上下文。你可以试试把检索到的段落和正确答案拼接成训练样本，然后故意换掉部分检索内容让模型答错，这样负样本能逼它学会依赖输入。冻结层的话我建议只动最后几层transformer，前面特征提取保持原样，效果会稳一点。另外LoRA这种低秩适配也值得试，参数改得少，对原有知识破坏小。

24G跑7B按理说真够用了，问题大概率出在vLLM的KV cache预留上，`--gpu-memory-utilization`默认值0.9但配合gptq反而容易踩坑，建议直接显式设成0.85再配`--max-num-seqs`小一点试试。另外你这场景代码补全其实对长上下文没那么刚需，不如把max-model-len砍到4096然后专注调`--block-size`，换页问题能缓解不少。AWQ和F

我最近也踩过这个坑，Qwen2.5-7B不带function calling的话，纯靠prompt约束真的容易放飞自我，尤其参数多的时候。建议直接换Qwen2.5那个专门的function calling版本，或者试试用vLLM配合工具调用的模板，比LangChain默认的解析稳多了。另外你temperature调低到0.1以下试试，模型瞎编的概率会小不少。框架方面其实不用急着换，先把工具定义写严

torch.compile这玩意真不是无脑加的，我试过几次发现它特别吃batch size和显存，小batch下CUDA graph那套优化反而成了负担。你ResNet50固定尺寸按理说没问题，但得把torch._dynamo.mark_dynamic去掉，还得确保数据加载器里没有隐式的shape变化。另外试试mode="max-autotune"或者关掉cudagraphs，我这边用reduce

说实话全量微调7B在80G上跑满序列长度确实紧，我当时也卡在这。DeepSpeed ZeRO-3加上offload能撑住，但速度会掉不少，建议先试这个。梯度检查点别自己写，PyTorch自带那个实现已经挺成熟了，配合DeepSpeed基本能压到一半显存。另外注意下序列长度和batch size，有时候把max_seq_len从4096降到2048，效果差不了多少但显存直接省一大截。