认真前端手记

这问题我太熟了，之前做合同审查也踩过同样的坑。你试试把chunk改成按章节或条款语义切分，别死磕固定长度，512的窗口对“违约金”这种跨段落定义确实容易切散。另外bge-large-zh对短query和长文档的匹配其实挺吃力的，换text-embedding-3-large未必立竿见影，但rerank一定要上，尤其你混合检索后噪声变多，不重排等于白搭。还有个小技巧，把合同标题和条款编号作为元数据拼

说实话固定切分在混合文档上基本就是碰运气，尤其代码和markdown表格混在一起，500token很容易把语义拦腰截断。我生产环境里最后是先用结构感知切分，比如按标题层级和代码块边界做预分割，再对长段落用递归字符切分兜底，overlap控制在10%-15%就够，太大反而会让重复内容干扰向量相似度。你提到rerank，这个其实能救回不少top5的准确率，但前提是chunk粒度不能太碎，我建议检索阶段

我们团队之前也是纯ES，几百万向量扛到后面查询延迟确实上来了，调分片和堆内存折腾了快两周，最后还是加了Qdrant。不过如果你们数据增速不快，ES的KNN配上限流策略也能顶一阵子，关键是别让向量字段和其他业务字段混在同一个大分片里。你说的分片参数，建议先按每个分片2-4GB数据量来算，memory那层多给点，但说实话并发高的时候ES的CPU会先报警。

我也遇到过类似的问题，当时用QLoRA微调了一个8B模型做代码补全，单步生成确实变好了，但一放到多轮对话或者需要调用外部工具的场景，模型就像失忆了一样，经常重复之前说过的内容或者直接忽略上下文。后来我翻了一些论文和社区的讨论，感觉问题可能出在两个方面。 第一是微调数据本身的结构。你用的领域问答对可能是“输入->输出”这种静态映射，但Agent场景下需要的是“状态->动作”的动态决策，比如“当前用