记忆系统
AI agnt的分层记忆如何进行？
🏖️ LLM大多数还是通过缓存，缓存不下就通过数据库存起来，LLM缓存容量需要到大模型部署配置时候配置选择。
🎉 不管是短期记忆、中期记忆和长期记忆都需要根据业务复杂度和实时性需求进行灵活配置
| 记忆层级 | 记忆内容 | 作用 | |
|---|---|---|---|
| 短期记忆 | 1.工作记忆：当前任务上下文；2.对话历史：近期的交互记录；3.临时状态：执行的中间结果 | 使用上下文窗口或对话历史，实现对话轮次间的连贯性。适用于当前的对话的引用，追问与范文处理，优先使用缓存方案。 | |
| 中期记忆 | 对用户历史对话进行聚焦提取、嵌入编码并存入向量库，支持语义召回。适用于多轮对话、任务型助手等需要回忆近期语义信息的场景 | ||
| 长期记忆 | 将结构化知识（用户偏好、FAQ、行业资料）进入SQL数据库，供知识增强 |
多轮对话的检索性能优化策略
压缩历史对话内容，借助LLM进行层级摘要，对用户历史交互进行语义压缩，保留关键要素同时降低token成本。
情况一：需要重新召回
- 对话状态未持久化存储 如果对话系统没有将历史对话信息进行持久化存储（例如保存在数据库、缓存等中），那么每次进行新的对话交互时，系统无法直接获取到之前的对话内容。这时候为了能够理解当前对话与历史对话的上下文关系，就需要重新召回之前的历史问答。 例如，一个简单的命令行对话程序，如果没有将历史对话保存到文件或其他存储介质中，那么下一次启动程序进行对话时，就无法知道之前的对话内容，必须重新召回（如果有存储的话）或者重新开始对话。
- 对话逻辑需要完整上下文 某些复杂的对话场景，例如需要进行多轮的推理、决策或者涉及到多个相关问题的讨论，对话逻辑高度依赖完整的上下文信息。每次对话都需要基于之前所有的历史问答来进行，这样才能保证对话的连贯性和准确性。 比如在一个医疗问诊的对话系统中，医生（AI）需要根据患者之前描述的症状、病史、检查结果等所有历史信息来进行诊断和给出建议。如果不重新召回这些历史问答，就无法全面了解患者的情况，可能导致诊断错误。
- 用户可能回溯或修改之前的请求 在一些交互性较强的对话场景中，用户可能会回溯到之前的某个问题进行修改或者补充信息。这时候就需要重新召回之前的历史问答，以便根据用户的新操作来调整对话流程和结果。 例如在一个旅游规划的对话系统中，用户可能先询问了去某个景点的路线，之后又修改了出发时间，这时候系统需要重新召回之前关于景点和路线的对话内容，结合新的出发时间来重新规划路线。
情况二：不需要重新召回
- 对话状态已持久化存储且可快速访问 如果对话系统已经将历史对话信息进行了持久化存储，并且能够在需要的时候快速、方便地访问到这些信息，那么在大多数情况下不需要每次都重新召回之前的历史问答。系统可以直接从存储中获取相关的历史对话内容，用于当前对话的上下文理解和处理。 例如，一个基于 Web 的智能客服系统，用户的对话历史会被保存在服务器的数据库中，当用户再次发起对话时，系统可以通过用户标识快速从数据库中检索出该用户的历史对话记录，而不需要重新召回（这里的 “召回” 可能指的是从外部数据源重新获取，而不是从本地存储）。
- 当前对话与历史对话关联性较弱 在某些简单的对话场景中，每次对话的问题相对独立，与之前的历史对话关联性较弱。这时候可以不需要重新召回之前的历史问答，直接处理当前的问题即可。 比如在一个天气查询的对话系统中，用户每次询问的都是不同城市或者不同时间的天气情况，这些问题之间没有太多的上下文关联。系统可以直接根据用户当前的查询请求进行处理，而不需要考虑之前的天气查询历史