Class Interpreter

Turn a saved lesson transcript into a concise summary that can be checked against the original passages. The prototype selects important passages with NLP and passes them to an AI API for a readable summary.

Repository: M2-King/class-interpret.

The existing project has a Python backend and browser interface for microphone/shared-tab audio capture, English transcription with faster-whisper, Chinese translation with Argos Translate, saved classroom records, editable entries, note export, and summaries. Selected source functions include transcribe, translate, fallback_summary, ask_deepseek, and make_summary. Recorded entries already have unique IDs and elapsed timestamps.

fallback_summary already filters words, counts frequencies, scores entries with a length adjustment, selects entries across chronological groups, and separately extracts task/deadline mentions. This logic is reusable; it should not be described as entirely new work. Its formatted output does not retain supporting entry IDs.

When local DeepSeek is available, make_summary sends the transcript directly through the Ollama API. Long transcripts are split into character blocks and their summaries are combined. If DeepSeek is unavailable or fails, the extractive fallback runs instead. These are alternative paths: the NLP-selected entries are not passed into the API summary. The current prompt requests a Chinese summary without supporting entry IDs; citation validation is absent. Frontend concept extraction is a display feature, not the API's input-selection stage.

The proposed notebook must connect the reusable selection logic to the API, preserve IDs in its inputs and outputs, validate citations, and add checked evaluation data. No Jupyter Notebook or dedicated evaluation dataset was found in the reviewed default-branch tree. Existing code uses local Ollama/DeepSeek; a hosted-provider route would require new adapter work. No model run or hardware feasibility was verified in this source review.

The handwritten vision includes API/transcription and summary improvements, classroom Q&A, lecturer/student assignment workflows, announcements, and calendars. This reference retains a narrower saved-transcript summary task. Transcription and translation already exist in the application; reusing them is optional for the notebook. Classroom Q&A remains future work, while assignment management, announcements, and calendars are excluded from this proposed assessed scope. Those exclusions are later scope choices, not claims that the original brainstorm omitted the features.

• Problem: students find it difficult to review a long transcript while preserving important concepts and tasks.
• Target user: a student reviewing one lesson.
• Input: a short saved transcript with passage IDs and, where available, timestamps.
• Output: a concise summary with supporting passage IDs, plus the selected passages for checking.
• Boundary: the system summarises the provided transcript. It cannot establish whether the transcript itself accurately captured the lecturer.

Study one deployed AI transcription/recap application, such as Microsoft Teams Intelligent Recap. Keep the case study focused on transcription and lesson/meeting review, matching our prototype's domain.

Compare manual review and note-taking with AI-assisted summaries. Examine accessibility, time-saving evidence, missed details, transcription errors, privacy, dependence on generated notes, and the energy/cost implications of local versus cloud processing. SDG 4, Quality Education, is a possible connection where the analysis explains learning access and support.

Primary starting point:

• Microsoft: Intelligent recap for Teams

Product documentation establishes functionality. Claims about improved learning or time saved still need credible supporting evidence.

Saved lesson transcript
    -> NLP tokenisation and word-frequency scoring
    -> Select important original passages
    -> Preserve task/deadline passages and their IDs
    -> Send selected passages to an AI API
    -> Generate a concise summary with passage references
    -> Display sources and save results

The API must consume the NLP-selected material. Merely placing an extractive summariser and a separate chatbot in one notebook does not demonstrate this integration.

Use about three short English lesson transcripts initially. Preserve existing entry IDs and timestamps when importing application records, or assign stable passage IDs to prepared transcripts. Manually mark key concepts, examples, and task statements. An English summary is a proposed simplification; the existing application generates Chinese summaries. Chinese translation already exists in the application and need not be rebuilt for the notebook.

1. Import saved entries or a prepared transcript and show its IDs and timestamps.
2. Adapt the existing fallback's word filtering, frequency counts, and length-adjusted scoring into explainable notebook functions.
3. Return selected original passages in chronological order with their IDs, rather than only the fallback's formatted text.
4. Adapt existing task/deadline detection and explicitly retain the relevant passages in the API input, including low-scoring passages; test omissions and the existing capped task list.
5. Connect the selected passages to one API route. Update the prompt to request the chosen output language, avoid unsupported additions, and cite supplied passage IDs.
6. Add response and reference-ID validation, display supporting passages beside the summary, and save outputs. Manually check citation support as well as ID existence.

Use one model/API route for the demonstration. Local Ollama/DeepSeek is the existing implementation and can be reused if the demonstration computer supports it. A hosted API is an alternative requiring a new adapter, credential setup, and failure handling; it is not an existing feature. Record dependencies, setup, and any costs. Do not assume local hardware or remote access has already been verified.

An API failure should produce a labelled failure or extractive-only fallback. A fallback does not prove that the complete two-technique pipeline succeeded.

For each transcript, create a manually checked list of key points and task statements. Measure key-point coverage, inspect factual consistency, verify that passage references support the summary, and record response time.

Test empty transcripts, repeated passages, unclear terms, a briefly stated deadline, no deadline mentioned, and an unavailable API. The model should not invent a deadline when none is present.

Compare NLP-only extraction, API summarisation of the full short transcript, and the integrated selection-plus-API approach. Compare coverage and errors as well as input length and processing time. Reduced input length is a measurable property; it is not automatically proof of better summaries.

Proposed success criterion: the summary preserves the agreed key points and tasks, gives checkable references, handles failures clearly, and runs reproducibly on the demonstration computer. Report actual outcomes rather than guaranteeing this target in advance.

Explain tokenisation, common-word filtering, scoring and length adjustment, selection order, special treatment of tasks, prompt construction, the API request/response, and evaluation. Explain how transcription mistakes can propagate into a summary.

The group should understand the API's purpose and general model behaviour without pretending to know its proprietary internals. Every part of our submitted notebook must remain explainable.

Do not include lecturer/student account systems, assignment submission, calendars, announcement scraping, or public deployment. Live transcription and lesson Q&A can be optional demonstrations or future work after the core is complete. Do not add Yinwei playback or news checking to this project.

This is the reference's preferred starting option because Python scoring, task detection, entry IDs, storage, and local API code already exist. The missing work is connecting selection to the API, retaining and validating supporting references, preparing the notebook and evaluation data, and evaluating summary faithfulness. This recommendation is a reuse-based planning judgement, not a measured superiority claim or the handwritten plan's ranking.