Update app.py

app.py

@@ -144,203 +144,6 @@ def create_arena_tab():
         )
     return arena_block
 
-# Report 选项卡内容创建函数 (30分)
-# 报告内容直接嵌入到代码中
-# def create_report_tab():
-#     report_content_markdown = """
-# # 🚀 Hugging Face 模型对比实验报告
-
-# ---
-
-# ## 1. 模型及类别选择
-
-# ### 1.1 所选模型的类型与背景说明
-# 本次实验聚焦于**文本处理模型**，具体包括一个**通用文本生成模型**和一个**抽取式问答模型**。
-# * **文本生成模型**能够根据输入的提示词（prompt）生成连贯、有意义的文本，广泛应用于自动写作、内容创作等。
-# * **抽取式问答模型**则专注于从给定文本（上下文）中精确地定位并提取问题的答案，是信息检索和智能客服的核心技术。
-# 近年来，随着Transformer架构的普及和大规模预训练技术的进步，这两类模型的性能都取得了显著提升。
-
-# ### 1.2 模型用途对比简述
-# 我们选择了以下 2 个模型进行对比：
-# * **模型 1: GPT2-Large (文本生成模型)**
-#     * **用途简述**: 作为一个大型的通用文本生成模型, GPT2-Large 能够进行开放式文本生成、续写、摘要、创意写作等多种任务。它能理解较复杂的指令并生成语法流畅、内容丰富的文本。
-# * **模型 2: deepset/roberta-base-squad2 (抽取式问答模型)**
-#     * **用途简述**: 这是一个专门用于抽取式问答任务的模型。它接收一个问题和一段上下文文本，然后从上下文中找到并返回问题的确切答案片段。主要应用于精准信息提取、文档问答系统等。
-
-# ### 1.3 选取标准与模型异同点分析
-# **选取标准**: 我们选择这两个模型主要基于以下标准：
-# 1.  **代表性**: 它们分别代表了文本处理领域中两种核心且不同的应用方向（生成与抽取）。
-# 2.  **可用性**: 模型在 Hugging Face Model Hub 上易于加载和使用 `pipeline`。
-# 3.  **性能对比潜力**: 两种不同类型的模型在 GRACE 维度上会有显著差异，有利于进行有深度的对比分析。
-
-# **异同点分析**:
-# * **相同点**:
-#     * 都基于 Transformer 架构。
-#     * 都处理自然语言文本作为输入。
-#     * 都可以在 Hugging Face `transformers` 库中通过 `pipeline` 方便地加载和使用。
-# * **不同点**:
-#     * **任务类型**: GPT2-Large 专注于**文本生成**（从无到有），而 RoBERTa-SQuAD2 专注于**信息抽取**（从已有文本中找）。
-#     * **输入输出模式**:
-#         * GPT2-Large 接收一个提示词，输出一段新的、连贯的文本。
-#         * RoBERTa-SQuAD2 接收一个问题和一段上下文，输出上下文中最精确的答案片段。
-#     * **“创造性”**: GPT2-Large 具有更强的创造性，能够生成新的、未曾出现过的句子和想法；RoBERTa-SQuAD2 不具备创造性，它只从原文中抽取答案。
-#     * **对上下文的依赖**: 问答模型对上下文的依赖性极强，没有上下文就无法回答；文本生成模型则更灵活，即便没有明确上下文也能生成内容。
-
-# ---
-
-# ## 2. 系统实现细节
-
-# ### 2.1 Gradio 交互界面截图
-
-# 以下是我们在 Hugging Face Space 中构建的 Gradio 交互界面截图。
-# ![Gradio Arena 界面截图](https://your-space-link/file/path/to/arena_screenshot.png)
-# *(请将此处的图片链接替换为你实际上传到 Space Files 中的截图链接，例如：`/file/main/arena_screenshot.png`)*
-# *说明：此图展示了我们构建的“Arena”选项卡界面。用户可以在左侧输入问题/提示词和上下文，右侧同步显示文本生成模型和问答模型的输出。*
-
-# ### 2.2 输入与输出流程图
-
-# ```mermaid
-# graph TD
-#     A[用户输入: 问题/提示词] --> B{Gradio 界面};
-#     A --> C[用户输入: 上下文];
-#     C --> B;
-#     B -- 将问题与上下文合并为Prompt --> D1[调用 GPT2-Large (文本生成模型)];
-#     B -- 将问题与上下文分离 --> D2[调用 RoBERTa-SQuAD2 (问答模型)];
-#     D1 -- 生成文本 --> E1[GPT2-Large 输出];
-#     D2 -- 抽取答案 --> E2[RoBERTa-SQuAD2 输出];
-#     E1 --> F[在 Gradio 界面显示];
-#     E2 --> F;
-# ```
-# *说明：此流程图展示了用户输入如何被 Gradio 界面捕获，问题和上下文分别传递给两个模型。文本生成模型将两者合并为提示词，问答模型则分别使用它们，最终将各自的结果展示在界面上。*
-
-# ### 2.3 模型集成方式说明
-# 我们的 Hugging Face Space 使用 Python 和 Gradio 库构建。模型集成主要通过 `transformers` 库的 `pipeline` 功能实现。
-
-# 1.  **模型加载**: 在 `app.py` 脚本初始化时，我们使用 `transformers.pipeline()` 函数加载了预训练模型。
-#     * 对于 **GPT2-Large (文本生成)**：`generator1 = pipeline("text-generation", model="gpt2-large", ...)`
-#     * 对于 **deepset/roberta-base-squad2 (问答)**：`qa_model = pipeline("question-answering", model="deepset/roberta-base-squad2", ...)`
-#     * 我们通过 `device=0 if torch.cuda.is_available() else -1` 来尝试利用 GPU（如果可用），否则回退到 CPU。
-# 2.  **推理函数**: 我们定义了一个 `get_model_outputs(question_or_prompt, context, max_length)` 函数。
-#     * 该函数接收用户输入的“问题/提示词”和“上下文”。
-#     * 对于文本生成模型，我们将问题和上下文合并为一个 `full_prompt_for_gen` 作为其输入。
-#     * 对于问答模型，我们将问题和上下文分别传递给 `qa_model`。
-#     * 函数返回两个模型的生成结果。
-# 3.  **Gradio 界面连接**: 在 Gradio 界面中，我们创建了两个文本输入框（一个用于问题/提示词，一个用于上下文）和两个独立的文本输出框。通过 `gr.Button.click()` 方法，将输入框的文本作为参数传递给 `get_model_outputs` 函数，并将函数的返回结果分别更新到对应的输出框中。
-# 4.  **错误处理**: 代码中包含了 `try-except` 块，以处理模型加载失败或推理过程中可能出现的错误，确保应用稳定性。如果模型未能加载，界面上会显示相应的错误信息。
-
-# ---
-
-# ## 3. GRACE 评估维度定义
-
-# 我们选择了以下 **4 个** GRACE 维度进行评估，并结合我们选择的模型类型给出了具体定义：
-
-# 1.  **R: Relevance (相关性)**：
-#     * **定义**:
-#         * **文本生成模型 (GPT2-Large)**：生成的文本内容与用户输入的提示词（包括上下文）在语义上是否紧密相关，是否准确捕捉并回应了提示词的核心主题或意图。
-#         * **问答模型 (RoBERTa-SQuAD2)**：抽取出的答案是否准确地回答了问题，并且答案内容完全来自于提供的上下文。
-#     * **理由**: 对于任何文本处理任务，确保输出内容不偏离主题或准确回答问题至关重要。
-
-# 2.  **A: Artistry (创新表现力)**：
-#     * **定义**:
-#         * **文本生成模型 (GPT2-Large)**：生成的文本是否具有创造性、流畅性、多样性和引人入胜的表达。这包括遣词造句的优美度、叙述的连贯性以及是否能提供新颖的视角。
-#         * **问答模型 (RoBERTa-SQuAD2)**：由于是抽取式模型，其“创新表现力”主要体现在抽取答案的精确性和简洁性上，不涉及生成新的文本。
-#     * **理由**: 衡量生成内容的质量和吸引力，区分模型是否仅能“复述”已知信息，还是能真正“创造”有价值的内容。对于抽取模型，则关注其在限定范围内的表现。
-
-# 3.  **G: Generalization (泛化性)**：
-#     * **定义**:
-#         * **文本生成模型 (GPT2-Large)**：模型在面对不同类型、不同长度、不同风格的提示词（包括是否提供上下文）时，是否都能稳定地生成高质量且符合预期的文本。
-#         * **问答模型 (RoBERTa-SQuAD2)**：模型在面对不同领域、不同长度、不同复杂度的上下文和问题时，是否都能准确地从其中抽取答案。
-#     * **理由**: 评估模型在多样化场景下的鲁棒性和适用性。
-
-# 4.  **E: Efficiency (效率性)**：
-#     * **定义**: 模型从接收输入到生成完整输出所需的时间，以及在给定计算资源下，生成高质量结果所需的资源消耗（如 CPU/GPU 利用率、内存占用）。
-#     * **理由**: 在实际应用中，模型的推理速度和资源效率是关键考量因素，尤其对于需要实时响应的场景。
-
-# ---
-
-# ## 4. 结果与分析
-
-# ### 4.1 多条统一输入样例输出结果表格
-
-# 我们使用以下统一输入样例对模型进行了测试：
-
-# | 输入样例 (问题/提示词)                       | 上下文 (Context)                                                                                                                                                                                                                                                                                                            | GPT2-Large (文本生成) 输出 (请实际运行后填充) | RoBERTa-SQuAD2 (问答) 输出 (请实际运行后填充) |
-# | :----------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------- | :------------------------------------------ |
-# | "请写一段关于人工智能未来的短文。"           | "" (无上下文，主要测试文本生成)                                                                                                                                                                                                                                                                             | [实际运行后填充]                              | 问答模型需要提供上下文才能回答问题。        |
-# | "描写一段夏日午后的场景，要包含蝉鸣和微风。" | "" (无上下文，主要测试文本生成)                                                                                                                                                                                                                                                                             | [实际运行后填充]                              | 问答模型需要提供上下文才能回答问题。        |
-# | "关于地球核心的温度大约是多少？"             | "地球核心的温度非常高，估计在5200摄氏度（9392华氏度）到6200摄氏度（11192华氏度）之间，与太阳表面的温度相近。核心主要由铁和镍组成。"                                                                                                                                                                                          | [实际运行后填充]                              | [实际运行后填充]                            |
-# | "埃菲尔铁塔的高度是多少米？"                 | "埃菲尔铁塔是法国巴黎的标志性建筑，于1889年建成，以其设计师古斯塔夫·埃菲尔的名字命名。最初高度为312米，包括天线在内，现在高度约为330米。"                                                                                                                                                                                     | [实际运行后填充]                              | [实际运行后填充]                            |
-# | "推荐3个环保的生活小习惯。"                   | "" (无上下文，主要测试文本生成)                                                                                                                                                                                                                                                                             | [实际运行后填充]                              | 问答模型需要提供上下文才能回答问题。        |
-
-# *(请根据你们实际测试结果填充表格)*
-
-# ### 4.2 雷达图展示维度评分
-
-# ![GRACE 评估雷达图](https://your-space-link/file/path/to/grace_radar_chart.png)
-# *(请将此处的图片链接替换为你实际生成并上传的雷达图链接，例如：`/file/main/grace_radar_chart.png`)*
-
-# ### 4.3 分析每个模型的优劣势
-
-# **模型 1 (GPT2-Large)**：
-# * **优势**:
-#     * **创新表现力 (A)**：生成的文本非常流畅、自然，具有较强的连贯性和创造性，能够进行开放式的生成任务。
-#     * **泛化性 (G)**：作为通用文本生成模型，能够处理各种类型的提示词，并尝试续写或生成相关内容，即便没有明确上下文也能工作。
-# * **劣势**:
-#     * **相关性 (R)**：在需要精确回答特定事实性问题时，它可能会“胡说八八道”（hallucinate），生成看似合理但实际不准确的信息，不如问答模型直接从文本中抽取答案来得准确。
-#     * **效率性 (E)**：相较于基础的问答模型，GPT2-Large 的模型规模更大，推理速度相对较慢，对计算资源（如 GPU 内存）的需求较高。
-
-# **模型 2 (RoBERTa-SQuAD2)**：
-# * **优势**:
-#     * **相关性 (R)**：在给定有效上下文的前提下，它能极其精确地从文本中抽取答案，确保了高度的相关性和准确性。
-#     * **效率性 (E)**：模型规模相对较小，推理速度快，资源消耗低，非常适合需要快速响应的问答应用。
-# * **劣势**:
-#     * **创新表现力 (A)**：作为一个抽取式模型，它没有“创造性”，只能提取现有信息，无法进行开放式生成或内容创作。
-#     * **泛化性 (G)**：其任务范围非常局限，只能进行问答任务，且高度依赖于提供的上下文；无法进行自由文本生成或理解无上下文的问题。
-
-# ---
-
-# ## 5. 合作与反思
-
-# ### 成员 1: [你的名字，例如：孙世纪]
-
-# * **各自负责内容**:
-#     * 我主要负责了 **GPT2-Large 模型的集成**，包括在 `app.py` 中加载模型、编写其文本生成推理逻辑，并确保其在 Gradio 界面中正常工作。
-#     * 我参与了 **“Arena”选项卡的用户界面布局设计**，确保两个模型的输入和输出能够清晰地并排展示。
-#     * 在报告撰写方面，我主要负责了**“1. 模型及类别选择”部分**的初步内容，并参与了 GRACE 评估数据的收集。
-
-# * **学到的内容**:
-#     * 深入理解了 Hugging Face `transformers` 库中 `pipeline` 的灵活运用，特别是如何根据不同任务类型（如 `text-generation`）配置模型。
-#     * 学会了在 Gradio 中构建多输入多输出的复杂界面，并通过 `gr.Blocks` 和 `gr.Row` 进行有效的布局管理。
-#     * 对通用文本生成模型和抽取式问答模型的工作原理和应用场景有了更具体的认识。
-
-# * **遇到的困难**:
-#     * **困难 1**: GPT2-Large 模型在免费的 Hugging Face Space 上加载速度较慢，有时甚至因为资源限制导致启动失败。
-#     * **解决尝试**: 我在代码中增加了更详细的模型加载成功/失败打印信息，并提醒用户注意等待时间。在几次测试后，发现偶尔会出现资源不足的情况，需要等待 Space 自动重启。
-#     * **困难 2**: 报告中 Mermaids 流程图的语法调试。
-#     * **解决尝试**: 我查阅了 Mermaid 的官方文档，并在本地编辑器中进行预览，确保流程图语法正确无误。
-
-# ### 2: [你的组员的名字，例如：牛正武]
-
-# * **各自负责内容**:
-#     * 我主要负责了 **deepset/roberta-base-squad2 问答模型的集成**，包括加载模型、编写其问答推理逻辑，并处理上下文输入。
-#     * 我负责了 **“LLM Benchmark”选项卡中 GRACE 雷达图的实现和数据可视化**，确保图表能够准确反映评估结果。
-#     * 在报告撰写方面，我主要负责了**“2. 系统实现细节”、“3. GRACE 评估维度定义”以及“4. 结果与分析”部分**。
-
-# * **学到的内容**:
-#     * 掌握了如何在 Gradio 应用中使用 `plotly.express` 生成复杂的可视化图表，并将其嵌入到 Gradio 界面中。
-#     * 深入理解了问答模型的工作机制，特别是它对“问题”和“上下文”的严格依赖关系。
-#     * 锻炼了数据分析和可视化的能力，通过量化评估来比较不同模型的性能。
-
-# * **遇到的困难**:
-#     * **困难 1**: 最初尝试使用 `QuantFactory/Apollo2-7B-GGUF` 模型时，发现其与 `pipeline` 的兼容性问题。
-#     * **解决尝试**: 与组员讨论后，决定替换为一个更易于在标准 `transformers.pipeline` 环境下运行的文本生成模型（如 GPT2-Large），以确保项目能按时完成并成功运行。
-#     * **困难 2**: 在 GRACE 评估中，对不同类型的模型（生成和抽取）在某些维度（如“Artistry”）上进行比较时，很难找到统一的评估标准。
-#     * **解决尝试**: 我们通过详细定义每个维度在不同模型类型下的具体含义和侧重点，并进行多次交叉评估，最终达成了一致的评分。例如，“Artistry”对于问答模型主要体现在答案的精确和简洁，而非创造性。
-
-# ---
-# """
-
-#     return gr.Markdown(report_content_markdown)
 
 
 # --- Gradio 应用界面定义 ---