# 针对长上下文LLMs的提示注入作为RAG的替代方案？ **URL:** \ **Category:** Support\ **Tags:** ai, ai-bot\ **Created:** [2024年五月22日 22:47 UTC](https://meta.discourse.org/t/prompt-injection-for-long-context-llms-as-an-alternative-to-rag/309086 "2024-05-22T22:47:33Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![StevePlex](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/steveplex/32/269106_2.png) [@StevePlex](https://meta.discourse.org/u/StevePlex)\ **Post date:** [2024年五月22日 22:47 UTC](https://meta.discourse.org/t/prompt-injection-for-long-context-llms-as-an-alternative-to-rag/309086/1 "2024-05-22T22:47:33Z")
是否可以将中等大小的文档（例如，最多 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](https://global.discourse-cdn.com/meta/original/4X/3/c/4/3c4220903808d5224ac79ce66682bd474aede7c5.png) 我问了几个我知道答案只在论文中的问题。它正确地回答了所有问题。所以我想它从提示中读取了 20k token，并在每个问题中进行了解析？ 在会话和上下文内容不是太大的情况下，这种方法有什么缺点吗？ 非常感谢.. ![image](https://global.discourse-cdn.com/meta/original/4X/8/f/4/8f47384eb52bb06d2977989d8f4b4fbafec77ef5.png) * * * ![image](https://global.discourse-cdn.com/meta/original/4X/3/a/c/3acab2721ec5da7223ca5d86572227e355ec1601.png) * * * 脚注 - 在会话中途从提示中删除上下文 当我删除会话中的提示注入内容并继续提问时，Gemini 继续正确回答问题，但在几个问题后，它找不到上下文并失败了。正如有些预期的那样，Gemini 1.5 可以在多个对话轮次中保持上下文，但并非无限期。 所有想法、评论和指导都将受到赞赏！ ---
**Author:** ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)\ **Post date:** [2024年五月23日 02:58 UTC](https://meta.discourse.org/t/prompt-injection-for-long-context-llms-as-an-alternative-to-rag/309086/2 "2024-05-23T02:58:18Z")
> [@StevePlex](#): > > 通过系统提示将中等大小的文档（例如，高达 100KB）注入 Discourse AI 机器人会话的上下文是否可行？ 是的，我们有依赖于 LLM 允许的令牌数量的截断逻辑，我们将 Gemini 1.5 模型的阈值设置得很高（800k）。 应该可行，但每次交互的成本可能非常高。 总的来说，我发现限制上下文有助于模型保持更专注，但从长远来看（2-5 年后）……检索增强生成（RAG）可能变得毫无意义，因为我们将拥有如此多的令牌和焦点，以至于它不再重要。 ---
**Author:** ![StevePlex](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/steveplex/32/269106_2.png) [@StevePlex](https://meta.discourse.org/u/StevePlex)\ **Post date:** [2024年五月23日 06:29 UTC](https://meta.discourse.org/t/prompt-injection-for-long-context-llms-as-an-alternative-to-rag/309086/3 "2024-05-23T06:29:50Z")
尽管我对提示填充（prompt stuffing）有所疑问……我其实很喜欢检索增强生成（RAG）。 在我看来，你们在大型嵌入引擎方面所做的工作目前非常强大且有用……但也同意 RAG……可能会注定失败。 正如 Sam Altman 在最近的一次采访中所说……要警惕那些阻碍大型语言模型（LLM）发展的商业模式和项目计划！！我们会碾压你们！……或者类似的话…… 所以最终……也许我们想要做的只是将我们的东西交给 LLM，而不需要很多低维（输入）然后高维（嵌入）然后低维（提示）然后高维（Transformer 推理）然后低维（输出）的预处理流程……搞定！ 这是我偶然发现的一些关于 RAG 与长上下文的背景资料……还没全部听完，但似乎可能相关……（与此视频中的任何人均无关联 🙂 https://www.youtube.com/embed/Brwhbjh3boU?feature=oembed&wmode=opaque ---
**Author:** ![StevePlex](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/steveplex/32/269106_2.png) [@StevePlex](https://meta.discourse.org/u/StevePlex)\ **Post date:** [2024年五月23日 17:17 UTC](https://meta.discourse.org/t/prompt-injection-for-long-context-llms-as-an-alternative-to-rag/309086/4 "2024-05-23T17:17:49Z")
补充说明 我观看了关于 Gradient long-context LLama3 的视频。它提醒我们，上下文包括了所有正在起作用的因素： - 用户输入 - LLM 输出 - 控制令牌 - 系统指令 ……随着窗口滑动，有些东西会被遗漏……但他们提到，在上下文窗口被填满的会话中，系统提示可以得到“保护”。 此外，还存在“最大输入大小”以及模型最初训练的“序列长度”等问题，这些都可能影响结果。 下面是一个长上下文提示填充的实际示例。 总的来说，创建一支由 Discourse AI 角色组成的团队似乎是可行的，每个角色都拥有大量专业内容或代码库供查询（请记住按 token 付费时成本高昂的注意事项！）。 ![image](https://global.discourse-cdn.com/meta/original/4X/c/5/f/c5fd47717d8ab859e98ed334051597af063ca7e2.png) ---
**Author:** ![RGJ](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rgj/32/523185_2.png) [@RGJ](https://meta.discourse.org/u/RGJ)\ **Post date:** [2024年五月23日 21:19 UTC](https://meta.discourse.org/t/prompt-injection-for-long-context-llms-as-an-alternative-to-rag/309086/5 "2024-05-23T21:19:25Z")
但这不只是 RAG 的一个（效率低下且）“静态”版本吗？ 所有 RAG 与此方法不同的地方在于，它选择并包含_相关内容块_，而不是_包含所有内容_。 ---
**Author:** ![StevePlex](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/steveplex/32/269106_2.png) [@StevePlex](https://meta.discourse.org/u/StevePlex)\ **Post date:** [2024年五月24日 01:25 UTC](https://meta.discourse.org/t/prompt-injection-for-long-context-llms-as-an-alternative-to-rag/309086/6 "2024-05-24T01:25:08Z")
说得有理，确实如此…… IMO 没有简单的答案。 我猜这取决于用例。 RAG 对某些应用程序效果很好，但对于其他相当确定性的目标用例（例如，客户问答、支付、医疗等），在过去一年中，我和其他人一直在 RAG 向量搜索方面遇到准确性问题。也就是说，机器人要么会遗漏内容，要么会编造内容（在信息检索方面召回率低、精确率低），这一点已被斯坦福大学、谷歌等广泛记录。 那么问题就来了……如果可以将整个语料库提供给 LLM，为什么还要给它一大堆块呢？至少在使用上下文注入时，当 LLM 不准确时，你需要调整的东西会更少…… 好吧，这对于庞大的文档/代码库不起作用……但对于中小型内容库来说，到目前为止它似乎效果很好……我正在做一个项目来正式测试这一点…… 很快会有更多信息……谢谢。 附注：——为了让事情更有趣……我在上下文注入+微调方面取得了不错的成果……并且有新兴的方法结合了 RAG 和上下文注入！……等等等等。 另请参阅： > **[Google Search](https://www.google.com/search?q=papers%2Bon%2Bthe%2Bproblems%2Bwith%2Bllm%2Brag)** > **[Why RAG Applications Fail in Production](https://pub.towardsai.net/why-rag-applications-fail-in-production-a-technical-deep-dive-15cc976af52c)** > > It worked as a prototype; then all went down! ---
**Author:** ![StevePlex](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/steveplex/32/269106_2.png) [@StevePlex](https://meta.discourse.org/u/StevePlex)\ **Post date:** [2024年五月24日 15:59 UTC](https://meta.discourse.org/t/prompt-injection-for-long-context-llms-as-an-alternative-to-rag/309086/7 "2024-05-24T15:59:24Z")
ADDENDUM 2 这是对白皮书（约 20k 标记）的问答测试，通过 **提示注入与 RAG** 进行情境化。（内容和设置尽可能相同。LLM = Gemini-1.5-Pro）。 分析： RAG 不稳定……有时能找到答案，有时找不到。 * * * :github_check: 提示注入成功： ![image](https://global.discourse-cdn.com/meta/original/4X/3/3/1/331219bb21f759dbd75a5037001864f2452530ca.png) * * * ❌ RAG 失败： ![image](https://global.discourse-cdn.com/meta/original/4X/0/2/f/02fa55538484e0193a0ad58d7fc754de57def255.png) * * * RAG 请求跟踪： ![image](https://global.discourse-cdn.com/meta/original/4X/2/3/8/2382135ff1be85c31705c690d17766485352e86f.png) 我确实让 RAG 回答了文档开头文件上传中的问题，并且通过引导，它可能会查看中间和结尾部分……所以并非完全失败……但它是不稳定的……不稳定，或者 IMO 更难处理 : ) ---
**Author:** ![StevePlex](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/steveplex/32/269106_2.png) [@StevePlex](https://meta.discourse.org/u/StevePlex)\ **Post date:** [2024年五月24日 16:31 UTC](https://meta.discourse.org/t/prompt-injection-for-long-context-llms-as-an-alternative-to-rag/309086/8 "2024-05-24T16:31:57Z")
这里是测试文件，供大家参考： 文件包含以下 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](https://meta.discourse.org/uploads/short-url/m4K3iJaiqbTxBrh4rYiq8Q5vcny.txt) (71.8 KB) 欢迎提出所有评论、批评和指导！接下来，我将使用更多的 LLM 和嵌入模型等进行测试。 ---
**Author:** ![StevePlex](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/steveplex/32/269106_2.png) [@StevePlex](https://meta.discourse.org/u/StevePlex)\ **Post date:** [2024年五月24日 21:02 UTC](https://meta.discourse.org/t/prompt-injection-for-long-context-llms-as-an-alternative-to-rag/309086/9 "2024-05-24T21:02:18Z")
脚注： 我能够使用 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|](https://api.openai.com/v1/chat/completions%7C) |托管模型的服务 API 密钥|D20230943sdf\_fake\_Qqxo2exWa91|| ||| |分词器|OpenAITokenizer| |提示的令牌数|30000|