深夜代码笔记

我们直接把Prompt当代码管，每次改动跑固定测试集，崩了的case标红，比记笔记靠谱多了。

试试先做归一化再用余弦距离，ResNet特征直接上L2确实容易翻车。

bge-small确实太小了，换m3提升会很明显，但先别急着上OpenAI，查查chunk切分是不是把离职和入职混一起了。

我也踩过这个坑，最后发现根子还是在节点职责没切干净。检索和总结如果共用同一个全局state，LangGraph按拓扑顺序跑的时候很容易读到脏数据。我后来把总结拆成子图，用Send API按doc粒度分发，每个子图只拿自己那份context，串行错位就没了。全局state适合放轻量路由字段，重数据建议走子图隔离，不然你加再多checkpoint也是打补丁。

我们实测BGE-large-zh在中文FAQ上跟ada差距不大，合规优先的话直接上BGE，再配个GPU推理提速就行。

试试限制单请求max-model-len，长history直接截断，显存能稳不少。

这个问题我也踩过坑，说下我的做法吧。MCP的tool参数确实只支持JSON schema那几种基础类型，string、number、boolean、object这些，没有原生的image类型，所以你想定义一个"图像"类型基本不可能，只能靠约定。我现在是base64塞进string字段，但schema里会加description明确写"base64 encoded PNG, RGB, 224x224

MCP的memory查询默认好像带session过滤，看看metadata里session_id对没对上。

量化后AWQ在小batch下确实可能拖后腿，先试试不量化跑一下对比延迟。

PettingZoo的MAMujoco多进程跑NCCL超时，八成是环境reset和step的随机性没对齐，每个rank采到的数据分布不一样，梯度同步时通信量暴涨。我之前也踩过，把env的seed固定住、每个进程单独设不同种子但保证episode长度一致，超时就少多了。内存溢出大概率是replay buffer在多进程里没做分片，每个rank都存了全量数据，改成各存各的再all-gather试试。

我本地跑32B也遇到过类似情况，感觉不完全是量化锅，更像是注意力在长上下文里被稀释了。我的做法是拆成“接口摘要+目标文件”两段喂，跨文件只给函数签名和docstring，别塞完整实现。另外可以试试把关键变量名和已有工具函数列个短清单放在prompt最前面，能明显减少重复造轮子。

我踩过一模一样的坑，后来发现八成是切块把语义切碎了。512加50重叠看着合理，但文档结构不一样效果差很多，先按标题段落切、再控制长度，比盲目上reranker管用。重排序只能在你召回的前N里有正确答案时才救得回来，召回本身漏了它也没辙。建议拿一批badcase手动看看chunk里到底装了什么，问题经常一眼就露出来了。混合检索可以加，但优先级排在切块之后。

几十万条这个量级pgvector真没必要换，我生产环境快两百万条了HNSW配得好响应也就几十毫秒。你真正要担心的是并发和写入性能，但业务库本来就在PG里，少一套组件省太多事了。IVFFlat得先聚类而且数据涨了要重建，建议直接无脑HNSW，参数调好就行。真到千万级再考虑拆独立向量库也不迟，别被那些卖服务的文章带节奏。

太真实了，AI写代码像橡皮筋，松紧全靠prompt拿捏，调参比写码还费神。 prompt调到头秃，还不如自己敲两行实在，AI只能当个高级补全工具用。

这现象我太熟了，之前用Qwen做类似实验也栽过跟头。其实问题很可能出在训练数据的构造方式上，几百条样本里如果简单任务占多数，模型就会把“输出格式”当成最高优先级的模式去学，而复杂任务里的推理链条反而被当成了噪声。LoRA微调本质是在压缩任务空间，一旦你的工具调用数据里没有刻意平衡多步推理的样本，模型自然就学会了“偷懒”——直接套用最常见的工具组合，而不是真的去理解用户意图。 另外我猜你微调时

大概率是某些算子在ONNX转换时被融合或近似了，试试把opset降到13以下，再关掉onnxruntime的graph optimization。 我之前遇到过类似情况，最后发现是导出时把upsample的mode设成nearest了，检查下你的插值参数。

24G跑7B全精度本来就不是拿来直接干推理的，你加载模型的时候transformers默认会按fp16把权重全塞进显存，再加上KV cache和中间激活值，3090确实会爆。我猜你之前是不是没设`torch_dtype=torch.float16`，只是默认fp32加载？那显存占用直接翻倍，不OOM才怪。 b nb的4bit慢我觉得挺正常的，它那个量化是在CPU上做反量化，每层都要来回搬运数据，

我之前也踩过类似的坑，YOLOv5转ONNX后置信度掉一截，八成不是量化的问题，你amp都关了基本能排除。Focus和SiLU被拆成小算子挺正常的，ONNX导出时官方就喜欢这么干，关键是拆分后数值精度会不会有损失，尤其是SiLU，有些老版本opset对它的近似计算会引入误差。建议你先把opset设到12以上，最好用13或17，然后导出时把dynamic_axes配好，特别是batch和长宽维度，不

这问题太真实了，开源小模型对格式的敏感度确实比闭源API夸张，本质上是指令跟随和模板泛化能力弱。我自己试下来，最管用的招是把约束条件直接写进代码注释里，比如“# 先检测每列缺失率，高于30%才填充”，比在prompt里绕来绕去稳得多。另外把示例顺序固定成“坏例子+好例子”的对比格式，模型跑偏概率能降不少，你可以试试。

几秒延迟大概率不是chunk_size的锅，你这数据量Chroma不至于慢成这样，先查下embedding模型是不是也在CPU上跑了，或者是不是每次查询都重新加载了索引。chunk我建议按章节语义切而不是固定大小，白皮书本身结构清晰，用标题+段落做unit，512和1024对检索质量影响真不大。混合检索值得试，BM25加向量召回再合并，能明显拉高相关片段的比例，rerank用个轻量的cross-e