大模型应用完全指南：提示词、上下文与RAG关键技术深度解析（建议收藏）

最新推荐文章于 2025-11-23 19:13:18 发布

原创最新推荐文章于 2025-11-23 19:13:18 发布 · 889 阅读

20 ·

CC 4.0 BY-SA版权

文章标签：

#人工智能 #语言模型 #ai #大模型 #程序员 #转行 #产品经理

如果prompt、上下文、记忆、知识库、RAG这些概念在你的脑海里也有一些些零碎和杂糅，那么我们不妨一起尝试厘清。

2025年被称为“智能体元年”，在智能体的概念还没有深入人心之前，我们所使用的聊天型应用主要是基于大模型而提供的，那时没有人在聊智能体，而是在聊提示词（prompt），并充满着“不会写提示词就等于不会用AI”、“AI回答不好是因为你不会问”的类似焦虑。

然而计划赶不上变化，就在绝大部分人还没有开始学提示词的时候，AI Agent概念爆火，大家的目光又都转向了围绕智能体的一切。聊天型应用上也开始出现的友好的常用场景功能键，如：翻译、写作、拍题等等，也不再嫌弃用户不会提问。但又给用户提出了新的“学习要求”，如：搭建你的知识库、联网搜索、搭建你的智能体…

但我们知道，智能体在本质上并没有带来一种技术，它提供了一种人工智能应用的范式，包括了理念、模式随之逐渐丰富的技术框架。围绕智能体范式涉及到很多关键技术，这些技术本身也并不是源起于智能体，这些技术本身就有其独自的意义。因此，尽管智能体这个大概念铺天盖地，但提示词、上下文、记忆、RAG等概念也依然零散地活跃，并且十分重要。这些概念之前似乎有交界，经常同时出现，因此，将这些零碎的概念厘清，对于更好认识模型在应用层面的关键技术十分重要。

本文的组织思路是：从我们作为用户使用AI应用的实际场景核心需求出发，理清这些概念是如何随着实际需求而依次出现的，分别解决哪些问题，带来了哪些用户价值，又产生了哪些新的问题。通过满足实际需求迭代角度去串联理解这些概念，并尝试从中更深切地体会他们发挥的作用和局限。

一、关于提示词：科学化地与模型沟通

核心需求：如何让模型给出更符合我们预期的回答

我们不妨先回忆一下第一次使用AI聊天应用时的场景：你打开了deepseek或者chatgpt甚至是一个不知道背后是什么模型的一个AI聊天app，映入眼帘的不是丰富的功能按钮和搜索框，取而代之的是一个消息发送框，并告诉你可以问他任何想问的问题。这么直白的交互方式，对于习惯了只需动动手指点击按钮这种交互方式的我们，自然是有些意外和“不知所措”，于是我们都默契而又熟练地打出了那三个字“ 你是谁 ”。然后我们就打开了新世界的大门，提问一发不可收拾。我们也开始分享自己和AI的有趣对话，包括惊艳的、蠢得可爱的、错误的以及荒谬的…大家对于AI回答的满意度褒贬不一，于是，网络上开始出现了教大家“如何正确地提问”的文章和教程，也就是：写提示词。那么用户被要求学习的“提示词”是什么？

提示词和它如何发挥作用

提示词（prompt）的本质是一个以自然语言或结构化指令形式输入的文本，它用来向模型传递我们的任务意图、语境信息和输出要求。也就是说，提示词是用户与模型交互的“语言”。我当我们在向大模型提问时，大模型并非真正“理解”问题，而是依据训练中学得的统计模式来预测下一个最合理的词或符号。优秀的提示词的作用，就在于以最有效的方式约束与引导模型的生成空间。因此，提示词的质量直接决定了AI输出内容的质量。

优秀的提示词能够获得更符合我们预期的回答，为什么优秀的提示词会更有效？这里从模型角度出发，给出最主要的两点：

模型的生成机制决定了“输入文字的形式”影响“输出质量”。大语言模型的本质是基于概率分布的下一个词预测系统。它通过在海量文本中学习词语间的条件关系，建立出潜在的语义空间。当用户输入提示词时，模型会在这个空间中寻找与提示最匹配的生成轨迹。因此，提示词的表达清晰度、上下文完整性、逻辑顺序都会显著影响模型对“下一步应输出什么”的判断。
提示词补充了模型缺乏的“外部记忆与意图理解”。大语言模型是“无记忆”的系统，即单次对话不具备长期状态。除非应用单独做了中间的记忆处理，对于那些直接通过与大模型交互来聊天的应用而言，在我们每次提问时，我们对于模型而言都是陌生人，它不记得你是谁，你的任务背景以及上一次发生了什么。因此，提示词中提供的信息，就相当于一次性输入的“工作记忆”。例如说明“任务背景”让模型理解语境，指明“目标对象”让模型确定风格，指定“输出格式”让模型约束内容形态。这种补充行为使得模型在缺乏真实理解的情况下，也能“模拟”出理解后的行为。

因此，当我们使用日常习惯的聊天提问方式提问时，面对一些日常性、通用性的问题，得到的回答质量不会有明显的影响，但当我们面向一些特定的专业、复杂任务时，使用优秀的提示词就会得到明显更好的回答。

优秀的提示词范本

提示词并非严格意义上的编程语言，亦没有强制的语法规则。作为用户，我们非常希望有一个放之四海皆准的提示词写法或者模版，但遗憾的是，提示词并非是“一次写好，到处通用”。因为提示词是用于更好地与模型来沟通，提示词怎么写更有效与你用的模型密切相关。而每个模型在架构、训练方式和上下文机制都有不同。比如：OpenAI 系列模型倾向理解自然语言中的语义逻辑，因此偏好自然指令式、角色化提示；而Anthropic Claude 系列强调安全与上下文理解，对层级结构、编号步骤、XML格式响应最佳；Google Gemini / DeepMind系列则偏好短指令＋格式模板组合，对JSON类结构支持较强。

不过，随着大模型在复杂任务中的使用逐渐系统化，业界其实已经形成了一些结构化提示（Structured Prompt）的通用模式，这些结构可以显著提高模型理解度与输出一致性。

在这里插入图片描述

这些格式的共同点是：

明确边界、减少歧义、增加可解释性。
而并非强制要求某种语法。

在 Anthropic 的文档《Be clear, direct, and detailed》中，明确指出：

“Claude 不知道你的工作习惯或语境，因此越具体越好。编号、结构化、限定输出类型都会提升效果。”

由于本文重点不是教大家写提示词，这里不过多赘述如何写提示词。从AI应用的视角出发，未来使用AI门槛一定是越来越低的，无需普通用户付出高学习成本的，因此不建议在此有过多焦虑。但是，如果你是想在现在就充分探索和利用模型能力，那么学和用提示词基本是逃不掉的。

如果模型能完全“理解意图”，提示词工程就不需要存在；但事实恰恰相反，当前的大语言模型虽强大，却并非通用理性智能体，而是基于概率的语义生成系统。因此，“如何用恰当的语言触发模型的潜能”就成了一门工程科学。

在这里插入图片描述

提示词工程：提示词从经验技巧到工程范式的转变

在大模型兴起的早期阶段，提示词的设计主要依赖经验性技巧而非科学化的设计，其成效高度依赖于设计者对模型行为的感知与调校经验。随着模型能力的快速提升和应用场景的复杂化，单纯依靠经验的提示词编写方式逐渐暴露出可扩展性不足、复现性低和任务一致性弱等问题。由此，提示词设计逐渐从“试验性实践”演化为“工程化过程”。提示词工程（Prompt Engineering）由此成为连接语言模型与具体任务目标之间的关键中间层，其研究目标从“如何写出好提示”转向“如何系统化地设计、验证与优化提示系统”，形成具有理论支撑和工具体系的工程学科方向。

提示词工程的目标是：最大化模型的性能，最小化其输出的不确定性和错误。

提示词工程的核心研究内容包括：结构化表达、可解释的推理控制与模型行为约束等，更细节的内容笔者没有做详细的研究，但是可以理解提示词工程的核心思想是：用语言来控制模型的行为。也就是说，不止包括研究如何通过结构化表达语言来充分激发模型潜能，还涉及到通过提示词来控制模型按照我们需要的应用场景和目的来实现预期表现，包括：通过提示词影响模型的思维链条、通过提示词对模型行为进行约束，确保其输出在伦理、安全和一致性上的可控等等。

提示词工程与模型、AI应用的关系

从一个通俗意义上的AI应用内在层次逻辑架构上来看（开发视角）：

提示词工程置于模型训练层之上，不会直接修改模型参数（那是训练层面的问题），而是通过提示词来控制模型在推理阶段的表现。因此，提示词工程是一种“非参数化的模型调控手段”，它介于模型层与应用逻辑层之间，为模型提供了任务适配、语义约束与行为一致性的控制接口。提示词工程通过系统Prompt、模板化变量、上下文注入等机制，使开发者可以在不重新训练模型的情况下，动态配置模型的行为边界与任务逻辑。

扩展一下，实际上还存在一个提示词微调（Prompt-Tuning）的概念，在模型输入层注入可训练的“软提示（soft prompt）”向量，通过小规模训练调整模型内部表征。不改变模型主体参数，训练成本低，介于提示词工程和模型微调之间。

从一个AI应用的终端用户角度来看（用户视角）：

对于终端用户而言，大模型的“智能”体验会受到提示词层的设计质量影响。当我们在Deepseek或ChatGPT中输入自然语言指令时，系统在后台会先经过一系列隐藏提示（如角色设定、风格约束、目标指令），我们看到的是友好的自然回答，但其实应用内在逻辑上存在提示词层在完成翻译，实际模型接收到的是拼接了这些指令的系统消息，用户无需直接编写复杂提示。

因此，对用户而言，提示词层是无需直接感知的，它的价值就在于帮用户屏蔽模型复杂性，提供一致、稳定的输出体验。应用本身的提示词层做的越好，就对用户输入的问题的规范性要求越低。例如，当前豆包、kimi等提供的一些常用场景功能，如：生成博客、解题、写作等其实都已经面向特定任务包裹了一层提示词优化了。未来使用AI门槛一定是越来越低的，无需普通用户付出高学习成本的，这就是不建议纯用户在此有过多焦虑的原因。

二、关于上下文：在合适的时间，提供合适的信息和工具

核心需求：与模型顺畅地进行多轮对话

当我们和他人聊天的时候，我们可以非常流畅的持续对话，但是模型不一样，模型本身是无状态的，它不会在不同请求之间保留“对话记忆”。换言之，每次输入都被视为一个全新的任务，模型无法自动感知历史语境。比如，模型之上直接加一个交互界面，而不做其他任何多余的逻辑，能够做一个问答小助手，是很简单的，但是它无法连续对话。你问“北京有什么名胜古迹？”，它回答“万里长城、故宫…”，但如果你继续问“上海呢？”，模型并不记得你上一个问题问的是“北京的名胜古迹”，也不记得你们在聊地域的名胜古迹的话题，它在回答“上海呢？”这个问题的时候则不知道你要具体问的是什么，它可能就会直接对上海这个城市做一个整体简介。

新的需求自然地产生了：如何让模型“持续地理解我在说什么”。用户在与AI持续互动时，希望模型能理解“这次问的内容”与“上一次的讨论”之间的关联，这是一种更接近人类交互逻辑的对话体验。

因此，若希望模型能理解多轮语义关联，必须人为地将“上下文”纳入输入。如果我们在这个对话助手产品内部加一个逻辑，当用户问第二个问题的时候，每次都把之前的问题和答案的核心内容拼接到这一次的提示词中，不就可以了吗？但是，当我们问第N个问题的时候，这种拼接机制就会让提示词变得很低效，第N个问题的提示词中的背景信息会越来越长，也会超出提示词的最大长度限制。

为此，“上下文工程”应运而生。

上下文窗口

还是想说一下上下文这个看起来挺高级的词汇（不好意思这是我必须要吐槽这个词的某种执念哈哈）。

上下文（Context）指的其实就是围绕某个事物、事件、话语或行为的相关环境、条件或背景。比如语文考试里最折磨人的阅读理解，如果想要理解作者写下的“清风徐来，水波不兴”表达了哪些中心思想，就需要了解这句话“被写出来时的状态”，包括前文和后文，它的作者写下这篇作品的时间、地点、境遇等等，才更可能回答得准确。因此，上下文并非是人工智能领域里发明的词汇。在数据治理领域，也使用上下文概念来说明数据入湖或治理过程中来保留数据的关联关键信息的重要性。在程序或人工智能领域，上下文就是系统在执行时所知道的当前状态。

大语言模型的上下文记忆依赖于上下文窗口（context window）这一机制。上下文窗口（context window）指模型一次能读入并考虑的输入文本最大长度，通常以“token”（词元）为单位。窗口内的所有tokens（包括用户输入与模型输出）都会被共同作为当前输入的一部分，供模型进行下一次生成预测。换言之，模型回答问题时，能“看到”的输入（包括系统提示、用户问题、之前的对话）都有一个长度限制，超过这个范围的内容，它就看不到了。

在这里插入图片描述

窗口容量决定了模型“能记得多少内容”，但这是一种短期记忆（short-term memory），当窗口被填满后，旧的信息将被舍弃或压缩。上下文窗口的上限极大影响连续对话的体验，举个具体的实际例子：有些朋友可能在和deepseek连续对话时遇到过这个问题，会突然提示你“已达到最大对话长度，请开启新会话”，这就达到了上下文窗口上限。你只能选择创建一个新会话。8月底，deepseek低调升级了一次V3模型，上下文窗口上限由之前的64k提升到128k，大大提升了连续对话的体验，而且有些网友也聪明地使用之前已经达到上限的旧会话继续聊天了。

所以，如何在有限的窗口内选择哪些信息保留、哪些舍弃，就成为上下文工程的首要问题。若提示词工程是“优化一次输入”，上下文工程则是“优化整个对话周期”。提示词工程是让你获得一次优质的回答，而上下文工程是为了确保你连续1000次获得的回答都是优质的。

上下文工程及其研究范畴

上下文工程（Context Engineering）的目标是在有限的上下文窗口内，有策略地组织和利用对话历史信息，使模型在每次推理时都能获得足够且恰当的语境支撑。换言之，就是在多轮对话中确保模型在回答时不缺少关键细节——避免"Garbage In, Garbage Out"。这就要求系统在必要且合适的情况下，为模型提供相关的知识（信息）和能力（工具）。

与提示词工程不同的，上下文工程不是研究一个结构化模版，而是关于如何设计一套可靠的运行时系统，设计如何有效组织这些上下文，也就是上下文窗口中的全部信息（输入、输出、记忆、工具、外部知识、系统级隐性上下文等）。因此它的主要研究就包括了对上下文窗口中全部涉及到的上下文信息的组织设计，具体包括：

运行时的上下文管理

也就是对任务输入输出和系统运行中的隐藏上下文进行管理策略设计。在有限且昂贵的上下文窗口条件下，尤其面对长对话或复杂任务时，高效的上下文管理策略至关重要。主要包括：上下文压缩与摘要，对冗余或低价值信息进行压缩，同时保留核心语义和关键信息，以降低Token消耗并延长有效上下文容量；上下文重排，通过信息优先级评估，将关键事实、最新状态或任务关键信息置于模型最易关注的位置，以缓解模型中途遗忘问题；动态记忆调度，根据对话阶段或任务复杂度动态调整短期与长期记忆的内容权重，实现对上下文信息的实时优化。

长期与短期记忆系统

也就是对过去的交互内容或记忆数据进行管理策略设计，以增强对话的连贯性与个性化能力。包括：短期记忆，负责当前会话内的信息管理，包括用户输入、模型输出及对话状态，以确保多轮交互的逻辑连续性和语境一致性；长期记忆，存储跨会话周期的关键信息，如用户偏好、历史决策、业务规则及特定事件等，使 AI 能够保留经验，实现真正的个性化与持续优化服务。

外部知识库的动态供给

为应对大模型在知识陈旧、领域适应性不足及事实可靠性上的局限，上下文工程的核心策略之一是接入多源外部知识库。通过检索增强生成（Retrieval-Augmented Generation, RAG）技术，系统在接收到用户请求时，首先从企业私有数据库、实时信息流、开放互联网或其他结构化/非结构化数据源中检索相关信息，再将检索结果与提示词组合形成完整上下文，引导 LLM 基于最新、准确的知识生成响应。

这一部分，我们就会在下一章节进行展开。

工具与能力的扩展

也就是模型可调用的外部工具的上下文进行管理策略设计。这些工具通常以函数调用或MCP服务的形式呈现，使 LLM 在生成文本的同时能够执行特定操作，包括：数据库查询与信息更新；调用外部服务以获取实时数据或执行任务等。

针对以上四项关键组成，可以简单总结为：外部记忆系统和上下文管理主要侧重模型“记得”的问题，而外部知识库和工具扩展则侧重模型“知道”扩展知识的问题。

Everything is Context Engineering

至此，虽然RAG还没有写到，但是关于上下文工程、提示词工程、RAG和记忆几个概念之间的关联关系已经开始明晰，上下文工程是一个相对而言大的范畴，也即 “Everything is Context Engineering！”

概念关系概览（来源：参考资料[2]）

如果说，上下文还是让你觉得轻飘飘的，没有感受到重要性，那么下面这个章节我们会针对上下文工程中比较厚重的部分——RAG进行展开。

三、关于RAG：模型的 “外脑”

核心需求：让模型“知道”它不知道的事

在解决了连续对话的问题后，新的问题随之浮现：模型虽然“记得”，但它“知道”的仍然有限。

例如，当我们让模型分析某份最新的市场报告，或者让智能客服回答企业内部知识库中的细节问题时，模型即便语言生成能力再强，也难以提供准确答案。原因在于，大模型的“知识”依赖于预训练的参数，并不能动态更新（这就是模型内部记忆，又称参数记忆）。比如GPT-3当时的训练数据只截止到2022年底，所以它并不知道世界在2023年之后发生了什么，也无法自主访问外部数据库或上网搜。当你问它一些最新的资讯时，它的回答就会过时。以上是从时间维度去看的模型知识的局限性，那么从知识覆盖范围维度上，也同样存在局限性，即便训练语料海量，也不可能覆盖全部领域，尤其是私域数据或内部资料（如企业内文档）。

那么你可能会说，那模型进行快速迭代，保持更新不就好了。但这并不现实，最主要的原因：1. 模型训练的成本极高，不管是算力还是时间成本都很高； 2. 世界知识是动态的，几乎每天都有更新，重新训练无法满足这种高频更新需求。因此，构建一种成本低且动态性高的外部知识接入机制是十分必要的，这正是 RAG诞生的起点。

RAG及其工作原理

检索增强生成（Retrieval-Augmented Generation, RAG）是一种结合信息检索与生成式语言模型的混合式生成框架。其基本原理是：在生成阶段之前，从外部知识库或文档集合中检索与输入查询相关的内容，并将检索结果作为上下文信息与原始输入一并输入至生成模型，从而生成更准确、事实一致且可追溯的输出结果。它的主要工作机制就像它的名称定义一样简单直接：

检索（Retrieval）：当用户提出问题时，系统首先从外部知识源（如文档库、数据库、网页或企业内部资料）中检索出最相关的内容。与我们通识下的检索不同，这里的检索是通过语义向量化（embedding）实现，也就是将用户问题与知识库文本映射到同一语义空间中，计算相似度后选出排在最前面的几条。
增强（Augmentation）：系统将这些检索结果作为增强上下文（augmented context）与用户的提问共同构成新的上下文输入，即在模型的上下文窗口中注入。
生成（Generation）：模型基于增强后的上下文生成回答。因为给模型的输入中就包含了额外知识内容，模型就可以基于“内部知识 + 外部检索知识”来输出更有针对性的结果。

因此，RAG 的核心思想可概括为一句话：

“在生成前，先检索；生成时，带引用。”

本质上，RAG重点是解决模型知识的“外部可扩展性”问题。通过将外部知识（非参数化知识）与模型内部参数知识（参数化知识）结合，RAG可以在无需语言模型重新训练的情况下实现动态知识增强，更贴合现实世界中外部知识随时间变化的情形，避免了因模型静态训练数据所导致的知识时效性和范围有限性问题。

下面我们将通过稍详细的工作机制理解RAG中的要点，以及它为何不能与模型训练媲美，它的局限性在哪。

RAG工作机制

我们通过一个更详细的例子来理解RAG工作机制和要点。下图是一个典型的、基础的RAG应用工作流：

概念关系概览（来源：参考资料[3]）

索引阶段（Indexing）：这个阶段是一个前置的外部知识获取过程，外部数据需要经过清洗并转换为模型能够理解的格式，为后续的检索搭建一个准备好的知识库，并且是一个模型可以理解的知识库。这个阶段涉及到几个比较核心的概念，所以这里我们还是细化一下这个阶段的内部过程：

数据分块：分块划分是向量化前的一个基础过程，会将文档切成一些小的块（chunks）；
数据向量化：外部知识（文本、文档、图像等）会经过“向量化”过程从其原始格式转换为向量表示（embeddings）。那么执行这个“向量化”过程的就是一个嵌入模型（Embedding Model）；
向量化存储：生成向量后，这些向量会被将存储起来以便后续检索，通常是存储在向量数据库（vector database）中，这种存储方式可以为后续的任务提供快速高效的信息检索。

向量化（来源：参考资料[4]）

用户输入阶段（Input）：当用户提出问题时，这里其实往往会加上一步「用户意图理解」，也就是从用户的原始提问中分析出用户的真正意图，来明确出从外部知识中检索什么。就像我们在搜索某个领域相关资料时，也会切换尝试不同的检索匹配词，以获取更好的检索结果。
检索阶段（Retrieval）：使用上面同一个嵌入模型（Embedding Model）将要检索的内容也进行向量化转化，然后在向量数据库里进行相似度检索，选出排在最前面的几条，如图中可以看到选择出的最相关的3个结果chunks。
增强阶段（Augmentation，对应图中的Combine Context and Prompts）：系统将这些检索结果作为增强上下文（augmented context）与用户的提问共同构成新的一个上下文输入给模型，如图中可以看到将用户的原始问题和搜索到的前几条chunks合并为一个新的提示词提供给了模型。
生成阶段（Generation）：模型基于增强后的上下文生成回答。因为给模型的输入中就包含了额外知识内容，模型就可以基于“内部知识 + 外部检索知识”来输出更有针对性的结果。并且，模型的回答中会额外提供外部信息的明确来源，以实现信息来源的透明可溯源。

以上给出的工作机制其实只是比较基础经典Naive RAG框架，从架构的演进上，目前已经演进Advanced RAG 和 Modular RAG，关于这些更专业的部分，感兴趣的朋友可以阅读文末的扩展资料[3]的这篇论文。

RAG vs. 微调（Fine-tuning）、以及RAG的局限、未来

RAG 与模型微调代表了两种不同的知识整合路径：微调通过更新模型参数，将知识直接嵌入模型内部；而RAG则在推理时从外部检索相关信息，将其作为生成条件输入模型，从而避免频繁再训练。因此，微调关注“内部适配”，而 RAG 关注“外部扩展”。

个人认为，RAG的本质问题在于，它并没有真正提升模型固有的知识水平或理解能力，而是为其接入了一个“外挂”。它解决了“知识”的问题，但没有解决“智力”的问题。模型拥有强大的理解能力主要来自于其预训练和微调，虽然模型从数据中学习到的这种不透明的模式对于我们是黑盒，但依然能给我们带来模型是真正理解了我们的直接感受。因此，微调更贴近真正的人工智能理念。

未来的方向上，目前大部分观点认为在未来是一种微调和RAG的融合模式，从RAG框架演进上，Modular RAG框架其实已经和微调进行了融合，参考资料[3]的作者在论文中的观点也提到了未来发展方向是融合模式（Hybrid Approach）：通过微调实现模型对任务的语言风格和逻辑适应，再通过 RAG 提供实时知识支撑，从而在“稳定性”与“时效性”之间取得平衡。