如何处理历史错误命中的缓存向量和本次查询的相似度过高导致的查询错误？

[golddream-y]

您好：
如果有些知识相近或 LLM 对于垂直领域知识的不清晰，导致的第一次知识检索错误，然后当前查询向量和历史知识簇的查询嵌入向量匹配度过高，导致的错误命中如何处理?
是全部的 cache clear 还是有逐条清理的机制。如果是生产环境，可能全部清理的风险比较大。

延伸出来下一个问题，基于当前查询流程，如果是知识更新后，实际上可能出现匹配度更高的知识文档，但是当前由于缓存只能命中历史的cache，这个是否如何处理？
是否可以更新知识的时候，同步刷新相关缓存？

[wangxingjun778]

这个问题比较关键也相对更难权衡处理，采用以下两个action：

1. 【已完成】增加LLM response质量审计门控机制，对于LLM认为质量差的回答，或者纯chat内容，不做持久化处理，具体可参考0.0.5post2的release notes： https://github.com/modelscope/sirchmunk/releases/tag/v0.0.5post2
2. 【计划中】增加调度任务机制，对已有的cluster内容进行动态自学习，定期运行任务来合并、移除、刷新已存在的缓存中的知识簇，具体可持续关注这个feature的状态： [Feature] Scheduler module for self-learning from knowledge base #36

[golddream-y]

感谢解惑，对于 action2 个人觉得能解决大多数问题。在更加严谨的业务场景下，两个问题的都需要平衡知识管理成本和模型不确定性的副作用。
有一些不太成熟的建议，是否可以在后续规划中考虑一些人工介入的机制，比如 action1 后续考虑增加可配置的置信度和质量审计Prompt 自定义 ，如果高于 0.85 认为是安全区间，0.7～0.85 认为是争议区间，争议区间范围内的暂存，让人工标记，确定质量的好与坏。基于此，后可以对人工标记结果建立正负样本库，在 action2 中基于相关的正负样本能够相对更加准确的进行cache 内的知识清洗。

[wangxingjun778]

很好的建议，已创建feature跟进，后续可关注该feature状态： #92