从零开始商业修炼册

2k条数据其实不算少，但关键看分布。工具调用的能力SFT肯定能灌进去，但模型得先学会“什么时候不该调”，负样本一定要加，比例可以占到20%到30%左右。参数格式老出错的话，检查下你的loss是不是只算在assistant回复上，tool call那段的特殊token有没有被mask掉。另外Qwen2.5本身function calling底子不错，prompt里把工具schema写清楚再配合微调，

8张A10跑7B其实挺宽裕的，关键是别死磕单卡batch size。vLLM开张量并行2或4，把并发摊到多卡上，再配合PagedAttention和chunked prefill，50并发问题不大。量化我建议优先试AWQ，比GPTQ稳，4bit下乱码基本能压住。粗略估算的话，7B的4bit权重约4G，KV cache按每token每层2×2×hidden算，单条2K上下文大概1G出头，乘并发数再留

我一般是直接在.cursorrules里把“禁止新增抽象层”写死，还加了一条“除非我明确要求，否则不要拆文件”。PropTypes那个确实烦，后来发现是它默认套ESLint模板，在rules里写“项目使用TypeScript，禁止任何PropTypes和defaultProps”就消停了。至于看代码库风格，可以试试在对话里先@几个你写得最满意的现有组件，说“照这个风格来”，比纯文字描述管用多了。

我遇到过类似情况，感觉你卡在召回这步真不一定是embedding的锅。表格和流程图这种结构信息，bge-large-zh本身对纯文本语义还行，但它没法理解“表格旁边那段总结”和表格之间的空间关系，切完chunk之后这种关联直接断了。你把chunk_size调到200反而更差，大概率是因为表格被切碎，上下文更不完整了。我觉得可以先别急着换colbert，试试按文档结构做分块，比如用unstructu

我之前也踩过这个坑，后来发现与其在检索端硬调，不如在入库前用LLM给每个chunk生成一句“这个片段具体回答了什么问题”的摘要，把摘要拼到原文前面再embedding，召回精准度提升很明显。另外rerank确实值得加，bge-reranker跑一遍top-20重排，泛泛段落基本就被压下去了。query改写也可以试试，但别指望它单独解决信息密度的问题，配合前两步一起上才稳。

7B模型确实在指令跟随上会弱一些，尤其是Qwen2.5这种偏基础的版本，你描述的那种跑偏和重复生成，很多时候不是Prompt结构本身的问题，而是模型对长上下文里关键信息的抓取能力有限。我自己用类似规模模型做知识助手时发现，把“请基于以下资料回答”改成更硬的结构约束会好很多，比如直接写“只根据下面三段内容回答，不要引入其他信息，如果资料里没有就说不知道”，这种否定式加边界限定比单纯说“基于资料”管用

先做rerank按相关性截断，再对高分段做句子级压缩，比调chunk size靠谱。

几十万条这个量级其实两个都能扛住，关键还是你提到的重启加载和过滤这两点。我自己之前也踩过FAISS的坑，后来单机场景直接上了Qdrant，docker一个容器起来就能用，持久化是默认带的，重启不用重建索引这点真的省心。过滤这块Qdrant的payload filter做用户ID筛选挺顺手，而且它过滤和向量检索是融合执行的，不会先全量召回再筛导致性能塌方。Milvus功能确实更全，但单机跑stand

模板对齐这块确实容易踩坑，训练时加“请调用xxx工具”这种前缀，线上用户肯定不会这么规范说话，分布一偏模型就懵了。另外只调最后一层可能不太够，LoRA一般建议至少挂到注意力层的q和v上，不然模型很难学到新的调用模式。可以试试把训练数据里的指令改得更口语化、更随机一些，跟线上真实输入靠拢，泛化会稳不少。

分步要函数骨架先，再单独让它补异常，一次全塞容易漏。

光靠Prompt确实很难压住，模型看到点相关内容就忍不住往下编。我一般的做法是让模型先输出结构化结果，比如带个“是否找到答案”的字段，再在代码里判断，只有明确命中才让它生成正文。阈值的话可以分两档，高阈值直接答，中间那段就只回答“不确定”，别硬凑。另外System Prompt里可以要求它引用原文句子，编不出来就说明该拒答了。

topk降到5试试，再不行加个rerank模型筛一遍，杂音少很多。

我之前也踩过这个坑，Claude对MCP prompt里的参数类型确实不太敏感，光靠description写“必须是字符串”基本没用。后来改成在模板里用XML标签把每个参数单独包起来，比如`<file_path>{file_path}</file_path>`，情况好转了不少。另外建议参数名别太泛，`action`这种词容易被模型自己脑补成别的语义，换成`operation_type`之类的会稳定

我也遇到过这问题，后来把状态拆成子图，每个Agent只管自己那块，回传校验用独立通道，清爽不少。

我之前也踩过类似的坑，LangGraph那套状态机本质上就是个编排层，它并不关心你底层用的是OpenAI还是本地模型，但问题恰恰出在它默认的生态是围着LangChain那套抽象转的。你手动序列化JSON、自己管上下文窗口，其实是在重新实现LangChain里已经有的东西，只是它跟PyTorch原生推理之间没有现成的桥。我的建议是别急着用PyTorch重写整个流程，那个工作量比你想的大得多，尤其是工

几十万条暴力检索还能扛，但过滤条件一多延迟准崩，上HNSW后基本能稳在几十毫秒。

我之前也踩过这个坑，跑几秒断掉大概率不是防火墙的事，是stdio那层被日志污染了。MCP走stdout传JSON-RPC，你代码里任何print或者库的debug输出都会把协议帧冲烂，Cursor那边就以为连接挂了。建议把日志全改到stderr，再确认下server别自己退出，异步任务记得await住。

同感，换数据集就崩多半是例子标签分布太偏，试试把few-shot打乱再随机采样几个负例？

我折腾过一阵子，感觉 MCP 真正省事的地方在于工具复用和动态发现。你直接写 function calling，每接一个新模型或新客户端都得把 schema 重写一遍，工具一多就乱。MCP 把这些抽成独立 server，Claude、Cursor 这些都能直接挂，换模型不用重写。但配置确实烦，尤其是本地跑多个 server 的时候，调试起来比直接调 API 绕。所以我一般单模型单工具就懒得上了，多

TopK这个事我也折腾过挺久，后来发现单纯纠结这个数值其实有点治标不治本。你那个不同查询得分分布差异大的问题，本质上是embedding空间的相似度没法跨查询直接比较，所以固定阈值基本是条死路。我现在的做法是TopK先设大一点比如30到50，然后接一个轻量级的rerank模型，用cross-encoder对query和每个片段做精排，取分数最高的5到8个喂给LLM。这样召回率和精度能同时兼顾，代价