首页 产业新闻 5亿个token之后,我们得出关于GPT的七条宝贵经验

5亿个token之后,我们得出关于GPT的七条宝贵经验

产业新闻 14

    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个州之一相关。这不是一项艰巨的任务,可以使用字符串 / 正则表达式,但有足够多奇怪的极端情况,因此需要更长的时间。所以我们的第一次尝试大致是这样的:

    这有时会起作用(约超过98% 的情况),但失败的情况足以让我们不得不进行更深入的挖掘。

    在调查时,我们注意到字段「名称」始终返回州的全名,尽管我们没有明确要求它这样做。

    因此,我们改用对名称进行简单的字符串搜索来查找状态,然后模型就一直运行良好。

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

    经验2:不需要 langchain

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

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

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

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

    该函数中的40行代码大部分都是围绕 OpenAI API 被关闭的500s/socket 的错误处理。

    我们内置了一些自动截断功能,因此不必担心上下文长度限制,我们有自己专有的 token 长度估计器。

    在存在大量句点或数字的极端情况下(token ratio <3characters /token),这种方法会失败。所以还有另一个专有的 try/catch 重试逻辑:

    我们已经依靠上述方法取得了很大进展,并且该方法足够灵活,可以满足我们的需求。

    经验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/

广告

文章目录

    标签列表