一只萤火虫会调Bug

这个思路不错，收藏了。

这个思路不错，收藏了。

学到了，感谢分享！

写得挺好，建议补充一些性能数据。

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

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

写得挺好，建议补充一些性能数据。

学到了，感谢分享！

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

学到了，感谢分享！

LangChain的AgentExecutor确实容易丢状态，试试把中间结果显式存进memory再传给下一步。

16G跑7B q4确实够用，想再大点可以试试Qwen1.5-14B的q3，速度能接受，问答补全基本够。

我踩过一模一样的坑，最后发现是chunk切分把关键信息切碎了，512字符对中文来说其实挺短的，答案经常跨在两个chunk的边界上。建议先别急着上rerank，拿几个召回失败的case把原文和命中的chunk都打印出来看看，大概率能定位到切分逻辑的问题。另外embedding对纯中文长文本本身就有点吃亏，可以试试换bge-m3这类中文友好的模型对比下。

同研一，我去年也纠结过这个，后来直接选了PyTorch没回头。组里师兄用啥你就跟着用啥，这个真的省事很多，遇到bug有人问，代码也能互相参考。TF的静态图现在2.x其实已经默认eager了，TFRecord那种东西你当它是个数据格式就行，不用想得太复杂。工业界岗位写TF多，但面试时候更看重你懂不懂模型原理和工程落地，框架只是工具，现学也来得及。部署这块，PyTorch现在有TorchScript和

50万条768维其实不算大，HNSW调M和efConstruction收益本来就有限，你涨2个点已经算正常了。recall@10只有70%我更怀疑是embedding的问题，中文长文档切片重叠多，同一个模型编码后语义本来就容易糊在一起，先拿几百条query算算向量间的区分度看看。efSearch你试过拉高吗？这个对召回影响比建索引参数直接多了，先拉到256甚至512看看天花板在哪。IVF_PQ别急

“入职两年能休几天”这种问法翻车，大概率是检索没把年假计算规则那块召回来，top5里可能全是政策概述。建议先把检索命中率测一下，拿几个bad case看看context里到底有没有答案，没有的话调prompt也白搭。prompt这边可以试试让模型先复述资料再回答，能压一压它自己发挥的冲动。few-shot确实不适合这种场景，问题太散，不如在system里把“资料没有就说不知道”卡死。

50万这个量级确实开始踩坑了，ResNet50的特征本身维度就高，直接上IVF_FLAT或者HNSW再调参，边际收益很有限。我建议先确认一下是不是量化方式的问题，比如用了SQ8或者PQ压缩太狠，相似图之间的细微差异直接被压没了，换成IVF_SQ8或者干脆不压缩试试。另外可以加一层粗排再精排的思路，先用向量库召回Top-100，再用原始特征做余弦重排，召回率一般能拉回来不少。还有别忘了检查图片预处理

这个问题其实挺关键的，我刚开始做RAG的时候也踩过同样的坑。向量数据库里存的本质就是embedding向量加一些元数据，但关键在于你往embedding模型里喂的是什么——喂文本就对应文本语义，喂图片就对应视觉特征，它本身不区分模态，只看你用什么编码器。你现在的做法就是典型的单模态RAG，图片等于被丢掉了，用户问图表趋势答不上来太正常了。想解决的话有两条路，一种是用多模态embedding模型比如

我上个月刚踩过一模一样的坑，Qwen2.5-7B做合同字段抽取，prompt换个说法结果就变，后来发现是sglang那边默认的采样温度没调，冷启动时特别明显，设成0之后稳定性好了不少。但json约束还是会偶发抽风，尤其是字段名映射，模型会自己发明一些看起来很合理但原文没有的key，后来我在system里加了一句“字段名必须从以下列表中选，不允许新增”，效果比单纯写json schema好。few-

我上周也这样，把MCP SDK降到1.0.0就通了，版本兼容确实有坑。