1. 项目概述与核心价值最近在折腾大语言模型应用时遇到了一个挺普遍但容易被忽视的问题上下文长度限制。无论是用 OpenAI 的 GPT-4还是部署开源的 Llama、ChatGLM你总会碰到那个恼人的“Token 超限”错误。尤其是在处理长文档总结、多轮对话历史管理或者构建知识库问答系统时这个问题尤为突出。我们通常的解决方案是粗暴地截断或者尝试各种摘要方法但前者会丢失关键信息后者则可能引入偏差或消耗额外的算力。就在我为此头疼时发现了liyucheng09/Selective_Context这个项目它提出了一种名为“选择性上下文”的思路让我眼前一亮。简单来说Selective_Context不是一个具体的应用而是一个方法论和工具包。它的核心思想是在面对超长的输入文本时我们不必也无法将全部内容都塞给模型。相反我们可以用一种智能的、可学习的方式筛选出对当前任务最关键的上下文片段只将这些“精华”部分送入模型进行处理。这就像你在阅读一篇冗长的报告时会本能地抓住核心论点、关键数据和结论而略过一些细节描述或重复论证。这个项目就是试图让 AI 学会这种“抓重点”的能力。它的价值在于为突破大模型上下文窗口限制提供了一个全新的、可优化的技术路径。不同于简单的滑动窗口可能割裂语义或递归总结可能累积误差选择性上下文旨在动态评估文本中每个部分的重要性并进行保留或压缩。这对于构建高效的 AI 智能体、实现超长文档的理解与交互、降低大模型 API 调用成本都有着直接的实践意义。接下来我将深入拆解这个项目的设计思路、关键技术点并分享如何将其集成到你的实际项目中的具体方法。2. 核心思路与架构设计解析2.1 问题定义为什么需要“选择性上下文”要理解Selective_Context首先要明确它要解决的根本矛盾模型有限的处理能力与无限增长的输入信息之间的矛盾。大语言模型虽然有强大的理解和生成能力但其上下文窗口Context Window是硬性限制。例如GPT-4 Turbo 是 128KClaude 3 是 200K而许多优秀的开源模型可能只有 4K 或 8K。当输入文本远超这个限制时我们面临几个选择直接截断保留开头、结尾或中间一部分。缺点是可能丢失位于被丢弃部分的核心指令或信息导致模型输出完全偏离预期。滑动窗口将长文本切成重叠的片段分别处理后再合并结果。这对摘要类任务尚可但对需要全局连贯理解的任务如代码分析、逻辑推理会带来信息碎片化的问题。外部检索使用向量数据库先检索相关片段再输入。这需要额外的检索系统且检索质量直接影响最终效果存在“检索遗漏”的风险。递归总结将文本分段总结再将总结作为下一段的上下文。这种方法误差会累积且最终的总结可能高度抽象丢失了大量原始细节。Selective_Context的思路是上述方法的补充和优化。它不依赖于外部系统也不进行不可逆的摘要压缩而是在输入模型前对原始文本进行一次“重要性评分”和“智能筛选”。目标是保留那些对完成当前用户查询Query最不可或缺的文本单元可以是句子、段落或固定长度的Token块。2.2 核心架构如何实现“选择性”项目的核心架构通常包含以下几个关键模块虽然具体实现可能有所不同但思想是相通的文本分块与单元化首先将长文档按语义边界如句子、段落或固定长度进行分块。分块策略直接影响筛选的粒度。太细如按词则计算开销大且缺乏上下文太粗如整章则筛选不够精准。实践中按句子或小段落100-200字分块是一个平衡点。重要性评估器这是整个系统的“大脑”。它的任务是给每一个文本块打一个“重要性分数”。这个分数应该反映该文本块对于回答当前特定问题或完成当前任务的贡献度。实现评估器有多种方式基于嵌入的相似度计算每个文本块的向量嵌入如用text-embedding-ada-002或BGE同时计算用户查询的向量嵌入。通过余弦相似度来衡量文本块与查询的相关性。这是最直接的方法但可能无法捕捉复杂的逻辑重要性。使用轻量级评估模型训练或微调一个小的分类模型如基于 BERT输入“查询文本块”输出一个相关性分数。这比纯嵌入更灵活但需要训练数据。利用大模型自评直接调用大模型如 GPT-3.5通过精心设计的提示词Prompt让模型判断某个文本块对于回答某个问题的重要性。这种方法零样本能力强但成本较高延迟大。Selective_Context项目可能会提供或推荐其中一种或多种实现。筛选与组合策略拿到所有文本块的分数后需要决定保留哪些。简单的方法是设置一个阈值保留高于阈值的块。更高级的策略是预算约束下的优化在不超过模型上下文Token上限的前提下选择一组能最大化总重要性得分的文本块。这实际上是一个0/1背包问题可以用动态规划或贪心算法近似求解。上下文重构将筛选出的文本块按照它们在原文中的顺序或其他有助于模型理解的顺序如按重要性降序重新组合形成一个新的、缩短后的上下文连同原始的用户查询一并提交给下游的大语言模型进行处理。注意这里的“选择性”是动态的、面向任务的。同一份长文档面对不同的问题筛选出的上下文片段会完全不同。这是它与静态摘要最本质的区别。2.3 方案选型背后的考量为什么选择“重要性评估筛选”这条路径这背后有几层考量可解释性相比于黑盒式的摘要模型重要性评分提供了每个文本块为何被保留或丢弃的直观依据分数便于调试和优化。保真度它保留的是原始文本片段而非重新生成的摘要避免了摘要模型可能引入的事实性错误或风格变化。灵活性评估器可以针对不同任务问答、总结、分析进行定制或提示适应性更强。可优化性整个流程分块、评估、筛选的每个环节都可以独立改进。例如可以尝试更好的嵌入模型、更高效的排序算法或者引入对块间连贯性的考虑。3. 关键技术细节与实操要点3.1 文本分块的艺术与陷阱分块是第一步也是最容易埋坑的一步。不合理的分块会导致语义割裂严重影响后续评估和最终效果。实操要点优先使用语义分块不要简单按固定字符数切割。利用标点符号句号、问号、感叹号、换行符进行句子级分割再合并过短的句子。对于中文可以使用jieba或pkuseg进行分词和句子划分或直接用langchain的RecursiveCharacterTextSplitter它尝试按字符递归分割能较好地保持段落和句子的完整性。设置合理的块大小与重叠块大小需要匹配你的评估模型和下游大模型的特性。通常块大小在200-500个字符或Token之间比较合适。在块与块之间设置一个小的重叠区例如50个字符可以防止关键信息恰好被切在边界上而丢失。例如一个关键论点可能跨越两个段落重叠能确保它至少在一个块内是完整的。保留元数据为每个文本块记录它在原文中的起始位置、所属章节等信息。这在后期调试或需要追溯原文时非常有用。常见陷阱表格和代码被切碎对于技术文档表格和代码块需要特殊处理。最好将它们视为一个整体单元不进行内部切割。可以使用正则表达式或专门的解析库如PyMuPDF提取表格tree-sitter解析代码来识别这些特殊结构。列表项分散一个列表的各个项目被分到不同的块破坏了其并列关系。处理时应将一个完整的列表从列表开始标记到结束作为一个块。3.2 重要性评估器的实现选择这是选择性上下文系统的核心。liyucheng09/Selective_Context项目可能提供了基础实现但理解其原理才能更好地调优。方案一基于嵌入相似度快速、经济这是最常用的基线方法。流程如下使用嵌入模型如all-MiniLM-L6-v2,BGE-M3,text-embedding-3-small将用户查询Q和每个文本块C_i转换为向量v_q和v_i。计算余弦相似度score_i cosine(v_q, v_i)。将相似度分数归一化或直接作为重要性分数。# 伪代码示例 from sentence_transformers import SentenceTransformer import numpy as np embedder SentenceTransformer(BAAI/bge-base-en-v1.5) # 以BGE模型为例 query What is the main contribution of the paper? chunks [Chunk 1 text..., Chunk 2 text..., ...] query_embedding embedder.encode(query, normalize_embeddingsTrue) chunk_embeddings embedder.encode(chunks, normalize_embeddingsTrue) # 计算余弦相似度已归一化点积即余弦相似度 scores np.dot(chunk_embeddings, query_embedding.T).flatten()优点速度快计算开销小无需训练。缺点只能捕捉表面语义相关性对于需要复杂推理或隐含关联的任务效果有限。例如查询“证明过程中的关键引理是什么”与“引理3.2”字面不匹配的证明步骤文本块可能得分很低尽管它们至关重要。方案二使用交叉编码器或微调模型精准、稍慢交叉编码器Cross-Encoder将查询和文本块同时输入模型进行深度交互直接输出一个相关性分数。这比双编码器Bi-Encoder即上面的嵌入模型更准确但无法预先计算文本块嵌入每次都需要实时计算速度慢。# 使用 sentence-transformers 的交叉编码器 from sentence_transformers import CrossEncoder model CrossEncoder(cross-encoder/ms-marco-MiniLM-L-6-v2) pairs [[query, chunk] for chunk in chunks] scores model.predict(pairs)方案三大模型自评零样本能力强、成本高通过Prompt让大模型直接打分。例如你是一个信息筛选助手。请根据以下问题判断对应的文本片段对于回答问题的重要性从0到10打分10分最高。 问题{query} 文本片段{chunk} 请只输出一个0-10的整数分数。然后解析模型的输出作为分数。这种方法非常灵活能理解复杂意图但API调用成本高延迟大且分数可能不稳定。实操心得混合策略在实际生产中可以采用混合策略。先用快速的嵌入模型进行粗筛过滤掉明显不相关的块如分数低于某个阈值再对剩下的候选块使用更精准但更慢的交叉编码器或大模型进行精排。这能在效果和效率间取得平衡。分数标准化不同评估器输出的分数范围不同如相似度在[-1,1]交叉编码器分数可能任意值。需要进行标准化如Min-Max缩放或Z-score以便后续统一阈值筛选或优化算法处理。考虑块间关系当前评估是独立的但有时重要性是相对的。例如一个块定义了关键术语另一个块使用了它。可以尝试在评分后引入图算法根据共现或引用关系对关联块进行分数传播或加权。3.3 筛选算法在预算内做出最优选择得到分数后我们有一个Token预算即下游大模型的上下文容量减去查询和系统提示的占用。目标是选择一组文本块使得总重要性分数最高且总Token数不超过预算。这是一个经典的0/1背包问题每个块选或不选价值重要性分数重量Token数。对于块数较多的情况精确的动态规划可能计算量较大可以采用贪心算法近似求解计算每个块的“价值密度”密度 分数 / Token数。按价值密度降序排序。按排序顺序依次将块加入最终集合直到加入下一个块会导致总Token数超预算为止。这种贪心算法对于分数和Token数正相关的情况效果不错但不是全局最优。项目可能会实现更精确的算法。实操要点Token计数要准确必须使用与下游大模型一致的Tokenizer来计算每个文本块的Token数。例如对于GPT系列使用tiktoken对于Llama系列使用其对应的transformers库中的Tokenizer。错误的计数会导致筛选结果超出实际容量。保留必要的顺序信息虽然按重要性筛选但将筛选后的块乱序输入模型可能会破坏逻辑连贯性。一种做法是在筛选阶段将“保持原始顺序”作为一个软约束或后处理步骤。例如先筛选出高分块再按原始顺序输出或者允许轻微的顺序调整但避免大的跳跃。4. 集成与实战构建一个选择性上下文问答系统让我们以一个具体的场景为例构建一个基于长技术文档如一篇50页的PDF论文的问答系统。我们将把Selective_Context的思想集成进去。4.1 系统架构设计整个系统的工作流程如下文档预处理将PDF转换为纯文本并进行清洗。文本分块使用语义分块器将长文本分割成易于管理的块。向量化与索引为每个文本块生成向量嵌入并存入向量数据库如Chroma、Weaviate或FAISS。这一步是可选但推荐的它为快速检索粗筛提供了基础。用户查询处理 a.检索粗筛根据用户查询从向量数据库中检索出Top-K个最相关的文本块例如K20。这步快速过滤了绝大部分不相关的内容。 b.精排选择性上下文核心对检索出的K个候选块使用更精细的重要性评估器如交叉编码器进行重新评分。 c.预算约束筛选根据精排后的分数和每个块的Token数使用筛选算法如带预算的贪心算法选出最终要送入大模型的文本块集合。 d.上下文重构将选中的块按原始顺序组合并添加上下文指令如“请根据以下上下文回答问题”形成最终的Prompt。调用大模型将构建好的Prompt发送给大语言模型如GPT-4、Claude或本地部署的Llama获取答案。输出与溯源返回答案并可选择性地附上被选中的文本块及其来源位置增强可信度。4.2 分步实现与代码要点步骤1环境准备与依赖安装你需要安装一些核心库。假设我们使用langchain作为框架sentence-transformers做嵌入chromadb做向量存储。pip install langchain langchain-community sentence-transformers chromadb pypdf步骤2文档加载与分块from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 1. 加载文档 loader PyPDFLoader(your_long_paper.pdf) documents loader.load() # 2. 创建文本分割器 text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 每个块的字符数 chunk_overlap50, # 块间重叠字符数 length_functionlen, separators[\n\n, \n, 。, , , , , 、, , ] # 中文分隔符 ) # 3. 执行分块 all_chunks text_splitter.split_documents(documents) # all_chunks 是一个列表每个元素是一个 Document 对象包含 page_content 和 metadata步骤3向量化与存储from langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import Chroma # 1. 选择嵌入模型 embedding_model HuggingFaceEmbeddings(model_nameBAAI/bge-base-zh-v1.5) # 中文模型 # 2. 创建向量数据库 vectorstore Chroma.from_documents( documentsall_chunks, embeddingembedding_model, persist_directory./chroma_db # 持久化到本地 )步骤4实现选择性上下文检索链这是核心部分。我们将自定义一个检索器它先做向量检索再做精排和筛选。from langchain.retrievers import BaseRetriever from typing import List from langchain.schema import Document from sentence_transformers import CrossEncoder import tiktoken # 用于GPT Token计数如果是其他模型需换对应tokenizer class SelectiveContextRetriever(BaseRetriever): def __init__(self, vectorstore, cross_encoder_namecross-encoder/ms-marco-MiniLM-L-6-v2, budget3000): self.vectorstore vectorstore self.cross_encoder CrossEncoder(cross_encoder_name) self.tokenizer tiktoken.get_encoding(cl100k_base) # GPT-4/3.5 的编码器 self.budget budget # Token预算 def _get_relevant_documents(self, query: str) - List[Document]: # 第一步向量检索粗筛获取较多候选 candidate_docs self.vectorstore.similarity_search(query, k20) if not candidate_docs: return [] # 第二步交叉编码器精排 pairs [[query, doc.page_content] for doc in candidate_docs] relevance_scores self.cross_encoder.predict(pairs) # 将分数附加到文档元数据中 for doc, score in zip(candidate_docs, relevance_scores): doc.metadata[relevance_score] float(score) # 计算Token数 doc.metadata[token_count] len(self.tokenizer.encode(doc.page_content)) # 第三步预算约束下的筛选贪心算法 selected_docs [] current_token_count 0 # 按价值密度分数/Token数降序排序 candidate_docs.sort(keylambda x: x.metadata[relevance_score] / x.metadata[token_count], reverseTrue) for doc in candidate_docs: if current_token_count doc.metadata[token_count] self.budget: selected_docs.append(doc) current_token_count doc.metadata[token_count] else: # 如果预算紧张可以尝试跳过一些或者提前结束 # 这里简单实现为跳过当前块 continue # 第四步按原始位置排序保持阅读连贯性 selected_docs.sort(keylambda x: x.metadata.get(page, 0) * 10000 x.metadata.get(start_index, 0)) return selected_docs步骤5构建问答链from langchain.chains import RetrievalQA from langchain.chat_models import ChatOpenAI # 或其他LLM # 初始化选择性上下文检索器 retriever SelectiveContextRetriever(vectorstorevectorstore, budget3000) # 初始化大语言模型 llm ChatOpenAI(modelgpt-4-turbo-preview, temperature0) # 创建问答链 qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, # 将检索到的文档“塞”进Prompt retrieverretriever, return_source_documentsTrue # 返回源文档用于溯源 ) # 提问 question 这篇论文提出的核心方法是什么它的主要创新点在哪里 result qa_chain({query: question}) print(答案, result[result]) print(\n--- 使用的上下文来源 ---) for i, doc in enumerate(result[source_documents]): print(f片段 {i1} (分数{doc.metadata[relevance_score]:.3f}, Token数{doc.metadata[token_count]}):) print(doc.page_content[:200] ...) # 打印前200字符 print()4.3 参数调优与效果评估实现之后关键在于调优。以下几个参数对效果影响巨大分块大小与重叠对于技术文档chunk_size400-600字符overlap50-100字符是个不错的起点。可以通过观察被选中块的完整性来调整。粗筛数量K在向量检索阶段返回的候选文档数。太小可能漏掉重要但语义不直接相关的信息太大会增加精排的计算量。建议从15-25开始尝试。Token预算这取决于你的大模型上下文窗口和查询长度。预留足够的空间给系统提示词、用户查询和模型的回答。例如GPT-4的128K窗口实际处理长文本时给上下文的预算设为8000-12000 Tokens是常见的。评估模型选择嵌入模型对于中文BGE系列是当前主流。英文可选text-embedding-3-small或all-MiniLM-L6-v2。交叉编码器cross-encoder/ms-marco-*系列是在通用检索数据上训练的对于问答任务效果不错。如果有领域数据可以进行微调以获得更好效果。如何评估效果人工评估准备一组测试问题对比使用“选择性上下文”和“简单向量检索Top-N”两种方式得到的答案质量。从答案相关性、信息完整性、是否存在幻觉等方面打分。自动化指标可以使用RAGAS、TruLens等评估框架计算答案的忠实度Faithfulness是否基于上下文、答案相关性Answer Relevance等指标。成本与延迟监控记录每次查询消耗的Token数特别是输入Token和总响应时间。选择性上下文的目标是在可控的成本和延迟下提升答案质量。5. 常见问题、排查技巧与进阶思考在实际集成和使用过程中你肯定会遇到各种问题。下面是我踩过的一些坑和对应的解决方案。5.1 常见问题速查表问题现象可能原因排查与解决方案答案明显遗漏关键信息1. 关键信息所在文本块在粗筛向量检索阶段就被漏掉了。2. 关键信息被分块切碎了。3. 精排模型给关键块的分数过低。1.检查向量检索增大粗筛数量K或尝试不同的嵌入模型/相似度算法如换用dot product。2.检查分块查看原始文档确认关键信息是否完整存在于某个块中。调整分块大小或使用更智能的分割器如按章节。3.检查精排分数打印出所有候选块的分数看关键块是否在其中且分数是否合理。考虑使用更强大的精排模型如更大的交叉编码器或调用大模型打分。答案包含无关内容或幻觉1. 筛选算法选入了相关性不高的块。2. Token预算过高导致选入了过多边缘内容。3. 大模型自身产生了幻觉。1.调整筛选阈值在精排后可以设置一个最低分数阈值过滤掉绝对低分块。2.收紧预算降低Token预算迫使系统只选择最核心的少数几个块。3.优化Prompt在给大模型的指令中强调“仅根据提供的上下文回答”并加入“如果上下文未提供相关信息请回答‘我不知道’”的约束。系统响应速度慢1. 交叉编码器精排步骤耗时过长。2. 分块数量过多向量检索慢。1.模型轻量化使用更小的交叉编码器模型或仅在候选块数量多时启用精排。2.两阶段检索优化先用更快的双编码器做第一轮严格筛选如取Top-50再用交叉编码器对Top-10进行精排。3.异步与缓存对固定的文档库可以预先计算好所有块的嵌入并缓存。对于精排结果如果查询相似也可以考虑短期缓存。答案逻辑不连贯1. 筛选出的块顺序混乱。2. 块间缺乏必要的过渡信息。1.强制顺序输出在筛选算法最后严格按原始文档顺序重新排序选中块。2.引入连贯性惩罚在筛选算法中不仅考虑单个块的重要性也考虑块与块之间的位置关系对跨度大的块组合进行轻微扣分鼓励选择连续的块。Token计数不准导致预算超支使用了错误的Tokenizer进行计数。统一Tokenizer确保Token计数器与最终使用的大模型完全一致。如果使用Azure OpenAI/Anthropic查阅其官方文档确认编码方式。对于本地模型使用其transformers库中的tokenizer进行精确计数。5.2 进阶技巧与优化方向查询扩展与重写用户的原始查询可能很简短或表述不准确。在检索前可以使用一个小型LLM如GPT-3.5-turbo对查询进行扩展或重写生成多个相关的问题或关键词然后用这些扩展后的查询去并行检索最后合并结果。这能显著提高召回率。层次化筛选对于超长文档如整本书可以先在章/节级别进行粗选再在选中的章节内部进行段落/句子级的精选。这能大幅减少需要精细评估的文本量。融合检索与生成选择性上下文可以与传统的检索增强生成RAG结合。在最终Prompt中不仅可以包含筛选出的原始文本块还可以包含一个由这些块生成的、非常简短的摘要或大纲帮助大模型快速把握全局结构。持续学习与反馈系统可以记录用户的反馈如对答案的点赞/点踩。如果某个查询下被选中的上下文产生了高质量答案可以强化这些块与查询的关联反之则弱化。这需要构建一个反馈循环来微调重要性评估模型。考虑多模态如果文档包含图片、表格选择性上下文的思路可以扩展。例如为图片生成描述性文本将表格转换为结构化数据然后将这些信息也作为可筛选的“文本块”纳入系统。5.3 关于liyucheng09/Selective_Context项目的使用由于我无法直接运行或查看该项目的具体代码这是一个假设的解析在实际应用时你应该仔细阅读项目README和源码理解作者提供的接口、预训练模型和默认配置。从示例开始通常项目会提供简单的示例脚本。先跑通示例理解其输入输出格式。将其作为组件集成很可能该项目提供了一个核心的“选择性上下文”处理类或函数。你可以像上面示例中自定义SelectiveContextRetriever一样调用该项目提供的方法来完成重要性评估和筛选而不是自己从头实现交叉编码和贪心算法。关注开源社区的讨论在GitHub Issues或讨论区中经常会有其他使用者分享调参经验、遇到的问题和解决方案这些都是宝贵的实战资料。选择性上下文不是银弹它是在现有技术约束下的一种优雅折中。它迫使我们去思考对于特定的任务一段文本中究竟什么才是“不可或缺”的这种思考本身对于设计更高效、更智能的AI应用就极具价值。通过今天的拆解希望你能不仅学会如何使用这个工具更能掌握其背后的思想并在你遇到的长文本处理挑战中灵活运用和演化这套方法。