简介这份资源是一套基于ChatGPT实现情感分析的Python项目源码面向计算机、人工智能、通信工程等专业的在校学生与教师也适合具备一定基础、希望进阶学习自然语言处理的小白开发者可用于毕业设计、课程设计、作业提交或项目初期立项演示。压缩包共3个文件包含2个py源码文件与1个md说明文档整体约9KB其中py文件承载情感分析主逻辑与UIE情感调用流程md文件提供项目说明与运行指引。目前已有108人学习浏览。项目代码均经过实际运行测试功能完整作者答辩评审平均分达96分读者可借此掌握给定句子判断情感倾向的完整实现思路理解ChatGPT接口调用与情感分类逻辑的结合方式并可在源码基础上修改扩展实现更丰富的分析功能适合作为学习参考与二次开发起点。1. 从一份 Python 情感分析源码说起ChatGPT 到底替我们省了哪一步电商评论、应用商店评分、客服工单这些文本每天都在产生但真正让人头疼的不是拿不到数据而是拿到之后怎么判断一条评论到底是夸还是骂。传统做法是拉一批标注数据训一个 BERT 或者 TextCNN调参、评估、上线一套流程走下来少说两周。而「python实现的基于ChatGPT的情感分析源代码文档说明」这个标题指向的方案核心思路是把分类这一步直接交给大模型用 Python 做工程封装把数据读取、批量请求、结果落盘、可视化串成一条流水线。它适合两类人一类是刚学完 Python 基础、想找一个能跑通又有实际价值的练手项目另一类是手头有几千条评论、不想训模型、只想快速拿到情感标签的从业者。这篇文章不讲空泛概念而是把源码里最关键的几个模块拆开告诉你每一步为什么这么写、参数怎么调、哪里最容易翻车。读完你应该能自己搭出一套可用的情感分析流水线而不是只会复制粘贴。2. 用 Python 封装 ChatGPT 情感分析从单条请求到批量流水线2.1 为什么选 ChatGPT 而不是自己训模型先说选型理由。自己训模型的好处是可控、离线、成本固定但代价是标注数据。情感分析看着简单实际标注一致性很差同一句话三个人可能给出三种标签。ChatGPT 这类大模型在预训练阶段已经见过海量带情感倾向的文本零样本或少量样本就能给出相当稳定的判断省掉的正是最贵的那一步。从工程角度看用 API 做情感分析本质是一次文本分类请求。输入是评论原文输出是「正面 / 负面 / 中性」加一个简短理由。Python 在这里的角色是胶水层读数据、拼 prompt、发请求、处理异常、写结果。源码里通常会把这几件事拆成独立函数方便替换模型或调整 prompt。需要提前想清楚的是成本和延迟。一条评论一次请求一万条就是一万次调用。如果每条评论平均 200 字按主流模型的计费方式成本并不低。所以源码里一般会做两件事一是批量并发二是结果缓存。并发控制不好会触发限流缓存没做会导致重复请求浪费钱。2.2 最小可运行的单条分析脚本先看最核心的一段代码把一条评论发给模型并拿回结构化结果。这里用常见的 OpenAI 兼容接口写法实际替换成你手头可用的模型服务即可。import os import json from openai import OpenAI # 从环境变量读取密钥不要硬编码在源码里 client OpenAI( api_keyos.getenv(API_KEY), base_urlos.getenv(BASE_URL, https://api.openai.com/v1) ) def analyze_sentiment(text: str) - dict: 对单条文本做情感分析返回结构化字典 prompt f你是一个情感分析引擎。请判断下面这段文本的情感倾向。 只返回 JSON不要任何额外解释。格式 {{label: 正面|负面|中性, confidence: 0.0-1.0, reason: 一句话理由}} 文本{text} resp client.chat.completions.create( modelgpt-4o-mini, # 模型名按你实际可用的填 messages[{role: user, content: prompt}], temperature0, # 分类任务要确定性温度设 0 max_tokens200, response_format{type: json_object} # 强制 JSON 输出 ) content resp.choices[0].message.content return json.loads(content) if __name__ __main__: result analyze_sentiment(物流很快但是包装有点破损东西还行。) print(result)这段代码有三个关键点。第一temperature0是分类任务的标配温度越高输出越随机情感标签会飘。第二response_format强制 JSON省去了解析自然语言的麻烦但要注意不是所有模型都支持这个参数不支持时得靠 prompt 约束加正则兜底。第三prompt 里明确要求「只返回 JSON」并且给了格式示例这是让模型稳定输出的最有效手段。参数说明model决定成本和效果轻量模型足够做情感三分类max_tokens设 200 是因为理由通常很短设太大浪费confidence字段是让模型自评实际用的时候可以设阈值低于 0.6 的转人工复核。2.3 批量处理并发、限流与断点续跑单条能跑通之后真正的工程问题才出现。几千条评论串行请求按每条 1 秒算要一个多小时而且中途任何一次网络抖动都会让整个脚本崩掉。源码里通常用线程池加队列的方式解决。import csv import time from concurrent.futures import ThreadPoolExecutor, as_completed def batch_analyze(input_csv: str, output_csv: str, max_workers: int 5): 批量分析 CSV 中的评论支持断点续跑 # 读取已处理的结果用于断点续跑 done set() try: with open(output_csv, r, encodingutf-8) as f: for row in csv.DictReader(f): done.add(row[text]) except FileNotFoundError: pass rows [] with open(input_csv, r, encodingutf-8) as f: for row in csv.DictReader(f): if row[text] not in done: rows.append(row) with open(output_csv, a, encodingutf-8, newline) as f: writer csv.DictWriter(f, fieldnames[text, label, confidence, reason]) if not done: writer.writeheader() with ThreadPoolExecutor(max_workersmax_workers) as pool: futures {pool.submit(analyze_sentiment, r[text]): r for r in rows} for fut in as_completed(futures): r futures[fut] try: res fut.result() writer.writerow({text: r[text], **res}) f.flush() # 每条都落盘崩了也不丢 except Exception as e: print(f失败: {r[text][:20]}... 原因: {e}) time.sleep(1) # 失败后稍等避免连续触发限流逻辑说明先读输出文件建立已处理集合这样脚本中断后重跑不会重复请求也不会重复计费。max_workers5是保守值多数 API 的并发限制在 10 到 60 之间设太高会收到 429 错误。每条结果立即flush这是血泪经验——曾经跑了两千条没落盘程序崩溃后全部重来。异常捕获里加time.sleep(1)是简单的退避生产环境应该用指数退避。参数怎么改数据量小可以把max_workers提到 10如果 API 返回限流错误频繁降到 3 并加长退避时间input_csv的列名要和代码里的text对齐否则会 KeyError。2.4 结果落盘与可视化让标签变成能看的东西拿到标签之后源码里一般会配一个简单的统计和绘图脚本把正面负面比例、随时间的变化趋势画出来。这一步不是花架子而是验证结果是否合理的手段。如果一批明显是好评的评论被标成负面说明 prompt 或模型选型有问题。import pandas as pd import matplotlib.pyplot as plt df pd.read_csv(output.csv) counts df[label].value_counts() counts.plot(kindbar, title情感分布) plt.tight_layout() plt.savefig(sentiment_dist.png) # 按置信度过滤低置信度的单独导出复核 low_conf df[df[confidence] 0.6] low_conf.to_csv(need_review.csv, indexFalse) print(f总条数 {len(df)}待复核 {len(low_conf)})这段代码做了两件事画分布图以及把低置信度样本单独导出。后者是实际项目里最容易被忽略但最有价值的一步模型不确定的样本往往正是边界案例人工看一遍能发现 prompt 的系统性偏差。3. 避坑与排查情感分析流水线最容易翻车的五个地方3.1 现象模型把反讽判成正面原因反讽、双重否定、网络梗是情感分析的经典难题。模型看到「真是太好了呢」这种句子字面是正面实际是负面。prompt 里如果没有特别说明模型倾向于按字面判断。解决在 prompt 里加一句「注意识别反讽和双重否定结合语境判断真实情感」并给一两个反讽示例。如果数据里反讽比例高考虑先做一轮规则过滤把带明显反讽标记的句子单独处理。3.2 现象批量跑一半开始大量报错原因多数是触发了 API 限流返回 429 或连接超时。并发数设太高、请求间隔太短都会导致。另一个可能是密钥额度用尽。解决把max_workers降到 3在异常处理里加指数退避第一次等 1 秒第二次 2 秒第三次 4 秒。同时监控错误率超过 10% 就暂停脚本检查额度。3.3 现象JSON 解析失败程序崩溃原因模型偶尔会在 JSON 前后加解释文字或者输出不完整的 JSON。即使设了response_format部分兼容接口也不完全遵守。解决解析前先用正则提取第一个{到最后一个}之间的内容再做json.loads。加一层 try-except解析失败时把原始输出存下来不要直接丢弃。3.4 现象同一句话两次请求结果不一样原因temperature没设成 0或者模型本身有随机性。另外 prompt 太长时模型对后半部分的注意力会下降。解决分类任务固定temperature0。prompt 控制在 500 字以内把判断标准放在前面。如果还是不稳定对同一条文本请求两次取一致结果不一致的标记为待复核。3.5 现象成本远超预期原因没有做缓存重复文本反复请求或者 prompt 里塞了太多示例每次请求都带上token 数翻倍。解决用文本的哈希值做缓存键本地存一份hash - result的映射请求前先查。few-shot 示例控制在 2 到 3 个且只保留最有代表性的。定期统计 token 消耗设一个日预算上限。4. 进阶技巧用 few-shot 和自一致性把准确率再抬一截零样本能跑通但要做到可用few-shot 是性价比最高的提升手段。做法是在 prompt 里放几条标注好的示例让模型模仿判断标准。示例的选择有讲究不要只放典型的好评差评要放边界案例比如「质量一般但客服态度好」这种混合情感让模型学会按主要倾向归类。FEW_SHOT 示例1 文本东西不错就是发货太慢了。 输出{label: 中性, confidence: 0.7, reason: 褒贬并存整体偏中性} 示例2 文本用了三天就坏了客服还不理人。 输出{label: 负面, confidence: 0.95, reason: 质量问题加服务问题} 示例3 文本包装很用心会回购。 输出{label: 正面, confidence: 0.9, reason: 明确正面表达} def build_prompt(text: str) - str: return f你是一个情感分析引擎按示例的判断标准处理新文本。 只返回 JSON。 {FEW_SHOT} 文本{text} 输出示例数量控制在 3 条左右太多会推高每次请求的成本而且边际收益递减。示例的标签分布要均衡不能全是正面否则模型会偏向正面。另一个技巧是自一致性投票。对同一条文本用稍有不同的 prompt 请求三次取多数结果。这能把准确率提升几个百分点代价是成本翻三倍。适合用在对准确率要求高、数据量不大的场景比如几百条重点客户的反馈。验证方法上我一般会手工标 100 条作为测试集跑完算准确率和混淆矩阵。重点看负面被误判成正面的比例这类错误在实际业务里代价最大。如果负面召回率低于 0.8就回去调 prompt加负面相关的示例。最后说个习惯每次改完 prompt不要直接全量跑先拿那 100 条测试集验证确认指标没退化再上。prompt 调优是个玄学活改一处可能好也可能坏没有测试集就是盲改。这套方案值不值得做取决于你的数据量和准确率要求——几千条以内、要求快速出结果它比训模型划算得多几十万条且要求极致准确还是得回到微调路线。希望帮到你。本文还有配套的精品资源点击获取