update

README.md

@@ -10,63 +10,6 @@ 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
 

app.py

@@ -1,3 +1,56 @@
+"""
+# 大型语言模型 (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. 部署与提交问题
+
+在开发和部署 LLM 基准测试系统时，常遇到“模型未找到”（因私有性或访问权限问题）和 `trust_remote_code=True` 安全警告（平台出于安全考虑拒绝自动提交此类模型） 两类问题。解决方案是选择公开可用的模型，并避免使用需要 `trust_remote_code=True` 的模型进行平台提交。
+
+## 6. 结论与展望
+
+本项目成功构建了一个中文到英文翻译模型对比评估系统，并利用 GRACE 框架对 Opus-MT 和 T5-Small 进行了多维度分析。结果显示，专门翻译模型在质量上表现稳定，而小型通用模型在效率上优势明显。未来可引入真实用户评估、集成更高级的量化评估指标（如 BLEU、ROUGE）、扩展模型库以及优化 GPU 环境下的性能，以提升评估的全面性和准确性。
+"""
 import gradio as gr
 import pandas as pd
 import plotly.graph_objects as go
@@ -5,7 +58,7 @@ import plotly.express as px
 import time
 import numpy as np
 # 导入 AutoTokenizer 和 AutoModelForSeq2SeqLM
-from transformers import pipeline, AutoTokenizer, AutoModelForSeq2SeqLM
+from transformers import pipeline, AutoTokenizer, AutoModelForSeq2SeqLM 
 import torch
 import json
 import re
@@ -26,10 +79,10 @@ MODEL_CONFIGS = {
     }
     # 如果需要第三个模型，可以取消注释下面这个，或替换成您想要的
     # "Chinese-to-English (Another Model)": {
-    #       "model_name": "facebook/mbart-large-50-one-to-many-mmt",
-    #       "description": "中文到英文的机器翻译模型 (Facebook mBART-Large-50)",
-    #       "max_length": 200,
-    #       "color": "#45B7D1"
+    #     "model_name": "facebook/mbart-large-50-one-to-many-mmt",
+    #     "description": "中文到英文的机器翻译模型 (Facebook mBART-Large-50)",
+    #     "max_length": 200,
+    #     "color": "#45B7D1"
     # }
 }
 
@@ -44,7 +97,7 @@ class TranslationComparator:
         for model_key, config in MODEL_CONFIGS.items():
             try:
                 print(f"加载 {model_key} ({config['model_name']})...")
-
+                
                 # T5模型通常用于多任务，这里我们明确指定它用于翻译
                 # pipeline("translation") 会尝试自动处理，但T5需要特定输入格式
                 self.models[model_key] = pipeline(
@@ -75,7 +128,7 @@ class TranslationComparator:
 
         try:
             start_time = time.time()
-
+            
             # **针对 T5 模型添加输入格式化**
             if "t5-small" in model_key.lower(): # 检查是否是T5-Small模型
                 # T5的翻译任务通常需要这样的前缀
@@ -89,11 +142,11 @@ class TranslationComparator:
                     text_to_translate,
                     max_length=max_length
                 )
-
+            
             end_time = time.time()
-
+            
             translated_text = result[0]['translation_text']
-
+            
             return {
                 "translated_text": translated_text,
                 "inference_time": round(end_time - start_time, 3),
@@ -103,7 +156,7 @@ class TranslationComparator:
                     "max_length": max_length
                 }
             }
-
+        
         except Exception as e:
             return {
                 "error": f"翻译错误: {str(e)}",
@@ -117,7 +170,7 @@ comparator = TranslationComparator()
 
 def run_translation_comparison(zh_prompt, max_length):
     """运行所有中文到英文模型的翻译对比"""
-
+    
     if not zh_prompt.strip():
         # 返回与模型数量相匹配的错误消息
         return tuple([gr.Code.update(value=json.dumps({"错误信息": "请输入中文文本进行翻译"}, ensure_ascii=False)) for _ in MODEL_CONFIGS])
@@ -132,7 +185,7 @@ def run_translation_comparison(zh_prompt, max_length):
             max_length=int(max_length)
         )
         results[model_key] = result
-
+    
         # 格式化输出
         if "error" in result:
             outputs_list.append(json.dumps({"错误信息": result["error"]}, indent=2, ensure_ascii=False))
@@ -144,7 +197,7 @@ def run_translation_comparison(zh_prompt, max_length):
                 "翻译速度": f"{result['output_length']/max(result['inference_time'], 0.001):.1f} tokens/s"
             }
             outputs_list.append(json.dumps(formatted, indent=2, ensure_ascii=False))
-
+    
     return tuple(outputs_list)
 
 
@@ -154,17 +207,17 @@ def calculate_grace_scores_for_translation():
     grace_data = {
         "Chinese-to-English (Opus-MT)": {
             "Generalization": 7.8, # 处理不同领域中翻英能力
-            "Relevance": 8.3,       # 翻译内容与原文语义相关性
-            "Accuracy": 8.0,        # 翻译精确性
-            "Consistency": 7.9,     # 翻译稳定性
-            "Efficiency": 7.5       # 推理效率
+            "Relevance": 8.3,     # 翻译内容与原文语义相关性
+            "Accuracy": 8.0,      # 翻译精确性
+            "Consistency": 7.9,   # 翻译稳定性
+            "Efficiency": 7.5     # 推理效率
         },
         "Chinese-to-English (T5-Small)": { # **T5-Small 的模拟 GRACE 分数**
             "Generalization": 6.8, # 比T5-Base略低，泛化性可能稍弱
             "Relevance": 7.0,
             "Accuracy": 6.5,
             "Consistency": 6.8,
-            "Efficiency": 9.0       # 模型更小，效率更高
+            "Efficiency": 9.0     # 模型更小，效率更高
         }
     }
     return grace_data
@@ -180,7 +233,7 @@ def create_translation_radar_chart():
     for i, (model_name, scores) in enumerate(grace_scores.items()):
         values = [scores[cat] for cat in categories]
         # 这里使用 MODEL_CONFIGS[model_name]["color"] 依赖于 MODEL_CONFIGS 和 grace_scores 的键名一致
-        color = MODEL_CONFIGS[model_name]["color"]
+        color = MODEL_CONFIGS[model_name]["color"] 
 
         fig.add_trace(go.Scatterpolar(
             r=values,
@@ -254,7 +307,7 @@ def create_model_info_table():
         else: # 默认值
             params = "未知"
             size = "未知"
-            
+        
         model_info.append({
             "模型": model_key,
             "参数量": params,
@@ -383,84 +436,7 @@ def create_app():
                             label="GRACE 评分摘要",
                             interactive=False
                         )
-            
-            # New tab for the Evaluation Report
-            with gr.TabItem("📄 评估报告"):
-                gr.Markdown("""
-                    # 大型语言模型 (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 环境下的性能，以提升评估的全面性和准确性。
-                    """)
-            
+        
     return app
 
 # 创建并启动 Gradio 应用