Hugging Face's logo

Spaces:
hellokawei
/
work
Sleeping

App Files Community
3
work
File size: 7,947 Bytes 
713cdf1
b9c3284
713cdf1
 
 
 
 
 
b9c3284
713cdf1
 
 
d9db988
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
713cdf1
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
 
---
title: Sample Leaderboard
emoji: 🥇
colorFrom: green
colorTo: indigo
sdk: gradio
app_file: app.py
pinned: true
license: mit
short_description: Duplicate this leaderboard to initialize your own!
sdk_version: 5.19.0
---
"""
"""
# 大型语言模型 (LLM) 翻译能力对比评估报告
## 1. 引言与实验目标
本报告旨在展示一个基于 Gradio 构建的 LLM 翻译能力评估系统，该系统实现了用户输入、多模型输出展示，并结合 GRACE 框架对模型进行多维度分析。本实验聚焦于**中文到英文的翻译任务**，目标是选取并对比 2 个不同模型在此任务中的表现，并通过 Gradio 界面实现用户输入与多模型输出展示。此外，还将结合 GRACE 框架对模型进行维度分析。
## 2. GRACE 评估框架
GRACE 框架是一个多维度评估框架，用于全面衡量 LLM 在特定任务中的性能。在本次翻译任务的评估中，我们选择了以下 5 个维度：
* **G: Generalization (泛化性)**：模型处理不同领域、风格、复杂度的文本并准确翻译的能力。
* **R: Relevance (相关性)**：翻译内容与原文语义和上下文的匹配程度。
* **A: Accuracy (准确性)**：翻译的精确性和无误性，包括语法、词汇和句法结构的正确性。
* **C: Consistency (一致性)**：相同或类似输入文本在不同时间或上下文中的翻译稳定性。
* **E: Efficiency (效率性)**：翻译速度和所需的计算资源。
## 3. 系统设计与模型选择
系统采用 Gradio 构建前端界面，后端利用 Hugging Face Transformers 库加载和运行模型，并结合 Pandas、Plotly 和 NumPy 进行数据处理与可视化。我们选择了两个中文到英文的翻译模型进行对比：
1.  **Chinese-to-English (Opus-MT)**: 使用 `Helsinki-NLP/opus-mt-zh-en`，这是一个约 3 亿参数、1.2GB 大小的专门翻译模型，预期在中文到英文翻译上具有较高准确性和流畅性。
2.  **Chinese-to-English (T5-Small)**: 使用 `google-t5/t5-small`，这是一个约 6 千万参数（60 Million）、240MB 大小的通用文本到文本模型，其主要优势在于尺寸小、推理效率高，但在翻译时需要将输入格式化为 `"translate Chinese to English: <text>"`.
在 `TranslationComparator` 类中，模型通过 `transformers.pipeline("translation")` 加载。`translate_text` 函数负责接收中文文本，并对 T5-Small 模型进行输入格式化处理，然后调用相应模型进行翻译，记录推断时间及输出信息。
## 4. 实验结果与分析
两个模型均成功加载并运行。在实际翻译中，Opus-MT 作为专门模型，通常提供更高质量和流畅的翻译；T5-Small 则以其小尺寸和高效率见长。
**GRACE 评估模拟结果 (数据来源于代码中的模拟分数):**
| 模型                             | 泛化性 | 相关性 | 准确性 | 一致性 | 效率性 | 平均分 |
| :------------------------------- | :----- | :----- | :----- | :----- | :----- | :----- |
| Chinese-to-English (Opus-MT)   | 7.8    | 8.3    | 8.0    | 7.9    | 7.5    | 7.90   |
| Chinese-to-English (T5-Small) | 6.8    | 7.0    | 6.5    | 6.8    | 9.0    | 7.22   |
从模拟数据中可以看出，Opus-MT 在翻译质量维度（泛化性、相关性、准确性、一致性）得分更高。T5-Small 则在**效率性**上表现突出（9.0分），但由于其通用性，翻译质量略低于专门模型。在参数量和模型大小上，T5-Small 显著优于 Opus-MT，在资源受限场景下更具优势。
**可视化示例:**
* **GRACE 雷达图**: 展示了模型在 GRACE 各维度的对比。
    ![GRACE 雷达图示例](image_6b7454.png)
* **GRACE 详细性能对比柱状图**: 提供各维度分数的直观比较。
    ![GRACE 详细对比示例](image_6b5a12.png)
## 5. 部署与提交问题
成员 A：系统架构与模型集成
负责内容：
设计TranslationComparator类，完成 Opus-MT、T5-Small、mBART-Large 三个模型的加载与管理，处理模型输入格式差异（如 T5-Small 的任务前缀、mBART 的源语言指定）。
实现翻译核心逻辑translate_text函数，集成推理时间计算、Token 统计等性能指标记录。
解决模型加载异常问题，设计 fallback 机制（如模型未找到时返回模拟翻译结果）。
学到的内容：
Hugging Face Transformers 库的底层原理，掌握pipeline接口在多模型场景下的参数定制（如src_lang、max_length）。
CPU 推理环境下的内存优化策略，通过torch.float32降低精度需求，避免大型模型（如 mBART）加载时的显存溢出。
跨模型兼容性处理，例如不同模型对输入文本格式的特殊要求（任务前缀、语言代码指定）。
遇到的困难：
mBART-Large 模型因多语言参数导致的加载耗时问题，最终通过预加载机制和异步处理缓解。
模型推理速度差异大（如 T5-Small 与 mBART 的效率对比），需在代码中平衡实时响应与翻译质量。
成员 B：前端开发与评估可视化
负责内容：
基于 Gradio 构建交互式界面，设计 “翻译竞技场” 和 “GRACE 基准测试” 双模块，实现用户输入、模型输出展示及参数调节功能。
开发 GRACE 评估可视化组件，包括雷达图（create_translation_radar_chart）、柱状图（create_performance_bar_chart）及数据表格。
整合示例文本功能与动态布局，优化响应式设计以适配不同设备。
学到的内容：
Gradio 框架的组件嵌套逻辑（Blocks/Tab/Row），掌握事件监听（如按钮点击、滑块调节）与数据绑定机制。
Plotly 图表开发技巧，例如雷达图中多模型曲线的颜色编码、分组柱状图的维度映射。
前端数据格式化处理，将模型翻译结果转换为 JSON 格式并在 Code 组件中高亮展示。
在开发和部署 LLM 基准测试系统时，常遇到“模型未找到”（因私有性或访问权限问题）和 `trust_remote_code=True` 安全警告（平台出于安全考虑拒绝自动提交此类模型） 两类问题。解决方案是选择公开可用的模型，并避免使用需要 `trust_remote_code=True` 的模型进行平台提交。
## 6. 结论与展望
本项目成功构建了一个中文到英文翻译模型对比评估系统，并利用 GRACE 框架对 Opus-MT 和 T5-Small 进行了多维度分析。结果显示，专门翻译模型在质量上表现稳定，而小型通用模型在效率上优势明显。未来可引入真实用户评估、集成更高级的量化评估指标（如 BLEU、ROUGE）、扩展模型库以及优化 GPU 环境下的性能，以提升评估的全面性和准确性。
"""
"""

# Start the configuration

Most of the variables to change for a default leaderboard are in `src/env.py` (replace the path for your leaderboard) and `src/about.py` (for tasks).

Results files should have the following format and be stored as json files:
```json
{
    "config": {
        "model_dtype": "torch.float16", # or torch.bfloat16 or 8bit or 4bit
        "model_name": "path of the model on the hub: org/model",
        "model_sha": "revision on the hub",
    },
    "results": {
        "task_name": {
            "metric_name": score,
        },
        "task_name2": {
            "metric_name": score,
        }
    }
}
```

Request files are created automatically by this tool.

If you encounter problem on the space, don't hesitate to restart it to remove the create eval-queue, eval-queue-bk, eval-results and eval-results-bk created folder.

# Code logic for more complex edits

You'll find 
- the main table' columns names and properties in `src/display/utils.py`
- the logic to read all results and request files, then convert them in dataframe lines, in `src/leaderboard/read_evals.py`, and `src/populate.py`
- the logic to allow or filter submissions in `src/submission/submit.py` and `src/submission/check_validity.py`