一文看懂大模型核心参数调优用法与实战
前言
目前大部分集成大模型开发用作后端响应,基本上生产环境用的都是OpenAI Python 的SDK,我也推荐大家用OpenAI Python 的SDK,统一、规范易于理解。OpenAI的SDK是现在大模型生态建设的相对完善而且比较全面的,开发者能够更方便地与模型交互。而且目前市面上的模型基本都兼容OpenAI的SDK,能容易集成其他大模型的API打造多模态大模型并用ASWL,因此本文将主要探讨OpenAI SDK的一些常用参数在创建大模型对话是可以使用哪些参数来强化优化回答效果。
我是Fanstuck,致力于将复杂的技术知识以易懂的方式传递给读者,每一篇文章都凝聚着我对技术的深刻洞察。从人工智能的基础理论到前沿研究成果,从热门框架的深度解析到实战项目的详细拆解,内容丰富多样。无论是初学者想要入门,还是资深开发者追求进阶,都能在这里找到契合自身需求的知识养分。如果你对大模型的创新应用、AI技术发展以及实际落地实践感兴趣,那么请关注Fanstuck。
一、参数调优的重要性
如果把调用大模型比作烹饪,那么参数调优就是掌控火候的关键——火候太小,菜肴寡淡无味;火候太大,食材可能烧焦。同样地,在使用OpenAI API时,参数的细微调整会直接影响生成内容的精准性、创造性和实用性。无论是让AI生成一段严谨的法律条文,还是创作一首天马行空的诗歌,参数的设定都决定了输出结果的“风味”。
- 为了更直观地理解参数调优的重要性,我们来看几个实际案例:
案例一:智能客服中的参数调优
在智能客服场景中,用户通常希望获得准确、简洁的回答。此时,可以设置较低的
temperature
(如 0.2)和top_p
(如 0.5),以减少生成内容的随机性和多样性,确保回答的准确性和一致性。 此外,可以设置适当的max_tokens
(如 100),限制回答的长度,避免冗长的回复。 案例二:内容创作中的参数调优 在内容创作场景中,如生成广告文案或社交媒体内容,通常需要富有创意和多样性的输出。此时,可以设置较高的temperature
(如 0.8)和top_p
(如 0.9),以增加生成内容的随机性和多样性,激发模型的创造力。 同时,可以适当调整frequency_penalty
和presence_penalty
,鼓励模型使用更多新颖的表达方式,避免重复使用相同的词汇和句式。 案例三:数据分析中的参数调优 在数据分析场景中,如从大量文本中提取关键信息并生成报告,通常需要结构化和准确的输出。此时,可以设置较低的temperature
(如 0.3)和top_p
(如 0.6),以减少生成内容的随机性,确保输出的准确性和一致性。 此外,可以设置适当的max_tokens
(如 200),限制输出的长度,确保报告的简洁性和可读性。
通过调整参数,如 temperature
、top_p
、frequency_penalty
等,可以控制生成内容的随机性、创造性和重复性,从而满足不同场景的需求。如果参数不当,则会极大影响模型输出质量:
1.过度发散的回答
当temperature=1.2
(过高)时,询问“如何做番茄炒蛋”,AI可能回答:
“首先,你需要一颗来自火星的番茄,在零重力环境下打散鸡蛋…” ——显然脱离了实际需求。
2.过度保守的回答 当temperature=0
(完全确定性模式)时,要求“写一首爱情诗”:
“两个人相遇,产生感情,最终结婚。” ——虽然符合逻辑,但毫无诗意。
3.意外中断的输出 若未合理设置max_tokens
(最大生成长度),生成长文时可能突然截断:
“综上所述,量子计算机的核心优势在于…(输出结束)” ——关键结论丢失,用户体验受损。
为什么开发者必须掌握参数调优?
- 成本控制:
max_tokens
直接关联API调用成本,冗余生成意味着浪费预算。 - 用户体验:客服场景中一个错误的发散回答可能导致用户流失。
- 业务适配:创意类场景需要“放飞”模型,而法律场景必须“收紧”模型。
接下来,我们将从基础调用代码出发,逐步拆解每个核心参数的作用机制,并通过真实案例演示如何像调节“旋钮”一样,精准操控AI的输出效果。
二、基础准备:OpenAI Python SDK 简介与安装
在深入探讨大模型参数调优之前,首先需要确保开发环境已正确配置。OpenAI 提供的官方 Python SDK 是与其 API 交互的首选工具,支持多种模型调用,包括文本生成、图像生成、语音识别等。
1. 安装 OpenAI Python SDK
确保已安装 Python 3.7 或更高版本。然后,在命令行中执行以下命令安装 OpenAI SDK:
代码语言:javascript代码运行次数:0运行复制pip install openai
如果下载有问题或者很吗就换清华源:
代码语言:javascript代码运行次数:0运行复制 pip install openai -i
安装完成后,可以通过以下方式验证安装是否成功:
代码语言:javascript代码运行次数:0运行复制import openai
print(openai.__version__)
如果输出版本号,则表示安装成功。
2. 初始化 SDK:配置 API Key、Base URL 和代理
要使用 OpenAI 的服务,需进行以下配置:
2.1 设置 API Key
为安全起见,建议将 API Key 存储在环境变量中,或者存储一个env文件,在程序里面读取:
代码语言:javascript代码运行次数:0运行复制from dotenv import load_dotenv
# 加载 .env 文件
load_dotenv("you_api.env")
api_key = os.getenv("API_KEY")
app_id = os.getenv("APP_ID")
2.2 配置 Base URL
如果使用代理服务或自定义接口,需设置 Base URL:
代码语言:javascript代码运行次数:0运行复制openai.api_base = ";
2.3 设置代理(可选)
在某些网络环境下,可能需要配置代理:
代码语言:javascript代码运行次数:0运行复制import os
os.environ["http_proxy"] = "http://127.0.0.1:8888"
os.environ["https_proxy"] = "http://127.0.0.1:8888"
或者使用 httpx
配置代理客户端:
import httpx
from openai import OpenAI
client = OpenAI(
api_key="your-api-key",
base_url=";,
http_client=httpx.Client(proxies="http://127.0.0.1:8888")
)
3.示例代码:使用 openai.ChatCompletion.create()
以下是一个使用 openai.ChatCompletion.create()
方法进行对话生成的示例:
import openai
openai.api_key = "your-api-key"
response = openai.ChatCompletion.create(
model="qwen-max-latest",
messages=[
{"role": "system", "content": "你是一个乐于助人的助手。"},
{"role": "user", "content": "请告诉我今天的天气。"}
],
temperature=0.7,
max_tokens=100
)
print(response.choices[0].message["content"])
在上述代码中:
model
指定使用的模型,如 qwen-max-latest`。messages
是对话的上下文,包括系统、用户和助手的消息。temperature
控制生成内容的随机性,值越高,生成的内容越多样化。max_tokens
限制生成内容的最大长度。
通过上述配置,开发者可以快速集成大模型能力,为应用程序添加智能对话功能。
三、核心接口与参数详解
在本篇文章中,我们将深入解析 OpenAI 官方提供的 Python SDK 的五大核心接口——ChatCompletion(多轮对话)、Completion(单轮文本补全)、Embedding(文本向量化)、Audio(语音识别与翻译)和 Image(图像生成与编辑)。我们将介绍每个接口的用途、主要参数(默认值及建议范围)、参数如何影响模型输出效果与使用成本,并提供对应的 Python 示例代码。此外,每节还结合实际业务场景举例,帮助理解参数设置的效果,并在最后给出实战建议。
文章内容力求通俗易懂且具有专业性,会适当穿插生活或业务类比,从开发者视角给出一些提示和经验。希望这份详解能帮助技术同仁更高效地使用 OpenAI SDK。
completions接口详解(多轮对话)
接口用途与场景: ChatCompletion 接口用于生成“多轮对话”的 AI 回复,是构建聊天机器人、智能助理等对话系统的核心。与传统的 Completion 接口不同,ChatCompletion 接口支持消息列表(包含角色和内容),能够保持对话上下文,多轮交互时模型可以“记住”之前的对话内容。例如,我们可以用它实现类似 ChatGPT 的聊天,或者让模型扮演某个角色进行问答。开发者可以通过设定系统消息来规定 AI 的行为,通过多轮 user/assistant 消息实现上下文相关的对话。在 SDK v1.5.0 中,通过 client.chatpletions.create()
方法调用该接口。
主要参数: 调用 openai.ChatCompletion.create()
时,常用的主要参数包括:
- model(模型): 使用的模型名称。例如常用的对话模型有
"gpt-3.5-turbo"
或"gpt-4"
等。GPT-4 通常在处理复杂任务上效果更好,但成本更高,而 GPT-3.5-Turbo 速度快、价格低。 - messages(消息列表): 多轮对话消息组成的数组。每个消息是一个字典,包含
role
(角色)和content
(内容)。典型角色有: "system"
:系统角色消息,可用于设定对话的背景或规则,比如指示 AI 扮演某种身份。"user"
:用户消息,即用户提出的问题或输入。"assistant"
:助手(AI)消息,即此前模型产生的回答。 开始对话时通常提供一个 system 指令和用户提问,模型会根据这些生成 assistant 回复。随着对话进行,messages 列表会不断加入新的 user 和 assistant 消息,以维持上下文。- max_tokens(最大生成长度): 控制模型输出的最长 Token 数。默认情况下,如果不设置,模型会尽可能长地生成直到达到模型上下文上限或遇到停止信号。设置此参数可以防止输出过长(从而控制成本),但若设得过小可能导致回答不完整。一般根据需求设置几十到上千不等。例如希望简短回答可设定如
max_tokens=100
。 - temperature(温度): 控制生成文本的随机性,取值范围 0~2,默认值为 1。温度越高,回复越随机、富有创造力;温度越低,回复越稳健严谨、更加确定。比如
temperature=0
时,每次回答几乎相同,适合问答、代码等需要确定性的场景;temperature=0.7
时,回复会更丰富多样,适合创意写作等需要一定随机性的场景。 - top_p(概率截断): 又称 核采样,取值 0~1,默认值为 1。它控制模型考虑预测下一个词时累积概率的范围。当
top_p<1
时,模型仅从概率前top_p
部分的词中采样,例如top_p=0.1
意味着只考虑前10%概率质量的词。通常和 temperature 二选一调整,不需要同时修改这两个参数。在需要输出更符合常理语句时,可降低 top_p 来减少罕见词输出的可能性。 - n(返回结果数量): 一次请求生成多少个回复,默认 1。如果设置
n>1
,接口会返回多个备选回复。适用于希望从多种应答中进行选择的场景,比如生成多种文案创意。但要注意n
值越大,消耗的 Token 和费用近似线性增加(相当于做了多次生成)。 - stream(流式输出): 是否启用流式输出,默认
False
。若设为True
,API 将逐步返回部分消息(类似打字机效果),适合实时应用。例如在聊天界面一点点显示回答。流模式下需在代码中迭代读取流响应。需要注意的是,开启流式并不改变最终内容或费用,但可以降低延迟、提升用户体验。 - stop(停止标志): 可以是字符串或字符串列表,表示生成过程中遇到该标志时就停止输出,不再继续生成。例如设置
stop=["\n\nHuman:"]
可以在对话模型开始生成下一个 Human/user 提示时强制停止。合理使用 stop 有助于避免模型跑题或输出多余内容。默认情况下没有强制停止标志,模型会根据自身学习到的停止符(如系统消息或 max_tokens 耗尽)来结束。 - presence_penalty(话题新颖度惩罚): 数值范围 -2.0~2.0,默认 0。。正值会惩罚模型重复提及对话中已出现过的主题,提高引入新话题的倾向。换句话说,值越高,模型越倾向于不重复自己,鼓励拓展到新内容;负值则反之,会提高模型重复提及已有内容的概率。
- frequency_penalty(频率惩罚): 数值范围 -2.0~2.0,默认 0。正值会惩罚模型重复输出相同字词的频率。值越高,输出越不容易重复用词,以避免内容重复啰嗦;负值则可能使模型更倾向重复字词。比如在总结场景下可设置略高的频率惩罚以避免模型重复句子。在押韵诗歌等场景或需重复关键词时则可使用负值降低惩罚。
- functions(列表,可选):函数调用功能的描述列表。每个函数由 name、description、parameters 等定义,用于引导模型以函数格式输出。这是 ChatCompletion 新增的高级特性,可让模型按照指定函数的参数格式返回结构化数据。当提供此参数时,模型可能选择返回一个函数调用结果而非自然语言。
- function_call(字符串或字典,可选):指定函数调用方式。默认为
"auto"
让模型自行决定是否调用函数;可设为"none"
强制禁止函数调用;或指定为某个函数名强制模型调用该函数。配合 functions 参数使用,用于更精细地控制模型输出格式(比如强制模型给出JSON调用某函数的参数)。 - user(字符串,可选):用于标识终端用户的唯一标识符。这个信息不会影响生成内容,但会在日志中记录,OpenAI 用它来监控滥用。对于多用户的应用,传递 user 参数有助于将请求与用户对应,以满足审计或安全需求。
参数对内容和成本的影响: ChatCompletion 接口的输出很大程度上由 prompt消息内容 和 模型 决定,但上述参数提供了重要的调优手段:
- 创意与一致性:
temperature
和top_p
直接决定回复的随机性。较低的 temperature(接近0)让模型每次都选取最可能的词,输出偏确定和可预测,这适合事实问答或代码生成等需要稳定结果的任务;较高的 temperature/top_p 允许模型探索不太可能的词,增加回复的多样性,用于创意写作、对话聊天等场景会更生动。但是温度过高(如 >1.5)可能导致胡言乱语或跑题,需要谨慎调整。 - 输出长度:
max_tokens
决定回复长度上限。如果希望简洁回答,可设一个较小的 max_tokens;生成长文则应提高该值。但无论何种情况,max_tokens 越大潜在成本越高,因为模型可能输出更多内容。同时由于每个 token 都按单价计费(输入和输出均计费),限制 max_tokens 也是控制花费的方法之一。对于聊天模型,例如 GPT-3.5,每千 tokens 定价几美分左右,所以生成100 tokens和1000 tokens在成本上相差一数量级。 - 重复与话题控制:
presence_penalty
和frequency_penalty
提供对内容重复度和话题广度的控制。举例来说,在一个产品描述生成任务中,如果模型倾向重复某些词,可以增加 frequency_penalty,使其换用不同表达。而在头脑风暴应用里,提高 presence_penalty 可以促使模型不断引入新创意而不是反复纠结旧点子。反过来,如果希望模型紧扣用户给定的话题,可以设置适度的负值以鼓励模型重复提及相关主题词。不过一般大多数应用保持默认0即可,除非有明确需要。 - 多回复与成本: 使用
n>1
可以一次性得到多种不同风格或角度的回答,例如在客服聊天中生成多个答复备选。但需要注意每个候选实际上是独立调用模型生成,费用也近似按倍数增加。例如生成3个回复的费用约是单回复的3倍(因为输出 token 数增加)。因此除非有挑选最佳回答的需求,否则不建议轻易将 n 调太高。 - 函数输出: 提供
functions
参数会影响模型输出——模型可能返回一个函数调用而非直接回答。这对工具使用场景很有用,例如要求模型返回结构化数据给程序处理。如果不想模型走函数调用分支,应避免提供 functions 或将 function_call 设为 "none"。 - 流式输出:
stream=True
虽然不改变最终内容,但对交互体验影响显著。在需要实时显示的应用(如聊天机器人打字效果)中使用流式能降低延迟,提高用户感知速度。不过实现上要处理好分片消息的组装。另外,开启 stream 并不会减少费用,因为总Token用量不变,但由于可边生成边发送,在长内容时可以节省一点总体请求时间。
调用示例(Python): 下面我们以 qwen-long 模型为例,演示 ChatCompletion 接口的基本用法。
代码语言:javascript代码运行次数:0运行复制# 准备对话消息
messages = [
{"role": "system", "content": "你是一位乐于助人的数学讲师,用通俗易懂的语言回答问题。"},
{"role": "user", "content": "请解释一下 Monty Hall 问题 的意义。"}
]
# 不同参数设置下调用 ChatCompletion 接口
response_default = client.chatpletions.create(
model="qwen-max-latest",
messages=messages
)
print("默认参数回复:\n", response_default.choices[0].message.content)
response_creative = client.chatpletions.create(
model="qwen-max-latest",
messages=messages,
temperature=1.2, # 提高随机性
n=2, # 获取2个不同风格的回答
max_tokens=150 # 扩大量以获得详细解释
)
for i, choice in enumerate(response_creative.choices):
print(f"\n回复 {i+1}:\n{choice.message.content}")
运行上述代码,模型会生成一个对于 ChatCompletion 接口的解释性回答。
在上述代码中,response_default
使用默认参数,会得到模型较为中规中矩的解释。而 response_creative
则提高了温度并让模型输出两个版本,可能一个解释更风趣类比,另一个更严谨数学。需要强调的是,n=2
虽然让我们一次获得两个答案,但其消耗的 Token 也是双倍的(输入部分共享但输出两份)。实际应用时,可以根据需求权衡这种一次多回复的策略。
应用场景与参数调优: 在聊天机器人或对话系统中,合适地调整这些参数能够显著改善用户体验。例如,当构建一个代码助理时,为了保证代码输出的确定性和正确性,常将 temperature
设为 0,使模型每次都产生几乎相同的结果,减少随机 bug。同时可能设置较高的 max_tokens 以便生成较长的代码段,并利用 stop
参数让模型在输出完函数定义后停止,避免啰嗦解释。
又如,在创意写作场景(故事生成、诗歌创作),可以将 temperature
提高到 1.0 以上甚至 1.5,并将 presence_penalty
适当提高以鼓励引入新主题、新意象,从而获得更有想象力的输出。然而要注意此时可能需要对结果进行人工筛选,因为高随机性下质量波动也会增大,必要时可以请求多次或增加 n
来获取多个候选文本。
Completion 接口(文本补全)
基本用途: Completion 接口提供传统的文本补全能力,通常用于非对话场景:给定一个提示文本(prompt),模型继续生成后续内容。这是 OpenAI 最早期的文本生成 API,在 GPT-3 模型(如 Davinci、Curie 等)时代被广泛使用。尽管如今对话模型更流行,但 Completion 对于单次提示-完成的任务仍然适用,如文章续写、代码自动完成等。SDK v1.5.0 中通过 clientpletions.create()
方法调用该接口。
clientpletions.create(...),只能用于调用官方 OpenAI 平台的 Completion 接口。如果是阿里云通义千问(Qwen)系列模型用的是百炼的API,阿里云 DashScope 提供的 OpenAI 兼容接口(通常是 ),也就是说,通义目前仅支持
chat/completions
接口(即对话模式),不支持传统的 completions
(prompt-only)接口,所以不能写 clientpletions.create(...)
。
除了以上参数外,Completion还有三个独特的参数:
- logprobs(整数或 None,可选):如果设置一个正整数 n,模型将返回每个生成的 token 的前 n 个候选词及其概率对数值(对数概率)。例如设置
logprobs=5
,则对每个输出token,提供当时概率最高的5个token及其log概率。这对于分析模型输出、调试提示或在应用中基于置信度做处理很有帮助。默认值为 None(不返回概率信息)。注意:使用 logprobs 不会改变生成的内容,但响应中包含更多数据。n 最大不宜过大,一般5足够,否则响应体积会变大。logprobs 会额外占用一定计算,但相比生成文本本身开销不算太高。 - echo(布尔值,可选):是否在输出中包含提示文本本身。默认 False。如果设为 True,模型的完整输出将前面附带原始 prompt,然后接着生成的completion。这在某些场景下(例如想要得到“prompt+完成”的整体文本)有用。一般大多数应用下我们只需要生成部分,不需要 echo。
- best_of(整数,可选):一次生成的候选数用于选优,默认 1。当
best_of > 1
时,服务器会生成 best_of 份补全,但只返回其中得分最高的一个v1-14.docs.dapr.io。这与n
不同:n 会返回所有n个结果,而 best_of 会进行内部比拼后只给一个结果。注意 best_of 会显著增加 token 使用量,因为模型实际生成了 best_of 个完成,只是扔掉了其余的。只有在需要追求更高质量且愿意多花费用时才考虑使用。例如 best_of=5 能提高拿到一个高质量输出的概率,但费用约是5倍且只返回1个结果。不能将 best_of 和 stream 或 n 结合使用(若 n < best_of 则返回 n 个中最好的 n 个)。
Completion 接口的参数调优和 ChatCompletion 类似,但考虑到非对话、可能篇幅更长的特点,有一些侧重点:
- 长度控制与成本:
max_tokens
是必须关注的参数。默认16往往不足以完成任务,因此绝大多数情况下需要根据期望输出长度设置较大的值。但切忌一味设置过高,比如 prompt 只需要模型补全一句话摘要,却给了500的max_tokens,这不仅可能产生多余内容,还平白增加费用。经验上可以估算一下期望输出大概多少字,然后乘以2左右作为 token 数上限预留余量。对费用敏感的应用,可以在生成完毕后记录实际用量来优化 max_tokens 设定。 - 创造性输出: 对于如小说续写、营销文案生成等需要创造力的任务,提高
temperature
(如0.8-1.2)或降低top_p
(如0.9)能让模型提供意想不到的转折或措辞。但为了保证主旨连贯,可以辅以较高的 presence_penalty,避免模型一直停留在已有情节上不前进。相反,对于要事实准确的任务(如补全维基百科式陈述),应将 temperature 降为0,让模型选取概率最高的词序列,从而得到确定性输出,不过在这种情况下也要小心模型可能直接引用训练中的句子。 - 多样性 vs. 一致性: 如果对输出质量要求很高且可以承担成本,使用
best_of
是一种策略。比如生成产品描述时,希望每次都拿到最优表述,可以设best_of=3
或 5,让模型想出多个版本并返回概率最高的那个。因为语言模型的 logprob 通常和输出连贯性相关,best_of 可以过滤掉一些不良续写。但这需要注意,当 prompt 自身不确定时(如要求模型自由发挥),logprob最高的不一定就是“质量最好”,因此 best_of 策略对特定任务有效,对另一些可能未必值得。 - 调试与分析: 开发者在调试 prompt 时,可利用
logprobs
返回模型每一步的决策信息。例如看到模型为什么突然结束输出,可以查看是否遇到某 token 的概率骤降或 stop符号。另外 logprobs 也可用于实现自定义后处理:比如拿到备选词后,人工或程序进行筛选,再拼接成最终输出。不过这比较高级,一般用于研究。 - Echo用例: 在构建交互式应用时,有时 echo=True 可以简化处理——模型输出的文本开头就是用户提示,后面跟答案,这样客户端直接展示即可,无需再拼接提示。但这也意味着要传输更多数据。大多数批量或后端任务无需 echo,因为我们已经有 prompt 在本地。
下面通过代码演示 Completion 接口的用法和参数调节效果。我们将构造两个例子:一个让模型续写诗歌,另一个让模型补全代码。通过调整 temperature 来对比输出差异:
代码语言:javascript代码运行次数:0运行复制# 示例1:中文诗歌续写
prompt_poem = "人工智能像一束光,"
completion_poem = clientpletions.create(
model="text-davinci-003",
prompt=prompt_poem,
max_tokens=64,
temperature=1.0,
top_p=1.0,
n=1,
stop="。", # 使用句号作为停止符,输出完整一句后停止
presence_penalty=0.5,
frequency_penalty=0.5
)
print("诗歌续写结果:", completion_poem.choices[0].text)
# 示例2:代码补全
prompt_code = "def is_prime(n):\n # 判断一个整数是否为质数\n"
completion_code = clientpletions.create(
model="code-davinci-002",
prompt=prompt_code,
max_tokens=64,
temperature=0.2, # 低温度,保证代码确定性
stop=["\n\n"] # 遇到空行就停止,避免生成多余注释
)
print("代码补全结果:\n", completion_code.choices[0].text)
结语:调参数,其实是一种对模型的“对话艺术”
在大模型的世界里,参数调优不仅仅是技术微调,更像是与模型进行一场默契的对话。你给它温度,它回应你创意;你设定停止词,它懂得适可而止;你调高惩罚因子,它便收起啰嗦、言简意赅。每一个参数都是调节“风格”“稳定性”“长度”“成本”的旋钮,合理配置就像调音师手中的推子,最终奏出你理想中的“AI交响乐”。
本文基于 OpenAI SDK v1.5.0,从 ChatCompletion
到 Completion
,从 Embedding
到 Audio
与 Image
接口,逐一讲解了常见调用方式与关键参数的用法,并结合实际业务场景和典型案例,帮助你建立系统性的参数理解框架。你不仅能写出能用的调用代码,更能理解“为什么这样调”与“调完之后会怎样”。
在实际项目中,无论你是在开发客服助手、文案生成系统、知识库搜索引擎,还是构建多模态 Agent,理解并掌握这些参数的调优技巧,是将大模型从“能跑”到“好用”的关键一步。
最后,记住一点:模型是死的,Prompt和参数才是活的。与其一味吐槽“模型答错了”,不如从“调Prompt、调参数”开始,换个方式与它对话,也许你就能听懂它真正的声音。
发布者:admin,转转请注明出处:http://www.yc00.com/web/1747531505a4648128.html
评论列表(0条)