Update app.py

app.py

@@ -1,68 +1,52 @@
 """
 # 大型语言模型 (LLM) 翻译能力对比评估报告
-
 ## 1. 引言与实验目标
-
 本报告旨在展示一个基于 Gradio 构建的 LLM 翻译能力评估系统，该系统实现了用户输入、多模型输出展示，并结合 GRACE 框架对模型进行多维度分析。本实验聚焦于**中文到英文的翻译任务**，目标是选取并对比 **3 个不同模型**在此任务中的表现，并通过 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 千万参数、240MB 大小的通用文本到文本模型，其主要优势在于尺寸小、推理效率高，但在翻译时需要将输入格式化为 `"translate Chinese to English: <text>"`.
 3.  **Chinese-to-English (mBART-Large)**: 使用 `facebook/mbart-large-50-one-to-many-mmt`，这是一个约 6 亿参数、2.4GB 大小的多语言翻译模型，泛化能力强，但需要为其指定源语言（`zh_CN`）。
-
 在 `TranslationComparator` 类中，模型通过 `transformers.pipeline("translation")` 加载。`translate_text` 函数负责接收中文文本，并根据模型需求（如 T5-Small）进行输入格式化处理，然后调用相应模型进行翻译，记录推断时间及输出信息。
-
 ## 4. 实验结果与分析
-
 三个模型均成功加载并运行。在实际翻译中，专门模型（Opus-MT）和大型多语言模型（mBART）通常提供更高质量的翻译；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   |
 | Chinese-to-English (mBART-Large) | 8.5    | 8.6    | 8.4    | 8.2    | 6.0    | 7.94   |
-
-
 从模拟数据中可以看出，Opus-MT 和 mBART 在翻译质量维度得分更高，其中 mBART 在泛化性上表现最佳。T5-Small 则在**效率性**上表现突出（9.0分）。在参数量和模型大小上，T5-Small 显著优于其他两者，在资源受限场景下更具优势。
-
 **可视化示例 (由下方应用实时生成):**
 *   **GRACE 雷达图**: (下图为报告生成时的示例)
     
 *   **GRACE 详细性能对比柱状图**: (下图为报告生成时的示例)
     
-
-## 5. 收获
-成员 A：系统架构与模型集成
+## 5. 部署与提交问题
+成员 A：系统设计与前端开发
 负责内容：
 
-设计TranslationComparator类，完成 Opus-MT、T5-Small、mBART-Large 三个模型的加载与管理，处理模型输入格式差异（如 T5-Small 的任务前缀、mBART 的源语言指定）。
-实现翻译核心逻辑translate_text函数，集成推理时间计算、Token 统计等性能指标记录。
-解决模型加载异常问题，设计 fallback 机制（如模型未找到时返回模拟翻译结果）。
+基于 Gradio 构建前端交互界面，设计 “翻译竞技场” 和 “GRACE 基准测试” 两个功能模块。
+实现用户输入文本处理、模型翻译结果展示及动态交互逻辑。
+整合示例文本功能和参数调节滑块，优化用户体验。
 
 学到的内容：
 
-Hugging Face Transformers 库的底层原理，掌握pipeline接口在多模型场景下的参数定制（如src_lang、max_length）。
-CPU 推理环境下的内存优化策略，通过torch.float32降低精度需求，避免大型模型（如 mBART）加载时的显存溢出。
-跨模型兼容性处理，例如不同模型对输入文本格式的特殊要求（任务前缀、语言代码指定）。
+Gradio 框架的组件布局与事件监听机制，掌握 Blocks、Tab、Row 等容器组件的嵌套使用。
+前端与后端数据传输的格式处理，例如将模型翻译结果格式化为 JSON 并在 Code 组件中展示。
+响应式设计原则，确保界面在不同设备上的兼容性。
 
 遇到的困难：
 
-mBART-Large 模型因多语言参数导致的加载耗时问题，最终通过预加载机制和异步处理缓解。
-模型推理速度差异大（如 T5-Small 与 mBART 的效率对比），需在代码中平衡实时响应与翻译质量。
+多模型并行翻译时前端加载速度优化问题，通过异步处理和模型预加载缓解延迟。
+Gradio 组件样式定制限制，部分交互效果需通过 JavaScript 脚本间接实现。
 成员 B：前端开发与评估可视化
 负责内容：
 
@@ -80,12 +64,9 @@ Plotly 图表开发技巧，例如雷达图中多模型曲线的颜色编码、
 
 多模型翻译结果同时渲染时的界面卡顿问题，通过分批加载和虚拟滚动技术优化。
 雷达图中评估维度（泛化性、准确性等）的视觉权重平衡，需反复调整坐标轴范围与标签显示策略。
-
 在开发和部署 LLM 基准测试系统时，常遇到“模型未找到”（因私有性或访问权限问题）和 `trust_remote_code=True` 安全警告（平台出于安全考虑拒绝自动提交此类模型） 两类问题。解决方案是选择公开可用的模型，并避免使用需要 `trust_remote_code=True` 的模型进行平台提交。
-
 ## 6. 结论与展望
-
-本项目成功构建了一个中文到英文翻译模型对比评估系统，并利用 GRACE 框架对 Opus-MT、T5-Small 和 mBART-Large 进行了多维度分析。结果显示，专门和大型模型在质量上表现优异，而小型通用模型在效率上优势明显。未来可引入真实用户评估、集成更高级的量化评估指标（如 BLEU、ROUGE）、扩展模型库以及优化 GPU 环境下的性能，以提升评估的全面性和准确性。
+#本项目成功构建了一个中文到英文翻译模型对比评估系统，并利用 GRACE 框架对 Opus-MT、T5-Small 和 mBART-Large 进行了多维度分析。结果显示，专门和大型模型在质量上表现优异，而小型通用模型在效率上优势明显。未来可引入真实用户评估、集成更高级的量化评估指标（如 BLEU、ROUGE）、扩展模型库以及优化 GPU 环境下的性能，以提升评估的全面性和准确性。
 """
 import gradio as gr
 import pandas as pd
@@ -406,4 +387,4 @@ def create_app():
 # 创建并启动 Gradio 应用
 if __name__ == "__main__":
     app = create_app()
-    app.launch()
+    app.launch()