边学边做运维学习者

我一般先固定模型和参数，只改prompt做对比，不然真不知道是哪儿起的作用。

这个问题我也踩过，Cursor有时候确实会“自作主张”重命名，尤其是在你让它补全后续代码的时候。我的经验是把变量名放在项目根目录的`.cursorrules`文件里固定下来，或者在对话里用@引用具体的代码块，让它别乱动。另外可以试试写一段带类型注解的示例函数，AI照着改的时候会更收敛一点。

MCP这玩意儿目前真没到能省心的阶段，torch.mcp那个类型报错我也踩过，后来发现是它默认tensor和numpy之间的dtype映射有坑，手动指定float32才勉强跑通。TensorFlow那边配置确实反人类，但好处是序列化格式统一，跨框架传图像不用来回转。真要图省事，不如先用ONNX Runtime当中间层，虽然不算严格意义的MCP，但至少文档全、坑少。你那个多模态项目如果对延迟不敏感，

几十万文档这个量级其实挺尴尬的，Chroma扛不住并发是意料之中的，它本身定位就是轻量级原型工具，你把它放到生产环境确实有点为难它了。Milvus性能没得说，但你说的etcd、Pulsar那一套确实劝退，除非团队里有人愿意专门维护，不然光踩坑就够你喝一壶的。我前段时间也遇到过类似的选择，最后用了Qdrant，部署比Milvus简单太多，单机docker就能跑，性能也够用，几十万向量毫无压力，你可以

我踩过类似的坑，后来发现光调模板不够，得把检索和生成分开看。建议先固定一个模板别动，手动检查那些答崩的case，看是检索压根没召回还是模型没用好。温度我一般调到0.1以下，JSON模式反而会让模型太拘谨，不太适合需要推理的问答。另外可以在prompt里加一句“如果资料里没有就直说不知道”，比单纯强调“严格基于资料”管用。

你提到的LLM自己写代码调用其实挺常见的，但MCP的价值在于把工具调用标准化了，不同模型、不同框架都能用同一套接口去访问，不用每个模型都单独写适配。至于显存和并发，确实是个坑，我们内部的做法是MCP服务器只做路由和权限校验，真正跑推理还是走独立的推理服务，这样MCP那层很轻，不会占显存。跨语言和权限隔离才是它真正有用的地方，比如让Java服务安全地调Python模型，没MCP就得自己搭一套协议。

我一般不让Cursor直接写工具调用那层，先手写一个最小可跑的请求函数跑通，再让它照着这个模式补其他节点，这样它就不会瞎编参数名了。文档全塞进去反而容易乱，不如把关键字段和示例响应单独摘出来放注释里。另外可以试试在prompt里加一句“不确定的字段必须标注TODO”，它就不敢那么自信地硬编了。

先做结构识别再分块确实更靠谱，表格和段落混着切很容易把语义切碎。rerank提升挺明显的，建议加上试试。

7B模型指令遵循本来就偏弱，prompt越长越容易稀释注意力，你可以在关键约束前后重复强调，别指望它一次记住。知识库别整段塞，改成先检索出最相关的两三段，再用固定模板拼进去，中间加一句“仅根据以上内容回答，不知道就说不知道”。温度调到0.1到0.3之间会稳很多，另外加个后处理校验，命中敏感词或参数格式不对就兜底回复。

MCP主要给LLM接工具用的，跟你PyTorch训练基本不搭边，别被带偏了。

我这边也踩过类似的坑，后来发现大概率不是检索的问题，而是模型压根没被“逼”到必须用工具那一步。Claude这类模型本身知识量就大，你问的东西它觉得自己能答，就懒得去调MCP了，尤其你提示词里要是没明确要求它先查再答，它默认走记忆路线很正常。另一个坑是工具返回的内容格式太“干净”了，模型看不出这是权威依据，反而当成普通上下文给忽略了。可以试试在系统提示里硬性规定“任何事实性问题必须调用检索，且回答需

我A100上也踩过这坑，torch.compile对动态shape确实挺敏感的，beam search那种变长序列很容易触发重编译，反而更慢。你可以先试试mark_dynamic或者pad到固定长度看看效果，不过说实话生成式推理这块vLLM的paged attention优势太明显了，torch.compile目前真不太适合硬刚。

我也遇到过，感觉Sonnet就是有种“顺手帮你优化”的冲动，改bug改着改着就开始重构了。后来我在prompt里直接写“只改动与这个bug相关的行，其他代码保持原样，不要重构不要拆组件”，效果好了很多。另外可以试试把要改的代码块单独贴出来，告诉它只在这个范围内修改，别碰上下文。老项目混新写法确实很烦，review的时候一眼就能看出来哪块是AI写的。

我上周也踩了差不多的坑，R1的思考链确实太能写了，4096根本打不住。后来我干脆把AgentExecutor换掉，自己写了个轻量状态机，专门盯`<tool_call>`标签出现的位置，一旦检测到就直接截断思考段，不依赖max_tokens硬切。你也可以试试在prompt里塞个“思考结束请输出<END_THINK>”的哨兵，配合流式回调提前掐掉，比调大预算省事多了。

这个问题挺典型的，多跳推理类的问题单靠向量检索确实容易拼不齐。你可以先加个重排序模型试试，比如bge-reranker，把top_k提到10再用rerank压到3-4条，通常比直接调top_k干净不少。另外切分上可以试试按语义或者按条款切，别死磕固定字数，政策类文档按章节切效果会好很多。实在不行就在prompt里明确要求逐条列出每个片段涉及的约束再综合，逼着模型别跳步。

BN在batch小的时候确实容易炸，我之前也是第3个epoch开始NaN，换成GroupNorm就好了。

别让仨Agent共用一个State，各写各的再合并试试。

测试集风格差这么多，召回率不跌才怪，先换成真实用户query再调模型吧。

我一般按语义段落切，chunk size真没固定值，得看文档结构，硬切肯定丢上下文。

你这个情况我前阵子也踩过，base64那串东西一旦进了上下文，模型很难不被带跑。我的做法是别让图片以原始字符串形式进模板，工具返回里把图片单独放一个content block，type标明image，让协议层去处理，文本部分只保留JSON。模板里就不要再写{{tool_result}}这种大杂烩占位符了，拆成{{text_result}}和图片引用分开。另外MCP本身支持多模态content数组，