针对长上下文LLMs的提示注入作为RAG的替代方案？

支持
,
1

是否可以将中等大小的文档（例如，最多 100KB）通过系统提示注入到 Discourse AI Persona 机器人会话的上下文中？

用例
一个自定义 AI Persona，链接到 AWS 实例中的私有 LLM（如 Llama3-8b），其中成本按小时计算，而不是按 token 计算。也就是说，请求/响应 token 的数量无关紧要，并且服务器拥有相当大的 CUDA 算力，因此性能很好。也就是说，RAG 可能是可选的？

（替代用例：Gemini.1.5 LLM，API 调用不收费）

目标
减少管道中的活动组件，并通过避免相似性检索来提高准确性。

实验
在 Gemini 1.5 Pro 上进行非正式的 AI Persona 测试，其中将一个约 20k token 的文本文档插入到系统提示中。

image
image298×106 4.02 KB

我问了几个我知道答案只在论文中的问题。它正确地回答了所有问题。所以我想它从提示中读取了 20k token，并在每个问题中进行了解析？

在会话和上下文内容不是太大的情况下，这种方法有什么缺点吗？

非常感谢..

image
image749×1088 57.3 KB

image
image1228×732 51.3 KB

脚注 - 在会话中途从提示中删除上下文
当我删除会话中的提示注入内容并继续提问时，Gemini 继续正确回答问题，但在几个问题后，它找不到上下文并失败了。正如有些预期的那样，Gemini 1.5 可以在多个对话轮次中保持上下文，但并非无限期。

所有想法、评论和指导都将受到赞赏！

1 个赞
2

是的，我们有依赖于 LLM 允许的令牌数量的截断逻辑，我们将 Gemini 1.5 模型的阈值设置得很高（800k）。

应该可行，但每次交互的成本可能非常高。

总的来说，我发现限制上下文有助于模型保持更专注，但从长远来看（2-5 年后）……检索增强生成（RAG）可能变得毫无意义，因为我们将拥有如此多的令牌和焦点，以至于它不再重要。

3 个赞
3

尽管我对提示填充（prompt stuffing）有所疑问……我其实很喜欢检索增强生成（RAG）。

在我看来，你们在大型嵌入引擎方面所做的工作目前非常强大且有用……但也同意 RAG……可能会注定失败。

正如 Sam Altman 在最近的一次采访中所说……要警惕那些阻碍大型语言模型（LLM）发展的商业模式和项目计划！！我们会碾压你们！……或者类似的话……

所以最终……也许我们想要做的只是将我们的东西交给 LLM，而不需要很多低维（输入）然后高维（嵌入）然后低维（提示）然后高维（Transformer 推理）然后低维（输出）的预处理流程……搞定！

这是我偶然发现的一些关于 RAG 与长上下文的背景资料……还没全部听完，但似乎可能相关……（与此视频中的任何人均无关联 :slight_smile:

4

补充说明

我观看了关于 Gradient long-context LLama3 的视频。它提醒我们，上下文包括了所有正在起作用的因素：

  • 用户输入
  • LLM 输出
  • 控制令牌
  • 系统指令

……随着窗口滑动，有些东西会被遗漏……但他们提到，在上下文窗口被填满的会话中，系统提示可以得到“保护”。

此外，还存在“最大输入大小”以及模型最初训练的“序列长度”等问题，这些都可能影响结果。

下面是一个长上下文提示填充的实际示例。

总的来说，创建一支由 Discourse AI 角色组成的团队似乎是可行的，每个角色都拥有大量专业内容或代码库供查询（请记住按 token 付费时成本高昂的注意事项！）。

image
image1819×1157 308 KB

5

但这不只是 RAG 的一个（效率低下且）“静态”版本吗？

所有 RAG 与此方法不同的地方在于，它选择并包含相关内容块，而不是包含所有内容。

2 个赞
6

说得有理，确实如此…… IMO 没有简单的答案。

我猜这取决于用例。

RAG 对某些应用程序效果很好，但对于其他相当确定性的目标用例（例如，客户问答、支付、医疗等），在过去一年中，我和其他人一直在 RAG 向量搜索方面遇到准确性问题。也就是说，机器人要么会遗漏内容，要么会编造内容（在信息检索方面召回率低、精确率低），这一点已被斯坦福大学、谷歌等广泛记录。

那么问题就来了……如果可以将整个语料库提供给 LLM，为什么还要给它一大堆块呢？至少在使用上下文注入时，当 LLM 不准确时，你需要调整的东西会更少……

好吧，这对于庞大的文档/代码库不起作用……但对于中小型内容库来说，到目前为止它似乎效果很好……我正在做一个项目来正式测试这一点…… 很快会有更多信息……谢谢。

附注：——为了让事情更有趣……我在上下文注入+微调方面取得了不错的成果……并且有新兴的方法结合了 RAG 和上下文注入！……等等等等。

另请参阅：

7

ADDENDUM 2

这是对白皮书（约 20k 标记）的问答测试，通过提示注入与 RAG 进行情境化。（内容和设置尽可能相同。LLM = Gemini-1.5-Pro）。

分析：
RAG 不稳定……有时能找到答案，有时找不到。

:github_check: 提示注入成功：

image
image800×703 39.7 KB

:x: RAG 失败：

image
image834×700 39.6 KB

RAG 请求跟踪：

image
image1015×913 65.4 KB

我确实让 RAG 回答了文档开头文件上传中的问题，并且通过引导，它可能会查看中间和结尾部分……所以并非完全失败……但它是不稳定的……不稳定，或者 IMO 更难处理 : )

8

这里是测试文件，供大家参考：

文件包含以下 BME 针（haystack ‘needles’），保证是唯一的，即不会出现在互联网上该论文的外部副本中。

开头：

Proofreader: Felonius Monko

中间：

编辑注：Goldich 稳定性系列由 Maurice Goldrch 发现。虽然 Goldich 最初的矿物风化势顺序是定性的，但后来由 Michal Kowalski 和 J. Donald Rimstidt 的工作以定量方式将该系列进行了排序。感谢 NMU 的 Gomez Pyle 博士对此的澄清。

结尾：

Dang, S. et al. Cryo-EM structures of the TMEM16A calcium-activated chloride channel. Nature 552, 426429 (2017)。

Equatics-paper1-with-unique-haystack-needles-v116.txt (71.8 KB)

欢迎提出所有评论、批评和指导！接下来，我将使用更多的 LLM 和嵌入模型等进行测试。

9

脚注：

我能够使用 GPT4o（128k 上下文）重新运行上述测试，并确保使用大型令牌/块设置。但对于我的白皮书问答用例来说，它仍然非常不稳定（中间丢失、末尾丢失等）。如果有人想复制和改进，以下是我的设置。如果我们能为这个用例找到合适的设置，我将非常高兴：

|自定义AI角色||
|—|—||
|||
|启用？|是|
|优先级|是|
|允许聊天|是|
|允许提及|是|
|视觉启用|否||
|||
|名称|Rag 测试机器人 3|
|描述|测试 RAG 与长上下文提示注入|
|默认语言模型|GPT-4o-custom|
|用户| Rag_Testing_Bot_bot|
|已启用命令|Categories, Read, Summary|
|允许的组|trust_level_4||
|||
|系统提示|根据 Equatic 碳移除研究提供的上下文，尽可能全面地回答。不要编造内容。不要使用此会话外部的内容。尽可能准确、完整地根据提供的内容创建答案。|
|||
|最大上下文帖子数|50|
|温度|0.1|
|Top P|1||
|||
| ||
|上传| Equatics-paper1-with-unique-haystack-needles-v116.txt|
|||
|上传块令牌数|1024|
|上传块重叠令牌数|10|
|搜索对话块数|10|
|用于问题整合器的语言模型|GPT-4o-custom||
|||
|自定义机器人||
|||
|显示名称|GPT-4o-custom||
|||
|模型名称|gpt-4o||
|||
|托管模型的服务|OpenAI|
|托管模型的服务 URL|https://api.openai.com/v1/chat/completions|
|托管模型的服务 API 密钥|D20230943sdf_fake_Qqxo2exWa91||
|||
|分词器|OpenAITokenizer|
|提示的令牌数|30000|