1. 从“窗口”到“策略”为什么长文本是LLM的“阿克琉斯之踵”如果你最近在折腾大语言模型无论是用OpenAI的API、部署开源模型还是研究RAG应用大概率都听过“上下文窗口”这个词。它听起来像个技术参数但背后藏着的是几乎所有LLM应用都会遇到的瓶颈。简单来说上下文窗口就是模型一次性能“看到”并处理的文本长度上限。比如GPT-4 Turbo的128KClaude 3的200K或者开源Llama 3的8K、128K版本。这个数字很诱人对吧能一口气塞进一整本小说或者几十页PDF感觉所有问题都能迎刃而解。但实际用起来你会发现事情没那么简单。直接给模型扔一个100K token的长文档然后问一个细节问题模型的回答质量往往会断崖式下跌——它要么“忘记”了中间的关键信息要么开始胡言乱语把不同部分的内容张冠李戴。更别提随之而来的天价API费用和漫长的响应等待了。这背后的根本原因在于Transformer架构的核心机制。Transformer依赖的“注意力机制”其计算复杂度与序列长度的平方成正比。一个128K的序列注意力计算的开销是8K序列的256倍这不仅仅是算力成本问题更会导致模型在超长序列中难以有效分配“注意力”信息过载最终表现失准。所以“上下文窗口管理”和“长文本策略”不是一个炫技的选修课而是构建可靠LLM应用的必修课。它关乎成本、速度更关乎最终效果的生死线。本文将从一个实践者的角度拆解长文本处理的完整链条。我们不会停留在理论介绍而是深入到具体策略的选择逻辑、实操中的陷阱以及如何根据你的具体场景是文档问答、代码分析还是多轮对话来设计最经济有效的方案。无论你是刚接触提示工程的开发者还是正在为产品选择技术路线的架构师这些从真实项目中踩坑得来的经验或许能帮你少走弯路。2. Transformer架构的“内存墙”理解上下文长度的根本限制要制定有效的策略首先得明白敌人是谁。为什么增加上下文窗口这么难一切都要回到Transformer的注意力机制。2.1 注意力机制的计算开销平方级的诅咒Transformer的核心是自注意力机制。对于长度为n的输入序列模型需要计算一个n x n的注意力分数矩阵。这个计算过程无论是时间还是空间复杂度都是O(n²)。我们来算笔账假设处理一个8K token的序列注意力矩阵的元素数量是 8000² 64,000,0006400万。如果上下文窗口扩大到32K这个数字就变成了 32,000² 1,024,000,00010.24亿。而到128K时则是惊人的 128,000² 16,384,000,000163.84亿。每一次前向传播都需要存储和计算这个庞大的矩阵这对GPU显存构成了直接挑战。这就是为什么即使模型宣称支持长上下文在实际使用中你也需要一块显存巨大的显卡并且推理速度会显著变慢。注意这里说的是“原生”的全注意力机制。后续的许多优化如FlashAttention通过算法优化大幅降低了显存占用但计算量本身依然是平方级关系只是通过巧妙的IO调度隐藏了部分成本。它让长上下文变得“可能”但并没有改变“昂贵”的本质。2.2 位置编码的困境外推与内插除了计算另一个关键点是位置编码。Transformer本身不具备感知token顺序的能力需要依靠位置编码来注入序列的顺序信息。最经典的正弦位置编码Sinusoidal Positional Encoding或可学习的位置编码在训练时都是在某个固定长度比如2048或4096上进行的。当你在推理时输入一个远超训练长度的序列时模型就遇到了它从未见过的位置索引。这会导致“外推”问题模型无法正确处理这些新位置的关系性能急剧下降。为了解决这个问题社区发展出了两种主要思路外推Extrapolation直接修改位置编码的数学形式使其能够适应更长的位置。例如线性缩放Linear Scaling或NTK-aware缩放。这类方法有时能work但不够稳定尤其在需要精确理解长距离依赖的任务上容易失效。内插Interpolation在推理时将长序列的位置索引“压缩”到模型训练时见过的范围内。比如将10000的位置按比例映射到训练时的2048以内。RoPERotary Position Embedding编码因其良好的外推性常与内插法结合使用如通过调整RoPE的base值。目前许多支持长上下文的开源模型如经过微调的Llama模型都采用了此类技术。在实际选择模型时你必须关注它的技术报告它宣称的长上下文能力是通过“从头训练”得来的还是通过“位置编码内插微调”实现的后者成本低但可能在需要超长程精确推理的任务上表现不佳。2.3 KV Cache推理加速与内存的博弈在自回归生成一个一个token地输出时为了避免重复计算Transformer会缓存每个解码步中Key和Value的状态这就是KV Cache。KV Cache的大小与batch_size * sequence_length * num_layers * hidden_size相关。这意味着你的上下文越长KV Cache占用的显存就越大。对于一次处理多个长序列的批处理场景这很快就会成为瓶颈。因此一些推理优化框架如vLLM会实现KV Cache的PagedAttention像操作系统管理内存一样管理KV Cache以提高显存利用率。但即便如此长上下文对显存的压力依然是实实在在的。理解了这些底层限制我们就能明白单纯追求更大的上下文窗口数字是鲁莽的。更聪明的做法是结合上层应用策略让模型在它“舒适”的范围内工作。这就是下文要讨论的各种长文本策略。3. 核心长文本策略全景图从RAG到“无损”压缩面对长文本业界已经形成了几种主流策略范式。它们没有绝对的好坏只有是否适合你的场景。下图概括了这几种核心策略及其典型工作流程flowchart TD A[输入长文本] -- B{选择核心处理策略} B -- C[“策略一检索增强生成br(RAG)”] B -- D[“策略二层次化处理br(MapReduce/MapRerank)”] B -- E[“策略三上下文压缩br(Summarization/Filtering)”] B -- F[“策略四直接处理br(Native Long Context)”] C -- C1[文档切分brChunking] C1 -- C2[向量化与检索] C2 -- C3[将相关片段注入Prompt] C3 -- G[LLM生成最终答案] D -- D1[将长文本切分为片段] D1 -- D2[“并行处理每个片段brMap阶段”] D2 -- D3[“聚合或重排所有结果brReduce/Rerank阶段”] D3 -- G E -- E1[使用LLM或小模型进行摘要] E1 -- E2[或提取关键实体/过滤冗余] E2 -- E3[将压缩后文本注入Prompt] E3 -- G F -- F1[依赖模型自身的br长上下文能力] F1 -- G3.1 策略一检索增强生成——精度与成本的平衡术RAG是目前最流行、最实用的长文本处理方案尤其适合知识库问答、文档分析等场景。它的核心思想不是让模型记住所有内容而是建立一个“外部记忆库”在需要时快速检索相关片段。工作流程与关键抉择文档切分Chunking这是RAG的基石也是第一个大坑。常见的错误是盲目使用固定大小的切分如512个token。为什么不能盲目切分固定切分会无情地割裂完整的句子、段落甚至表格导致检索到的片段语义不完整严重影响后续效果。如何正确切分应采用基于语义的切分。例如使用langchain的RecursiveCharacterTextSplitter并设置separators为[\n\n, \n, 。, , , , , , ]优先按段落、句子切分。同时可以设置一个chunk_size如1000和chunk_overlap如200重叠部分能有效防止关键信息被切在边界丢失。进阶技巧对于高度结构化的文本如Markdown、代码可以按标题# ##或函数/类定义进行切分这能更好地保持上下文。检索Retrieval如何找到最相关的片段向量检索主流将文本块编码为向量存入向量数据库如Chroma, Pinecone, Weaviate。查询时将问题也编码为向量计算余弦相似度返回最相似的K个片段。它的优点是能捕捉语义相似性。关键词检索补充使用BM25等算法。它在寻找精确术语匹配时非常有效是向量检索的良好补充。最佳实践往往是“混合检索”同时进行向量检索和关键词检索然后对结果进行重排序Rerank。重排序Rerank初检返回的Top K个结果比如20个可能包含一些语义相关但实际对回答问题无用的片段。使用一个更小、更快的重排序模型如BAAI/bge-reranker系列对这20个结果进行精排只选出最相关的2-3个注入Prompt能极大提升答案质量并节省上下文窗口。RAG的优劣分析优点精度高只注入相关信息、成本低每次调用模型处理的文本短、可解释性强可以追溯答案来源。缺点架构复杂需要维护向量数据库、嵌入模型等且存在“检索失败”的单点风险——如果关键信息没被检索到模型再强也无能为力。适用场景文档问答、知识库聊天机器人、需要引用来源的场景。3.2 策略二层次化处理——分而治之的经典哲学当任务需要对整个长文档进行整体分析、总结或推理时RAG可能力有不逮。这时层次化处理模式就派上用场了。其代表是MapReduce和MapRerank。MapReduce模式详解Map映射将长文档切分成多个有重叠的片段。然后并行或串行地将每个片段连同你的问题或总结指令发送给LLM要求它对每个片段生成一个“局部答案”或“摘要”。Reduce归约收集所有片段的“局部答案”将它们组合成一个新的、较短的文本。最后将这个组合文本再次发送给LLM要求它基于所有局部信息生成一个全局的、连贯的最终答案。实操中的陷阱与技巧并行与成本并行调用能极大缩短时间但会瞬间消耗大量API配额。对于OpenAI等按token计费的API需谨慎控制并发数。指令设计给Map阶段的指令至关重要。例如如果你要总结一篇技术论文给Map阶段的指令可以是“请总结本片段的核心论点、实验方法和数据结论。” 而Reduce阶段的指令则是“你收到了来自同一篇论文各个部分的总结。请整合它们写出一篇涵盖引言、方法、结果、讨论的完整论文摘要。”信息丢失Reduce阶段模型需要消化多个局部答案可能丢失细节。可以在Map阶段要求模型同时输出“关键引用”如原文中的关键句子并在Reduce的Prompt中提供这些引用。MapRerank模式这是MapReduce的变体适用于答案明确、需要选择最佳答案的场景如选择题、事实核查。在Map阶段让模型对每个片段生成一个答案并给出一个置信度分数。在Reduce阶段直接选择置信度最高的答案或者对所有答案进行投票。优劣分析优点能处理需要全局理解的任务比直接处理整个长文档更可靠。缺点流程复杂调用次数多成本高且最终答案质量严重依赖Map阶段的质量。适用场景长文档摘要、跨多个章节的综合问答、对全文进行情感或主题分析。3.3 策略三上下文压缩——主动为模型减负这个策略的核心思想是在将长文本交给核心LLM处理之前先对其进行预处理剔除冗余信息保留精华。这就像给模型看的“简报”。主要压缩手段摘要Summarization使用一个LLM可以是更小、更便宜的模型先对原文进行摘要。然后将摘要而非原文送入主模型处理。这里的一个技巧是“渐进式摘要”对于极长的文本可以先分段摘要再对摘要进行摘要。过滤Filtering根据任务目标只提取相关部分。例如如果你只关心文档中的财务数据可以用一个小的NER命名实体识别模型或规则提取出所有货币、百分比、日期等实体和周围的句子。提取关键句使用无监督方法如TextRank或有监督的小模型从原文中提取出最关键的几个句子。一个实用的混合方案在RAG的检索环节之后对检索到的相关片段进行压缩。例如检索到5个相关段落总计3000token。在注入最终Prompt前先用GPT-3.5-Turbo对这5个段落做一个简洁摘要压缩到800token再交给GPT-4进行最终回答。这样既能保留核心信息又节省了昂贵模型的上下文开销。优劣分析优点直接降低主模型的token消耗节省成本和时间。缺点存在信息损失的风险压缩模型本身也可能出错。适用场景成本敏感型应用或当主模型上下文窗口有限时的备选方案。3.4 策略四直接处理——信任模型的“原生”能力这就是最简单粗暴的方法找一个宣称支持超长上下文如128K、200K的模型把整个文档和问题一起丢进去。随着模型能力的提升这正在成为更多场景的可行选项。何时可以考虑直接处理任务简单任务不需要非常精细的、跨超长距离的推理。文档结构清晰文档本身段落分明模型容易定位。成本不敏感或一次性任务对于内部分析、研究等非高频场景。模型经过验证你已通过测试确认该模型在类似长度和任务上表现可靠。必须进行的“压力测试”直接使用前务必设计测试用例。不要用一篇普通文章测试要用你业务中最复杂、最长、信息密度最高的文档。问一些需要结合文档开头、中间和结尾信息才能回答的问题。观察模型是否会出现“中间丢失”现象即对文档中间部分的信息记忆或理解变差。优劣分析优点架构简单无需复杂的预处理流水线。理论上模型能利用全文信息。缺点成本最高速度可能最慢且模型在超长上下文下的实际性能存在不确定性。适用场景对简单长文档进行一次性分析、作为其他策略的对比基线。4. 实战构建一个混合策略的长文档QA系统理论说再多不如动手搭一个。下面我们设计一个兼顾精度、成本和复杂度的混合策略系统用于处理长达数百页的技术手册PDF的问答。系统目标用户上传PDF手册可以任意提问。系统需要返回准确答案并注明答案来源的页码和章节。架构设计混合RAG 压缩文档解析与增强切分使用PyPDF2或pdfplumber解析PDF提取文本和元数据如页码。采用语义切分但为每个文本块额外附加“页码”和“上级标题”作为元数据。两级检索系统第一级粗筛向量检索将文本块向量化存入ChromaDB。用户提问时进行向量相似度检索返回Top 10相关块。第二级精筛重排序关键词过滤使用重排序模型对Top 10进行精排。同时对用户问题提取关键词在Top 10中筛选出同时包含关键词的块提升精确匹配。最终选出置信度最高的Top 3文本块。上下文压缩与组装将Top 3文本块及其元数据页码、标题组合。如果组合后token数超过主模型上下文限制例如GPT-4的8K则调用GPT-3.5-Turbo指令为“请根据以下来自技术手册的片段提取出与问题‘[用户问题]’最相关的信息并保持原文措辞。请以列表形式输出每条信息后注明原页码。” 将返回的压缩列表作为最终上下文。提示词工程与最终回答将压缩后的上下文、用户问题以及严格的指令组装成Prompt发送给主模型如GPT-4。你是一位技术手册专家。请严格根据以下提供的上下文片段来回答问题。如果上下文中的信息不足以回答问题请直接说“根据提供的信息无法回答”。 上下文片段附页码 [压缩后的上下文列表] 问题[用户问题] 请给出准确、简洁的答案并在答案后以【页码X】的形式注明信息来源。关键代码片段示意使用LangChain简化流程from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.vectorstores import Chroma from langchain.embeddings import OpenAIEmbeddings from langchain.llms import OpenAI from langchain.chains import RetrievalQA from langchain.retrievers import ContextualCompressionRetriever from langchain.retrievers.document_compressors import LLMChainExtractor # 1. 加载和切分文档 text_splitter RecursiveCharacterTextSplitter( chunk_size1000, chunk_overlap200, separators[\n\n, \n, 。, , , , , , ] ) docs text_splitter.split_documents(your_documents) # your_documents需包含page元数据 # 2. 创建向量库 vectorstore Chroma.from_documents(docs, OpenAIEmbeddings()) # 3. 创建压缩检索器使用一个更便宜的LLM进行压缩 base_retriever vectorstore.as_retriever(search_kwargs{k: 10}) compressor LLMChainExtractor.from_llm(OpenAI(temperature0, modelgpt-3.5-turbo-instruct)) # 使用更便宜的模型做压缩 compression_retriever ContextualCompressionRetriever(base_compressorcompressor, base_retrieverbase_retriever) # 4. 创建QA链 qa_chain RetrievalQA.from_chain_type( llmOpenAI(temperature0, modelgpt-4), # 主模型用更强的GPT-4 chain_typestuff, retrievercompression_retriever, return_source_documentsTrue, # 返回源文档用于显示页码 chain_type_kwargs{prompt: YOUR_CUSTOM_PROMPT} # 传入自定义的严格Prompt ) # 5. 提问 result qa_chain.run(如何校准设备X的传感器) print(result[result]) for doc in result[source_documents]: print(f来源页码{doc.metadata[page]})避坑经验元数据丢失在切分和检索过程中务必确保页码等元数据能跟随文本块一起传递。LangChain的Document对象有metadata字段要善用。压缩失真负责压缩的模型如gpt-3.5-turbo-instruct可能会过度概括或歪曲原意。如果发现答案不准可以尝试去掉压缩步骤或者改用“提取关键句”而非“重写摘要”的压缩方式。成本监控这个流程涉及多次LLM调用嵌入、压缩、最终回答。务必为每个环节设置token上限和合理的模型选择并在生产环境记录每次调用的token消耗。5. 未来展望与模型选型建议长文本处理的技术正在快速演进。除了上述策略还有一些前沿方向值得关注状态化模型Stateful Models模型能够记住之前的对话或文档内容无需在每次交互时重新传入全部历史。这能从根本上改变长文本交互模式但实现难度大且对隐私和控制力提出挑战。更高效的注意力机制如Longformer、Linformer的稀疏注意力FlashAttention的IO优化以及不断改进的位置编码方案都在从模型底层推动上下文窗口的边界。智能的上下文窗口管理未来的框架或模型本身可能会集成更智能的上下文管理功能例如自动判断哪些历史信息需要保留、哪些可以丢弃或压缩。给开发者的选型建议从RAG开始对于绝大多数知识密集型应用RAG仍然是性价比最高、可控性最强的方案。先搭建一个基于语义切分和向量检索的RAG原型它能解决80%的问题。根据任务复杂度升级如果RAG因为检索失败导致效果不佳且你的任务需要全局理解考虑引入MapReduce模式。可以先从串行MapReduce开始验证效果后再考虑并行化以提升速度。谨慎使用超长上下文模型将“直接处理”作为最后的选择或用于对简单长文档的初步探索。上线前必须进行严格的、基于真实数据的性能评估和压力测试。混合策略是王道不要拘泥于单一策略。就像我们的实战案例RAG 检索后压缩就是一种高效的混合。也可以根据查询类型动态选择策略简单事实查询用RAG复杂分析查询用MapReduce。最终没有银弹。最好的长文本策略永远是深刻理解你的数据特性、用户需求以及成本约束后所做的那个量身定制的设计。它可能不那么酷炫但一定最管用。 大语言模型长文本处理策略：从RAG到上下文压缩的工程实践
1. 从“窗口”到“策略”为什么长文本是LLM的“阿克琉斯之踵”如果你最近在折腾大语言模型无论是用OpenAI的API、部署开源模型还是研究RAG应用大概率都听过“上下文窗口”这个词。它听起来像个技术参数但背后藏着的是几乎所有LLM应用都会遇到的瓶颈。简单来说上下文窗口就是模型一次性能“看到”并处理的文本长度上限。比如GPT-4 Turbo的128KClaude 3的200K或者开源Llama 3的8K、128K版本。这个数字很诱人对吧能一口气塞进一整本小说或者几十页PDF感觉所有问题都能迎刃而解。但实际用起来你会发现事情没那么简单。直接给模型扔一个100K token的长文档然后问一个细节问题模型的回答质量往往会断崖式下跌——它要么“忘记”了中间的关键信息要么开始胡言乱语把不同部分的内容张冠李戴。更别提随之而来的天价API费用和漫长的响应等待了。这背后的根本原因在于Transformer架构的核心机制。Transformer依赖的“注意力机制”其计算复杂度与序列长度的平方成正比。一个128K的序列注意力计算的开销是8K序列的256倍这不仅仅是算力成本问题更会导致模型在超长序列中难以有效分配“注意力”信息过载最终表现失准。所以“上下文窗口管理”和“长文本策略”不是一个炫技的选修课而是构建可靠LLM应用的必修课。它关乎成本、速度更关乎最终效果的生死线。本文将从一个实践者的角度拆解长文本处理的完整链条。我们不会停留在理论介绍而是深入到具体策略的选择逻辑、实操中的陷阱以及如何根据你的具体场景是文档问答、代码分析还是多轮对话来设计最经济有效的方案。无论你是刚接触提示工程的开发者还是正在为产品选择技术路线的架构师这些从真实项目中踩坑得来的经验或许能帮你少走弯路。2. Transformer架构的“内存墙”理解上下文长度的根本限制要制定有效的策略首先得明白敌人是谁。为什么增加上下文窗口这么难一切都要回到Transformer的注意力机制。2.1 注意力机制的计算开销平方级的诅咒Transformer的核心是自注意力机制。对于长度为n的输入序列模型需要计算一个n x n的注意力分数矩阵。这个计算过程无论是时间还是空间复杂度都是O(n²)。我们来算笔账假设处理一个8K token的序列注意力矩阵的元素数量是 8000² 64,000,0006400万。如果上下文窗口扩大到32K这个数字就变成了 32,000² 1,024,000,00010.24亿。而到128K时则是惊人的 128,000² 16,384,000,000163.84亿。每一次前向传播都需要存储和计算这个庞大的矩阵这对GPU显存构成了直接挑战。这就是为什么即使模型宣称支持长上下文在实际使用中你也需要一块显存巨大的显卡并且推理速度会显著变慢。注意这里说的是“原生”的全注意力机制。后续的许多优化如FlashAttention通过算法优化大幅降低了显存占用但计算量本身依然是平方级关系只是通过巧妙的IO调度隐藏了部分成本。它让长上下文变得“可能”但并没有改变“昂贵”的本质。2.2 位置编码的困境外推与内插除了计算另一个关键点是位置编码。Transformer本身不具备感知token顺序的能力需要依靠位置编码来注入序列的顺序信息。最经典的正弦位置编码Sinusoidal Positional Encoding或可学习的位置编码在训练时都是在某个固定长度比如2048或4096上进行的。当你在推理时输入一个远超训练长度的序列时模型就遇到了它从未见过的位置索引。这会导致“外推”问题模型无法正确处理这些新位置的关系性能急剧下降。为了解决这个问题社区发展出了两种主要思路外推Extrapolation直接修改位置编码的数学形式使其能够适应更长的位置。例如线性缩放Linear Scaling或NTK-aware缩放。这类方法有时能work但不够稳定尤其在需要精确理解长距离依赖的任务上容易失效。内插Interpolation在推理时将长序列的位置索引“压缩”到模型训练时见过的范围内。比如将10000的位置按比例映射到训练时的2048以内。RoPERotary Position Embedding编码因其良好的外推性常与内插法结合使用如通过调整RoPE的base值。目前许多支持长上下文的开源模型如经过微调的Llama模型都采用了此类技术。在实际选择模型时你必须关注它的技术报告它宣称的长上下文能力是通过“从头训练”得来的还是通过“位置编码内插微调”实现的后者成本低但可能在需要超长程精确推理的任务上表现不佳。2.3 KV Cache推理加速与内存的博弈在自回归生成一个一个token地输出时为了避免重复计算Transformer会缓存每个解码步中Key和Value的状态这就是KV Cache。KV Cache的大小与batch_size * sequence_length * num_layers * hidden_size相关。这意味着你的上下文越长KV Cache占用的显存就越大。对于一次处理多个长序列的批处理场景这很快就会成为瓶颈。因此一些推理优化框架如vLLM会实现KV Cache的PagedAttention像操作系统管理内存一样管理KV Cache以提高显存利用率。但即便如此长上下文对显存的压力依然是实实在在的。理解了这些底层限制我们就能明白单纯追求更大的上下文窗口数字是鲁莽的。更聪明的做法是结合上层应用策略让模型在它“舒适”的范围内工作。这就是下文要讨论的各种长文本策略。3. 核心长文本策略全景图从RAG到“无损”压缩面对长文本业界已经形成了几种主流策略范式。它们没有绝对的好坏只有是否适合你的场景。下图概括了这几种核心策略及其典型工作流程flowchart TD A[输入长文本] -- B{选择核心处理策略} B -- C[“策略一检索增强生成br(RAG)”] B -- D[“策略二层次化处理br(MapReduce/MapRerank)”] B -- E[“策略三上下文压缩br(Summarization/Filtering)”] B -- F[“策略四直接处理br(Native Long Context)”] C -- C1[文档切分brChunking] C1 -- C2[向量化与检索] C2 -- C3[将相关片段注入Prompt] C3 -- G[LLM生成最终答案] D -- D1[将长文本切分为片段] D1 -- D2[“并行处理每个片段brMap阶段”] D2 -- D3[“聚合或重排所有结果brReduce/Rerank阶段”] D3 -- G E -- E1[使用LLM或小模型进行摘要] E1 -- E2[或提取关键实体/过滤冗余] E2 -- E3[将压缩后文本注入Prompt] E3 -- G F -- F1[依赖模型自身的br长上下文能力] F1 -- G3.1 策略一检索增强生成——精度与成本的平衡术RAG是目前最流行、最实用的长文本处理方案尤其适合知识库问答、文档分析等场景。它的核心思想不是让模型记住所有内容而是建立一个“外部记忆库”在需要时快速检索相关片段。工作流程与关键抉择文档切分Chunking这是RAG的基石也是第一个大坑。常见的错误是盲目使用固定大小的切分如512个token。为什么不能盲目切分固定切分会无情地割裂完整的句子、段落甚至表格导致检索到的片段语义不完整严重影响后续效果。如何正确切分应采用基于语义的切分。例如使用langchain的RecursiveCharacterTextSplitter并设置separators为[\n\n, \n, 。, , , , , , ]优先按段落、句子切分。同时可以设置一个chunk_size如1000和chunk_overlap如200重叠部分能有效防止关键信息被切在边界丢失。进阶技巧对于高度结构化的文本如Markdown、代码可以按标题# ##或函数/类定义进行切分这能更好地保持上下文。检索Retrieval如何找到最相关的片段向量检索主流将文本块编码为向量存入向量数据库如Chroma, Pinecone, Weaviate。查询时将问题也编码为向量计算余弦相似度返回最相似的K个片段。它的优点是能捕捉语义相似性。关键词检索补充使用BM25等算法。它在寻找精确术语匹配时非常有效是向量检索的良好补充。最佳实践往往是“混合检索”同时进行向量检索和关键词检索然后对结果进行重排序Rerank。重排序Rerank初检返回的Top K个结果比如20个可能包含一些语义相关但实际对回答问题无用的片段。使用一个更小、更快的重排序模型如BAAI/bge-reranker系列对这20个结果进行精排只选出最相关的2-3个注入Prompt能极大提升答案质量并节省上下文窗口。RAG的优劣分析优点精度高只注入相关信息、成本低每次调用模型处理的文本短、可解释性强可以追溯答案来源。缺点架构复杂需要维护向量数据库、嵌入模型等且存在“检索失败”的单点风险——如果关键信息没被检索到模型再强也无能为力。适用场景文档问答、知识库聊天机器人、需要引用来源的场景。3.2 策略二层次化处理——分而治之的经典哲学当任务需要对整个长文档进行整体分析、总结或推理时RAG可能力有不逮。这时层次化处理模式就派上用场了。其代表是MapReduce和MapRerank。MapReduce模式详解Map映射将长文档切分成多个有重叠的片段。然后并行或串行地将每个片段连同你的问题或总结指令发送给LLM要求它对每个片段生成一个“局部答案”或“摘要”。Reduce归约收集所有片段的“局部答案”将它们组合成一个新的、较短的文本。最后将这个组合文本再次发送给LLM要求它基于所有局部信息生成一个全局的、连贯的最终答案。实操中的陷阱与技巧并行与成本并行调用能极大缩短时间但会瞬间消耗大量API配额。对于OpenAI等按token计费的API需谨慎控制并发数。指令设计给Map阶段的指令至关重要。例如如果你要总结一篇技术论文给Map阶段的指令可以是“请总结本片段的核心论点、实验方法和数据结论。” 而Reduce阶段的指令则是“你收到了来自同一篇论文各个部分的总结。请整合它们写出一篇涵盖引言、方法、结果、讨论的完整论文摘要。”信息丢失Reduce阶段模型需要消化多个局部答案可能丢失细节。可以在Map阶段要求模型同时输出“关键引用”如原文中的关键句子并在Reduce的Prompt中提供这些引用。MapRerank模式这是MapReduce的变体适用于答案明确、需要选择最佳答案的场景如选择题、事实核查。在Map阶段让模型对每个片段生成一个答案并给出一个置信度分数。在Reduce阶段直接选择置信度最高的答案或者对所有答案进行投票。优劣分析优点能处理需要全局理解的任务比直接处理整个长文档更可靠。缺点流程复杂调用次数多成本高且最终答案质量严重依赖Map阶段的质量。适用场景长文档摘要、跨多个章节的综合问答、对全文进行情感或主题分析。3.3 策略三上下文压缩——主动为模型减负这个策略的核心思想是在将长文本交给核心LLM处理之前先对其进行预处理剔除冗余信息保留精华。这就像给模型看的“简报”。主要压缩手段摘要Summarization使用一个LLM可以是更小、更便宜的模型先对原文进行摘要。然后将摘要而非原文送入主模型处理。这里的一个技巧是“渐进式摘要”对于极长的文本可以先分段摘要再对摘要进行摘要。过滤Filtering根据任务目标只提取相关部分。例如如果你只关心文档中的财务数据可以用一个小的NER命名实体识别模型或规则提取出所有货币、百分比、日期等实体和周围的句子。提取关键句使用无监督方法如TextRank或有监督的小模型从原文中提取出最关键的几个句子。一个实用的混合方案在RAG的检索环节之后对检索到的相关片段进行压缩。例如检索到5个相关段落总计3000token。在注入最终Prompt前先用GPT-3.5-Turbo对这5个段落做一个简洁摘要压缩到800token再交给GPT-4进行最终回答。这样既能保留核心信息又节省了昂贵模型的上下文开销。优劣分析优点直接降低主模型的token消耗节省成本和时间。缺点存在信息损失的风险压缩模型本身也可能出错。适用场景成本敏感型应用或当主模型上下文窗口有限时的备选方案。3.4 策略四直接处理——信任模型的“原生”能力这就是最简单粗暴的方法找一个宣称支持超长上下文如128K、200K的模型把整个文档和问题一起丢进去。随着模型能力的提升这正在成为更多场景的可行选项。何时可以考虑直接处理任务简单任务不需要非常精细的、跨超长距离的推理。文档结构清晰文档本身段落分明模型容易定位。成本不敏感或一次性任务对于内部分析、研究等非高频场景。模型经过验证你已通过测试确认该模型在类似长度和任务上表现可靠。必须进行的“压力测试”直接使用前务必设计测试用例。不要用一篇普通文章测试要用你业务中最复杂、最长、信息密度最高的文档。问一些需要结合文档开头、中间和结尾信息才能回答的问题。观察模型是否会出现“中间丢失”现象即对文档中间部分的信息记忆或理解变差。优劣分析优点架构简单无需复杂的预处理流水线。理论上模型能利用全文信息。缺点成本最高速度可能最慢且模型在超长上下文下的实际性能存在不确定性。适用场景对简单长文档进行一次性分析、作为其他策略的对比基线。4. 实战构建一个混合策略的长文档QA系统理论说再多不如动手搭一个。下面我们设计一个兼顾精度、成本和复杂度的混合策略系统用于处理长达数百页的技术手册PDF的问答。系统目标用户上传PDF手册可以任意提问。系统需要返回准确答案并注明答案来源的页码和章节。架构设计混合RAG 压缩文档解析与增强切分使用PyPDF2或pdfplumber解析PDF提取文本和元数据如页码。采用语义切分但为每个文本块额外附加“页码”和“上级标题”作为元数据。两级检索系统第一级粗筛向量检索将文本块向量化存入ChromaDB。用户提问时进行向量相似度检索返回Top 10相关块。第二级精筛重排序关键词过滤使用重排序模型对Top 10进行精排。同时对用户问题提取关键词在Top 10中筛选出同时包含关键词的块提升精确匹配。最终选出置信度最高的Top 3文本块。上下文压缩与组装将Top 3文本块及其元数据页码、标题组合。如果组合后token数超过主模型上下文限制例如GPT-4的8K则调用GPT-3.5-Turbo指令为“请根据以下来自技术手册的片段提取出与问题‘[用户问题]’最相关的信息并保持原文措辞。请以列表形式输出每条信息后注明原页码。” 将返回的压缩列表作为最终上下文。提示词工程与最终回答将压缩后的上下文、用户问题以及严格的指令组装成Prompt发送给主模型如GPT-4。你是一位技术手册专家。请严格根据以下提供的上下文片段来回答问题。如果上下文中的信息不足以回答问题请直接说“根据提供的信息无法回答”。 上下文片段附页码 [压缩后的上下文列表] 问题[用户问题] 请给出准确、简洁的答案并在答案后以【页码X】的形式注明信息来源。关键代码片段示意使用LangChain简化流程from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.vectorstores import Chroma from langchain.embeddings import OpenAIEmbeddings from langchain.llms import OpenAI from langchain.chains import RetrievalQA from langchain.retrievers import ContextualCompressionRetriever from langchain.retrievers.document_compressors import LLMChainExtractor # 1. 加载和切分文档 text_splitter RecursiveCharacterTextSplitter( chunk_size1000, chunk_overlap200, separators[\n\n, \n, 。, , , , , , ] ) docs text_splitter.split_documents(your_documents) # your_documents需包含page元数据 # 2. 创建向量库 vectorstore Chroma.from_documents(docs, OpenAIEmbeddings()) # 3. 创建压缩检索器使用一个更便宜的LLM进行压缩 base_retriever vectorstore.as_retriever(search_kwargs{k: 10}) compressor LLMChainExtractor.from_llm(OpenAI(temperature0, modelgpt-3.5-turbo-instruct)) # 使用更便宜的模型做压缩 compression_retriever ContextualCompressionRetriever(base_compressorcompressor, base_retrieverbase_retriever) # 4. 创建QA链 qa_chain RetrievalQA.from_chain_type( llmOpenAI(temperature0, modelgpt-4), # 主模型用更强的GPT-4 chain_typestuff, retrievercompression_retriever, return_source_documentsTrue, # 返回源文档用于显示页码 chain_type_kwargs{prompt: YOUR_CUSTOM_PROMPT} # 传入自定义的严格Prompt ) # 5. 提问 result qa_chain.run(如何校准设备X的传感器) print(result[result]) for doc in result[source_documents]: print(f来源页码{doc.metadata[page]})避坑经验元数据丢失在切分和检索过程中务必确保页码等元数据能跟随文本块一起传递。LangChain的Document对象有metadata字段要善用。压缩失真负责压缩的模型如gpt-3.5-turbo-instruct可能会过度概括或歪曲原意。如果发现答案不准可以尝试去掉压缩步骤或者改用“提取关键句”而非“重写摘要”的压缩方式。成本监控这个流程涉及多次LLM调用嵌入、压缩、最终回答。务必为每个环节设置token上限和合理的模型选择并在生产环境记录每次调用的token消耗。5. 未来展望与模型选型建议长文本处理的技术正在快速演进。除了上述策略还有一些前沿方向值得关注状态化模型Stateful Models模型能够记住之前的对话或文档内容无需在每次交互时重新传入全部历史。这能从根本上改变长文本交互模式但实现难度大且对隐私和控制力提出挑战。更高效的注意力机制如Longformer、Linformer的稀疏注意力FlashAttention的IO优化以及不断改进的位置编码方案都在从模型底层推动上下文窗口的边界。智能的上下文窗口管理未来的框架或模型本身可能会集成更智能的上下文管理功能例如自动判断哪些历史信息需要保留、哪些可以丢弃或压缩。给开发者的选型建议从RAG开始对于绝大多数知识密集型应用RAG仍然是性价比最高、可控性最强的方案。先搭建一个基于语义切分和向量检索的RAG原型它能解决80%的问题。根据任务复杂度升级如果RAG因为检索失败导致效果不佳且你的任务需要全局理解考虑引入MapReduce模式。可以先从串行MapReduce开始验证效果后再考虑并行化以提升速度。谨慎使用超长上下文模型将“直接处理”作为最后的选择或用于对简单长文档的初步探索。上线前必须进行严格的、基于真实数据的性能评估和压力测试。混合策略是王道不要拘泥于单一策略。就像我们的实战案例RAG 检索后压缩就是一种高效的混合。也可以根据查询类型动态选择策略简单事实查询用RAG复杂分析查询用MapReduce。最终没有银弹。最好的长文本策略永远是深刻理解你的数据特性、用户需求以及成本约束后所做的那个量身定制的设计。它可能不那么酷炫但一定最管用。