大模型入门：两核心参数三大范式，小白也能轻松掌握LLM应用开发

本文详细介绍了大模型的基本范式与核心应用，重点解析了messages和tools两大核心参数，以及RAG检索增强生成和ReAct推理行动两大范式。通过翻译和计算器实例，展示了调优提示词、增加调用次数和模型微调三种主要应用方式，并强调大模型应用需结合业务场景，不能盲目依赖技术本身。文章旨在帮助读者理解大模型工作原理，降低入门门槛，为实际应用提供指导。

ai绘画-安安妮

528人浏览 · 2025-09-10 11:32:28

ai绘画-安安妮 · 2025-09-10 11:32:28 发布

本文是作者给兄弟团队做的大模型入门分享，介绍了基本大模型模式，分享出来希望帮助更多的同学参与到LLM应用建设。

前言

大模型作为新兴领域，不断地冒出来新的专有术语和新的概念，让大家觉得很神秘，捉摸不透。但是大部分复杂性的背后都会有一个极其简单便于理解的模型，本次分享最主要就是大模型的基本范式，通过范式将这些神秘感去除。

大模型虽然很厉害，很神秘，但作为使用人员，门槛是非常非常非常低的。

模型基础

虽然市面上的大型语言模型（LLMs）种类繁多，但在使用层面大家平等的都是API调包侠，因此从接口层面来剖析大模型有哪些能力。LLM的接口通常都遵循或类似于 OpenAI 的规范。这里我们以 OpenAI 的接口为例进行说明。

在与大型模型交互时，除了控制模型输出随机性的参数外，最核心的参数只有两个：messages 和 tools。可以说，市面上各种各样的大模型应用，都是基于这两个参数的基础上设计而来。

messages-大模型是怎么实现记忆的？

messages是一个对话数组，其中角色主要有：
system：代表当前对话的系统指令，一般放提示词
user：用户指令
assistant：LLM的回复
…：不同厂商会有不同的扩展定义

大模型所谓的对话记忆实际上就是依赖该数组做信息传递，如下图所示，第一轮我告诉我的名字叫屈定，第二轮的时候在问他是谁，他已经知道了我的名字，之所以知道因为我在messages的上下文中传递给了他这个信息。

使用user传递用户的对话

753767597ed93.jpeg)

使用system设置系统指令

在这里插入图片描述

提示词的不稳定容易被指令注入攻击

三张图看完，先总结下：

大模型为什么能记住之前的对话？

只是因为后台系统给了他之前的对话，并不是他自己记住。大模型的请求调用就是一个无状态的，取决于每次给的对话内容。

大模型的提示词有什么用？

大模型的提示词可以进一步控制(覆盖)模型的行为，具备高优先级，但存在不稳定性。

接下来我们就可以来理解第一个重要的大模型范式：检索增强生成，也就是RAG(Retrieval Augmented Generation)。

直白的理解为用检索到的知识，来增量生成答案的质量。比如我有一个关于数仓各种问题处理的Q&A，想要做一个问答机器人，这个问答机器人要基于我的Q&A回复用户。这个检索Q&A -> 基于检索到的Q&A回复用户，这个流程就是一个典型的RAG链路。也显而易见，RAG的最终目标是生成靠谱的答案给到用户。

RAG链路的搭建是很简单，但是效果却很难，从流程里面我们能发现两个关键点：

1.知识库检索召回：这里要解决如何召回最靠谱的答案。

2.LLM基于知识回答：这里要解决的是如何让模型在一堆知识中给出自信准确的回答。

这些都是业界在不断探索的东西，没有所谓的标准答案，只有适合当前业务的最佳方案。

tools-大模型能执行任何工具？

经常有同学会问一些大模型是否能查询odps，或者大模型能够把数仓数据导入到ob之类的问题。这些问题的背后是对LLM存在错误的理解，也就是tools参数的理解。

tools也是一个数组，包含了一堆工具集合，核心为工具的作用描述，和工具需要的参数，如下图天气工具的定义。

接下来就是使用工具，基于工具的回答至少要两次大模型请求调用：

1.将用户的对话和工具一起给到大模型，大模型需要执行的工具以及工具参数；

2.后端系统依据大模型选择结果，去执行对应的工具，拿到结果；

3.再次请求大模型，此时上下文中给到了工具执行结果，大模型基于信息回复；

先总结下：

1.大模型并不能够执行任何工具，但是大模型能够选择接下来要执行的工具。选择后工具由配合的系统来执行获取结果。

接下来我们就可以来理解第二个重要的大模型范式ReAct(Reason+Act)。

这里需要强调下，大模型的很多范式都是对生活中人类行为的模拟，因此我们也是从生活中的案例来理解大模型。

案例主题：老板让写一份调研外部大模型框架的报告

工具：互联网搜索，PPT，思维导图

思考 (Reasoning): 需要调研外部大模型框架，明确调研目标是了解行业内的主要框架、特点和应用场景。需要先明确有哪些主流框架，然后针对性地收集资料。

思考 (Reasoning): 我已经拿到了想要的资料，接下来使用思维导图搭建汇报思路

思考 (Reasoning): 信息基本收集完毕，需要将所有信息整理成结构化的报告，并使用PPT进行总结和分析。

这个思考的流程就是ReAct，后面有实际案例，这里先理解这个概念。

模型使用

大模型的应用五花八门，但都离不开上述两个核心参数，接下来围绕上述的参数，我们能利用的现有的模型交互手段主要有以下三种，包括：

调优提示词：大模型工程中的核心，提示词的优秀与否决定了你是否需要链路上做额外的兜底
增加调用次数：将一个任务拆分为多个子任务执行，最后判断结果。这是一种常用的对提示词能力的补充手段，降低单一提示词的复杂性。
模型微调：通过引入特定业务场景案例，让模型能更好地理解用户的意图和需求。

用大模型+提示词做翻译 [提示词调优]

为了更好的评价，我们选择哪吒中的英文台词，然后将英文翻译成中文，看还原度如何？

The prejudice in people's hearts is like a mountain. No matter how hard you try, you can't move it.

方案一：直接使用提示词进行翻译

## Role and Goal:

绝大多数情况下，直接使用提示词能做到的效果就已经能达到60%了（现在的模型确实强大了），下方的问题在于一些短的语句翻译不够传神。


模型	方案一翻译结果：
gemini-2.0-flash	* 人心中的成见就像一座大山，任你怎么努力也无法搬动。 * 如今想来，三年光阴，也不算长。 * 还不快快听我号令！ * 我命由我定，不由天！ * 要问我人能否改变自己的命运，我不知道。但是，逆天而行，就是哪吒的命。

方案二：提示词中引入COT（Chain-of-Thought）

COT被称为思维链，简单点来说是要告诉模型针对问题的思考步骤是什么，引导模型去按照特定思维解决问题。概念很抽象，以翻译为例，我们思考一般人是如何进行翻译的？

1.先直接翻译

2.结合上下文再审视这个翻译是否合理，有哪些改进点

3.针对改进点再斟酌修改

那么我们也让模型按照这个思路来执行翻译。

## Role and Goal:

该方案取得了意想不到的效果，针对长句翻译成短句组合形式，相比官方的来看，更像是修道者的口吻，但针对一些特殊短句用法，仍然不够理想。


模型	方案一翻译结果：	方案二翻译结果：
gemini2.0 flash	* 人心中的成见就像一座大山，任你怎么努力也无法搬动。 * 如今想来，三年光阴，也不算长。 * 还不快快听我号令！ * 我命由我定，不由天！ * 要问我人能否改变自己的命运，我不知道。但是，逆天而行，就是哪吒的命。	* 人心存偏见，如山岳难移。纵使竭尽全力，亦不可撼动分毫。 * 如今想来，三年光阴，弹指一挥间。 * 奉我号令，不得有误！ * 我命由我不由天！ * 若问世人能否逆天改命，吾不得而知。然，抗争宿命，乃哪吒之命也。

方案三：引入动态few shot

few shot指的是提示词中的少样本技巧，动态就是将这部分样本抽离到一个知识库，每一次走翻译前先去知识库里面召回TOP最相关的，然后放入到提示词的Example中。

假设我的知识库中召回了如下两句：

Item1: 原文：Be quick to obey my command

结合后提示词如下：

## Role and Goal:


模型	方案一翻译结果：	方案二翻译结果：	方案三翻译结果：
gemini2.0 flash	* 人心中的成见就像一座大山，任你怎么努力也无法搬动。 * 如今想来，三年光阴，也不算长。 * 还不快快听我号令！ * 我命由我定，不由天！ * 要问我人能否改变自己的命运，我不知道。但是，逆天而行，就是哪吒的命。	* 人心存偏见，如山岳难移。纵使竭尽全力，亦不可撼动分毫。 * 如今想来，三年光阴，弹指一挥间。 * 奉我号令，不得有误！ * 我命由我不由天！ * 若问世人能否逆天改命，吾不得而知。然，抗争宿命，乃哪吒之命也。	* 人心之偏见，如山岳岿然，纵移山填海，亦难撼其分毫。 * 事过境迁，三年光阴，亦不过弹指一挥间。 * 急急如律令 * 我命由我不由天！ * 若问人定胜天否，我亦茫然。然逆天而行，乃哪吒之宿命。

few shot这种开卷考试方法是大模型链路中一种重要的优化手段，few shot是提示词中为数不多能够动态变化的部分，且对模型整体效果影响较小，更为可控。此外业务流量一般都是符合2:8分布的，且是可收敛的，可能只需要20%的few shot案例，就能满足80%的场景诉求。

用大模型+Agent做计算器 [增加调用次数]

大家应该都看过下面的案例，大模型是很不擅长数学计算的，那么用大模型直接做计算器就非常容易出问题。

这里使用llama_index的agent框架做演示：

1.定义了三个工具函数，乘法，加法，减法

2.构建一个Agent执行模式

import os

> Running step cba1a160-74c3-4e34-bcc4-88e6a678eaf9. Step input: What is60-(20+(2*4))? Calculate step by step

上次有同学问，那么大模型在这种链路里面到底发挥了什么作用？大模型最大的能力就是自然语言理解，我们可以尝试把规则再复杂化，输入改成张三代表减法,李四代表加法,王二代表乘法,What is 60张三(20李四(2王二4))? Calculate step by step，表现仍然可以，这就带来了对自然语言的容错，会像人一样去思考，而不是固定死的逻辑。

Thought: The current language of the user is English. I need to use a tool to help me answer the question. The expression given is60张三(20李四(2王二4)), which translates to 60 - (20 + (2 * 4)). I will calculate step by step.

模型微调

这部分具体案例就不好说了，我举个实际生产的案例，在给WorldFirst做客服的时候，存在很多特殊的业务知识，比如用户在万里汇下载银行对账单 != 下载交易流水单。这里有业务背景，银行对账单是亚马逊要求的账户证明文件。这些业务背景是模型难以掌握的，此时就需要引入微调，将这部分知识内置到模型里面。

现在主流的方式都在慢慢弱化微调，因为费时费力，还不一定起到正向的效果，更多的工程实践是将提示词复杂化动态化，工程上做更多的兜底工作。

一些感想

大模型能带来很大的工作和问题思考方式的革新，让一些问题解决方式变成取决于你的想象力，但对客的业务的效果并非完全取决于大模型。很多同学认为有了LLM，业务效果，开发效率，交付质量都能很方便解决，什么都往LLM上靠拢，这是很大的误区。

以笔者参与的客服场景感想，最早都认为客服是非常适合大模型的场景，笔者同样也是这样认为。实际深入后，并非如此，尤其是在对专业度和准确率有明确要求的场景。客服作为售后，用户是带着问题带着情绪来的，他需要的是明确的解决方案，不需要机械式的安抚和吐答案。因此业办能力 + 拟人化是客服成功的两大主要因素，确定主要因素后，再去思考LLM在这些因素点上能带来什么，接着思考构建你的方案，这样的应用才是靠谱的方式。

端到端全链路追踪诊断

本方案为您介绍如何使用应用实时监控服务 ARMS 应用监控进行一站式调用链路追踪，帮助您快速定位问题，洞察性能瓶颈，重现调用参数，从而大幅提升线上问题诊断的效率。