PyLLM

主题

响应合成的核心挑战与设计理念 ​

在 RAG 管道中，检索阶段负责"找到相关内容"，而响应合成（Response Synthesis）阶段负责把这些内容变成人类可读的自然语言答案。听起来很简单——不就是让 LLM 读一下检索到的文字然后总结一下吗？

但如果你真正在生产环境中使用过 RAG 系统，就会发现响应合成远比表面看起来复杂得多。检索到的内容可能是：

  • 不完整的——答案分散在多个 Node 中，每个只包含一部分信息
  • 有冲突的——不同 Node 对同一件事说法不一致
  • 有噪音的——混入了不太相关的内容
  • 超长的——所有 Node 拼接起来可能超过 LLM 的上下文窗口
  • 格式混乱的——包含表格、代码块、列表等混合格式
  • 缺少上下文的——某个 Node 中提到"该产品"，但没说"该产品"具体是什么

响应合成的任务就是在这样充满挑战的输入条件下，生成一个准确、完整、连贯、有用的答案。这一节我们从问题出发，理解响应合成面临的核心挑战和 LlamaIndex 的设计理念。

一个典型的失败案例 ​

让我们先看一个响应合成做得不好的例子，感受一下问题的严重性：

用户查询: "S1 的退货政策是什么？"

检索到的 5 个 Node:
[1] score=0.92 | "公司提供30天无理由退款服务..."
[2] score=0.89 | "登录账户进入订单管理页面，点击申请退款..."
[3] score=0.85 | "定制产品不适用无理由退款政策..."
[4] score=0.82 | "S2 产品的退款流程为：联系客服获取RMA号..."
[5] score=0.78 | "退款将在3-5个工作日内原路退回..."

糟糕的合成结果:
"根据文档信息，公司提供30天无理由退款服务。
 S2 产品的退款流程为联系客服获取RMA号。
 退款将在3-5个工作日内退回。
 登录账户可以申请退款。"

这个答案有三个明显的问题：

问题一：产品混淆。 用户问的是 S1，但答案中混入了 S2 的信息（Node #4 是关于 S2 的，被错误地纳入了答案）。这是因为简单的拼接方式无法区分不同产品的信息。

问题二：关键遗漏。 Node #3 提到"定制产品不适用无理由退款"这个重要例外条件，但最终答案中完全没有提及。用户如果买了定制版产品按这个答案去申请退款会被拒绝。

问题三：逻辑断裂。 各个信息点之间没有过渡和关联，读起来像是几段无关文字的拼凑。

一个好的合成结果应该是这样的：

"S1 产品支持 30 天无理由退款服务（从签收之日起计算）。
 具体操作流程为：登录您的账户 → 进入'我的订单'页面 →
 点击对应订单的'申请退款'按钮 → 选择退款原因并提交审核。

 需要注意的是：定制类产品（如刻字、特殊配色等）
 不适用于此无理由退款政策。如有疑问请联系客服确认。

 审核通过后，退款将在 3-5 个工作日内原路退回至
 您的支付账户。"

对比之下，好的合成结果做到了：准确区分了产品（只谈 S1）、包含了例外情况、操作步骤清晰有序、各部分之间有逻辑衔接。

核心挑战分析 ​

挑战一：信息整合 ​

这是最根本的挑战。检索返回的 N 个 Node 就像 N 块拼图的碎片——你需要把它们正确地组合成一幅完整的画面。但问题是：

  • 有些碎片是多余的（重复内容）
  • 有些碎片是干扰的（不相关信息）
  • 有些碎片的边缘模糊（被截断的半句话）
  • 碎片之间的顺序不确定（检索排序 ≠ 逻辑阅读顺序）

挑战二：上下文窗口限制 ​

LLM 的上下文窗口是有限的（GPT-4o-mini 为 128K tokens，但实际有效利用通常在 4K-16K）。当你检索到 20 个 Node，每个平均 500 字符时，原始文本就约 10,000 字符（~2500-4000 tokens），再加上 Prompt 模板和对话历史，很容易逼近或超过限制。

这意味着 Synthesizer 必须做出取舍：哪些信息应该保留？哪些可以省略？如何用最少的 token 传达最多的有效信息？

挑战三：忠实度 vs 可读性 ​

这里有一个微妙的权衡：

  • 高忠实度：严格基于检索到的内容回答，不添加任何外部知识 → 可能生硬、片段化
  • 高可读性：流畅自然、像人写的 → 可能引入幻觉（LLM 用自己的知识"填补"了文档中没有的信息）

理想的状态是在两者之间找到平衡——既严格基于检索内容，又组织得流畅易读。

挑战四：引用准确性 ​

用户不仅想要答案，还想知道"你说的这些是从哪来的"。但自动生成的引用并不总是准确的——LLM 可能把 Node A 中的信息放在了引用 Node B 后面，或者把多个 Node 的内容混在一起后却只引用了一个来源。

LlamaIndex 的设计哲学 ​

面对上述挑战，LlamaIndex 的 Response Synthesizer 采用了以下设计原则：

原则一：多种策略，按需选择。 不存在一种"最好"的合成方式——不同的场景需要不同的策略。LlamaIndex 提供了 4 种内置模式（第七章会详细讲解），每种针对不同的 Node 数量、查询类型和质量要求做了优化。

原则二：可插拔可替换。 Synthesizer 和 Retriever 一样，是一个独立的、可替换的组件。你可以使用内置的，也可以完全自定义——包括 Prompt 模板、调用逻辑、输出格式等一切方面。

原则三：透明可调试。 Synthesizer 的执行过程可以通过 verbose=True 来观察，每一步的输入输出都清晰可见。这让你能够精确定位问题出在哪个环节。

原则四：保留溯源信息。 无论采用哪种合成模式，最终的 Response 对象始终携带 source_nodes 信息——确保用户总能追溯到答案的数据来源。

Synthesizer 在架构中的位置 ​

回顾整体架构：

Query Engine 内部:
┌──────────────┐     ┌──────────────────────┐
│  Retriever   │ ──▶ │  Postprocessor       │
│  (找到候选)   │     │  (过滤/重排/去重)      │
└──────────────┘     └──────────┬───────────┘
                                │
                       最终 Node 列表
                                │
                                ▼
              ┌─────────────────────────────┐
              │    Response Synthesizer      │
              │                             │
              │  接收: Query + Nodes          │
              │  处理: 选择合成策略            │
              │        组织 Prompt            │
              │        调用 LLM                │
              │        格式化输出             │
              │                             │
              │  输出: Response 对象           │
              │    - response (答案文本)       │
              │    - source_nodes (来源)      │
              │    - metadata (元数据)         │
              └─────────────────────────────┘

Synthesizer 是 RAG 管道的最后一公里——它之前所有的努力（数据加载、解析、索引、检索、后处理）最终都要通过它转化为用户可见的价值。如果 Synthesizer 出了问题，前面所有环节的工作都会大打折扣。

四种内置合成模式预览 ​

LlamaIndex 内置了四种主要的响应合成模式：

模式思路适用场景Node 数量
REFINE迭代精炼需要综合多源信息的复杂问答中等 (<20)
COMPACT_ACCUMULATE压缩后精炼Node 数量不确定时自适应任意
TREE_SUMMARIZE树状汇总大量 Node 需要结构化总结多 (>15)
SIMPLE_SUMMARIZE一次生成快速、简单场景少 (<5)

下一节我们会深入每一种模式的内部机制、Prompt 结构、优缺点和最佳实践。

自定义 Synthesizer 的基本形态 ​

虽然四种内置模式覆盖了大多数需求，但你可能仍然需要自定义 Synthesizer。以下是基本的实现框架：

python
from llama_index.core.response_synthesizers import BaseResponseSynthesizer
from llama_index.core import Response
from typing import Sequence
from llama_index.core.schema import TextNode, QueryBundle


class MyCustomSynthesizer(BaseResponseSynthesizer):
    def __init__(self, llm=None, **kwargs):
        super().__init__(**kwargs)
        self.llm = llm or Settings.llm

    def synthesize(
        self,
        query: str,
        nodes: Sequence[TextNode],
        **kwargs,
    ) -> Response:
        # Step 1: 准备上下文（你的自定义逻辑）
        context = self._build_context(nodes)

        # Step 2: 构建 Prompt（你的自定义模板）
        prompt = self._build_prompt(query, context)

        # Step 3: 调用 LLM
        response_text = self.llm.complete(prompt).text

        # Step 4: 构建并返回 Response 对象
        return Response(
            response=response_text,
            source_nodes=[
                NodeWithScore(node=n, score=n.get_score())
                for n in nodes
            ],
        )

    def _build_context(self, nodes):
        """自定义的上下文组装逻辑"""
        parts = []
        for i, node in enumerate(nodes, 1):
            parts.append(f"[资料 {i}] {node.text}")
        return "\n\n".join(parts)

    def _build_prompt(self, query, context):
        """自定义的 Prompt 模板"""
        return (
            f"请基于以下参考资料回答问题。\n\n"
            f"参考资料:\n{context}\n\n"
            f"问题: {query}\n\n"
            f"要求:\n"
            f"- 只使用参考资料中的信息\n"
            f"- 如果信息不足，明确说明\n"
            f"- 以清晰的结构组织答案\n"
        )

这个骨架展示了自定义 Synthesizer 的最小必要结构。实际项目中你可能还需要处理流式输出、异步调用、错误重试等细节。

常见误区 ​

误区一:"合成就是把检索结果塞给 LLM"。 这是最简化的理解。好的合成需要考虑：哪些信息是核心的、哪些是补充的、信息之间的逻辑关系是什么、如何组织才能既完整又简洁、如何避免幻觉……这些都是 Synthesizer 要解决的问题，而不是简单地把文本传给 LLM。

误区二:"REFINE 模式总是最好的选择。" 不是的。REFINE 在 Node 数量适中（5-20个）且需要深度综合时效果最好。但对于只有 2-3 个 Node 的简单查询，SIMPLE_SUMMARIZE 更快且效果相当；对于超过 30 个 Node 的大规模查询，TREE_SUMMARIZE 更能发挥优势。根据实际场景选择合适的模式。

误区三:"合成质量只取决于 LLM 的能力。" LLM 能力固然重要，但 Synthesizer 的设计同样关键——包括 Prompt 模板的质量、上下文的组织方式、迭代策略的选择等。同样的 LLM，配合精心设计的 Synthesizer 和粗糙的默认配置，效果可能有天壤之别。

基于 MIT 许可发布

版权所有 © 2024-至今