RAG-04生成编排-Long-Context-RAG

本文属于 RAG 工程框架中的「4 生成与智能体编排」环节，聚焦「Long Context RAG」方法。可先阅读 RAG-00.方法概述再进入本篇。

原理

通过大窗口模型直接注入更多原文，弱化复杂检索流程。

flowchart LR
  Q[Query] --> S[粗检。目录定位]
  S --> C[大量上下文拼接]
  C --> LLM[长上下文模型]
  LLM --> A[答案]

优缺。

优点：工程链路简化；少量文档场景效果稳定。
缺点：token 成本高；注意力分散导致“看不全”。

性能/资源

推理成本与上下文长度近似线性上升。
高并发场景成本压力大。

应用场景

小规模高价值资料库（合同包、项目档案）。
需要较完整原文上下文的审阅任务。

统一合成数据示例

输入数据片段

{
  "query": "总结差旅报销全流程",
  "long_context_docs": ["D01", "D02", "D03", "D04", "D05"],
  "token_count": 18000
}

中间结果（长上下文拼接）

{
  "selected_segments": [
    {"doc_id": "D01", "start": 0, "end": 420},
    {"doc_id": "D03", "start": 30, "end": 260},
    {"doc_id": "D05", "start": 10, "end": 210}
  ],
  "final_prompt_tokens": 6200
}

最终生成示例（含引用）

{
  "answer": "流程为：提交单据 -> 部门审批 -> 财务复核 -> 打款，且机票上限 2000 元、30 天内提交。",
  "citations": [{"doc_id": "D01", "evidence_span": "上限 2000 元、30 天内提交"}]
}

原始发表与工程实现

代表性原始发表：Longformer (2020), LongRoPE (2024)。
核心解决问题：解决超长上下文推理。
成熟实现工具：Claude/GPT/Qwen 长上下文模型。

详细原理拆解

长上下文策略强调片段选择和顺序，避免注意力稀释。
典型实现可拆为：输入预处理 -> 方法核心计算 -> 候选/证据构建 -> 生成与引用。
工程调优重点：质量（准确率/引用率）与成本（时延/token）的联合优化。

flowchart LR
  In[输入 Query 与知识] --> Core[方法核心计算]
  Core --> Rank[匹配/路由/排序]
  Rank --> Build[证据组装]
  Build --> Out[答案与引用]

工程落地扩展示例

伪代码

def long_context_pack(query, doc_segments, model_window: int, reserve_for_answer: int, scorer):
    ordered = rank_segments(query, doc_segments, scorer)
    packed, total = [], 0
    budget = model_window - reserve_for_answer
    for seg in ordered:
        if total + seg.tokens <= budget:
            packed.append(seg); total += seg.tokens
    return concat(packed)

参数示例

1
2
3

model_window_tokens: 128000
reserve_for_answer: 4096
segment_priority: [summary_first, then_by_relevance]

常见失败案例

失败模式 1：「全塞进去」导致 中间注意力稀释，关键句在超长上下文里被忽略。
失败模式 2：多文档顺序乱，条款引用串台（A 文档结论配 B 文档依据）。
失败模式 3：长窗模型成本高，与压缩/检索二选一 需算 ROI。

Demo 数据带入计算示例

1
2

四段 token 1200/900/1400/800，窗口 3000：按相关性贪心取 1200+900+800=2900，丢弃 1400 段。
若该段含「例外条款」，长窗策略可能 **漏关键约束**——需例外段硬保留或二次检索。