Nobody tells you how lonely a thesis can feel at 2 AM when your model is outputting nonsense and your deadline is three weeks away. This post is the honest account of my CSE 400 final year thesis — not the polished version in the paper, but the actual experience: the confusion, the dead ends, the moments of clarity, and what I'd do differently.

If you're a CS student about to start your own thesis, I hope this helps you feel less alone — and gives you a realistic map of what to expect.

The Starting Point: A Problem, Not a Solution

My thesis began not with an idea for a model, but with a problem I found genuinely interesting: how do you detect anomalous events in surveillance video when you can't collect examples of every possible anomaly? A robbery. An explosion. A sudden crowd dispersal. You can't anticipate all of them.

I started by reading papers. A lot of papers. The first month was almost entirely literature review — which felt frustrating because I wasn't "building" anything. But this phase was crucial. I needed to understand the landscape: what had been tried, what the benchmarks were, what the open problems were.

Advice for Students

Don't rush to code. Spend at least 3–4 weeks reading deeply in your area before writing a single line. Understanding the existing literature will save you from reinventing the wheel — and help you identify where a genuine contribution lies.

The First Dead End: Trying to Use Supervised Methods

My first instinct was to fine-tune an existing anomaly detection model on the UCF-Crime dataset. I spent two weeks getting the data pipeline working, the model loading correctly, and the training loop running. The results were... okay. 76% ROC-AUC. But it wasn't novel — this had been done before, and done better.

My supervisor, Prof. Dr. Md. Ashraful Alam, pushed back: "What's the new contribution here? Why would someone cite this?" It was the right question, and it stung. I had to go back to the drawing board.

The Pivot: Zero-Shot as the Core Idea

The pivot came from a conversation about CLIP. I had been reading about vision-language models and mentioned, almost offhandedly, that CLIP could potentially describe what's "normal" in a scene using text. My co-supervisor Md Tanzim Reza's response: "What if you used that to detect what's abnormal — without ever training on abnormal examples?"

That was the moment the thesis crystallized. Zero-shot anomaly detection. The model would learn only from normal video, and use semantic alignment via CLIP to understand context — so that when something unusual happened, it would be flagged as a deviation from the learned normal distribution.

Building the Architecture: Three Components, One Goal

The architecture I eventually settled on had three components working together:

  • TimeSformer for spatiotemporal feature extraction from video clips
  • DPC-RNN for predictive temporal modeling — learning to predict what comes next, so it can detect when something unexpected happens
  • CLIP for semantic scene context — aligning visual features with text descriptions of the scene type

Getting these three to work together was the hardest part of the project. Each component individually worked fine. But integration introduced subtle bugs — mismatched tensor shapes, gradient flow issues, inconsistent normalization between CLIP's preprocessing and TimeSformer's.

"The most time-consuming part of ML research is rarely the model idea — it's the implementation details that textbooks don't mention."

The Training Nightmare: Google Cloud and GPU Bills

Training TimeSformer on the UCF-Crime dataset required a GPU with at least 24GB VRAM. My laptop didn't have that. Neither did my university's lab machines (they were always occupied). I ended up running experiments on Google Cloud Compute Engine with an A100 GPU — which was fast, but expensive.

I burned through my free trial credits in the first week of serious training. After that, I was rationing GPU time, running experiments overnight to minimize cost. I learned to be extremely efficient with hyperparameter searches — no more "let's just try 50 configurations." Every run had to be justified.

The Breakthrough: Context-Gating

The model was working, but false alarm rates were high in scenes with unusual but normal activity — a crowded market, a sports event. The problem: the model had no concept of scene context. A crowded market should have different "normal" behavior than an empty corridor.

The solution was a context-gating mechanism: CLIP classifies the scene type (outdoor, indoor, crowded, sparse) and produces a gating vector that modulates the anomaly score. The same motion that would be anomalous in an empty hallway might be completely normal in a shopping mall.

Adding this single mechanism dropped false alarms by ~18% and pushed ROC-AUC from 81.2% to 84.5%. It was the kind of insight that only comes from really understanding your failure cases — not just chasing benchmark numbers.

What I'd Do Differently

  • Start the literature review earlier. I wasted time in the first month reading too broadly. Having a focused research question from the start narrows your reading list dramatically.
  • Keep a research journal. I forgot why I made certain architectural decisions midway through, which caused confusion during the write-up. Document every experiment, hypothesis, and result.
  • Fail faster. I spent too long trying to make my first approach work. Kill an idea that isn't working after two weeks of evidence — not four.
  • Write while you research. Don't leave all the writing to the end. Maintain a running document of your methodology section. It forces clarity of thinking.

Final Thoughts

The thesis was the hardest and most rewarding thing I did at BRAC University. Seeing 84.5% ROC-AUC appear in the results table after months of work — and knowing I'd built something genuinely novel — was a feeling no course assignment had ever given me. If you're starting your own thesis, embrace the difficulty. The confusion is the process.


Back to Blog