什么是上下文工程
1️⃣ 考察意图
面试官想考察你是否能清晰区分“上下文工程”与“Prompt Engineering”的边界，并理解其在RAG、长对话Agent中的核心价值。这属于概念辨析+工程取舍类问题。刁钻点在于：很多人会把上下文工程等同于“写更长的Prompt”或“简单拼接历史”，而面试官真正想看的是你对上下文窗口的预算分配、信息密度优化、动态注入策略的系统性认知。答好了能展示你对LLM输入侧瓶颈的深刻理解，以及从“写Prompt”到“设计上下文系统”的工程思维跃迁。
2️⃣ 标准答
上下文工程（Context Engineering）是指对LLM输入上下文的长度、结构、信息密度进行系统性设计和优化，以在有限的上下文窗口内最大化输出质量。它不等于Prompt Engineering——Prompt Engineering聚焦单条指令的措辞、格式、角色设定；而上下文工程关注的是整个输入序列的编排，包括历史对话、检索文档、工具调用记录、系统指令等。
核心要素与关键技术：
- 上下文窗口预算分配：LLM的上下文窗口（如GPT-4的128K、Claude的200K）是有限资源。需要按优先级分配：系统指令（固定占5-10%）、核心用户查询（20-30%）、检索到的知识片段（40-50%）、历史对话摘要（10-20%）。工程取舍：给检索片段更多空间会提升事实准确性，但可能压缩历史记忆导致对话连贯性下降——需要根据场景动态调整，比如客服场景优先历史，问答场景优先检索。
- 动态注入与检索增强（RAG）：不是把所有知识都塞进上下文，而是通过检索器（如BM25+Embedding混合检索）实时拉取最相关的top-k片段。实际落地的坑：检索到的片段可能冗余或冲突。解法：引入重排序器（Reranker，如Cohere Rerank 3或BGE-Reranker）对检索结果二次打分，只保留前3-5个高置信度片段；同时用去重策略（MinHash或基于embedding的相似度阈值过滤）避免重复信息挤占窗口。
- 上下文压缩与摘要：长对话历史不能直接拼接，否则会稀释注意力。常用策略：① 滑动窗口：只保留最近N轮对话（如10轮），更早的历史用LLM生成的摘要替代；② 分层摘要：按时间或主题对历史做多级摘要（如“用户今天问了3个技术问题，2个关于API，1个关于部署”），在需要时展开细节。坑：摘要可能丢失关键实体（如订单号、日期）。解法：在摘要中强制保留结构化字段（如“订单ID: #12345”），用正则或NER模型提取后注入摘要模板。
- 指令层次设计：上下文中的指令需要分层——最顶层是系统级约束（不可违背的安全规则、输出格式），中间层是任务级指令（当前任务的目标），底层是示例或few-shot。为什么这么做：避免用户输入覆盖系统指令（即“Prompt注入”）。实践中用XML标签或Markdown标题分隔层次，并在系统指令中明确“以下为不可修改的规则”。
- 与Prompt Engineering的边界：Prompt Engineering是“写一条好指令”，上下文工程是“设计整个输入系统”。例如，一个多轮Agent的上下文工程包括：① 系统指令（角色+规则）；② 工具调用历史（JSON格式）；③ 用户当前问题；④ 检索到的知识片段；⑤ 历史对话摘要。而Prompt Engineering只负责优化第①部分中的措辞。
实际落地的坑 + 解法：在构建长对话Agent时，发现上下文越长，模型越容易“迷失在中间”（Lost in the Middle现象）。解法：① 将最重要的信息（如用户当前问题、最新检索结果）放在上下文开头和结尾；② 对中间部分用注意力掩码（如FlashAttention的局部注意力）强制模型关注关键位置；③ 对超过窗口长度的内容做分块+并行处理，用多个LLM调用分别处理不同块，再汇总结果。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，上下文工程的定义——它是对LLM输入上下文的长度、结构、信息密度进行系统性设计，区别于Prompt Engineering的单条指令优化。第二，核心技术——包括上下文窗口预算分配、动态检索注入、历史压缩与摘要、指令层次设计。第三，实际落地要点——比如用Reranker解决检索冗余、用分层摘要保留关键实体、用注意力位置优化对抗Lost in the Middle。总结一句：上下文工程是把LLM的输入从‘一段文字’升级为‘一个精心编排的信息系统’。”
4️⃣ 高频追问 & 应对
追问 1：上下文工程和RAG有什么区别？RAG不就是检索+拼接吗？
核心区别在于RAG是上下文工程的一种实现手段，但上下文工程更底层。RAG只解决“检索什么”的问题，而上下文工程还要解决“检索到的内容怎么放、放多少、和别的信息怎么交互”。例如，RAG可能直接拼接top-5文档，但上下文工程会考虑：① 这些文档是否和当前对话历史冲突？② 是否需要压缩成摘要再放入？③ 是否需要按时间或相关性排序？④ 如果窗口不够，哪些文档可以丢弃？所以RAG是上下文工程的一个子集，上下文工程是更完整的输入编排系统。
追问 2：如果上下文窗口无限大，上下文工程还有必要吗？
即使窗口无限大，上下文工程依然必要，原因有二：一是信息密度问题——无限窗口意味着可以塞入海量噪声，但模型对噪声的鲁棒性有限，实验表明（如Lost in the Middle论文）无关信息会显著降低准确率；二是计算成本——Transformer的注意力计算是O(n²)，窗口越大推理延迟和成本越高。所以上下文工程的核心不是“塞得下”，而是“塞得对”。即使窗口无限，也需要做相关性排序、去重、摘要压缩来保证输出质量。
追问 3：你提到用摘要压缩历史，但摘要本身可能丢失细节，怎么权衡？
这是一个典型的精度-压缩率trade-off。我的做法是分层压缩：对最近5轮对话保留完整文本（高精度），对5-20轮对话用LLM生成结构化摘要（保留实体、时间、关键动作），对20轮以上的对话只保留统计摘要（如“用户共提问23次，涉及3个主题”）。同时，在摘要中嵌入可展开的锚点——比如摘要里写“用户曾询问订单#12345的状态”，当用户再次提到该订单时，触发检索器从完整历史中拉取该轮对话的原始文本。这样既压缩了上下文，又保留了关键细节的可追溯性。
5️⃣ 避坑 · 常见错误答法
- ❌ 把上下文工程等同于“写更长的Prompt”或“把历史对话全部拼接” → ✅ 正确切入：上下文工程的核心是信息筛选与编排，不是简单堆砌。要强调预算分配、动态注入、压缩策略。
- ❌ 认为上下文工程只适用于RAG场景，忽略多轮对话和Agent → ✅ 正确切入：上下文工程适用于所有需要管理LLM输入的场景，包括长对话记忆、工具调用历史、多模态输入融合等。
- ❌ 只谈概念不谈工程取舍，比如“用摘要压缩历史”但不提精度损失 → ✅ 正确切入：每个技术选择都要给出trade-off分析，比如“摘要压缩节省空间但可能丢失实体，所以需要分层策略”。
6️⃣ 简历呼应
- 如果你有RAG项目：从“检索结果与对话历史的冲突处理”切入，举例你在项目中如何用上下文工程解决检索片段和用户历史意图不一致的问题，比如引入上下文一致性校验模块。
- 如果你只做过传统NLP：用“信息检索中的查询扩展与文档排序”类比，说明上下文工程类似于对检索系统的查询和文档进行联合优化，强调从“单次匹配”到“多轮上下文感知”的思维迁移。
- 如果你是校招无项目：聚焦论文复现，比如复现“Lost in the Middle”实验，并设计一个简单的上下文重排算法来验证位置对模型输出的影响，展示你对上下文工程核心问题的理解。
- 《Lost in the Middle: How Language Models Use Long Contexts》（Liu et al., 2023）
- 《RAG vs. Long Context: A Comparative Study》（Anthropic, 2024）
- 《Context Compression for Long-Form Dialogue》（Xu et al., 2023）
- FlashAttention: Fast and Memory-Efficient Exact Attention（Dao et al., 2022）
- Cohere Rerank 3 官方文档与最佳实践