1. 项目概述当长文档遇上大模型我们到底在解决什么如果你尝试过让 Claude 或 GPT-4 去处理一份上百页的 PDF 技术手册、一份冗长的法律合同或者一个包含数万行代码的 GitHub 仓库你大概率会遇到一个令人沮丧的提示“上下文长度超出限制”。即便你使用的模型支持超长上下文比如 128K 甚至 200K tokens结果也常常不尽人意模型要么“忘记”了文档中间的关键细节要么在回答时混淆了不同章节的信息甚至干脆生成一些看似合理但与文档内容无关的“幻觉”答案。这背后的核心矛盾在于大语言模型LLM的“有效上下文窗口”远小于其“名义上下文窗口”。简单来说模型虽然能“吃下”很长的文本但真正能用来做精准推理和生成的部分却非常有限。这就是 SAGESelective Attention-Guided Context Compression框架要解决的核心痛点。它不是一个全新的模型而是一个精巧的、基于注意力机制原理的“预处理”框架。你可以把它想象成一位拥有“火眼金睛”的超级助理。当面对一部长篇大论时这位助理不会笨拙地从头读到尾再试图回忆所有内容来回答你的问题。相反他会根据你的具体问题Query快速扫描整个文档识别出哪些段落、句子甚至词汇是与问题最相关的“精华”然后将这些精华部分连同问题本身打包成一个简短的、高信息密度的“摘要包”最后再交给 LLM 去处理。这个过程的精妙之处完全在于“注意力引导”。我们借鉴了 Transformer 模型中核心的“自注意力”和“交叉注意力”机制的思想。在 SAGE 中文档的每个片段比如一个段落或一个句子都会与用户的问题进行一次“注意力评分”这个评分决定了该片段对于回答当前问题的重要性。通过这种方式我们实现了动态的、与问题强相关的上下文压缩而不是简单的截断、抽取式摘要或随机采样。最终目标是用尽可能少的 tokens携带尽可能多的、与任务相关的信息从而在有限的上下文窗口内显著提升长文档问答的准确性、相关性和效率。2. SAGE 核心设计思路注意力机制如何成为“信息滤网”要理解 SAGE我们必须先抛开那些复杂的数学公式从直觉上把握“注意力”在信息处理中的角色。想象一下你在嘈杂的咖啡厅里和朋友聊天。你的耳朵会接收到各种声音朋友的谈话、咖啡机的蒸汽声、别人的笑声、背景音乐。但你大脑的“注意力机制”会自动聚焦于朋友的声音抑制其他噪音。Transformer 中的注意力机制干的是类似的事情它决定在处理某个词时应该“关注”输入序列中的哪些其他词。SAGE 将这个思想应用在了文档压缩层面。其核心设计可以分解为三个层次2.1 从“静态压缩”到“动态查询感知压缩”传统处理长文档的方法可以称为“静态压缩”截断Truncation直接砍掉超出部分。简单粗暴但会丢失关键信息尤其是当关键信息在文档尾部时。滑动窗口Sliding Window将长文档切成重叠的小块分别提问再整合答案。成本高昂多次 API 调用且容易丢失跨窗口的全局关联。概括摘要Summarization先让模型为整个文档生成一个摘要再用摘要来问答。问题在于摘要的生成是“通用”的可能丢失了你特定问题所需的细节。比如一份产品手册的通用摘要可能不会包含某个特定错误代码的详细解决步骤。SAGE 采用的是“动态查询感知压缩”。它的压缩策略不是事先决定的而是完全由用户的实际问题Query动态驱动。对于同一个长文档你问“总结第三章的主要内容”和问“第五章第四节提到的那个公式是如何推导的”SAGE 为你筛选和压缩出的上下文片段将是完全不同的。这就像给你的问题配了一把特制的钥匙只打开文档中与之最匹配的那些锁。2.2 注意力评分量化“相关性”的尺子那么如何实现这种动态筛选呢关键在于计算文档中每个“文本块”Chunk与用户问题的“注意力分数”。这个过程通常分为两步向量化表示首先利用一个嵌入模型Embedding Model将用户的问题Q和文档的每一个文本块C_i分别转换为高维空间中的向量即 embeddings。这个模型可以是专门训练过的也可以直接使用 OpenAI 的text-embedding-ada-002、Cohere 的 Embed 模型或开源的BGE、GTE等。相似度计算然后计算问题向量与每一个文本块向量之间的相似度。最常用的方法是余弦相似度Cosine Similarity。得分越高意味着该文本块与问题的语义相关性越强。注意这里存在一个重要的工程权衡。使用大型、高精度的嵌入模型如text-embedding-3-large能得到更准确的相似度判断但计算成本也更高。对于超长文档如百万字级别需要权衡速度和精度。在实践中对于大多数百页以内的文档使用一个中等规模的嵌入模型已经能取得很好的效果。2.3 选择性聚合构建高密度上下文拿到所有文本块的注意力分数后SAGE 并不是简单地把得分最高的前 N 个块堆叠起来。它采用了一种更智能的“选择性聚合”策略阈值过滤设定一个相关性阈值。只有分数超过该阈值的文本块才会被选中。这避免了纳入大量无关的“噪音”。多样性控制为了避免选中的全是表达同一意思的重复段落可以引入 MMRMaximal Marginal Relevance等算法在保证相关性的同时增加所选内容的多样性。结构保留在聚合时会尽量保持被选中文本块在原始文档中的相对顺序这有助于 LLM 理解信息的逻辑流。长度约束最终聚合的所有文本块总长度必须符合目标 LLM 的上下文窗口限制需预留问题本身和系统指令的空间。最终输出的是一个由高相关性文本块有序拼接而成的“压缩上下文”。这个上下文直接替代原始长文档与用户问题一起构成给 LLM 的最终提示Prompt。3. 实操构建一步步实现你自己的 SAGE 管道理论说得再多不如动手搭一个。下面我将以一个具体的场景为例从一个长达 200 页的 Python 数据分析教程电子书中准确回答关于pandas高级索引MultiIndex的具体问题。我们将使用 Python 和一些主流开源库来构建一个简化版的 SAGE 流程。3.1 环境准备与工具选型首先明确我们的技术栈。核心任务包括文档加载与分块、文本向量化、相似度计算与筛选、以及最终调用 LLM。# 建议的依赖库 pip install langchain langchain-community pypdf2 chromadb sentence-transformers openai tiktoken工具选型解析langchain虽然我们不完全遵循其复杂的 Chain 设计但其提供的文档加载器PyPDFLoader、文本分割器RecursiveCharacterTextSplitter非常成熟好用能避免重复造轮子。sentence-transformers我们选用其开源的嵌入模型例如all-MiniLM-L6-v2。它体积小80MB速度快并且在语义相似度任务上表现相当不错完全足以胜任我们的任务。这避免了调用付费的 Embedding API便于本地部署和调试。chromadb或faiss用于高效存储和检索向量。这里我们为了简化先使用内存计算但实际生产环境中向量数据库对于管理海量文档块至关重要。LLM 接口我们将使用 OpenAI 的 GPT-3.5-Turbo 作为最后的问答模型。你也可以无缝替换为 Claude、国产的 Qwen 或通义千问的 API。3.2 文档加载与智能分块这是整个流程的基石分块的好坏直接影响后续检索的质量。切忌简单按固定字符数切割。from langchain.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 1. 加载文档 loader PyPDFLoader(“path/to/your/python_data_analysis_book.pdf”) raw_documents loader.load() # 2. 配置智能文本分割器 text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 每个块的最大字符数 chunk_overlap100, # 块之间的重叠字符数防止上下文断裂 separators[“\n\n”, “\n”, “.”, “,”, “ “, “”], # 按此优先级分割 length_functionlen, ) # 3. 执行分块 all_chunks text_splitter.split_documents(raw_documents) print(f“将 {len(raw_documents)} 页文档切分成了 {len(all_chunks)} 个文本块。”)实操心得分块参数的艺术chunk_size500是一个经验值。对于技术文档500-800 字符能较好地容纳一个完整的小概念如一个函数定义加一个例子。对于小说或叙述文可以适当增大到 1000-1500。chunk_overlap100至关重要。它确保了关键信息比如一个在块末尾被截断的专业术语定义能在下一个块的开头再次出现极大地提高了检索的召回率。我吃过亏没有重叠的分块经常导致检索到的片段缺少关键前提信息。优先使用\n\n作为分隔符能很好地保持“段落”的完整性。3.3 嵌入计算与相似度检索接下来我们为每个文本块计算向量并针对用户问题进行检索。from sentence_transformers import SentenceTransformer import numpy as np # 1. 加载嵌入模型 embedding_model SentenceTransformer(‘all-MiniLM-L6-v2’) # 2. 为所有文档块预计算嵌入向量可缓存以加速后续查询 print(“正在计算文档块嵌入向量这可能需要一些时间...”) chunk_texts [chunk.page_content for chunk in all_chunks] chunk_embeddings embedding_model.encode(chunk_texts, show_progress_barTrue, convert_to_numpyTrue) # 3. 处理用户查询 user_query “在 pandas 中如何使用 MultiIndex 进行多层数据筛选请给出示例代码。” # 4. 计算查询向量 query_embedding embedding_model.encode([user_query], convert_to_numpyTrue) # 5. 计算余弦相似度并排序 from sklearn.metrics.pairwise import cosine_similarity # 计算查询向量与所有文档块向量的相似度 similarities cosine_similarity(query_embedding, chunk_embeddings)[0] # 将相似度与文本块关联并按相似度降序排序 scored_chunks list(zip(all_chunks, similarities)) scored_chunks.sort(keylambda x: x[1], reverseTrue) # 按相似度得分降序排列 # 6. 选择性筛选设置阈值并控制总长度 top_k 10 # 最多考虑前10个最相关的块 relevance_threshold 0.25 # 经验阈值可根据任务调整 selected_chunks [] total_token_count 0 max_context_tokens 3000 # 为目标LLM预留的上下文token上限 for chunk, score in scored_chunks[:top_k]: if score relevance_threshold: break # 低于阈值的认为不相关停止收集 # 估算当前块的token数这里用简单字符数/4近似生产环境应用tiktoken精确计算 chunk_token_est len(chunk.page_content) // 4 if total_token_count chunk_token_est max_context_tokens: # 如果加上当前块会超出限制则停止 break selected_chunks.append(chunk) total_token_count chunk_token_est print(f“根据查询从 {len(all_chunks)} 个块中筛选出了 {len(selected_chunks)} 个相关块预估占用 {total_token_count} tokens。”)3.4 上下文组装与 LLM 问答将筛选出的高相关片段组装成最终的提示词。from langchain.schema import HumanMessage, SystemMessage from langchain.chat_models import ChatOpenAI import os # 1. 组装压缩后的上下文 compressed_context “\n\n---\n\n”.join([chunk.page_content for chunk in selected_chunks]) # 2. 构建系统指令和用户提示 system_prompt “””你是一位专业的Python数据分析助手。请严格依据用户提供的上下文信息来回答问题。 如果上下文中的信息不足以完全回答问题请明确指出哪些部分缺失并仅基于已有信息给出部分答案。严禁编造信息。“”” user_prompt f“””请基于以下上下文信息回答我的问题。 上下文信息 {compressed_context} 我的问题是{user_query} “”” # 3. 调用LLM chat ChatOpenAI(model_name“gpt-3.5-turbo”, temperature0.1, openai_api_keyos.getenv(“OPENAI_API_KEY”)) messages [ SystemMessage(contentsystem_prompt), HumanMessage(contentuser_prompt) ] response chat(messages) print(“回答”, response.content)4. 性能调优与高级策略基础的 SAGE 管道搭建完成后我们会发现其效果严重依赖于几个关键环节。下面分享一些进阶调优策略和实战中踩过的坑。4.1 嵌入模型的选择与微调嵌入模型是 SAGE 的“眼睛”它的好坏直接决定了检索质量。通用 vs. 领域专用all-MiniLM-L6-v2是通用模型。如果你的文档是高度专业化的如生物医学论文、法律条文使用在该领域语料上微调过的嵌入模型如BGE系列的领域适配版会有质的提升。你可以用自己领域的文档通过对比学习Contrastive Learning对开源嵌入模型进行轻量微调。多语言问题如果文档和查询涉及多语言需选择多语言嵌入模型如paraphrase-multilingual-MiniLM-L12-v2。长文本处理标准的句子嵌入模型对长段落效果会下降。对于较长的文本块512词可以考虑先对其进行概括再用概括句计算嵌入或者使用专门处理长文本的模型如Longformer的嵌入版本。4.2 分块策略的深度优化简单的递归字符分割并非万能。更高级的策略包括语义分块利用嵌入模型本身计算句子间的语义变化在语义发生较大转折处进行分割。这比基于标点的分割更符合人类理解。保留元数据在分块时务必保留每个块的元数据如源文件名、页码、章节标题。在组装最终上下文时将这些信息例如[来自第5章 高级索引 页码: 127]一并提供给 LLM。这能极大增强 LLM 对信息来源的追溯和理解能力回答中常会引用“如第X页所述”。层次化分块采用两级分块策略。第一级是大块如 2000 字符用于初步、快速的粗筛。第二级是在粗筛出的大块内部再进行更细粒度如 300 字符的分块和精筛。这种“粗-精”检索模式能平衡速度和精度。4.3 重排序提升检索精度的关键一步我们之前直接使用了嵌入相似度排序。但“语义相似”不等于“最能回答问题”。例如问题“如何解决XXX错误”文档中可能有一段描述“XXX错误很常见”相似度高但无用另一段“解决XXX错误的步骤是…”相似度可能略低但直接有用。引入重排序模型Re-ranker可以解决这个问题。它是一个小型交叉编码器Cross-Encoder同时接收查询和单个文档块作为输入直接输出一个相关性分数。这个分数比单纯的嵌入余弦相似度更精准。# 伪代码示例使用交叉编码器进行重排序 from sentence_transformers import CrossEncoder # 假设我们已经通过嵌入模型得到了 top-20 的候选块 candidate_chunks reranker CrossEncoder(‘cross-encoder/ms-marco-MiniLM-L-6-v2’) pairs [[user_query, chunk.text] for chunk in candidate_chunks] rerank_scores reranker.predict(pairs) # 根据重排序分数重新排列候选块流程变为嵌入模型快速召回 Top-K如 K50 - 重排序模型对 K 个候选进行精排 - 选取精排后的 Top-N 送入 LLM。虽然多了一步计算但答案质量提升非常明显。4.4 上下文窗口的极致利用压缩与提炼即使经过筛选有时相关文本的总长度仍会超出限制。此时可以在送入 LLM 前对筛选出的文本块进行“二次压缩”。提取式压缩使用 LLM如 GPT-3.5对每个相关块进行指令式总结例如“请用一句话概括以下文本的核心内容保留所有与‘函数参数’相关的信息。” 然后将这些概括句而非原文送入最终上下文。抽象式压缩风险较高但可以尝试让 LLM 对整个筛选出的集合进行连贯的、保留关键事实的摘要。重要警告压缩会带来信息损失和引入幻觉的风险。必须严格测试并考虑在最终提示中要求 LLM 注明答案依据的来源块编号以便核查。5. 常见问题与故障排查实录在实际部署和调试 SAGE 框架时我遇到了不少典型问题。这里列出一个速查表希望能帮你绕过这些坑。问题现象可能原因排查步骤与解决方案LLM 回答“根据上下文信息不足”1. 检索失败未找到相关块。2. 相关块被截断关键信息丢失。3. 相似度阈值设得过高。1.检查检索结果打印出相似度最高的前5个块及其内容看是否真的相关。2.调整分块重叠增大chunk_overlap例如从100调到150或200。3.降低阈值将relevance_threshold从 0.25 暂时降至 0.15观察更多候选。LLM 的回答包含明显错误或“幻觉”1. 检索到了相关但包含错误信息的块如文档本身有误。2. 上下文中有多个矛盾的信息片段LLM 混淆了。3. 系统指令不够强硬。1.源头核查确认源文档质量。2.增强指令在系统提示中强调“如果上下文信息存在矛盾请指出矛盾所在而不要猜测”。3.实施重排序引入交叉编码器重排序确保最相关、最准确的块排在前面。处理速度非常慢1. 嵌入模型太大或未启用 GPU。2. 为每个查询都重新计算所有文档块的嵌入。3. 文档分块过多。1.使用向量数据库将预计算的块嵌入存入 ChromaDB 或 FAISS实现毫秒级相似度搜索。2.选择轻量模型在精度可接受范围内换用更小的嵌入模型。3.优化分块大小增大chunk_size以减少总块数但需平衡检索粒度。对于包含专业术语或代码的问题检索效果差通用嵌入模型对专业术语和代码的语义捕捉能力弱。1.领域模型微调使用领域文本微调嵌入模型。2.混合检索结合关键词检索如 BM25。先通过关键词快速筛选出包含专业术语的块再与语义检索结果融合。答案忽略了文档中某个明显的部分1. 该部分信息分布在多个不连续的块中单个块相关性不高。2. 问题表述与文档表述差异大。1.尝试 HyDE让 LLM 先根据问题生成一个“假设性答案”然后用这个生成的答案作为查询去检索。这能有效对齐查询和文档的语言风格。2.查询扩展使用同义词或 LLM 生成的问题变体进行多次检索合并结果。我个人最深刻的一个教训是关于分块重叠的。早期我为了追求压缩率设置了chunk_overlap0。结果在一个技术问答中一个关键的方法定义刚好被切分在两个块的边界导致检索永远只能拿到一半信息LLM 的回答始终不完整。自从将重叠度设置为块大小的 20%-25% 后这类“边界丢失”问题基本绝迹。这看似增加了上下文长度但换来了检索稳定性的巨大提升绝对是值得的。SAGE 框架的精髓在于它承认 LLM 处理长文本的局限性并巧妙地运用其自身赖以成功的“注意力”思想来前置解决这个问题。它不是魔法而是一套可工程化、可调试的系统性方法。通过精心设计的分块、精准的检索和智能的聚合我们能够显著拉近长文档与高质量问答之间的距离。随着嵌入模型、重排序技术和 LLM 自身能力的不断进步这类上下文压缩框架的效率和智能程度只会越来越高成为处理海量文本知识不可或缺的桥梁。