ChatGPT和其他OpenAI模型目前正在被炒作。但它们并不是唯一可用的解决方案。或者说它们是吗？让我们今天尝试一下，在没有代码的情况下，只用一般的概念、痛苦和折磨来弄清楚它。
想象一下，你需要创建一个聊天机器人，它可以根据你自己的数据来回答用户的问题：网上商店的产品、支持服务的知识库、营销文章等。或者在我的例子中，一个咖啡馆和协同工作空间的列表。
直到最近，这种对话都是在*"你对这个感兴趣吗？- 点击这里。对其他东西感兴趣吗？- 点击那里。什么都不明白？- 请等待接线员*"。不是很友好，但有时也很容易预测和理解，只是创建这样一个复杂的逻辑需要很长的时间。
好吧，让我们增加一些友好性，创建一个 "自然语言界面"，如"告诉我在伦敦的10家有插座的咖啡馆，离我很近"（如果营销人员是可信的，人们会写更疯狂的东西，只是为了找到他们正在寻找的东西）。
第一批像这样的 "人类语言识别器 "之一是亚马逊Lex服务（以及谷歌Dialogflow和其他十几个）。
亚马逊Lex V2是一项AWS服务，用于构建使用语音和文本的应用程序的对话界面。亚马逊Lex V2提供了自然语言理解（NLU）和自动语音识别（ASR）的深度功能和灵活性，因此您可以通过栩栩如生的对话式互动构建高度吸引人的用户体验，并创建新的产品类别。
亚马逊Lex V2使任何开发人员都能快速建立对话式机器人。有了Amazon Lex V2，不需要深度学习的专业知识--创建一个机器人，您在Amazon Lex V2控制台中指定基本的对话流程。亚马逊Lex V2管理对话，并动态地调整对话中的反应。使用该控制台，你可以建立、测试和发布你的文本或语音聊天机器人。然后你可以将对话界面添加到移动设备、网络应用和聊天平台（例如Facebook Messenger）上的机器人。
听起来不错：它可以从纯文本中提取实体，并传递给数据API。
对于我上面的例子，我必须写一个语词*"给我看看{count}**{**type}与{sockets}在{region}附近*的实体 "并描述这些实体。之后，从原始短语中获得JSON{count: 10, type: cafe, sockets: many, region: London} 。
但是问题来了，对于一个类似的短语*"给我10个里加的协同工作*"，需要一个完全不同的话语，而对于最简单的查询*"附近的5个工作场所*"，需要第三个话语。🤷♂️ 一般来说，我在说了几百个愚蠢的词的排列组合后就停止了。运行所有的测试大约花了一个小时。
另一个痛苦是对话；例如，寻找工作场所的人的第二个请求可能是*"咖啡馆呢？*"。在Lex中，上下文可以通过三种方式传递，但次数有限，而且只能通过代码（Amazon Lambda函数）。
Lex还有另一种使用方式：在数十万个问题和答案的数据集上进行训练，并进一步自动回复。可能适用于有类似查询的呼叫中心。
好吧，让我们继续讨论ChatGPT和传闻中的功能
揭穿神话：通过API提供的模型比聊天网络界面 "更笨"，因为它们没有内存或上下文🤦♂️
因此，要使用产品目录，你需要在每个请求中传输整个目录，这甚至不适合最昂贵的gpt-4-32k模型的32k令牌限制。而且，每条信息都需要传输所有以前的请求和响应，以保持上下文。
这就是大约99.9(9)%的典型机器人的工作方式，它们从第10个响应开始向用户收费（例如）。帷幕落下。
一般来说，实现这一想法的第二个选项是对源文本、文章或产品目录进行标记化和矢量化；对用户查询进行标记化和矢量化，并根据余弦相似度找到几个最接近的合适矢量。
简而言之，这就是语义搜索的工作方式，而且它不需要聊天模型。但是，为了对话和回应的 "友好性"，可以使用聊天模型，并且可以将找到的向量及其相应的原文与查询一起传送。
所有的操作都可以通过API在你自己的模型、OpenAI模型（如text-embedding-ada-002）以及任何公开可用的模型上进行，如NLP云。矢量可以存储在CSV文件中，但最好使用专门的矢量数据库，如Qdrant。
现在，这种方法已经成为事实上的标准，大多数ChatGPT的搜索插件都是基于这种方法。
它有几个优点：
- 矢量化的成本低（只在源数据被上传/修改时进行）和存储，特别是在本地数据库中
- 有可能通过将整个对话与每个请求一起带到聊天模型中来维持上下文。
也有一些缺点：
- 源数据必须是基于文本的，或者更准确地说，是描述性的（我的咖啡馆目录由JSON格式的枚举参数构成，但并不奏效）。
- 必须有大量的数据
已经出现了一些服务，它们简化了从数据准备到为你的网站获得聊天代码的整个堆栈的实施。例如，Databerry和Spellbook。而且也有很好的替代模式，如Vicuna。
经过矢量实验，我改用第三种方案--用聊天模型将人类请求翻译成JSON
事实证明，这是实现我最初想法的最简单、最便宜、最快速的方法😎。
该模型附有指令，与用户的请求一起传送。
Convert the question below to JSON data.
Mostly questions are related to cafes and coworkings with different amenities.
Use only following parameters.
Skip unknown parameters and parameters that not in question.
Just output JSON data without explanation, notes or error messages!
Parameters
"""
- count: integer from 0 to 5
- type: one of "Cafe", "Coworking" and "Anticafe"
- region: any city
- sockets: one of "None", "Few" and "Many"
- noise: one of "Quiet", "Medium" and "Noisy"
- size: one of "Small", "Average" and "Big"
- busyness: one of "Low", "Average" and "High"
- view: one of "Street", "Roofs" and "Garden"
- cuisine: one of "Coffee & snacks" and "Full"
- roundclock: one of true and false
进入全屏模式 退出全屏模式
在大多数情况下，会返回一个完全正常的JSON响应，如{count: 5, type: cafe, sockets: many, region: London} ，它可以被传递到微服务API。
但如果一个文本生成模型总是以同样的方式响应（即使是用temperature=0 冻结），它就不是一个文本生成模型。大约有10%的时间，它 "被卡住"，添加了不存在的参数或忘记关闭JSON，而类似的重复请求被正常处理。
打击这种情况是没有意义的，但你可以通过验证响应与JSON模式来删除不存在的参数或无效的值，还可以建议用户再次询问机器人。
顺便说一下，最新的gpt-4模型被证明是 "更聪明 "的，更可预测的，并且不添加随机参数，但它的成本是6倍。我们正在等待gpt-4-turbo。
你可以在这里询问产生的机器人@WorkplacesDigitalBot，它的预算是10美元/月，直到它开始自己挣钱，而且没有上下文保存。
