深夜大模型备忘录

PyTorch这边跨框架复现踩坑太常见了。你可以重点查两个地方：一是损失函数，比如用CrossEntropyLoss时如果输入没做log_softmax，PyTorch的F.nll_loss在某些边界值上会直接爆NaN，TF的categorical_crossentropy默认from_logits=False处理不一样。二是优化器，Adam的eps默认1e-8，TF是1e-7，梯度小的时候PyT

我也拿torch.compile试过Agent里的小模型推理，编译开销确实挺烦的。不过你注意过没有，如果输入长度经常变，它可能会反复触发重编译，反而更慢。我后来把dynamic shape打开才稳一点，但速度提升就没那么明显了。你那边工具选择的输入长度是固定的吗？

我们也在用这俩，确实风格差挺多，后来统一用CLAUDE.md和copilot-instructions.md约束才好转。

试试AWQ量化，比NF4稳不少，4090应该能塞下。

单次Prompt写完整脚本确实难，我一般先让它搭框架再逐段补，最后自己调异常处理。

我一般让它先复述改动计划再动手，确认没跑偏才放行，能少踩很多坑。

7B量化版写代码确实容易断片，试试把max_new_tokens调大点，或者换DeepSeek-Coder，补全稳不少。

说实话我更建议先试MCP那层做重试，微调成本高不说，数据构造也容易翻车，尤其错误信息格式一变模型可能又懵了。而且工具调用本身就很吃格式遵循能力，微调样本稍微带偏一点，可能连正常调用都开始出错。我之前遇到过类似情况，最后是写了个简单的重试逻辑加规则校验，比动模型省心多了。如果你实在想微调，建议至少模拟完整的多轮轨迹，光给错误和修正对儿，模型学不到“何时该停”的边界。

我之前也踩过这个坑，后来发现核心问题往往不是模型不行，而是你的工具描述和prompt里对“什么时候该用哪个工具”写得太模糊了。建议把每个工具的description写得更具体，比如“当需要数学运算时调用”，而不是“计算器”，这样模型误判概率会低很多。中断大概率是输出格式解析失败，可以试试在prompt里强制要求只输出JSON格式，并且用Pydantic解析器来兜底。另外max_iterations

说实话我之前也纠结过这个问题，最后是直接上了BGE-large-zh没换OpenAI。中文场景下，ada-002对中文语义的理解确实不如专门训练的中文模型，尤其是一些领域术语和口语化表达，BGE的向量空间会更贴合。不过你说的召回率没评测，我建议可以拿你们自己的文档抽个几百条做个小测试，用hit rate和MRR看下，比网上任何教程都靠谱。 至于Rerank，确实能兜底，但别指望它完全弥补Embe

这问题太真实了，我上个月刚被折磨完一轮。试下来感觉pdfplumber直接抽表格结构还行，但一遇到跨页或者合并单元格就原形毕露，后来干脆放弃纯文本流，改用OCR管线把整页转成Markdown再喂给模型。表格转文本这块，我踩过最大的坑就是切块——别按固定token切，最好先按行识别，保留表头作为每块的上下文前缀，比如“资产负债表-流动资产-应收账款”，这样embedding检索时语义才不散。另外有个

我都是让它按我写好的接口和数据结构来补，不然版本一混就白搭，还是得自己先定好骨架。

function calling确实是正解，尤其是字段缺失这种问题，靠prompt很难根治，模型本质上还是概率生成，输出长度和格式稍微一飘就容易崩。我之前也踩过这个坑，后来直接改成在prompt里要求“把JSON放在```json代码块里”，再配合正则提取，基本能挡住90%的脏数据。不过最稳的还是直接走API的structured output或者function calling，让模型自己按sc

试试把任务拆成独立小步，每步单独校验输出，比硬控思维链稳多了。

4090跑7B其实挺极限的，你试没试过把max_batch_size调大然后用continuous batching？vLLM确实能省不少显存，关键它把KV cache和激活内存都优化了，你那个4bit慢多半是量化没走对路，试试GPTQ或者AWQ的预量化版本，乱码大概率是校准集没弄好。另外多请求复用同一个模型实例就是vLLM的核心功能，不用自己折腾GPU共享，直接上vLLM把torchserve换

这问题我上周刚踩完坑，MCP那层协议本身只管消息传递，它不关心你payload里是tensor还是别的，所以“Expected tensor, got dict”基本就是你handler里没做反序列化导致的。官方示例确实全是JSON，那是因为他们demo都是文本任务，你这种图像输入得自己在service端把base64字符串先解出来，再走torch的frombuffer之类的转成tensor，没捷

这太正常了，MCP现在就是个协议层，动态更新还得自己搞，别指望生态帮你解决。 监听文件变化触发增量索引呗，或者干脆定个短周期轮询，比手动强点但本质还是半自动。

说实话你这准确率瓶颈不太像数据量的问题，5000条做四分类其实够用了。我怀疑是LoRA只改了attention层的权重，对这种短文本语义抽取任务来说，模型底层特征根本没被充分激活，你可以试试把target_modules全开了，或者直接全量微调几轮对比下。另外合同文本里专业术语和数字占比高，Llama-2的tokenizer对这类内容不一定友好，要不要先做下词表扩充或者用领域预训练模型做底座？我之

说实话6.7B这个量级跟Copilot背后那套大模型比上下文理解本来就是降维打击，别太指望它跨文件推理。我试过把相关代码片段直接粘到prompt里让它续写，比光靠注释强不少，但变量名冲突还是得靠人工改。另外你可以试试把温度调低到0.1，补全会更保守但至少不会乱编变量。

我倾向方案二，先查再塞context，模型调用工具容易把格式搞乱，延迟其实可控。 我们实测过，方案一模型经常误触发检索，反而不如后端直接塞top-k稳定。