茶桁.MAMT

本入门指南聚焦于构建真实世界 LLM 应用时最重要的挑战之一：上下文窗口管理。 大型语言模型（LLM）正迅速改变我们构建软件、处理知识及自动化复杂任务的方式。与此同时，LLM 生态演进之快，以至于我们很难把真正有用的工程工具从噪声中分辨出来。 当应用变得越来越复杂时，决定向 LLM 提供哪些信息、省略哪些信息，以及如何结构化并维护上下文，就变得对可靠性、性能和成本至关重要。在本文中，你将学到管理上下文的业界前沿实用方法，包括：上下文选择、压缩、摘要、检索、记忆，以及避免上下文过载和"中途丢失（lost-in-the-middle）“现象的技巧。目标是为你在构建真实世界 LLM 应用时理解并运用上下文窗口管理，提供一个实用的起点。每一节都会介绍相关的博客和实用工具，你可以亲自尝试和使用。 如果你觉得这篇文章有帮助，欢迎关注我，因为我会写更多数据科学的内容！我建议你亲自尝试本文中的动手示例，这能帮你学得更快、理解更深、记得更牢。泡杯咖啡，享受乐趣！ LLM 全景概览 要理解快速演进的 LLM 生态，最好把眼光放到单个 LLM 模型之外，去理解围绕它们构建的工具与工作流。已经很清楚的一点是：这个大型语言模型本身充当着整个系统的"计算核心”，而它的周围需要许多构建模块。下图给出了 LLM 全景的概览，可以看到现代 LLM 技术栈的开发涉及众多组件。本文聚焦于上下文管理以及（外部）数据的处理。在下一节，我们会看到一些帮助我们进行窗口上下文管理的工具与技术。你将学习如何为系统指令和结构化输出构建上下文架构。 切勿低估上下文窗口的重要性 与 LLM 协作感觉很直观，这既是优点也是缺点；你随便聊几句，它就能返回结果。 LLM 可以极其强大，但其输出在很大程度上取决于它所收到的系统、指令、上下文、技能与约束。提示工程（Prompting）与其说是找到完美的问题，不如说是与模型一起设计一套可靠的架构。其目标是让 LLM 更可预测、更可靠、更高效。而这一切都要从上下文窗口说起。 提示工程与其说是寻找完美的问题，不如说是与模型一起设计一套可靠的架构。 总上下文窗口大小就是限制 上下文窗口的重要性不容低估；它是你 LLM 流水线中最重要的部分之一，因为它是模型的临时工作记忆。然而，就像真正的记忆一样，上下文窗口空间有限，却需要容纳几十种不同的功能。即便是支持超大上下文窗口（比如 200K token）的模型，也容易被推到实际极限。结果，关键段落（例如文档中的某部分）可能被隐式压缩或忽略，导致推理不完整。下图列出了一些最重要的组成部分，即：密集的系统指令、标准与严格的输出格式 schema，以及以块（chunk）形式存在的文档、聊天历史等等。 可以把上下文窗口看作你拥有的内存（RAM）大小。一旦超出它的极限，它就会崩溃并返回错误。 当你使用 OpenAI、Anthropic 或 Kimi K3 时，很可能拥有 1M token 的上下文窗口。这很棒，但在解决庞大而复杂的任务时，把所有信息都塞进聊天窗口（所谓的"单体式 monolithic"方法）有诸多缺点。详细的拆解和其他细节推演可以在<构建个人 Agentic 系统的分步指南>这篇文章里找到。下一节我们会介绍如何有效利用上下文窗口的方法，其中系统和指令是关键。 上下文管理：可靠且高效的 LLM 像 OpenAI 和 Anthropic 这样的领跑者，会大量利用上下文来提升模型性能，综合运用专门化的系统提示词、指令、工具以及其他相关信息来有效引导模型。但 LLM 上下文窗口的内容已不再局限于提示词和用户消息。新技术，尤其是 Agent、记忆、检索和工具使用，正不断改变进入上下文窗口的内容。归根结底，最优的上下文取决于具体任务与使用场景，这使得有效的上下文管理成为构建可靠、高效 LLM 应用不可或缺的一环。下图描绘了上下文窗口中几大知名组成部分的概览。在接下来的小节里，每个部分都会连同最相关的博客和 GitHub 仓库一起介绍。 ...

从 RAG、记忆到规划、反思和知识图谱，这些模式支撑着 ChatGPT、Claude Code、Cursor、GitHub Copilot 以及各类企业级 AI 助手。 Agent 不是一段提示词。它是分布式系统：检索信息、调用工具、记住上下文、做多步推理、验证自己的输出，再把一堆专业组件协调起来。今天做 AI 应用，理解这些架构模式已经和懂 REST API、数据库、微服务一样重要。 大多数教程把 Agent 讲成一条直线：用户 → LLM → 响应。这条链路应付简单问答没问题。一旦问题需要公司知识库、外部 API、长期记忆或多步推理，它就开始露馅：产生幻觉、忘掉之前的对话、超时，或者在复杂任务上直接失败。 原因是，生产环境里的 AI 系统是架构设计出来的，不是靠提示词堆出来的。现代 AI 应用正是把多种模式组合在一起，才做到可靠、可扩展、智能。下面逐一介绍这七种。 1. 检索增强生成（RAG） 问题所在 LLM 只知道自己训练时见过的东西，不会自动了解： 你公司的文档 内部 API 客户合同 源代码 数据库 最新的产品变更 文档一变就去微调模型不现实，所以生产系统选择在推理时动态检索相关信息。 架构流程 用户查询 → 查询重写（可选）→ 向量嵌入 → 混合搜索（向量 + BM25）→ Top-K 检索 → 重排序 → 上下文压缩 → LLM → 最终答案 工作原理 典型的生产 RAG 流水线分七步： 把用户查询转成向量嵌入（Embeddings）。 在向量数据库里搜语义相似的内容。 把词法搜索（BM25）和向量搜索结合起来。 用交叉编码器（Cross-encoder）对检索结果重排序。 压缩掉冗余信息。 组装最终 Prompt。 生成回答。 每一步都在提升回答质量，同时省 Token。 ...

大多数开发者认为构建 AI 系统的核心在于选择模型，但真正的挑战在于理解何时让 AI 获取知识（RAG），何时让 AI 执行操作（MCP）。本文深入剖析两者的区别、互补性以及混合架构的未来。

创建一个从图像像素中选择 RGB 通道的工具

使用 Python 通过翻转、调整亮度、颜色抖动和随机噪声来增强数据

新专栏《AI秘籍》，你所感兴趣的一切

使用鼠标或键盘标记图像数据

SHAP 如何受到特征依赖性、因果推理和人为偏见的影响

如何计算 SHAP 特征贡献的概述

如何计算 SHAP 特征贡献的概述