1. 项目概述：当RAG遇上“上下文饥渴症”

最近在折腾几个基于大语言模型的应用项目，从智能客服到文档分析，几乎都绕不开一个核心架构：检索增强生成。也就是大家常说的RAG。这东西听起来很美——模型记不住的海量知识，我通过外部检索给你“喂”进去，你就能对答如流了。但实际干过的人都知道，这里面的坑，一个比一个深。最让人头疼的，不是检索不准，也不是生成不好，而是你明明“喂”了文档，模型给出的答案却还是胡言乱语，或者干脆来一句“根据提供的信息，无法回答”。

问题出在哪？我花了大量时间排查、实验，最后发现症结往往不在模型本身，也不在检索系统的最顶层，而在于一个被严重低估的环节： 上下文是否真的“足够”了 。我们以为把相关文档片段塞进提示词就万事大吉，却忽略了模型对上下文的理解和利用，有着极其微妙和苛刻的要求。这个项目，就是我对“足够上下文”在RAG中扮演的核心角色的一次深度探索和实战总结。它不是关于如何搭建一个RAG系统，而是聚焦于如何让一个已经能跑的RAG系统，从“能用”变得“好用且可靠”。

简单来说，RAG的工作流可以概括为“检索-拼接-生成”。我们关注的重点通常是检索的召回率和排序精度，却容易假设“只要检索到的内容相关，拼接后模型就能用好”。但现实是， 相关不等于可用，片段不等于语境 。一个专业术语的解释、一个事件的前因后果、一组数据的对比关系，往往分散在文档的不同部分。只检索到其中一片，就像只给了拼图的一块，模型根本无法还原全貌，自然只能瞎猜或拒绝回答。因此，“足够的上下文”意味着提供给模型的文本片段，不仅要相关，更要 自洽、完整、富含逻辑关系 ，足以支撑模型进行安全的推理和生成。

这适合所有正在实施或优化RAG应用的朋友，无论是工程师、算法同学还是产品经理。如果你也困扰于RAG的答案质量不稳定、时好时坏，或者想在现有基础上把准确率提升一个台阶，那么关于“上下文充分性”的这些洞察和技巧，或许正是你需要的解药。

2. 核心困境解析：为什么“相关”不等于“足够”？

在深入技术细节之前，我们必须先厘清一个根本性的认知误区。在经典的RAG范式里，我们评估检索阶段成功与否的核心指标是“相关性”。无论是用嵌入模型计算向量相似度，还是用BM25进行关键词匹配，目标都是找到与用户问题最相关的文档块。这没错，但这是从“信息检索”视角出发的完美标准，却未必是“语言模型生成”视角的充分条件。

2.1 模型视角下的“信息缺口”

语言模型，尤其是大语言模型，本质上是一个基于概率的序列生成器。它在生成每一个词时，都会极度依赖其上下文窗口内已出现的所有文本。当我们将一个检索到的文档片段作为上下文提供给模型时，模型会试图基于这个片段所构建的“微型世界”进行理解和推理。

问题在于，一个孤立的、从长篇文档中切割出来的片段，本身可能是不自洽的。我举个例子：假设用户问“某某产品的旗舰型号支持哪些独特功能？”。检索系统可能精准地找到了产品手册中描述“旗舰型号”的段落，里面罗列了功能A、B、C。看起来非常相关。但是，手册中可能在前文定义了“独特功能”特指“相较于标准版新增的功能”。而这个定义，并没有出现在检索到的“旗舰型号”段落里。对于模型来说，它看到了“功能A, B, C”，但无法判断它们是否属于“独特功能”。此时，模型面临选择：1. 冒险推断，直接列出A、B、C，但可能出错；2. 保守回答，表示信息不足。很多时候，模型会选择后者，或者更糟，进行“幻觉”生成，编造一个判断依据。

这就是“信息缺口”。检索到的片段本身，缺失了完成特定推理所必需的 前提、定义、背景或关联信息 。这些信息可能就在原文档中，但仅仅因为切割（Chunking）策略或检索排序的原因，没有被一同纳入上下文窗口。

2.2 检索系统的“碎片化”供给与模型的“整体性”需求矛盾

这是另一个结构性矛盾。为了效率和精度，现代检索系统通常不会将整篇文档扔给模型。而是先将文档切割成较小的块（比如512或1024个token的片段），然后检索最相关的几个块。这种“碎片化”供给方式，直接破坏了文档固有的整体结构。

• 叙事逻辑断裂 ：一个问题的答案可能需要“背景-冲突-解决-结果”的完整叙事链。检索可能只找到了“解决”部分，模型就无法理解这个解决方案的针对性和有效性。
• 指代消解失败 ：文档中大量使用“它”、“上述系统”、“后者”等指代词。当上下文只包含指代对象，而不包含被指代对象时，模型就会困惑。例如，片段里说“它采用了新型算法”，但“它”指的是什么？这个信息在前一个片段里。
• 对比与列举不全 ：当问题涉及“比较A和B的差异”或“列出所有选项”时，检索系统可能只返回了关于A的片段，或者只返回了部分选项的片段。模型无法给出完整答案。

因此，模型的“整体性”需求——它需要连贯的、结构化的信息来做出可靠判断——与检索系统提供的“碎片化”供给之间，存在天然的张力。所谓的“足够上下文”，就是要设法缓解这种张力，在碎片中重建整体性。

注意 ：这里说的“整体性”不是指返回整篇文档，而是指提供的多个片段之间，以及片段与问题之间，能形成逻辑闭环，没有关键信息缺失。

2.3 量化“不足”带来的成本：幻觉、拒绝与不一致

上下文不足的直接后果，会体现在生成质量的三个维度上，这些都可以被量化观测：

1. 幻觉率上升 ：当模型无法从上下文中找到确凿依据，但又被迫或被引导生成答案时，它编造信息的概率会大幅增加。我们可以通过设计“仅基于上下文可回答”的测试集，来统计模型生成内容中无法在上下文中找到支持的比例。
2. 拒绝回答率上升 ：对于经过对齐训练、比较保守的模型（如GPT-4、Claude等），当它们感知到上下文信息不足时，倾向于直接拒绝回答，或给出“信息不足”的通用回复。这会严重影响用户体验和系统可用性。
3. 答案不一致 ：对于同一个问题，如果检索到的上下文片段组合每次略有不同（由于向量搜索的近似性），模型可能会给出截然不同的答案。这种不一致性在严肃应用中是不可接受的。

理解这些困境，是我们优化RAG系统、追求“足够上下文”的起点。接下来，我们就拆解如何从系统设计层面应对这些挑战。

3. 构建“足够上下文”的核心策略与架构设计

要让上下文“足够”，不能只靠运气，需要在RAG流水线的多个环节进行有意识的设计和干预。这不仅仅是一个算法问题，更是一个系统工程问题。

3.1 策略一：面向生成的智能文档切割

文档切割是RAG的起点，也是决定上下文质量上限的关键。传统的切割方法（固定长度、重叠滑动窗口）只考虑了存储和检索效率，完全忽视了语义完整性。

改进方案：语义切割

• 原理 ：利用文本的天然结构（如标题、段落）和语义边界（如句子结束、话题转换）进行切割。可以使用NLP工具识别文档结构，确保每个切割块在语义上尽可能自包含。
• 操作 ：对于技术文档，可以按“章节-子章节”切割；对于会议纪要，可以按“议题”切割；对于长篇文章，可以按“叙事段落”切割。同时，可以辅以嵌入模型，计算句子间的语义相似度，在相似度骤降处进行切割。
• 工具参考 ：可以使用 langchain 的 RecursiveCharacterTextSplitter 并自定义分隔符优先级，或者使用 semantic-text-splitter 这类更高级的库。

进阶方案：层次化切割与索引

• 原理 ：不仅存储小片段，同时存储其上一级的“父片段”（如所在段落或章节）的摘要或关键信息。在检索时，可以联动检索。
• 操作 ：建立两级索引。一级索引是细粒度片段，用于精准匹配问题。二级索引是粗粒度主题块。当检索到细粒度片段时，可以将其所属的粗粒度主题块信息作为“背景板”一同送入模型。这相当于为碎片补充了它所在的“地图”。

3.2 策略二：检索阶段的上下文扩展

在检索到最相关的核心片段后，不急于将其送入生成器，而是先以其为锚点，进行上下文扩展。

1. 父文档检索 这是最简单有效的方法。当检索系统返回一个文档片段（子块）时，自动将该片段所属的整个原始文档（或文档中一个较大的逻辑部分，如章节）也作为候选上下文。然后，可以从这个更大的范围里，再提取与问题相关的其他部分。这能有效解决指代消解和叙事断裂问题。

2. 关联片段检索 以核心检索片段为中心，在其向量空间中，寻找与其语义最接近的其他片段。这些片段可能来自同一文档的不同部分，也可能来自不同文档。它们的作用是补充核心片段缺失的视角、细节或前提条件。例如，核心片段在描述一个“结果”，关联片段可以补充其“原因”。

3. 图检索增强 对于知识结构复杂的领域（如医疗、法律），可以预先构建知识图谱。当检索到文本片段时，通过实体链接技术识别片段中的关键实体，然后在知识图谱中查询这些实体的邻居节点和关系，将这些图谱信息以文本形式（如“实体A是实体B的一种，其特性包括...”）补充到上下文中。这为模型提供了深度的领域知识和关系网络。

3.3 策略三：上下文压缩与精炼

无限制地扩展上下文会导致新的问题：噪声引入和核心信息被稀释。更长的上下文也会消耗更多token，增加成本并可能分散模型的注意力。因此，在扩展之后，往往需要压缩和精炼。

1. 提取式摘要 对扩展后的大段上下文，使用一个较小的、专门训练的提取式摘要模型（或提示大模型本身），提取出与用户问题最直接相关的句子或关键事实。保留原始文本的措辞，避免引入摘要模型的幻觉。

2. 基于问题的重排序与过滤 不是所有扩展来的上下文都同等重要。可以使用一个轻量级的交叉编码器模型，对候选上下文片段列表进行重排序。这个交叉编码器同时编码问题和每个片段，直接计算它们的相关分数，比单纯的向量相似度更精准。然后，只保留Top-K个最相关的片段。

3. 元数据过滤 在文档切割时，就为每个片段打上丰富的元数据标签，如“包含定义”、“包含步骤”、“包含数据表格”、“属于背景介绍”等。在检索后，可以根据问题的类型，动态选择包含特定元数据标签的片段。例如，对于“如何操作”类问题，优先保留“包含步骤”的片段。

通过“扩展-压缩”这个动态过程，我们旨在为模型提供一个 既全面又聚焦 的上下文环境。全面，确保了关键信息不缺失；聚焦，确保了模型注意力不被无关信息干扰。

4. 系统实现与关键参数调优

理论需要落地。下面我将以一个基于开源栈的简化RAG系统为例，展示如何实现上述策略，并讨论几个关键参数的调优心得。

系统组件假设 ：

• 嵌入模型： BAAI/bge-large-zh-v1.5 (中文场景优秀)
• 向量数据库： Chroma (轻量易用)
• LLM： GPT-3.5-Turbo (或任何你熟悉的API模型)
• 框架： LangChain (用于快速编排)

4.1 实现智能切割与层次化索引

from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.vectorstores import Chroma
from langchain.embeddings import HuggingFaceEmbeddings
import json

# 1. 语义切割（尝试按段落和标点优先）
text_splitter = RecursiveCharacterTextSplitter(
    separators=["\n\n", "\n", "。", "！", "？", "；", "，", "、", " "], # 中文分隔符优先级
    chunk_size=500,  # 目标块大小
    chunk_overlap=80, # 重叠部分，避免在句子中间切断
    length_function=len,
)

documents = [...] # 你的原始文档列表
all_splits = text_splitter.split_documents(documents)

# 2. 为每个split添加元数据和父级信息
for i, split in enumerate(all_splits):
    # 假设documents有metadata记录来源文件、章节等
    split.metadata.update({
        "chunk_id": i,
        "parent_section": split.metadata.get("chapter", "unknown"), # 记录父章节
        "content_type": classify_content_type(split.page_content) # 自定义函数，判断内容类型（如“定义”、“步骤”、“案例”）
    })

# 3. 创建向量库（索引细粒度片段）
embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-large-zh-v1.5")
vectorstore = Chroma.from_documents(documents=all_splits, embedding=embeddings)

# 4. （可选）创建第二个“父级”向量库，索引章节摘要或标题
parent_summaries = generate_parent_summaries(all_splits) # 自定义函数，生成父级摘要
parent_vectorstore = Chroma.from_texts(texts=parent_summaries, embedding=embeddings, metadatas=[...])

关键参数调优心得 ：

• chunk_size ：这是最重要的参数。太小则信息碎片化，太大则检索精度下降且可能超过模型上下文窗口。我的经验是，对于事实性问答，250-500 token的块是不错的起点；对于需要推理的复杂问题，可以尝试500-800 token。 必须用你的实际数据做AB测试 ，评估不同尺寸下检索召回率和答案准确率。
• chunk_overlap ：重叠是为了防止关键信息恰好被切在边界而丢失。通常设置为 chunk_size 的10%-20%。但注意，重叠部分在检索时可能被重复计算，略微增加噪声。对于结构清晰的文档（如API文档），可以减小重叠；对于散文或连续叙述，需要较大重叠。
• 分隔符优先级 ： RecursiveCharacterTextSplitter 会按你提供的 separators 列表顺序尝试切割。把“\n\n”（空行）放在最前面，能很好地保持段落完整性，这对语义连贯性至关重要。

4.2 实现检索时上下文扩展

from langchain.retrievers import ContextualCompressionRetriever
from langchain.retrievers.document_compressors import LLMChainExtractor
from langchain.chat_models import ChatOpenAI
from langchain.retrievers import EnsembleRetriever
from langchain.vectorstores import Chroma

# 1. 基础向量检索器
base_retriever = vectorstore.as_retriever(search_kwargs={"k": 7}) # 初始多检索一些

# 2. 父文档检索器（模拟实现）
class ParentDocumentRetriever:
    def __init__(self, child_retriever, parent_vectorstore):
        self.child_retriever = child_retriever
        self.parent_vectorstore = parent_vectorstore

    def get_relevant_documents(self, query):
        # 第一步：用子检索器找到最相关的细粒度片段
        child_docs = self.child_retriever.get_relevant_documents(query)
        relevant_parent_ids = set()
        expanded_docs = []

        for doc in child_docs:
            # 获取该片段的父级ID（假设存储在metadata中）
            parent_id = doc.metadata.get("parent_section_id")
            if parent_id and parent_id not in relevant_parent_ids:
                # 从父级向量库或存储中，获取整个父级文档内容
                parent_doc = retrieve_parent_by_id(parent_id) # 自定义函数
                if parent_doc:
                    expanded_docs.append(parent_doc)
                    relevant_parent_ids.add(parent_id)
            expanded_docs.append(doc) # 也保留原始子片段
        # 对expanded_docs去重（基于内容哈希）
        return remove_duplicate_documents(expanded_docs)

# 3. 组合检索器（Ensemble）
parent_retriever = ParentDocumentRetriever(base_retriever, parent_vectorstore)
# 可以组合多个检索器，如关键词检索（BM25）
ensemble_retriever = EnsembleRetriever(retrievers=[base_retriever, parent_retriever], weights=[0.7, 0.3])

# 4. 上下文压缩（使用LLM进行提取式摘要）
llm = ChatOpenAI(temperature=0, model="gpt-3.5-turbo")
compressor = LLMChainExtractor.from_llm(llm)
compression_retriever = ContextualCompressionRetriever(base_compressor=compressor, base_retriever=ensemble_retriever)

关键操作解析 ：

• search_kwargs={“k”: 7} ：初始检索数量 k 值得仔细权衡。太小可能漏掉关键片段，太大则引入噪声且增加后续处理成本。建议从5-10开始，根据答案质量调整。如果你的扩展策略强，可以适当减小 k ；如果依赖后续压缩，可以稍大。
• Ensemble权重 ： weights=[0.7, 0.3] 表示我更信任基础向量检索的结果，父文档检索作为补充。这个权重需要根据你的数据特性调整。如果文档结构性强、章节独立，可以提高父文档检索的权重。
• LLMChainExtractor ：这是一个强大的压缩器，它使用LLM来读取原始查询和检索到的文档，然后 从文档中逐字提取 与问题相关的句子。它不会改写或总结，只是做筛选，因此几乎不会引入幻觉。但它的缺点是会增加LLM的调用次数和延迟。

4.3 提示词工程：引导模型关注“足够上下文”

即使提供了优质的上下文，也需要通过提示词告诉模型如何利用它。一个糟糕的提示词会让所有前期努力白费。

基础但关键的提示词模板 ：

你是一个专业的问答助手，将严格根据以下提供的“参考上下文”来回答问题。
如果答案没有明确地、完整地包含在上下文中，请直接回答“根据提供的上下文，我无法回答这个问题”。不要编造任何信息。

参考上下文：

{context}

用户问题：{question}

请基于且仅基于上述参考上下文回答：

进阶技巧 ：

1. 指令位置 ：将“严格根据上下文”的指令放在最前面，比放在后面效果更好，更能影响模型的初始行为设定。
2. 明确禁忌 ：直接说“不要编造任何信息”比说“请避免幻觉”更有效，指令更具体。
3. 格式化上下文 ：使用```分隔符将上下文包裹起来，视觉上将其与指令和问题区分开，有助于模型将其识别为独立的输入源。
4. 指定输出格式 ：对于无法回答的情况，明确给出回复句式，这能极大提高回复的一致性。
5. 添加上下文元信息 ：在上下文中每个片段前，可以添加简短来源提示，如 [来自用户手册-安全章节] 。这不仅能增加可信度，有时也能微妙地提示模型该片段的重要性或领域。

一个更精细的模板示例 ：

你是一个严谨的分析师。你的任务是根据我提供的“证据材料”来回答“用户疑问”。
证据材料来自多个文档片段，每个片段开头标有其来源。你的回答必须完全扎根于这些证据材料。
如果证据材料中没有足够信息来构成一个完整的答案，你必须说：“根据现有证据，无法得出确定结论。”
禁止结合外部知识，禁止进行证据材料之外的推测。

证据材料开始：
---
[来源：产品规格书-v2.1] {text_chunk_1}
---
[来源：技术白皮书-第三章] {text_chunk_2}
---
... (更多片段)
证据材料结束。

用户疑问：{question}

基于证据材料的分析：

这种“角色扮演+证据框架”的提示词，能进一步约束模型行为，使其更倾向于做一个被动的、基于证据的“提取者”和“组织者”，而非主动的“创造者”。

5. 评估、监控与持续迭代

构建一个具备“足够上下文”感知能力的RAG系统不是一劳永逸的。你需要建立评估和监控机制，持续迭代优化。

5.1 如何评估上下文是否“足够”？

除了最终答案的准确性，我们还需要更细粒度的评估指标来诊断上下文问题：

1. 上下文相关性评分 ：对于每个问答对，人工或使用高级模型（如GPT-4）评估检索到的上下文片段与问题的直接相关程度。这能帮你判断检索阶段是否找到了“对”的材料。
2. 上下文支持度评分 ：评估生成的答案中，每一句关键主张是否都能在提供的上下文中找到明确的文字支持。这能直接反映模型是否“用好了”上下文。
3. 幻觉检测 ：使用专门的幻觉检测模型或规则，识别答案中是否存在上下文未提及的信息。高幻觉率通常指向上下文不足或模型未能遵循指令。
4. 拒绝回答分析 ：统计系统拒绝回答的比例，并分析这些被拒绝的问题。它们的上下文有什么共同特征？是碎片化太严重，还是缺乏核心定义？

5.2 构建测试集与回归测试

• 构建领域特定的测试集 ：不要只用通用基准。从你的真实用户日志中采样问题，并人工标注标准答案和所需的上下文范围。这个测试集应包含：
  • “易答问题”：答案明确集中在单个片段中的。
  • “需综合问题”：答案需要拼接多个片段信息的。
  • “需推理问题”：答案需要基于上下文进行简单逻辑推理的。
  • “边界问题”：上下文部分相关但不足以完全回答的。
  • “无法回答问题”：上下文完全不相关的。
• 实施回归测试 ：任何对切割策略、检索参数、提示词的修改，都必须在这个测试集上重新运行，监控各项指标的变化。确保优化不会在某一类问题上提升，而在另一类问题上倒退。

5.3 线上监控与反馈闭环

• 日志记录关键数据 ：在线上系统日志中，不仅记录用户问题和最终答案，还要记录：
  • 检索到的所有片段及其来源、相关性分数。
  • 最终送入模型的上下文内容（压缩后）。
  • 模型的原始输出（在后续格式化或过滤之前）。
• 设计用户反馈机制 ：提供“答案是否有用？”的反馈按钮。将用户点“无用”的案例自动收集到待审查队列。
• 定期人工审查 ：每周抽样审查失败案例（用户反馈“无用”或高置信度但被检测为幻觉的答案）。人工分析根本原因：是检索遗漏？切割不当？上下文不完整？还是提示词问题？根据分析结果，定向优化你的系统。

5.4 迭代优化循环

基于评估和监控，形成一个持续的优化循环：

1. 发现问题 ：通过测试集或线上反馈，定位某一类问题（如“比较类问题”回答差）。
2. 根因分析 ：检查这类问题的检索上下文，发现往往是只检索到了比较对象A的信息，缺失了对象B的信息。
3. 策略调整 ：针对“比较类问题”，在检索后增加一个步骤：识别问题中的比较实体，主动检索每个实体的核心信息片段进行组合。
4. 实验验证 ：在测试集的“比较类问题”子集上验证优化效果。
5. 上线与监控 ：将优化部署到线上，并密切监控相关指标和用户反馈。

这个循环的核心思想是： “足够上下文”是一个动态的、相对于问题类型而言的概念 。不存在一个放之四海而皆准的“完美”上下文配置。最好的系统是能够洞察自身不足，并针对不同问题模式进行自适应调整的系统。

6. 常见陷阱与实战避坑指南

在追求“足够上下文”的路上，我踩过不少坑。这里分享一些典型的陷阱和应对策略，希望能帮你节省时间。

陷阱一：盲目追求更长的上下文窗口

• 现象 ：听说新模型支持128K上下文了，立刻把所有文档不分青红皂白地塞进去。
• 问题 ：模型对长上下文的“注意力”是有限的，关键信息如果被淹没在大量无关文本中，效果反而更差。同时，成本急剧上升。
• 对策 ：长上下文是工具，不是目的。它最适合用于需要引用文档中多个分散部分的长篇分析任务。对于大多数事实性问答，精心检索和压缩后的短上下文效果更好、更经济。 始终优先做检索和压缩，把长上下文当作最后的安全网，而不是首选方案。

陷阱二：过度依赖向量相似度

• 现象 ：检索只靠嵌入模型计算余弦相似度，对于措辞差异大但语义相同的问题（如“怎么开机？”和“启动步骤是什么？”），可能召回率不高。
• 对策 ：采用混合检索。结合 稀疏检索 （如BM25，擅长关键词精确匹配）和 密集检索 （向量模型，擅长语义匹配）。 EnsembleRetriever 可以轻松将两者结合。对于专业领域，还可以加入基于知识图谱的检索。

陷阱三：忽略文档的预处理质量

• 现象 ：PDF解析后格式混乱，表格变成乱码，图片中的文字全部丢失。
• 问题 ：垃圾进，垃圾出。糟糕的预处理会污染你的向量库，检索到的片段本身信息就是残缺或错误的。
• 对策 ：投资一个强大的文档解析管道。使用专门的工具处理不同格式（如 pdfplumber 、 pymupdf 处理PDF， unstructured 库处理多种格式）。对于表格，尽量保留其结构化表示（如Markdown表格）；对于图片，使用OCR（如 paddleocr 、 Tesseract ）提取文字，并将“图注”文字与图片内容关联存储。

陷阱四：提示词过于简单或模糊

• 现象 ：只写“请根据下文回答问题”，模型经常自由发挥。
• 对策 ：如第4.3节所述，使用强约束性、角色明确的提示词。明确指令模型的行为边界。 将“禁止幻觉”作为一条铁律写在提示词里，并明确无法回答时的输出格式。

陷阱五：没有评估体系，盲目调参

• 现象 ：跟着感觉调整 chunk_size 或 top_k ，不知道是好是坏。
• 对策 ：立即着手构建第5节提到的评估测试集。哪怕只有50-100个精心标注的样本，也能为你提供宝贵的优化方向。没有数据驱动的优化，就像在黑暗中射击。

陷阱六：认为RAG是万能的

• 现象 ：试图用RAG解决所有知识性问题，包括需要复杂逻辑推理、数学计算或高度创造性综合的问题。
• 现实 ：RAG的核心是“记忆扩展”，不是“智能创造”。它擅长基于已有文本的查询和重组。对于需要深度推理、计算或多步规划的问题，可能需要将RAG与思维链、程序调用等技术结合。
• 对策 ：清晰定义你系统的能力边界。对于边界之外的问题，设计优雅的降级或引导策略，例如告知用户“这个问题需要更复杂的分析，目前我主要擅长基于文档的查询”。

追求“足够上下文”的本质，是让RAG系统从简单的“文档查找”升级为“信息缝合”。这要求我们以终为始，从模型生成的需求出发，反向设计我们的检索、加工和提供信息的流程。这个过程没有银弹，需要的是对数据、对问题、对模型行为的持续观察和细致调优。当你发现你的RAG系统开始能稳定地给出“有据可查”的答案时，你就会知道，在上下文充分性上花的每一分功夫，都是值得的。