ChatGPT 和 LangChain
date
Apr 13, 2023
slug
chatgpt_langchain
status
Published
tags
ChatGPT
AI
summary
大型语言模型 (LLM) 和围绕它的软件基础架构能否使计划自动化？在这一部分中，我们测试了我们新的 langchain ……这是一个雄心勃勃的项目，但它揭示了使用大型语言模型时的一些重要新概念。 LLM 不仅有效地成为软件的新构建块，不仅成为与最终用户交互的方式……而且成为内部协调员和利用现有代码功能的新方式，迷人。
type
Post
为什么这是一个重要的Use Case？
我们认为，消息传递应用程序、LLM 和“推理系统”的组合效应将取代大多数前台工作。……推理功能将不可避免地与语言处理相结合，以实现常见的前台功能，例如：日历安排、管理预订。
世界上许多小型企业都是以服务为基础的，而且大多数以服务为基础的企业都是按时间表运营的（提供什么服务——为谁——由谁——何时提供）。
大语言模型并不擅长这一点，归根结底，因为大多数时间表都有独特的特征，因为没有一个统一的、标准类型的“时间表”，所以涉及到一些推理。
所以今天，无数人通过电话和 [越来越多地] 在与客户的消息线程中管理企业的日程安排。我们可以自动安排吗？这是一个大问题，不仅因为它的实际用途，而且因为它是我们有兴趣了解的前台自动化中断的预兆。
第 1 部分：ChatGPT 可以用日程表做什么？我们需要什么？
就其本身而言：不多。
让我们采用一个简单的 5 天计划并以 json 格式表示，Key是日期，Value是时间（24 小时格式）和客户名称：
让我们把这个连同指令交给 ChatGPT，看看它能做什么……
- LLM 无法知道企业的日程安排如何运作或它与任何其他日程安排有何不同
- LLM没有整合到企业的日历中来创建预订
我们需要一种方法来连接或“链接”LLM（例如 ChatGPT）与“推理系统”。推理系统最好和最简单的例子是……写代码。这就是 LangChain 的用武之地。
LangChain 是一个用于开发由语言模型驱动的应用程序的框架。我们相信，最强大和差异化的应用程序不仅会通过 API 调用语言模型，而且还会：
1.数据感知：将语言模型连接到其他数据源
2.允许语言模型与其环境交互
我们需要将 LLM 与这些功能链接起来，并将它们包装成一个集合，用户可以使用该集合通过自然语言与它们进行交互。在这种类型的系统内部，LLM 将使用提供的函数来处理数据，此外它将解释这些函数的返回值以确定需要什么。这是一种在程序执行中使用自然语言来使事情正常进行的方法。
这是一个notebook，用于设置和组织简单的日程安排……
我们检查可用时间的功能：
以及我们保留日期/时间的功能：
请注意，返回值都非常冗长且具有描述性。这对于内部函数来说是不正常的。我们需要这个，因为我们将在我们的链中使用这些功能作为工具，LLM 将使用自然语言与这些功能进行交互。
第 2 部分：创建一个结构以使用所需的工具“链接”LLM
我们的调度测试装置的完整代码在这里：
我们将逐个检查它，
首先，必要的导入：（根据需要安装）
您会在这里注意到以下内容：（请在继续之前阅读，这些是新概念）
OpenAI（这里不需要介绍），我们将使用它作为我们的 LLM
接下来我们设置我们的第一个链：（我已经更改了 API 密钥，插入你自己的）
这将实例化我们的 llm 并创建一个 PALChain，我们可以使用它来解决“单词问题”，例如“从现在起 7 天”。我们将在我们的工具定义中引用这个 PAL 链……
在这里，我们定义了我们的链将能够使用的“工具”。 4个工具：
- 今天日期的简单 Python 函数
- 我们在第 1 部分中描述的调度实用程序函数
- 我们的 PAL 链
请注意，每个工具都使用 lambda 来描述接口，但更重要的是请注意，每个工具都提供了如何使用它的自然语言描述。这类似于Prompt，必须谨慎措辞。
请注意，工具本身可以是一条链……链套链。
最后我们实例化我们的链：
Memory已定义（阅读带有上面链接的内存文档）以获取更多详细信息。我们实例化 streamlit (st) 会话状态并初始化我们的 agent_chain。
有关 streamlit.io 中会话状态的详细信息，请参阅： https://docs.streamlit.io/library/api-reference/session-state
verbose=True 将为我们提供内部运作方式的详细信息……
又一个新概念：‘Agent’，这里读文档：
最后是 streamlit 网络应用程序设置：
第 3 部分：检查结果——细节决定成败……
我们运行我们的装备： $ streamlit run langChainFuncs.py
让我们从最简单的[上下文]问题开始：
为了回答我们的 LLM 需要调用函数“今天的日期”，我们可以通过查看详细日志看到它使用了它：
回想一下我们之前定义今天的日期“工具”：
因此，我们的代理“链”提供了一个功能来检索 LLM 不一定拥有的一条信息。
今天的日期可能微不足道，但 LLM 也无法访问无限的内部业务信息，这些数据远不及它的训练语料库。
让我们继续……为了简化我们将使用具有相同代码的笔记本：
您会注意到我们添加了 dayOfWeek(date) 函数和工具。另请注意，我们提前了一天...…
本题langchain使用PAL和定义的PalChain来计算明天的日期。这类似于解决数学应用题。
它正确地使用了工具“可用约会”，它用所需的日期参数（上面的紫色部分）回复，然后链用正确格式的日期重试并得到答案。
内部再次对日期格式提出了一些反对意见，但它能够询问明天的可用时间。
使用另一种工具，我们到达了明天的星期几。
可用时间（来自“可用约会”工具）正确地给出了答案。 LLM“理解”函数响应的另一个例子。
这变得有点棘手，LLM 正确地确定明天下午 3 点（15:00）是可用的，但在响应中犯了一个错误，包括初始问题中的两个时间。
在这里，我们开始了一条富有成效的道路，“我需要找出今天是星期几”，结果是“星期三”（正确），然后是“我需要找出这个星期五是星期几”，但出于奇怪的原因尝试 +3 天（而不是 +2），然后继续检查第 15 天（本周六）的可用性。接近但不完全是！
但在此查询中，它正确地将 2 天添加到当前日期。
我们可以尝试什么？
我们可以尝试使用不同的“代理”或构建更适合此类链的新代理。 https://python.langchain.com/en/latest/modules/agents/agents/agent_types.html
尝试使用代理：
conversational-react-description您可以按如下方式检查代理：
在上方，您可以看到代理的对话片段/部分的结构。您可以创建自定义代理： https://python.langchain.com/en/latest/modules/agents/agents/custom_agent.html
我们还可以尝试在调度函数中提供改进的描述，并努力确保“明天”和“本周三”的日期计算正确。后者似乎是一个可以隔离和解决的问题，而不管链的其他部分如何。
您还可以尝试更新更强大的 GPT Turbo 3
反思（现在）……
Langchain 正走在一条富有成效且至关重要的道路上，但事情仍然很原始。这是意料之中的。 Langchain 的 github 存储库始于 22 年 10 月。
新模型将不可避免地以新方式与这些链及其“代理”交互，因此链基础设施将需要随着时间的推移与模型一起发展。
使用自然语言与 Python 函数返回值交互很有趣。这样做的好处是不必紧密耦合 API，缺点是 LLM 与工具处于试错模式。
很明显，代理说明（提示）需要专门针对所需的自动化类型。这是很自然的，如果我们雇用一个人来执行调度任务，他们将需要指令。