结合检索到的内容与提示词

将检索到的文档片段与用户查询结合，是检索增强生成（RAG）过程中向大型语言模型（LLM）有效呈现信息的主要一步。虽然检索可以识别语义相关的文档片段，但仅仅执行检索是不够的。LLM需要被明确指示如何使用这些获得的内容来生成其回答。

提示词工程在RAG中的作用

其核心在于，结合内容和查询涉及细致的提示词工程。我们需要构建一个提示词，引导LLM在组织其回答时优先使用所提供的内容。目标是让LLM的生成 依赖于 检索到的文档，而不是仅仅依赖其内部预训练知识。

构建增强型提示词

一种常见方法是创建一个提示词模板，其中包含检索到的内容和原始用户查询的占位符。结构通常如下所示：

1. 指示： 告诉LLM它的任务以及如何使用所提供的内容。
2. 内容： 插入检索到的文档片段的内容。
3. 查询： 说明用户的原始问题或请求。

以下是一个使用Python f-string来说明此结构的示例：

# 假设 'retrieved_chunks' 是一个字符串列表（文档内容）
# 假设 'user_query' 是原始问题字符串

# 将文档片段组合成一个字符串，通常使用分隔符
formatted_context = "\n\n---\n\n".join(retrieved_chunks)

# 创建最终提示词
prompt = f"""
你是一个助手，旨在 *仅* 根据所提供的文档回答问题。
不要使用下面所给内容之外的任何信息。
如果在文档中找不到答案，请明确说明。

内容文档:
{formatted_context}

用户查询:
{user_query}

回答:
"""

# 这个 'prompt' 字符串随后会发送给LLM API。

格式化检索到的内容

你如何格式化 formatted_context 部分很重要。简单地拼接文本可能会让LLM感到困惑。常见策略包括：

• 分隔符： 在片段之间使用清晰的分隔符，如 ---、***，或特定标记（[DOCUMENT 1 START]...[DOCUMENT 1 END]）。
• 编号： 为每个片段添加标识符作为前缀（例如，文档 1: ...，文档 2: ...）。
• 元数据： 如果可用且相关，有时包含来源信息（如文件名或页码）。

选择取决于具体的LLM和实验。目标是使其明确，一段检索到的信息在哪里结束，另一段在哪里开始，并清晰区分内容部分与指示和用户查询。

编写有效的指示

提示词的初始指示部分影响力很大。它为LLM应如何表现奠定了基础。考虑这些变体：

• 严格遵循内容： “仅根据以下文档中提供的信息回答问题。不要引用任何外部知识。如果答案不在文档中，请说‘未找到信息’。”（适用于封闭领域问答）。
• 内容优先生成： “根据以下文档，回答用户的问题。你可以综合多份文档中的信息。”（允许基于内容进行更灵活的生成）。
• 摘要/提取： “从所提供的文档中总结与用户查询相关的重要点：...”

这些指示的清晰度和具体性直接影响生成回答的质量和忠实度。你本质上是通过提示词来编程LLM针对此特定任务的行为。

可视化流程

获取查询、检索内容、并在发送给LLM之前格式化提示词的过程可以按如下方式可视化：

流程图说明了用户查询和检索到的内容如何通过提示词格式器组合，以创建发送给LLM的增强型提示词。

实际考量

• 内容窗口限制： LLM有最大输入令牌限制（即内容窗口）。如果你检索的片段过多，或者片段本身非常大，组合后的提示词可能会超出这个限制。你的实现需要处理这种情况，比如通过检索更少的片段、截断片段，或者使用具有更大内容窗口的模型。这在第三章中已讨论过，但在此处尤其适用。
• 指示遵循： 尽管我们指示LLM使用内容，但模型仍可能偶尔出现幻觉或忽视指示。评估输出（稍后会介绍）是必要的，以确保RAG系统按预期运行。
• 内容相关性： 检索步骤的质量直接影响此阶段。如果检索到不相关的文档，它们会增加提示词的噪音，并可能降低最终回答的质量，即使有好的指示。

通过细致地构建提示词，以包含清晰的指示和格式良好的内容以及原始查询，你有效地为LLM提供了它需要的特定信息，以生成相关、贴合内容的回答，克服其静态内部知识的局限性。这一增强步骤是RAG技术有效性的核心所在。