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 之后，总结出的七条宝贵教训。
Ken Kantzer
机器之心对这篇博客进行了不改变原意的编译、整理，以下是博客原文实质：
教训 1：prompt，少即是多
我们发现，如果 prompt 中的信息已经是常识，那么该 prompt 不会帮助模型产生更好的结果。GPT 并不愚蠢，如果您过度指定，它实际上会变得混乱。
这与编码不同，编码中的一切都必须是明确的。
举一个让我们感到困扰的例子：
pipeline 的一部分读取一些文本块，并要求 GPT 将其分类为与美国 50 个州之一相关。这不是一项艰巨的任务，可以应用字符串 / 正则表达式，但有足够多奇怪的极端环境，因此须要更长的时间。所以我们的第一次尝试大致是这样的：
Here's a block of text. One field should be "locality_id", and it should be the ID of one of the 50 states, or federal, using this list:
[{"locality: "Alabama", "locality_id": 1}, {"locality: "Alaska", "locality_id": 2} ... ]
这有时会起作用（约超过 98% 的环境），但失败的环境足以让我们不得不进行更深入的挖掘。
在调查时，我们注意到字段「称号」始终前往州的全名，尽管我们没有明确要求它这样做。
因此，我们改用对称号进行简单的字符串搜刮来查找状态，然后模型就一直运行良好。
总而言之，GPT 显然知道 50 个州。当 prompt 更加模糊时，GPT 的质量和泛化能力都可以提高，这太疯狂了 —— 这是高阶思维的典型标志。
教训 2：不须要 langchain
你只须要 chat API，不须要 langchain，甚至可能不须要 OpenAI 去年在其 API 中发布的任何其他实质。
Langchain 是过早抽象的完美例子。我们开始认为我们必须应用它。但相反，数百万个 token 之后，我们可能在生产中应用了 3-4 个非常多样化的 LLM 函数，而我们的 openai_service 文件中仍然只有一个 40 行的函数：
def extract_json(prompt, variable_length_input, number_retries)
我们应用的唯一 API 是 chat API。我们不须要 JSON 模式、函数调用等等（尽管我们做了所有这些），我们甚至不应用系统 prompt。gpt-4-turbo 发布时，我们更新了代码库中的一个字符串。
这就是强大的广义模型的美妙之处 —— 少即是多。
该函数中的 40 行代码大部分都是围绕 OpenAI API 被关闭的 500s/socket 的错误处理。
我们内置了一些自动截断功能，因此不必担心上下文长度限制，我们有自己专有的 token 长度估计器。
if s.length > model_context_size * 3 # truncate it! end
在存在大量句点或数字的极端环境下（token ratio < 3 characters /token），这种方法会失败。所以还有另一个专有的 try/catch 重试逻辑：
if response_error_code == "context_length_exceeded" s.truncate(model_context_size * 3 / 1.3)
我们已经依靠上述方法取得了很大进展，并且该方法足够灵活，可以满足我们的需求。
教训 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/