阿航Design手记

我之前也踩过类似的坑，vLLM那个首token抖动大概率是调度器在动态batching时把长prompt插到前面了，可以试试限制max_num_batched_tokens或者开chunked prefill。SGLang的OOM基本就是mem_fraction_static给太高了，A100上留10G余量的话建议压到0.82左右，再配合disable_radix_cache看看。另外AWQ 4b

现在这行情确实没啥好纠结的，Agent方向基本被PyTorch垄断了，新框架清一色torch，你硬扛TF只会越来越孤立。互转这块别指望有丝滑方案，ONNX算子不支持是常态，我们组之前也折腾过，最后直接重写模型比转来转去省时间。建议线上服务慢慢往TorchServe或者Triton迁，短期可以TF和PyTorch双轨跑，但新东西一律用PyTorch写。

3060跑ResNet50 bs=32按理说问题不大，但224×224加上数据增强和DataLoader的pin_memory确实容易顶到天花板。先别急着怀疑代码，用torch.cuda.memory_summary看看是模型本身占得多还是数据加载那块爆的。混合精度基本是立竿见影的，能省三成左右显存，梯度累积配合小batch也能凑出大batch的效果，就是训练时间会拉长。另外检查下有没有在训练循环

500条样本确实偏少，风格学习本身就容易过拟合，loss卡在1.8不奇怪。你试的学习率跨度挺大，但batch size 4对7B模型来说梯度噪声不小，可以试试gradient accumulation加到16或32再跑。另外[INST]标记如果基座模型没在预训练阶段见过这种格式，反而会干扰，建议用Qwen2.5官方的chat template对齐一下。数据格式检查下是不是每条都带完整指令和输出，别

这个坑我去年踩过一轮，最后发现单纯靠文本层抽表格基本没救，尤其是那种三线表混着合并单元格的，PyPDF2抽出来就是灾难现场。后来我们试过camelot和pdfplumber做结构化抽取，对规则表格还行，但扫描件或者复杂排版还是得靠OCR兜底。跨页表格确实头疼，我现在的做法是先检测表头重复模式，把跨页的几块拼回一张逻辑表再切chunk，能缓解不少错位问题。其实可以先用unstructured的hi_

先确认下server是不是只绑了127.0.0.1，客户端换localhost试试，我之前就栽在这。

MCP 对 template 确实挺敏感的，之前我也遇到过类似情况，后来发现是对话里的 role 标签和模型预训练时的格式没对齐，改过来之后 loss 才正常往下走。3k 条数据微调其实不算少，关键看质量，如果 eval loss 反弹大概率是过拟合或者数据里有噪声样本。建议先拿一小批数据过拟合试试，能降到很低说明流程没问题，再回头查数据格式。学习率 1e-5 可能偏低了，MCP 这类模型 2e-

合同条款提取这种复杂任务，ShareGPT多轮格式更合适，单轮混训容易让模型分不清对话边界。

我一般会先把CSV的列名和几行样例数据贴进去，再补一句“输出保持原列顺序，去重按A+B组合”。这样AI基本不会瞎猜字段，import也齐了。多步骤任务最好让它先列步骤再写代码，比直接要成品稳很多。

我拿它写pandas脚本也碰到过类似情况，但后来发现多半是自己给的上下文太少了。比如inplace搞反，往往是没告诉它你想保留原df还是返回新对象。网络请求那块我会直接在prompt里明确要求加timeout和retry，不然它默认就写个裸requests。变量名拼错这种我倒觉得v2比之前好很多了，可能是你任务描述里字段名没写清楚。

你这个方向其实不算歪，但确实得看你怎么定位MCP。它本质是给模型提供上下文和工具调用的协议，不是拿来当任务调度系统用的。你那个LoRA训练挂tool调用上，如果客户端是同步等待，大概率会撞超时，因为MCP本身没规定心跳机制，各家客户端实现也不一样，有的可能几十秒就断了。参数大小限制也是同理，协议层没硬性规定，但实际传输受客户端和传输层限制，塞大JSON样本很容易出问题。至于客户端断开后任务还跑不跑

几百万条这个量级，Qdrant单机其实完全扛得住，我去年一个项目400多万条跑生产环境没啥问题，内存给够就行。Milvus确实重，etcd加MinIO那套部署下来运维成本不低，除非你数据量再涨一个数量级或者要分布式。HNSW的M从16起步，efConstruction给到100到200一般够用，主要还得拿自己数据测召回率，别照搬文章里的参数。急着上线的话建议先用Qdrant把链路跑通，后面真扛不住

我用这模型写pandas脚本也遇到过类似的，inplace那点特别容易翻车，明明说了要原地修改它还是给你整个赋值回去。后来我干脆在prompt里明确要求每个函数都加上try-except，并且把inplace=True这种关键参数单独强调一遍，出错率就降下来了。另外网络请求那块建议直接让它用requests加tenacity重试，比它默认写的裸调用靠谱很多。你可以在系统提示里固定一套代码规范，比每

这个问题其实我也踩过不少坑，后来发现光看max_tokens来定chunk size真的不够用。我现在习惯的做法是先按语义段落切，比如技术文档就顺着标题层级和小节走，代码块和表格尽量别拆开，然后如果某段还是太长再按token上限硬切一刀，加个overlap兜底。闲聊类文本我倒觉得可以切小一点，因为本身信息密度低，切大了反而容易把好几个话题混在一起。检索效果评估我一般会自己标一批query和对应的g

我之前也踩过这个坑，感觉问题可能不在chunk粒度，而是整个prompt结构让模型觉得“检索到的就是标准答案”。你只加一句“用自己的话总结”，模型很容易忽略，因为它天然会优先信任context里的原文。试试在system里明确分工，比如“检索内容仅作为参考，如果与问题场景不匹配，请以你自身知识为主进行回答”，同时把用户原始问题放在context之后再强调一遍。另外温度调高其实帮助有限，RAG场景下

loss降到0.3不代表模型学会了你要的东西，很可能它只是学会了数据里的表面模式。你这种“问题描述+代码段”的格式，模型很容易退化成无脑复制括号和缩进，因为它发现光靠这些就能把loss压下去。我之前用LoRA微调小模型做SQL生成也踩过类似的坑，loss低得离谱，结果输出一堆重复的SELECT。建议你先别急着调参，拿几条训练数据直接做推理，看模型能不能复现，如果连训练集都过拟合不出来，那八成是数据

我之前也踩过这个坑，八成不是推理的问题，而是MCP客户端那侧的timeout设太短了，默认可能就几秒，而工具调用链路一长就超了。你先看看MCP配置里有没有request_timeout之类的参数，调大到60秒试试。另外vLLM那边如果是同步阻塞调用，工具函数又串行执行，也容易卡住，建议查下是不是工具调用没走异步。

几十万条数据其实两个都扛得住，不用太纠结扩展性。我去年用Qdrant搭过类似规模的RAG，docker-compose起一个节点几分钟就搞定，LangChain也有现成的vectorstore封装，基本零折腾。Milvus功能确实更全，但etcd、minio那一套组件对新手来说维护成本偏高，除非你确定后面要上亿级别。召回率主要还是看embedding模型和分块策略，数据库本身影响没那么大，真要说省

Chroma本地跑跑还行，扔生产环境多用户并发基本必炸，它本身就不是为这种场景设计的。加锁能顶一阵但吞吐直接跪，不如早点换Milvus或者Qdrant这类正经向量库，读写分离和并发都稳。云服务的话Pinecone省心但贵，延迟看region，预算紧可以先用自建的Milvus试水。

这个问题挺典型的，文档量一上来检索质量断崖式下跌，很多时候不是embedding不行，而是索引里混了太多语义相近但业务上完全不该放一起的内容。你说的合同串项目，我第一反应就是元数据没管住，光靠向量相似度去兜，跨项目的高相似片段太容易被召回。粗分类再分别建索引我觉得是有效的，但别只分一层，最好按业务线加文档类型做两级过滤，检索时先把范围收窄。另外可以试试混合检索，BM25加向量召回再重排，纯向量在专