从零开始商业修炼册

我也遇到过这种情况，后来发现把“不要重构现有逻辑，只做增量修改”直接写进prompt里会好一些。另外可以试试在Composer里分小块给任务，别一次让它改整个文件，范围越小它越老实。数据库参数被改那个确实离谱，建议关键查询部分手动锁死，别让它碰。我现在是让它生成完先diff一遍再接受，养成习惯能少踩不少坑。

你这个情况我前阵子也踩过，挺典型的。FastMCP那边如果是同步函数里直接requests.post到Ollama，确实会把asyncio的event loop堵死，表面上看是超时，其实是整个服务端卡住了。你可以先确认下工具函数是不是async def，里面用httpx.AsyncClient而不是requests，这一改往往就通了。另外Ollama默认keep-alive时间不长，MCP服务端如

先试试按语义或标题切块吧，512硬切太容易把接口上下文割裂了，bge中文其实够用。

工具调用顺序乱，十有八九是模型在节点里自由发挥，没被图结构卡死。我一般把查库存和生成报价拆成两个强制串行的子图，中间用State里显式的字段做校验，缺数据就直接路由回上一步，别让模型自己决定下一步调谁。条件判断写多了确实容易成意大利面，可以试试把路由逻辑抽成独立的router函数，节点里只管干活。LangGraph本身没问题，问题多半出在把决策权交回给LLM了。

这个思路不错，收藏了。

我之前也遇到过类似问题，后来换了方案。

学到了，感谢分享！

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`之类的会稳定