一起来研究langchain和langchain-chatchat

看langchain文档里的一段示例代码，演示了怎么把提示 + 模型 + 输出解析器链接在一起。不知道大家有没有疑问官方说类似于unix管道操作符，但是python本身不是默认支持管道操作符的，那它是怎么实现的呢运算符重载是通过定义特定的魔术方法（特殊方法）来实现的。__add____sub____mul____or____or__方法的定义非常简单，接受一个参数，表示运算符右侧的对象。通常，__or__方法会返回一个新对象，代表了两个对象通过运算符结合的结果。

前一篇文章中，我们一起写了一个agent，为了简化代码是直接传递sql的，这一篇文章我们将通过大模型根据我们的自然语言生成sql，然后再通过agent查询数据并交给大模型思考得出结果。通过本文的示例，我们展示了如何使用 LangChain 和 SQLAlchemy 创建一个自定义的 SQL 查询 Agent。生产的步骤主要就是：扫描数据库结构 -> 生成 SQL 查询-> 执行 SQL 查询。大家可以使用自己喜欢的大模型来测试和练习。

之前我们一块学习了如何使用LangChain库使用大模型与SQL数据库进行交互文章末尾说了要写一个自定义的 agent 把我们的代码包进去，今天我们一块来尝试写一个自定义agent# 创建数据库会话# 定义执行SQL查询的工具函数try:# 定义LangChain的工具# 初始化LangChain的LLM# 创建自定义Agentllm=llm,

默认使用 Chroma 作为向量存储后端，而不是 FAISS。Chroma 和 FAISS 都是用于相似性搜索的向量数据库，但它们各自有一些特点和优点。我们一块来了解一下。

使用。

看Langchain源码的时候，发现Langchain有2个文件夹查了一下，他们都用来做向量索引，那么我们一起来研究下他们的区别是什么。

langchain发布了v0.2版本，LangChain v0.2 相比 v0.1 带来了许多显著的增强和改进，反映了在稳定性和功能性方面的巨大进步。总体而言，LangChain v0.2 提供了更好的稳定性、更完善的文档和增强的功能，以满足其开发者社区日益增长的需求。

langchain的Runnable接口是用于定义一个可以运行的组件或单元的抽象接口。这种接口通常用于将各种处理逻辑模块化，使其能够在一个链条中串联运行。langchain作为一个库，旨在帮助构建和管理语言模型的链条处理，因此Runnable接口是其核心组成部分之一。Runnable接口允许你定义一个可运行的对象，该对象可以是任何执行某种操作的逻辑单元。这个接口的主要目的是标准化这些逻辑单元，使它们能够在更大的系统中无缝协作。"""运行该组件的主要方法"""pass"""配置组件参数"""

看下面这段例子# 数据向量化# 向量化检索# 结果梳理。

之前的代码里有下面这句话，可能有看不明白的读者。今天一起来看下这句话。这句话的主要目的是将每个Document对象的文本内容转换为向量，并将所有这些向量组成一个新的列表vectors，方便后续的向量存储和检索操作。它不会修改原来的Document对象，而是生成一个新的向量列表。

前几篇文章中，我们在代码示例里看见Document的组成部分里有metadata。在 LangChain 的向量存储和检索过程中，metadata可以在多个方面发挥重要作用。虽然在简单的相似性搜索中，主要是通过文本内容的向量进行匹配，但元数据在多个方面可以增强搜索和后处理的效果。元数据在 LangChain 的向量存储和检索过程中具有重要作用，能够显著提高搜索的准确性和相关性，提供更丰富的搜索结果展示，并支持多种检索模式。通过合理利用元数据，可以构建更智能、更高效的搜索和推荐系统。

在 LangChain 中，使用简单字符串列表（如texts列表）和使用Document类表示文本有一些关键区别。主要区别在于数据的结构化程度和附加信息的存储能力。选择使用简单字符串列表还是Document类，主要取决于具体的应用需求。如果仅需处理简单的文本数据，可以选择字符串列表；如果需要更丰富的上下文信息和更复杂的操作，Document类会是更合适的选择。

在 LangChain 框架中，Document类是用于表示文本文档的基本数据结构。这个类通常用于存储文本数据及其元数据，为后续的处理、分析、索引和检索提供统一的接口。

LangChain 是一个用于构建和使用大语言模型（LLMs）的框架，它为构建自然语言处理应用程序提供了多种工具和功能。其中，向量存储（Vector Store）是 LangChain 的一个重要组件，用于存储和检索文本的向量表示。向量存储的基本思想是将文本数据转换为向量（通常是高维数值数组），然后将这些向量存储在数据库或索引中，以便后续快速检索和相似性搜索。

在大模型交互的时候，我们有时需要大模型借助已有的数据来作答，通常业务数据会存储在数据库里，需要大模型具备生成正确sql并查询数据库的能力。因此我们一起来练习如何使用LangChain库使用大模型（如GPT-4）与SQL数据库进行交互。以上的例子，大家可以一起练习一下，当然今天的例子应该是业务使用中的一环，并不是所有的问答都需要查询数据库。后面我们会看如何自定义一个agent 然后把sql的这部分包装进去。

一起来写一写练习下prompt的用法。prompt的组织方法并没有特定的规范，用来标注用户还是ai，还是历史记录、已知信息的前缀也不是固定的。只要格式明确就可以了。大模型自己能识别。

前一篇文章里，如果模型替换了，就得更改代码，很麻烦，那有没有更简单的方法呢？通过这种方式，我们可以使用和AutoModel更加简洁和通用地加载模型，适应不同的模型配置，而无需修改代码。

langchain的手册里只有使用在线openai接口这一个例子，实际运用中我们大部分还是要用本地的大模型的。所以我们一起尝试写一写，练一练我们以 GPT-2 为例，定义一个调用本地 GPT-2 模型的# 定义 BERT 嵌入模型类# 定义 GPT-3 生成模型类以上我们用三个章节介绍了如何调用本地模型，如何使用langchain自带的管道方法，以及如何从绝对地址来调用模型。大家可以清晰的在各段代码里看到改变，可以尝试自己使用自己的方法。

前一篇文章我们讲了Langchain的 PromptTemplate 的详细使用方法，在使用 LangChain 的时，有一些常见的容易出错的地方和需要注意的事项。通过注意这些常见的注意事项和潜在的陷阱，可以更有效地使用 LangChain 的并减少出错的可能性。

上一篇文章我们讲了Prompt的概念和作用（大模型的交互工具 prompt简介与运用），以及如何在langchain里实现一个PromptTemplate。这篇文章我们详细介绍下 LangChain Prompt Template 的用法。

按我们前面一节langchain表达式 LCEL来看，，可以大概看出大模型的应用主要分三部分，prompt 提示词、model模型计算 、output_parser输出格式化。今天我们讲 prompt。在深入了解langchain这一块的源码前，我们先简单看看它的概念和简单的运用通过上述步骤，我们使用 LangChain 创建了一个 prompt template，并通过填充模板生成了一个具体的 prompt，最后将其应用于 OpenAI 的大模型生成内容。