对于如何输入长文本给大模型，论文 Retrieval Augmented Generation or Long-Context LLMs? 比较了 RAG(Retrieval Augmented Generation) 和支持较长文本输入的 LLM，给出了比较明确的结论：在资源足够的情况下，使用 LLM 的性能优于 RAG。
LLM 的输入长度限制
下面是一些可能会用到的大语言模型的长度限制
| model | size |
|---|---|
| BERT | 512 |
| GPT2 | 1024 |
| GPT3 | 2048 |
| GPT4o | 128K |
| Claude 3 | 200K |
| Gemini 1.5 | 1M |
可以看到近些时间 LLM 的文本输入长度变得越来越大，直接丢给他一本书来分析已经不在话下。
RAG 不及预期的原因
论文给出了 4 种原因
- query 需要多步推理的情况，后面的推理需要以前一步的结果为基础。比如某个歌曲的演唱者是哪国人，首先需要知道演唱者是谁。
- 比较笼统的查询，比如小组对某件事情的看法，这种的查询RAG 就比较难构造有效的背景信息。
- 查询很长而且复杂，RAG 无法理解。
- query 是隐性的，需要理解整个背景。例如在一篇关于太空旅行的冗长的对话叙述中，像“是什么导致了宇宙飞船后面的阴影？”这样的问题要求读者把这些点联系起来并推断出答案，因为在揭示原因时没有明确提到阴影。
其他意见
针对上面论文的观点，也有人持有不同意见，比如下面这位。他们实验的结果是需要基于复杂内容做推理的时候直接使用长文本的 LLM 可能没有 RAG 有效。
她最后给出的结论是对于非复杂场景两个都可以，复杂的场景使用 RAG。
结论
可以看出，针对 RAG 和 LLM 的使用上，目前意见并未完全统一，分歧点主要在复杂场景的使用上。但对于什么是复杂场景，可能大家的理解各有不同。从工程角度来说，如果我能一次把需要的数据都给模型，肯定是比构建 RAG 系统要简单的多。不过需要注意的是，api 方式调用模型的时候需要留意那些按照 token 计费的接口，因为很可能作为附件的那些长文本信息会被记入到 token 当中。
