【LLM】宣布LangChainJS支持多种JS环境
TLDR：我们宣布支持在浏览器、Cloudflare Workers、Vercel/Next.js、Deno、Supadase Edge Functions中运行LangChain.js，同时支持Node.js ESM和CJS。请参阅安装/升级文档和中断更改列表。
上下文
最初，我们将LangChain.js设计为在Node.js中运行，Node.js是长期存在的服务器端JavaScript运行时。早在二月份（时间过得很快！），我们就开始从社区收集关于我们应该支持哪些其他JS运行时的反馈，并从那时起收到了大量关于让LangChain在浏览器、Deno、Cloudflare Workers、Vercel/Next.JS、Vite、Supadase Edge Functions等上运行的请求。
更改以启用多个环境
从那以后，我们一直在与社区贡献者一起，为尽可能多的JS环境提供支持，这一过程中有一些亮点
【LLM】LangChain 支持 Supabase
Suabase本周将举办一场人工智能黑客马拉松。在LangChain，我们是Suabase和黑客马拉松的忠实粉丝，所以我们认为这将是一个完美的时机来强调您可以同时使用LangChain和Suabase的多种方式。
我们之所以如此喜欢Supadase，是因为它在多种不同方面都很有用。构建有趣的人工智能应用程序的一个重要部分是将GPT-3等模型与您的个人数据连接起来。因此，通过这种方式，Suabase支持的不同类型的数据库非常有用。但是，在您构建了应用程序之后，您还需要一种与世界共享应用程序的方式——Suabase也可以提供帮助。
Suabase矢量存储
人们一直在构建的人工智能应用程序的主要类型之一是与文档数据“聊天”的方式。基本上是ChatGPT，但它知道特定数据的信息，无论是你的个人写作还是一个深奥的网站。有关这种类型的应用程序的深入教程，请参阅此博客。这个应用程序的很大一部分是将文档的嵌入存储在向量库中。苏巴斯可以做到！有关如何执行此操作的演练，请参阅此处的文档。
【LLM】LangChain自定义代理
我们听到的最常见的要求之一是为创建自定义代理提供更好的功能和文档。这一直有点棘手，因为在我们看来，实际上还不清楚“代理”到底是什么，因此它们的“正确”抽象可能是什么。最近，我们感觉到一些抽象开始融合在一起，所以我们在Python和TypeScript模块上做了一个大的努力，以更好地执行和记录这些抽象。请参阅下面的技术文档链接，然后是我们介绍的抽象和未来方向的描述。
【LangChain】LangChain Retrieval
TL；DR：我们正在调整我们的抽象，以便在LangChain中使用除LangChain VectorDB对象之外的其他检索方法。这样做的目的是（1）允许在LangChain中更容易地使用在其他地方构建的检索器，（2）鼓励对替代检索方法（如混合搜索）进行更多实验。这是向后兼容的，所以所有现有的链都应该像以前一样继续工作。然而，我们建议尽快从VectorDB链更新到新的Retrieval链，因为这些链将是未来最受支持的链。
【LLM】LangChain+Zapier自然语言动作（NLA）
我们非常高兴能与Zapier合作，并将其新的Zapier-NLA API集成到LangChain中，您现在可以将其用于您的代理和链。通过这种集成，您可以通过自然语言API接口访问Zapier平台上的5k+应用程序和20k+操作。这是非常强大的，并为您的LangChain代理提供了看似无限的可能性。向Mike Knoop和Zapier团队的其他成员大声疾呼，感谢他们帮助实现了这一集成。您可以在上面共享的链接中请求访问。你将建造什么？
Zapier NLA
NLA支持Gmail、Salesforce、Trello、Slack、Asana、HubSpot、Google Sheets、Microsoft Teams等应用程序，以及成千上万的应用程序：https://zapier.com/apps
Zapier NLA处理所有底层API身份验证和自然语言翻译->底层API调用->返回LLM的简化输出。关键思想是通过类似oauth的设置窗口公开一组操作，然后可以通过REST API查询和执行这些操作。
NLA提供API密钥和OAuth，用于对NLA API请求进行签名。
【LangChain】语言模型评估
评估语言模型，以及在语言模型之上构建的扩展应用程序，是很困难的。随着最近的模型发布（OpenAI、Anthropic、Google），评估正成为一个越来越大的问题。人们开始尝试解决这个问题，OpenAI发布了OpenAI/evals，专注于评估OpenAI模型。相应地，我们很高兴地宣布，我们对评估链和代理的方式进行了一些补充和改进。
问题
评估LangChain链和代理可能非常困难。这主要有两个原因：
#1：缺乏数据
在开始一个项目之前，你通常没有大量的数据来评估你的链/代理。这通常是因为大型语言模型（大多数链/代理的核心）是非常棒的少试和零试学习者，这意味着你几乎总是能够在没有大量示例数据集的情况下开始执行特定任务（文本到SQL、问答等）。这与传统的机器学习形成了鲜明的对比，在传统机器学习中，甚至在开始使用模型之前，都必须先收集一堆数据点。
#2：缺乏指标
大多数链/代理执行的任务没有很好的指标来评估性能。例如，最常见的用例之一是生成某种形式的文本。评估生成的文本比评估分类预测或数字预测要复杂得多。
【LLM】LLMs 和 SQL
Francisco Ingham和Jon Luo是领导SQL集成变革的两名社区成员。我们真的很高兴能写这篇博客文章，让他们复习他们学到的所有技巧和窍门。我们更高兴地宣布，我们将与他们进行一个小时的网络研讨会，讨论这些知识并提出其他相关问题。本次网络研讨会将于3月22日举行-请在以下链接注册：
LangChain库有多个SQL链，甚至还有一个SQL代理，旨在使与存储在SQL中的数据的交互尽可能简单。以下是一些相关链接：
【LLM】LangChain和 Origin Web浏览器
[编者按]：这是众多客串帖子中的第二篇。我们打算重点介绍构建在LangChain之上的新型应用程序。如果您有兴趣与我们合作，请联系harrison@langchain.dev.
作者：Parth Asawa（pgasawa@）、Ayushi Batwara（Ayushi.Batwara@）、Jason Ding（jasonding@）、Arvind Rajaraman（Arvind.Rajaraman@）[@berkeley.edu]
链接到原始博客文章
问题
你的浏览器以前是这样的吗？
【LLM】LangChain提示选择器
我们听到的一个常见抱怨是，默认的提示模板并不能同样适用于所有型号。上周OpenAI发布了ChatGPT API，这一点变得尤为明显。这个新的API有一个全新的界面（需要新的抽象），因此许多用户注意到旧提示的问题不再有效。尽管我们很快添加了对该模型的支持，但许多用户注意到，适用于GPT-3的提示模板在聊天设置中效果不佳。
所有链都公开了自定义这些提示模板的方法，因此总是可以选择让用户传递更有效的提示。但我们想做得更好。具有默认提示模板的链的一个目标是提供开箱即用的“Just Works”功能。如果不同的模型期望不同类型的提示，则会出现故障。
我们的解决方案是引入PromptSelector的概念。与其为每个链定义默认的PromptTemplate，不如为每个链创建PromptSelector。如果用户未指定提示，则PromptSelector将根据传入的模型选择要使用的PromptTemplate。
有关此操作的示例，请查看以下示例：
【LLM】LangChain聊天模型
上周，OpenAI发布了一个ChatGPT端点。它在上市时有几个大的改进，最显著的是便宜了10倍，速度也快了很多。但它也附带了一个全新的API端点。我们能够快速为这个端点编写一个包装器，让用户像使用LangChain中的任何普通LLM一样使用它，但这并没有充分利用新的基于消息的API。在这篇博客文章中，我们介绍了新的API模式，以及我们如何调整LangChain以适应ChatGPT以及所有未来基于聊天的模型。
关键环节：
为什么是新的抽象概念？
所以OpenAI发布了一个新的API——有什么大不了的？为什么甚至需要新的抽象？