Spaces:
Sleeping
Sleeping
| 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 详细性能对比柱状图**: 提供各维度分数的直观比较。 | |
|  | |
| ## 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` |