长期关注品牌实践笔记

试试AWQ或GPTQ量化，7B压到4bit显存直接砍半，A100跑起来轻松多了。

我之前也踩过这个坑，流式拼接最怕的就是半包和乱序。后来在Agent和MCP之间加了个缓冲层，按换行符切分再逐条解析，比直接拼JSON稳很多。丢包的话建议给每个chunk带个序号或者用SSE的id字段做校验，不然确实对不上。LangChain那边可以用自定义callback把流式结果转成结构化事件再喂进去，别硬塞JSON。

我一般会把prompt拆成“固定框架”和“可替换块”两部分，比如把数据处理逻辑写成模板，变量用占位符标出来，改需求时只动那一小块。另外可以试试把常用指令存成片段，像搭积木一样拼，比从头写省事多了。不过GPT有时候会忽略细节，所以关键约束最好在prompt里重复强调一下，别指望它自己记住。

我一般会先用小样本测模型对标签词位置的敏感度，比如把标签放前面和后面各跑一轮，看它是不是在复制例子。你遇到的复制标签问题，试试在few-shot里故意混入一个不同格式的样本，或者把标签换成同义词再映射回去。另外别光靠手调，用promptfoo或dspy这类工具做批量对比，至少能把随机性压到可复现的范围内。真要系统化，还是得盯着logprob看模型到底在选哪个token，别只看输出文本。

0.9的gpu_memory_utilization确实太激进了，降到0.85试试，给系统留点余量。

5-6 steps/s 对于7B LoRA在4090上确实偏慢，我这边类似配置能跑到12-15左右，关键差别就是flash attention。没开FA的话attention那块计算量大不少，而且序列512其实不算短。建议先把attn_implementation换成flash_attention_2，再把gradient checkpointing关掉试试，应该能明显快一截。另外确认下peft版

512定长切还没重叠，问题大概率就出在这儿。你问的是“2023年第四季度营收”，关键词集中在几个字里，切碎了之后语义早散了，bge-small中文本身对长文本也不敏感。建议先把chunk换成按段落或标题切，加个50到100字符重叠，再往query前面塞点提示词试试召回。Cursor生成的代码逻辑一般没问题，但它默认那套切法就是够用级别，真跑业务还得自己调。

这个“写着写着就丢了”太真实了，我最近也踩过一模一样的坑。我感觉问题不一定在模型，而是我们给的业务背景是叙述性的，它更像在“读故事”，而不是在执行一份清单。像退款窗口这种硬规则，如果混在一大段背景里，它就很容易在生成过程中被稀释掉。我后来试过一个办法，把硬约束单独抽成结构化的禁止项和必含项，再让它生成完自己逐条打勾检查，漏了就重写。另外新员工Prompt模板这种场景，可能更适合先给一个合格样例，让

我之前也踩过这个坑，工具说明放System确实容易被多轮对话稀释，后来改成System里只放工具名和一句话用途，详细的参数schema用结构化JSON单独走一个tool定义字段，模型反而更稳。你用的框架如果支持原生function calling，就别硬塞prompt里了，省token还准。

简历这种结构化文本用固定长度切确实容易把一段经历拆散，试试按项目或工作经历分段切，每段自带上下文会好很多。bge-large-zh本身不差，先别急着换，加个bge-reranker-base在top20上重排，中文场景提升通常比换embedding明显。另外你检索时可以把岗位JD或问题关键词拼进去做query扩展，简历问答里query太短是召回杀手。

全参数微调跑两天确实容易把基座能力带偏，疯狂换行和重复基本就是学习率太大加上数据量不够撑全参的典型症状。你几千条数据用LoRA更稳，全参至少要上万条且lr得压到1e-6以下。至于“其他”类不输出，我觉得不一定是数据不平衡，更可能是sharegpt格式里system prompt把模型带偏了，或者推理时的生成参数有问题。建议先固定住解码参数，再拿几百条测试集做个混淆矩阵看看，别急着调采样。

这个坑我去年踩过好一阵，最后发现光靠LangChain自带的max_retries根本不够用，因为它对工具级别的异常处理其实挺粗的。我的做法是在每个工具函数外面包一层自定义的retry decorator，用tenacity那种带指数退避的，区分一下哪些错误值得重试（超时、连接错误），哪些直接放弃（参数错误、权限问题）。另外Agent那边最好也加个fallback，工具彻底挂了就让模型基于已有信息

5000条数据3个epoch确实容易过拟合，先查查数据里有没有大量重复或低质样本吧。

LangGraph 确实更适合这种常驻场景，把状态存外面，Agent 图只建一次就行。

Qwen2.5-7B用vLLM在A100 80G上，FP16权重就占15G左右，加上KV Cache和激活，实际并发上去显存涨得很快，20个实例那是理论值别当真。我之前跑过类似配置，单卡稳定支撑8-10路并发比较现实，再多TTFT就压不住了。4卡张量并行延迟能降但吞吐未必划算，2卡各跑一个实例加负载均衡对知识库问答这种场景更实用。AWQ 4bit掉点其实还好，知识库问答基本感知不到，但2秒内响应得

我用Pydantic做state，字段按流程分成输入、中间、输出三块，中间数据只留必要摘要，原始API response单独存Redis或文件，state里放引用key就行。并发不用太担心，LangGraph节点默认顺序执行，真要并行就用reducer合并。回滚的话我是在关键节点前checkpoint整个state，失败了从上一个checkpoint重跑，别想着原地恢复。

FP16卡23G基本就是KV Cache在吃显存，Qwen2.5-7B的KV头数不算少，上下文一长就顶不住。可以试试vLLM或者SGLang开PagedAttention加gpu_memory_utilization，能挤出不少空间，KV Cache量化到FP8也基本不掉质量。4bit掉智商主要是权重误差累积，试试AWQ加更小的group size，或者用GPTQ的act-order版本会好一些。

这种“排十几名开外”的情况我遇到过，大概率是chunk把关键参数和上下文切散了，比如“最大连接数”和具体数值分到两块里，embedding再强也救不回来。你可以试试按语义段落切，别死守300字，或者把标题和层级路径拼到chunk前面一起编码。另外top-20里真正相关的排后面，不如加个轻量rerank模型捞一把，bge-reranker-base就很便宜。bge-m3本身没问题，先别急着换。

bge-large-zh直接拿来用确实不一定比3-small强，尤其你没加instruction前缀的话效果会差一截，它训练时query和passage是分开编码的。我之前也踩过这个坑，加上"为这个句子生成表示以用于检索文章："之后召回明显好了。chunk 500对中文长文档偏小，可以试试800-1000再带点overlap，语义完整度会好很多。

这问题太真实了，我去年做类似项目也是demo惊艳上线就崩。后来发现关键不在框架，而在你有没有把任务拆到模型每次只需要做一个“二选一”的判断。如果单个节点里模型要同时决定调什么工具、传什么参数、要不要追问，那出错率是指数级上升的。建议先别急着加规则兜底，拿一批真实case跑个混淆矩阵，看看模型到底在哪个决策点上翻车，很多时候是提示词里的选项边界没写清楚。