MeetingBot

Meetings generate a lot of talk and very little structure. Decisions, owners and deadlines end up buried in a transcript that nobody wants to read twice, and a general-purpose chatbot asked about the meeting will happily answer from guesswork rather than from what was actually said.

A full-stack application with a Flask API and a Next.js / TypeScript / Tailwind CSS frontend:

• Transcript and audio ingestion — paste text, or upload a recording that is transcribed with Whisper before analysis. Uploads go through secure file-handling checks.
• Meeting intelligence — a summary, action items (task, owner and deadline where they are clearly stated), confirmed decisions and detected participants.
• Ask MeetingBot — a retrieval-augmented chat that answers questions about the meeting from the transcript.
• Two execution paths — OpenAI-powered when a key is configured, with a local-model fallback when it isn’t.

For question answering, the transcript is chunked along speaker turns, embedded with a sentence-transformer model, and indexed in FAISS. Retrieved chunks are returned in their original document order so the context the model reads stays coherent.

The retrieved context and the question then go to OpenAI when available, or to a local extractive question-answering model otherwise. Summaries, action items and decisions follow the same pattern: OpenAI when configured, local models and deterministic conversational patterns when not. Long transcripts are processed in chunks and merged rather than truncated.

Evaluation surfaced a failure on a long transcript. MeetingBot answered a semantically direct question correctly, but failed a more generic question whose evidence sat deeper in the transcript.

The easy conclusion would have been “the model got it wrong”. The actual cause was retrieval and context coverage: similarity search ranked the direct question’s evidence highly, but the generic question didn’t match the relevant passage strongly enough, so the evidence never reached the model at all.

Development is evaluation-driven. The failure above followed a deliberate loop:

1. Discover — an evaluation question failed on a long transcript.
2. Reproduce — the failure was isolated and reproduced.
3. Diagnose — traced to retrieval/context coverage, not the language model.
4. Fix — the OpenAI path uses the full transcript when it fits the context budget, and similarity-ranked chunks plus their neighbours when it doesn’t.
5. Validate — the fix was verified against the evaluation and the test suite.

The suite currently stands at 79 passing tests and 2 expected-failure tests.