Ananya

the problem

• Inference services fail silently or cascade across dependent microservices, and traditional monitoring tools don't capture the dependency chain
• Incident triage is slow because metrics are scattered across services with no unified view of what went wrong and why

how it works

• Kubernetes-deployed services with per-service autoscaling, separated liveness/readiness probes, and chaos-injectable endpoints for reliability testing under variable traffic
• Kafka streams service metrics in real time from every containerized microservice
• Redis caches live service status for instant health checks; PostgreSQL stores historical incidents for trend analysis
• Service dependency graph correlates failures across upstream and downstream services
• LLM-powered root-cause analysis ingests correlated failure data and generates actionable incident summaries

results

• Reduced incident triage time by surfacing correlated failures and root causes automatically
• Chaos-injectable endpoints enabled proactive reliability testing before failures hit production traffic
• Dependency graph correlation caught cascading failures that per-service monitoring missed entirely

the problem

• Compliance audits take weeks of manual cross-referencing against regulatory frameworks
• Every new regulation or policy update means starting from scratch

how it works

• Upload policy docs, pick a framework (GDPR, SOC 2, HIPAA), get a gap analysis in minutes
• LangGraph multi-agent pipeline — one agent retrieves clauses, one maps gaps, one generates the report
• Dual vector stores: FAISS for fast keyword retrieval, Chroma for semantic search
• Every finding cites the exact clause and policy section it references
• Next.js frontend, FastAPI backend, deployed to GCP Cloud Run with CI/CD via GitHub Actions

results

• Supports three regulatory frameworks out of the box
• Dual vector store approach improved retrieval relevance over single-store setups
• Fully cited reports — no black-box findings

the problem

• Firebase docs are massive and fragmented across guides, references, and tutorials
• Built-in search struggles with questions that span multiple products

how it works

• 1,070+ doc chunks embedded into Pinecone for semantic search
• Gemini API generates grounded answers with citations from retrieved chunks
• Exposed via MCP — plugs into any MCP-compatible AI coding assistant
• Node.js backend, React frontend, MongoDB for conversation history
• Containerized and deployed on GCP

results

• Answers grounded in actual docs, not hallucinated content
• Chunking strategy and embedding quality were the biggest levers for answer quality
• MCP integration makes the tool usable beyond its own UI

the problem

• Informal ride-sharing relies on manual coordination — forums, DMs, no guarantees
• No way to see routes on a map, book instantly, or handle payments in one place

how it works

• Post rides, search by route, book seats with live map visualization
• RabbitMQ queue handles concurrent bookings — last seat goes to one person, rest get notified
• Next.js + Redux frontend, Express.js API backend
• Dockerized and deployed to AWS ECS with MongoDB

results

• Async booking queue eliminated race conditions on seat availability
• Map visualization made route evaluation instant vs. reading text descriptions
• API stays responsive under concurrent booking pressure

the problem

• Stations run empty in high-traffic areas while others overflow with unused bikes
• Restocking is reactive — crews respond after stations are already empty

how it works

• Airflow-orchestrated pipeline runs monthly: ingest data, engineer features, train, evaluate
• Features include time-of-day patterns, weather correlations, seasonal trends
• MLflow tracks every experiment — hyperparameters, metrics, artifacts
• DVC versions training data alongside code
• Dockerized on GCP with GitHub Actions CI/CD

results

• Runs autonomously with monthly retrains, no manual triggers
• Easy to compare model iterations and roll back underperformers via MLflow
• DVC solved the "which data did this model train on" problem

the problem

• Hospitals run multiple EHR systems that don't sync with each other
• Stale or conflicting patient data across systems is a safety risk

how it works

• Kafka event backbone — each source system publishes record updates to topics
• Stream processor applies conflict resolution (timestamp-based, field-level merging)
• PostgreSQL serves as the single source of truth
• Airflow batch job runs periodic reconciliation as a safety net

results

• Handles high-throughput updates without bottlenecking
• Field-level conflict resolution preserves concurrent updates instead of dropping one
• Batch reconciliation catches edge cases where event ordering gets tricky

the problem

• NYT Strands isn't just find-the-word — every cell must be used exactly once with no overlaps
• Words must also fit a hidden theme, adding a semantic constraint on top of the spatial one
• The search space grows exponentially with grid size, making brute force infeasible

how it works

• Trie + DFS pass extracts every valid word traceable through adjacent cells in the grid
• SBERT ranks candidates by semantic similarity to the puzzle theme — so thematically relevant words score higher
• CSP solver picks the final subset of words that tiles the grid perfectly with no gaps or overlaps
• Dancing Links (DLX) and Genetic Algorithm implemented as alternative solvers to benchmark tradeoffs
• Pygame visualization shows the solver working through the grid step by step in real time

results

• Successfully solves Strands grids end-to-end given a letter grid and theme
• SBERT ranking significantly narrows the candidate pool before the CSP stage, reducing solve time
• Three solver approaches benchmarked — CSP with semantic pre-ranking performed best overall

the problem

• Complex image processing workflows require professional editing software with steep learning curves
• Non-technical users need accessible tools without sacrificing capability

how it works

• Built in Java using OOP and MVC architecture — modular, extensible codebase with clean separation of concerns
• Command pattern dispatch system supports 10+ image operations: compression, RGB/HSV/grayscale conversions, intensity adjustments, and matrix-based filtering
• Three execution modes from a single codebase — Swing GUI, interactive CLI, and batch script processing
• Split-view preview lets users compare original and processed images side by side before committing
• Histogram alignment tools for color correction and levels adjustment

results

• ~90% JUnit test coverage ensuring reliable transformations across all operations
• Reduced reliance on professional editing software for common image processing tasks
• Extensible architecture — adding new operations requires no changes to existing code

the problem

• MoE models have massive parameter counts but only activate a fraction of experts per token — uniform quantization treats all experts the same regardless of how often they're used
• Aggressive INT4 compression saves memory but costs noticeable quality; INT8 is near-lossless but gives up half the compression

how it works

• Profiled expert activation frequencies across the model — a small subset of "hot" experts handles most tokens while many remain cold
• Activation-aware strategy: hot experts quantized to INT8 (near-lossless), cold experts to INT4 (maximum compression)
• All quantization implemented from scratch using PyTorch — no external quantization libraries
• Benchmarked FP16 baseline, uniform INT8, uniform INT4, and activation-aware variants on perplexity and memory

results

• INT8 is effectively lossless — perplexity unchanged while halving expert memory (49.9% savings)
• Uniform INT4 compresses 4x but costs 0.53 perplexity points
• Activation-aware approach cuts INT4 degradation by two-thirds (0.18 points) with 57.6% memory savings
• Expert activation frequencies are highly non-uniform, which is exactly why differential precision allocation works

the problem

• MoE models need multi-GPU serving, but it's unclear whether tensor parallelism, expert parallelism, or a hybrid approach is the right default
• Emerging diffusion-based MoE architectures introduce routing overhead at every denoising step, with unknown throughput implications

how it works

• Benchmarked Tensor Parallelism (TP), Expert Parallelism (EP), and Hybrid (TP+EP) strategies on NVIDIA A100 GPUs across multiple MoE architectures
• Varied request concurrency levels and measured throughput, latency, and resource utilization for each strategy
• Statistical analysis (ANOVA) to decompose what actually drives throughput variance — strategy choice vs. system-level factors
• Tested diffusion-based MoE architectures to quantify routing overhead at scale

results

• TP is a strong default, but EP matches or exceeds TP for models with 60+ small experts
• Naive Hybrid strategy severely underperforms both TP and EP in all tested configurations
• Request concurrency explains 51.7% of throughput variance vs. just 6.6% for strategy choice — tune concurrency before picking a strategy
• Diffusion-based MoE architectures suffer a 9.8x throughput penalty vs. dense models due to per-step routing overhead