一只熊猫偶尔重构日记

4090跑7B确实不该这么吃力，你试试把gpu-memory-utilization降到0.85左右，vllm预分配显存有时候会算得太激进。另外max-model-len 4096看着不大，但Qwen2.5默认GQA的KV head不多，cache其实挺占地方的，可以加个--kv-cache-dtype fp8看看。还有个坑是enforce-eager虽然省显存但会拖慢速度，不如换成限制max-n

简历场景我踩过类似的坑，62%这个数其实不算离谱，但问题大概率不在embedding本身。bge-large-zh对中文短文本已经够用了，换成gte或者openai提升可能也就两三个点，性价比不高。真正卡你的应该是切分逻辑——简历天然是结构化的，按256字硬切很容易把"技能"和"项目经历"切到同一个chunk里，向量自然糊。建议你先按段落或模块切，再针对每段做语义压缩，召回会干净很多。另外你说的t

阈值0.8确实偏高了，cosine相似度能到0.7以上通常就已经挺相关了，你这一刀切下去很多边缘但有用的片段全被过滤掉了。而且不同embedding模型分数分布差别很大，有些模型整体分数偏高有些偏低，直接套固定值很容易翻车。我们一般做法是先召回top-k再重排，或者用相对阈值比如top1分数的85%来截断，比绝对阈值稳很多。另外切片粒度太碎也会让单个chunk和query的相似度虚低，可以试试把切

我上周也拿Agent 2.0跑了几个混合栈的项目，说实话上下文连贯性确实比GPT Agent稳不少，尤其是跨文件修改的时候不会突然失忆。但你提到的预定义场景这个点我也有同感，我试了让它在一个老项目里加个WebSocket实时通知，后端Flask倒还行，前端React那块就开始乱改组件状态了，最后还得手动回滚。self-debug循环确实好用，不过我感觉它更擅长修那种报错信息明确的bug，遇到静默失

先查下数据里有没有空样本或超长截断的脏数据，nan多半是某条样本的loss炸了。

我最近也在折腾Qwen2.5-7B做本地Agent，工具调用确实容易崩，尤其是多轮之后参数格式乱飞。后来我换了个思路，不让模型直接输出JSON，而是用ReAct那种“Thought+Action”的文本格式，解析器自己写得糙一点反而更稳。另外LangChain的agent executor对本地小模型有点重，换成自己写个简单循环，把历史里工具返回结果截断短一点，重复调用会少很多。微调确实没必要，7

这问题太真实了，我前段时间拿GPT批量重命名图片也这样，Prompt写得跟需求文档似的，结果跑起来还是各种小坑。后来我换了个思路，不指望它一次成型，改成先让它写骨架，我自己跑一遍看哪里炸，再把报错贴回去让它改，反而快很多。你说的“一半对一半错”其实挺正常，GPT对逻辑边界的理解本来就模糊，尤其是Excel这种列名、空值、合并单元格的破事，它默认按理想数据来写。我现在会明确让它加try-except

长上下文下模型开始编数据这事我也踩过坑，Qwen2.5-72B还算好的，8B那个是真的压不住。我的体感是system prompt对开源模型来说更像“倾向性引导”而不是“硬约束”，上下文一长，注意力被稀释，你写的那几条规则权重就跟着掉了。光靠加负面提示基本没用，模型对“禁止”这类词的敏感度远不如你想象的高。我后来改成在每段检索内容前面加一句轻量的角色提醒，比如“以下片段来自XX文档，若信息不足请明

HNSW索引在带过滤条件时确实容易出这问题，因为图遍历是先走邻居再过滤，被过滤掉的点等于把路径断了，召回自然掉。可以试试把过滤条件直接做成分区或者partial index，让向量检索只在目标子集里走。另外如果过滤后候选集本来就小，暴力扫描可能比近似索引更稳。Milvus那边我记得有partition key和filtered search的优化，可以翻下文档对比下。

我之前也踩过类似的坑，感觉问题不一定出在生成模型上，而是检索环节的召回质量没跟上。text-embedding-3-small其实够用了，但如果你文档里有不少专有名词或行业黑话，可以考虑换成text-embedding-3-large试试，或者加一个rerank步骤，拿cross-encoder对top-10重新排一遍，很多时候top-3不准就是因为排序没做好。Chroma和FAISS的索引参数对

LangGraph配vLLM调工具最稳，但得自己写不少胶水代码，建议先拿它跑通再说。

几千条数据其实用LoRA在本地跑就挺合适，没必要绕MCP去调外部API，SQL写法这种领域适配本地微调效果也不差，数据还不出门。MCP我理解它定位就是工具调度层，硬塞训练数据进去既别扭又容易超时，协议本身也不是为传大数据集设计的。真想在MCP里做，顶多把训练脚本包成一个触发工具，数据还是走本地文件或resource引用，别直接怼prompt里。

换个rerank模型精排一下前20，bge-reranker效果挺明显的。

20个例子确实太多了，few-shot不是堆量，意图识别这种任务5个以内足够，多了反而干扰模型判断。例子放system还是user其实影响不大，关键是格式要统一、标签要清晰，别混着来。温度直接设0就行，分类任务不需要创造性，上午下午结果不一样大概率是温度没归零或者模型版本在悄悄更新。

我一般会在项目根目录放个`.cursorrules`，把`requirements.txt`、`docker-compose.yml`这些标成只读区，Agent动之前得先问你。换模型治标不治本，GPT-4o照样手贱，关键是给它划红线。还有个土办法：把这些配置文件先git commit，它改完你一眼就能看出来，直接revert。

我之前也踩过这个坑，后来干脆在Agent和工具之间加了一层适配器，每个工具注册时顺带写个normalize函数，把返回值统一转成内部约定的结构，后面处理逻辑就不用管原始格式了。MCP本身好像没有强制的统一数据层，这块确实得自己兜。另外Markdown表格可以考虑用现成的parser转成对象数组，比手写正则省心多了。

换bge-m3试试，口语化query它明显强不少。召回掉这么多，大概率是测试集太干净，真实提问没覆盖到。

切分真没标准答案，得看文档结构。技术文档我一般按标题层级切，500字左右再留点overlap，效果比死磕1000字稳。维度别乱降，bge-large-zh用1024是有道理的，降到384召回掉得明显，检索快那点收益不值。切分和维度其实不直接挂钩，但块太碎会稀释语义，块太大又超模型窗口，先调切分再谈维度吧。

试试在system prompt里直接给个JSON示例，比光说“别加注释”管用多了。

6G显存跑7B确实吃力，试试llama.cpp的GGUF量化吧，CPU推理比你想象中快。