我处理了 5 亿 GPT tokens 后：LangChain、RAG 等都没什么用

本文最初发布于 KEN KANTZER 的个人博客。

在过去的六个月里，我的创业公司 Truss（gettruss.io）发布了多项倚重 LLM 的功能，而我在 Hacker News 上读到的关于 LLM 的故事现在已经和我的实际情况脱节了，所以我想在处理过 5 亿多（我估计）tokens 之后，分享一些更“令人惊讶”的经验教训。

本文要点：

• 我们正在使用 OpenAI 模型，如果你想知道我对其他模型的看法，请阅读底部的问答部分。

• 在我们的用例中，GPT-4 占 85%，GPT-3.5 占 15%。

• 我们专门处理文本，因此不涉及 GPT-4-vision、Sora、whisper 等。

• 我们有一个 B2B 用例——重点是汇总 / 分析 - 提取，你的情况可能有所不同。

• 5 亿 tokens 其实并不像想象的那多，也就大概 75 万页文本，要正确看待。

我们发现，不要在提示中给出确切的列表或指令——如果这些东西已经是常识的话，这样可以获得更好的结果。GPT 并不愚蠢，你提供的细节过多，反而会让它混乱。

这和编写代码不一样，代码必须明确。

下面是我们遇到的一个例子。

我们的一部分管道读取了一些文本块，并要求 GPT 根据它们与美国 50 个州或联邦政府的相关性进行归类。这不是什么很难的任务——或许用 string/regex 就可以搞定，但会有许多奇怪的边缘情况，花费的时间会更长。因此，我们首先做了（大致）这样的尝试：

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% 以上的情况都可以），但如果需要深入挖掘的话经常会失败。

经过研究，我们注意到字段 name 始终返回州的全名——即使我们没有明确要求它这样做。因此，我们改为对 name 做简单的字符串搜索来找出相应的州。从那以后，它就工作得很好了。

我认为，更好的方法应该是：

就是这么不可思议！你的提示模糊一点，GPT 概括的反而更好，反馈的质量反而更高——这是高阶委托 / 思维的典型标志。

（注 1：你可能会想 GPT 从根本上讲是一个随机模型，但它面对 M 开头的州失败次数最多。）

（注 2：当我们要求 GPT 从列表中选择一个 ID 时，如果我们以格式化的 JSON 发送，每个州一行，那么它就不会那么困惑了。我认为，\n 是一个比逗号更强大的分隔符。）

Langchain 是过早抽象的一个典型例子。

我们一开始以为必须得用它，因为网上是这么说的。而实际上，在 tokens 数量达到成百上千万、生产环境具备大概 3～4 个完全不同的 LLM 特性之后，我们的 openai_service 文件中仍然只有一个 40 行的函数：

def extract_json(prompt, variable_length_input, number_retries)

我们唯一使用的 API 是 chat。我们总是提取 JSON。我们不需要 JSON mode、函数调用和助手（虽然我们都做了），我们甚至没有使用系统提示（或许我们应该）。当 gpt-4-turbo 发布的时候，我们只更新了代码库中的一个字符串。

这就是功能强大的通用模型的美妙之处——少即是多。

在这个函数的 40 行代码中，大部分代码都是用来处理普通的 500 错误或套接字关闭错误（尽管 OpenAI API 变得越来越好，但考虑到它们的负载，出现这样的问题也并不奇怪）。

我们内置了一些自动截断代码，因为我们不必担心上下文长度限制。我们有自己的 tokens 长度估计器，如下所示：

if s.length > model_context_size * 3  # truncate it!end

在一些极端情况下，如句号或数字过多时，上述代码会不起作用。因此，我们还有下面这个特有的 try/catch 重试逻辑：

if response_error_code == "context_length_exceeded"   s.truncate(model_context_size * 3 / 1.3)

我们使用这种方法取得了不错的效果，而且也有足够的灵活性来满足我们的需求。

我们可能认为这就是一个噱头，但用户对于这个特性的反响很是积极。

“Return an empty output if you don’t find anything（如果没有找到任何内容，则返回空）”——这可能是我们遇到的最容易导致 GPT 出错的提示语。

GPT 经常会产生幻觉，提供不那么真实的答案，而不是什么都不返回。但这样的问题会导致它缺乏信心，什么都不返回的次数会比正常情况下多。

我们大部分提示都是类似下面这样：

有一段时间，我们有一个 Bug，就是 [文本块] 可以为空。GPT 会出现糟糕的幻觉。顺便说一下，GPT 喜欢幻想面包店，下面这些都很棒：

• Sunshine Bakery

• Golden Grain Bakery

• Bliss Bakery

我们的解决方案是修复这个 Bug，如果没有文本就不发送提示。但难点在于，通过编程判断“它是空”比较困难，其实这时需要 GPT 参与进来了。

很少有人知道：GPT-4 允许的最大输入窗口为 128K，而输出窗口仍然只有 4K。显然，“上下文窗口”一词是有迷惑性的。但问题的糟糕之处在于，我们经常要求 GPT 返回一个 JSON 对象的列表。想象一下，一个 JSON 任务的数组列表，每个任务都有一个名称和标签。

GPT 实在没法返回 10 项以上。硬要让它返回 15 项的话，或许只有 15% 的情况下可以做到。

一开始，我们以为这是因为 4K 大小的上下文窗口限制，但我们发现，10 项的时候只有 700～800 个 tokens，GPT 就停下了。

现在，你当然可以把输出变成输入。你给它一个提示，要求它返回一个任务，然后把提示和任务一起提供给它，再要求下一个任务，以此类推。但现在，你在和 GPT 玩电话游戏，并且必须处理类似 Langchain 这样的事情。

我累了，我真得累了。每次我想到一个杀手级的 RAG / embeddings 用例时，我都会狼狈不堪。

我认为，数据库 /RAG 事实上是为搜索而存在的，仅限于搜索，而且是像谷歌或必应那样的真正的搜索。下面是一些原因：

1. 缺少相关性界限。这里有一些解决方案，比如你可以创建自己的相关性界限启发式，但那并不可靠。在我看来，这会扼杀 RAG——总是会检索出不相关的结果，或者过于保守，错过重要的结果。

2. 为什么要把向量存入一个专有数据库里而远离其他数据呢？除非你的规模达到了谷歌 / 必应的水平，否则是不值得丢失上下文的。

3. 除非你做的是一个非常开放的搜索，比如整个互联网——用户通常不喜欢语义搜索，因为它会返回一些不相关的东西。对于大多数商业应用中的搜索，用户都是领域专家——他们不需要你去猜测他们的意思，他们会直接告诉你！

在我看来（没测试过），对于大多数的搜索场景，LLM 更好的用法是使用正常的提示补全将用户的搜索转换为面搜索，甚至是更复杂的查询（甚至是 SQL）。但这根本不是 RAG。

从根本上讲，我们的用例都是“这里有一个文本块，从中提取一些东西。”

一般来说，如果你让 GPT 给出一段文本中提到的公司名，它不会随机给出一个公司（除非文本中没提及任何公司——这是零假设问题！）。

如果你是一名工程师，那你肯定已经注意到了：GPT 并没有真正地生成幻觉代码，它不会创建变量，或者在重写你发送给它的代码块过程中随机引入错别字。

当你要求它给你一些东西时，它确实会产生存在标准库函数的幻觉，但我还是把那看作零假设。它不知道怎么说“我不知道”。

但如果你的用例完全是这样的：“这是全部的上下文信息，分析 / 总结 / 提取”，那么它会非常可靠。最近发布的很多产品都强调了这个严谨的用例。

因此总的来说，输入的数据好，GPT 就会给出好的响应。

对于一些问题，我在下面直接做了回答。

A：不。用这种转换器 + 互联网数据 +$XB 基础设施的方法是不行的。

A：它百分之百有用。现在仍然是互联网的早期阶段。

A：不。从根本上讲，它降低了人们进入 ML/AI 领域的门槛，而之前这是谷歌才有的能力。

A：实际上，我们并没有做任何严谨的 A/B 测试，但我在日常编码过程中测试过，感觉它们还差得比较远。主要体现在一些比较微妙的事情上，比如感知你的意图。

A：不需要这么做。关于 The Bitter Lesson，我想过很多，模型性能的总体改进会远超小幅优化。如果真是这样，你所需要担心的就只有 GPT-5 何时问世，其他的都不重要。OpenAI 在此期间发布的其他所有东西（不包括 Sora 等，那是完全不同的东西）基本上都是干扰。

A：和其他人一样，我一直在试图从 OpenAI 那里寻找相关的蛛丝马迹。遗憾的是，我认为我们接下来只会看到渐进式的改进。我对“GPT-5 会改变一切”不抱多少希望。

这其中的根本原因是经济方面的。我之前以为，从 GPT-3 到 GPT-3.5 可能是模型通过训练获得超线性改进：训练难度提高 2 倍，而性能提升 2.2 倍。但显然，情况并非如此。我们看到的是对数关系。事实上，为实现增量改进，token 速度是呈指数级下降而单 token 成本是呈指数级增长的。

如果是这样的话，我们就处于某种帕累托最优曲线上，而 GPT-4 可能就是最优的：尽管与 GPT-3.5 相比，我愿意为 GPT-4 支付 20 倍的价格。但老实说，从 GPT-4 到 GPT-5，我不认为我会为每个 token，而不是为 GPT-4 所使用的任务集，支付 20 倍的价格。

GPT-5 可能会打破这一局面。或者，只是 iPhone 5 与 iPhone 4 的差别。我并不会为此感到失落！

原文链接：

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

声明：本文为 InfoQ 翻译整理，未经许可禁止转载。