该教程旨在解决用户在使用

应用程序时普遍遇到的一个问题#xff1a;如何高效地管理聊天历史记录。

LangChain

在管理聊天历史记录中的重要性并提供了相关教程链接帮助用户更好地理解和使用

Dragonfly

驱动的应用程序如聊天机器人优化性能是一项重大挑战。

大型语言模型LLMs是许多当今高级聊天机器人的核心但它们本质上是无状态的因此需要强大的机制来高效管理聊天上下文和会话数据。

虽然传统数据库如

Postgres能够存储聊天记录但添加一个具有快速访问速度和多功能数据结构的缓存层对于提高应用程序性能至关重要。

Dragonfly

的高性能内存数据存储解决方案非常适合用于缓存聊天机器人上下文和会话数据。

本文探讨了如何集成

Dragonfly

构建的聊天机器人的性能实现对最近聊天会话的快速访问并确保对话的连续性。

所有代码片段可在

dragonfly-examples

应用程序的过程。

通过抽象出与这些模型交互的复杂性LangChain

from

内存数据存储是一种数据库管理系统它将数据存储在计算机的主内存中而不是在磁盘上。

这允许更快地访问数据因为不需要从磁盘读取或写入数据。

在此场景中LangChain

处理消息并利用

本质上是无状态的。

在处理初始提示并生成响应后模型不会保留此交互的任何上下文。

如果用户随后提出问题如“我的名字是什么我想了解什么”模型将无法回忆起之前的上下文。

这种无状态性在开发需要在多次交互中保持上下文的对话代理时会带来障碍因为用户期望对话的连续性。

如果没有额外层来管理对话上下文或“状态”“记忆”聊天机器人可能会显得脱节因为它无法识别过去的交互。

存储聊天会话

为了提供无缝和有吸引力的用户体验必须实现一种机制使聊天机器人能够记住之前的交互并保持上下文。

一种方法是将我们的

LLM

ChatSession(Base):__tablename__

chat_sessions

back_populateschat_session)class

ChatHistory(Base):__tablename__

chat_histories

back_populateschat_histories)我们的数据库模式包含两个主要实体ChatSession

ChatHistory。

这些实体旨在记录并链接每次聊天会话中的每次交互使用

SQLAlchemy一个

ORM。

如上所示每个聊天会话都与多个聊天历史记录相关联多对一每次需要与

LLM

通常有一个有限的上下文窗口这意味着我们不能向它们发送无限数量的词或标记。

将一切包装为服务

对象的消息该对象是用户发送的提示消息。

它还有三个依赖项如你可能猜到的一个数据库连接一个

Dragonfly

交互的更多细节。

但这里的主要思想是我们将用户的第一个提示消息发送到

OpenAI然后创建一个聊天会话记录以及前两个聊天历史记录即提示和响应。

app.post(/chat)

HumanMessage(contentchat_message_human.content)

chat_message_ai

创建一个新的聊天会话包含前两个聊天历史记录条目。

chat_session

ChatSessionCreate(llm_nameLARGE_LANGUAGE_MODEL_NAME)

new_chat_histories

__messages_to_histories(chat_message_human,

chat_message_ai)

srv.create_chat_session(chat_session,

new_chat_histories)

chat_session_response接下来我们有以下端点来帮助用户继续与

LLM

ID它是从上一个端点回复的以便我们知道用户正在处理特定的聊天会话。

我们检查聊天会话的存在性检索该会话的过去某些数量的聊天历史记录并将它们与用户新提供的提示消息一起发送给

async

srv.read_chat_histories(chat_id)

None:

prev_chat_session_response.chat_histories

messages

chat_histories[i].is_human_message:

messages.append(HumanMessage(contentchat_histories[i].content))

else:

messages.append(AIMessage(contentchat_histories[i].content))

messages.append(HumanMessage(contentchat_message_human.content))

OpenAI

__messages_to_histories(chat_message_human,

chat_message_ai)

srv.add_chat_histories(prev_chat_session_response,

new_chat_histories)

chat_session_response一个示例连续上下文对话可能如下所示

{chat_session_id:

}最后我们有一个端点来检索聊天会话。

想象一个用户在初次聊天几天后回来我们仍然能够检索该聊天会话并从那里继续。

LLM

的内部工作方式但有许多机会可以提高服务器的效率。

**聊天机器人的交互通常在当前或最近的会话中最为频繁和密集。

**用户动态地与机器人互动通常需要机器人立即回忆对话的上下文。

通过缓存这些最近的交互我们确保聊天机器人能够立即访问会话信息显著减少检索时间提升用户体验。

Dragonfly

是缓存的理想解决方案因为它具有高性能、多线程的能力。

它被设计为一个强大的内存数据存储提供极快的缓存数据访问速度。

通过在

Dragonfly

中存储最近聊天会话的上下文和详细信息我们的聊天机器人可以快速获取必要的信息而无需反复查询主数据库。

如上面的代码片段所示我们的

DataService

srv.read_chat_histories(chat_id)

路径为例我们使用旁路缓存策略首先尝试从

中随时可用较旧的会话则不会被丢弃而是持久存储在数据库中。

这些会话由于访问可能性较低而不会主动保存在缓存中。

但是如果一个旧会话再次变得相关可能是因为用户回到了过去的主题上述机制会将这些会话从数据库中检索并重新缓存。

def

cache_svc.read_chat_histories(chat_session_id)

not

ChatSessionResponse(chat_session_id,

如果聊天历史记录未缓存于

self.db.query(models.ChatHistory)

.filter(models.ChatHistory.chat_session_id

chat_session_id)

.order_by(models.ChatHistory.id)

.limit(100)

cache_svc.add_chat_histories(chat_session_id,

return

ChatSessionResponse(chat_session_id,

chat_history_responses)缓存到磁盘比例平衡成本和性能

虽然缓存的概念很简单——将数据暂时存储在更快的存储介质中以快速访问但决定缓存什么数据以及缓存多长时间则更为复杂。

一个看似微不足道但常常被忽视的问题是为什么不缓存所有内容让我们深入探讨为什么这种方法通常不可行以及为什么一个出色的驱逐策略很重要。

内存相对于磁盘存储的主要优势在于速度。

内存数据的访问时间显著快于磁盘检索。

然而这种速度是有代价的。

内存的成本远高于磁盘存储无论是初始投资还是维护费用。

递减效益

虽然缓存可以显著提升性能但随着缓存的数据增多效益会逐渐递减。

这是因为并非所有存储的数据都经常被访问。

在许多应用中仅有一小部分数据经常被访问而大部分数据很少被使用——这被称为

长尾效应它与我们在聊天机器人示例中看到的情况完全吻合。

将这些很少访问的长尾数据存储在昂贵的内存资源中提供的性能提升相对于成本来说是最小的。

长尾效应

采用了超越传统最近最少使用LRU或最少频繁使用LFU方法的先进缓存驱逐算法。

这些传统算法并不总是与现代应用的实际使用模式相匹配后者可能需要更不可预测地访问某些类型的数据。

Dragonfly

根据访问的最近性和频率优先级数据确保最相关和最常访问的数据在缓存中停留时间更长。

在达到内存限制之前主动驱逐数据这有助于在不因缓存饱和而突然减速的情况下保持最佳性能。

优化了内存使用确保系统在不增加不必要的内存成本的情况下保持响应性。

要利用这一强大功能只需在启动

Dragonfly

等工具进行内存管理对于创建互动和连续的用户体验至关重要。

通过采用智能缓存策略并维护动态内存数据存储开发人员可以显著提升聊天机器人的响应速度和上下文感知能力。

这不仅改善了用户交互还优化了资源利用有效平衡了成本和性能。

Dragonfly

提升了性能但磁盘数据库对于长期数据持久性和完整性仍然至关重要。

它们确保数据随着时间的推移保持安全和可检索当缓存数据不可用时提供后备支持。

缓存策略的探索和聊天会话管理的实际实现表明通过使用合适的工具和方法实现无状态

LLM

的有状态交互不仅是可能的而且是高度有效的。

除了先进的缓存驱逐算法Dragonfly

Redis