README.md

metadata

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:

{
    "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