2023 年，在 ChatGPT 之后，我们看到了对生成式 AI 的兴趣爆发。所有公司——从初创公司到企业——都在（并且仍然在）试图弄清楚他们的 GenAI 战略。
“我们如何将 GenAI 融入我们的产品？我们应该遵循哪些参考架构？哪些模型最适合我们的用例？我们应该使用什么技术栈？我们如何测试我们的 LLM 应用程序？”
这些都是公司正在自问的问题。在如此不确定的时期，每个人也想知道其他人在做什么。已经有一些尝试来阐明这一点，但凭借 LangChain 在生态系统中的独特地位，我们觉得我们可以真正地揭示团队实际是如何使用 LLM 进行构建的。
为了做到这一点，我们转向 LangSmith 中的匿名元数据。LangSmith 是我们的云平台，旨在让从原型到生产的过渡变得容易。它提供跟踪、回归测试和评估等功能。虽然仍处于私有 Beta 阶段，但我们每天都在让人们解除等待列表，所以请在此注册，如果您对企业访问或支持感兴趣，请联系我们。
通过这个，我们可以回答关于人们正在构建什么、他们如何构建这些东西以及他们如何测试这些应用程序的问题。所有统计数据均来自 2023-07-02 至 2023-12-11。
人们正在构建什么？
在这里，我们来看看人们正在构建的一些常见的东西。
尽管 LangSmith 与 LangChain 无缝集成，但它也很容易在 LangChain 生态系统之外使用。我们看到 LangSmith 中大约 15% 的使用来自不使用 LangChain 的用户。我们为使上述所有组件的 入门体验 无论您是否使用 LangChain 都能同样出色地工作 投入了大量工作。
检索已成为将您的数据与 LLM 结合使用的主要方式。LangChain 提供了与 60 多个向量数据库（索引非结构化数据的最常见方式）的集成。LangChain 还提供了许多 高级检索策略。我们看到 42% 的复杂查询涉及检索——这既说明了检索的重要性，也说明了 LangChain 使检索变得多么容易。
最后，我们看到大约 17% 的复杂查询是代理的一部分。代理涉及让 LLM 决定要采取哪些步骤，这使您的系统能够更好地处理复杂查询或边缘情况。但是，它们仍然不是非常可靠或高性能，这可能就是我们没有看到更多代理的原因。
LCEL 使用情况
过去几个月 LangChain 的重大新增功能之一是 LangChain 表达式语言（简称 LCEL）。这是一种将组件组合在一起的简单方法，使其非常适合创建复杂、自定义的链。现在仍处于整个 GenAI 旅程的早期阶段，每个人都在试图弄清楚如何确切地使 LLM 为他们工作。这涉及大量的实验和定制。LCEL 使这一切变得容易——并且我们看到随着我们添加更多功能和改进文档，其使用量在过去几个月中迅速增加。
最常用的 LLM 提供商
这一切中的新技术是 LLM。那么人们正在使用哪些 LLM 提供商呢？
毫不奇怪，我们看到 OpenAI 位居榜首，AzureOpenAI 紧随其后。OpenAI 已成为 2023 年领先的 LLM 提供商，而 Azure（具有更多企业保证）也很好地抓住了这一势头。
提供专有模型的其他托管服务包括 Anthropic（第 3 位）、Vertex AI（第 4 位）和 Amazon Bedrock（第 8 位）。
在开源模型方面，我们看到 Hugging Face（第 4 位）、Fireworks AI（第 6 位）和 Ollama（第 7 位）成为用户与这些模型交互的主要方式。
请注意，这些排名是基于使用过给定提供商的用户数量。
最常用的 OSS 模型提供商
最近，开源模型受到了很多关注，越来越多的提供商竞相以越来越低的成本托管它们。那么开发人员究竟是如何访问这些开源模型的呢？
我们看到人们主要在本地运行它们，例如 Hugging Face、LlamaCpp、Ollama 和 GPT4All 等选项排名很高。
在提供 OSS 模型 API 访问的提供商中，Fireworks AI 领先，其次是 Replicate、Together 和 Anyscale。
请注意，这些排名是基于使用过给定提供商的用户数量。
最常用的向量数据库
如前所述，检索是 LLM 应用程序的重要组成部分。向量数据库正在成为检索相关上下文的主要方式。在 LangChain 中，我们有 60 多个向量数据库集成——人们最常使用哪些？
我们看到本地向量数据库是最常用的，其中 Chroma、FAISS、Qdrant 和 DocArray 都排在前 5 名。这些排名是基于使用过给定向量数据库的用户数量，因此如果以这种方式计算，本地、免费的向量数据库是最常用的，这是有道理的。
在托管产品中，Pinecone 领先，是前 5 名中唯一的托管向量数据库。Weaviate 紧随其后，表明向量原生数据库目前比添加向量功能的数据库更常用。
在添加了向量功能的数据库中，我们看到 Postgres (PGVector)、Supabase、Neo4j、Redis、Azure Search 和 Astra DB 领先。
请注意，这些排名是基于使用过给定提供商的用户数量。
最常用的嵌入
为了使用向量数据库，您需要计算文本片段的嵌入。那么开发人员是如何做到这一点的呢？
与 LLM 类似，OpenAI 占据主导地位——但之后我们看到了更多的多样性。开源提供商更常用，其中 Hugging Face 位居第二，GPT4All 和 Ollama 也位居前 8 名。在托管方面，我们看到 Vertex AI 实际上击败了 AzureOpenAI，而 Cohere 和 Amazon Bedrock 也紧随其后。
顶级高级检索策略
仅仅在嵌入之间进行余弦相似度计算，在检索方面只能走这么远。我们看到很多人依赖于 高级检索策略——我们在 LangChain 中实施并记录了其中很多策略。
即便如此——我们看到的最常见的检索策略不是内置的，而是自定义的。这说明了
- 在 LangChain 中轻松实现自定义检索策略
- 为了获得最佳性能，需要实施自定义逻辑
在那之后，我们看到了更多熟悉的名字出现
- 自查询 - 从用户的问题中提取元数据过滤器
- 混合搜索 - 主要通过提供商特定的集成，如 Supabase 和 Pinecone
- 上下文压缩 - 这是对基本检索结果的后处理
- 多查询 - 将单个查询转换为多个查询，然后检索所有查询的结果
- 时间加权向量数据库 - 更多地偏向于最近的文档
人们如何进行测试？
评估和测试已成为开发人员在构建 LLM 应用程序时遇到的最大痛点之一，而 LangSmith 已成为 进行此操作的最佳方法之一。
我们看到大多数用户都能够制定一些指标来评估他们的 LLM 应用程序——83% 的测试运行都有某种形式的反馈与之关联。在有反馈的运行中，平均有 2.3 种不同类型的反馈，这表明开发人员在找到一个完全依赖的单一指标方面存在困难，而是使用多种不同的指标进行评估。
在记录的反馈中，大多数反馈 使用 LLM 来评估输出。虽然有些人对此表示担忧和犹豫，但我们看好这种方法，并看到在实践中它已成为主要的测试方式。另一个值得注意的数据点是，近 40% 的评估器是 自定义评估器。这与我们观察到的评估通常真正特定于正在开发的应用程序这一事实相符，并且没有一种通用的评估器可以依赖。
人们正在测试什么？
我们可以看到，大多数人仍然主要关注其应用程序的正确性（而不是毒性、提示泄露或其他护栏）。我们还可以从精确匹配作为评估技术的低使用率中看出，判断正确性通常非常复杂（您不能只是完全比较输出）！
结论
随着 LLM 应用程序开发的第一个真正年份接近尾声，我们从许多团队那里听到他们希望弥合从原型到生产的差距。希望分享这些使用统计数据有助于阐明人们正在构建什么、他们如何构建这些东西以及他们如何测试这些东西。
LangSmith 正在成为团队将其应用程序从原型推向生产的主要方式——无论他们是否使用 LangChain。如果您对企业访问或支持感兴趣，请联系我们或在此注册。