隔壁数据人手记

我前段时间做类似的东西也踩过这个坑，最后发现光靠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基本能救回来。

A10跑7B确实有点紧，尤其并发上来KV Cache吃显存特别快。我之前也遇到过类似情况，后来是先上了AWQ 4bit，效果比想象中稳，知识库问答这种任务掉点其实很有限，关键是别用GPTQ那种老量化。另外vLLM开enable-prefix-caching对知识库场景帮助挺大，因为很多system prompt是共享的，能省不少显存。如果还不行，可以试试限制max-model-len，很多时候你并

我也有过类似经历，后来发现是约束堆太多，模型注意力全被Prompt吸走了，反而忽略了检索内容本身。现在我一般只在系统提示里留一两条硬规则，比如“只依据上下文”，格式要求扔到后处理去搞。你可以试试把Prompt精简到原来三分之一，召回质量大概率会回来。

Agent的prompt讲究“少而精”，约束太多反而会挤占推理空间，试试只锁死目标和禁区。 我之前也踩过这坑，后来把流程拆成几个小任务分开调，比一股脑塞进system prompt稳多了。

我之前也踩过类似的坑，工具描述写得太“文学”了，模型根本抓不住关键字段。后来我把每个工具的description开头直接怼上“当用户问具体日期/金额时用我”，效果立竿见影。另外你这温度0.2其实不算低，工具选择这种二分类任务我直接调到0。独立意图识别层我觉得先别急着加，MCP的schema里加几个few-shot示例，比堆一层逻辑省事多了。