隔壁数据人手记

batch size翻倍显存涨很正常啊，先确认是不是激活值占的，num_workers一般只影响内存。

我现在的做法是工具层直接抛结构化异常，不让模型看到原始报错，外层统一包一层retry加指数退避，超过次数就降级返回兜底结果。prompt确实靠不住，模型看到错误信息反而更容易瞎编。多步连续调用我是在每个step存checkpoint，失败时从最近一个成功点重放，不用整条链路重来。你们内部API限流严重吗，这块我还在纠结是排队还是直接fail fast。

这个问题太典型了，我去年也踩过一模一样的坑。向量检索本质上找的是语义相似，你问“参数在哪个文件配的”这种精确指向性问题，embedding反而容易把语义沾边但位置不对的片段捞上来。建议试试混合检索，BM25和向量各召回一部分再rerank，效果提升很明显。另外512字符切块对这种定位类问题确实偏大，可以试试按段落或函数边界切，语义完整性更好。

我之前也遇到过类似问题，后来换了方案。

我前段时间做类似的东西也踩过这个坑，最后发现光靠prompt硬怼确实有天花板。你说的两次调用思路挺对的，我现在基本都拆成“先判断这段话里有没有可抽取的信息，再单独抽”，比一口气全塞给模型稳不少。长对话也确实得切，超过一定token之后模型对中间部分的注意力明显下降，我一般按对话轮次切，保留一点上下文重叠。另外输出格式乱这个问题，可以试试用function calling或者response_for

我之前也这样，后来干脆把prompt当代码管了，丢进git里每个版本写清楚改了啥、为啥改。关键是每次只动一个变量，改完拿固定的一组测试case跑一遍，别凭感觉觉得变好了。那些“真的最终版”过两天自己都看不懂，还不如老老实实写commit message。

数据量几千条做函数级补全确实偏少，eval loss回升基本就是过拟合了，不是LoRA rank的问题。建议先加dropout和weight decay，再把LoRA挂到MLP层试试，只调attention确实容易欠拟合。显存20G+的话可以直接上QLoRA 4bit，4090完全能跑，省下的显存把batch size提上去效果会稳很多。另外代码补全任务bleu不太靠谱，换成编辑距离或者pass@

我试过把检索片段放最前面，历史对话压缩成摘要放中间，当前问题放最后，效果比全塞system里好很多。那个记忆块我也折腾过，单独拎出来容易让模型把它当新指令，反而更乱。关键信息强调我一般就在user里用括号重复一次关键词，别搞太花。你用的分隔符可能得跟Qwen2.5的chat template对齐，Ollama默认模板有时候会吃掉特殊token。

2k条其实不算少，但关键看质量。我踩过的坑是：负样本必须加，而且比例不能低，不然模型会过度倾向调工具，遇到闲聊也硬调。参数格式错多半是训练数据里工具schema不统一，或者多轮里历史工具结果没对齐，建议先抽查几十条确认格式一致性。另外工具调用这事SFT只是打底，推理时配个严格的parser做后处理能救回一大半。

历史对话别直接拼，先摘要再检索，混合检索也加上，稳很多。

几百条数据确实偏少，工具调用这种结构化输出对数据质量和数量都挺敏感的。你检查下训练样本里函数名和参数格式是否完全统一，字段顺序、空格这些细节不一致很容易让模型学乱。另外7B做tool calling不是不行，但建议推理时加上约束解码或者用outlines这类工具限制输出空间，能明显减少乱选函数的情况。

我也遇到过类似情况，感觉堆规则到后面模型反而更爱演，因为它把那些禁止项也当成了角色设定的一部分。后来我把寒暄和总结直接从输出格式里砍掉，只留一个极简的JSON schema，效果反而稳很多。负面指令确实不太靠谱，不如用few-shot给两三个“冷冰冰”的示例，让模型照着模仿。XML标签有用，但别拿它当万能药，结构清晰比标签数量重要。

上一代那个AI批改确实有点鸡肋，错题本功能聊胜于无。T90如果真能把星火大模型用到动态诊断上，我倒觉得关键不在技术多牛，而在于它敢不敢让孩子“跑偏”。你提的发散思维问题挺戳心，应试提分和培养思考本来就是两套逻辑，AI越精准反而越容易把孩子框死在标准答案里。除非产品设计时留出探索空间，否则再强的模型也只是个高级刷题机。

几百条对话量其实完全不用纠结RAG还是Agent，这个规模下你两个都可以直接上手试，成本低到可以忽略。你说的“上次那个方案”检索不到，本质不是RAG的问题，而是纯embedding丢了时间线和指代关系，加时间戳权重只是缓解，真正管用的是把最近几轮对话直接塞进context，再让检索去补更早的信息，相当于rag和短期窗口混着用。MemGPT那套剪枝逻辑对个人项目确实过重了，你可以先写个最简单的规则：

Prompt确实关键，但别光套模板，得结合自己场景多试几版才摸得准。

3090单卡跑8B，vLLM的PagedAttention确实更省，但int4对长文摘要多少有损，建议AWQ量化试试。

我一般会把types文件在对话里用@引用一次，让Cursor把类型定义读进上下文，光贴路径它有时候懒得翻。另外生成组件前先手动写好函数签名和Props解构，它填充实现时就不太容易跑偏。还有个坑是别让它自己新建类型文件，prompt里直接说清楚“只引用不新建”，不然它真会给你整一套平行类型出来。tab补全对这种强类型场景确实不太行，换agent模式会稳一些。

微调这块我踩过坑，直接拿错误+修正调用做样本对，模型容易学成“见错就套模板”，换个错误类型就懵了，最好还是构造带推理过程的完整轨迹。另外微调确实可能把原有的格式指令遵循带偏，得混一部分原始工具调用数据进去。但说实话，与其折腾模型，不如先在MCP层做错误归一化和自动重试，把确定性逻辑交给代码，模型只负责决策要不要重试，这样稳得多。

3000行就该上规则文件了，不然它真会到处乱插。小项目Cursor够用，大了得靠.cursorrules管着。

工具描述里把“什么时候该用”写清楚，光写功能不够。GPT-4o-mini确实容易犯这毛病，加几个few-shot基本能救回来。