键盘边读书记

200字符分块对API文档来说太碎了，一个接口的签名、参数、返回值和示例经常被拦腰截断，模型拿到半截信息自然容易串味。而且你问的“创建订单并处理库存回滚”其实是个跨多个接口的组合意图，单靠向量相似度很难把分散在不同文档块里的相关片段都捞出来。我建议先把分块改成语义分块，按接口或功能单元来切，比如一个接口一块，把相关示例和错误码绑在一起。另外bge-large-zh在代码和API这种偏结构化文本上未

这问题我熟，之前做合同问答也栽这上面过。个人感觉bge-m3在长尾语义上确实容易把“相关但不对题”的段落拉进来，试试切分时加个标题/章节维度做候选过滤，比单纯调chunk_size管用。另外rerank别只依赖分数，可以按业务词表做个硬性初筛，比如报销流程相关词得同时命中才进top20。你现在的es里有没有存文档结构元数据？结构化约束比换模型见效快。

这个评测结果挺有意思的，我们之前做门牌识别的时候也遇到过类似问题，模型在规整字体上都快满分，一碰到手写体或者带图案的标识就崩。GLM-4.5V普通模式能赢，说明它确实没被“推理”带偏，直接靠视觉特征做判断反而更稳。不过你提到部署多模态，我更好奇的是你们在实际场景里测过不同光照和遮挡条件下的表现吗？那种情况下分数差距会不会更明显？

试试把历史对话压缩成摘要再拼进system prompt，亲测比单纯截断稳很多。 我这边是给关键意图加了个路由判断，无关问题直接走拒答分支，模型根本没机会跑偏。

哈哈，你这个问题我也纠结过很久。个人项目几百条对话量的话，我觉得直接上轻量级Agent框架可能更省心。RAG那种纯基于文本相似度的检索，确实在指代消解上天然弱势，像“上次那个方案”这种模糊引用，除非你额外加多层后处理逻辑，否则很难命中。我试过给Chunk加时间戳和对话轮次权重，效果有提升，但代码量直接翻倍，而且还得自己维护一个时间衰减函数，性价比不高。 MemGPT那种方案逻辑虽然复杂，但你仔细