【辉光】【评估实践篇】你的AI模型“变笨”了吗?教你用GPT-4给它当“考官
介绍并实践LLMOps的第二大支柱——评估(Evaluation)。聚焦于“为什么”和“怎么做”,并提供可运行的代码示例。
《你的AI模型“变笨”了吗?教你用GPT-4给它当“考官”》
在前两篇文章中,我们先是感受了AI的“不确定性”,然后亲手给它装上了“安全带”(护栏)。我们的AI应用现在安全多了,不会在公开场合“酒后驾车”了。
但一个新的问题浮出水面:
你花了一周时间,精心优化了你的Prompt,让AI客服的回答更简洁、更热情。你满怀信心地发布了新版。
一周后,用户反馈说:“机器人是热情了,但好像有点傻,总答不到点子上。”你优化了A指标(热情度),却在不经意间损害了B指标(有用性)。
你怎么量化这种“感觉”?你怎么知道一次小小的改动,是让模型整体变好了,还是变坏了?
在传统的软件工程里,我们有单元测试、集成测试。每次代码提交,测试用例都会跑一遍,用红灯绿灯告诉我们系统是否正常。
在LLMOps里,我们就需要一套类似的体系来保证AI的“行为质量”。这就是评估 (Evaluation)。
为什么不能只看“护栏”有没有触发?
护栏是底线,它防止AI做坏事。但一个不说脏话的AI,不等于一个好AI。它可能礼貌地胡说八道,或者给出毫无帮助的“正确废话”。
我们需要一个方法,来衡量AI输出的“好坏程度”。但“好”是一个很主观的词。对于AI生成的内容,什么是“好”?
- 有帮助性 (Helpfulness): 它解决用户的实际问题了吗?
- 事实性 (Factuality): 它说的内容符合事实吗?
- 简洁性 (Conciseness): 它是不是啰嗦了一大堆?
- 品牌调性 (Tone): 它的语气符合我们的品牌形象吗?
手动去检查成千上万条回答显然不现实。所以,我们要请出终极武器——用一个更强大的AI,来给我们的AI当“考官”。
用AI评估AI:建立你的“黄金测试集”
这个过程的核心思路分为两步:
- 建立“黄金评估集 (Golden Set)”: 这不是训练数据!这是一份你精心设计的“考卷”,包含几十到几百个有代表性的、棘手的用户问题。这份考卷是衡量所有模型好坏的唯一标准。
- AI考官 (AI-based Evaluator): 我们用一个强大的模型(比如GPT-4),告诉它评分标准(比如“请从1-5分,为这个回答的‘简洁性’打分”),然后让它自动批改我们工作模型的“答卷”。
今天,我们就用Python和openai库,从零开始实现一个最简单的AI评估流程。
我们的目标:
创建一个AI“考官”,自动评估我们上一篇文章中那个“广告文案生成器”的输出质量,主要评估其**“创意性”**。
【动手时间】打造你的AI质检流水线
第一步:准备你的“考卷”和“答卷”
我们不需要复杂的库。首先,定义我们的“黄金评估集”(考卷)和待评估的AI生成内容(答卷)。
# 1. 我们的“黄金评估集”(考卷) - 包含各种需要生成广告语的产品
golden_eval_set = [
"一款能自动加热的智能咖啡杯",
"一款适合程序员的超静音机械键盘",
"一款给宠物猫设计的翻译项圈"
]
# 2. 假设这是我们某个版本的模型,针对考卷生成的三份“答卷”
# (在真实世界里,这部分是由你的被测模型API生成的)
model_answers = [
"告别冷咖啡,每一口都是温暖的拥抱。", # 针对咖啡杯
"代码在指尖流淌,世界只剩安静的思考。", # 针对键盘
"它喵的,终于知道主子在想什么了!" # 针对猫项圈
]
第二步:定义你的“考官”和“评分标准”
这是最关键的一步。我们要编写一个函数,它会调用一个强大的AI(如GPT-4)来执行评估任务。
import os
import openai
# 同样,确保你的OPENAI_API_KEY已设置
# os.environ["OPENAI_API_KEY"] = "sk-YourKeyHere"
client = openai.OpenAI()
def get_creativity_score(question: str, answer: str, evaluator_llm: str = "gpt-4-turbo"):
"""
使用一个强大的AI作为“考官”,为另一个AI的回答的“创意性”打分。
返回一个包含分数和理由的字典。
"""
system_prompt = """
你是一个严格、公正的创意评估专家。
你的任务是评估一个AI生成的广告文案的“创意性”。
请根据以下标准,给出1到5分的评分:
1分:毫无创意,非常普通。
2分:略有新意,但仍显平庸。
3分:中规中矩,符合基本要求。
4分:很有创意,能吸引眼球。
5分:惊为天人,极具原创性和启发性。
你必须只返回一个JSON对象,格式如下:
{"score": <你的评分>, "reason": "<你的评分理由,简短说明>"}
"""
user_prompt = f"""
请评估以下广告文案的创意性。
---
产品描述: {question}
---
AI生成的广告文案: {answer}
---
"""
try:
response = client.chat.completions.create(
model=evaluator_llm,
messages=[
{"role": "system", "content": system_prompt},
{"role": "user", "content": user_prompt}
],
response_format={"type": "json_object"}, # 强制要求返回JSON
temperature=0.0 # 评估时,我们需要稳定的结果
)
return response.choices[0].message.content
except Exception as e:
return f'{{"score": 0, "reason": "评估时出错: {e}"}}'
代码解析:
- 我们给了“考官”(GPT-4)一个非常明确的角色(
system_prompt)和评分标准。 - 我们使用了GPT-4的JSON Mode,来确保它返回的格式是规范的,方便我们程序解析。
- 我们将
temperature设为0.0,因为在评估时,我们追求的是一致性和确定性,而不是创造性。
第三步:执行评估并查看“成绩单”
现在,我们把考卷和答卷交给考官,让它开始“批改作业”。
import json
total_score = 0
evaluation_results = []
print("--- AI质量评估流水线启动 ---")
for i, question in enumerate(golden_eval_set):
answer = model_answers[i]
print(f"\n正在评估第 {i+1} 条回答...")
print(f" - 产品: {question}")
print(f" - 文案: {answer}")
# 调用考官进行评估
evaluation_str = get_creativity_score(question, answer)
try:
evaluation = json.loads(evaluation_str)
score = evaluation.get("score", 0)
reason = evaluation.get("reason", "无理由")
print(f" - 考官评分: {score}/5")
print(f" - 评分理由: {reason}")
total_score += score
evaluation_results.append(evaluation)
except json.JSONDecodeError:
print(f" - 评估失败: 无法解析返回的JSON: {evaluation_str}")
print("\n--- 评估报告 ---")
average_score = total_score / len(golden_eval_set) if golden_eval_set else 0
print(f"本次模型版本的平均创意分: {average_score:.2f} / 5.0")
# 想象一下,在CI/CD流水线里,你可以这样做:
if average_score < 3.5:
print("\n[!] 警告:模型平均分低于基线(3.5),部署已自动中止!")
else:
print("\n[✓] 成功:模型平均分达标,可以安全部署!")
运行代码,你可能会看到这样的“成绩单”:
--- AI质量评估流水线启动 ---
正在评估第 1 条回答...
- 产品: 一款能自动加热的智能咖啡杯
- 文案: 告别冷咖啡,每一口都是温暖的拥抱。
- 考官评分: 3/5
- 评分理由: 表达清晰,但创意略显不足,是比较常见的描述方式。
正在评估第 2 条回答...
- 产品: 一款适合程序员的超静音机械键盘
- 文案: 代码在指尖流淌,世界只剩安静的思考。
- 考官评分: 4/5
- 评分理由: 意境营造得很好,准确抓住了目标用户的核心痛点和追求。
正在评估第 3 条回答...
- 产品: 一款给宠物猫设计的翻译项圈
- 文案: 它喵的,终于知道主子在想什么了!
- 考官评分: 5/5
- 评分理由: 极具创意和幽默感,巧妙地使用了网络梗,能立刻抓住用户的兴趣。
--- 评估报告 ---
本次模型版本的平均创意分: 4.00 / 5.0
[✓] 成功:模型平均分达标,可以安全部署!
现在,你拥有了一个可以量化的、自动化的“行为质量晴雨表”。每次修改Prompt或更换模型后,跑一遍这个评估流水线,你就能得到一个客观的分数,以此决定是否上线新版本。
结论:从“手工作坊”到“现代化工厂”
这个三部曲带我们走过了一段从混沌到有序的旅程:
- 第一篇:我们认识到了AI的“不确定性”,理解了为什么需要新的运维哲学(LLMOps)。
- 第二篇:我们学会了用“护栏”,为AI的行为设定了不可逾越的底线,保证了安全性。
- 第三篇:我们掌握了用“评估”,为AI的行为质量建立了一套可度量的标准,保证了可靠性。
当你把“护栏”和“评估”结合,并将它们深度集成到你的开发(CI/CD)流程中时,你就真正从一个管理“AI宠物”的家长,进化成了一位设计“AI系统”的行为建筑师。
你的AI应用,也终于从一个充满不确定性的“手工作坊”,变成了一个质量可控、可迭代、可信赖的“现代化工厂”。这,就是LLMOps的真正力量。
如果你觉得这个系列对你有启发,别忘了点赞、收藏、关注,我们下篇见!
火山引擎开发者社区是火山引擎打造的AI技术生态平台,聚焦Agent与大模型开发,提供豆包系列模型(图像/视频/视觉)、智能分析与会话工具,并配套评测集、动手实验室及行业案例库。社区通过技术沙龙、挑战赛等活动促进开发者成长,新用户可领50万Tokens权益,助力构建智能应用。
更多推荐

所有评论(0)