Pith. sign in

REVIEW 3 major objections 4 minor 29 references

MedGame transforms static clinical case reports into executable storytelling games, and task-specific fine-tuning lets open-source LLMs approach commercial quality on the two core generation tasks.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-01 07:01 UTC pith:CCCITZZK

load-bearing objection Solid new benchmark and system for LLM-driven clinical case gamification; content-quality claims need stronger human validation before the fine-tuning results are taken at face value. the 3 major comments →

arxiv 2607.21570 v1 pith:CCCITZZK submitted 2026-07-23 cs.CL cs.HC

MedGame: Storytelling Gamification Empowered by Large Language Models for Medical Education

Qian Wu , Xinrong Zhou , Zizhan Ma , Kai Chen , Zheyao Gao , Xun Lin , Hongqiu Wu , Longfei Gou
show 3 more authors
Yixiao Liu Ann Sin Nga Lau Qi Dou
This is my paper
classification cs.CL cs.HC
keywords medical educationstorytelling gameslarge language modelsnarrative generationmultimodal orchestrationcase-based learningfine-tuninggamification
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

This paper is trying to establish that large language models can convert static clinical case reports into structured, executable storytelling games for medical education, and that the conversion is best done as two separate generation tasks. It introduces MedGame, a dual-engine framework: a Medical Narrative Designer builds a case-grounded storyline with acts, scenes, and decision nodes, and a Story Director turns that storyline into a dependency-aware multimodal execution plan rendered by an interactive platform. The paper reports that fine-tuning open-source models on a few thousand reference trajectories substantially improves their output quality and narrows the gap with commercial models, and that medical students perceive the multimodal game as more engaging and useful than text-only cases. If correct, this offers a scalable, low-cost way to turn existing case libraries into active reasoning practice.

Core claim

The paper's central claim is that case-to-game transformation can be factorized into two tractable generation tasks rather than one free-form request to 'write a game.' The Medical Narrative Designer produces a hierarchical Clinical Storyline — Acts, Scenes, and Decision Nodes — that preserves the factual trajectory of the source case while adding learner-facing choices and feedback. The Story Director then maps that storyline into a directed acyclic graph of multimodal generation primitives (image, audio, video) with explicit identity and scene dependencies, so the same patient and location remain consistent across the rendered game. The paper provides evidence that task-specific fine-tunin

What carries the argument

The load-bearing object is the Clinical Storyline, a hierarchical, machine-readable structure built from Acts (macro-stages), Scenes (clinical steps), and Decision Nodes (learner-facing checkpoints). The key move is to make this structure the interface between two LLM-driven engines: the Medical Narrative Designer, which generates it from a patient summary under fidelity, pedagogical, and structural constraints, and the Story Director, which consumes it and emits a directed acyclic graph of multimodal generation tasks with dependency placeholders. This separation decouples clinical narrative ideation from technical orchestration, and the graph's dependency propagation is what preserves chara

Load-bearing premise

The load-bearing premise is that LLM-as-a-judge scores on 1,000 test cases genuinely measure clinical accuracy and educational quality; human agreement is strong for narrative generation but only moderate for story direction, and the reference trajectories used for fine-tuning were themselves produced by a commercial model without independent medical verification.

What would settle it

A blinded review in which independent medical experts score a random sample of 200 generated storylines and orchestration plans using the paper's own rubrics; if their scores fail to correlate with the LLM judge's scores (roughly r < 0.5 for story direction or r < 0.7 for narrative generation), the benchmark's quality claims collapse. A randomized controlled trial comparing knowledge retention in students who play the multimodal game versus those who read the static case could settle whether the engagement advantage translates into learning gains.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • Existing static case libraries can be repurposed into interactive, decision-centered training without human actors, at a fraction of the cost of standardized patient programs.
  • A few thousand reference trajectories are enough to make open-source LLMs structurally reliable at both narrative generation and story direction, so institutions can run the pipeline on local hardware.
  • Medical accuracy remains the hard part: even the strongest models score around 7/10 on clinical accuracy metrics, so expert review is still required before generated content reaches students.
  • The Story Director's dependency-aware graph makes identity-preserving, causally coherent multimodal rendering feasible, which the paper links to higher perceived engagement and presence in learners.
  • The benchmark and evaluation protocol give the community a reusable way to measure structured educational storylines, beyond single-turn medical question answering.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Inference: The same dual-engine factorization — narrative design separate from technical orchestration — could transfer to other high-stakes training domains, such as law, aviation, or emergency response, where cases exist as static text but reasoning must be practiced sequentially.
  • Inference: Because the paper's story-direction quality scores rely on an LLM judge with only moderate human agreement (r=0.61), orchestration-quality claims should be treated as approximate until larger human validation is run.
  • Inference: A testable extension is to randomize learners across linear versus branching versions of the same case to see whether the branching extension the paper outlines in an appendix improves reasoning outcomes.
  • Inference: The logical next step, which the authors explicitly leave open, is a larger longitudinal study measuring knowledge retention and clinical reasoning transfer rather than perceived engagement.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. This paper introduces MedGame, a dual-engine framework that turns static clinical case summaries into structured, executable storytelling games. A Medical Narrative Designer generates a hierarchical clinical storyline (Acts, Scenes, Decision Nodes), and a Story Director converts that storyline into a directed acyclic graph of multimodal generation tasks. The authors release MedGame Bench, built from 5,000 PMC-Patients cases, with rule-based structural validation and GPT-5.2 LLM-as-a-judge scoring for content-oriented indicators. Experiments compare commercial and open-source LLMs, and LoRA fine-tuned open-source models trained on Gemini-3-Pro reference trajectories. The reported results show that fine-tuning substantially improves open-source models on structural validity and on several content metrics, narrowing the gap with commercial models. A small learner-perception study and expert-revision analyses provide additional evidence. The central quantitative claim is that task-specific fine-tuning improves open-source LLMs on both MedGame Bench tasks.

Significance. The framework and benchmark address a real gap in LLM-based medical education: moving from fragmented QA interactions to whole-case, decision-centered learning trajectories. Concrete strengths include the released interactive platform, machine-checked Pydantic schemas, rule-based validation pipelines, a balanced 5,000-case benchmark, and extensive appendices. The structural validity results are convincing because they rely on automated checks rather than subjective scoring. The related-case overlap analysis is a responsible check on a common benchmark artifact. However, the content-oriented claims that carry the headline conclusion — fine-tuning improves medical accuracy and educational quality — depend on an LLM judge validated on only 50 cases per task, with per-indicator correlations as low as r=0.48. The reference trajectories produced by Gemini-3-Pro without independent medical verification further complicate interpretation. If the judge validity is strengthened or the claims are scoped to structural and stylistic improvements, the contribution is solid; as it stands, the central quantitative claim is conditional on a measurement whose validity is weakest in exactly the indica

major comments (3)
  1. [§6.4 / Fig. 18 / Tables 2–3] The LLM-as-a-judge validation is based on only 50 cases per task. For Story Direction, the average human correlation is r=0.61, and the API Type Selection indicator — which is central to the fine-tuning gains in Table 3 (e.g., Qwen3.5-27B* ATS 9.02 vs. 7.01) — has r=0.48. With n=50, the 95% CI for r=0.48 spans roughly 0.23–0.67, so the judge's ranking of models is nearly indistinguishable from noise for that indicator. The headline claim that fine-tuning 'substantially improves' content quality and narrows the gap with commercial models rests on these scores. Please either provide a much larger human validation (per indicator, with inter-rater reliability) or explicitly downgrade the content-level conclusions to exploratory.
  2. [§6.3 / Appendix C.2] Fine-tuned models are trained on Gemini-3-Pro reference trajectories, and content quality is subsequently scored by GPT-5.2 without an independent medical gold standard. Appendix C.2 states that these reference trajectories 'are not treated as direct evidence of clinical correctness.' Because the judge may reward the formatting and narrative conventions of the reference model, the observed content gains (e.g., CSU 5.41→8.50 for Qwen3-32B*) may reflect distillation of Gemini-3-Pro style rather than improved clinical or pedagogical quality. Structural metrics are rule-based and robust to this concern, but CDA/ODA/MEA/QDQ/FQ are not. To support the interpretation, the authors should compare fine-tuned outputs against base outputs with human experts on content dimensions, or use independent expert-constructed references.
  3. [§5 / Appendix A.3 / Appendix D.3] The Story Direction track evaluates only image-generation orchestration: the three API types in Appendix D.3 are character_gen, fusion, and modification, and all reported task-reasonability indicators (RA/ATS/PC) concern image tasks. The framework description in §4.2 and the toolset in Appendix A.3, however, include audio and video generation (f_aud, f_vid). No benchmark metric or experiment covers audio/video task planning or dependency modeling for those modalities. Thus the claim of validating 'dependency-aware multimodal orchestration plans' is overstated; MedGame Bench's Story Direction track should be described as visual orchestration only, or the benchmark should be extended to cover the other modalities.
minor comments (4)
  1. [§3 / Appendix B] Eq. (1) defines a linear storyline, which is an explicit design choice. Appendix B's branching extension is presented only as an inference-time construction and is not evaluated. Please state in the main text that the benchmark and experiments cover linear storylines only.
  2. [§6.4 / Appendix D.4] The same three medical Ph.D. evaluators who validated the LLM judge also performed the expert-revision study. Please clarify whether the revision evaluators were blinded to model identity and whether they had access to their own earlier scores for the same cases.
  3. [References] Reference formatting contains errors: 'LujieZheng LujieZheng' is duplicated, several entries end with '1 others', and one author name appears as 'Co¸ skun'. Please clean up the bibliography.
  4. [§6.5 / Fig. 4] The learner-perception study uses eight students and a one-sided paired Wilcoxon test. This is acceptable for a pilot, but the conclusion should more explicitly emphasize the exploratory nature, as the Limitations section already does for long-term outcomes.

Circularity Check

0 steps flagged

No significant circularity: the benchmark's fine-tuned models are evaluated on held-out cases with rule-based checks and a separately human-validated LLM judge; self-citations are not load-bearing.

full rationale

MedGame's central derivation is an empirical construction/evaluation loop, not a mathematical derivation. The reference trajectories are produced by Gemini-3-Pro (Appendix C.2), and open-source models are fine-tuned on them, so the 'gap narrowing' relative to Gemini-3-Pro is partly a distillation effect. However, the paper explicitly states that 'these reference trajectories are not treated as direct evidence of clinical correctness' and that content indicators are 'assessed by separate evaluation rubrics rather than by exact matching to the reference trajectories' (Appendix C.2). Structure validation is rule-based (Section 5, Appendix D.2.1/D.3.1), content scores come from GPT-5.2 with human correlation reported (r=0.81 for Medical Narrative Generation, r=0.61 for Story Direction, Appendix D.4), and RQ4 is an independent paired student perception study. There is no equation in which a predicted quantity is identical to a fitted input, and no load-bearing self-citation: the cited prior works by the authors (Wu et al. 2025b/c; Ma et al. 2026; Wang et al. 2026) are contextual and do not supply a uniqueness theorem or an ansatz that the paper treats as external. The moderate Story Direction human-judge correlation, the lack of independent medical verification of reference trajectories, and the expert-marked 8.3–8.9 revision regions per draft (Appendix E.3) are validity/robustness limitations, which the paper itself acknowledges, rather than circularity by construction.

Axiom & Free-Parameter Ledger

0 free parameters · 4 axioms · 0 invented entities

No fitted constants or new physical entities are introduced; the framework's new constructs are implemented software artifacts (dual-engine architecture, schema, DAG, platform) rather than unobserved entities. The central claims rest on assumptions about the benchmark substrate: linear case flattening, synthetic references as training/eval targets, LLM judge as quality oracle, and PMC-Patients as representative source.

axioms (4)
  • ad hoc to paper Linear storyline flattening: a clinical case can be represented as a single sequence of decision-gated states (Eq. 1).
    Section 3 states this is motivated by source format, not by clinical reasoning being linear; branching is only sketched in Appendix B.
  • domain assumption Gemini-3-Pro reference trajectories provide valid targets for fine-tuning and format-compatible references.
    Section C.2; the paper itself says they are not treated as direct evidence of clinical correctness.
  • domain assumption GPT-5.2 judge scores are a valid proxy for expert quality on all benchmark dimensions.
    Appendix D.4 reports human correlations r=0.81 (n=50) for narrative and r=0.61 (n=50) for direction; moderate agreement for the latter.
  • domain assumption PMC-Patients summaries are representative clinical cases for educational gamification.
    Section 5; 5,000 cases balanced across eight specialties, but summaries are case-report-derived and not necessarily representative of all clinical education material.

pith-pipeline@v1.3.0-alltime-deepseek · 36201 in / 11980 out tokens · 120398 ms · 2026-08-01T07:01:36.916995+00:00 · methodology

0 comments
read the original abstract

Large Language Models (LLMs) show promise for medical education, but most existing systems focus on localized interactions such as question answering or single-turn feedback, rather than organizing an entire clinical case into a decision-centered learning trajectory. We introduce \textit{MedGame}, a framework that transforms static clinical cases into structured, executable storytelling games. MedGame uses a dual-engine design: a Medical Narrative Designer synthesizes case-grounded clinical storylines with states and decision nodes, while a Story Director converts them into dependency-aware multimodal orchestration plans rendered by our released interactive platform. We construct MedGame Bench, a 5,000-case benchmark and evaluation protocol for Medical Narrative Generation and Story Direction. Experiments show that task-specific fine-tuning substantially improves open-source LLMs on MedGame Bench and narrows the gap with commercial models. A pilot student study further shows that learners perceive MedGame as more engaging and useful than text-only alternatives.

Figures

Figures reproduced from arXiv: 2607.21570 by Ann Sin Nga Lau, Hongqiu Wu, Kai Chen, Longfei Gou, Qian Wu, Qi Dou, Xinrong Zhou, Xun Lin, Yixiao Liu, Zheyao Gao, Zizhan Ma.

Figure 1
Figure 1. Figure 1: MedGame at a glance. Given a static clinical [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Overview of the MedGame framework architecture. MedGame follows a two-phase generative workflow. In the script synthesis phase (Steps ①–②), the Medical Narrative Designer transforms raw patient summaries and persistent narrative elements into a structured Clinical Storyline. In the orchestration and execution phase (Steps ③–⑥), the Story Director decomposes the storyline into multimodal generation primitiv… view at source ↗
Figure 3
Figure 3. Figure 3: Overview of MedGame Bench. The bench￾mark contains 5,000 PMC-Patients cases split into 4,000 training and 1,000 test cases, balanced across eight med￾ical specialties with 625 cases each. Among the test cases, 409 have at least one high-similarity patient vari￾ant in the training set; here, high-similarity variants refer to PMC-Patients relations with score 2, corresponding to patient summaries from the sa… view at source ↗
Figure 4
Figure 4. Figure 4: Medical student perception across three pre [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Hierarchical structure of the Clinical Story. The tree consists of five levels: the root Clinical_Story_Tree contains multiple Acts (chap￾ters), each Act contains multiple Scenes (stages), each Scene contains scene_items (interaction elements), and each item contains Options for user interaction. Level 0: Clinical_Story_Tree. The root node defines the overall narrative and specifies the target_students fie… view at source ↗
Figure 6
Figure 6. Figure 6: Clinical locations (L) used in MedGame. Each row shows two perspectives: facing-patient/staff (left) and facing-doctor (right). Descriptions include Visual appearance and Narrative purpose [PITH_FULL_IMAGE:figures/full_fig_p014_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Visual generation tool fvis examples from Case 5915692-2. (a) CharacterGen creates patient portraits from text. (b-c) Fusion composes characters into scenes. (d) Modification updates attributes while preserving identity [PITH_FULL_IMAGE:figures/full_fig_p017_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Complete prompt Φdes for Medical Narrative Designer [PITH_FULL_IMAGE:figures/full_fig_p019_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Complete prompt Φdir for Story Director [PITH_FULL_IMAGE:figures/full_fig_p020_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Act-level branching as prefix-conditioned [PITH_FULL_IMAGE:figures/full_fig_p021_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: summarizes the statistical properties of the generated reference artifacts, including the distributions of narrative structure (acts, scenes, and questions) and orchestration complexity (task counts, dependency counts, and graph depth). C.4 Medical Narrative Designer Reference Corpus The Medical Narrative Designer reference corpus is used for fine-tuning models to transform patient summaries into structur… view at source ↗
Figure 12
Figure 12. Figure 12: Complete LLM-as-a-Judge prompt for Dimension 1: Story Adaptation Quality. [PITH_FULL_IMAGE:figures/full_fig_p026_12.png] view at source ↗
Figure 13
Figure 13. Figure 13: Complete LLM-as-a-Judge prompt for Dimension 2: Medical Accuracy. [PITH_FULL_IMAGE:figures/full_fig_p027_13.png] view at source ↗
Figure 14
Figure 14. Figure 14: Complete LLM-as-a-Judge prompt for Dimension 3: Educational Value. [PITH_FULL_IMAGE:figures/full_fig_p028_14.png] view at source ↗
Figure 15
Figure 15. Figure 15: Complete LLM-as-a-Judge prompt for Story Direction Dimension 1: Resource Assignment. [PITH_FULL_IMAGE:figures/full_fig_p031_15.png] view at source ↗
Figure 16
Figure 16. Figure 16: Complete LLM-as-a-Judge prompt for Story Direction Dimension 2: API Type Selection. [PITH_FULL_IMAGE:figures/full_fig_p032_16.png] view at source ↗
Figure 17
Figure 17. Figure 17: Complete LLM-as-a-Judge prompt for Story Direction Dimension 3: Parameter Content Quality. [PITH_FULL_IMAGE:figures/full_fig_p033_17.png] view at source ↗
Figure 18
Figure 18. Figure 18: Pearson correlation between GPT-5.2 and hu [PITH_FULL_IMAGE:figures/full_fig_p034_18.png] view at source ↗
Figure 19
Figure 19. Figure 19: Radar chart comparing key models on Medi [PITH_FULL_IMAGE:figures/full_fig_p034_19.png] view at source ↗
Figure 20
Figure 20. Figure 20: Game flow state machine. The platform cy [PITH_FULL_IMAGE:figures/full_fig_p036_20.png] view at source ↗
Figure 21
Figure 21. Figure 21: Medical staff personas (P) used in MedGame. Each role has multiple visual variants to promote inclusive representation. The Doctor (Player) is represented as a bear character to create an approachable learning atmosphere [PITH_FULL_IMAGE:figures/full_fig_p037_21.png] view at source ↗
Figure 22
Figure 22. Figure 22: Platform interface showcase. Top row: (Left) Film mode with patient dialogue and progressive subtitles; (Center) Interactive mode with explorable options and Doctor Thinking background; (Right) Film mode in radiology room with specialist dialogue. Bottom row: (Left) Interactive dialogue popup triggered by option selection; (Center) Text mode with typewriter-style narrative display; (Right) End roleplay tr… view at source ↗
Figure 23
Figure 23. Figure 23: Representative MedGame stills rendered for clinical simulation scenes, including patient encounters, [PITH_FULL_IMAGE:figures/full_fig_p038_23.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

29 extracted references · 1 linked inside Pith

  1. [1]

    por- trait

    character_gen— Generate character portrait with pure white background. Use Case:Create patient images for the story (first appearance). Parameters: age (int), ethnicity (string), gender (string), appearance (string), expression (string), clothing (string),shot_type (string, default: “por- trait”)

  2. [2]

    Use Case:Place characters into clinical environ- ments

    fusion— Fuse one or multiple person images into a scene at specified positions. Use Case:Place characters into clinical environ- ments. Supports single-person and multi-person scenarios. Parameters: person_image_path (string or list), scene_image_path (string), location_description (string or list), posture_expression(string or list). Note:For multi-perso...

  3. [3]

    I’ve been experiencing these symptoms for weeks now

    modification— Modify the state of person(s) in an existing image. Use Case:Adjust expression, posture, or clothing while preserving identity. Essential for reflecting narrative progression. Modifiable Attributes:Facial expression, body posture, action state, clothing style, interaction with objects. Parameters: input_image_path (string, sup- ports [task_X...

  4. [4]

    single_choice

    Executes tasks in order, resolving placeholders to actual file paths as upstream tasks complete A.6.3 Dependency Graph Metrics For quality assurance, we compute several metrics on the generated dependency graphs: • Root Tasks: Tasks with no dependencies (typ- ically Act 1 Character_Profile and initial scene Instruction Template:Φ des # Objective: We are d...

  5. [5]

    Stories” indicates the number of storylines featuring each character type, and “Total Usage

    Merge A1:k with each valid A(m) k+1 to obtain branch- specific storyline variants. This construction should be interpreted as an inference-time extension rather than as a claim that the model automatically discovers a complete branching policy. The branch states may be manu- ally specified or semi-automatically proposed and should be medically reviewed, e...

    2023

  6. [6]

    Audio: The synthesized speech from faud, which drives lip movements

  7. [7]

    First Frame: A static character image (from fvis), defining the visual appearance

  8. [8]

    sitting hunched over, clutching abdomen

    Text Description: A natural language prompt describing the character’s state, posture, and expression. Description Generation.An LLM generates video descriptions by analyzing: • Character States: Whether each character in frame istalking(audio contains their dialogue) orlistening(only appears visually). • Emotion Tags: Extracted from the dialogue to infor...

    2026

  9. [9]

    Parses all [task_XXX_output] references to construct the dependency graph

  10. [10]

    Performs topological sorting to determine a valid execution order

  11. [11]

    Validates that no circular dependencies exist

  12. [13]

    Mouth closed

    modification: Modify the state of person(s) in an existing image (expression, posture, clothing, etc.). Can reference previous task outputs via [task_XXX_output]placeholder. # Task List There are{N}image generation tasks. Based on the plot, visual continuity, and dialogue characters, determine the appropriate API type and parameters for each task. {task_l...

  13. [14]

    Generate or select a shared Act prefix A1:k = ⟨A1, . . . , Ak⟩

  14. [15]

    , bM }, where each bm describes the clinical state entering the next Act

    Specify branch states Bk ={b 1, . . . , bM }, where each bm describes the clinical state entering the next Act

  15. [16]

    For each branch state bm, prompt the Medical Narra- tive Designer with Spat, A1:k, and bm to generate only A(m) k+1

  16. [17]

    Validate the generated successor Act against the Clini- cal Storyline schema

  17. [19]

    Character Profile Rules: • Act 1 Character_Profile: MUST usecharacter_gen(generate from scratch) • Act 2/3 Character_Profile: MUST usemodificationwithinput_image_pathreferencing previous Act’s profile • The modification chain should be: Act 1→Act 2→Act 3 (not Act 1→Act 3 directly)

  18. [20]

    First-Person Perspective Rules: • Doctor_Thinking scenes: Only doctor in frame, camera looks at doctor • Dialogue scenes: Doctor NEVER appears with other characters; use first-person view showing others

  19. [21]

    Multi-Person Scene Rules: • 2+ characters in frame: Must usefusionormodificationwith LIST parameters • Single character: Can usefusion(single) ormodification

  20. [22]

    api_type_selection

    Fusion vs Modification Strategy: • Story/Plot images: Should prioritizefusionto maintain image quality • Avoid long chains ofmodification(causes quality degradation) •modificationshould only be used when plot requires subtle changes to existing image Scoring Criteria: • 10: Perfect - All API type selections strictly follow the rules • 9: Excellent - Nearl...

  21. [23]

    after”, “again

    description(character_gen, fusion): • Should accurately describe the visual content of the image • Should only contain visual elements, NOT plot words like “after”, “again”, “returned” • Should be concise and clear

  22. [24]

    mouth closed

    posture_expression(fusion): • Should match the emotional context of the plot • Serious scene→serious/concerned expression (NOT smiling) • Should explicitly state posture: Sitting/Standing/Leaning, etc. • Note: Whether “mouth closed” is included does NOT affect scoring

  23. [25]

    main_position

    location_description(fusion): • Should be specific position descriptions • WRONG: “main_position”, “secondary_position”, “left_side” • CORRECT: “standing in the center of the room”, “sitting on the hospital bed”

  24. [26]

    patient”, “doctor

    modification_target(modification): • Should describe visual features, NOT identity • WRONG: “patient”, “doctor”, “the nurse” • CORRECT: “the elderly man lying in bed”, “the young woman in hospital gown”

  25. [27]

    modification_details(modification): • Should describe specific changes needed • For Character_Profile (Act 2/3): Should reflect disease progression (e.g., more tired, paler skin, changed expression)

  26. [28]

    standing and thinking

    Doctor_Thinking Diversity: • Doctor’s postures should be varied across different thinking scenes • NOT always the same “standing and thinking” • Examples: arms crossed, hand on chin, looking at report, leaning forward, etc

  27. [29]

    parameter_content

    character_gen parameters(for Act 1 Character_Profile only): • expression: Should match the patient’s initial emotional state • appearance: Should establish the patient’s baseline look • clothing: Appropriate attire for initial hospital visit • All parameters should be specific and visual, not generic placeholders Scoring Criteria: • 10: Perfect - All para...

    2023

  28. [2023]

    chapter-level

    Judging llm-as-a-judge with mt-bench and chatbot arena.Advances in neural information pro- cessing systems, 36:46595–46623. Appendix Overview A Game Design Logic . . . . . . . 12 A.1 Clinical Story Structure. . . . 12 A.2 Details of Narrative Elements . 13 A.3 Details of Multimodal Toolset . 15 A.4 The Instruction used for Medical Narrative Design:Φ des ....

  29. [2025]

    InProceedings of the 2025 Con- ference on Empirical Methods in Natural Language Processing, pages 272–292

    From problem-solving to teaching problem- solving: Aligning llms with pedagogy using rein- forcement learning. InProceedings of the 2025 Con- ference on Empirical Methods in Natural Language Processing, pages 272–292. Zhuoyun Du, LujieZheng LujieZheng, Renjun Hu, Yuyang Xu, Xiawei Li, Ying Sun, Wei Chen, Jian Wu, Haolei Cai, and Haochao Ying. 2025. Llms c...

    Pith/arXiv arXiv 2025