兔子收集工具日记

fp16掉点先别急着怀疑转换链路，UNet++里的SE注意力在fp16下很容易数值不稳，尤其遥感图动态范围大。你可以试试polygraphy对比逐层输出，定位是哪一层开始偏的，大概率在注意力模块或者上采样那块。另外opset 12报nbDims那个错，八成是某个reshape或squeeze在TRT里维度推导没对上，跟精度问题是两码事。小目标断裂更像是fp16精度不够导致低响应被截断，先跑个fp3

入门我觉得是能稳定复现想要的效果，进阶就得啃论文和多模型实战了。

试试vLLM开FP8加PagedAttention，KV Cache能省不少，7B在4090上跑长上下文稳很多。

量化版本身就有随机性，试试固定seed加贪心解码，比调temperature管用多了。

7B模型做结构化输出确实容易飘，我一般会把temperature压到0.1以下，再配合vLLM的guided decoding或者outlines这类工具直接约束生成，比纯靠prompt稳多了。自检逻辑可以加，但别让它自己改，而是跑完用json.loads校验，失败了就带错误信息重试一次，成功率能提不少。Qwen2.5其实算听话的，真要换可以试试DeepSeek，指令跟随确实更紧一些，不过7B这个

你暴力检索能到85%说明embedding本身没问题，差距应该出在索引近似搜索的精度损失上。归一化确实关键，Milvus里如果用IP度量必须先把向量L2归一化，不然内积和余弦就不是一回事了，nprobe调大召回会涨但延迟也上去了，可以试试nprobe设到nlist的10%看看天花板在哪。另外你top-10的62%是拿什么当ground truth的，如果是用暴力结果对拍那62%就是索引召回率，这个

我之前也踩过类似的坑，后来发现是chunk切太碎导致模型拿到一堆半截话，反而更容易自己脑补。你可以把chunk调大点或者加个overlap试试，256确实有点小。另外prompt里“仅基于上下文”写太硬有时候会让模型过度保守，不如改成“优先参考上下文，不足时可说明”这种。定位的话我一般先固定检索结果手动喂给模型看它答得怎么样，如果还是乱就说明是生成端或prompt的问题。

先试试加个rerank吧，同篇多片段的问题会缓解不少，父子chunk也值得搞。

PDF技术手册建议按标题层级切，固定size容易把表格和代码块切碎，这块影响比换模型大。

刚入门，这个对我帮助很大。

有没有更详细的教程推荐？

我之前也遇到过类似问题，后来换了方案。

学到了，感谢分享！

50万条768维不算大，HNSW调到64还提不上去，感觉问题可能不在索引参数上。你切的片段有重叠，如果切片粒度太碎或者语义不完整，embedding本身区分度就差，调啥索引都白搭。建议先抽一批bad case看看是不是召回的邻居本身就不相关，如果是那就得回头搞切片和embedding了。efSearch可以往上拉到128或256试试，但收益一般有限，别抱太大希望。IVF_PQ对高维中文语义场景不一

拆成多步喂确实稳很多，先让它列边界情况再写代码，比一股脑塞要求管用。

几十万条这个量级其实不算大，pgvector慢大概率是索引没调好或者没建HNSW，换库之前可以先看看执行计划。不过既然决定换，我两个都用过，说点实际的。Milvus功能确实全，但那个部署架构真的是劝退，etcd、minio、pulsar一堆组件，单机版勉强能跑，一旦上集群运维成本直接翻倍，小团队没人专职搞这个会很难受。Qdrant就舒服多了，一个二进制文件或者docker起一个容器就完事，Rust

这个问题我踩过类似的坑，感觉大概率不是embedding模型本身的问题，而是检索粒度和查询意图没对齐。你问“怎么配置显卡驱动”，这其实是个操作指导类的短查询，但512的chunk里很可能混了一大段显卡型号对比的内容，embedding把整段压成一个向量，主题词“显卡”权重太高，就把那些对比文章拉上来了。我自己试过把chunk降到128到200左右，再配合按标题或小段落切，召回的相关性明显好一些，尤

这个问题我踩过，大概率不是Claude那边只读，而是你用的filesystem服务器启动参数里没放开写路径。官方那个server通常要显式传允许读写的目录，只传了读的目录就会这样。你可以先看下启动命令和capabilities里tools有没有暴露write_file这类工具，没有的话Claude自然调不了。另外也确认下目录权限和沙盒配置，别是系统层给拦了。

提取任务确实容易踩这种坑，我之前也折腾过类似的东西。后来发现关键不是堆例子，而是把任务拆细，先让模型判断情绪，再单独抽产品名，一次只干一件事，稳定性能好不少。温度直接调到0，别让它自由发挥。如果量级够大，微调小模型确实更稳，但标注数据得攒够，不然还不如先用规则兜底。

多轮对话里人设漂移确实挺常见，我自己也踩过这个坑。你每轮重新塞system其实方向没错，但GPT-4o对system的注意力会随着对话变长而衰减，尤其历史里那些“天气八卦”的内容会形成很强的上下文惯性。我后来用了个土办法，把system指令压缩成三五条硬规则，再用一个独立的轻量模型或者正则先判断用户意图，无关的直接走兜底话术，根本不进主对话历史。另外历史对话别全留着，超过三四轮就做摘要，把和产品无