AI Research Management Platform

Overview

My Bachelor's thesis at the University of Groningen. The problem was pretty straightforward: researchers in the AI lab spent too much time on administrative tasks — tracking papers, managing experiments, coordinating dataset annotations — when better tooling could handle most of it. So I built that tooling.

What I Built

A full-stack web application with three core modules:

1. Paper Management & Semantic Search

• Import papers from arXiv, Semantic Scholar, or manual upload
• Automatic metadata extraction (title, authors, abstract, citations)
• Semantic search powered by sentence-transformer embeddings (all-MiniLM-L6-v2)
• Research topic clustering and trend visualization
• Reading lists with annotation and highlight support

2. Experiment Tracking

• Log experiments with hyperparameters, metrics, and artifacts
• Comparison dashboards for model selection
• Integration with MLflow for existing workflows
• Automatic experiment lineage tracking (which paper → which hypothesis → which experiment)

3. Collaborative Annotation

• Multi-user annotation interface for text, image, and tabular data
• Configurable label schemas
• Inter-annotator agreement metrics (Cohen's κ, Fleiss' κ)
• Active learning suggestions for efficient labeling

Technical Details

Architecture:

• Backend: FastAPI with async SQLAlchemy ORM, background task processing with Celery + Redis
• Frontend: React + TypeScript with TanStack Query for data fetching
• Database: PostgreSQL with pgvector extension for embedding storage and similarity search
• Infrastructure: Docker Compose for local development, CI/CD with GitHub Actions

Key Technical Decisions:

• pgvector over dedicated vector DB: Kept the stack simpler by using PostgreSQL's pgvector extension. For the scale of a research group (~10K papers), this performs more than adequately and avoids operational complexity of a separate vector database.
• FastAPI over Django: Chose FastAPI for its async-first design, automatic OpenAPI documentation, and better TypeScript client generation via openapi-typescript-codegen.
• Sentence-transformers over OpenAI embeddings: Self-hosted embeddings for privacy (unpublished research) and cost reasons.

Challenges & Tradeoffs

• Embedding search quality: Generic sentence-transformers don't capture domain-specific nuances well. I fine-tuned on a small dataset of paper similarity judgments, which improved retrieval precision by ~20%.
• Real-time collaboration: The annotation system needed conflict resolution for simultaneous edits. I implemented optimistic locking with version vectors rather than full CRDT, trading theoretical robustness for implementation simplicity.
• Scope management: A thesis has a fixed timeline. I prioritized the paper management + annotation modules and kept experiment tracking as a thinner integration layer with MLflow.

Results

• Deployed to the University's AI research group (5 researchers, ~2000 papers)
• 40% reduction in time spent on paper discovery (user survey)
• Annotation throughput improved by 2.3x compared to spreadsheet-based workflows
• Thesis received 9/10 — contributed to cum laude distinction
• The platform is still actively used by the research group

What I Learned

• Scoping a full-stack app solo under a thesis deadline teaches you to cut ruthlessly — and to know what's actually important
• My initial design assumptions were wrong in several places. Watching researchers actually use the prototype changed the direction significantly
• Got a lot better at database design for search-heavy workloads
• Learned to write a thesis that satisfies both the technical implementation and the academic writing requirements