ThetreStageAI: Multi-View Retrieval-Augmented Generation for Structured Bengali Theatre Production Planning

What it claims

ThetreStageAI generates a full Bengali stage plan as one validated JSON object: characters, scenes, dialogue, stage directions, actor blocking, lighting cues and optional sound cues. Its central design choice is retrieving scene, blocking and lighting examples from three separate Qdrant collections instead of one mixed pool. The authors argue that a scene can match the story yet be a poor example for movement or lighting. The paper appears at IEEE iCOSTE 2026 (November 2026, Cox's Bazar). It reports only prototype diagnostics, not retrieval-quality or creative-quality scores.

How it works

The production brief lists theme, genre, language, actor count, target duration, stage size, available fixtures, scene time and desired emotion. It is turned into view-specific queries. Full multi-view mode returns 3 scene, 2 blocking and 2 lighting references. Duplicate sources within a view are removed, and each hit is logged with source ID, rank, score and view type. The single-combined baseline is capped at seven documents to match this budget. Six modes exist in total: no RAG, scene-only, scene+blocking, scene+lighting, single-combined and full multi-view.

The stage is split into nine zones (USL, USC, USR, CSL, CSC, CSR, DSL, DSC, DSR). A blocking cue records actor, start zone, destination zone, action and trigger. A lighting cue records ID, trigger, fixture, focus zone, RGB, intensity and fade duration. Dialogue, movement and lighting can share one event ID as their trigger.

flowchart TD
  B[Production brief] --> S[Scene view k=3]
  B --> K[Blocking view k=2]
  B --> L[Lighting view k=2]
  S --> C[Bounded context]
  K --> C
  L --> C
  C --> G[Gemini JSON]
  G --> V1{Pydantic structural check}
  V1 -->|pass| V2{Brief constraint check}
  V1 -->|fail| R[One repair request]
  V2 -->|pass| A[Accept]
  V2 -->|fail| R
  R --> V3{Recheck}
  V3 -->|pass| A
  V3 -->|fail| X[Reject]

The structural check verifies required fields, zone values, numeric ranges, unique IDs, known speakers, and that cue triggers point to real events in the same scene. The brief check covers actor count, genre, theme alignment, completeness and allowed fixtures. The repair request includes the validation errors and the rejected output, which is treated as untrusted. Gemini sits behind a provider interface.

Evidence

The corpus has 500 records across 15 themes, 5 genres and 20 character names. It holds 3,000 dialogue lines and 1,000 cues each for blocking, lighting and sound. All 1,000 lighting cues pass the RGB, intensity and fade checks. However, the 3,000 dialogue lines contain only 39 distinct strings, a 1.3% unique ratio. The authors attribute this to template-based synthetic construction. Mean search-text length is 719.3 characters for scene documents, 514.0 for blocking and 475.4 for lighting.

An initial seven-run log had five valid outputs, two invalid outputs, a median generation time of 29.95 s and zero repair attempts. A paired comparison on 12 fixed briefs (single-combined vs. full multi-view, same model, settings and budget) follows. Its results are cut off in the fetched text.

How to use it

The backend uses Django, Pydantic, google-genai, sentence-transformers and qdrant-client, with local Qdrant storage. Each run logs model settings, RAG mode, retrieval trace, validation state, repair count, raw and accepted output, and latency. The page gives no install commands, licence or repository URL.

Limits

No Precision@k, Recall@k, MRR or nDCG is reported, because the dataset has no relevance labels. Creative quality, including dialogue naturalness and stageability, has no human evaluation. The system was not deployed in a real theatre and does not drive DMX hardware. The corpus is a small synthetic test set that the authors say does not represent Bengali theatre writing. No energy savings were measured, despite the sustainability framing.