大模型（LLM）基础知识科普

智能问答作为大模型最经典且广泛的应用之一，是探索大语言模型（LLM）工作机制的最佳范例。

以一个简单的输入"ACP is a very"为例，来具体看看大模型是如何一步步处理这个输入，并最终生成完整句子的。

大模型的文本生成流程可以分为文本分词、Token 向量化、大模型推理、解码与自回归、输出文本五个阶段：

第一阶段：文本分词

计算机无法直接理解人类的文字。因此，第一步需要将我们输入的文本“ACP is a very”转换成计算机能够处理的数字格式。

Token 是分词器（Tokenizer）把文本编码后得到的基本单元，每个 token 对应词表中的一个整数 ID。token 通常是子词片段或字符片段，不一定等于一个完整的"词"，也不一定具有独立语义。

比如英文单词可能被拆成词根和后缀，中文可能按字或常见词组切分，空格和标点也可能被编码进 token。

以"ACP is a very"为例，Tokenizer 会将其编码成若干 token，并为每个 token 分配一个 ID。

第二阶段：Token 向量化

虽然得到了数字 ID 序列，但这些 ID 本身的数值大小并没有实际意义（比如，ID 500 并不意味着它在语义上就比 ID 50 更“重要”或“相关”）。

为了让模型理解 token 的真实含义，我们需要将这些离散的 ID 转换成包含丰富语义信息的数学表示——向量 (Vector)。

这个转换通过一个被称为 Embedding 矩阵 的巨大表格完成。

简单来说，就是用 token ID 在这个大表格里“查表”，取出对应的那一整行向量。每个 token 的向量都包含了其在多维度语义空间中的坐标。

此外，语言的顺序至关重要（“我帮你”和“你帮我”截然不同）。

但基础的 Transformer 模型本身并不直接处理时序信息。因此，还需要额外给每个 token 向量添加位置信息，让模型能够区分出 “我” 是第一个词，“你” 是第三个词，以此类推。

第三阶段：大模型推理

现在，携带了语义和位置信息的向量序列被送入Transformer模型的解码器层进行计算，这个过程被称为前向计算。

向量序列会逐层穿过数十个甚至上百个结构相似的解码器层，在因果自注意力机制和前馈神经网络 的作用下，文本向量中的信息被一次一次压缩和提取。

最终会得到最后一个 token（也就是 “very”）所对应的隐藏状态向量。这个向量可以被认为是模型在阅读了 “ACP is a very” 之后，对接下来可能出现的内容的一个高度浓缩的“思考总结”。

最后，这个“思考总结”向量会通过一个线性投影层，映射到整个词汇表的维度，得到一个庞大的分数向量。

第四阶段：解码与自回归

在得到 logits 之后，大模型还需要经过 softmax 函数计算，将这些 logits 重新映射为一种概率分布P，表示每个 token 被选中的概率。最后，大模型会根据一个解码策略来决定最终输出哪个 token。

解码策略主要分为两类：

• 近似确定性解码：如贪心解码，每次选概率最高的 token，或 Beam Search 保留多个候选路径。
• 随机采样解码：如Top-p、Top-k Sampling，从高概率的候选集合中随机抽取。

很多在线服务默认使用随机采样解码，因此即使输入完全相同，也可能出现"回答略有不同"的现象。

通过调整 temperature，你可以改变 softmax 输出概率分布的"尖锐程度"。

temperature越低，token 之间的概率差异越大，概率分布越集中于少数的高概率 token，模型输出越确定。

temperature 越高，输出概率分布越平坦，模型的输出多样性越高。配合 top_p（控制参与采样的候选集合范围）等参数，可以在模型输出的多样性与稳定性之间做权衡。

例如，下图展示了模型预测出的部分候选 token 及其概率（实际词汇表远比这大得多）：

一旦选定了下一个 token（比如模型选择了 “informative”），这个新生成的 token 就会被追加到原始输入序列的末尾，形成新的输入 “ACP is a very informative”。

然后，模型会基于这个新序列，重复第三和第四阶段，继续预测下一个 token。这个"文字接龙"的过程称为自回归生成。

模型的自回归循环会持续进行，直到满足某个停止条件：

• 生成了特殊的终止符 (End-of-Sequence, EOS token)。
• 达到了预设的最大生成长度限制。
• 生成了用户指定的停用词序列。

第五阶段：输出文本

最后，系统会将整个生成过程中的 token ID 序列转换回人类可读的字符串，并呈现给我们。

我们经常看到的流式输出效果，其实是服务端每生成一个或几个 token，就立刻将其解码并增量地发送到你的界面上。

由于 token 可能是子词片段，所以在流式显示时，有时会看到一个词被分成几部分输出，或者空格的出现时机看起来有些奇怪，这都是正常现象。

影响大模型内容生成的随机性参数

假设在一个对话问答场景中，用户提问为：“在大模型ACP课程中，你可以学习什么？”。

为了模拟大模型生成内容的过程，我们预设了一个候选Token集合，这些Token分别为：“RAG”、“提示词”、“模型”、“写作”、“画画”。大模型会从这5个候选Token中选择一个作为结果输出，如下所示。

用户提问：在大模型ACP课程中，你可以学习什么？

大模型回答：RAG

在这个过程中，有两个重要参数会影响大模型的输出：temperature 和 top_p，它们用来控制大模型生成内容的随机性和多样性。

temperature：调整候选Token集合的概率分布

在大模型生成下一个词之前，它会先为候选Token计算一个初始概率分布。这个分布表示每个候选Token作为next-token的概率。

temperature是一个调节器，它通过改变候选Token的概率分布，影响大模型的内容生成。通过调节这个参数，可以灵活地控制生成文本的多样性和创造性。

为了更直观地理解，下图展示了不同temperature值对候选Token概率分布的影响。

图中的低、中、高温度基于Qwen-Max模型的范围[0, 2)划分。

由上图可知，温度从低到高（0.1 -> 0.7 -> 1.2），概率分布从陡峭趋于平滑，候选Token“RAG”从出现的概率从0.8 -> 0.6 -> 0.3，虽然依然是出现概率最高的，但是已经和其它的候选Token概率接近了，最终输出也会从相对固定到逐渐多样化。

针对不同使用场景，可参考以下建议设置 temperature 参数：

• 明确答案（如生成代码）：调低温度。
• 创意多样（如广告文案）：调高温度。
• 无特殊需求：使用默认温度（通常为中温度范围）。

需要注意的是，当 temperature=0 时，虽然会最大限度降低随机性，但无法保证每次输出完全一致。如果想深入了解，可查阅 temperature的底层算法实现。

top_p：控制候选Token集合的采样范围

top_p 是一种筛选机制，用于从候选 Token 集合中选出符合特定条件的“小集合”。

具体方法是：按概率从高到低排序，选取累计概率达到设定阈值的Token 组成新的候选集合，从而缩小选择范围。

下图展示了不同top_p值对候选Token集合的采样效果。

图示中蓝色部分表示累计概率达到top_p阈值（如0.5或0.8）的Token，它们组成新的候选集合；灰色部分则是未被选中的Token。

当top_p=0.5时，模型优先选择最高概率的Token，即“RAG”；而当top_p=0.8时，模型会在“RAG”、“提示词”、“模型”这三个Token中随机选择一个生成输出。

由此可见，top_p值对大模型生成内容的影响可总结为：

• 值越大 ：候选范围越广，内容更多样化，适合创意写作、诗歌生成等场景。
• 值越小 ：候选范围越窄，输出更稳定，适合新闻初稿、代码生成等需要明确答案的场景。
• 极小值（如 0.0001）：理论上模型只选择概率最高的 Token，输出非常稳定。但实际上，由于分布式系统、模型输出的额外调整等因素可能引入的微小随机性，仍无法保证每次输出完全一致。

那么，是否需要同时调整temperature和top_p？

为了确保生成内容的可控性，建议不要同时调整top_p和temperature，同时调整可能导致输出结果不可预测。

你可以优先调整其中一种参数，观察其对结果的影响，再逐步微调。

知识延展：top_k在千问系列模型中，参数top_k也有类似top_p的能力。它是一种采样机制，从概率排名前k的Token中随机选择一个进行输出。一般来说，top_k越大，生成内容越多样化；top_k越小，内容则更固定。当top_k设置为1时，模型仅选择概率最高的Token，输出会更加稳定，但也会导致缺乏变化和创意。

知识延展：seed在千问系列模型中，参数seed也支持控制生成内容的确定性。在每次模型调用时传入相同的seed值，并保持其他参数不变，模型会尽最大可能返回相同结果，但无法保证每次结果完全一致。

设置 temperature、top_p、seed 控制大模型输出，为何仍存在随机性？

即使将 temperature 设置为 0、top_p 设置为极小值（如 0.0001），并使用相同的 seed ，同一个问题的生成结果仍可能出现不一致。

这是因为一些复杂因素可能引入微小的随机性，例如大模型运行在分布式系统中，或模型输出引入了优化。

举个例子： 分布式系统就像用不同的机器切面包。虽然每台机器都按照相同的设置操作，但由于设备之间的细微差异，切出来的面包片可能还是会略有不同。

让大模型能够回答私域知识问题

回到最初的挑战：答疑机器人无法回答“我们公司项目管理用什么工具”这类内部问题。

根本原因在于，大模型的知识来源于其训练数据，这些数据通常是公开的互联网信息，不包含任何特定公司的内部文档、政策或流程。

你可以把大模型想象成一台刚出厂的超级计算机：它的 CPU（推理能力）极其强大，硬盘（模型权重）里也预装了海量的通用知识。但对于你公司的“内部资料”，它的硬盘里是空白的。

面对这个问题，最直观的解决思路就是：在运行时，把公司的内部知识临时告诉它。

（1）初步方案：在提示词中“喂”入知识

你可以来验证这个思路：将公司项目管理工具的说明文档，直接添加到给模型的指令（System Prompt）中，作为背景知识提供给它。

然而，当你试图将更多的公司文档（例如几十页的员工手册、上百页的技术规范）都用这种方式“喂”给大模型时，一个新的、更严峻的挑战出现了。

（2）核心瓶颈：有限的上下文窗口

大模型接收我们输入（包括指令、问题和背景知识）的地方，被称为上下文窗口。你可以把它理解为计算机的“内存（RAM）”——它的容量是有限的。

你无法将整个公司的知识库（成百上千份文档）一次性塞进这个有限的窗口里。一旦输入内容超过模型的最大限制，就会导致错误。

这引出了一个核心问题：你需要对放入上下文窗口的内容进行筛选和管理。

（3）解决之道：上下文工程

简单粗暴地将信息塞进上下文，除了会超出窗口限制外，还会带来一系列“隐性”问题：

1. 效率低：上下文越长，大模型处理所需的时间就越长，导致用户等待时间增加。
2. 成本高：大部分模型是按输入和输出的文本量计费的，冗长的上下文意味着更高的成本。
3. 信息干扰：如果上下文中包含了大量与当前问题无关的信息，就像在开卷考试时给了考生一本错误科目的教科书，反而会干扰模型的判断，导致回答质量下降。

你会意识到，成功的关键不在于“喂”给模型多少知识，而在于“喂”得有多准。

如何在正确的时间，将最相关、最精准的知识，动态地加载到大模型有限的上下文窗口中？——这门系统性地设计、构建和优化上下文的实践，就是上下文工程。

从这个角度看，许多大模型应用的失败，并非模型本身不够智能，而是“上下文”的失败。

上下文工程正是释放大模型潜力的关键所在。

那么，上下文工程具体包含哪些技术呢？你可以通过下面这张概念图来快速了解它的核心版图：

上下文工程的核心技术主要有：

它是构建可靠、高效大模型应用的一系列关键技术的总和，主要包括：

RAG (检索增强生成)：从外部知识库（如公司文档）中检索信息，为模型提供精准的回答依据。

Prompt (提示词工程)：通过精心设计的指令，精确地引导模型的思考方式和输出格式。

Tool (工具使用)：赋予模型调用外部工具（如计算器、搜索引擎、API）的能力，以获取实时信息或执行特定任务。

Memory (记忆机制)：为模型建立长短期记忆，使其能够在连续对话中理解历史上下文。

现在，聚焦于当前最紧迫的问题——如何解决私域知识问答。在这个技术版图中，RAG 是最直接、最有效的解决方案。

技术方案：RAG（检索增强生成）

RAG（Retrieval-Augmented Generation，检索增强生成） 就是实现上下文工程的强大技术方案。它的核心思想是：

在用户提问时，不再将全部知识库硬塞给大模型，而是先自动检索出与问题最相关的私有知识片段，然后将这些精准的片段与用户问题合并后，一同传给大模型，从而生成最终的答案。这样既避免了提示词过长的问题，又能确保大模型获得相关的背景信息。

构建一个 RAG 应用通常会分为两个阶段。

（1）第一阶段：建立索引

建立索引是为了将私有知识文档或片段转换为可以高效检索的形式。通过将文件内容分割并转化为多维向量（使用专用 Embedding 模型），并结合向量存储保留文本的语义信息，方便进行相似度计算。

向量化使得模型能够高效检索和匹配相关内容，特别是在处理大规模知识库时，显著提高了查询的准确性和响应速度。

这些向量经过 Embedding 模型处理后不仅很好地捕捉文本内容的语义信息，而且由于语义已经向量化，标准化，便于之后与检索语义向量进行相关度计算。

（2）第二阶段：检索与生成

检索生成是根据用户的提问，从索引中检索相关的文档片段，这些片段会与提问一起输入到大模型生成最终的回答。这样大模型就能够回答私有知识问题了。

总的来说，基于 RAG 结构的应用，既避免了将整个参考文档作为背景信息输入而导致的各种问题，又通过检索提取出了与问题最相关的部分，从而提高了大模型输出的准确性与相关性。

RAG的工作原理

RAG（Retrieval Augmented Generation，检索增强生成），是上下文工程中最重要、最有效的技术之一，专门解决大模型“知识不足”的问题。RAG应用通常包含建立索引与检索生成两部分。

建立索引

你可能会在考试前对参考资料做标记，来帮助你在考试时更容易地找到相关信息。类似的，RAG应用往往也会在回答前就已经做好了标记，这一过程叫做建立索引，建立索引包括四个步骤：

1. 文档解析
   就像你会将书上看到的视觉信息理解为文字信息一样，RAG应用也需要首先将知识库文档进行加载并解析为大模型能够理解的文字形式。
2. 文本分段
   你通常不会在做某道题时把整本书都翻阅一遍，而是去查找与问题最相关的几个段落，因此你会先把参考资料做一个大致的分段。类似的，RAG应用也会在文档解析后对文本进行分段，以便于在后续能够快速找到与提问最相关的内容。
3. 文本向量化
   在开卷考试时，你通常会先在参考资料中寻找与问题最相关的段落，再去进行作答。在RAG应用中，通常需要借助嵌入模型分别对段落与问题进行数字化表示，在进行相似度比较后找出最相关的段落，数字化表示的过程就叫做文本向量化。
4. 存储索引
   存储索引将向量化后的段落存储为向量数据库，这样RAG应用就无需在每次进行回复时都重复以上步骤，从而可以增加响应速度。

在建立索引后，RAG应用就可以根据用户的问题检索出相关的文本段了。

检索生成

检索、生成分别对应着RAG名字中的Retrieval（召回）与Generation（生成）两阶段。检索就像开卷考试时去查找资料的过程，生成则是在找到资料后，根据参考资料与问题进行作答的过程。

1. 检索
   检索阶段会召回与问题最相关的文本段。通过embedding模型对问题进行文本向量化，并与向量数据库的段落进行语义相似度的比较，找出最相关的段落。

   检索是RAG应用中最重要的环节，你可以想象如果考试的时候找到了错误的资料，那么回答一定是不准确的。

   这个步骤完美诠释了上下文工程的精髓：从海量知识中“精准地选择相关信息”来填充上下文。找到最匹配的内容，是保证后续生成质量的第一步。为了提高检索准确性，除了使用性能强大的embedding模型，也可以做重排（rerank）、句子窗口检索等方法。

2. 生成
   在检索到相关的文本段后，RAG应用会将问题与文本段通过提示词模板生成最终的提示词，由大模型生成回复，这个阶段更多是利用大模型的总结能力，而不是大模型本身具有的知识。

   这个提示词模板的设计，是上下文工程的另一个关键环节。我们不仅要提供检索到的“资料”，还要明确地“指导”模型如何使用这些资料来回答问题。

   一个典型的提示词模板为：请根据以下信息回答用户的问题：{召回文本段}。用户的问题是：{question}。

RAG 多轮对话

在大模型中，多轮对话的意义是：让大模型能够参考历史对话信息，理解上下文关联，从而给出连贯、准确的回复。

多轮对话的工作原理：

在 OpenAI SDK 中，实现多轮对话的关键在于 messages 参数。这是一个列表，包含了对话的完整历史记录。每条消息都有两个关键字段：

role：消息的角色，可以是 system（系统指令）、user（用户输入）或 assistant（模型回复）

content：消息的具体内容

大模型会根据 messages 列表中的所有消息来生成回复，因此你需要将之前的对话历史（包括用户问题和模型回答）都保存在这个列表中。

对话历史会占用上下文窗口的空间。如果对话轮次过多，可能需要对历史消息进行截断或摘要处理。

在生产环境中，通常需要将对话历史持久化存储（如数据库），以支持用户跨会话的连续对话体验。

好了，再来回想一下RAG的检索阶段：系统会将用户的问题与知识库中的文本段进行语义相似度比较，找出最相关的内容。但如果用户的问题依赖于对话历史中的上下文，会发生什么呢？

举个例子：

• 第一轮：用户问「张三的工位在哪里？」
• 第二轮：用户接着问「他的主管是谁？」

如果检索系统只用第二轮的问题「他的主管是谁？」去匹配文本段，它根本不知道「他」指的是谁，很可能召回错误的内容，导致回答不准确。

解决方案：问题改写

如果把完整的对话历史和问题一起输入检索系统，由于文本过长，embedding模型的效果会下降。业界通用的解决方案是：

1. 问题改写：利用大模型根据对话历史对当前问题进行改写，将上下文信息融入问题中
2. 正常检索：使用改写后的问题进行检索和生成

例如，上面的例子中，大模型会将「他的主管是谁？」改写为「张三的主管是谁？」，这样检索系统就能准确地找到相关信息了。

拓展阅读

文本向量化

计算机并不能直接理解“我喜欢吃苹果”与“我爱吃苹果”这两句话到底有多相似，但它能理解两个相同维度的向量的相似度（通常使用余弦相似度来衡量）。

文本向量化通过embedding模型，将自然语言转化为计算机能够理解的数字形式。

embedding模型的训练通常会包含对比学习的环节，输入数据是许多已标记为是否相关的文本对(s1,s2)，模型的训练目标是尽可能让相关的文本对生成的向量相似度变高，不相关的文本对生成的向量相似度变低。

在建立索引阶段，假设已经通过文本分段获得了n个chunk：[c1,c2,c3,…,cn]，那么embedding模型会将这n个chunk分别转化为向量：[v1,v2,v3,…,vn]，并存储为向量数据库。

在检索阶段，假设用户的问题为q，那么embedding模型会将问题q转化为向量vq，并在向量数据库中找出与vq最相似的n个向量（这个值你可以自己设定），通过向量与文本段的索引关系得到文本段，作为检索结果。

提示词工程和框架

提示词 (Prompt) 可以来精细地控制大模型的输出，例如调整语气、规范格式，甚至赋予它处理文本总结、推断、转换等多种任务的能力。

提示词框架基本要素

当和大模型在交流时，可以将它想象是一个经过“社会化训练的”人，交流方式应当和人与人之间传递信息的方式一样。

你的需求需要清晰明确，不能有歧义。你的提问方式越清晰明确，大模型越能抓住问题的关键点，回复就越符合你的预期。

为了系统性地构建高效的上下文，我们可以遵循一个包含多个基本要素的提示词框架：任务目标、上下文、角色、受众、样例、输出格式。

这些要素共同构成了一个完整的上下文“蓝图”，能帮助你构建一个完整、有效的提示词。

要素	含义
任务目标（Object）	明确要求大模型完成什么任务，让大模型专注具体目标
上下文（Context）	任务的背景信息，比如操作流程、任务场景等，明确大模型理解讨论的范围
角色（Role）	大模型扮演的角色，或者强调大模型应该使用的语气、写作风格等，明确大模型回应的预期情感
受众（Audience）	明确大模型针对的特定受众，约束大模型的应答风格
样例（Sample）	让大模型参考的具体案例，大模型会从中抽象出实现方案、需要注意的具体格式等信息
输出格式（Output Format）	明确指定输出的格式、输出类型、枚举值的范围。通常也会明确指出不需要输出的内容和不期望的信息，可以结合样例来进一步明确输出的格式和输出方法

当然，除了上面讲的提示词框架，许多问题分析的思维范式都可以用来帮助你描述清晰具体的需求。例如，SWOT分析法、5W2H分析法等。

构建有效提示词的技巧

清晰表达需求，并使用分隔符

明确的表达需求可以确保大模型生成的内容与任务高度相关。需求包括任务目标、背景及上下文信息，还可以使用分隔符将各种提示词要素隔开。

分隔符可以使大模型抓住具体的目标，避免模糊的理解，也减少对不必要信息的处理。分隔符一般可以选择 “【】”、“<< >>”、“###”来标识关键要素，用“===”、“—”来分隔段落，或者使用xml标签如<tag> </tag>来对特定段落进行标识。

当然，分隔符不止上述提到的几种，只需要起到明确阻隔的作用即可。需要注意的是，如果提示词中已大量使用某种符号（如【】），则应避免用该符号作为分隔符，以防混淆。

限定角色和受众

角色指大模型在特定场景下应扮演的身份，如专家、顾问或助手。

受众是使用模型输出的目标用户群体，如普通消费者或学生。这有助于开发者定制内容的风格和深度。

以下示例将展示不同的系统角色对输出文本风格和内容的影响，用户的问题为：qwen-vl是什么？

角色	大模型算法工程师
提示模板	“你是资深的大模型算法工程师，请根据用户的问题进行解答\n” “---------------------\n” “{context_str}\n” “---------------------\n” “问题：{query_str}\n。” “回答：”
用户问题	Qwen-VL
输出回答	Qwen-VL是阿里巴巴云推出的一种多模态预训练模型，它结合了文本和图像处理能力，能够理解和生成与图像相关的文本描述。简单来说，Qwen-VL可以看作是一个能够“看图说话”的人工智能助手，它不仅能够理解图片的内容，还能根据图片内容生成相应的文字描述或回答相关问题。这种技术在多个领域都有广泛的应用前景，比如自动图像标注、视觉问答系统、基于内容的图像搜索等。对于新媒体运营而言，Qwen-VL这样的工具可以帮助提高内容创作效率，增强用户体验，为用户提供更加丰富多元的信息展示方式。

小学老师
“你是一名小学老师，请根据用户的问题进行解答\n” “---------------------\n” “{context_str}\n” “---------------------\n” “问题：{query_str}\n。” “回答：”
Qwen-VL
小朋友们，我们今天来认识一个新朋友，它的名字叫做Qwen-VL！ Qwen-VL就像是一个非常聪明的机器人，它拥有“眼睛”👀和“大脑”🧠。它能“看”图片、视频，还能理解它们的意思，就像我们一样！ 比如，你给它看一张小猫玩毛线球的图片，它不仅能认出这是一只小猫🐱，还能告诉你它在玩毛线球🧶。 更厉害的是，你还可以问它：“小猫是什么颜色的？”，它就能告诉你小猫的颜色。 它还能理解视频里的内容，比如你给它看一段小朋友们踢足球⚽️的视频，它能告诉你谁在踢球，球踢到了哪里，甚至还能猜到接下来可能会发生什么！ Qwen-VL就像一个正在学习的小朋友，它还在不断地学习和进步，将来它会变得更聪明，能做更多的事情，帮助我们更好地了解这个世界！

规定输出格式

有时候，开发者在设计大模型应用时，需要采用结构化的数据作为下游系统的输入，才能完成整个应用的开发，但是一般大模型是输出连续的文本。不用担心，大模型有结构化输出的能力。

你只需在提示词中指定输出的格式和要求，大模型有很大可能会输出结构化的内容。

在下面的示例中，将基于提示词模板，以答疑机器人的身份帮助公司开发的文档进行文档质量审查，并将结果以json的格式输出：

question_task= """
【任务要求】
你将看到一句话或一段话。你需要审查这段话中有没有错别字。如果出现了错别字，你要指出错误，并给出解释。
“的” 和 “地” 混淆不算错别字，没有错误
---
【输出要求】
请你只输出json格式，不要输出代码段
其中，label只能取0或1，0代表有错误，1代表没有错误
reason是错误的原因
correct是修正后的文档内容
---
【用户输入】
以下是用户输入，请审阅：
"""

由上述示例的结果可知，在提示词question_task中注明了输出格式为json，也规定了输出的内容，大模型成功的输出了格式化的内容。这种稳定的格式化输出，使得在现有的系统中接入大模型这个操作变得具有可行性。

提供少样本示例

在上个例子中，提示词规定了输出的格式，大模型成功生成了格式化的内容。

然而，如果希望大模型输出的内容不仅格式正确，而且风格和结构也保持一致，可以提供几个样例作为参考。这相当于给大模型提供了一本“参考书”。

question_task= """
【任务要求】
请根据用户的主题，结合下面【样例】给的例子，理解和使用一致的风格和结构继续创作内容，不要输出多余的内容。
---
【输出要求】
最终输出需要以Markdown格式呈现，请注意，在你的回答中包含所有必要的Markdown元素，如标题、列表、链接、图片引用、加粗等，以便于阅读、后续编辑和保存。
---
【样例】
### 示例1: 制作简易书签
# 简易书签制作教程
## 材料清单
- 彩色卡纸
- 剪刀
- 装饰贴纸
- 铅笔
## 步骤
1. 选择一张彩色卡纸。
2. 用铅笔在卡纸上画出一个长方形，尺寸约为2英寸 x 6英寸。
3. 沿着铅笔线剪下长方形。
4. 使用装饰贴纸对书签进行个性化装饰。
5. 完成！现在你有了一个独一无二的书签。
## 结束语
希望这个教程能帮助你制作出满意的书签！
---
【用户输入】
以下是用户的要求创作的主题：
"""

给模型“思考”的时间

对于一些复杂的任务来说，使用上面提到的提示词也许还不能帮助大模型完成任务。但是你可以通过让大模型一步步“思考”，引导大模型输出任务的中间步骤，允许大模型在进行推理之前，得到更多的依据，从而提升在复杂任务的表现能力。

思维链（COT）方法是让模型进行思考的一种方法。它通过让模型处理中间步骤，逐步将复杂问题分解为子问题，最终推导出正确答案。

使用COT方法，让大模型逐步进行思考。

question = """某教育培训机构（以下简称“公司”）在2023年度发生了以下主要支出：
为了给不同城市的学校学生上课，公司的老师全年共出差了5次，每次出差时间为一周，具体费用如下：
- 交通费及住宿费：平均1600元/次
- 教学用具采购费用：公司在年初一次性购买了一批教学用具，总价为10000元，预计可以使用4年。
### 问题描述
请根据上述背景信息，完成以下任务：
计算全年因教师出差而产生的差旅总费用，包括摊销的教学用具。
### 输出要求
请你一步步推导，计算总差旅费用"""

在开发大模型应用时，可以在提示词中添加思维链的方法，可以确保一些推理任务能正确执行。

使大模型进行 “思考”的方法还有很多种，比如：思维树（ToT)、思维图（GOT） 等。但是就目前大模型的发展来说，仅靠引导大模型“思考”还是无法完成更复杂的工作。大模型也逐渐从COT的提示方法向多智能体（Agent）方向进行发展。

推理大模型

前面所讲的提示词技巧和提示词框架可以广泛适用于通用大模型（如Qwen2.5-max、GPT-4、DeepSeek-V3），这类模型面向通用对话、知识问答、文本生成等广泛的场景。

除了通用大模型，目前还有一类专门为“推理”设计的大模型——推理大模型。

什么是推理大模型?

相较于通用大模型，推理大模型通常在解决复杂问题时更可靠，比如在数学解题、代码编写、法律案件分析等需要严谨推理的场景。

并不是说推理模型一定更好，两种模型都有各自的应用场景，下表从一些典型维度对这两类模型进行了对比：

维度	推理模型	通用模型
设计目标	专注于逻辑推理、多步问题求解、数学计算等需要深度分析的任务	面向通用对话、知识问答、文本生成等广泛场景
训练数据侧重	大量数学题解、代码逻辑、科学推理数据集增强推理能力	覆盖百科、文学、对话等多领域海量数据
典型输出特征	输出包含完整推导步骤，注重逻辑链条的完整性	输出简洁直接，侧重结果的自然语言表达
响应速度	复杂推理任务响应较慢（需多步计算）	常规任务响应更快（单步生成为主）

推理模型还是通用模型？如何选择？以下是一些推荐：

• 明确的通用任务：对于明确定义的问题，通用模型一般能够很好地处理。
• 复杂任务：对于非常复杂的任务，且需要给出相对更精确和可靠

的答案，推荐使用推理模型。

这些任务可能有：

• 模糊的任务：任务相关信息很少，你无法提供模型相对明确的指引。
• 大海捞针：传递大量非结构化数据，提取最相关的信息或寻找关联/差别。
• 调试和改进代码：需要审查并进一步调试、改进大量代码。

• 速度和成本：一般来说推理模型的推理时间较长，如果你对于时间和成本敏感，且任务复杂度不高，

通用模型可能是更好的选择。

当然你还可以在你的应用中结合使用两种模型：使用推理模型完成Agent的规划和决策，使用通用模型完成任务执行。

适用于推理大模型的提示词技巧

推理模型在面对相对模糊的任务也能给出详尽且格式良好的响应。

你依然可以通过提示词技巧保证推理大模型的推理质量的下限：

技巧一：保持任务提示简洁清晰，提供足够的背景信息

之前介绍的清晰表达需求同样适用于推理模型，虽然推理模型能力很强，但却不能“看穿人的想法”，你需要保持提示简洁、清晰，从而让推理大模型专注于核心任务。

技巧二：避免思维链提示

一般来说，你无需提示推理模型“逐步思考”或“解释你的推理”，因为它们本身会进行深入的思考，你的提示可能反而限制推理模型的发挥。除非你需要大模型严格按照固定的思路去推理，这种情况很少发生。

技巧三：根据模型响应调整提示词

推理模型因其回复形式(包含思考过程)，天然适合你分析它的思考推理结论的过程，便于你调整提示词。

因此，你不需要纠结提示词是否足够完善，只需要不断与推理模型对话，过程中补充信息，完善提示词即可。

比如当你的描述太抽象或无法准确描述时，你可以用之前讲到的增加示例的技巧来明确这些信息，这些示例有时可以从与模型的对话历史中挑选出来。 这个过程可以是重复多次的，不断尝试调整提示，让模型不断推理迭代，直到符合你的要求。

技巧四：让推理模型成为你的“提示词教练”

由于推理模型擅长分步思考和逻辑推导，它们在分析一个提示词的优缺点、并系统性地提出改进建议方面表现得尤为出色。

它们不仅能给你一个更好的提示词，还能清晰地展示出“为什么”这样改会更好，让你在优化过程中也能学到提示词工程的精髓。

推理模型与非推理模型的使用

以上充分展示了将合适的工具用在合适的任务上的重要性，这背后是 任务复杂性 与 执行成本（时间与费用） 之间的权衡：

通用模型（非推理模型）：

优势：执行速度快，成本较低。

适用场景：适合执行相对直接、明确的任务，例如根据一个已经优化好的提示词进行信息提取、格式转换或简单问答。

推理模型：

优势：擅长处理复杂、模糊或需要深度逻辑推导的任务。

适用场景：更适合执行“元任务”（meta-task），例如分析和优化另一个任务（即提示词本身）的定义、进行复杂的规划或调试代码。

成本：由于需要进行多步思考，其响应时间通常更长，成本也相对更高。

在你构建自己的大模型应用时，混合使用这两种模型往往是实现最佳性价比的策略。

你可以借鉴这种思路，构建一个“分工明确”的智能系统： 当任务需要深度思考或规划时，引入推理模型来充当“规划师”或“分析师”的角色，让它来分解复杂任务或优化流程；然后，将拆解后的、更简单的子任务交由通用模型或其他工具来高效、低成本地执行。

这种协作模式，能让你在保证高质量输出的同时，有效控制应用的响应时间和运行成本。

RAG的自动化评测

为了系统化地评测RAG系统，业界出现了一些非常实用的开源自动化评测框架，这些框架通常会从以下几个维度进行评估：

• 召回质量 (Retrieval Quality)： RAG系统是否检索到了正确且相关的文档片段？
• 答案忠实度 (Faithfulness)： 生成的答案是否完全基于检索到的上下文，没有“胡编乱造”（幻觉）？
• 答案相关性 (Answer Relevance)： 生成的答案是否准确地回答了用户的问题？
• 上下文利用率/效率 (Context Utilization/Efficiency)： 大模型是否有效地利用了所有提供给它的上下文信息？（这与我们之前提到的“Lost in the Middle”和“知识浓度”密切相关） 这里介绍几个当前比较流行且功能强大的RAG评测框架：

Ragas

这是领域里非常出名的一个框架，它的核心思想是“让大模型来帮助你评估RAG系统”。

在评测时，Ragas 会调用一个大模型作为评测专家来阅读你的问题、RAG检索到的上下文和生成的答案，然后根据预设的指标给出分数。

Ragas的评估指标高度契合RAG系统的痛点，主要包括：

• 整体回答质量的评估：

• Answer Correctness，用于评估 RAG 应用生成答案的准确度。

• 生成环节的评估：

• Answer Relevancy，用于评估 RAG 应用生成的答案是否与问题相关。
• Faithfulness，用于评估 RAG 应用生成的答案和检索到的参考资料的事实一致性。

• 召回阶段的评估：

• Context Precision，用于评估 contexts 中与准确答案相关的条目是否排名靠前、占比高（信噪比）。
• Context Recall，用于评估有多少相关参考资料被检索到，越高的得分意味着更少的相关参考资料被遗漏。

该框架提供了Python库，只需几行代码就能集成到你的RAG工作流中，也是本章后续介绍的重点。

TruLens

这个框架专注于评估的可观测性，它不仅仅告诉你RAG哪里可能有问题，它还能帮你追溯RAG的整个运行过程。

包括每次运行的输入、输出、中间步骤、调用的大模型、检索召回的上下文等等，并提供一系列“反馈函数”来自动化评估这些运行。

TruLens 框架可以与LangChain、LlamaIndex等框架无缝集成，并提供了一套可视化工具，展示每次RAG调用的详细过程。

同时，TruLens 提供了细粒度的反馈函数，从多个角度评估RAG性能，帮助你快速定位问题。其主要评估指标包括：

• Groundedness：生成的答案是否是来自于检索召回的知识
• Answer Relevance：生成的答案是否与问题相关
• Context Relevance：评估召回的知识是否跟问题相关。

DeepEval

DeepEval 则将传统软件开发的测试理念引入到RAG应用中。它鼓励你采用单元测试和测试驱动开发（TDD）的思想，在RAG功能开发前就编写评估测试，确保应用性能从一开始就符合预期。

为此，DeepEval提供了一个专门的测试框架，让你能够像编写传统软件的单元测试一样，为RAG系统创建LLM评估测试。

它支持为每个测试用例设置明确的通过/失败（Pass/Fail）阈值，这使得DeepEval能轻松集成到你的持续集成/持续部署（CI/CD）流程中，从而实现自动化回归测试。

DeepEval 的主要评测指标类似Ragas，也支持Faithfulness, Answer Relevance, Context Relevance, Context Recall等。

你可以访问DeepEval官网了解更多内容。

自定义评测框架

除了前面介绍的Ragas、TruLens、DeepEval等专业评测框架，你可能也接触过其他的开源评测工具，比如LlamaIndex和LangChain这些主流RAG开发框架本身也有内置评估工具。

这些评估工具能让你在构建RAG流程的同时，方便地进行性能评估，实现无缝衔接。但是，在某些特定场景下，你可能需要更灵活、更贴合业务的评估方式，这时你也可以选择自定义评测框架。

对于评测一个智能客服系统而言，你不仅仅想知道RAG有没有“瞎说”或者答案是否“相关”，你更想知道它是否符合你业务的特定规则，或者提供的答案是否真正解决了用户的痛点。

• 案例一：当用户询问“报销的流程是什么？”，你们的业务专家可能会要求“好的报销答案，必须明确包含报销单链接和二级主管审批信息。”或者“好的答案，必须引导用户到费用系统提交报销申请。”，这样才能满足“流程合规”的要求。
• 案例二：当用户询问“订单延迟了怎么办？”，更好的回答可能是先要“安抚用户的情绪，再给出物流状态，预期送达时间、延误原因（如果已知）、以及后续处理（如退款/投诉）的指引。”而不仅仅是回答“您的订单正在派送中，请耐心等待”。

因此，你可以把“流程可操作性”、“政策合规性”、“情绪安抚度”、“问题解决完备性”等指标，加入你的自定义评测框架。

请注意：领域专家的深度参与是评测系统乃至AI应用成功的关键。使用自动化评测框架并非要让机器彻底取代人工判断，而是旨在为评测提效。

前面介绍的许多自动化框架（如Ragas）会利用大模型来充当“评委”，对RAG表现进行初步判断。

然而，只有领域专家才能提供那些最宝贵的、真正反映业务需求的高价值“正确答案”（Ground Truth），并对用户提问和RAG回答的正确性进行权威性的审定。

因此，我们必须让领域专家深度参与到评测集的构建和系统性评估中。

自动化评测的真正价值，在于它能将专家提供的这些宝贵Ground Truth或评估标准，转化为大规模、可重复的日常评测任务，从而解放专家的时间，让他们聚焦于更具挑战性的问题分析和优化策略制定，而非陷入重复性的判断劳动中。

评估检索召回效果

Ragas 中的 context precision 和 context recall 指标可以用于评估 RAG 应用中的检索的召回效果。

• Context precision 会评估检索召回的参考信息（contexts）中与准确答案相关的条目是否排名靠前、占比高（信噪比），侧重相关性。
• Context recall 则会评估 contexts 与 ground_truth 的事实一致性程度，侧重事实准确度。

实际应用时，可以将两者结合使用。

为了计算这些指标，你需要准备的数据集应该包括以下信息：

• question，输入给 RAG 应用的问题。
• contexts，检索召回的参考信息。
• ground_truth，你预先知道的正确的答案。

打造卓越的评测运营体系

自动化评测虽然能有效提升评测效率，但更大的挑战来自于构建高质量的评测样本以及如何凝练、积累深厚的领域知识。

因此，你还需要结合自身业务特点，建立一套完善的评测运营体系。

构建高质量评测集

自动化评测的有效性，完全取决于评测集的质量。一个好的评测集应该能反映真实的业务需求，而不是技术人员凭空想象的问题。

评测集的问题从哪里来？

评测集中的问题应该来源于真实用户场景：

• 用户问题抽样：从线上系统收集用户实际提出的问题，按频率和类型进行抽样
• 用户工单/反馈：客服系统中用户提交的工单、投诉和反馈，往往代表了用户最关心的痛点
• 业务场景覆盖：确保问题覆盖主要业务场景，包括高频问题和边界情况

标准答案从哪里来？

评测集中的标准答案必须由业务领域专家提供：

• 为什么是业务专家？

  只有业务专家才知道"什么答案是对的、好的、符合业务规范的"

• 技术人员的局限：技术人员可以判断"系统有没有检索到相关内容"，但无法判断"这个答案在业务上是否正确、完整、合规"

关键认知：正因为评测集的问题来自真实用户、答案来自业务专家，所以自动化评测的结果才能反映真实的业务效果。

评测先行的优化策略

在大模型应用开发中，评测应该走在优化前面，而不是"先优化，再评测看效果"。

阶段	关键动作	责任方
明确业务目标	定义可量化的业务指标（如满意度 > 90%）	业务方/产品
构建评测集	从用户问题抽样，专家编写答案	业务专家
建立自动化评测	配置评测框架，获得基线分数	技术+业务
针对性优化	根据指标定位问题，实施优化	技术+业务
评测验证	对比优化前后效果	技术+业务
持续迭代	跟踪意图变化，更新评测集	业务专家

为什么要"评测先行"？

• 避免盲目优化：没有评测基线，你不知道优化是否真的有效
• 量化改进效果：从"感觉变好了"变成"指标提升了 15%"
• 防止"跷跷板效应"：一处优化可能导致另一处退步，评测能发现整体是否提升

业务指标与评测指标对齐

Ragas 提供的 Context Recall、Context Precision、Answer Correctness 等是算法指标，但最终我们关心的是业务指标。

理解它们之间的关系，才能让评测真正服务于业务目标。

层级	指标示例	说明
业务指标	用户问答满意度 > 90%	最终目标，衡量业务价值
核心技术指标	召回准确率 > 85%、响应时间 < 2s	拆解业务指标，可工程化衡量
算法指标	Context Precision、Answer Correctness	自动化评测，快速迭代验证

核心原则：算法指标是手段，业务指标才是目标。不要为了提升 Context Recall 而优化，而要为了提升用户满意度而优化。

持续运营评测体系

你可以从"找到最懂业务的人，用科学的方法，深度参与评测"入手：

• 让业务专家参与 AI 评测：例如让电商客服主管评测促销规则回复准确性，让物流专员评测运费时效回复准确性
• 从最终用户视角出发：从用户视角评判答案的正确性、简洁性与可操作性
• 建立闭环机制：“发现问题 → 改进优化 → 跟踪效果 → 迭代指标”，让评测持续驱动业务系统改进

下图展示了一个完整的评测运营体系架构：

优化RAG应用提升问答准确度

正如前言提到的，你需要让大模型拿到正确的"参考书"，才能给出正确的"答案"。

因此，你可以尝试增加每次拿到"参考书"的数量（增加召回的文档切片数量），或者将"参考书中的知识点"整理成结构化的表格（文档内容结构化）。

让大模型获取到更多参考信息

单纯增加召回的切片数量并不是一个好方法。想想看，如果这种方法能解决问题，那么不如召回整个知识库，这样不会遗漏任何的信息……

可是这不仅会超出大模型的输入长度限制，过多的无关信息还会降低大模型回答的效率和准确性。

给大模型结构更清晰的参考信息

在实际应用中，文档的组织结构对检索效果有着重要影响。

想象一下，同样的信息，放在一个结构清晰的表格中和散落在一段普通文字里，哪个更容易查找和理解？显然是前者。

大语言模型也是如此。当把原本在表格中的信息转换成普通文本时，虽然信息本身没有丢失，但结构性却降低了。这就像是把一个整齐的抽屉变成了一堆散乱的物品，虽然东西都在，但查找起来就没那么方便了。

Markdown格式是一个很好的选择，因为它：

• 结构清晰，层次分明
• 语法简单，易于阅读和维护
• 特别适合RAG（检索增强生成）场景下的文档组织

熟悉 RAG 的工作流程

RAG是一种结合了信息检索和生成式模型的技术，能够在生成答案时利用外部知识库中的相关信息。

它的工作流程可以分为几个关键步骤：解析与切片、向量存储、检索召回、生成答案等。具体的概念你可以回顾"扩展答疑机器人的知识范围"这一节。

RAG应用各个环节与改进策略

文档准备阶段

在传统的客服系统中，客服人员会根据用户所提问题，积累知识库，并共享给其他客服人员参考。在构建 RAG 应用时，这一过程同样不可缺少。

• 意图空间：可以把用户提问背后的需求绘制成点，这些点组成了一个用户意图空间。
• 知识空间：而你沉淀在知识库文档中的知识点，则构成了组成一个知识空间。这里的知识点，可以是一个段落、或者一个章节。

当我们将意图空间和知识空间投影到一起，会发现两个空间存在交集与差异。这些区域分别对应了后续的三个优化策略：

1. 重叠区域：

• 即可以依靠知识库的内容来回答用户问题的部分，这是 RAG 应用效果保障的基础。
• 对于这部分用户意图，你可以通过优化内容质量、优化工程和算法，不断地提升回答质量。

2. 未被覆盖的意图空间：

• 因为缺乏知识库内容的支撑，大模型容易输出“幻觉”回答。例如，公司新增了一个"数据分析部"，但知识库中没有相关文档，不论如何改进工程算法，RAG 应用都无法准确回答这一问题。
• 你需要做的是主动补充缺漏的知识，不断跟进用户意图空间的变化。

3. 未被利用的知识空间：

• 召回不相关知识点可能会干扰大模型的回答。
• 因此，需要优化召回算法避免召回无关内容。此外，你还需要定期查验知识库，剔除无关内容。

文档解析与切片阶段

首先，RAG应用会解析你的文档内容，然后对文档内容进行切片。

大模型在回答问题时拿到的文档切片如果缺少关键信息，会回答不准确；如果拿到的文档切片非关联信息过多（噪声），也会影响回答质量。即过少或过多的信息，都会影响模型的回答效果。

因此，在对文档进行解析与切片时，需要确保最终的切片信息完整，但不要包含太多干扰信息。

在文档解析与切片阶段，你可能会遇到以下问题：

类别	细分类型	改进策略	场景化示例
文档解析	文档类型不统一，部分格式的文档不支持解析 比如前面用到的 SimpleDirectoryLoader 并不支持 Keynote 格式的文件	开发对应格式的解析器，或转换文档格式	例如，某公司使用了大量的 Keynote 文件存储员工信息，但现有的解析器不支持 Keynote 格式。可以开发 Keynote 解析器或将文件转换为支持的格式（如 PDF）。
已支持解析的文档格式里，存在一些特殊内容 比如文档里嵌入了表格、图片、视频等	改进文档解析器	例如，某文档中包含了大量的表格和图片，现有解析器无法正确提取表格中的信息。可以改进解析器，使其能够处理表格和图片。
…	…	…
文档切片	文档中有很多主题接近的内容 比如工作手册文档中，需求分析、开发、发布等每个阶段都有注意事项、操作指导	扩写文档标题及子标题 「注意事项」=>「需求分析>注意事项」 建立文档元数据（打标）	例如，某文档中包含多个阶段的注意事项，用户提问“需求分析的注意事项是什么？”时，系统返回了所有阶段的注意事项。可以通过扩展标题和打标来区分不同阶段的内容。
文档切片长度过大，引入过多干扰项	减少切片长度，或结合具体业务开发为更合适的切片策略	例如，某文档的切片长度过大，包含了多个不相关的主题，导致检索时返回了无关信息。可以减少切片长度，确保每个切片只包含一个主题。
文档切片长度过短，有效信息被截断	扩大切片长度，或结合具体业务开发为更合适的切片策略	例如，某文档中每个切片只有一句话，导致检索时无法获取完整的上下文信息。可以增加切片长度，确保每个切片包含完整的上下文。
…	…	…

没有最好的切片方法，只有最适合你场景的方法。

你可以尝试不同的切片方法，观察 Ragas 评估结果，找到最适合你需求的方案。

切片向量化与存储阶段

文档切片后，你还需要对其建立索引，以便后续检索。

一个常见的方案是使用嵌入（Embedding）模型将切片向量化，并存储到向量数据库中。

在这一阶段，你需要选择合适的 Embedding 模型以及向量数据库，这对于提升检索效果至关重要。

不同的 Embedding 模型对相同的几段文字进行计算时，得到的向量可能会完全不同。通常越新的 Embedding 模型，其表现越好。

在构建 RAG 应用时,你有多种向量存储方案可以选择,从简单到复杂依次是：

当数据量增大时,可以使用开源的向量数据库,如 Milvus、Qdrant 等。这些数据库提供了数据持久化和高效检索能力。

优点是功能完整、可控性强；缺点是需要自行部署维护。

检索召回阶段

检索阶段会遇到的主要问题就是，很难从众多文档切片中，找出和用户问题最相关、且包含正确答案信息的片段。

从切入时机来看，可以将解法分为两大类：

1. 在执行检索前，很多用户问题描述是不完整、甚至有歧义的，你需要想办法还原用户真实意图，以便提升检索效果。
2. 在执行检索后，你可能会发现存在一些无关的信息，需要想办法减少无关信息，避免干扰下一步的答案生成。

时机	改进策略	示例
检索前	问题改写	「附近有好吃的餐厅吗？」=> 「请推荐我附近的几家评价较高的餐厅」
问题扩写 通过增加更多信息，让检索结果更全面	「张伟是哪个部门的？」=> 「张伟是哪个部门的？他的联系方式、职责范围、工作目标是什么？」
基于用户画像扩展上下文 结合用户信息、行为等数据扩写问题	内容工程师提问「工作注意事项」=> 「内容工程师有哪些工作注意事项」 项目经理提问「工作注意事项」=> 「项目经理有哪些工作注意事项」
提取标签 提取标签，用于后续标签过滤+向量相似度检索	「内容工程师有哪些工作注意事项」=> * 标签过滤：{“岗位”: “内容工程师”} * 向量检索：「内容工程师有哪些工作注意事项」
反问用户	「工作职责是什么」=> 大模型反问：「请问你想了解哪个岗位的工作职责」 *实现反问的提示词可以参考：*10分钟构建能主动提问的智能导购
思考并规划多次检索	「张伟不在，可以找谁」 => 大模型思考规划： => task_1：张伟的职责是什么, task_2：${task_1_result}职责的人有谁 => 按顺序执行多次检索
…	…
检索后	重排序 ReRank + 过滤 多数向量数据库会考虑效率，牺牲一定精确度，召回的切片中可能有一些实际相关性不够高	chunk1、chunk2…、chunk10 => chunk 2、chunk4、chunk5
滑动窗口检索 在检索到一个切片后，补充前后相邻的若干个切片。这样做的原因是：相邻切片之间往往存在语义联系，仅看单个切片可能会丢失重要信息。 滑动窗口检索确保了不会因为过度切分而丢失文本间的语义连接。	常见的实现是句子滑动窗口，你可以用下方的简化形式来理解： 假设原始文本为：ABCDEFG（每个字母代表一个句子） 当检索到切片：D 补充相邻切片后：BCDEF（前后各取2个切片） 这里的BC和EF是D的上下文。比如： * BC可能包含解释D的背景信息 * EF可能包含D的后续发展或结果 * 这些上下文信息能帮助你更准确地理解D的完整含义 通过召回这些相关的上下文切片，你可以提高检索结果的准确性和完整性。
…	…

问题改写

为什么需要问题改写？

想象一下你在搜索"找张伟"或者"张伟 部门"这样的关键词。看似简单，但对于RAG系统来说，这样零散的搜索词可能不太好回答。因为在真实场景中，可能存在多个叫张伟的同事，而且用户输入的关键词往往过于简单，缺少必要的上下文信息。

问题改写能带来什么？

问题改写就像是帮助系统更好地理解用户意图。比如当你问"找张伟"时，系统可以把问题改写为更完整的形式，比如"请告诉我公司中所有叫张伟的员工及其所在部门"。这样的改写不仅能提高检索的准确性，还能让回答更加全面。

那么，如果让问题表达得更完整一些会怎样？比如明确说明你想知道"公司里所有叫张伟的同事的部门信息"。接下来，你可以试试用大模型来改写问题，看看效果会不会更好。

【方法一：使用大模型扩充用户问题】

你可以让大模型充当一个问题改写助手。它会帮你把简单的问题改写得更加完整和清晰。比如，它不仅会考虑到可能存在多个张伟的情况，还会把相关的上下文信息都补充进去。

看看具体怎么做：

query_gen_str = """\
系统角色设定:
你是一个专业的问题改写助手。你的任务是将用户的原始问题扩充为一个更完整、更全面的问题。
规则：
1. 将可能的歧义、相关概念和上下文信息整合到一个完整的问题中
2. 使用括号对歧义概念进行补充说明
3. 添加关键的限定词和修饰语
4. 确保改写后的问题清晰且语义完整
5. 对于模糊概念，在括号中列举主要可能性
原始问题:
{query}
请生成一个综合的改写问题，确保：
- 包含原始问题的核心意图
- 涵盖可能的歧义解释
- 使用清晰的逻辑关系词连接不同方面
- 必要时使用括号补充说明
输出格式：
[综合改写] - 改写后的问题
"""

【方法二：将单一查询改写为多步骤查询】

除了改写问题，你还可以尝试另一种思路：把复杂的问题拆解成简单的步骤。

LlamaIndex 提供了两个强大的工具来实现这个功能：

• StepDecomposeQueryTransform： 这个工具可以帮你把一个复杂问题分解成多个子问题。比如对于"张伟是哪个部门的?",它会先分解为：

1. “公司里有几个叫张伟的员工？”
2. “这些张伟分别在哪些部门？”

这样可以更全面地获取所有张伟的信息。

• MultiStepQueryEngine： 这个查询引擎会按顺序处理这些子问题。它会先获取公司所有张伟的信息，然后再查询每个张伟的部门信息，最终将答案整合成一个完整的回应，告诉用户"公司有三名张伟，分别在教研部、课程开发部和IT部"。

这种方法就像解决数学题一样 - 把大问题分解成小问题往往更容易得到准确的答案。不过要注意，这种方法会多次调用大模型，所以会消耗更多的token。

通过这种方式，系统会先理解问题的整体目标，然后把它分解成几个小步骤来逐一解决。比如对于"张伟是哪个部门的"这个问题，系统可能会先找到所有的张伟，然后再分别查询他们的部门信息。

【方法三：用假设文档来增强检索（HyDE）】

前面的方法都是在调整问题本身，现在让我们换个思路：如果我们先假设一个可能的答案会怎样？这就是HyDE（Hypothetical Document Embeddings）方法的独特之处。

它的工作方式很有趣：

1. 先让大模型基于问题编一个"假想的答案文档"
2. 用这个假想文档来检索真实文档
3. 最后用检索到的真实文档来生成实际答案

这就像你在找一本书时，心里已经有了一个大致的内容轮廓，然后用这个轮廓去图书馆匹配相似的书籍。

有趣的是，虽然这个"假想文档"完全是AI编造的，但它的结构和风格与真实的公司员工信息非常相似。

LlamaIndex提供了灵活的控制机制来优化这个过程：

HyDEQueryTransform类允许我们通过以下方式精确控制假想文档的生成：

• 自定义LLM：通过llm参数传入不同的大模型配置，可以选择更适合的语言模型来生成假想文档
• 提示词模板：通过hyde_prompt参数自定义提示词模板，精确控制输出的格式和内容
• 查询策略：使用include_original参数决定是否将原始查询与假想文档结合使用

TransformQueryEngine则作为查询引擎的包装器，它会：

1. 先调用HyDEQueryTransform生成假想文档
2. 使用假想文档进行向量检索
3. 最后返回查询结果

这种架构让我们能在不修改底层查询引擎的情况下，通过调整HyDEQueryTransform的参数来优化检索效果。即使假想文档的具体内容可能不够准确，但通过精心设计的配置，它可以帮助系统更准确地检索相关信息。

提取标签增强检索

在向量检索的基础上，我们还可以添加标签过滤来提升检索精度。

这种方式类似于图书馆既有书名检索，又有分类编号系统，能让检索更精准。

标签提取有两个关键场景：

1. 建立索引时，从文档切片中提取结构化标签
2. 检索时，从用户问题中提取对应的标签进行过滤

当我们建立索引时，可以将这些标签与文档切片一起存储。这样在检索时，比如用户问"张伟是哪个部门的"，我们可以：

1. 从问题中提取人名标签 {“key”: “人名”, “value”: “张伟”}
2. 先用标签过滤出所有包含"张伟"的文档切片
3. 再用向量相似度检索找出最相关的内容

这种"标签过滤+向量检索"的组合方式，能大幅提升检索的准确性。特别是在处理结构化程度较高的企业文档时，这个方法效果更好。

生成答案阶段

现在，大模型会根据你的问题和检索召回的内容，生成最终的答案。然而，这个答案可能还是不及你的预期。你可能会遇到的问题有：

1. 没有检索到相关信息，大模型捏造答案。
2. 检索到了相关信息，但是大模型没有按照要求生成答案。
3. 检索到了相关信息，大模型也给出了答案，但是你希望 AI 给出更全面的答案。

为了解决这些问题，你可以从以下角度着手分析与解决：

1. 选择合适的大模型：

2. 如果只是简单的信息查询总结，小参数量的模型足以满足需求。

3. 如果你希望答疑机器人能完成较为复杂的逻辑推理，建议选择参数量更大、推理能力更强的大模型，比如 qwen-plus甚至是 qwen-max。

4. 如果你的问题需要查阅大量的文档片段，建议选择上下文长度更大的模型，比如 qwen-long、qwen-turbo或qwen-plus。

5. 如果你构建的 RAG 应用面向一些非通用领域，如法律领域，建议使用面向特定领域训练的模型，如farui-plus。

6. 充分优化提示词模板，比如：

7. 明确要求不编造答案：大模型可能会产生一些不真实的内容，通常称为幻觉。你可以通过提示词要求大模型：「如果所提供的信息不足以回答问题，请明确告知"根据现有信息，我无法回答这个问题。"切勿编造答案。」，来减少大模型产生幻觉的几率。

8. 添加内容分隔标记：检索召回的文档切片如果随意混杂在提示词里，人也很难看清整个提示词的结构，大模型也会受到干扰。建议将提示词和检索切片明确地分开，以便大模型能够正确地理解你的意图。

9. 根据问题类型调整模板：不同问题的回答范式可能是不同的，你可以借助大模型识别问题类型，然后映射使用不同的提示词模板。比如有些问题，你希望大模型先输出整体框架，然后再输出细节；有些问题你可能希望大模型言简意赅的给出结论。

10. 调整大模型的参数，比如：

11. 如果你希望大模型输出在相同的问题下，输出的内容尽可能相同，你可以在每次模型调用时传入相同的seed值。

12. 如果你希望大模型在回答用户问题时不要总是用重复的句子，你可以适当调高 presence_penalty 值。

13. 如果你希望查询事实性的内容，可以适当降低 temperature 或 top_p 值；反之，查询创造性的内容时，可以适当增加它们的值。

14. 如果你需要限制字数（如生成摘要、关键词）、控制成本或减少响应时间的场景，可以适当降低max_tokens的值，但是若max_tokens过小，可能会导致输出截断，反之，需要生成大段文本时，可以提高它的值。

15. 调优大模型：如果上述方法都做了充分的尝试，仍然不及预期，或者希望有更进一步的效果提升，你也可以尝试面向你的场景调优一个模型。在后续的章节中，你将学习和实践这一点。

补充学习：

• GraphRAG 技术巧妙地结合了检索增强生成（RAG）和查询聚焦摘要（QFS）的优点，为处理大规模文本数据提供了一个强大的解决方案。
• 它把两种技术的特长融合在一起：RAG 擅长找出精确的细节信息，而 QFS 则更善于理解和总结文章的整体内容。

通过这种结合，GraphRAG 既能准确回答具体问题，又能处理需要深入理解的复杂查询，特别适合用来构建智能问答系统。

普通人如何抓住AI大模型的风口？

领取方式在文末

为什么要学习大模型？

目前AI大模型的技术岗位与能力培养随着人工智能技术的迅速发展和应用 ， 大模型作为其中的重要组成部分 ， 正逐渐成为推动人工智能发展的重要引擎 。大模型以其强大的数据处理和模式识别能力， 广泛应用于自然语言处理 、计算机视觉 、 智能推荐等领域 ，为各行各业带来了革命性的改变和机遇 。

目前，开源人工智能大模型已应用于医疗、政务、法律、汽车、娱乐、金融、互联网、教育、制造业、企业服务等多个场景，其中，应用于金融、企业服务、制造业和法律领域的大模型在本次调研中占比超过 30%。

随着AI大模型技术的迅速发展，相关岗位的需求也日益增加。大模型产业链催生了一批高薪新职业：

人工智能大潮已来，不加入就可能被淘汰。如果你是技术人，尤其是互联网从业者，现在就开始学习AI大模型技术，真的是给你的人生一个重要建议！

最后

只要你真心想学习AI大模型技术，这份精心整理的学习资料我愿意无偿分享给你，但是想学技术去乱搞的人别来找我！

在当前这个人工智能高速发展的时代，AI大模型正在深刻改变各行各业。我国对高水平AI人才的需求也日益增长，真正懂技术、能落地的人才依旧紧缺。我也希望通过这份资料，能够帮助更多有志于AI领域的朋友入门并深入学习。

真诚无偿分享！！！
vx扫描下方二维码即可
加上后会一个个给大家发
【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】

大模型全套学习资料展示

自我们与MoPaaS魔泊云合作以来，我们不断打磨课程体系与技术内容，在细节上精益求精，同时在技术层面也新增了许多前沿且实用的内容，力求为大家带来更系统、更实战、更落地的大模型学习体验。

希望这份系统、实用的大模型学习路径，能够帮助你从零入门，进阶到实战，真正掌握AI时代的核心技能！

01 教学内容

• 从零到精通完整闭环：【基础理论 →RAG开发 → Agent设计 → 模型微调与私有化部署调→热门技术】5大模块，内容比传统教材更贴近企业实战！

• 大量真实项目案例： 带你亲自上手搞数据清洗、模型调优这些硬核操作，把课本知识变成真本事‌！

02适学人群

应届毕业生‌： 无工作经验但想要系统学习AI大模型技术，期待通过实战项目掌握核心技术。

零基础转型‌： 非技术背景但关注AI应用场景，计划通过低代码工具实现“AI+行业”跨界‌。

业务赋能突破瓶颈： 传统开发者（Java/前端等）学习Transformer架构与LangChain框架，向AI全栈工程师转型‌。

vx扫描下方二维码即可
【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】

本教程比较珍贵，仅限大家自行学习，不要传播！更严禁商用！

03 入门到进阶学习路线图

大模型学习路线图，整体分为5个大的阶段：

04 视频和书籍PDF合集

从0到掌握主流大模型技术视频教程（涵盖模型训练、微调、RAG、LangChain、Agent开发等实战方向）

新手必备的大模型学习PDF书单来了！全是硬核知识，帮你少走弯路（不吹牛，真有用）

05 行业报告+白皮书合集

收集70+报告与白皮书，了解行业最新动态！

06 90+份面试题/经验

AI大模型岗位面试经验总结（谁学技术不是为了赚$呢，找个好的岗位很重要）

07 deepseek部署包+技巧大全

由于篇幅有限

只展示部分资料

并且还在持续更新中…

真诚无偿分享！！！
vx扫描下方二维码即可
加上后会一个个给大家发
【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】