刺猬爱写代码日记

试试把LoRA的rank调小点，再开gradient checkpointing，我4090跑8B bf16也就batch=2。4bit微调确实容易掉点，不如试试QLoRA配小rank。

query改写这块可以试试用LLM先把口语化的问法扩写成带具体技术词的版本，比如“调参不爆显存”扩成“PyTorch训练降低显存占用的技巧 batch size gradient checkpointing”，召回质量会明显不一样。rerank我用的bge-reranker-base，效果有但别指望它救回压根没召回的段落。另外你chunk 300字对技术博客偏碎了，操作步骤容易被切断，可以试试按标

我一般把格式约束直接塞进工具返回那层做校验，模型跑偏就自动重试一次，比死磕Prompt管用。

试试给agent加个should_continue的条件边，让它自己判断答案够了就直接结束，别硬跑满轮数。

我前段时间也踩过这个坑，检索看着没问题但生成还是飘，后来发现是chunk切得太碎了，top5拼起来上下文不连贯，模型只能自己脑补。你可以先把检索到的5个chunk原样拼成一个prompt手动喂给GPT-4看看，如果这样它能答对，那问题就在拼装或者chunk粒度上，不是检索本身。另外bge-large-zh对长query有时候召回会偏，试试把用户问题改写一下再检索，或者加个rerank模型过一遍。还

query改写加个小模型rerank确实管用，先让LLM把口语转成关键词再检索，召回准多了。

这个断联问题我前段时间也踩过，折腾了半天才发现是异步任务没处理好。MCP的stdio传输对进程生命周期挺敏感的，如果你的工具函数里有await没跑完就返回，或者后台起了个task没join，Cursor那边很容易就判定transport closed了。你可以在工具处理函数里加个try/except把异常打出来，很多时候是子进程悄悄崩了但没报错。另外文件搜索这种IO密集的操作，建议在handler

参数传错这事我也遇到过，感觉根子不在Prompt写得多细，而是模型对“上周”这种相对时间根本没概念，你不给它当前日期它只能瞎猜。customer_id和order_id搞反更典型，光靠schema约束不住，得在工具层做参数类型校验，传错直接返回明确报错让模型自己重试。另外few-shot例子最好覆盖边界case，比如“上周”要给出具体日期换算的示范，比干巴巴写规则管用。工程上校验加有限重试基本是标

你这个情况我遇到过，bge-large-zh在长文档上确实容易把泛泛的概念段排前面，因为语义相似度高但信息密度低。建议先别急着换模型，加个bge-reranker对top20做重排试试，召回率能明显提一截。分块上512字符对案例类文档有点碎，可以按段落或标题层级切，再给每块拼上文档标题和所属章节当上下文，检索命中率会稳不少。

说入门的话我觉得能稳定写出让模型按格式输出、少胡编的prompt就算摸着门了，别一上来就追求什么万能模板。进阶其实更多是往评测和迭代上走，比如同一任务攒一批case反复对比改动效果，而不是凭感觉调词。我自己踩过的坑是光堆技巧不建反馈闭环，调半天也不知道到底变好没变好。你们平时会专门做小规模测试集吗，还是直接上手试？

这个坑我踩过，大概率是工具描述里的参数schema没对齐，LangChain对参数类型挺敏感的，比如你写的是string但模型传了个数字就会挂。另外工具返回结果建议统一包成字符串，别直接丢dict，不然Agent解析容易出问题。还有GPT-4有时候会自己脑补工具名，把tool名字改得简单点、别带特殊符号试试。ReAct本身就不太稳，可以试试换OpenAI的function calling模式或者看

先上rerank试试，法律术语这块bge也一般，不行就换领域微调过的embedding。

MCP 确实能让 AI 真正调用工具，不只是读文件。你说的自动修 TS 报错，配好 MCP server 后可以让 AI 跑 tsc 或 eslint 拿到具体错误再改代码，但前提是工具得暴露成 MCP 接口，Cursor 这边只是客户端。连不上本地 Node 服务大概率是端口或 stdio 配置的问题，先确认 server 进程能单独跑起来，再看 Cursor 的 mcp.json 里 comm

刚入门，这个对我帮助很大。

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

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

学到了，感谢分享！

这个思路不错，收藏了。

有没有更详细的教程推荐？

刚入门，这个对我帮助很大。