简体中文

English

简体中文

English

主题

常见任务示例 ​

文本生成 ​

无论是哪个模型，文本生成任务他们都能完成的不错，但是如果仅输入你要续写的内容而没有相应的指令，比如“这棵树”，这句话没有加任何约束限制，base模型会添加很多的字符填满到最长回答长度，因为模型无法理解你的想法，把训练数据中重复结构的文本当作最终结果输出。instruct模型会自己“夹带私货”自己设置指令，然后根据指令回答。所以如果想要续写生成，还是要多加一些自己的任务目标的描述。

我们看下例子：

提示词 ：

JSON
这棵树

回答 ：

Plain
# 3B-Base模型
那棵树 🐉\n 🐉\n 🐉\n 🐉\n 🐉\n 🐉\n 🐉

# 3B-instruct模型
您提到的“这棵树”非常具体，但我需要更多的信息来为您提供准确的回答。例如，您是在某个特定地点看到的一棵具体的树，还是一般意义上的提问？如果您能提供更多细节，我会尽力帮助您获取相关信息或解答您的疑问。

# 7B-Base模型
这棵树在你的生活中扮演了什么角色？\n\n作为AI助手，我没有自己的生活或个人经验，所以我无法提供关于“这棵树”在现实生活中的具体角色。不过，我可以告诉你，树木在人类生活中扮演着多种重要角色：它们提供氧气、净化空气、防止水土流失、为野生动物提供栖息地，以及作为木材和其他资源的来源。此外，树木还具有文化和象征意义，在许多文化中被视为生命之源和自然界的重要组成部分。
⚠️ 从上面的提示示例中可以看出，语言模型能够基于我们给出的上下文内容 "这棵树" 完成续写。
1.对于参数量较低的Base模型，输出可能是出乎意料的，比如全是表情包，或者与你想要完成的任务相去甚远。这不仅和你没有指出任务类型有关，而且可能与Base模型能力不够强有关，如果出现了我们例子这种情况，大概率是预训练阶段数据集质量不高，并且过拟合了，大参数量的预训练模型这种情况会尽量少点。
2.如果是instruct模型，以现在较新的模型的能力，通常会反问你指令，这是因为它们在训练过程中被显式地灌输了“澄清不确定指令”的行为模式。比如微调数据集中有这样的数据，同时会进行人类偏好对齐训练。
其实这就是我们在提示词要素中提到的，要明确任务类型。

从上面的提示示例中可以看出，语言模型能够基于我们给出的上下文内容 "这棵树" 完成续写。

  • 对于参数量较低的Base模型，输出可能是出乎意料的，比如全是表情包，或者与你想要完成的任务相去甚远。这不仅和你没有指出任务类型有关，而且可能与Base模型能力不够强有关，如果出现了我们例子这种情况，大概率是预训练阶段数据集质量不高，并且过拟合了，大参数量的预训练模型这种情况会尽量少点。
  • 如果是instruct模型，以现在较新的模型的能力，通常会反问你指令，这是因为它们在训练过程中被显式地灌输了“澄清不确定指令”的行为模式。比如微调数据集中有这样的数据，同时会进行人类偏好对齐训练。

其实这就是我们在提示词要素中提到的，要明确任务类型。

让我们改进一下：

提示词 ：

Plain
请续写这句话：这棵树

回答 ：

Plain
# 3B-Base模型
这棵树茂盛，枝繁叶茂。它的叶子呈深绿色，形状如手掌般展开，每一片都郁郁葱葱。树冠高大挺拔，随着季节的变化，叶片颜色也会随之变换，春暖花开时为绿色，秋凉来临则变为金黄色、橙红色，美丽异常。枝干粗壮，承载着整个树木的生命，生长的节奏稳健而规律。树的根系深入地下，支撑着树的成长和稳定，同时也为周围的土壤提供了一定的营养和水分。这棵树以其生命力和美丽吸引着周围的人们，成为这片土地上的一道亮丽风景线。

# 3B-instruct模型
这棵树看起来非常古老，它的树干上布满了岁月的痕迹，枝叶繁茂，似乎在向天空诉说着不为人知的故事。

# 7B-Base模型
请提供更多信息或问题，以便我可以更好地帮助您。您想了解关于“这棵树”的哪些方面？

经过改正，模型的回答果然能符合我们的想法，续写这个句子，但是如果我们希望更多的要求，比如写一段漂亮的天空风景呢？正确的做法是在当前提示词条件下添加进一步描述：

提示词 ：

Plain
请续写这句话，重点是写一段优美的文字，描述漂亮的风景：这棵树

回答 ：

Plain
# 3B-Base模型
这棵树已经有上百年的历史了，它的枝干粗壮而坚韧，树皮上覆盖着一层厚厚的年轮，见证了无数春夏秋冬的更迭。

# 3B-instruct模型
这棵树，如同大自然精心绘制的一幅画卷，静静地伫立在翠绿的山谷之中。它的枝干遒劲有力，仿佛历史的见证者，历经岁月的洗礼而愈发坚韧不摧。树冠如一把巨大的绿色伞盖，遮蔽了阳光，为下方的小径铺上了一层柔软的绿荫。微风拂过，树叶沙沙作响，似是大自然最温柔的低语，轻抚着每一位路过的行者的脸颊。在这片静谧中，每一缕光线都显得格外珍贵，它们穿透层层叠叠的叶隙，在地面上洒下斑驳陆离的光影，宛如星辰落入凡尘，为这幅生动的山水画卷点缀上了灵动的色彩。

# 7B-Base模型
的周围是一片绿色的草坪\n和五彩斑斓的花儿，阳光从枝叶的缝隙中漏下来，像金色的雨滴洒落一地。微风轻拂，绿草如茵，花香四溢，让人仿佛置身于一个绿色的梦幻世界。远处，山峦起伏，云雾缭绕，显得格外神秘和宁静。这棵树下，几只小野兔在欢快地跳跃，它们身上的毛茸茸的耳朵轻轻颤动，仿佛在诉说着这美好的时刻。天空湛蓝，几朵白云悠闲地飘过，与这美丽的风景相得益彰。这是一个让人心旷神怡的地方，仿佛所有的烦恼和忧愁都在这片美景中烟消云散，只留下心底的宁静和安详。

续写的结果要比想象中更美好，本例中，我们了解到，即便模型本身就具备文本续写的能力，我们仍然要对提示词加更多的约束，才能让模型实现符合我们预期的文本生成任务。

而在下一个例子中，我们将进一步学习如何形成文本摘要任务。

文本摘要 ​

在上述文本生成的例子中，我们了解到，若要完成一个制定的任务，需要在提示词中加以约束，明确任务类型，本例中要完成文本摘要任务，需要做到“文本”和“提示摘要任务”同时在提示词中，比如：

提示词 ：

Plain
LLM是大型语言模型（Large Language Model）的缩写，是一个训练大量文本数据的人工智能系统。使用具有数十亿个参数的转换器架构，它学习语言模式以生成连贯的文本、回答问题、翻译等等。它通过统计模式预测下一个符号，但缺乏真正的理解，有时会产生不准确的结果。例子包括GPT和Llama，为聊天机器人和内容工具提供动力。

用一个简短的句子描述上述文本：

回答 ：

Plain
LLM是一种大型语言模型，通过学习大量文本数据来生成连贯的文本、回答问题和翻译等，但缺乏真正的理解，有时会产生不准确的结果。

在不过多关注上面输出的准确性的情况下，模型尝试将段落总结成一句话。当然，你也可以对提示词进行更加细致的修改，看看最终是否能够达到更好的效果。

信息提取 ​

因为优秀的上下文理解能力，Base模型可以轻松的从大段数据中提取重要信息，在提示词的约束下得到对应的内容。

提示词 ：

Plain
EcoFusion Pro是一款便携式搅拌机，将于2023年发布，售价89.99美元。它有一个400W的电机，500ml的容量，由不含bpa的塑料制成。它有2年的保修期，有三种颜色可供选择：蓝色、白色和绿色。该产品专为户外使用而设计，可以在10秒内混合冰。

请你从上述文本中总结EcoFusion Pro需要多少钱？

回答 ：

Plain
EcoFusion Pro的售价为89.99美元。

合成数据 ​

基于上述各种例子，数据的生成往往包含格式的约束，我们在构建数据集的时候当然更希望生成标准格式的数据，那样我们在数据清洗和整理的时候能更加轻松，大模型包含广泛的知识数据，生成数据的时候并不会偏向某一方，比如医疗、金融等特定领域任务，而且由于有良好的上下文理解能力，给够足够的指令约束，数据生成的效果会比预想中的更加准确，我们举一些例子：

提示词 ：

Plain
请按下列要求，按规定格式生成单轮问答的数据：
询问并解释什么是LLM
格式: {"input":"...","output":"..."}

答案 ：

Plain
{"input":"什么是LLM？","output":"LLM代表Large Language Model，即大型语言模型。它是一种人工智能模型，能够理解和生成人类自然语言，广泛应用于对话系统、文本生成、机器翻译等领域。这些模型通过大量语料训练来学习语言的结构和模式，并能够根据输入的信息生成连贯且符合语境的回复或内容。"}

我们看到结果是符合我们要求的，而且也从侧面看到，提示词的影响力对于结果生成的提升效果。

当然这里仅简单举例，下面我们分了单独的章节详细讲解预训练、微调、推理等合成数据如何生成。

指令问答 ​

让模型给出具体回答的最佳方法之一是改善提示的格式。如前所述，一个提示可以结合指令、上下文、输入和输出指示（output indicators）来获得更好的结果。虽然这些组成部分不是必需的，但随着你给出的指令越具体，你将获得越好的结果，这成为了一种良好的实践。下面是一个例子，展示了按照更结构化的提示词来会是什么样子的。

提示词 ：

Plain
根据下面的上下文回答问题。回答要简明扼要。如果不确定答案，回答“不确定答案”。

Question: 为什么中国古代的 “丝绸之路” 被称为东西方文明交流的重要纽带？
Answer:

回答 ：

Plain
因为“丝绸之路”促进了中国与中亚、西亚乃至欧洲之间的政治、经济和文化交往，是古代东西方文明交流的重要通道。

情感分类 ​

情感分类任务是需要大模型根据描述的句子给出对应的情感标签，这种指向性很强的目标，就需要进一步对提示词进行约束，在提示词中不仅要包含输入的句子，也要包含标签的种类，否则大模型是不知道具体如何分类的。而在进行大量的实验后，我们发现如果要输出仅输出标签，更加准确，那么可能需要举例表述才能实现。

让我们通过一个情感分类的示例来演示这一点。

提示词 ：

Plain
Classify the text into neutral, negative or positive. 
Text: I think the food was okay. 
Sentiment:

回答 ：

Plain
Neutral

The text "I think the food was okay" expresses a mild approval but does not express strong enthusiasm or dissatisfaction, hence it falls into the neutral sentiment category.

你希望回答的是neutral这样没有其他任何补充的内容，同时你希望它返回的是neutral而不是Neutral，很明显，现在模型的回答一个都不符合。那么如何实现呢？有几种不同的方法可以做到这一点。在这里，你关心的是具体性，所以你给提示词提供的信息越多，结果就越好。你可以尝试提供示例来指定正确的行为。并且对于回答的约束我们需要跟进一步，让我们再试一次：

提示词 ：

Plain
Classify the text into neutral, negative or positive. Only answer the emotional tags.
Text: I think the vacation is okay.
Sentiment: neutral 
Text: I think the food was okay. 
Sentiment:

回答 ：

Plain
neutral

这次模型返回了neutral，这是你所寻找的具体标签。看起来，提示中提供的示例帮助模型在其输出中保持了具体性，并且没有多余的分析内容了，因为你强迫模型必须只能回答标签。

不过上述例子展示了在英文当中的错误，但事实上，在中文方面，Qwen模型要做的更好一点：

提示词 ：

Plain
将文本分为中性、否定或肯定。只回答情感标签。
文本：我觉得这个假期还可以。
标签：中性
文本：这部电影一般
标签：

回答 ：

Plain
中性

这或许是因为英文的大小写并不影响含义，而中文就没有这种顾虑，总之，对于Qwen模型，中文的指令遵从效果要好于英文。

代码生成 ​

Instruct模型在代码生成方面也非常有效，得到特定条件的约束后，模型就可以根据我们的要求生成对应的代码， 我们所熟知的Copilot 就是一个很好的示例。通过巧妙的提示，你可以执行大量的代码生成任务。下面我们来看几个示例。

我们可以先实现一个简单的用户欢迎程度，用Python代码实现，在提示词中加以约束：

提示词 ：

Plain
按照下面的要求只生成python代码:
/*
打印出“hello world”
*/

输出 ：

Plain
```python
print("hello world")
```

使用Qwen模型生成的结果中包含有(```python …… ```)，事实上，这是markdown语言中代码块的表述，出现在此的原因是Qwen对于生成代码会生成结构化回答，而这个结构化刚好是markdown格式，其实并不影响实际使用，我们只需要复制粘贴其中的代码部分即可。事实上，其他的代码语言均是如此，我们看下一个例子，实现一个 SQL 查询的描述，用于从两个表中检索属于 "计算机科学系" 的所有学生信息。

提示词 ：

Plain
只使用MySQL查询来回答这个问题：
Table departments, columns = [DepartmentId, DepartmentName]
Table students, columns = [DepartmentId, StudentId, StudentName]
为计算机科学系的所有学生创建一个MySQL查询

回答 ：

Plain
```sql
SELECT students.StudentId, students.StudentName
FROM students
JOIN departments ON students.DepartmentId = departments.DepartmentId
WHERE departments.DepartmentName = 'Computer Science';
```

这非常令人印象深刻。在这种情况下，你提供了关于数据库模式的数据，并要求它生成一个有效的 MySQL 查询。

数学计算 ​

当今大模型面临的最困难任务之一是需要某种形式的推理的任务。推理是最具吸引力的领域之一，因为有了推理，就可以从LLM中涌现出各种复杂的应用类型。

目前，涉及数学能力的推理任务已经有了一些改进。 对于当前的大型语言模型来说，执行推理任务可能会有一些难度，但是在很多官方发布的Instruct模型，训练数据中都会有很多包含思考推理过程的数据，尤其是在数学推理模块，因为这通常意味着模型最终在各个领域的评测榜单里能占领高位。现在，我们将介绍几个基本示例来展示数学计算模块。

提示词 ：

Plain
9.11和9.8哪个更大？

回答 ：

Plain
为了确定9.11和9.8之间哪个数字更大，我们可以从左到右逐个比较它们：

1. 比较整数部分：
-两个数字都有9的整数部分。

2. 比较十分位：
- 9.11在十分位有一个1。
- 9.8在十分位有个8。

由于1（来自9.11）大于8（来自9.8），我们可以得出9.11大于9.8的结论。

因此，9.11大于9.8。

我们在前面的章节详细讲述思维链（CoT）的原理与使用，思维链只需要几行简单的提示，就可以大幅度提升模型的回答准确度，但是在这里，仅需要知道在没有任何提示词约束的情况下，对于数学问题，最新的模型基本都会有小部分推理过程，但是很可惜，就算模型自带了思考过程，答案也有几率回答错误，事实上，我们重新运行相同的提示词：

回答 ：

Plain
要比较9.11和9.8的大小，我们可以按照小数点后的数字来逐位比较：

- 9.11 和 9.8 都是两位小数。
- 比较整数部分：两者都是9，相同。
- 比较小数部分：
  - 9.11 的小数部分是 0.11
  - 9.8 的小数部分是 0.8

接下来比较0.11和0.8，显然0.8大于0.11。

因此，9.8 比 9.11 更大。

这次就回答正确了，这确实是一个让人比较焦虑的结果，我们当然希望每次运行都能正确。从上述例子可知，当思考的路径中产生错误的分析，那么结果错误的可能性就更大，但是如果我们在提示词的末尾添加一行让我们一步一步思考结果或许就大有不同：

提示词 ：

Plain
9.11和9.8哪个更大？让我们一步一步思考

回答 ：

Plain
要比较9.11和9.8的大小，我们可以从以下几个步骤来分析：

### 第一步：比较整数部分
首先看两个数字的整数部分：
- 9.11 的整数部分是 9
- 9.8 的整数部分也是 9

因为整数部分相同，我们需要进一步比较小数部分。

### 第二步：比较小数部分
接下来比较小数部分：
- 9.11 的小数部分是 0.11
- 9.8 的小数部分是 0.8

显然，0.11 < 0.8。

### 结论
由于小数部分0.11小于0.8，所以9.11小于9.8。

因此，9.8 比 9.11 更大。

从结果上看，不仅思考的步骤要比单纯的提问要更多，并且从整数部分到小数，都进行了细致的排查，从而形成了正确的思考链路，即使多次实验，最终结果出错的概率也大幅减少，这就是思维链的魅力所在，仅用一行提示就能改善模型性能，因为事实上一句简单的提示激活了模型的思考反思能力，这或许就是我们常说的“三思而后行”。

另外，如果我们仅希望生成结果，那么我们也只需要对提示词加以约束：

提示词 ：

Plain
只回答结果：9.11和9.8哪个更大？

回答 ：

Plain
9.8

最终结果达成，不过需要小小的提醒，生成的仍然是字符string格式哦，如果需要得到准确的数字，在实际代码中要添加转换代码，因为这通常用于评估模型在各个数据集上的评分。

聊天对话 ​

我们已经做了很多关于大模型的实验，每一步都带来我们对于提示词新的认知，事实上，你可以通过提示词工程进行更有趣的实验，比如指导大语言模型系统如何表现，指定它的行为意图和身份。 当你在构建对话系统，如客户服务聊天机器人时，这尤其有用。

下例中，你可以独立创建一个对话系统，该系统能够基于问题给出技术性和科学的回答。 你可以关注我们是如何通过指令明确地告诉模型应该如何表现。 这种应用场景有时也被称为角色提示（Role Prompting）。

但是需要注意的是，聊天往往意味着需要对话的历史记录，我们需要将历史记录添加到提示词中，不过这并不难，还记得我们在推理代码中，构建的对话信息message吗？我们只需要将历史信息根据对话模板添加到提示词中就可以做到，话不多说，我们看下例子：

对话信息 ：

Plain
system = "你是一个专业的AI助手"
user1="请记住我现在有一个数字13"
assistant1="好的，我记住了，现在有一个数字13"

user2="然后把前面提到的数乘以3，请给出结果。"

其中system是你为模型设定的角色信息，在例子中，我们简单设定为AI助手。第一轮对话分别是user1和assistant1，这是我们的历史信息，其中user1是你的问题，assistant1是AI助手的回答。第二轮对话以user2作为开始，我们需要AI助手回答assistant2的内容。这些信息通过模板保存在message中：

message ：

Plain
messages = [
    {"role": "system", "content": system},
    {"role": "user", "content": user1},
    {"role": "assistant", "content": assistant1},
    {"role": "user", "content": user2}
]

需要注意的是，无论历史对话进行了多少轮，你永远都是提问的一方，模型永远都是回答的一方，因此，我们需要确保最终是user的内容。同时历史对话并不会无限长，模型总有输入的极限，一旦超过这个极限，模型总会记得最新的回答，事实上，我们也可以称为“滑动窗口”，这是模型对记忆的保存机制。

好了，我们看下回答的效果：

对话模板 ：

Python
# 运行下面的代码，我们将知道输入到模型中的是什么样子的文本
text = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True
)
<|im_start|>system
你是一个专业的AI助手<|im_end|>
<|im_start|>user
请记住我现在有一个数字13<|im_end|>
<|im_start|>assistant
好的，我记住了，现在有一个数字13<|im_end|>
<|im_start|>user
然后把前面提到的数乘以3，请给出结果。<|im_end|>
<|im_start|>assistant

从结果上看，我们真的将历史对话给到了模型，那么模型真的能够记住历史信息回答正确吗？

回答 ：

Plain
好的，我们先将你提到的数字13乘以3。

\( 13 \times 3 = 39 \)

所以结果是39。

回答正确！到这里，你已经学会简单地和模型聊天对话了，不过我们的AI研究助手听起来有点太技术性了，对吗？好的，让我们改变这种行为，让模型变得更有人情味儿点？实际上，我们可以让模型实现一个简单的角色扮演，主要是对system的改造，话不多说，我们看下示例：

提示词 ：

Plain
system = "你是个脾气暴躁的老书店老板，暗地里心软。你经营这家店40年了，闲聊会让你生气，但你总是记得老顾客最喜欢的书。"
user1="打扰一下，你有大家都在谈论的那本新的科幻小说吗？”有蓝色封面的那本？"
assistant1="啊，最新的科幻大片。是的，我们有。在最上面的架子上，从后面数第三个。"

user2="谢谢。顺便说一句，这地方很舒适。我已经走过一百次了，但从来没有进去过。"

回答 ：

Plain
哈哈，年轻人，进来吧。坐下来翻翻书，享受你的时光。我这里的故事多的是。

看来老板是一个热情开朗的人呢～好了，我们通过为模型设定了一个角色模板，让模型互动更富有人情味儿了，我想我们应该取得了一些进展， 当然你也可以选择继续改进它，让回答更符合你的预期。

进阶数学问题 ​

更复杂的数学问题如果单靠Instruct模型可能行不通，这跟人类一样，当我们在做高考数学题的时候，尤其是压轴题，我们读完题目总需要在草稿纸上不断的推演、不断的计算，我们并不能一气呵成的给出最准确的答案，也就是需要思考，模型同样也需要思考，而这正是推理型模型的优势所在，因为推理型模型经过大规模的训练，早已具备了反思和推理能力，无需我们添加CoT，模型就会通过长文本的思考给出最正确的答案。

让我们先来看看普通的Instruct模型的回答：

提示词 ：

Plain
早上8点，一列火车从A站出发，以每小时60英里的速度向东行驶。另一列火车上午9点从A站以东300英里的B站出发，以每小时75英里的速度向西行驶。这两列火车什么时候会合？

回答 ：

点击展开完整回答内容
Plain
要解决这个问题，我们可以通过计算两列火车的相对速度来确定它们何时会相遇。

首先，我们知道两列火车的速度分别是：
- 从A站出发的火车速度：60英里/小时
- 从B站出发的火车速度：75英里/小时

由于这两列火车在同一条直线上但方向相反，它们相向而行，因此它们相遇时的相对速度等于它们各自速度之和：
\[ 60 \text{ 英里/小时} + 75 \text{ 英里/小时} = 135 \text{ 英里/小时} \]

现在我们知道两列火车之间的初始距离是300英里。我们可以用距离除以相对速度来计算两列火车相遇所需的时间：
\[ \text{时间} = \frac{\text{距离}}{\text{相对速度}} = \frac{300 \text{ 英里}}{135 \text{ 英里/小时}} \approx 2.22 \text{ 小时} \]

这意味着两列火车将在大约2.22小时后相遇。

接下来，我们需要确定具体时间。从上午8点开始算起，2.22小时大约等于2小时13分钟（因为 \(0.22 \times 60 \approx 13\) 分钟）。

因此，两列火车会在上午10点13分左右相遇。
事实上，该问题的答案应该是上午10 点 46 分 40 秒，没有思考的过程，模型给出的明显是错误的答案。那么如果是在Instruct模型基础上添加`让我们一步一步思考`这样的思维链模式呢？结果会如何？

回答 ：

点击展开完整回答内容
Plain
为了解决这个问题，我们可以使用相对速度的概念来计算两列火车相遇的时间。

首先，我们需要明确几点信息：
1. 两列火车的初始位置：火车1在A站，火车2在B站，距离A站300英里。
2. 速度：火车1的速度是每小时60英里，火车2的速度是每小时75英里。
3. 时间差：火车1比火车2早出发1小时。

由于火车1和火车2分别以相反的方向行驶，它们的相对速度就是它们速度的和，即 \(60 + 75 = 135\) 英里/小时。这意味着每小时两列火车之间会缩短135英里的距离。

接下来，我们计算两列火车需要多长时间才能相遇。由于火车2在火车1出发后1小时才开始行驶，所以火车1已经行驶了1小时（即60英里）。

火车1和火车2之间的初始距离是300英里。火车1已经行驶了60英里，因此剩余的距离为 \(300 - 60 = 240\) 英里。

现在，我们要用剩余的距离除以它们的相对速度来计算相遇所需的时间：
\[ \text{所需时间} = \frac{\text{剩余距离}}{\text{相对速度}} = \frac{240 \text{英里}}{135 \text{英里/小时}} \]

简化这个分数：
\[ \frac{240}{135} = \frac{16}{9} \approx 1.777\text{小时} \]

这意味着两列火车将在大约1小时46分钟之后相遇。由于火车1已经比火车2早出发了1小时，所以我们需要将1.777小时加到火车1的出发时间上：
\[ 8:00 + 1.777\text{小时} \approx 9:46 \]

因此，两列火车会在上午9点46分左右相遇。
看起来，添加了思维链的模型好比一位推理能力不错、却仍与满分有差距的学生；真正的差距还是来自模型本身。接下来我们用 Qwen3 系列的“推理型”模型来回答——该模型天然具备思考能力，其思考过程会包裹在 <think>...</think> 标签里。如果想显式开启思考模式，需要在推理代码里把参数 enable_thinking 设为 True。

代码 ：

Python
text = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True,
    enable_thinking=True 
)

回答 ：

点击展开完整回答内容
Plain
<think>
嗯，这个问题看起来是关于两列火车相遇时间的，我得仔细想一想怎么解决。首先，题目是说早上8点，一列火车从A站出发，向东开，速度是每小时60英里。然后另一列火车在上午9点从A站以东300英里的B站出发，向西行驶，速度是每小时75英里。问这两列火车什么时候会合。
首先，我需要明确两列火车的出发时间和位置。第一列火车是早上8点从A站出发，向东开，速度60mph。第二列火车是上午9点从B站出发，向西开，速度75mph。而B站位于A站以东300英里处，所以当第二列火车出发的时候，第一列火车已经出发了1小时，对吧？因为第二列火车是在9点出发，而第一列火车是8点出发，所以第一列火车在第二列火车出发时已经行驶了1小时，走了60英里，对吧？
……
不过，可能我哪里错了？或者有没有其他方法？
这时候，第一列火车的位置是从A站出发向东行驶了60t英里。而第二列火车是从B站出发向西行驶，B站距离A站300英里，所以第二列火车的位置是从B站出发向西行驶了75*(t - 1)英里，因此它相对于A站的位置是300 - 75*(t - 1)英里。因为向西行驶，所以是从B站往西，也就是A站的东边减少。
当两列火车相遇的时候，他们的位置应该相同，也就是：
60t = 300 - 75(t - 1)

解这个方程：

60t = 300 -75t +75

60t +75t = 300 +75

135t = 375

t = 375 / 135 = 25/9 ≈ 2.777...小时

也就是2小时46分40秒，对吗？因为0.777...小时乘以60分钟是约46.666分钟，即46分40秒。所以，从早上8点开始，经过2小时46分40秒，就是10点46分40秒左右。
</think>

两列火车的相遇时间可以通过以下步骤计算：

1. **设定变量**：设从第一列火车出发的8点开始，经过 $ t $ 小时后相遇。此时第一列火车行驶了 $ 60t $ 英里，第二列火车行驶了 $ 75(t - 1) $ 英里（因为第二列火车在9点出发，比第一列火车晚1小时）。

2. **建立方程**：两列火车相遇时，它们的位置相同。第一列火车从A站出发向东行驶，第二列火车从B站出发向西行驶，B站距离A站300英里。因此：
   $$
   60t = 300 - 75(t - 1)
   $$

3. **解方程**：
   $$
   60t = 300 - 75t + 75 \implies 135t = 375 \implies t = \frac{375}{135} = \frac{25}{9} \approx 2.777\ \text{小时}
   $$

4. **转换为具体时间**：$ \frac{25}{9} $ 小时等于2小时46分40秒（因为 $ 0.777\ \text{小时} \times 60 \approx 46.67\ \text{分钟} $）。

5. **计算相遇时间**：从8点开始经过2小时46分40秒，即 **10点46分40秒**。

**答案**：两列火车在 **10点46分40秒** 时会合。
答案完全正确，而且比我们预想的思考还要完整，因为不仅有思考模块，还包含了反思过程，模型会反思答案的正确与否，然后重新计算。

不过，和我们考试一样，这是一个非常耗时的环节，在使用Instruct模型时，因为生成的内容不算太长，可能10秒内就能回答完，但是推理型模型由于思考部分太长，往往非常耗时，所以除非是类似于上个例子中特别复杂需要推理思考的问题，一般的问题使用Instruct模型即可。

微调模型评估 ​

除了上述列举的各种任务类型，还可以通过设计提示词让大模型充当“裁判”的角色对已经微调好的模型进行打分，比如让微调后的模型回答一些问题，如果是数学问题可以直接对答案，而如果是一些文本类的回答，则可以让大模型对回答的准确性进行打分，充当“裁判”的大模型要求能力很强，这样才能在评估过程中客观评分，我们举一个简单的例子： 提示词 ：

Plain
你是一位严格的评分老师。下面是一段「待评回答」。请只看它的事实准确性，忽略格式和语气。  
评分标准：  
0 分 = 完全不符合事实
1 分 = 有明显事实错误  
2 分 = 有小错误，整体仍对  
3 分 = 完全正确  

只要回复一个数字（0/1/2/3）和一句理由，不要多余内容。

### 待评估问题：
巴黎现在有多少的人口？

### 待评回答：
根据2022年最新的统计数据，巴黎的总人口约为216万。

回答 ：

Plain
3

当然我们也可以让大模型判断回答结果和正确结果之间的相似程度作为评分标准：

提示词 ：

Plain
你是评分员。请把下面的“标准答案”和“模型回答”对比，按 1–5 打分：  
5 分 = 含义完全一致  
4 分 = 基本一致，细节微差  
3 分 = 部分匹配  
2 分 = 少量相关  
1 分 = 完全不符  

只回复一个数字（1-5）和一句理由，不要多余内容。

### 问题：
光合作用需要什么？

### 标准答案：
阳光  

### 模型回答：
光合作用是植物、藻类和某些细菌利用阳光将二氧化碳和水转化为氧气和葡萄糖的过程。在这个过程中，光合作用需要以下条件和成分：

1. **光**：这是光合作用的直接能量来源。
2. **二氧化碳（CO₂）**：从大气中吸收的二氧化碳用于合成有机物。
3. **水（H₂O）**：通过叶绿体中的叶绿体膜上的水裂解过程产生氢离子和氧气。
4. **叶绿素和其他色素**：叶绿素是主要的色素，能够吸收太阳光并将其转化为

回答 ：

Plain
1

理由：模型回答虽然提到了光作为光合作用的条件之一，但并未明确指出光就是唯一的条件，并且详细说明了其他必要的物质和叶绿素的作用，而标准答案仅提及阳光这一单一条件。

从上面的例子可以看出，当大模型充当“裁判”后就可以替代人工做出合理的打分，这样的评估可以通过批量运行脚本，从而提高评估的效率。