野生运维人手记

TensorFlow和PyTorch在数值稳定性上确实有些差异，比如PyTorch的log和除法在接近0时更容易出问题。你可以试试在loss里加个eps，或者检查一下有没有哪层输出直接进了log或除法。我之前也遇到过类似的，最后发现是某个softmax后的值太小导致log炸了。建议逐层打印一下中间输出的范围，定位到具体位置就好办了。

MCP的context window和训练的sequence length根本不是一回事，前者是推理时工具调用链的token预算，后者是喂给模型的样本长度，别混着算。工具调用的返回结果确实会占上下文，但跟显存OOM关系不大，爆显存基本是batch size乘上seq len再乘模型参数量那套老账。建议先把max_tokens调小、gradient checkpointing打开，再考虑用QLoRA

我这边生产就挂了三个：文件、数据库、监控，GitHub和Slack都拆到独立workflow里按需拉起。工具一多模型确实容易犯迷糊，尤其写操作重叠的时候，光靠prompt压不住。我们的做法是在MCP server层做命名前缀加权限白名单，再配合任务路由动态加载，别指望模型自己选对。这块确实没啥标准答案，还在踩坑。

这个其实不全是prompt的问题，Claude在agent模式下确实会“脑补”一些它觉得你将来可能用到的类型注解。我自己也遇到过，后来在项目根目录放了个pyproject.toml加ruff配置，每次生成完顺手跑一下ruff check --fix，那些没用的import自己就没了。另外可以在.cursorrules里加一句“不要引入未使用的类型提示”，比在对话里反复说管用。FastAPI项目尤其

你暴力检索能到85%说明embedding本身没问题，差距基本出在索引近似搜索上。先确认下你建索引和查询时向量有没有归一化——Milvus的IP和COSINE在归一化后等价，但没归一化直接用IP就完全不是一回事了。另外nprobe别只调一个值，从16试到128看看召回曲线拐点在哪，50万数据其实用不着IVF，HNSW的M和efConstruction没调好的话反而更差。rerank可以加，但那是把

我一般把回传校验拆成独立子图，主图只留关键节点，状态清爽很多。

我用Qwen2.5-7B做代码补全时也折腾过这俩参数，后来发现temperature降到0.2以下确实容易变傻，注释全给省了。现在基本固定temperature 0.7、top_p 0.9不动，主要精力放在few-shot示例和输出格式约束上。开源模型对Prompt里的结构比GPT敏感得多，你把要求拆成带序号的步骤，再给一两个输入输出样例，跑偏概率会小很多。另外可以试试在system里明确写“保留

3060 12G跑7B Q4确实到顶了，上下文一长就开始漂很正常，KV cache吃显存太狠。我建议先把7B流程跑通别急着换卡，Agent的瓶颈经常不在模型大小，而在工具调用格式和检索质量上。embedding和LLM分开部署会好不少，embedding丢CPU或者另一张小卡都行，能省出几个G给上下文。14B量化在12G上基本别想舒服，等50系落地再一步到位更划算。

几十万这个量级pgvector完全够用，别被那些推文带焦虑了。真正开始难受大概要到几百万往上，而且瓶颈往往在内存和索引参数调优，不一定是pgvector本身不行。我这边三百万条用HNSW索引，召回和延迟都还能接受，就是建索引比较吃资源。专用库的优势更多在高并发和分布式扩展，单机场景不一定值得折腾。GPU也不是必须的，Milvus和Qdrant纯CPU跑也很常见，别被忽悠了。

多轮对话OOM大概率不是模型本身的问题，而是vLLM的KV cache没配好。你把gpu-memory-utilization调低一点，比如0.85，再限制下max-model-len，别让它默认吃满。工具调用那套prompt确实会拉长上下文，尤其LangChain的Agent会反复塞历史，缓存一涨就爆。建议先上AWQ或者GPTQ量化版试试，7B跑Agent逻辑其实够用，关键是显存留够余量。

AI写的代码我也经常看不懂，但我会逼自己review一遍再让它解释，不然真成代驾了。

top_k这东西真没有万能公式，我自己踩过的坑是固定值基本都会翻车。两万条数据不算大，但文本长度不一时，chunk策略其实比top_k更影响召回质量，如果chunk切得碎，top_k=3可能连一个完整语义单元都凑不齐。我现在更倾向先召回一个稍大的候选集，比如top_k=20，然后用相似度分数做动态截断，比如只保留分数在最高分85%以上的，或者分数下降出现明显断崖就停。另外可以加个rerank模型，

Cursor的Composer处理多文件任务确实容易飘，我一般只用它写单文件的小函数，跨文件依赖多了它就开始瞎编函数名。你遇到的多文件PDF处理，不如先让它把每个模块的接口和输入输出用注释列清楚，再一个个文件生成，比一次性扔个大需求稳很多。另外装个pylint或者ruff在编辑器里，它写完立刻报错，你就能看到哪里不对，比靠肉眼查缩进快多了。

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

一万条数据可能不够，法律领域术语多，建议先检查数据里有没有重复或格式混乱的，LoRA秩也可以调大点试试。

state schema用TypedDict的话得注意每个节点返回的是增量还是全量，LangGraph默认会merge，但如果字段没在schema里声明就直接丢了。我之前也踩过这坑，排查半天发现是分析节点return的key名字跟schema对不上。对话历史建议别全塞state，超过十几轮token直接爆炸，用checkpointer配合外部存储按thread_id取更稳。

检索准不代表生成就稳，你这情况八成是卡在“上下文里塞了太多似是而非的东西”。top-5里只要有一两个片段跟问题沾边但不完全对，模型就容易把几篇内容缝在一起编。建议先加个rerank压一压，再把chunk按语义边界切，别硬凑512。排查的话可以固定同一批query，分别看检索命中、rerank后排序、生成引用来源这三步，基本能定位是哪层出的问题。

我之前也踩过类似的坑，最后发现是MCP的同步调用把GIL占住了，每10步一次看着不多，但回调里如果有json解析或者网络IO，正好卡在DataLoader取下一个batch的时机上，step时间就炸了。你可以试试把MCP的通信层扔到独立线程或者干脆用进程池，别让它跟训练主循环共享同一个event loop。另外确认下是不是日志级别开太高了，debug模式下每次请求都刷盘也挺要命的。

你这个困惑挺真实的，我一开始也这么想过。但后来发现区别在于调用时机——塞system prompt是你预先猜哪些文档有用，封装成MCP是让模型自己决定什么时候查、查什么、查几次。多跳问题里这个差别很明显，模型可以先查A再根据结果决定要不要查B。不过如果你的场景就是单轮简单问答，那确实包装成MCP收益不大。

我之前也踩过这个坑，纯靠向量相似度确实容易捞出一堆语义相近但时间对不上的东西。建议在metadata里把时间戳和来源类型都带上，检索时先按时间窗口过滤再算相似度，能让“上个月”这种限定词真正生效。另外embedding模型对代码片段和自然语言混在一起确实容易糊，可以考虑分库存，对话和笔记别塞同一个collection。Milvus和pgvector在过滤这块都比Chroma顺手，但换库之前先把元数