边学边做安全成长记

显存只涨不降大概率是KV cache没清干净，对话历史一直往context里塞，每次前向都在旧cache上叠，不涨才怪。你可以试试每轮只保留最近几轮历史，或者把工具返回的长文本先摘要再拼回去，别原样丢进去。另外记得推理时用torch.no_grad()，不然计算图会一直挂着。

换问法就检索不到，这个现象其实挺典型的，大概率不只是chunk大小的问题。固定512 token切分对纯叙述文本还行，但一遇到表格和跨页逻辑就很容易把语义切碎，检索时query和chunk的向量对不上也正常。你可以先试试按标题层级或者段落做结构化切分，表格单独拎出来走一套处理逻辑，别硬塞进512里。语义切分确实值得上，LangChain里SemanticChunker配合你的BGE先跑个小样本对比

单卡A100 80G跑7B按理说4K长度不至于崩，你这OOM大概率不是模型权重的问题，而是KV cache被并发撑爆了。vLLM默认会按gpu_memory_utilization预分配一大块显存给KV cache，但并发数一上来实际占用会超，建议把max_num_seqs调小点试试，比如设成8或16。另外tensor_parallel_size单卡就别设了，保持1就行，设错了反而会出问题。还有看

loss降到0.9不代表生成质量就上去了，代码任务里交叉熵和语法正确性经常是两码事。2e-4对LoRA来说确实偏高了点，3个epoch加上2万条数据，很容易过拟合到训练集的局部模式上，重复片段和括号不闭合就是典型症状。QLoRA本身问题不大，但4bit量化在长序列生成时确实会放大这种不稳定性。建议先把学习率降到5e-5左右，跑1-2个epoch看看eval的语法通过率，另外检查下训练数据里有没有大

这种敏感度我也遇到过，不过一般是在7B级别的小模型上，72B按理说稳得多。你试试把temperature降到0.3左右跑一遍对比，有时候是采样放大了prompt的扰动，跟模型本身关系不大。另外system prompt开头那几句权重挺高的，改措辞等于动了整个注意力分布的锚点，出现重复废话可能是模型在重新找格式。真要排查建议固定随机种子，同一prompt多跑几次看方差，不然很难分清是prompt问题

我们线上跑客服Agent也踩过这个坑，后来改成短期窗口保留最近几轮原文，更早的走向量库单独存记忆，检索时按query动态召回。关键点是摘要不能替代原始对话，多步工具调用时最好把每步的中间结果挂到当前turn上，而不是反复重写全局摘要。另外“昨天”这种时间指代，建议在检索前先做一轮query改写，把相对时间转成绝对时间再进向量库。

这个坑我踩过，感觉问题不在Prompt写得不够细，而是你把每个子任务的约束塞得太满，模型在串联时反而没有“余量”去理解上游的真实意图。单步测试好是因为上下文干净，一旦进入Agent链路，前一步的输出会带着噪声和格式残留，后一步的Prompt再详细也架不住输入本身已经漂了。我现在更倾向把中间步骤的输出结构定死，比如强制JSON schema或者用代码做一层解析校验，而不是指望LLM自己稳住格式。另外

RAG和记忆确实该分开，我一般用不同collection加metadata过滤，不然召回全乱套。

你这个场景其实挺典型的，很多人一开始都会把MCP和DDP混在一起理解，但这两个东西的抽象层级根本不一样。MCP管的是上下文和工具调用的状态，DDP管的是参数梯度同步，硬凑一起确实容易出问题。我理解你说的“上下文污染”其实不是DDP直接改了什么，而是你在每个rank上维护的client上下文各自独立，但DDP的allreduce又要求所有rank的梯度一致，结果就是不同client的在线学习信号被平

玄学感主要来自你把prompt当咒语而不是接口，其实它更像在给模型划定搜索空间。建议先啃OpenAI和Anthropic的官方prompt指南，再配合CoT、ReAct这些基础范式做对照实验，每次只改一个变量并记录输出差异。真正拉开差距的是评测集，攒几十条带标签的样本，用A/B对比替代凭感觉判断，慢慢就有手感了。参数那部分先别急着调，温度默认值够用，等prompt稳定了再动。

全局系统提示词定风格，每步只写增量指令，不然格式反复解释肯定乱。

你这个问题我踩过一模一样的坑，当时也是所有东西往一个dict里怼，结果节点一多自己都忘了哪个key是哪步写的。后来发现核心问题其实不在State大小，而在于你有没有把“消息历史”和“业务数据”分开存。LangGraph里messages字段是会被自动累加和传递的，但如果你把工具返回的JSON直接塞进普通字段里，下一轮节点读到的上下文里就只剩最后那次写入的值，前面查库存的结果自然就没了。我现在的做法

维度这事儿真不是越高越好，我踩过类似的坑。你从1536降到256/512效果忽好忽坏，很可能不是维度本身的问题，而是降维方式不对——直接截断或者PCA硬压，语义信息损失得厉害，召回质量自然飘。384维的sentence-transformers（比如MiniLM）其实是专门训练过的，跟ada-002混用问题不大，但前提是你得统一用同一个模型编码query和文档，混着用不同模型反而会翻车。速度慢这事

先别急着怀疑量化，用onnxruntime和PyTorch同一张图跑一遍中间层输出，看是从哪层开始偏的，Focus和SiLU确实容易出问题。

代码补全任务数据太杂确实容易卡loss，建议先清洗下数据，再换cosine调度试试。

我也经历过这个阶段，后来发现关键不是堆指令，而是控制变量。每次只改一个地方，比如只调few-shot示例的数量或顺序，记录效果变化，慢慢就能摸出哪些因素真正影响输出。另外建议试试把任务拆成多个简单调用串起来，比一个巨型Prompt稳定得多。最近在看DSPy那个方向，感觉比手动炼丹靠谱一些。

几百份文档全塞RAG确实容易翻车，试试先按时间或主题做个粗筛，再检索，能准不少。

角色冲突导致任务死锁这点太真实了，我之前搞多Agent协作也是卡在这儿，最后靠一堆if-else硬撑。StaffDeck用岗位定义自动生成行为约束的思路确实省事，但“绩效”那部分我比较怀疑，Agent的任务完成质量本来就很难量化，搞不好最后又变成人工打分。而且平台抽象层一厚，调试的时候出问题都不知道该从哪查起。

2万条数据做法律文书分类其实不算少了，BERT-base-chinese正常微调应该能work。你验证集F1掉4个点这个现象，我第一反应是label mapping或者数据里有没有脏标，尤其法律文书这种专业领域，标注一致性很容易出问题，建议先抽几十条看看标签有没有明显矛盾的。过拟合那个信号倒是挺明确的，train和val loss越拉越开，说明模型在死记训练集，这时候加class weight和f

schema校验是底线，但光靠它不够，因为模型编的字段有时能通过语法校验却语义错误。我们线上做法是在工具层加一层参数白名单和类型强校验，解析失败就自动把错误信息塞回上下文让它重试，最多两轮。实测GPT-4o在明确报错反馈下修正率挺高，但prompt里工具描述千万别写太长，越啰嗦它越容易脑补。