独家 | LLM的旅程：从POC（概念验证）到生产环境（上篇）

数据派THU

于 2024-08-27 17:04:06 发布

阅读量144

点赞数

原文链接：https://mp.weixin.qq.com/s?__biz=MzI1MjQ2OTQ3Ng==&mid=2247643863&idx=1&sn=66be86ac3ca1124bc6d7de528935c126&chksm=e89ae6a6f3746f87128d78d36e2fdf77e02b6faea2a848ea0704140b9ec9defeb0f36a756be1&scene=126&sessionid=0

版权

作者：Adva Nakash Peleg

翻译：付雯欣
校对：赵茹萱


本文约3100字，建议阅读10分钟
本文将从实际项目需求出发，手把手带你了解LLM。

图：由DALL-E生成的图片

试想一下：你有一个很棒的项目想法，可以通过大语言模型（LLM）来实现，并且很快实现了一个可运行的概念验证（POC）。你为自己感到骄傲，并惊讶于你只需很少的工作就能使其发挥作用。（只需五行prompt的魔力 ☺）

但接下来呢？

你很快就会意识到，在使用LLM时，编写POC是容易的，但要做出一个真正可行的产品却需要更多艰苦的工作。

如果你认同这个情景，你可能会对这篇文章感兴趣。

LLM旅程之始

理解这个旅程的最佳方式是看看我们当前的一个LLM项目。旅程的第一部分可以分为三个步骤。

1. 寻找动机

在一个充满复杂产品的世界里，还在面对着海量信息的情况下，我们的客户常常感到迷失。有时，即使是执行基本操作也需要阅读许多文档，耗费大量时间浏览产品的UI界面，或者分析大量信息，例如日志、报告和其他原始资料。

客户通常会问：“难道我不能用自己的话说出我想要的东西，然后让系统为我完成吗？”

答案是——有了LLM——可以的！

2. 确立目标

在这个例子中，项目目标是通过客户提供的自然语言（natural language，NL）对我们的产品进行操作。

我们的项目首先学习产品的API规范文件（以标准格式声明API的文件，通常是OpenAPI），然后使用LLM将自然语言请求转换为正确的API调用。

3. 实现可运行的概念验证（POC）

在确立项目目标后，我们进入了POC阶段。

POC的目的是确保我们的想法是可行的。

我们需要构建一个基本系统，该系统接收API规范文件连同自然语言的用户请求作为输入，并执行用户的请求作为结果。

为了实现这一点，我们选择了OpenAI的GPT作为我们的LLM，并选择了LangChain作为封装LLM使用的库。

我们编写了一个引擎，该引擎接收输入数据，将其处理成逻辑分组（服务），并将其加载到LangChain库中，同时包含用户请求和一些执行指令的prompt。我们使用LangChain的链、工具和代理来实现这一点，同时结合OpenAI的功能调用特性。

你可以在这个网站上了解更多关于LangChain工具和代理的信息：https://python.langchain.com/v0.1/docs/modules/agents/

下图描述了我们POC中的主要角色：

图：POC 流程

恭喜，我们有了一个可运行的POC！现在真正的旅程开始了……

首要任务：准确性

在初期对POC的兴奋消退后，我们开始看到LLM决策和响应中的一些缺陷。

在软件行业，我们通常使用确定性算法（即，对于相同的输入，算法总是产生相同的输出）。

我的第一个建议是将你习惯的确定性期望抛到一边。是的，即使在OpenAI的温度设置为0的情况下也是如此。

目标是学习如何在这个新的非确定性世界中导航。换句话说，我们如何使其更可预测，以及如何处理不同的响应？

这里有一些小tips：

Tip1：确保你在使用正确的prompt

你需要逐步告诉LLM需要做什么。这包括描述你的输入（它的格式、含义）、预期输出（它的格式、含义）等等。有时这意味着使用比你想象的更多的提示行，或在提示中包含示例。

在下面的Few-Shots Learning示例中，你可以看到在提示中添加例子（shots）的优势。

请看以下请求：“Get the user details of the user ‘user1’, and create a new user with those details”。

这看起来很基本和直截了当，对吗？错！你不会相信LLM尝试采取的奇怪操作——包括将“those”一词放入新用户的详细信息中。相反，在提示中给LLM以下示例效果非常好：

Question: Get the details of ‘User1’ entity and create a new entity named ‘User2’ with the same details

Thought: I should first get the details of ‘User1’ using the “Get entity Details” tool. then I should use the “entity writer” tool to create a new entity named ‘User2’ with the same details.

Tip2：给你的LLM配备工具

有时LLM不知道如何自行执行正确的操作。在这种情况下，你可以为LLM配备一套工具，当LLM不确定该怎么做时可以使用这些工具。这可以通过LangChain工具或OpenAI的功能调用轻松实现。

以下是一些不同工具的示例：

一个用于计算日期的日期工具。你可以问它：“给我所有昨天的日志。”由于LLM可能难以理解“昨天”具体指的是哪一天，日期工具可以帮助它将“昨天”转换为可用的时间戳。
一个可以帮助LLM向用户获取澄清信息的用户/人类工具。你可以问它：“创建一个新用户。”由于LLM可能需要额外的信息，比如用户名，它可以使用用户工具询问用户所需的用户名。

Tip3：限制LLM的创造力

另一个建议是限制LLM的创造力，让LLM在不确定时询问澄清信息，而不是妄自猜测。

例如，当你要求“创建一个名为‘user1’的新用户”时，API的一个参数是密码。

LLM可能会尝试使用生成的密码Password123来创建用户。这可能不是你想要的结果。你可以指示LLM在这种情况下询问澄清信息，而不是自行猜测。