预处理
在初始阶段，根据文档创建目录 (ToC)至关重要。
这些文档与 Prompt-RAG 旨在解决的特定领域有着错综复杂的联系。
理想情况下，文档作者应该已经准备好目录。
但是，如果没有，可以手动制作。或者，可以部署大型语言模型 (LLM) 来生成 ToC，特别是在明确定义文档结构的情况下。
LLM 的上下文窗口大小显着影响目录和检索到的文档部分的大小。
为了优化标记大小，可以通过消除页眉、页脚、页码等元素来格式化文档。
这种格式可确保目录和检索部分中文档内容的简化和简洁表示。
标题选择
提示包括用户查询以及目录 (ToC)，然后将其提供给大型语言模型 (LLM)。
LLM 旨在识别目录中与查询最相关的标题。
在某些情况下，可以选择多个标题，并且为了进一步细化选择，可以对文本进行总结。此摘要过程有助于缩小选项范围，确保所选标题与用户查询最相关。
可以根据预算和用于答案生成的生成模型的上下文窗口大小提前在提示中设置所选标题的数量。
一个重要的元素是优化提示以实现准确的 ToC 检索和令牌使用效率。
提示词注入
下一步涉及检索与所选标题相对应的文档部分，然后在推理过程中将其作为上下文引用注入到提示中。
注入到提示中的参考文本的大小必须小于 LLM 的上下文窗口大小，这一点至关重要。
为了确保符合此要求，可以采用大型语言模型 (LLM) 来总结、截断或以其他方式修剪检索到的“块”。
此过程对于调整参考文本以适应上下文窗口大小的约束并最小化标记使用是必要的，从而优化效率。
如果由于查询是问候语或随意对话而导致所选标题缺失，则不带参考部分的替代提示将传递到基于 GPT-3.5-turbo 的模型，以减少令牌使用并节省费用。
生成答案的提示如下所示：
You are a chatbot based on a book called {Book Name}.
Here is a record of previous conversations:
{history}
Reference: {context}
Question: {question}
Use the reference to answer the question.
The reference above is only fractions of '<>'.
Be informative, gentle, and formal.
If you can't answer the question with the reference, just say like
'I couldn't find the right answer this time'.
Answer in {Language of Choice}:在提示模板下方，没有选择标题以供随意查询...
You are a chatbot based on a book called {Book Name}.
Here is a record of previous conversation for your smooth chats.:
{history}
Question: {question}
Answer the question.
Be informative, gentle, and formal.
Answer in {Language of Choice}:”综上所述
即使 Prompt-RAG 没有独立使用，Prompt-RAG 研究的重要性也是不可否认的。在某些情况下，Prompt-RAG 可以充当更大的实施框架中的组件。
通过创新方法优化和利用即时工程与围绕应用程序构建更复杂的数据管理框架之间存在着永久的平衡。通常，随着实现的使用和复杂性的扩展，后一种方法往往会占主导地位。
然而，必须承认 Prompt-RAG 需要一个应用程序框架来监督数据流、验证输入和输出以及进行必要的数据操作。
传统RAG的缺点
- 优化文档块大小和管理重叠可能是一个挑战。
- 随着数据变化更新块和嵌入以保持相关性。
- 未针对少数语言实现进行优化
- 运行嵌入的额外成本
- 对于较小的实现来说很麻烦
- 对技术要求更高
传统 RAG 与 Prompt-RAG 相比的优势
- 扩展性良好
- 更多以数据为中心的方法
- 批量数据发现和数据开发对于企业实施仍然很重要。
- 一般来说，语义聚类是数据发现的一个重要方面，也是实施 RAG 的良好第一步。
Prompt-RAG 优点
- 非常适合规模较小、技术含量较低的实现和少数语言。
- 非常适合特定需求和实施
- 对于聊天机器人，某些意图可以路由到 Prompt-RAG 实现
- 简化
- 可以作为全面 RAG 实施的首次尝试
- 非梯度方法
- 可检查性和可观察性
- 旨在优化 Prompt-RAG 的数据发现和数据设计工具可以增加显着的价值。
Prompt-RAG 缺点
- 还是需要数据设计。
- 上下文窗口大小是一个障碍。
- Tokens使用量和成本会更高；这需要与嵌入模型tokens成本进行比较。
- 扩展和引入复杂性需要一个技术框架。
- 取决于 LLM 推理延迟和令牌使用成本。
- 需要创建内容结构。该研究主要集中于已有目录的文档。