深夜增长档案馆

说实话你这问题我太有共鸣了，之前搭客服bot也是栽在召回不准上。后来我干脆把记忆拆成三层：短期对话窗口只留最近5轮，关键实体用正则+LLM抽出来存Redis，长期偏好才进向量库。这样“吃辣”和“川菜”能通过实体关联上，token也稳住了。但图结构我试过neo4j，维护成本真不低，小团队慎入。

指数退避确实比固定重试靠谱，但我觉得更关键的是区分超时原因，是网络抖动还是工具本身卡死。我这边之前是给MCP client加了个拦截器，按工具类型配置不同重试策略，比如天气查询这种外部API就退避重试3次，数据库查询直接走备选连接。另外建议把超时时间调成可配置的，别用默认值，有些工具响应慢是常态。你也可以看看MCP官方文档里有没有关于deadline的说明，我们后来发现设置合理的超时上限比单纯重试

我们团队之前也纠结过这个，最后选了ES+向量混合。纯向量检索在小规模下确实够用，但一旦加权限过滤，Milvus那些filter性能掉得厉害，ES的倒排+filter反而更稳。BM25和向量分数融合不用搞太复杂，RRF（倒数排名融合）最简单有效，比线性加权省心很多，实测效果也不差。你文档量几万篇真不算大，如果运维不想多养一套库，直接ES搞混合检索就行，后期扩展元数据筛选也方便，别被开源项目的默认配置

时间衰减加相似度双通道打分吧，菜谱和代码向量距离近很正常，纯靠阈值肯定误杀。 试试按对话session做时间窗口硬过滤，再在窗口内做相似度排序，这样新旧内容不会串味儿。

这问题我踩过一样的坑，vllm对rope_scaling的支持其实挺挑参数的，尤其和max_model_len一起调的时候很容易显存翻车。我的经验是先把max_model_len设成你实际要用的长度，别贪多，然后rope_scaling用YaRN但type选linear试试，配合vllm的--rope-scaling-config参数，别直接在模型config里改。另外你确认下是不是输入里塞了太多

你这情况太典型了，固定字符切分遇到长短差异大的文档基本都会翻车。建议先按标题层级切，至少保证一个chunk是个完整语义块，然后再对超长的段落做二次切分。另外bge-large这个模型对长文本本身就不太友好，512字符可能已经稀释了关键信息，试试把max_length降到256或者128，配合更小的chunk。重排我觉得有必要加，尤其这种FAQ场景，粗召回top20再让cross-encoder挑一

这个架构思路确实挺新颖的，用多芯片分工来替代单颗大算力SoC，感觉更像是从实际场景痛点出发的设计。HDR 140dB和480fps超慢动作这个组合，确实能有效减少逆光或快速运动时的丢帧问题，我之前测试过单芯片方案，光照变化剧烈时经常出现卡顿。不过好奇这种多芯片协同的延迟控制怎么样，毕竟家庭环境里实时性很关键。