声明：本文来自微信公众号 机器之心（ID:almosthuman2014)，作者：机器之心，授权站长之家转载发布。

ChatGPT 正确使用姿势。

自 ChatGPT 问世以来，OpenAI 它一直被认为是一个全球生成的大模型领导者。2023年3月，OpenAI 开发者可以通过官方宣布 API 将 ChatGPT 和 Whisper 模型集成到他们的应用程序和产品中。在 GPT-4发布的同时 OpenAI 也开放了其 API。

一年过去了，OpenAI 业内开发者如何评价大模型的使用体验？

最近，初创公司 Truss 的 CTO Ken Kantzer 一篇题为发布《Lessons after a half-billion GPT tokens》博客阐述了使用中的博客 OpenAI 的模型（85% GPT-4、15% GPT-3.5处理5亿 token 之后，总结了七个宝贵的经验。

机器之心在不改变原意的情况下对这个博客进行了编译、整理，下面是博客原文的内容：

经验1:prompt，少即是多

如果我们发现的话 prompt 中间的信息已经是常识了，所以应该 prompt 它不会帮助模型产生更好的结果。GPT 这并不愚蠢。如果你指定太多，它实际上会变得混乱。

与编码不同，编码中的一切都必须清楚。

举一个困扰我们的例子:

pipeline 读取一些文本块的一部分，并要求 GPT 将其分类为美国50个州之一。这不是一项艰巨的任务，可以使用字符串 / 正则表达式，但有足够奇怪的极端情况，所以需要更长的时间。所以我们第一第二次尝试大致如下：

Here'sablockoftext.Onefieldshouldbe"locality_id"，anditshouldbetheidofoneofthe50states，orfederal，usingthislist:

这有时会起作用(大约98%) 情况)，但失败足以让我们进一步挖掘。

在调查中，我们注意到了字段「名称」尽管我们没有明确要求它回到州的全名。

因此，我们用简单的字符串搜索名称来找到状态，然后模型运行良好。

总而言之，GPT 显然知道50个州。当 prompt 更模糊的时候，GPT 可以提高质量和泛化能力，太疯狂了 —— 这是高级思维的典型标志。

经验2:不需要 langchain

你只需要 chat API，不需要 langchain，甚至可能不需要 OpenAI 去年在其 API 其他发布的内容。

Langchain 这是过早抽象的完美例子。我们开始认为我们必须使用它。但相反，数百万 token 之后，我们可能在生产中使用了3-4种非常多样化的产品 LLM 而我们的函数 openai_service 文件中仍然只有40行函数：

defextract_json（prompt，variable_length_input，number_retries）

我们使用的唯一 API 是 chat API。我们不需要 JSON 我们甚至不使用系统，如模式、函数调用等(尽管我们做了所有这些) prompt。gpt-4-turbo 在发布时，我们更新了代码库中的字符串。

这就是强大广义模型的美 —— 少即是多。

这个函数中的40行代码大多是围绕的 OpenAI API 关闭的500s/socket 错误处理。

我们内置了一些自动截断功能，不用担心上下文的长度限制。我们有自己独有的 token 长度估计器。

ifs.length>model_context_size*3

在有大量句点或数字的极端情况下（token ratio <characters /token），这种方法会失败。因此，还有另一种独特的方法 try/catch 重试逻辑:

ifresponse_error_code=="context_length_exceeded"

我们依靠上述方法取得了很大的进展，这种方法足够灵活，可以满足我们的需求。

经验3:通过流式 API 改进延迟并向用户显示变速输入的单词是 ChatGPT 重大用户体验创新

我们曾经认为这只是一个噱头，但实际上用户是对的「变速输入字符」反应非常积极 —— 感觉就像人工智能鼠标 / 光标用户体验时刻。

经验4:GPT 不擅长产生零假设

「如果找不到任何内容，返回空输出」—— 这可能是我们遇到的最容易出错的事情 prompting 语言。在这种情况下，GPT 它不仅会经常产生幻觉而不返回任何内容，还会导致幻觉「缺乏信心」，返回空白的次数比应有的要多。

我们大多数人 prompt 以下形式：

“Here’s a block of text that’s making a statement about a company， I want you to output JSON that extracts these companies. If there’s nothing relevant， return a blank. Here’s the text: [block of text]”

我们会遇到一段时间 bug，[文本块] 可能是空的，幻觉不时出现。顺便说一句，GPT 非常喜欢幻想面包店，这里有一些很棒的面包店：

• 阳光面包店

• 金粮面包店

• 极乐面包店

幸运的是，解决方案是修复它 bug，在没有文本的情况下，根本没有发送给它 prompt。

经验5:「上下文窗口」命名不当

「上下文窗口」它只会因输入而变大，而不会因输出而变大。

鲜为人知的事实是，GPT-4的输入窗口可能有128k token，但是输出窗口只有4k！

我们经常要求 GPT 返回 JSON 对象的列表 —— 一个 json 在任务的数组列表中，每个任务都有一个名称和一个标签 GPT 超过10个项目无法返回。

我们最初认为这是因为上下文的窗口大小是4k，但我们发现10个项目可能只有700-800个 token，GPT 就会停止。

经验6:向量数据库和 RAG / 嵌入对我们普通人来说几乎没用

我认为矢量数据库 / RAG 它确实用于搜索。以下原因如下：

1. 相关性没有界限。有一些解决方案，你可以创建自己的相关性，但它们不可靠。在我看来，这是真的「杀死了 RAG」—— 你总是冒着用不相关的结果危害检索的风险；或者过于保守，错过重要的结果。

2. 为什么要将向量放入远离所有其他数据的专有数据库中？除非你处理它 google/bing 规模化工作，否则上下文将丢失绝对不值得权衡。

3. 除非您正在进行非常开放的搜索（如整个互联网），否则用户通常不喜欢返回他们没有直接输入的语义搜索。

在我看来，对于大多数搜索案例(未经验证)，LLM 更好的用法是正常完成 prompt 将用户的搜索转换为分面搜索(faceted-search)，甚至更复杂的查询。但这根本不是 RAG。

经验7:幻觉基本上不会发生

本质上，我们的每一个用例都是「这是一个从中提取一些内容的文本」。一般情况下，如果要求 GPT 提供文本中提到的公司名称，不会为您提供「随机公司」(除非文本中没有公司，即零假设问题)。

类似地，GPT 它不会真正产生幻觉代码。如果用例完整、详细，则 GPT 其实很可靠。

原文链接:

https://kenkantzer.com/lessons-after-a-half-billion-gpt-tokens/