什么是 ‘The Lost-in-the-Middle Countermeasure’：在 LangGraph 中重新排列长检索结果以确保核心信息处于模型注意力中心

各位编程专家、架构师及LLM应用开发者们：

今天，我们来深入探讨一个在构建基于大型语言模型（LLM）的检索增强生成（RAG）系统时，经常被忽视却又至关重要的问题——“Lost in the Middle”（信息迷失在中间）。尤其是在处理长篇检索结果时，这一现象会严重影响LLM的理解和响应质量。而我们今天的主角，正是旨在解决这一问题的强大策略：“The Lost-in-the-Middle Countermeasure”（信息迷失在中间的对抗措施），以及如何在LangGraph这一灵活框架中将其付诸实践，确保核心信息始终处于模型的注意力中心。

---

1. 深入理解“Lost in the Middle”问题：为何关键信息会被忽视？

在当今的LLM应用中，RAG模式已成为提升模型准确性和实时性、减少幻觉的关键范式。其核心在于，当用户提出问题时，系统会首先从一个大型知识库（如向量数据库）中检索出相关文档或片段，然后将这些检索结果与用户问题一同提供给LLM，作为其生成回答的“上下文”。

然而，当我们提供的检索结果变得冗长时，一个显著的问题就浮现了：LLM并非总能平等地关注上下文中的所有信息。多项研究，特别是Anthropic在2023年发布的一篇名为《Lost in the Middle: How Language Models Use Long Contexts》的论文，明确指出LLM在处理长上下文时，往往更倾向于关注上下文的开头和结尾部分，而对于中间部分的信息，其注意力会显著下降。这就像你在阅读一篇冗长的文章时，更容易记住开头和结尾的观点，而中间的细节则可能模糊不清。

具体表现为：

• 召回率下降： 如果回答问题的关键信息恰好位于检索结果的中间部分，LLM很可能无法有效利用它，导致回答不完整或不准确。
• 幻觉增加： LLM可能会因为未能找到关键信息而“猜测”答案，从而产生幻觉。
• 用户体验下降： 尽管后台检索到了正确的信息，但模型未能正确利用，导致用户无法获得高质量的回答。

设想一个场景：用户咨询一份长达数页的合同中的某个具体条款，而这份条款恰好在合同的中间部分。RAG系统检索出了整个合同（或多个相关片段），并将它们拼接起来作为上下文。如果关键条款被“埋”在中间，LLM很可能无法察觉，进而给出模糊或错误的回答。这就是“Lost in the Middle”问题的典型案例。

2. LLM的注意力机制与上下文窗口：技术根源

要理解“Lost in the Middle”，我们必须回顾LLM的工作原理，特别是其注意力机制（Attention Mechanism） 和上下文窗口（Context Window）。

2.1 LLM如何处理输入：Token与注意力

LLM将输入文本（包括用户查询和检索结果）切分成更小的单元——Token。这些Token通过嵌入层转换为数值向量，然后输入到Transformer架构中。Transformer的核心是自注意力机制（Self-Attention），它允许模型在处理序列中的每个Token时，能够“关注”序列中的其他Token，并计算它们之间的关联度。

直观地讲，当模型生成下一个Token时，它会回顾之前所有的Token，并通过注意力权重来决定哪些Token对当前生成最有帮助。这些注意力权重在模型内部形成一个注意力矩阵，反映了不同Token之间的依赖关系。

2.2 上下文窗口的限制

尽管LLM的上下文窗口在不断扩展（从几千Token到数十万甚至百万Token），但它始终是一个有限的资源。超出上下文窗口的文本将直接被截断，无法被模型处理。更重要的是，即使在上下文窗口内部，也存在上述的注意力偏见。

为什么会出现这种偏见？

学术界对这一现象有多种解释：

• 位置编码的衰减： 许多Transformer模型使用位置编码来注入序列中Token的位置信息。随着距离的增加，位置编码的判别力可能会下降，导致模型对远距离信息的识别能力减弱。
• 训练数据偏差： 训练LLM的大规模语料库中，关键信息可能更多地出现在文章的开头和结尾（如标题、摘要、结论），导致模型在训练过程中形成了这种注意力偏置。
• 计算复杂性： 尽管自注意力机制理论上可以关注所有Token，但对于极长的序列，模型可能在内部学习到某种启发式，以简化计算或提高效率，从而牺牲对中间部分的关注。

特性	描述	影响
Token化	文本被分割成模型可处理的最小单元。	决定了上下文窗口的实际容量。
注意力机制	模型计算输入序列中每个Token与其他Token的关联度。	理论上允许模型关注任何位置的信息，但实践中存在偏见。
上下文窗口	LLM可以同时处理的Token序列的最大长度。	超出部分被截断，窗口内部存在“Lost in the Middle”偏见。
位置编码	向模型提供Token在序列中的位置信息。	可能导致模型对长距离依赖的识别能力下降。
训练数据偏见	模型在训练过程中，可能因数据分布（如文章结构）而学习到对开头和结尾信息的偏好。	导致模型在推理时对中间信息的注意力不足。

理解这些技术根源，是我们设计有效对抗措施的前提。我们的目标是，通过智能地重新排列检索结果，人工地将关键信息“移动”到LLM更关注的位置，从而弥补这一内在缺陷。

3. “Lost-in-the-Middle Countermeasure”的核心思想：重新排列的艺术

“The Lost-in-the-Middle Countermeasure”的核心思想非常直接：既然LLM更关注上下文的开头和结尾，那么我们就应该将最关键、最相关的信息放置在这两个区域。

这种策略的有效性在于，它并非试图改变LLM的注意力机制（这是模型内部的复杂结构），而是通过改变输入数据的结构来适应模型的行为模式。它是一种“曲线救国”的智慧。

具体策略概览：

1. 识别关键信息： 这通常通过检索系统提供的相关性分数、二次重排（re-ranking）或基于关键词的启发式方法来完成。
2. 构造新的上下文： 将最关键的文档或片段放置在上下文的开始和结束位置。
3. 处理中间部分： 对于那些相关性较低或被认为不那么紧急的文档，可以将其放置在中间，或者进行摘要处理，甚至直接丢弃（如果上下文窗口有限）。

这种重新排列的艺术，可以有多种具体的实现方式，我们将逐一探讨。

4. LangGraph与RAG：构建可编程、模块化的解决方案

在将“Lost-in-the-Middle Countermeasure”付诸实践时，我们需要一个强大的框架来编排复杂的RAG工作流。LangGraph，作为LangChain的扩展，正是为此而生。

为什么选择LangGraph？

• 状态机范式： LangGraph允许我们将复杂的LLM应用建模为有向无环图（DAG）或循环图（状态机），每个节点执行一个特定的任务，并通过边定义数据流和控制流。
• 模块化与可组合性： 我们可以将检索、重排、重新排列、LLM调用等步骤封装为独立的节点，然后像乐高积木一样组合它们，构建出高度定制化的RAG管道。
• 可观测性与调试： 图结构使得工作流的每一步都清晰可见，便于调试和优化。
• 灵活性： 传统的LangChain链可能难以表达复杂的条件逻辑或多步交互，而LangGraph能够轻松实现这些。

通过LangGraph，我们可以创建一个RAG管道，其中包含一个专门的节点来执行“Lost-in-the-Middle Countermeasure”，从而在不修改LLM本身的情况下，显著提升其性能。

5. 实现“The Lost-in-the-Middle Countermeasure”在LangGraph中

现在，让我们通过代码示例，逐步构建一个LangGraph工作流，并集成“Lost-in-the-Middle Countermeasure”。

我们将从一个基本的RAG设置开始，然后逐步引入各种重新排列策略。

5.1. 基础RAG设置 (Baseline)

首先，我们需要一个基础的RAG系统。这包括：

1. 文档加载与分块： 从某个源加载文档，并将其分割成适合嵌入和检索的块。
2. 嵌入模型与向量存储： 使用嵌入模型将文档块转换为向量，并存储在向量数据库中。
3. 检索器： 根据用户查询在向量数据库中查找相关文档块。
4. LLM： 接收用户查询和检索到的上下文，生成回答。

为了简化，我们将使用一个小型内存型向量存储和模拟的文档内容。

import os
from typing import List, Dict, Any, Tuple

# 假设已经安装了必要的库：
# pip install langchain langchain-community langchain-openai faiss-cpu pydantic
# pip install langgraph
from langchain_community.document_loaders import TextLoader
from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_core.documents import Document
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnablePassthrough, RunnableLambda
from langchain_core.prompts import ChatPromptTemplate

# LangGraph 相关的导入
from langgraph.graph import StateGraph, END

# 设置环境变量，实际应用中请使用安全方式管理API Key
os.environ["OPENAI_API_KEY"] = "YOUR_OPENAI_API_KEY"
os.environ["LANGCHAIN_TRACING_V2"] = "true" # 开启LangChain追踪方便调试
os.environ["LANGCHAIN_API_KEY"] = "YOUR_LANGCHAIN_API_KEY"

# 1. 模拟文档内容
long_document_content = """
The initial project proposal outlines a bold new initiative to develop an AI-powered personal assistant, codenamed "Project Aura." 
This assistant aims to revolutionize human-computer interaction by offering proactive support, contextual understanding, and natural language processing capabilities far superior to existing solutions. 
The core team, led by Dr. Evelyn Reed (Lead AI Scientist) and Mr. Mark Chen (Head of Product Development), has set an ambitious timeline of 18 months for the initial prototype.

One of the key challenges identified is the integration with diverse third-party APIs, requiring robust error handling and secure authentication protocols. 
The system architecture will be microservices-based, allowing for scalable development and deployment. 
Funding for Project Aura has been secured through a Series B investment round, totaling $50 million, with significant contributions from Quantum Ventures and Innovate Capital.

A critical decision point, often overlooked in the early stages, revolves around data privacy and ethical AI guidelines. 
**The ethical review board, chaired by Professor Anya Sharma from the Global Ethics Institute, strongly recommended that all personal data processed by Project Aura must be anonymized by default and encrypted using AES-256 standards.** 
This recommendation is non-negotiable and will require significant engineering effort to implement correctly, particularly concerning cross-border data transfer regulations like GDPR and CCPA. 
Failure to comply could result in severe legal penalties and reputational damage.

The user interface design phase will commence in Q3, focusing on minimalist aesthetics and intuitive user flows. 
Early mockups suggest a voice-first interaction model, complemented by a subtle visual display for complex information. 
Performance metrics will include response latency (target: <500ms), accuracy of intent recognition (target: >95%), and user satisfaction scores.

Further details regarding the marketing strategy indicate a phased rollout, starting with a closed beta for early adopters in Q1 of the next fiscal year. 
The project's success hinges on seamless integration with existing smart home ecosystems and enterprise productivity suites. 
A potential bottleneck could be the availability of high-quality training data for less common languages, which needs to be addressed proactively.
"""

# 2. 文档加载与分块
text_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=100)
docs = [Document(page_content=long_document_content, metadata={"source": "project_aura_proposal"})]
splits = text_splitter.split_documents(docs)

# 3. 嵌入模型与向量存储
embeddings = OpenAIEmbeddings()
vectorstore = FAISS.from_documents(splits, embeddings)
retriever = vectorstore.as_retriever(search_kwargs={"k": 5}) # 检索前5个最相关的块

# 4. LLM
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0.1)

# 辅助函数：格式化检索到的文档为字符串
def format_docs(docs: List[Document]) -> str:
    return "nn".join(doc.page_content for doc in docs)

# 5. 定义基础RAG链
rag_prompt_template = ChatPromptTemplate.from_messages(
    [
        ("system", "你是一个专业的助手。请根据提供的上下文回答用户的问题。如果上下文中没有相关信息，请说明你无法找到答案。"),
        ("human", "上下文:n{context}nn问题: {question}"),
    ]
)

# 构建一个简单的RAG链（非LangGraph版本，用于对比）
basic_rag_chain = (
    {"context": retriever | format_docs, "question": RunnablePassthrough()}
    | rag_prompt_template
    | llm
    | StrOutputParser()
)

print("--- 基础RAG链测试 ---")
query_baseline = "Project Aura的关键伦理和数据隐私规定是什么？"
# 假设这个关键信息在原始文档的中间部分。
# print(basic_rag_chain.invoke(query_baseline))

# 为了避免实际调用LLM，我们只展示检索结果
retrieved_docs_baseline = retriever.invoke(query_baseline)
print(f"基础RAG检索到的文档数量: {len(retrieved_docs_baseline)}")
print("部分检索内容示例：")
for i, doc in enumerate(retrieved_docs_baseline[:2]):
    print(f"--- Doc {i+1} ---")
    print(doc.page_content[:200] + "...") # 打印前200字符

分析基础RAG：
在这个基础设置中，retriever会直接返回它认为最相关的k个文档块。这些文档块会按照它们与查询的相关性分数（通常由向量相似度决定）降序排列。如果关键信息恰好位于某个相关性不那么高的文档块中，或者被更不重要的但相关性分数略高的文档块所包围，那么LLM就可能“Lost in the Middle”。

5.2. 对抗措施：重新排列策略与LangGraph实现

现在，我们来引入“Lost-in-the-Middle Countermeasure”。我们将在LangGraph中定义一个专门的节点来执行文档的重新排列。

5.2.1. 策略1: 简单头部/尾部拼接 (Head/Tail Concatenation)

这是最直接的策略：将检索结果的前N个文档和后M个文档组合起来，作为LLM的上下文。这种策略假设最相关的和最不相关的文档（或者说，那些可能包含补充信息的文档）可能会被LLM更好地关注到。

实现思路：

1. 检索器返回一组文档（通常已按相关性排序）。
2. 我们取前 top_n 个文档。
3. 我们取后 bottom_m 个文档。
4. 将它们拼接起来。

# 定义LangGraph的状态
class GraphState(Dict):
    question: str
    documents: List[Document]
    context: str # 用于LLM的最终上下文

# 节点：检索文档
def retrieve(state: GraphState) -> GraphState:
    print("---RETRIEVE---")
    question = state["question"]
    documents = retriever.invoke(question)
    return {"documents": documents, "question": question}

# 节点：重新排列文档 - 策略1: 简单头部/尾部拼接
def rearrange_docs_head_tail(state: GraphState) -> GraphState:
    print("---REARRANGE DOCS (Head/Tail)---")
    documents = state["documents"]
    question = state["question"]

    if not documents:
        return {"context": "", "question": question, "documents": []}

    # 假设我们取前2个和后2个文档
    top_n = 2
    bottom_m = 2

    rearranged_docs = []
    if len(documents) > top_n:
        rearranged_docs.extend(documents[:top_n])
    else:
        rearranged_docs.extend(documents) # 如果文档不足top_n，则全部取

    # 如果文档数量足够，并且top_n + bottom_m 不会重复选取太多
    if len(documents) > top_n + bottom_m:
        # 确保不重复选取文档，特别是当文档总数较少时
        # 简单处理：如果文档总数小于等于 top_n + bottom_m，则所有文档都在top_n中处理了
        # 否则，从原始文档列表的末尾开始选取
        rearranged_docs.extend(documents[len(documents) - bottom_m:])
    elif len(documents) > top_n and len(documents) <= top_n + bottom_m:
        # 如果文档数量介于 top_n 和 top_n + bottom_m 之间，
        # 则所有剩余文档都添加到 rearranged_docs 中（避免重复且不超出范围）
        # 此时已经包含了 top_n 个文档，剩余的直接添加
        rearranged_docs.extend(documents[top_n:])

    # 去重，因为extend可能导致重复
    unique_docs = []
    seen_page_contents = set()
    for doc in rearranged_docs:
        if doc.page_content not in seen_page_contents:
            unique_docs.append(doc)
            seen_page_contents.add(doc.page_content)

    # 将重新排列后的文档格式化为上下文
    context = format_docs(unique_docs)
    print(f"重新排列后上下文长度: {len(context)} 字符, 文档数量: {len(unique_docs)}")
    return {"context": context, "question": question, "documents": unique_docs}

# 节点：生成答案
def generate(state: GraphState) -> GraphState:
    print("---GENERATE---")
    question = state["question"]
    context = state["context"]

    # 使用LLM生成答案
    response = llm.invoke(rag_prompt_template.format(context=context, question=question))
    return {"question": question, "context": context, "documents": state["documents"], "answer": response.content}

# 构建LangGraph
workflow_head_tail = StateGraph(GraphState)

workflow_head_tail.add_node("retrieve", retrieve)
workflow_head_tail.add_node("rearrange_docs_head_tail", rearrange_docs_head_tail)
workflow_head_tail.add_node("generate", generate)

workflow_head_tail.set_entry_point("retrieve")
workflow_head_tail.add_edge("retrieve", "rearrange_docs_head_tail")
workflow_head_tail.add_edge("rearrange_docs_head_tail", "generate")
workflow_head_tail.add_edge("generate", END)

app_head_tail = workflow_head_tail.compile()

print("n--- LangGraph (策略1: 头部/尾部拼接) 测试 ---")
query_strategy1 = "Project Aura的关键伦理和数据隐私规定是什么？"
# for s in app_head_tail.stream({"question": query_strategy1}):
#     print(s)
# print(app_head_tail.invoke({"question": query_strategy1})["answer"])

# 为了展示效果，我们模拟运行到重新排列阶段
initial_state = {"question": query_strategy1, "documents": [], "context": ""}
retrieved_state = retrieve(initial_state)
rearranged_state_1 = rearrange_docs_head_tail(retrieved_state)

print("n重新排列后的文档内容预览 (策略1):")
print(rearranged_state_1["context"][:500] + "...") # 打印前500字符

策略1的局限性：
这种方法比较粗糙。它假设最重要信息总是在检索结果的前几位，或者在最不相关的后几位（可能包含某种补充信息）。但如果关键信息恰好位于中间，并且其相关性分数不是最高的，它仍然可能被忽略。

5.2.2. 策略2: “三明治”或“镜像”策略 (Sandwich/Mirror Strategy)

这种策略更精细一些。它通常涉及：

1. 识别出最核心的少数几个文档。
2. 将这些核心文档放置在上下文的开头和结尾（形成“三明治”结构）。
3. 将其他文档放置在中间。

“最核心”的文档可以通过多种方式确定：

• 初始检索器得分最高的文档。
• 经过二次重排器（Re-ranker）筛选出的文档。
• 基于关键词匹配或NER（命名实体识别）等启发式方法。

在这里，我们先假设通过初始检索器得分最高的文档就是核心文档。

# 节点：重新排列文档 - 策略2: 三明治/镜像策略
def rearrange_docs_sandwich(state: GraphState) -> GraphState:
    print("---REARRANGE DOCS (Sandwich)---")
    documents = state["documents"]
    question = state["question"]

    if not documents:
        return {"context": "", "question": question, "documents": []}

    # 假设我们认为得分最高的1个文档是最核心的
    # LangChain的retriever通常返回的文档已经按相关性降序排列
    core_docs = documents[:1] # 最相关的1个文档

    # 其他文档作为“填充”
    other_docs = documents[1:]

    rearranged_docs = []
    # 策略：核心文档 (开头) -> 其他文档 (中间) -> 核心文档 (结尾，可选重复或不同核心)
    # 这里我们简单地将核心文档放在开头，然后将其他文档打乱，最后再放一个核心文档的副本

    # 1. 放置核心文档在开头
    rearranged_docs.extend(core_docs)

    # 2. 将其他文档随机打乱或按某种启发式排序，然后放置
    # 注意：为了避免每次运行结果不同，这里暂时不打乱，直接按原顺序放置
    rearranged_docs.extend(other_docs)

    # 3. 再次放置核心文档在结尾 (可选，但有助于强化)
    # 确保只在有足够上下文空间且核心文档值得强调时才这样做
    if len(documents) > 1: # 只有当核心文档不是唯一的文档时才重复
        rearranged_docs.extend(core_docs)

    # 去重
    unique_docs = []
    seen_page_contents = set()
    for doc in rearranged_docs:
        if doc.page_content not in seen_page_contents:
            unique_docs.append(doc)
            seen_page_contents.add(doc.page_content)

    context = format_docs(unique_docs)
    print(f"重新排列后上下文长度: {len(context)} 字符, 文档数量: {len(unique_docs)}")
    return {"context": context, "question": question, "documents": unique_docs}

# 构建LangGraph (使用策略2)
workflow_sandwich = StateGraph(GraphState)

workflow_sandwich.add_node("retrieve", retrieve)
workflow_sandwich.add_node("rearrange_docs_sandwich", rearrange_docs_sandwich)
workflow_sandwich.add_node("generate", generate)

workflow_sandwich.set_entry_point("retrieve")
workflow_sandwich.add_edge("retrieve", "rearrange_docs_sandwich")
workflow_sandwich.add_edge("rearrange_docs_sandwich", "generate")
workflow_sandwich.add_edge("generate", END)

app_sandwich = workflow_sandwich.compile()

print("n--- LangGraph (策略2: 三明治/镜像) 测试 ---")
query_strategy2 = "Project Aura的关键伦理和数据隐私规定是什么？"
# for s in app_sandwich.stream({"question": query_strategy2}):
#     print(s)
# print(app_sandwich.invoke({"question": query_strategy2})["answer"])

# 模拟运行到重新排列阶段
retrieved_state_s2 = retrieve(initial_state) # 再次调用retrieve确保文档一致
rearranged_state_2 = rearrange_docs_sandwich(retrieved_state_s2)

print("n重新排列后的文档内容预览 (策略2):")
print(rearranged_state_2["context"][:500] + "...") # 打印前500字符

策略2的改进：
通过识别“核心”文档并将其重复放置在上下文两端，我们更有力地向LLM强调了这些信息。这种方法在许多场景下表现良好。但它的前提是，我们能够准确地识别出“核心”文档。

5.2.3. 策略3: 重排器结合头部/尾部放置 (Re-ranking + Head/Tail Placement)

这是目前最强大也最常用的策略之一。它引入了一个专门的重排器（Re-ranker）。重排器的任务是接收初始检索器返回的一组文档，然后根据查询，对这些文档进行更细粒度的相关性评分，并重新排序。重排器通常是基于更复杂的交叉编码器（cross-encoder）模型，能够更好地理解查询和文档之间的语义关系。

实现思路：

1. 初始检索： 从向量数据库中检索出较多的文档（例如，top-k，k可能比最终需要的上下文文档数量大）。
2. 重排： 使用重排器对这些文档进行二次评分和排序，找出真正的“最相关”文档。
3. 重新排列： 将重排后得分最高的文档放置在上下文的开头和结尾。其余文档（如果需要）放置在中间，或进行摘要。

我们将使用CohereRerank（需要API Key）或BGEReranker（本地运行，但需要额外的模型下载）作为示例。这里我们为了通用性，先假设有一个抽象的reranker。

# 导入重排器
from langchain_community.llms import Cohere # 示例，实际使用Rerank API
from langchain_community.rankers import CohereRerank
# 或者使用本地的BGE Re-ranker
from langchain_community.retrievers import BM25Retriever
from langchain_community.cross_encoders import HuggingFaceCrossEncoder
from transformers import AutoTokenizer, AutoModelForSequenceClassification

# 假设我们有一个Cohere API Key，或者本地加载一个交叉编码器
# 如果使用CohereRerank，请确保设置 COHERE_API_KEY
# os.environ["COHERE_API_KEY"] = "YOUR_COHERE_API_KEY"

# 抽象的重排器类，以便于替换
class CustomReranker:
    def __init__(self, model_name="BAAI/bge-reranker-base"):
        # 尝试加载本地BGE重排器
        try:
            self.tokenizer = AutoTokenizer.from_pretrained(model_name)
            self.model = AutoModelForSequenceClassification.from_pretrained(model_name)
            print(f"Loaded local reranker model: {model_name}")
        except Exception as e:
            print(f"Could not load local reranker model {model_name}: {e}")
            print("Falling back to a dummy reranker. Please install required libraries or set COHERE_API_KEY.")
            self.tokenizer = None
            self.model = None

    def rerank(self, query: str, documents: List[Document]) -> List[Document]:
        if not documents:
            return []

        if self.model and self.tokenizer:
            # 使用本地BGE重排器
            sentences = [(query, doc.page_content) for doc in documents]
            inputs = self.tokenizer(sentences, padding=True, truncation=True, return_tensors='pt')
            scores = self.model(**inputs).logits.squeeze().tolist()

            # 将得分与文档关联，并重新排序
            scored_docs = []
            for i, doc in enumerate(documents):
                # 确保scores是列表，且索引有效
                score = scores[i] if isinstance(scores, list) and i < len(scores) else 0.0
                scored_docs.append((score, doc))

            scored_docs.sort(key=lambda x: x[0], reverse=True) # 降序
            return [doc for score, doc in scored_docs]

        # 兜底方案：如果重排器未加载，则返回原始文档
        print("Using dummy reranker: returning documents in original order.")
        return documents

# 初始化自定义重排器
custom_reranker = CustomReranker()

# 节点：重排文档
def rerank_documents(state: GraphState) -> GraphState:
    print("---RERANK DOCUMENTS---")
    question = state["question"]
    documents = state["documents"] # 此时的documents是初始检索器返回的

    if not documents:
        return {"documents": [], "question": question, "context": ""}

    # 执行重排
    reranked_docs = custom_reranker.rerank(question, documents)
    print(f"重排后文档数量: {len(reranked_docs)}")
    return {"documents": reranked_docs, "question": question}

# 节点：重新排列文档 - 策略3: 重排器结合头部/尾部放置
def rearrange_docs_reranked_placement(state: GraphState) -> GraphState:
    print("---REARRANGE DOCS (Reranked Placement)---")
    documents = state["documents"] # 此时的documents已经是重排后的
    question = state["question"]

    if not documents:
        return {"context": "", "question": question, "documents": []}

    # 假设我们取重排后得分最高的2个文档作为关键信息
    top_critical_docs = documents[:2]

    # 剩下的文档
    remaining_docs = documents[2:]

    rearranged_docs = []
    # 1. 放置最重要的文档在开头
    rearranged_docs.extend(top_critical_docs)

    # 2. 随机打乱或按某种策略放置剩余文档
    # 为了保持示例的确定性，这里不打乱，直接按顺序放置
    rearranged_docs.extend(remaining_docs)

    # 3. 可选：再次放置最重要的文档的副本在结尾
    if len(documents) > 2: # 只有当有足够空间且值得强调时
        rearranged_docs.extend(top_critical_docs)

    # 去重
    unique_docs = []
    seen_page_contents = set()
    for doc in rearranged_docs:
        if doc.page_content not in seen_page_contents:
            unique_docs.append(doc)
            seen_page_contents.add(doc.page_content)

    context = format_docs(unique_docs)
    print(f"重新排列后上下文长度: {len(context)} 字符, 文档数量: {len(unique_docs)}")
    return {"context": context, "question": question, "documents": unique_docs}

# 构建LangGraph (使用策略3)
workflow_rerank_placement = StateGraph(GraphState)

workflow_rerank_placement.add_node("retrieve", retrieve)
workflow_rerank_placement.add_node("rerank_documents", rerank_documents)
workflow_rerank_placement.add_node("rearrange_docs_reranked_placement", rearrange_docs_reranked_placement)
workflow_rerank_placement.add_node("generate", generate)

workflow_rerank_placement.set_entry_point("retrieve")
workflow_rerank_placement.add_edge("retrieve", "rerank_documents")
workflow_rerank_placement.add_edge("rerank_documents", "rearrange_docs_reranked_placement")
workflow_rerank_placement.add_edge("rearrange_docs_reranked_placement", "generate")
workflow_rerank_placement.add_edge("generate", END)

app_rerank_placement = workflow_rerank_placement.compile()

print("n--- LangGraph (策略3: 重排器 + 头部/尾部放置) 测试 ---")
query_strategy3 = "Project Aura的关键伦理和数据隐私规定是什么？"
# for s in app_rerank_placement.stream({"question": query_strategy3}):
#     print(s)
# print(app_rerank_placement.invoke({"question": query_strategy3})["answer"])

# 模拟运行到重新排列阶段
retrieved_state_s3 = retrieve(initial_state)
reranked_state_s3 = rerank_documents(retrieved_state_s3)
rearranged_state_3 = rearrange_docs_reranked_placement(reranked_state_s3)

print("n重新排列后的文档内容预览 (策略3):")
print(rearranged_state_3["context"][:500] + "...") # 打印前500字符

策略3的优势与考量：

• 优势： 重排器能够更准确地识别出与查询最相关的文档，从而确保真正重要的信息被放置在显眼位置。
• 考量： 引入重排器会增加额外的计算开销和延迟。选择合适的重排器模型（本地部署或API服务）也很重要。

5.2.4. 策略4: 混合方法与高级启发式

更复杂的策略可以结合上述方法，并引入更多动态决策：

• 摘要中间文档： 对于那些不那么核心但仍有一定相关性的文档，可以对其进行摘要处理，以节省上下文空间，并减少“噪音”。
• 动态上下文窗口： 根据查询的复杂性或预期答案的长度，动态调整上下文窗口的大小和文档的取舍。
• 迭代检索与细化： 如果LLM的初步回答不够满意，可以基于LLM的反馈（例如，识别出缺失的信息）进行二次检索或重新排列。

这些高级策略通常需要更多的LLM调用或更复杂的逻辑，但LangGraph的灵活性使得它们完全可以实现。例如，我们可以添加一个summarize_middle_docs节点，或者一个decide_next_action节点来根据LLM的输出进行条件路由。

# 示例：一个简单的中间文档摘要节点
from langchain_core.runnables import RunnableParallel

# 假设我们有一个专门用于摘要的LLM或链
summarize_chain = ChatPromptTemplate.from_messages(
    [
        ("system", "请将以下文本摘要为1-2句话的关键信息。"),
        ("human", "文本: {text}"),
    ]
) | llm | StrOutputParser()

def summarize_middle_docs(state: GraphState) -> GraphState:
    print("---SUMMARIZE MIDDLE DOCS---")
    documents = state["documents"] # 假设这些是重排后，但仍待处理的文档
    question = state["question"]

    if not documents or len(documents) <= 2: # 如果文档很少，不需要摘要
        return {"documents": documents, "question": question}

    # 假设前两个和后两个文档是重要文档，中间的需要摘要
    important_head = documents[:2]
    important_tail = documents[len(documents)-2:] if len(documents) > 4 else []

    middle_docs = documents[2:len(documents)-2] if len(documents) > 4 else documents[2:]

    summarized_middle_contents = []
    if middle_docs:
        print(f"正在摘要 {len(middle_docs)} 个中间文档...")
        # 批量摘要可以并行化，这里为简化串行
        for doc in middle_docs:
            summary = summarize_chain.invoke({"text": doc.page_content})
            summarized_middle_contents.append(Document(page_content=f"摘要: {summary}", metadata=doc.metadata))

    # 重新组合文档
    final_docs = []
    final_docs.extend(important_head)
    final_docs.extend(summarized_middle_contents)
    final_docs.extend(important_tail)

    # 去重
    unique_docs = []
    seen_page_contents = set()
    for doc in final_docs:
        if doc.page_content not in seen_page_contents:
            unique_docs.append(doc)
            seen_page_contents.add(doc.page_content)

    print(f"摘要后最终文档数量: {len(unique_docs)}")
    return {"documents": unique_docs, "question": question}

# 构建一个包含摘要的LangGraph示例（基于策略3的扩展）
workflow_hybrid = StateGraph(GraphState)

workflow_hybrid.add_node("retrieve", retrieve)
workflow_hybrid.add_node("rerank_documents", rerank_documents)
workflow_hybrid.add_node("summarize_middle_docs", summarize_middle_docs) # 新增节点
workflow_hybrid.add_node("rearrange_docs_hybrid", rearrange_docs_reranked_placement) # 复用放置逻辑
workflow_hybrid.add_node("generate", generate)

workflow_hybrid.set_entry_point("retrieve")
workflow_hybrid.add_edge("retrieve", "rerank_documents")
workflow_hybrid.add_edge("rerank_documents", "summarize_middle_docs") # 重排后先摘要
workflow_hybrid.add_edge("summarize_middle_docs", "rearrange_docs_hybrid") # 再进行最终的重新排列
workflow_hybrid.add_edge("rearrange_docs_hybrid", "generate")
workflow_hybrid.add_edge("generate", END)

app_hybrid = workflow_hybrid.compile()

print("n--- LangGraph (策略4: 混合策略 - 重排+摘要+放置) 测试 ---")
query_strategy4 = "Project Aura的关键伦理和数据隐私规定是什么？"
# 注意：此链会进行LLM调用进行摘要，可能较慢且产生费用
# print(app_hybrid.invoke({"question": query_strategy4})["answer"])

5.3. LangGraph工作流集成总结

节点名称	职责	输入	输出
retrieve	从向量数据库检索初始文档。	question	documents
rerank_documents (可选)	使用重排器对检索到的文档进行二次排序。	question, documents	documents (重排后)
summarize_middle_docs (可选)	对非核心文档进行摘要以节省上下文空间。	question, documents	documents (部分摘要后)
rearrange_docs_... (核心)	根据选择的策略（头部/尾部、三明治、重排放置）重新排列文档。	question, documents	context (最终LLM上下文字符串), documents (重新排列后的列表)
generate	将格式化后的上下文和问题发送给LLM，生成最终答案。	question, context	answer

图结构流程：
Entry Point -> retrieve -> rerank_documents (可选) -> summarize_middle_docs (可选) -> rearrange_docs_... -> generate -> END

LangGraph的状态GraphState在节点之间传递，确保了数据流的连贯性。每个节点接收当前状态，处理后返回更新后的状态，然后传递给下一个节点。

6. 评估效果：如何衡量改进？

实施了“Lost-in-the-Middle Countermeasure”后，我们如何知道它是否真的有效？评估是至关重要的一步。

评估指标：

1. 回答准确性 (Accuracy/Factuality)：

   • 人工评估： 最可靠但成本最高。专家根据标准答案或源文档判断LLM回答的准确性和完整性。
   • 基于LLM的评估： 使用另一个强大的LLM作为评判者，根据给定的上下文和问题来评分。
   • RAGAS等工具： 专注于RAG评估的框架，提供忠实度（Faithfulness）、相关性（Relevance）、上下文召回（Context Recall）、上下文精确度（Context Precision）等指标。

2. 上下文利用率 (Context Utilization)：

   • 信息召回： 特定于“Lost-in-the-Middle”问题，检查LLM是否成功利用了位于原始中间位置的关键信息。
   • 注意力可视化： 对一些更透明的模型（如较小的Transformer模型）可以尝试可视化注意力权重，看是否确实对两端信息关注更多。

3. 用户满意度：

   • 通过A/B测试，比较使用和不使用对抗措施的系统，收集用户反馈。
   • 测量用户对答案的满意度、置信度等。

4. 延迟与成本：

   • 端到端延迟： 引入重排器或摘要步骤会增加延迟，需要权衡。
   • API调用成本： 额外的LLM调用（如摘要）会增加成本。

挑战：

• 长上下文评估的复杂性： 自动评估长上下文RAG的准确性仍是一个研究难题。
• 真实世界场景模拟： 构建能够充分体现“Lost-in-the-Middle”问题的测试集需要精心设计。

通常，我们会构建一个包含许多“埋藏”关键信息的测试集，然后比较基线RAG系统和应用了对抗措施的系统在该测试集上的表现。

7. 最佳实践与考量

在应用“The Lost-in-the-Middle Countermeasure”时，有几个关键点需要注意：

• 文档分块策略：

  • 粒度： 块的大小至关重要。如果块太小，可能丢失上下文；如果太大，可能超过上下文窗口或稀释关键信息。
  • 语义分块： 尽量使每个块包含一个完整的语义单元，而不是在句子中间截断。
  • 重叠： 适当的块重叠有助于在检索时捕捉跨块的信息。

• 相关性评分的可靠性：

  • 初始检索器的相关性分数可能不够精确，特别是对于复杂查询。
  • 重排器通常能提供更准确的相关性评估，但代价是延迟。

• 上下文窗口限制：

  • 即使重新排列，LLM的上下文窗口仍然是硬性限制。需要根据LLM模型的能力，决定最终上下文的总长度。
  • 如果检索到的文档过多，需要策略性地选择或摘要。

• 计算开销与延迟：

  • 重排、摘要等步骤会引入额外的计算，可能影响用户体验。
  • 需要根据应用场景对性能和准确性进行权衡。对于实时性要求高的应用，可能需要选择更轻量级的重排器或更简单的重新排列策略。

• 领域特异性：

  • “核心”文档的定义、重新排列的启发式规则可能需要根据特定领域或应用场景进行调整。
  • 例如，在法律文档中，特定条款的引用可能比一般性描述更重要。

• 透明度与可解释性：

  • 在某些应用中，用户可能需要知道答案来源于哪些原始文档。重新排列文档后，确保能够追溯到原始来源。

• 动态调整：

  • 可以根据用户查询的类型（例如，事实性问题、开放式问题、总结性问题）动态选择不同的重新排列策略。
  • 例如，对于事实性问题，重排器结合精确放置可能更有效；对于总结性问题，头部/尾部拼接加中间摘要可能更合适。

8. 高级话题与未来方向

“Lost-in-the-Middle Countermeasure”只是优化RAG系统性能的一个方面。未来可以探索更多高级技术：

• 自适应重排序： 训练一个模型来预测哪些文档对特定查询最关键，并动态调整其在上下文中的位置。
• 结合其他长上下文技术： 将重新排列与递归摘要、多跳检索、查询扩展等技术结合，构建更强大的RAG管道。
• 学习型重排序： 不仅仅依靠启发式规则，而是通过强化学习或监督学习来优化文档的放置策略，以最大化LLM的性能。
• 多模态RAG： 在处理图像、视频等多模态内容时，如何有效地组织和呈现检索到的多模态信息，以避免“Lost in the Middle”问题。
• 个性化RAG： 根据用户偏好和历史交互，个性化检索结果和重新排列策略。

9. 赋能健壮的RAG系统，持续进化

“The Lost-in-the-Middle Countermeasure”是一个强大且相对简单的技术，能够有效缓解LLM在处理长上下文时存在的注意力偏见。通过在LangGraph中将其模块化地实现，我们能够构建出更加健壮、可控且高性能的RAG系统。

随着LLM能力和上下文窗口的不断演进，RAG与LLM的交互方式也在持续进化。理解并主动应对LLM的内在行为模式，将是我们构建下一代智能应用的关键所在。利用LangGraph的灵活性，我们可以不断试验和迭代，为用户提供更加精准、可靠的AI体验。