周末移动开发成长录

MCP的流式返回确实得自己拼，建议试试用官方SDK里的顺序事件累加，别手动搞buffer，丢包问题能少点。 我之前也踩过这坑，后来直接改成回调里攒chunk，等end再组装，比硬拼稳多了。

重排序必须加，bge-reranker配混合检索能救回来不少，切片别死磕固定值，按语义段落走更稳。

两千条数据跑LoRA其实有点悬，特别是客服对话这种任务，格式和意图分布稍微偏一点，微调后反而会盖住基座原有的泛化能力。建议先看看是不是学习率设太高或者训练轮数过多了，LoRA通常几个epoch就够，跑太久容易灾难性遗忘。另外你用的基座模型本身可能就不太适合中文客服场景，换个中文指令微调过的基座试试，效果可能会差很多。还有个小技巧，推理时把temperature调低点，有时候是采样随机性在捣乱，不一

权重别固定死，试试0.3/0.7或者按query动态调，长文档截断加位置惩罚更关键。 查询改写对专有名词挺管用，但多向量模型可能更省心，建议先小批量对比下。

这问题我也踩过坑，现在习惯是把关键决策直接写进项目里的AGENTS.md或者TODO文件，每次改需求前先让Agent读一遍再动手。另外把需求拆成小步骤，别一口气全塞进去，能减少它“自由发挥”的概率。不过说实话，指望它完全记住上下文还是不太现实，版本控制该用还是得用。

`--max-num-seqs`确实得手动调一下，vLLM默认会按显存余量动态分配，但并发一高它容易把KV cache撑爆，我遇到过类似情况，设成8或者16能明显缓解。AWQ本身没问题，4bit下模型权重才5G不到，撑爆显存的肯定不是权重。另外你`gpu-memory-utilization 0.9`留给KV cache的比例其实偏激进，可以试试0.85，同时把`--max-model-len`降

我之前做设备维修知识库也撞过这个坑，换模型调chunk size都试过，最后发现是召回链路里“检索”和“重排”脱节了。Embedding只解决语义相似度，但你的PDF里“配置静态路由”和“OSPF邻居失败”如果出现在同一章节的上下文里，向量距离可能比想象中近得多。建议先看看你用的检索方式是不是纯向量top-k，试试混合检索，把BM25的关键词匹配分数和向量分数加权合并，对技术文档这种术语密集的场景

我之前也遇到过一模一样的情况，最后发现问题出在MCP返回的tool schema和DeepSeek官方function calling的字段名有细微差别上。FastMCP默认会在parameters外面包一层自己的结构，但DeepSeek这边认的是最原始的JSON Schema，你得手动把那个多余的嵌套剥掉才行。另外空响应大概率不是模型不支持，而是它已经解析出函数调用，但你的代码没把tools结果

说实话你这个情况我太懂了，之前调的时候也差点摔键盘。后来发现别死磕固定值，直接按段落结构切分比纯按字数靠谱，比如用markdown的标题层级当边界，chunk size设成512上下，overlap给个50-100就够。代码和纯文本真得分开处理，代码块建议整块保留别硬拆，不然语义碎得没法看。你可以试试先用一个小的验证集跑几轮，看哪些chunk是答不全的元凶，再针对性调，比盲目试参数高效多了。

你这情况我也遇到过，例子给多了确实容易把模型“带偏”，它会更倾向于模仿你给的格式而不是理解你想要的多样性。我现在的做法是，先给一个最典型的正例，然后明确告诉它“这只是风格之一，其他产品请用不同句式表达”，再配一个反例说明“不要这样写”。比如你写卖点，可以给一个标准句式，再补充一句“请避免重复使用这个结构”。临界点的话，我一般控制在3个例子以内，超过这个数模型就开始偷懒了。另外，如果你发现它开始套模

建议按话题片段分段存向量，同时用时间戳+话题标签做metadata，召回时按相似度和时间范围过滤。

这配置按理说跑7B模型不会这么惨，A100 80G给满0.9利用率的话，光模型权重也就占15G左右，剩下60多G够塞不少KV cache了。我觉得问题可能出在max_model_len和gpu_memory_utilization的组合上——你设了4096但显存利用率只有0.9，vLLM会按0.9去预分配显存，但实际每个请求的KV cache是按max_len动态分配的，如果并发数多或者请求长度超

刚踩过类似的坑，强烈推荐试试“分步拆解+角色锚定”的结构。比如你那个SQL检测任务，可以让GPT先扮演安全专家输出风险点列表，再另起一轮让它格式化——混在一起写prompt，权重一乱输出就崩。长上下文的话，我现在会主动给关键段落打标签，像代码里加注释一样，模型抓重点准很多。

这个问题我也踩过坑，bge-large-zh对中文长文本的语义捕捉确实不够细，尤其是512token切分后，上下文断裂是常态。我后来试了按自然段落切分，再配合一个小的重排序模型（比如bge-reranker），效果比单纯调chunk overlap稳定不少，至少检索到的片段相关性有明显提升。另外你提到的“训练loss下降异常”这种场景，其实很考验embedding对专业术语的聚类能力，我怀疑你的切

bge+Qwen组合确实召回准，但细节缺失可能是chunk切太粗了，试试调小点。

同感，我之前跑Qwen微调也踩过这个坑，感觉LoRA在小样本下容易把模型“教死”，让它过度拟合工具格式，反而牺牲了原版的推理泛化能力。你试试在微调数据里混入一些负样本（比如故意跳过步骤的错误例子），或者把微调学习率再调低一点，有时候保留一点原版的“模糊推理”反而更管用。

r=8确实偏低了，试试升到16或32，LoRA的秩对微调效果影响挺大的。