I build small LLM systems and then measure whether they actually work.
Most of what I publish follows one shape: build the thing the tutorial describes, write an evaluation harness for it, then report the number that disagreed with the tutorial. The build is the easy half. The measurement is the project.
Based in Mumbai. Working through LLM engineering in public — retrieval, evaluation, and model selection.
stylesense-rag — a RAG assistant over a fashion catalogue, swept across 18 configurations against the same 16-question test set.
The winning change was made at ingestion time, not at query time: chunking at 2000/400 instead of the tutorial's 1000/200 moved retrieval coverage from 64.0% to 69.6% and answer accuracy from 4.38 to 4.94. Raising k looked like +5.3 points of coverage and was a small regression once divided by the arithmetic ceiling — a coverage number without its ceiling is not a measurement. Numeric constraints ("something under Rs 1500") never improved under any configuration, because cosine similarity has no concept of less than.
llm-code-porting-eval — 36 measured runs comparing four models on Java-to-Kotlin migration, with each model's predicted rank locked in before the eval so the benchmark could not be retrofitted to the outcome.
Benchmark rank did not predict real-world value. The rank-2 model was the slowest and the poorest value, burning ~734 output tokens per task on hidden reasoning. The recommended model flips depending on whether a team weights quality or cost, so the deliverable is a weighted decision matrix rather than a single answer. Model selection is a business decision, not a leaderboard lookup.
embedding-space-explorer — a vector store over a synthetic catalog, then a hard look at the embedding space it produced.
At 1200-character chunks the top five similarity scores sat inside a 0.012 band: noise that happens to arrive sorted. Shrinking the chunks opened the spread to 0.130, which is real signal — and the near-verbatim match still only reached 2nd place. Vocabulary overlap beat the exact match.
synthetic-ticket-generator — support tickets generated side by side by a frontier model and a 4-bit quantized open model.
At batch size 5, both looked fine. At 15, the open model returned zero parseable rows — not from poor quality, but from hitting the token cap mid-array, where a single truncated row invalidates the entire JSON batch. Token budgets constrain open models harder as batch size grows, and strict JSON parsing fails all-or-nothing.
tokenizer-chat-template-explorer — one identical sentence pushed through four instruct-model tokenizers.
A vocabulary 56% larger bought almost nothing on plain English: the same sentence is 18 to 20 tokens everywhere. The divergence is in the chat template, the wrapper nobody inspects — formatting the same conversation costs Llama 32 extra tokens and Phi only 2, because Llama's template injects a "Today Date" line into every single call.
Python · LangChain · Chroma · OpenAI and Anthropic APIs · transformers · Gradio · pandas · t-SNE
Before this: Android development since 2017 — Kotlin, Java, Flutter. The older repositories here are that era.
Metadata filtering for the RAG project, so a budget becomes a database where clause instead of a vector, measured against the same test set. constraint coverage sat at 58% through all 18 configurations, so there is a clear number to beat.