上下文注入方法

上下文 (context)注入是将相关文本段落（即“上下文”）整合到将发送给大型语言模型（LLM）的提示词 (prompt)中。注入此上下文的方式显著影响LLM有效发挥其作用的能力。常见的上下文注入方法在此讨论。

直接拼接

最直接的做法是简单地将获取到的上下文 (context)直接附加到原始用户问题的前面或后面。通常会使用分隔符或引导短语。

示例结构：

上下文：
[获取到的段落 1]
[获取到的段落 2]
...

根据以上上下文，回答以下问题：[用户问题]

或者，问题可能在前：

问题：[用户问题]

使用以下信息回答问题：
[获取到的段落 1]
[获取到的段落 2]
...

• 优点： 实现简单。对提示词 (prompt)工程要求不高。
• 缺点： 对顺序和格式敏感。如果获取到的段落很多，原始问题可能会被“淹没”，或者重要上下文离问题太远，导致LLM无法有效集中处理。这种方法也更难控制LLM如何使用上下文而非其内部知识。

模板化注入

一种更有条理且通常更受欢迎的方法是使用提示词 (prompt)模板。这些是预定义的字符串，带有问题和上下文 (context)的占位符。Python的f-strings或专门的模板库（如Jinja2，常用于LangChain等框架中）可以使这项工作易于管理。

示例模板（Python f-string）：

# 假设 'retrieved_docs' 是字符串列表
# 'user_query' 是原始问题
context_string = "\n".join(retrieved_docs)

prompt_template = f"""
你是一个助手，负责根据提供的上下文回答问题。
不要使用以下上下文之外的任何信息。

上下文：
{context_string}

问题：{user_query}

答案：
"""

# 'prompt_template' 现在包含为LLM完全格式化好的提示词

• 优点： 对提示词结构有更强的控制力。允许向LLM提供关于如何使用上下文的清晰指令（例如，“仅根据提供的上下文回答”）。使提示词更易于管理、版本控制和调试。
• 缺点： 需要比直接拼接更多的设置。设计有效的模板可能需要一些尝试。

结构化输入格式

一些LLM或交互框架可能支持更结构化的输入格式，可能接受问题和上下文 (context)作为对象内的独立参数 (parameter)或字段。

示例（API调用）：

response = llm_api.generate(
  query="什么是RAG？",
  context_documents=[
    "RAG 是检索增强生成（Retrieve-Augmented Generation）的缩写...",
    "它结合了检索与生成..."
  ],
  instructions="仅使用提供的文档回答问题。"
)

• 优点： 可能非常清晰和明确。可能允许底层模型架构更有效地处理上下文分离。
• 缺点： 对于标准开源或广泛可用的商业LLM API来说不太常见，这些API通常期望单个字符串提示词 (prompt)。支持程度在不同模型和平台之间差异很大。

提示词 (prompt)中的位置

将上下文 (context)放在模板中的位置也很重要。常见模式包括：

1. 上下文优先： 将所有上下文放在问题和指令之前。
2. 问题优先： 将问题放在最前面，然后是指令，最后是上下文。
3. 交错放置（高级）： 在更复杂的场景中，上下文可能与指令或推理 (inference)过程的部分内容交错放置。这在基本的RAG中不太常见。

最佳位置取决于所使用的具体LLM和任务的性质。一些模型表现出近因偏差，更关注提示词中后面出现的信息。通常需要进行实验。

下图展示了模板化注入的流程：

用户问题和获取到的上下文段落被插入到提示词模板中指定的占位符内。生成的格式化提示词随后发送给LLM。

选择合适的注入方法需要在实现上的简易性、对LLM行为的控制需求以及优化其使用提供信息的方式之间取得平衡。模板化为大多数RAG应用提供了灵活性和控制力的良好结合。在构建RAG系统时，思考这些不同的注入策略如何影响最终的生成输出，尤其是在处理不同数量的获取上下文时。