周末网络笔记

试试把公共变量名写进.gitignore或者用类型注解锁死，再让它每步都print当前变量名，出错能少一半。

我遇到过类似的情况，当时折腾了好久才发现问题根本不在embedding上。你试试看检索前对query做一下改写或者意图识别，比如把“如何配置静态路由”拆成“静态路由配置命令”和“静态路由故障排查”两个子查询，再分别去检索，召回质量会明显不一样。另外chunk_size调来调去其实治标不治本，PDF文档里的表格、代码块和正文混在一起切分的话，语义很容易被切断，我后来是按文档结构来分块的，表格和代码单

16G跑Q4还是太勉强了，代码推理直接上1.5B蒸馏版吧，日常够用还快。

我最近也在折腾这个，深有同感。你提到的“把无用信息揉进去”其实挺常见的，我试过最有效的办法不是改Prompt，而是先把chunk做一层“压缩”——用LLM把检索到的几个chunk各自提取成摘要，再拼起来喂给生成模型，这样噪声会少很多。另外rerank确实值得试，尤其当召回top5但真正有用的就一两个时，用cross-encoder重排一下，效果比单纯靠embedding相似度稳得多。Prompt模

你这情况先按标题结构切块吧，bge对短文本语义敏感，长块反而稀释了重点，重排倒是可以后面再加。

我之前也踩过这个坑，后来发现光靠prompt不够，得从输出结构上卡死它。比如强制它按“决策：xxx｜负责人：xxx｜截止时间：xxx”这种格式输出，比纯文字描述管用得多。 另外你试过让模型先分步思考吗？比如先让它识别“谁说了什么”，再判断“这算不算决策”，比直接一步到位稳定。会议纪要这东西，本质是信息筛选，模型容易把“重要”和“相关”搞混。 我觉得你可以加一个后处理校验，用规则扫一遍输出，把没

动态插入肯定没问题，MCP的prompt模板本质就是个函数，参数里可以塞时间、用户行为这些上下文，客户端调用时传进去就行。至于为啥不直接写死在代码里，我实际用过之后觉得最大的好处是跨客户端复用，比如你同时维护Web端和命令行工具，改一次模板两边生效，不然每次调prompt都得动代码发版。另外MCP还能让非程序员通过配置改提示词，这点比硬编码灵活多了。不过说实话，如果只是单机小项目，确实没必要上MC

八成是stdio握手后没保持事件循环，试试在server里显式加asyncio.run(main())再启动。

本地检索确实没必要硬上MCP，ReAct够用了，MCP更适合多工具动态接入的场景。 工具多了MCP的价值才明显，单一数据源用传统Agent反而更轻量。

loss降到0.7但输出变啰嗦，八成是过拟合了，5000条数据对8B模型来说确实偏少，LoRA微调特别容易记住训练集里的冗余表达。学习率2e-4可以再降一半试试，epoch先砍到1，另外你推理时temperature和top_p是不是没调低？LoRA rank我觉得16够用，效果差别不大反而说明瓶颈不在rank上，先解决数据多样性和训练时长更靠谱。

12G跑SDXL确实紧巴，我4060Ti 16G开fp16加offload也就勉强稳，你试试把batch size锁1，分辨率别超1024，再加个--medvram参数，能缓解不少。另外别指望TensorRT了，3060支持不全还折腾，真想微调用LoRA吧，全量微调这卡真扛不住。 同款3060路过，你试试把diffusers降到0.24版本，新版显存优化反而有bug。我日常用ComfyUI跑SD

我之前也踩过类似的坑，后来发现system prompt在微调里其实挺看数据分布的。如果你每条都塞同样的话，模型容易把它当成“噪音”，反而削弱了它对真实指令的注意力，尤其7B这种小模型更敏感。建议试试把system prompt只放在部分样本里，或者干脆去掉，靠few-shot示例去引导格式，效果可能更稳。另外你检查下训练时loss有没有收敛到合理区间，有时候格式乱不一定是prompt的锅，可能是

说实话我刚开始也有这个疑问，后来想通了点：MCP这层更像是个“协议适配器”，不是给你本地调用的，而是让不同前端（比如Claude网页版、桌面端）都能统一访问你的知识库，省得每个前端都写一套对接逻辑。 你直接嵌SDK当然能跑通，但那就把业务逻辑和MCP绑死了，换个模型或者换个客户端又得重写。至于性能，本地调肯定更快，但MCP主要解决的是“异构系统怎么聊起来”的问题，不是性能瓶颈。 另外你说的“让

单卡80G跑7B其实ZeRO-2完全够，ZeRO-3的offload反而会引入大量CPU-GPU同步开销，第一步就爆可能是你忘了设zero_force_ds_cpu_optimizer或者把stage3_gather_16bit_weights_on_model_save开成了true。试试关掉offload直接用ZeRO-2，batch size开到4，应该能跑起来，我上周刚这么finetune

少堆砌指令，把检索到的上下文放前面，明确说“只根据这段内容回答”就够了，复杂模板真不如直接点。

这问题我也踩过坑，后来发现光靠system prompt压是压不住的，GPT-4对检索内容的“信任权重”远高于你的指令。我试过把提示词改成“如果上下文信息不足，必须明确回答不知道”，但效果还是不稳定，它会把检索片段里的模糊表述当成隐含线索去补全。后来我换了个思路，在检索层下功夫，比如把片段按相关度阈值过滤，低于某个分数的直接不送进模型，或者把多个片段做交叉验证，只保留互相印证的句子，这样模型能发挥

500条自标注客服数据，Loss降了但输出崩，大概率是数据问题而不是方法问题。客服对话本身有很多隐式意图和上下文依赖，标注不一致很容易让模型学到错误映射，你可以先抽10条让两个人分别标，看看一致性有多高。 另外MCP微调确实不建议全参数跑，冻结底层特征提取层只训顶层任务头会稳很多，你试试看。500条不是绝对不行，但对对话生成这种开放任务确实偏少，可以先用基座模型做数据增强，或者用更小的LoRA

多次迭代很正常，把“遍历所有sheet”这种高频需求直接写进自己的模板里，比每次重写提示词省事多了。

说实话你这情况我太熟了，之前搞RAG的时候也卡在同样这坑里。72B慢不光是大模型本身的问题，LangGraph里每个节点来回传上下文，再加上工具调用的多轮校验，延迟直接叠buff。我后来试了个取巧的办法，用72B做全局规划，但只让它输出精简的JSON步骤清单，然后拿7B去执行每一步，这样延迟能砍掉一大半。不过关键点是7B那个执行模型得针对你的工具集做点few-shot微调，不然它确实容易在参数格式

F.interpolate这个坑我太熟了，当时转完onnx也是警告一堆，后来直接在导出前把resize操作改成固定尺寸的nn.Upsample，或者干脆在trt里用resize层单独实现，虽然麻烦点但能彻底避开算子不兼容的问题。动态shape的话，如果Jetson上部署场景固定，建议直接设成固定尺寸，能省掉很多优化上的麻烦，比如显存分配和kernel选择都会更激进。int8掉5个点确实偏多，校准集