LangChain 团队发布了一篇关于使用 Dragonfly DB 来有效管理 LangChain 应用程序聊天历史记录的教程。
该教程旨在解决用户在使用 LangChain 应用程序时普遍遇到的一个问题:如何高效地管理聊天历史记录。
LangChain 团队在推文中强调了 Dragonfly DB 在管理聊天历史记录中的重要性,并提供了相关教程链接,帮助用户更好地理解和使用 Dragonfly DB。
引言
在快速发展的软件开发领域,为实时 AI 驱动的应用程序(如聊天机器人)优化性能是一项重大挑战。大型语言模型(LLMs)是许多当今高级聊天机器人的核心,但它们本质上是无状态的,因此需要强大的机制来高效管理聊天上下文和会话数据。虽然传统数据库(如 Postgres)能够存储聊天记录,但添加一个具有快速访问速度和多功能数据结构的缓存层对于提高应用程序性能至关重要。
Dragonfly 是一个现代的、多线程的、兼容 Redis 的高性能内存数据存储解决方案,非常适合用于缓存聊天机器人上下文和会话数据。本文探讨了如何集成 Dragonfly 来大幅提升使用 LangChain 构建的聊天机器人的性能,实现对最近聊天会话的快速访问,并确保对话的连续性。所有代码片段可在 dragonfly-examples 仓库中找到。本文将使用 LangChain 库的 Python 版本。
使用 FastAPI 和 LangChain 构建聊天机器人
LangChain 是一个强大的 AI 优先工具包,它简化了使用高级语言模型(如 OpenAI 提供的模型)来创建互动 LLM 应用程序的过程。通过抽象出与这些模型交互的复杂性,LangChain 使开发人员能够专注于优化用户体验和增强对话能力。
考虑一个用户发起对话的简单示例:
from langchain_openai import ChatOpenAI``from langchain_core.messages import HumanMessage`` ``chat = ChatOpenAI(model=MODEL_NAME, temperature=0.2)``chat.invoke(` `[` `HumanMessage(` `content="My name is Joe. I would like to learn more about in-memory data stores!"` `)` `]``)`` ``# 内存数据存储是一种数据库管理系统,它将数据存储在计算机的主内存中,而不是在磁盘上。``# 这允许更快地访问数据,因为不需要从磁盘读取或写入数据。
在此场景中,LangChain 处理消息并利用 OpenAI 的 API 生成相关响应。尽管非常强大,但需要注意的是,像 OpenAI 这样的 LLM 本质上是无状态的。在处理初始提示并生成响应后,模型不会保留此交互的任何上下文。如果用户随后提出问题如“我的名字是什么,我想了解什么?”模型将无法回忆起之前的上下文。
这种无状态性在开发需要在多次交互中保持上下文的对话代理时会带来障碍,因为用户期望对话的连续性。如果没有额外层来管理对话上下文(或“状态”,“记忆”),聊天机器人可能会显得脱节,因为它无法识别过去的交互。
存储聊天会话
为了提供无缝和有吸引力的用户体验,必须实现一种机制,使聊天机器人能够记住之前的交互并保持上下文。一种方法是将我们的 LLM 交互包装为后端服务,使用传统数据库如 Postgres 来存储聊天会话和历史记录。
from sqlalchemy import Boolean, Column, ForeignKey, Integer, String``from sqlalchemy.orm import relationship`` ``from database import Base`` ``class ChatSession(Base):` `__tablename__ = "chat_sessions"`` ` `id = Column(Integer, primary_key=True)` `llm_name = Column(String, nullable=False)`` ` `chat_histories = relationship("ChatHistory", back_populates="chat_session")`` `` ``class ChatHistory(Base):` `__tablename__ = "chat_histories"`` ` `id = Column(Integer, primary_key=True)` `chat_session_id = Column(Integer, ForeignKey("chat_sessions.id"), nullable=False)` `is_human_message = Column(Boolean, nullable=False)` `content = Column(String, nullable=False)`` ` `chat_session = relationship("ChatSession", back_populates="chat_histories")
我们的数据库模式包含两个主要实体:ChatSession
和 ChatHistory
。这些实体旨在记录并链接每次聊天会话中的每次交互,使用 SQLAlchemy,一个 Python SQL 工具包和 ORM。如上所示,每个聊天会话都与多个聊天历史记录相关联(多对一),每次需要与 LLM 交互时,我们都会将一堆先前的聊天历史记录(称为 上下文窗口)发送给它。通过这样做,LLM 可以“回忆”此对话的上下文并连续响应。LLM 通常有一个有限的上下文窗口,这意味着我们不能向它们发送无限数量的词或标记。
将一切包装为服务
我们将使用 FastAPI,这是一个现代的、快速的 web 框架,用于使用基于标准 Python 类型提示的 Python 3.6+ 构建 API。我们的第一个 API 端点旨在处理新聊天消息,通过 LangChain 交互 OpenAI API,并使用数据存储维护对话上下文。该端点接收用户发送的 ChatMessageCreate
对象的消息,该对象是用户发送的提示消息。它还有三个依赖项,如你可能猜到的:一个数据库连接,一个 Dragonfly 连接,以及一个由 LangChain 工具包提供的 OpenAI API 客户端。我们将详细介绍数据库和 Dragonfly 交互的更多细节。但这里的主要思想是我们将用户的第一个提示消息发送到 OpenAI,然后创建一个聊天会话记录以及前两个聊天历史记录(即提示和响应)。
@app.post("/chat")``async def new_chat(` `chat_message_human: ChatMessageCreate,` `db: Session = Depends(get_db_session),` `df: Dragonfly = Depends(get_dragonfly),` `chat: ChatOpenAI = Depends(get_chat),``) -> service.ChatSessionResponse:` `# 调用 OpenAI API 获取 AI 响应。` `message = HumanMessage(content=chat_message_human.content)` `chat_message_ai = chat.invoke([message])`` ` `# 创建一个新的聊天会话,包含前两个聊天历史记录条目。` `chat_session = ChatSessionCreate(llm_name=LARGE_LANGUAGE_MODEL_NAME)` `new_chat_histories = __messages_to_histories(chat_message_human, chat_message_ai)` `srv = service.DataService(db, df)` `chat_session_response = srv.create_chat_session(chat_session, new_chat_histories)` `return chat_session_response
接下来,我们有以下端点来帮助用户继续与 LLM 的互动。类似的参数和依赖项存在,但这次我们接收聊天会话 ID,它是从上一个端点回复的,以便我们知道用户正在处理特定的聊天会话。我们检查聊天会话的存在性,检索该会话的过去某些数量的聊天历史记录,并将它们与用户新提供的提示消息一起发送给 LLM。通过这样做,LLM 将能够了解对话的上下文并相应地响应。
@app.patch("/chat/{chat_id}")``async def continue_chat(` `chat_id: int,` `chat_message_human: ChatMessageCreate,` `db: Session = Depends(get_db_session),` `df: Dragonfly = Depends(get_dragonfly),` `chat: ChatOpenAI = Depends(get_chat),``) -> service.ChatSessionResponse:` `# 检查聊天会话是否存在并加载聊天历史记录。` `srv = service.DataService(db, df)` `prev_chat_session_response = srv.read_chat_histories(chat_id)` `if prev_chat_session_response is None:` `raise HTTPException(status_code=404, detail="chat not found")`` ` `# 从聊天历史记录构建消息,然后附加新的用户消息。` `chat_histories = prev_chat_session_response.chat_histories` `messages = []` `for i in range(len(chat_histories)):` `if chat_histories[i].is_human_message:` `messages.append(HumanMessage(content=chat_histories[i].content))` `else:` `messages.append(AIMessage(content=chat_histories[i].content))` `messages.append(HumanMessage(content=chat_message_human.content))`` ` `# 调用 OpenAI API 获取 AI 响应。` `chat_message_ai = chat.invoke(messages)`` ` `# 将两个聊天历史记录条目添加到现有聊天会话中。` `new_chat_histories = __messages_to_histories(chat_message_human, chat_message_ai)` `chat_session_response = srv.add_chat_histories(prev_chat_session_response, new_chat_histories)` `return chat_session_response
一个示例连续上下文对话可能如下所示:
{` `"chat_session_id": 1,` `"chat_histories": [` `{` `"id": 1,` `"content": "I want to learn more about in-memory data store.",` `"is_human_message": true` `},` `{` `"id": 2,` `"content": "An in-memory data store is a type of database management system that stores data in the main memory`` ` `of a computer rather than on a disk or other storage device...",` `"is_human_message": false` `},` `{` `"id": 3,` `"content": "What are some good use cases?",` `"is_human_message": true` `},` `{` `"id": 4,` `"content": "In-memory data stores are well-suited for a variety of use cases where speed, performance, and real-time data access are critical. Some common use cases for in-memory data stores include:...",` `"is_human_message": false` `}` `]``}
最后,我们有一个端点来检索聊天会话。想象一个用户在初次聊天几天后回来,我们仍然能够检索该聊天会话并从那里继续。
@app.get("/chat/{chat_id}")``async def read_chat_histories(` `chat_id: int,` `db: Session = Depends(get_db_session),` `df: Dragonfly = Depends(get_dragonfly),``) -> service.ChatSessionResponse:` `srv = service.DataService(db, df)` `chat_session_response = srv.read_chat_histories(chat_id)` `if chat_session_response is None:` `raise HTTPException(status_code=404, detail="chat not found")` `return chat_session_response
缓存最近的聊天会话
缓存是优化服务器端应用程序性能的关键技术。尽管我们无法优化 LLM 的内部工作方式,但有许多机会可以提高服务器的效率。**聊天机器人的交互通常在当前或最近的会话中最为频繁和密集。**用户动态地与机器人互动,通常需要机器人立即回忆对话的上下文。通过缓存这些最近的交互,我们确保聊天机器人能够立即访问会话信息,显著减少检索时间,提升用户体验。
Dragonfly 是缓存的理想解决方案,因为它具有高性能、多线程的能力。它被设计为一个强大的内存数据存储,提供极快的缓存数据访问速度。通过在 Dragonfly 中存储最近聊天会话的上下文和详细信息,我们的聊天机器人可以快速获取必要的信息,而无需反复查询主数据库。如上面的代码片段所示,我们的 DataService
类同时操作数据库和 Dragonfly。以 srv.read_chat_histories(chat_id)
路径为例,我们使用旁路缓存策略,首先尝试从 Dragonfly 读取。如果找到特定 chat_id
的聊天历史记录(作为排序集条目存储),我们可以快速返回响应。如果在 Dragonfly 中找不到键,我们会回退到读取数据库,并被动地在 Dragonfly 中缓存这些历史记录,设置一个过期时间。最近的聊天会话会在 Dragonfly 中随时可用,较旧的会话则不会被丢弃,而是持久存储在数据库中。这些会话由于访问可能性较低而不会主动保存在缓存中。但是,如果一个旧会话再次变得相关(可能是因为用户回到了过去的主题),上述机制会将这些会话从数据库中检索并重新缓存。
def read_chat_histories(self, chat_session_id: int) -> Union[ChatSessionResponse, None]:` `# 检查聊天历史记录是否缓存于 Dragonfly。` `cache_svc = _DataCacheService(self.df)` `chat_history_responses = cache_svc.read_chat_histories(chat_session_id)` `if chat_history_responses is not None and len(chat_history_responses) > 0:` `return ChatSessionResponse(chat_session_id, chat_history_responses)` ` # 如果聊天历史记录未缓存于 Dragonfly,则从数据库读取并缓存于 Dragonfly。` `chat_histories = self.db.query(models.ChatHistory) \` `.filter(models.ChatHistory.chat_session_id == chat_session_id) \` `.order_by(models.ChatHistory.id) \` `.limit(100) \` `.all()` `if chat_histories is None or len(chat_histories) == 0:` `return None`` ` `chat_history_responses = [ChatHistoryResponse(v.id, v.content, v.is_human_message) for v in chat_histories]` `cache_svc.add_chat_histories(chat_session_id, chat_history_responses)` `return ChatSessionResponse(chat_session_id, chat_history_responses)
缓存到磁盘比例:平衡成本和性能
虽然缓存的概念很简单——将数据暂时存储在更快的存储介质中以快速访问,但决定缓存什么数据以及缓存多长时间则更为复杂。一个看似微不足道但常常被忽视的问题是:为什么不缓存所有内容?让我们深入探讨为什么这种方法通常不可行,以及为什么一个出色的驱逐策略很重要。
内存与磁盘的权衡:速度与成本
内存相对于磁盘存储的主要优势在于速度。内存数据的访问时间显著快于磁盘检索。然而,这种速度是有代价的。内存的成本远高于磁盘存储,无论是初始投资还是维护费用。
递减效益
虽然缓存可以显著提升性能,但随着缓存的数据增多,效益会逐渐递减。这是因为并非所有存储的数据都经常被访问。在许多应用中,仅有一小部分数据经常被访问,而大部分数据很少被使用——这被称为 长尾效应,它与我们在聊天机器人示例中看到的情况完全吻合。将这些很少访问的长尾数据存储在昂贵的内存资源中,提供的性能提升相对于成本来说是最小的。
长尾效应
使用 Dragonfly 高效管理缓存
理解这些权衡,Dragonfly 采用了超越传统最近最少使用(LRU)或最少频繁使用(LFU)方法的先进缓存驱逐算法。这些传统算法并不总是与现代应用的实际使用模式相匹配,后者可能需要更不可预测地访问某些类型的数据。
Dragonfly 的驱逐算法旨在通过以下方式智能管理缓存空间:
-
根据访问的最近性和频率优先级数据:确保最相关和最常访问的数据在缓存中停留时间更长。
-
在达到内存限制之前主动驱逐数据:这有助于在不因缓存饱和而突然减速的情况下保持最佳性能。
通过这种方法,Dragonfly 优化了内存使用,确保系统在不增加不必要的内存成本的情况下保持响应性。要利用这一强大功能,只需在启动 Dragonfly 服务器时传递 --cache_mode=true
配置标志。
结论
LangChain 为使用 OpenAI 等 LLM 提供了一个强大的框架,使用 Dragonfly 等工具进行内存管理对于创建互动和连续的用户体验至关重要。通过采用智能缓存策略并维护动态内存数据存储,开发人员可以显著提升聊天机器人的响应速度和上下文感知能力。这不仅改善了用户交互,还优化了资源利用,有效平衡了成本和性能。
需要注意的是,尽管内存解决方案如 Dragonfly 提升了性能,但磁盘数据库对于长期数据持久性和完整性仍然至关重要。它们确保数据随着时间的推移保持安全和可检索,当缓存数据不可用时提供后备支持。缓存策略的探索和聊天会话管理的实际实现表明,通过使用合适的工具和方法,实现无状态 LLM 的有状态交互不仅是可能的,而且是高度有效的。除了先进的缓存驱逐算法,Dragonfly 还有许多吸引人的功能,如完全兼容 Redis 协议、高效的快照机制、Memcached 模式、集群模式等。立即开始使用 Dragonfly(下载社区版或申请免费 Dragonfly Cloud 试用)并构建你自己的惊人 AI 驱动应用程序!
如何学习大模型 AI ?
由于新岗位的生产效率,要优于被取代岗位的生产效率,所以实际上整个社会的生产效率是提升的。
但是具体到个人,只能说是:
“最先掌握AI的人,将会比较晚掌握AI的人有竞争优势”。
这句话,放在计算机、互联网、移动互联网的开局时期,都是一样的道理。
我在一线互联网企业工作十余年里,指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑,所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限,很多互联网行业朋友无法获得正确的资料得到学习提升,故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
第一阶段(10天):初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识,对大模型 AI 的理解超过 95% 的人,可以在相关讨论时发表高级、不跟风、又接地气的见解,别人只会和 AI 聊天,而你能调教 AI,并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么?
- 大模型是怎样获得「智能」的?
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例:向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段(30天):高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习,学会构造私有知识库,扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架,抓住最新的技术进展,适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示(Embeddings)
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段(30天):模型训练
恭喜你,如果学到这里,你基本可以找到一份大模型 AI相关的工作,自己也能训练 GPT 了!通过微调,训练自己的垂直大模型,能独立训练开源多模态大模型,掌握更多技术方案。
到此为止,大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗?
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2:手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段(20天):商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知,可以在云端和本地等多种环境下部署大模型,找到适合自己的项目/创业方向,做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身:基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例:如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程,只要学习就会有挑战。天道酬勤,你越努力,就会成为越优秀的自己。
如果你能在15天内完成所有的任务,那你堪称天才。然而,如果你能完成 60-70% 的内容,你就已经开始具备成为一名大模型 AI 的正确特征了。