大模型上下文长度优化实战从Token管理到检索增强生成的完整技术路线上下文长度的三个核心矛盾2023年到2026年大模型的上下文窗口Context Window从32K TokenGPT-4-32K扩展到200万字Claude可以在一个上下文里放约1500页的书。但上下文窗口越大不意味着你应该把尽可能多的内容都塞进去。这里有三个核心矛盾矛盾一成本与上下文长度的线性关系绝大多数大模型API按Token计费且输入Token和输出Token都计费。Claude的输入Token价格是$15/百万Token如果你每次调用都塞50万字上下文单次调用成本约$75——这个成本只有企业级产品才能承受。矛盾二模型注意力随上下文长度增加而稀释研究如N个 needle in a haystack测试表明当上下文超过一定长度通常约50万字Token模型对上下文开头和中间的信息的注意力会明显下降。表现为你明明在上下文里提供了相关信息但模型生成的回答忽略了这些信息。矛盾三长上下文导致响应延迟增加大模型处理长上下文需要更多计算量响应时间随上下文长度增加而线性增加。如果你的产品需要实时交互如AI聊天助手长上下文会导致用户体验变差。实战一Prompt压缩与上下文剪枝不是所有用户输入的历史消息都需要完整保留在上下文里。很多内容是冗余的、重复的、或已经被后续对话覆盖了的。策略一滑动窗口Sliding Window最朴素的策略只保留最近N轮对话在上下文里。旧的对话被滑出窗口。实现在LangChain或类似框架里from langchain.memory import ConversationBufferMemory # 只保留最近10轮对话 memory ConversationBufferMemory(k10)这个策略的缺点是可能丢失重要的早期信息——比如用户在第1轮说了我的产品是AI写作工具到第11轮时这个信息就被滑出窗口了。策略二摘要压缩Summary Compression更智能的策略当对话历史超过一定长度时用模型把旧对话压缩成一段摘要然后把摘要放在上下文里代替被压缩的详细对话。实现from langchain.memory import ConversationSummaryMemory from langchain.chat_models import ChatAnthropic llm ChatAnthropic() memory ConversationSummaryMemory(llmllm) # 当对话历史超过一定Token数时自动调用LLM生成摘要这个策略让重要信息不会丢失但代价是需要额外调用一次LLM来生成摘要增加了成本和延迟。策略三上下文剪枝Context Pruning更精细的策略分析对话历史里每条消息的重要性只保留最重要的消息在上下文里。重要性可以用以下信号判断用户显式引用如你刚才说的X是什么意思→ 被引用的消息重要包含实体/关键词如产品名称、技术名词→ 包含专业术语的消息重要导致后续对话方向改变如用户纠正了模型的回答→ 转折点的消息重要我自己的实现是给对话历史里的每条消息打一个重要性分0-10然后只保留分数7的消息在上下文里。这个分数用一个小模型如GPT-3.5或Claude Haiku快速预测成本很低。实战二RAG检索增强生成的完整技术路线当你的应用场景是基于私有知识库回答用户问题时如我们产品的退款政策是什么不应该把整个知识库都塞进上下文。正确的做法是RAGRAG的三个核心步骤索引阶段把知识库如产品文档、帮助中心文章切成片段Chunk把每个片段转换成向量Embedding存储到向量数据库如Pinecone、Weaviate、或PostgreSQL的pgvector扩展。检索阶段用户提问时把问题也转换成向量然后在向量数据库里搜索和最相关问题向量最相似的Top-K个知识片段。生成阶段把检索到的Top-K个片段放进上下文让LLM基于这些片段回答用户问题。技术实现细节以Pinecone OpenAI Embeddings为例步骤一创建向量索引import openai from pinecone import Pinecone, ServerlessSpec # 初始化Pinecone pc Pinecone(api_keyyour-pinecone-key) index pc.Index(product-docs) # 把文档切片如每段500字 docs [ 我们的退款政策规定用户在购买后14天内可以申请全额退款..., AI生成的内容版权归用户所有我们不会主张任何权利..., # ... 更多文档片段 ] # 生成Embedding embeddings openai.Embedding.create( modeltext-embedding-3-small, inputdocs ) # 上传到Pinecone vectors [ (fdoc_{i}, embedding.embedding, {text: doc}) for i, (doc, embedding) in enumerate(zip(docs, embeddings.data)) ] index.upsert(vectorsvectors)步骤二检索相关片段def retrieve_relevant_docs(query: str, top_k: int 5): # 把查询转成向量 query_embedding openai.Embedding.create( modeltext-embedding-3-small, inputquery ).data[0].embedding # 在Pinecone里搜索最相似的Top-K片段 results index.query( vectorquery_embedding, top_ktop_k, include_metadataTrue ) return [match.metadata[text] for match in results.matches]步骤三基于检索结果生成回答def answer_question(query: str): # 检索相关文档片段 relevant_docs retrieve_relevant_docs(query, top_k3) # 构造上下文 context \n\n.join(relevant_docs) # 调用LLM response openai.ChatCompletion.create( modelgpt-4-turbo, messages[ {role: system, content: f你是产品助手。根据以下文档片段回答用户问题。如果文档里没有相关信息说我不确定请联系supportproduct.com。\n\n文档片段\n{context}}, {role: user, content: query} ] ) return response.choices[0].message.contentRAG的核心优势上下文长度可控只放Top-3到Top-5个片段约2000-3000 Token成本可控不需要每次都塞几万字的私有知识库准确性高模型基于检索到的真实文档回答不是幻觉实战三混合上下文策略工作记忆 长期记忆对于需要长期个性化的AI产品如AI写作助手应该记住用户的写作风格偏好单纯的对话历史或RAG都不够。正确的架构是混合上下文工作记忆Working Memory当前对话的最近几轮如最近5轮完整放在上下文里。长期记忆Long-term Memory用向量数据库存储用户的历史偏好、历史对话要点在每次对话开始时检索相关记忆放进上下文。外部知识External Knowledge用RAG检索相关文档。技术实现MemGPT的思路class HybridMemorySystem: def __init__(self): self.working_memory [] # 最近5轮对话 self.long_term_db Pinecone(indexuser-memories) self.knowledge_db Pinecone(indexproduct-docs) def retrieve_context(self, user_id: str, query: str): # 1. 工作记忆完整保留 working_context self.working_memory[-5:] # 2. 长期记忆检索相关 user_memories self.long_term_db.query( vectorembed(query), filter{user_id: user_id}, top_k3 ) # 3. 外部知识RAG knowledge self.knowledge_db.query( vectorembed(query), top_k3 ) # 组装上下文 context { working_memory: working_context, user_memories: [m.text for m in user_memories], knowledge: [k.text for k in knowledge] } return context def update_working_memory(self, message: dict): self.working_memory.append(message) if len(self.working_memory) 10: # 当工作记忆超过10条压缩最早的5条成摘要 old_messages self.working_memory[:5] summary summarize(old_messages) # 把摘要存到长期记忆 self.long_term_db.upsert([(f{user_id}_mem_{timestamp}, embed(summary), {text: summary, user_id: user_id})]) # 删除已压缩的消息 self.working_memory self.working_memory[5:]成本优化从按Token计费到按价值计费最后谈一个现实问题长上下文的成本优化。策略一用更便宜的模型做上下文压缩不需要用GPT-4或Claude Opus来做把长文档压缩成摘要的任务。用GPT-3.5或Claude Haiku就够了成本只有前者的1/10。策略二缓存常见查询的上下文如果你的产品有很多重复或高度相似的问题如你们的产品支持Markdown格式吗可以缓存这个查询的检索结果LLM回答。下次有类似查询时直接返回缓存不调用LLM。实现用向量数据库做查询相似度搜索——如果新查询和已缓存查询的相似度0.95直接返回缓存回答。策略三让用户选择上下文深度有些用户的问题是简单的如今天天气怎么样有些是复杂的如分析我过去6个月的写作数据找出我的写作效率变化趋势。你可以在UI上提供简单模式和深度分析模式——简单模式只用短上下文最近1轮对话基础系统提示深度模式用长上下文过去10轮对话用户数据分析。这样80%的简单查询成本很低20%的深度查询成本较高但用户愿意等待。成本实测数据我的产品策略平均上下文长度平均成本/查询无优化总是塞完整上下文85,000 Token$1.28滑动窗口保留最近5轮12,000 Token$0.18RAG检索Top-3片段3,500 Token$0.05混合上下文工作长期RAG8,000 Token$0.12结论长上下文能力是LLM的重要进步但不应该无脑用。真正的竞争力在于**在成本、准确性、响应速度之间找到最优的上下文管理策略**。2026年的AI产品开发上下文工程Context Engineering会成为和Prompt工程一样重要的技能。