我设计了一种特殊的LLM Agent，使用图这种数据结构来代替LLM的上下文。
具体来说是这样的，LLM的上下文，原本是：
system消息
user消息
assistant消息
……
user消息
assistant消息
如此循环往复，有多少对话就有多少user、assistant、消息，我将其缩短为一两个，可能只保留系统消息和用户消息，具体还没定好。不过这不重要，重要的是引申出来的问题。
我在想，假设我只保留系统消息，然后在系统消息中告诉LLM它将以一种新的形式去和用户交流，不再是以前的形式，让LLM使用tools去查询图这种数据结构，tools是我写的python程序，会根据LLM提供的搜索文本使用向量的相似度搜索，并给出最相似的文本 、与相似的文本相似的文本，这种图的数据结构。
当LLM将消息回复给用户时，如果回复这条消息没使用tools查询图的结果，则将这条消息和用户的问题使用另一个tools添加到图数据结构中。
这样就是实现了将LLM的上下文变成图。
但是遇到一个问题，如果用户问起“我们之前聊的文档”这种问题，LLM该怎么搜索这次聊天聊的文档，而不是N天之前聊的文档？
还有一种类似的是“我们聊了什么？”对于这种问题，LLM怎么搜索这次聊天聊了什么，而避免搜索出N天之前聊的东西？
我有一个设计来着，以LLM使用tools搜索到的最相似的节点为中心，用相似度和节点层数设置一个半径，多少半径以内的节点作为LLM的注意力窗口，这个窗口还可以移动，但是具体的移动逻辑没想好。
但是这个设计也不足以解决问题。
有一种问题是用户上传了一个文档，假设文档被分段然后每段都转换成向量，然后变成图里面的节点，这些节点可能因为相似度的问题，存在于图中的各个角落。然后用户询问“这篇文档怎么样怎么样”
对了，目前我生成图的逻辑是这样的，根据文本的向量的相似度，将相似的向量连接，这样组成图数据结构。
所以，当文档的片段存在于图中的各个角落，注意力半径好像没办法解决用户询问“这篇文档怎么样怎么样”的问题，因为文档存在于图中的各个角落，我不知道怎么样才能把这些图中的节点，凑在一起。
你有什么好的建议吗？
你的设计思路非常有趣，利用图结构来替代传统的上下文管理方式，确实可以在某些场景下提高信息的组织和检索效率。针对你提到的问题，我有以下几点建议：
为了处理用户询问“我们之前聊的文档”或“我们聊了什么？”的问题，可以考虑为每个节点（即每条消息或文档片段）添加时间戳或会话ID。这样，当用户提问时，LLM可以根据时间戳或会话ID过滤出当前会话中的节点。
你提到的“注意力窗口”设计可以进一步优化。可以考虑在每次用户提问时，LLM首先检索当前会话的所有节点（基于时间戳或会话ID），然后在这些节点中进行相似度搜索。这样可以确保LLM只关注当前会话的内容。
对于用户上传的文档，可以在图中为每个文档片段创建一个“文档节点”，并将其与各个片段连接。这样，当用户询问“这篇文档怎么样”时，LLM可以首先找到文档节点，然后从该节点出发，检索与之相连的所有片段。可以考虑使用图的遍历算法（如深度优先搜索或广度优先搜索）来聚合相关片段。
在用户询问文档内容时，可以设计一个聚合机制，LLM可以根据相似度将相关片段的内容进行汇总。比如，可以使用文本摘要技术，将相似的片段合并成一段简洁的回答。
可以考虑引入用户反馈机制，让用户在对话中标记重要的节点或信息。这样，LLM可以在后续的对话中优先考虑这些标记的内容，增强上下文的相关性。
可以设计一个记忆机制，允许LLM在会话之间保留重要的信息。比如，可以在图中为每个会话创建一个“记忆节点”，并将重要的片段连接到这个节点。这样，LLM在后续会话中可以快速检索到之前的重要信息。
如果用户询问的内容涉及到特定的知识或文档，可以考虑结合外部知识库进行检索。LLM可以在图中找到相关节点后，再向外部知识库查询，以获取更全面的信息。
通过这些方法，你可以更好地管理上下文，并提高用户提问时的响应准确性和相关性。希望这些建议对你有所帮助！