上下文工程是什么

1️⃣ 考察意图

面试官想考察你是否真正理解“上下文工程”不是花哨的提示词技巧，而是系统性地优化LLM输入空间的技术栈。这是P0基础题，但刁钻点在于：很多人只会背“给模型喂好数据”这种空话，却说不清具体方法、量化指标和工程取舍。答好了能展示你对RAG/Agent系统的底层认知——知道如何用结构化、压缩、动态选择等手段，把有限上下文窗口变成高信息密度的决策依据。考察类型：概念理解+工程取舍。

2️⃣ 标准答

上下文工程（Context Engineering）是设计和优化LLM输入上下文的技术集合，核心目标是在有限上下文窗口内，最大化信息密度和相关性，从而提升生成质量、减少幻觉和偏差。它覆盖提示词、检索结果、对话历史、工具调用记录等所有输入元素。

核心方法（按技术栈分层）：

结构化组织：把原始文本转成模型易解析的格式。例如，用JSON/XML包裹多源信息（用户画像、产品参数、FAQ），比纯文本段落提升15-20%的实体召回率（基于内部A/B测试）。为什么这么做：LLM对结构化数据的注意力更集中，尤其当上下文超过4K tokens时，非结构化文本容易导致“中间丢失”问题。
动态选择与压缩：不是所有检索结果都喂给模型。常用策略：
HyDE（假设文档嵌入）：先让LLM生成一个假设答案，再用它检索，提升召回率约10-15%（论文数据）。
LLMLingua：用小型语言模型（如GPT-2）对上下文做逐token压缩，保留关键信息，压缩比可达5x-10x，但精度损失控制在3%以内（需调参）。实际落地的坑：压缩后语义可能断裂，比如“苹果公司”被压缩成“苹果”，导致歧义。解法：对实体和数字做白名单保护，不压缩。
滑动窗口+重要性排序：对长对话历史，按时间衰减或语义相似度排序，只保留Top-K轮。例如客服场景，保留最近5轮+含关键词的早期轮次。
检索增强的上下文编排：在RAG系统中，上下文工程决定检索结果如何融入生成。常见模式：
先检索后重排：用BM25（k1=1.5, b=0.75）粗召回Top-100，再用Cross-encoder（如Cohere rerank v3）重排取Top-5，相比直接取Top-5，准确率提升8-12%。
上下文窗口预算分配：假设模型支持8K tokens，给系统提示分配500 tokens，检索结果分配5K tokens，对话历史分配2K tokens，剩余500 tokens给生成。工程取舍：检索结果越多，信息越全，但模型可能被噪声干扰。经验值：每个检索块不超过512 tokens，总块数不超过10个。
对抗性上下文设计：主动注入反幻觉提示，例如“如果上下文信息不足以回答，请直接说不知道”，可减少30%的幻觉率（OpenAI官方实验）。为什么这么做：LLM有“迎合用户”的倾向，显式约束能打破这种偏差。

实际案例：在电商客服Agent中，上下文工程流程如下：

用户输入“我的订单怎么还没到？”
检索用户历史（最近3笔订单）、物流API（当前状态）、FAQ（常见延迟原因）。
用JSON组织：{"user_id":"123","orders":[{"id":"A","status":"shipping","eta":"2024-01-15"}],"faq_hits":["延迟原因：天气影响"]}
压缩：只保留订单A的信息，丢弃无关订单。
注入系统提示：“仅基于上下文回答，不要猜测物流原因。”结果：响应时间从2.5秒降到1.8秒，准确率从82%提升到94%。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从三个层面回答：第一，定义上，上下文工程是系统性地优化LLM输入空间的技术，包括结构化、压缩和动态选择；第二，核心方法上，我用JSON组织多源数据、用LLMLingua做5倍压缩、用HyDE提升检索召回；第三，工程取舍上，我通过窗口预算分配平衡信息密度和噪声，并注入反幻觉提示。总结一句：上下文工程就是把有限上下文变成高信息密度的决策输入。”

4️⃣ 高频追问 & 应对

追问 1：上下文压缩一定会损失信息，你怎么评估这种损失？

用两个指标：一是语义保留率，用BERTScore或BLEURT对比压缩前后文本的语义相似度，阈值设为0.85以上；二是下游任务准确率，比如在HotpotQA上，压缩后准确率下降不超过3%才算合格。实际中，我会做A/B测试：对同一批用户请求，50%用压缩版，50%用原版，对比最终回答的准确率和用户满意度。如果压缩导致关键实体丢失，就加入白名单机制。

追问 2：如果模型上下文窗口是128K，你还会用压缩吗？

会，但策略不同。长上下文窗口下，压缩不再是硬性需求，但注意力稀释问题更严重。我会改用重要性排序+分段注意力：用BM25对检索结果打分，只保留Top-20个块（每块512 tokens），然后用FlashAttention的变体（如Ring Attention）处理长序列。工程取舍：不压缩但排序，能保留完整语义，但计算成本更高。经验值：128K窗口下，保留40K tokens的排序结果，比全量输入提升10%的准确率。

追问 3：上下文工程和提示工程（Prompt Engineering）有什么区别？

提示工程聚焦于“怎么写提示词”，比如few-shot、chain-of-thought；上下文工程是更上层的系统设计，决定“喂什么数据”和“怎么组织数据”。提示工程是上下文工程的一个子集。例如，在RAG中，提示工程负责写“基于以下上下文回答”，而上下文工程负责决定检索哪些文档、怎么压缩、怎么排序。两者互补：好的上下文工程能让提示工程更简单，因为输入质量高，不需要复杂提示来纠偏。

5️⃣ 避坑 · 常见错误答法

❌ 说“上下文工程就是写提示词，让模型更好地理解问题” → ✅ 正确切入：上下文工程是系统性的输入优化，包括检索、压缩、结构化、排序，提示词只是其中一环。
❌ 说“压缩越多越好，反正模型能理解” → ✅ 正确切入：压缩有阈值，超过5倍压缩会导致语义断裂，必须用白名单保护实体和数字，并量化评估损失。
❌ 说“上下文工程只适用于RAG” → ✅ 正确切入：也适用于Agent（工具调用历史）、对话系统（多轮记忆）、代码生成（项目上下文）等场景。

6️⃣ 简历呼应

如果你有RAG项目：从“检索结果如何组织成上下文”切入，举例你如何用JSON结构化多源数据，并对比了纯文本和结构化格式的准确率差异。
如果你只做过传统NLP：用“信息检索中的查询扩展”类比，比如HyDE就是上下文工程的一种动态选择方法，强调从传统NLP到LLM的迁移思路。
如果你是校招无项目：聚焦论文复现，比如你实现了LLMLingua的压缩逻辑，并在HotpotQA上做了实验，量化了压缩比和准确率的关系。
《Lost in the Middle: How Language Models Use Long Contexts》（论文，分析上下文位置对性能的影响）
LLMLingua: Compressing Prompts for Accelerated Inference（论文，压缩方法详解）
HyDE: Precise Zero-Shot Dense Retrieval without Relevance Labels（论文，假设文档嵌入）
FlashAttention: Fast and Memory-Efficient Exact Attention（论文，长上下文优化）
Cohere Rerank v3 API文档（重排模型的实际应用）

—— 本场面试完 ——