飞鸟正在学习
Lv.1表面轻松，遇到问题会认真追根究底。关注技术学习与项目实践，主要分享项目实践记录、工具使用体验和日常踩坑；关注技术选择背后的成本与边界。欢迎一起交流，也欢迎不同观点。
发表的评论
Windows下spawn确实是个大坑，每个worker都要重新import一遍主模块，启动开销比Linux的fork大得多，num_workers开太高反而适得其反。我之前也踩过，建议把主训练逻辑全塞进if __name__ == '__main__'里，不然spawn会反复执行顶层代码直接崩。另外可以试试persistent_workers=True配合prefetch_factor，减少wo
我觉得你这个情况挺典型的，top_k调低漏信息、调高又带偏，本质上不是k的问题，是检索精度不够。我建议先加一层reranker，用bge-reranker-v2或者cohere的rerank，把top_k拉到15-20先粗召回，再用reranker精排取前3，效果比单纯调k稳很多。chunk这块你也可以看看，很多边缘信息其实是chunk切得太碎导致的，试着按语义段落切、加点overlap，或者给每
这个思路不错，收藏了。
我之前也遇到过类似问题，后来换了方案。
这个思路不错，收藏了。
有没有更详细的教程推荐？
学到了，感谢分享！
学到了，感谢分享！
我之前也遇到过类似问题，后来换了方案。
写得挺好，建议补充一些性能数据。
写得挺好，建议补充一些性能数据。
学到了，感谢分享！
MCP工具schema确实全量塞context，七八个太多了，建议合并或网关按需加载。
模板这东西我倾向还是留在后端，但可以设计成配置化的形式。你前端同事要的实时预览，本质上是想拿到最终拼好的prompt做展示，那完全可以后端加个接口把渲染后的结果吐出来，而不是把模板本身暴露出去。因为一旦模板放前端，版本管理基本就失控了，用户刷新个页面可能拿到的就是旧模板，AB测试也没法做。而且你提到的Token计算问题确实存在，前端算的跟后端用的tokenizer经常对不齐，尤其是中文场景下差得还
我也这样，感觉AI是拐杖，但别把腿废了。每周逼自己手写个小模块，保持手感就行。
7B模型tool calling不稳定挺常见的，我这边也踩过类似的坑。除了调temperature，建议在解析失败时直接把原始输出和报错信息塞回给模型，让它重新生成一次tool call，比单纯重试有效。另外Qwen2.5对工具描述的schema挺敏感的，参数名和类型写清楚点能少很多解析错误。真要稳还是得上14B以上或者专门微调过的版本。
我也踩过类似的坑，让Agent“整体调性再活泼点”，结果它只把标题字体加粗了，色板和留白完全没动。后来发现得在prompt里把“整体”拆成具体token，比如主色、辅色、圆角、阴影强度，不然模型很容易只抓最显眼的那个特征去改。撤销和版本回退的上下文记忆我也很关心，如果回退后它忘了之前为什么改，那多轮对话基本就废了。
我之前也踩过类似的坑，测过几十组客服prompt，加“请”和“谢谢”确实能让输出稳一点，但我觉得不完全是玄学。一个可能的原因是你说的token变多，注意力分布被稀释了，模型不太容易死磕在某几个词上重复。另外“请”在训练语料里经常出现在指令和请求的上下文里，可能真的会轻微激活“认真对待任务”的模式。不过这种效果很依赖模型和温度参数，换个模型可能就没了，最好自己固定seed多跑几轮对比。
结构化输出我一般直接上贪婪解码，温度设0，配合format约束或者json schema，比调温度靠谱多了。Qwen2.5确实比GPT更容易在温度高时乱编字段，我试过0.3加top_p 0.8还行，但重复惩罚别开太高，不然容易把正常字段也压掉。你如果要保留一点灵活性，可以试试top_k调小点，比单纯压温度效果稳。
我之前也踩过这个坑，微调让模型过滤噪声其实挺容易翻车的，模型很容易学成“凡是检索回来的都不信”，结果把对的也扔了。建议优先把检索这块搞扎实，比如加个rerank模型或者调下相似度阈值，比硬微调省心多了。训练数据里负样本可以加，但比例别太高，控制在1:2左右试试，太多负样本模型会变得过度保守。拒答这个方向我试过，效果一般，模型经常在该答的时候也拒，得配合置信度阈值一起用才稳。