Rajgire Akhil Reddy — AI Engineer. I build agent systems — and the tools that explain why they do what they do.

Problem

Fixed-time signals run a timer regardless of what is actually on the road. Queues build on one approach while an empty approach holds a green.

Approach

Model each intersection as a Double DQN agent over a 2×2 grid, simulated in SUMO. In cooperative mode every agent also sees its neighbours' queue state, so decisions account for what is about to arrive rather than only what is already waiting.

What made it hard

Designing the architecture of the RL system was hard, and training it was harder. Reward design is the whole problem — the reward penalises queue length, waiting time, and unnecessary phase switching, because an agent that flickers between phases can look good on paper while being useless on a road.

Outcome

94.3% average wait-time reduction against the fixed-time baseline, 141 seconds down to 8. A policy trained on the grid transferred to a 4-agent network with no additional training and still ran 68% better per intersection, converging roughly 7× faster than training from scratch.

Technical system

• Double DQN with experience replay, PyTorch
• SUMO traffic simulation, 2×2 intersection grid
• Cooperative mode: neighbouring queue state shared between agents
• Reward penalises queue length, waiting time and unnecessary phase switches
• Transfer learning from the trained grid to a larger network

Problem

Generated floor plans are only useful to an architect if they are actually buildable. Neural generators produce plausible-looking layouts but offer no guarantee that rooms fit inside the boundary or avoid overlapping, and reported constraint satisfaction sits in the 75–88% range. In a domain where compliance is mandatory, a plan that is 88% feasible is not feasible.

Approach

Drop the generative model entirely and state the problem as what it actually is: a constraint satisfaction problem. Each room becomes four integer variables — x, y, width, height. Containment, non-overlap and area bounds become hard constraints. Adjacency preferences, compactness and space utilisation become a weighted soft objective. Google OR-Tools CP-SAT then either returns a layout that satisfies every hard constraint, or reports that none exists.

Outcome

On a 25 m × 16 m footprint with five rooms, run ten times: 100% hard-constraint satisfaction, 85.82% space utilisation, 90% room compactness, 81.40% adjacency satisfaction, and an overall layout quality index of 89.38%. Average solve time under 8 seconds. No training data required, and every result is reproducible — the same input gives the same plan.

Technical system

• Rooms as integer variables (x, y, w, h) on a 0.3 m discretisation grid
• Hard constraints: boundary containment, non-overlap, per-room area bounds
• Soft objective: weighted adjacency, compactness and space utilisation
• Google OR-Tools CP-SAT v9.x, 30 second solver limit
• NetworkX for the adjacency graph, matplotlib for the rendered plan

Problem

A research paper is not flat. It has a title, authors, a venue, a year, sections and citations, and the section a passage came from is often what decides whether it answers the question or merely mentions the words in it. Most retrieval systems flatten all of that into undifferentiated text on the way in, and then have none of it left at the moment you ask.

Approach

Parse the structure on the way in and keep it. Title, authors, year, venue, DOI or arXiv ID, 20+ section types and both numbered and author-year citation styles are extracted at ingestion, and every chunk is classified from its full chain of enclosing headers — so “Experiments › Baseline Models” is tagged experiments rather than inheriting whatever heading came first. Questions are then answered by vector search for meaning fused with BM25 for exact terms, reranked by a cross-encoder, and every citation that comes back is checked against the retrieved sources by author and year.

What made it hard

Measuring it honestly, and then acting on what the measurement said. Running the ablation exposed that the shipped default had reranking switched off — the setting was being overridden by the pipeline’s balanced mode, so the system was scoring 0.2041 MRR, which is not significantly better than plain vector search (p = 0.16), while the same components configured as documented reach 0.2824. The gap was invisible until something measured it. Three features that were already built then turned out not to earn their place either. Section routing costs accuracy, because the evidence that answers a question is in the section it routes to only 13.3% of the time. LLM query rewriting costs 18% MRR, because the rewriter cannot see the corpus and invents the context an under-specified question is missing. Query expansion and intent classification reach nothing downstream at all. All three are still in the repo, switched off, with the numbers that killed them published rather than the features quietly removed.

Outcome

Evaluated on QASPER — 80 papers, 1,048 chunks and 259 questions with evidence grounded to real chunk ids, every arm answering the same questions so the comparison is paired, intervals from 10,000 bootstrap resamples. Hybrid retrieval is worth +20.2% MRR over vector-only, and a cross-encoder rerank a further +25.8% — it doubles precision-at-1, and it is where the query time goes. Running the embedding model and the reranker on ONNX Runtime rather than torch gives the same numbers to four decimal places for 326 MB resident instead of 758 MB, which is what makes free hosting possible. Deployed on Modal, answering in about two seconds once warm, with 338 tests passing.

Technical system

• Ingestion: converters → preprocessing → paper metadata → section-tagged chunks
• Qdrant for vectors, SQLite for documents and conversations
• Retrieval: vector search + BM25 fused with Reciprocal Rank Fusion, then a cross-encoder rerank
• Unsupported citations are deleted rather than shown — small models invent references even when told not to
• Per-user isolation: documents, vectors, BM25 corpora and conversations are scoped to their owner, and cross-tenant reads return 404
• Sessions are revocable server-side, which a signed JWT does not allow on its own
• Generation is a seam — Ollama locally, a hosted model on Groq when deployed, retrieval unchanged either way

Problem

Transaction alerts are unstructured text scattered across an inbox. There is real data in there and no way to ask it anything.

Approach

Ingest SMS alerts through n8n webhooks, parse UPI, IMPS, NEFT and card formats with regex into structured records, embed them, and answer natural-language questions over the result with retrieval plus Gemini.

What made it hard

The whole thing was built inside a 24-hour hackathon window.

Outcome

Over 1,000 transaction records indexed with sub-second semantic search. Second place at Hack-A-Sol 2025.

Technical system

• FAISS IndexFlatL2 vector index
• Sentence Transformers all-MiniLM-L6-v2 embeddings
• Gemini for response generation
• Real-time SMS ingestion via n8n webhooks
• Regex parsing for UPI / IMPS / NEFT / card alert formats

Problem

Study material is split across formats. A lecture recording, a slide deck and a scanned page are the same subject, but nothing lets you ask a question across all three at once.

Approach

Normalise every input into text — OCR for images, Whisper for audio, transcripts for video — then index it all together with hybrid retrieval so answers stay grounded in whichever source actually contains them. Re-index automatically as new material lands.

Outcome

Third place at APIhub.digital 2025.

Technical system

• Hybrid retrieval — FAISS dense vectors combined with BM25
• Gemini and LangChain for generation and orchestration
• OCR for images, Whisper transcription for audio, YouTube ingestion
• Automatic re-indexing as material is added
• OAuth2 / JWT authentication, collaborative study groups