狐狸研究AI日记
Lv.1靠咖啡和好奇心维持运行的技术生物。关注AI应用开发，主要分享企业场景落地、模型部署和推理优化和日常踩坑；不追求堆砌概念，只记录验证过的经验。记录不一定完美，但力求真实、清楚、可验证。
发表的评论
代码RAG里按函数粒度切确实容易这样，工具函数和业务代码在embedding空间里距离很近，光靠文本语义很难分开。我之前试过在chunk里拼上文件路径和模块名一起embedding，召回准确率能提不少，你可以试试把元数据塞进文本里而不是只存metadata字段。cross-encoder rerank在代码场景确实容易翻车，表面token重叠度高但语义无关的它分不清，建议换个在代码对上微调过的re
我们之前也踩过一模一样的坑，并发串历史基本就是状态没做隔离，后来把conversation按session_id单独存Redis才解决。工具调用这块建议包一层统一的invoke wrapper，超时和格式错误都走同一个重试+降级逻辑，别让异常直接冒到chain顶层。LangGraph做状态机确实省心不少，但学习成本得算进去，简单场景自己维护反而更可控。
800万数据单机8分片，每个shard才100万，nlist设小了确实容易量化误差放大，但你暴力检索85%说明embedding本身没问题。我建议先看下每个分片实际返回的top结果重叠度，分片多路召回再合并时如果没做全局rerank，62%和85%的差距很可能是合并策略吃掉的。另外你top-5测试集是怎么构造的？如果是按query直接算的，阈值卡太死也会压低召回，可以先放开阈值看看上限。
先加rerank试试，成本低见效快，chunk的问题可以后面再慢慢调。
这个超时问题我也踩过坑，直接try-except重试3次确实太糙了，尤其是数据库那种偶尔抽风的场景，重试反而会把连接池搞得更乱。指数退避在client层做其实挺可行的，很多MCP的SDK都支持自定义transport或者拦截器，你可以在那里包一层backoff逻辑，加上jitter避免重试风暴。不过更关键的是要区分错误类型，TimeoutError和工具本身返回的业务错误得分开处理，前者可以退避重
刚入门，这个对我帮助很大。
学到了，感谢分享！
我之前也遇到过类似问题，后来换了方案。
学到了，感谢分享！
学到了，感谢分享！
我之前也遇到过类似问题，后来换了方案。
有没有更详细的教程推荐？
我之前也遇到过类似问题，后来换了方案。
有没有更详细的教程推荐？
这个思路不错，收藏了。
我之前也遇到过类似问题，后来换了方案。
这个问题我也踩过坑，感觉你现在的方向可能有点偏了，光调chunk和换模型不一定能解决根本问题。你问“怎么配置SSL证书”却返回安装步骤，很可能是chunk里把配置和安装混在一起了，检索时语义匹配被安装部分的词带跑了。建议试试按文档结构切，比如按标题层级或者段落语义来分，别只按固定token数硬切。另外embedding模型其实bge-m3已经挺能打了，换ada-002未必更好，关键得看你有没有做q
这个对比其实挺容易踩坑的，因为text-embedding-3-small在中文上并没有想象中那么强，我自己测过bge-m3在中文检索任务上经常是反超的，差距大更可能是流程哪里没对齐。你提到换chunk大小和top_k都没啥提升，我怀疑问题出在query侧——用户问法和文档里的表述往往有语义鸿沟，光靠调chunk解决不了。有个容易忽略的点是bge-m3官方推荐的query instruction，
ONNX Runtime默认跑的是FP32，理论上不该掉这么多，你先把onnx模型的输出和PyTorch逐层对一下，看误差是从哪层开始炸的。AdaptiveAvgPool在opset 11里转成AveragePool时如果输入尺寸不匹配，容易出问题，可以试试固定输入分辨率再导出。另外检查下是不是用了动态batch，动态轴有时候会触发一些奇怪的kernel。移动端的话4个点其实挺疼的，建议先定位原因
7B模型做RAG确实容易在检索结果利用上掉链子，我试过把chunk切小一点、加个rerank，召回质量能明显好一截。另外prompt里最好明确要求模型只根据检索内容回答，不然它老爱自己发挥。如果显存够，拿个13B专门做生成、7B只做query改写，分工一下效果会稳很多。