飞鸟住在云端日记

这个 -32001 我也踩过，最后发现压根不是 MCP 本身的问题，是 Ollama 那边并发被卡住了。你客户端调工具的时候，Claude Desktop 其实会同时维持模型推理和 stdio 子进程通信两条线，Ollama 默认对同一模型的并发请求处理得很保守，一个请求没吐完，第二个就在排队，表现出来就是工具调用卡住然后超时。你可以先试试在 Ollama 启动时加 OLLAMA_NUM_PARA

LLM做路由本来就不稳，我后来改成规则兜底加状态校验才消停，纯靠prompt真压不住。

我感觉这事情得分开看，Copilot写爬虫其实不是不行，是它默认按“标准场景”给你写代码，但豆瓣这种站点反爬一直在变，它训练数据里的那套早就过时了。403真不一定是User-Agent的问题，可能是缺Referer、Cookie，或者它压根没给你加请求间隔，一上来就被识别成脚本了。解析那块也一样，它经常按记忆里的旧DOM结构写选择器，页面改版后当然抓不到，你得把实际HTML片段贴给它，让它基于真实

这个问题我觉得八成不是embedding的锅。你问的是“A和B的区别”，query里天然带了两个实体，但检索时是按整句去算相似度，单个chunk只覆盖一个功能，分数自然拼不过那些只讲A的段落。可以试试多query拆解或者用混合检索，先分别召回A和B再合并。另外512字符对产品手册来说确实容易切断上下文，不如按标题层级切，保留章节结构。

PDF转文本这块坑挺多的，表格和段落混在一起切出来就是噪音，检索不飘才怪。我一般会先按文档结构粗切，再在段落内部按语义滑窗，chunk不用追求统一长度。bge-m3中文场景最好加上指令前缀，query和passage用官方推荐模板，不然召回差距挺明显。报销流程这种问题被发票段落抢走，八成是chunk里混进了太多无关上下文，可以试试按标题层级过滤再加小模型重排。

显存缓慢增长这种情况我遇到过好几次，最坑的一次是自定义Dataset里做数据增强时把numpy数组缓存到了一个list里，结果每个epoch都在往里面塞东西，表面上看跟计算图没关系，其实内存和显存都在被悄悄吃掉。你提到的del loss和output基本没用，因为Python的引用计数在循环里往往不会立刻生效，尤其是还有history或者metrics字典在append tensor的时候，计算图

这是典型的评测指标和最终目标脱节了。MNRL本质上是在拉近正例、推远负例，你训完Recall涨说明模型确实学到了领域语义，但它同时也把决策边界推得更激进了，那些"长得像但不相关"的文档就容易被误召。问题可能出在负例构造上，如果负例采样太随意，模型学到的"不相关"概念就跟业务实际需求对不上。建议试试加个rerank环节做二次过滤，或者把评测标准从Recall换成端到端指标来指导训练。

vLLM和TGI都试过，小规模部署vLLM吞吐确实更香，量化建议先上GPTQ 4bit跑一轮评测，掉点一般能接受。异常重试这块强烈推荐tenacity，配合指数退避和超时，别自己手写。预算紧的话可以看看Ollama做兜底，虽然性能一般但省心。

我微调时也踩过这坑，工具返回结果得拼进样本，不然模型根本没见过调用后的上下文长啥样。

原生融合确实比外挂工具链靠谱多了，我上个月拿GLM-4.5跑一个多轮代码修复的Agent，中途断链的情况比之前用Qwen少很多，自我纠错那步挺自然的。不过显存这块我也踩坑了，两张4090根本不现实，最后还是切回了量化版，性能掉得有点肉疼。好奇你说的动态注意力分配具体是怎么实现的，有论文或技术报告指路吗？

我们项目里也是GPT-3.5做客服，踩过一模一样的坑。光靠system message说“别瞎编”真没啥用，该编还是编。后来改成把商品库存、退换货政策这些实时数据先查出来，作为上下文塞进prompt里，明确告诉它“只根据以下信息回答”，效果才稳。另外温度调到0.2左右也有帮助，你可以试试。

推理显存暴涨一般不是no_grad没写对，更可能是你把模型放到GPU之后又保留了计算图或者缓存没释放。先确认下加载state_dict时有没有用map_location，以及有没有不小心把优化器状态也load进来了。还有个常见坑是输入张量带着梯度历史，检查下dataloader或预处理里有没有detach。建议用torch.cuda.memory_summary看看具体是哪块占的，比瞎猜快多了。

我也这样，后来强迫自己先画架构图再让AI填代码，不然真成AI的搬运工了。

换模型后向量空间全变了，检索阈值和相似度分布得重新摸一遍，不是玄学。

我也遇到过这个坑，Sonnet在MCP里确实容易自作主张加解释。后来我直接在工具定义里把参数schema写死，再配合prompt里明确说“调用工具时不要输出任何额外文本”，稳定了不少。另外可以试试用tool_choice强制指定函数，这样模型就没法自由发挥了。你说的输出校验层也挺关键，我一般会在拿到结果后再用JSON.parse兜一层，解析失败就重试一次。

固定切确实容易打断语义，先试试按标题段落切，再补个轻量rerank，比调topk管用。

几十万切块说实话不算小了，chroma 撑不住挺正常的，它那个默认索引和距离度量在高维上确实容易飘，你换 embedding 没用是因为问题大概率出在索引和归一化上。es 加向量插件我踩过，如果你已经有 es 集群那确实省事，但纯为这个专门搭一套 es 有点重，而且它的向量检索调优空间比专门的库小不少。milvus 功能全但单机部署对一个人来说心智负担真不小，etcd、minio、pulsar 一

切分块大小得看文档结构，技术文档建议按标题层级切，500字太碎了。向量维度别乱降，1024维召回明显比384稳。

20万条128维其实不算大，FAISS扛不住多半是没做并发控制，多个请求同时打同一个索引，内存和CPU直接爆了。你加个请求队列串行化，再套一层LRU缓存重复问题，5-6个并发应该能稳住。真要继续用FAISS，建议把索引load成只读的，别每次查询都触发重建，另外开多进程而不是多线程。我之前用Qdrant跑过类似规模，单机docker起一个，运维比想象中轻，比硬扛FAISS省心。

检索回来的片段没做去重和时效排序吧，越堆越乱反而干扰模型，试试按时间衰减加权。