深度学习应用札记

说实话我试下来感觉这俩还是有用的，torch.compile主要优化的是计算图和算子融合，但dropout和bn的推理行为它不会替你改，no_grad更多是省显存和加速，该加还是得加。你显存变高可能不是心理作用，有时候编译模式会保留一些中间buffer，跟梯度计算关系不大。边缘case倒不至于出bug，但如果你模型里有自定义的forward逻辑依赖training标志位，那漏掉eval确实可能踩坑

bge维度高确实拖速度，几千条文档试下m3e-small，轻量且中文长句不输text2vec。

K值真没有固定答案，我刚调完一个项目，切分粒度影响特别大。你这512的chunk其实偏大了，试试切成256甚至128，K值就能跟着降下来，相关性会准很多。另外bge-large的得分普遍偏高，建议你按相似度阈值过滤而不是死磕Top-K，比如0.45以下的直接扔掉，效果比单纯调K稳。可以先用10做粗调，看badcase是漏信息还是杂音多，再往5或20微调，别指望一步到位。

说实话你这数据量纠结Milvus属实有点多余了，几万条记录Chroma本地SQLite存储绰绰有余，我跑过十万条也就百毫秒级查询，体感上根本察觉不到瓶颈。Milvus那套Docker Compose起来光配置就够喝一壶，而且单机模式下性能优势压根体现不出来，除非你打算以后真上生产级并发，否则纯给自己找事。MCP这边我实际测下来Chroma的Python SDK跟FastMCP的tool调用更顺手，

小模型真没必要折腾compile，你这收益正常，动态shape目前就是硬伤，直接eager吧。

双卡4090跑70B还是别死磕量化了，试试看8bit下只加载推理层，速度能救回来不少。

few-shot必须安排上，给个满注释的完整函数当模板比说一百句都管用。另外把“每行”改成“包括import和def在内的每一行”试试。

这问题我太有同感了，之前用LangChain搭客服bot的时候也被这个绕圈子折磨得够呛。后来我发现核心不在于塞更多上下文，而是得主动给Agent设定“止损机制”——比如在工具调用里加一个明确的max_retries参数，同时在Prompt里写死“如果连续两次搜索无果，必须停止并直接告诉用户没找到”。另外你提到换话题后它还在纠结旧问题，这大概率是memory里存的对话历史太“杂乱”了，可以试试只保留

我也有过这经历，prompt写太细反而把模型思路框死了，现在基本就留个核心约束，其他全删了。

之前做检测模型转换也踩过这个坑，置信度掉一截大概率不是量化问题，毕竟你都没开动态量化。建议先单独把focus层和slice的输入输出拉出来对一下，onnxruntime里用onnxruntime.transformers.optimizer或者直接比较中间tensor的余弦相似度，能快速定位是哪一步开始分叉的。另外试试opset 11，有些老算子映射在12上反而会有精度损失，我这边换成11后差异就