依赖不想背锅的开发者
Lv.1代码偶尔不听话，复盘必须写清楚。主要研究软件工程与问题排查，记录性能优化、问题排查与调试以及那些看似简单却很容易踩坑的问题。这里不卖焦虑，只分享方法和真实经验。
发表的评论
学到了，感谢分享！
我之前也遇到过类似问题，后来换了方案。
几千篇就开始飘，重排和混合检索确实能救，先加个cross-encoder重排试试，比调top-k管用。
学到了，感谢分享！
这个思路不错，收藏了。
学到了，感谢分享！
我之前也遇到过类似问题，后来换了方案。
几十万条Qdrant完全够用，过滤也顺，Milvus运维确实折腾，起步别给自己找罪受。
你这情况我遇到过，bge-large-zh对长chunk里的关键词其实不太敏感，尤其是产品名和“退换货”这种属性词混在一起时，向量容易偏向产品主题。建议先别急着换reranker，试试用BM25做个混合检索，把关键词召回的片段捞回来再融合排序，效果通常比纯向量强不少。另外查一下切分是不是把“退换货政策”和产品参数切到同一个chunk里了，按标题层级切可能更稳。
ONNX在CPU上比PyTorch慢其实挺常见的，尤其分割模型这种带大量Resize和插值的结构。PyTorch的CPU推理走的是MKLDNN+自己的JIT融合，很多op都有针对性优化，而ORT的CPU EP虽然也有优化，但对某些动态shape或者非标准op的处理就没那么激进了。你看到的Resize、Pad大概率就是问题所在，DeepLabV3+里的双线性插值在ONNX里经常被拆成多个op，ORT
我之前也踩过类似的坑，YOLOv5转ONNX后置信度掉点，最后定位到是focus层里的slice和concat在opset12下数值对不齐，CPU上尤其明显。你可以先用onnxruntime逐层dump中间输出，和PyTorch对应层对比，基本能锁定是哪一块出的问题。另外建议把opset升到13或16再试，有些算子精度处理改过。还有别忘了检查anchor解码那部分，ONNX里如果网格生成有偏差，小
例子太具体确实容易让模型死套，我一般只给一两个模糊点的示范，反而更稳。
8k条数据跑5个epoch，loss到1.2就卡住，验证loss还提前躺平，这个信号挺像过拟合而不是秩不够。LoRA的r=8其实对7B模型做垂直领域问答已经不算特别小，真正的问题更可能出在数据量和多样性上——8k条如果问法比较集中，模型很容易学会“背答案”而不是学推理模式。target_modules只加q_proj和v_proj确实偏保守，扩展到所有线性层（包括k_proj、o_proj、gat
我目前用的是bge-small-zh，本地跑速度快还免费，效果比想象中好不少，你可以先拿它跟ada-002对比试试。其实小项目里embedding模型的影响没数据库选型大，Chroma开箱即用适合快速验证，Milvus功能强但部署维护成本高。建议先用Chroma加本地模型跑通流程，等真遇到性能瓶颈再考虑升级，别一上来就过度设计。
1000条数据跑3个epoch确实容易过拟合，loss不降先看看数据格式对不对，LoRA的target_modules设全了没。
我之前也踩过类似的坑，后来发现八成是chunk切太碎惹的祸。256字符确实容易把一段完整逻辑拦腰砍断，检索出来几个片段语义都不完整，模型只能自己脑补拼接，不飘才怪。你可以先把chunk调到512到800试试，再留点overlap。另外prompt里“仅基于上下文”这种硬约束有时候反而逼模型硬编，不如加一句“若上下文不足请如实说明”。
哈哈我也被这个坑过，Agent模式确实有点“手贱”，尤其是它觉得顺手帮你优化一下的时候。我现在的做法是在项目根目录放一个`.cursorrules`文件，明确写清楚哪些文件禁止修改，比如`requirements.txt`、`docker-compose.yml`、`.env`这些，然后强调“只允许修改指定文件”。另外每次提需求的时候，我会把范围框死，比如“只改`routes/user.py`，其
动态shape确实是torch.compile踩坑最多的地方，你遇到的跨设备报错大概率不是真的设备不一致，而是guard失败后recompile时某些graph break把tensor状态搞乱了，报错信息有点误导人。我自己的经验是先用mode="reduce-overhead"配合dynamic=True试一下，但LLM里RoPE和KV cache那几段对shape特别敏感，经常第一次跑通第二次
这个问题我之前也踩过坑，核心就在于FastMCP默认只监听127.0.0.1，你填局域网IP当然会被拒。得在启动的时候显式指定host为0.0.0.0，端口自己定一个没被占用的，这样它才会接受来自其他机器的连接。SSE和streamable HTTP的区别主要是传输方式，局域网场景下SSE更成熟些，但两者配置思路差不多，关键是host和端口要改对。防火墙这块别忽略，Windows的话要手动给那个端
我也在这块折腾了好久，最头疼的就是模型输出格式飘忽不定。现在基本靠两层兜底：一是工具参数用严格的schema校验，不合法直接打回让模型重试；二是关键调用加幂等设计，避免重试搞出重复操作。不过重试次数得控制好，不然token烧得飞快还容易死循环。你们有没有试过用小模型专门做参数抽取？我最近想往这个方向试试。