在OpenAI Chat Completions API中，如何基于文档列表为RAG模型提供上下文？

1. SystemMessage vs HumanMessage：哪种传递上下文更有效？ #

优先选择将文档内容嵌入HumanMessage，原因如下：

• SystemMessage的核心作用是定义模型的角色和通用行为规则（比如“你是专注于文档问答的助手，回答必须基于提供的内容”），模型对这部分内容的权重低于用户当前的交互输入。
• HumanMessage是用户当前对话的核心诉求载体，把文档上下文和提问放在一起，能让模型明确感知到这部分内容是回答当前问题的直接依据，注意力聚焦度更高，信息利用率更好。

如果是跨所有对话的通用规则（比如禁止编造内容），可以放在SystemMessage里，但具体的文档上下文一定要和用户提问绑定在HumanMessage中。

2. 确保模型有效使用文档上下文的优化方案 #

• 结构化标注上下文：给每个文档片段添加清晰标识，比如[文档片段1]：xxx、[文档片段2]：xxx，帮助模型区分不同来源的信息，也便于精准引用。
• 前置明确提示：在HumanMessage开头先给模型明确指令：「以下是用于回答问题的文档上下文，请严格基于这些内容作答：」，再附上文档内容，最后放置用户的具体问题。
• 精准筛选上下文：不要盲目塞入所有文档，通过向量检索只返回与用户提问最相关的Top N片段（比如Top3-Top5），减少冗余信息对模型的干扰。
• 简短示例引导：如果是复杂场景，可在SystemMessage中加入1-2个极简示例，比如「示例：用户问‘产品X的质保期’，上下文是‘产品X提供1年质保’，回答‘产品X的质保期为1年’」，帮模型快速明确规则。

3. 上下文数量与大小的关键限制 #

• 总token上限：不同模型有固定的最大上下文窗口（如gpt-3.5-turbo的16k版本上限为16384token，gpt-4o为128k），所有对话消息（System+Human+历史Assistant消息）的总token数不能超过该值，否则会触发报错。可使用tiktoken工具实时计算token消耗。
• 单片段拆分：长文档必须拆分为小片段（建议每段200-500token），既避免单个片段占用过多上下文空间，也能提升模型对信息的提取精度，同时更适配向量检索的匹配逻辑。
• 冗余信息剔除：即使上下文窗口足够大，也不要加入与当前提问无关的文档内容，冗余信息会分散模型注意力，降低回答准确率，还会增加不必要的token成本。
• 多轮对话清理：如果是多轮交互，要定期清理无关的历史对话，或对历史内容做摘要压缩，确保当前的文档上下文和提问有足够的token额度。

内容的提问来源于stack exchange，提问作者bitznbytez