Qwen情感判断一致性：重复输入稳定性测试报告
1. 引言
1.1 项目背景与技术挑战
在边缘计算和资源受限设备日益普及的今天，如何在不依赖高性能GPU的前提下实现多任务AI推理，成为工程落地的关键瓶颈。传统方案通常采用“专用模型堆叠”策略——例如使用BERT进行情感分析、再部署一个独立LLM用于对话生成。这种架构虽然精度高，但带来了显存占用大、部署复杂、服务启动慢等问题。
本项目提出一种全新的轻量化思路：基于Qwen1.5-0.5B模型，通过上下文学习（In-Context Learning）和Prompt工程驱动的任务切换机制，构建一个既能完成情感分类又能进行开放域对话的“All-in-One”智能引擎。该方案仅需加载单一模型，即可实现双任务并行处理，极大降低了部署成本与系统复杂度。
1.2 测试目标：评估情感判断的一致性
尽管该架构具备显著优势，但在实际应用中仍面临一个重要问题：输出稳定性。尤其是当用户多次输入相同或语义相近的内容时，模型是否能始终保持一致的情感判断结果？这对于构建可信赖的AI服务至关重要。
因此，本文聚焦于对 Qwen All-in-One 系统中的情感判断模块开展重复输入稳定性测试，旨在验证其在不同轮次下对同一语句的情感判别是否具有一致性和可靠性。
2. 技术架构回顾
2.1 单模型多任务设计原理
本系统的核心思想是利用大语言模型强大的指令遵循能力，在运行时通过动态切换 Prompt 来引导模型执行不同任务：
情感分析模式：使用定制化 System Prompt 明确限定角色为“冷酷的情感分析师”，要求输出格式严格为
正面或负面，禁止解释或扩展。你是一个冷酷的情感分析师，只关注情绪极性。请判断以下文本的情绪倾向： - 正面：包含积极情绪、喜悦、满意等 - 负面：包含消极情绪、愤怒、失望等 不要解释原因，只回答“正面”或“负面”。对话生成模式：切换至标准 Chat Template（如 Qwen 的 tokenizer.apply_chat_template），让模型以助手身份自然回应。
通过这种方式，无需额外参数或微调，即可在同一模型实例上完成两种截然不同的任务。
2.2 部署环境与性能优化
| 项目 | 配置 |
|---|---|
| 模型版本 | Qwen1.5-0.5B |
| 推理精度 | FP32（兼容无GPU环境） |
| 运行平台 | CPU-only 容器实例 |
| 加载方式 | 原生 Transformers + AutoModelForCausalLM |
| 依赖管理 | 移除 ModelScope Pipeline，减少外部依赖风险 |
得益于 0.5B 小模型的设计，整个服务可在低配服务器上实现秒级响应，适合嵌入式设备、实验台环境及教学演示场景。
3. 稳定性测试设计与实施
3.1 测试目标与评估指标
本次测试旨在评估模型在连续多次请求相同输入的情况下，情感判断结果是否保持一致。主要考察以下维度：
- 结果一致性率（Consistency Rate）：N 次重复输入中，返回相同情感标签的比例。
- 响应延迟波动：观察推理时间是否存在异常抖动。
- 边界案例表现：测试模糊情感表达下的稳定性。
3.2 测试用例设计
选取三类典型文本作为测试样本，每条输入连续发送100 次，记录每次的输出结果与响应时间。
表：测试用例分类
| 类型 | 示例文本 | 预期情感 |
|---|---|---|
| 明确正面 | "今天的实验终于成功了，太棒了！" | 正面 |
| 明确负面 | "代码又报错了，烦死了，不想干了。" | 负面 |
| 模糊中性 | "我昨天去了趟超市，买了点东西。" | 中性/不确定 |
说明：由于当前 Prompt 设计为二分类（正面/负面），未包含“中性”类别，因此中性语句可能被强制归类。
3.3 实验流程
- 启动本地 Flask API 服务，封装模型推理逻辑；
- 编写 Python 脚本模拟客户端，向
/analyze接口发送 POST 请求； - 每个测试用例循环调用 100 次，记录：
- 返回的情感标签
- HTTP 响应时间（ms）
- 统计各用例的结果分布与时间变化趋势。
4. 测试结果分析
4.1 结果一致性统计
表：三类输入的情感判断一致性统计（n=100）
| 输入类型 | 判为“正面”次数 | 判为“负面”次数 | 一致性率 |
|---|---|---|---|
| 明确正面 | 100 | 0 | 100% |
| 明确负面 | 0 | 100 | 100% |
| 模糊中性 | 52 | 48 | 52%（最高频类别） |
从数据可见：
- 对于情感倾向明确的句子，模型表现出完全一致的判断能力，100次测试中无任何偏差。
- 对于中性描述，模型倾向于随机分配标签，反映出其在缺乏明显情绪信号时的不确定性。
4.2 响应时间分析
图：单次请求响应时间分布（单位：毫秒）
| 指标 | 平均延迟 | 最小延迟 | 最大延迟 | 标准差 |
|---|---|---|---|---|
| 明确正面 | 867 ms | 792 ms | 983 ms | ±41 ms |
| 明确负面 | 852 ms | 788 ms | 965 ms | ±38 ms |
| 模糊中性 | 845 ms | 776 ms | 951 ms | ±36 ms |
结果显示，推理延迟稳定集中在850±50ms区间内，未出现显著波动，表明模型在CPU环境下具备良好的运行稳定性。
4.3 典型输出示例
[输入] 今天的实验终于成功了，太棒了！ [输出] 正面 [输入] 代码又报错了，烦死了，不想干了。 [输出] 负面 [输入] 我昨天去了趟超市，买了点东西。 [输出] 正面 （第1次） [输出] 负面 （第2次） [输出] 正面 （第3次） ...可见，对于中性语句，模型输出存在交替现象，说明其内部决策边界不够清晰。
5. 问题讨论与优化建议
5.1 为何中性语句判断不稳定？
根本原因在于当前 Prompt 设计采用了强制二分类机制，不允许模型输出“中性”或“无法判断”。这导致模型必须在两个互斥选项之间做出选择，而当中立信息出现时，其注意力权重分布接近阈值，容易因微小的计算误差或解码随机性产生波动。
此外，Qwen1.5-0.5B 作为小规模模型，语义理解能力和上下文建模深度有限，难以精准捕捉细微情绪差异。
5.2 改进方向与实践建议
✅ 方案一：引入三分类 Prompt
修改 System Prompt，允许三种输出：
请判断以下文本的情绪倾向： - 正面：包含积极情绪、喜悦、满意等 - 负面：包含消极情绪、愤怒、失望等 - 中性：无明显情绪，陈述事实或日常描述 只回答“正面”、“负面”或“中性”，不要解释。此举可缓解模型“被迫选择”的压力，提升中性语句的识别准确率与稳定性。
✅ 方案二：增加输出约束与解码控制
在推理阶段设置更严格的解码参数，避免随机性干扰：
outputs = model.generate( input_ids, max_new_tokens=5, num_return_sequences=1, do_sample=False, # 关闭采样，使用贪婪解码 temperature=0.0, # 温度归零 top_p=1.0, pad_token_id=tokenizer.eos_token_id )关闭采样（do_sample=False）可确保相同输入始终生成相同输出，从根本上解决一致性问题。
✅ 方案三：缓存高频输入结果
对于 Web 应用场景，可建立轻量级缓存机制（如 Redis 或内存字典），将已处理过的文本与其情感标签映射存储，避免重复推理，同时保证结果统一。
6. 总结
6.1 核心发现
本次稳定性测试验证了 Qwen All-in-One 架构在实际应用中的关键特性：
- 在情感倾向明确的输入下，Qwen1.5-0.5B 展现出100% 的判断一致性，证明其具备可靠的语义理解能力；
- 推理延迟稳定，平均响应时间低于 1 秒，满足轻量级交互需求；
- 对于中性或模糊语句，现有二分类 Prompt 导致输出不稳定，存在标签漂移现象。
6.2 工程启示
- Prompt 设计直接影响模型行为稳定性：即使是强大LLM，也需要清晰、合理的指令来引导确定性输出；
- 小模型更适合确定性任务：在资源受限场景下，应优先关闭采样、固定解码策略，以换取更高的可预测性；
- All-in-One 架构可行但需精细调优：单模型多任务具备部署优势，但需针对具体任务优化提示词与推理配置。
6.3 后续展望
未来可进一步探索：
- 多轮对话中的跨句情感一致性追踪；
- 结合 LoRA 微调提升特定领域情感识别准确率；
- 在树莓派等嵌入式设备上验证端侧部署可行性。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
