Exam preparation in India has a pricing problem. A student preparing for JEE, NEET,
GATE, MHT-CET, UPSC, or SSC can find advice everywhere and full mock tests almost
nowhere without a subscription. SarvPariksha is my attempt to make the mock test part
free.
It is an agentic platform, not a static question bank. A static bank has two failure
modes: it goes stale, and it cannot respond to the person taking the test. I added an
agent layer so the platform can plan a paper, retrieve material with tools, evaluate the
attempt, and explain what went wrong.
The agent loop
A mock test starts with a plan. The agent reads the exam, subject, and attempt history,
then drafts a blueprint for the paper. It retrieves candidate questions through tools
rather than trusting model memory, checks them against structured metadata, and assembles
the test. After submission, it evaluates the attempt, explains mistakes, and recommends
what to practice next.
The important part is where the model is not allowed to work. Scoring stays
deterministic. Answer keys and question metadata live in PostgreSQL, not in a prompt. The
model plans and explains; the database and the grader decide what is true. That split
keeps an agentic system auditable when a student disputes an answer.
What it runs on
The app is built with Next.js, with PostgreSQL holding questions, attempts, and results.
Cloudflare handles delivery, and Groq powers inference for the agent. The stack is
deliberately boring. Exam software should be predictable; the interesting parts belong in
question quality and review, not in the framework.
What was actually hard
Not the UI. The hard part was the state machine around an attempt. A mock test has more
states than it appears to: not started, in progress, paused, submitted, auto-submitted,
reviewed, and abandoned. Every one of those states has to survive a slow connection, a
closed tab, and a student who hits the back button at the worst possible moment.
The second hard part was scale without a team. A private tool can assume a handful of
users and clean input. A public platform cannot. Making the jump meant caring about
caching, database indexes, abuse, and error states that never show up in a demo.
Where it goes next
Generated questions need stronger evaluation: answer-key checks, duplicate detection, and
a human review path before anything reaches a student. An agentic exam platform is only
as good as its ability to reject a bad question.
The model is not the product. The attempt state is.
SarvPariksha is live at
sarvpariksha.in. It is still the project I learn
the most from, because every feature has to survive an anxious student on a cheap phone.
Most fake data is not fake enough. A random name generator will happily produce a
19-year-old named something no 19-year-old in that state is named, living in a city that
does not match the pin code, with a language that does not match the region. The test
suite passes. The product still fails when real data arrives.
Indian-fakedata is a
dependency-free library that generates Indian profile data from Census 2011 statistics.
Instead of inventing plausible-looking rows, it samples from real distributions: state,
age, gender, and the layers that hang off them. The result is data that looks like the
country it claims to describe.
Why not just use a package?
Existing faker libraries are good at generating fields. They are less good at generating
a coherent person. A profile is not a bag of independent values; it is a set of values
that constrain each other. The library models those constraints so that the output holds
together across multiple fields.
Keeping it dependency-free was a deliberate constraint. It installs fast, runs anywhere,
and does not drag a data stack into a test suite that only needs a hundred fake users.
Built for LLM testing too
The same generator produces LLM-ready personas. When you are testing a retrieval system
or an agent, you need users with consistent backgrounds, not ten random strings. Census
distributions give the personas enough texture to expose bad assumptions in prompts and
evaluation sets.
The library has passed 100 downloads. The next problem is maintenance: census data ages,
and a generator is only as honest as the distribution behind it.
At GHRCE I led development of an AI hallway receptionist: a robot that listens, retrieves
campus information, and answers out loud, intended to run 24/7. The demo was quick.
Making it survive a hallway took the rest of the internship.
Speech is a latency budget
Text interfaces forgive a two-second pause. Voice does not. When the microphone closes
and the speaker has not started, users assume the system is broken. The pipeline was
speech-to-text, retrieval, then text-to-speech, and every stage spent part of the same
budget. Most of the engineering was not making each stage smarter; it was making the
handoffs quieter.
Grounding beats fluency
A receptionist that sounds confident and gives the wrong room number is worse than one
that says it does not know. RAG helped because it tied answers to campus documents, but
the real lesson was about stale documents. Retrieval will faithfully return last
semester’s timetable if nobody updates the source. The model is rarely the problem;
the corpus is.
Auth has to disappear
The accompanying student chatbot needed accounts, but students visit once or twice. Long
passwords and verification loops kill adoption. We architected passwordless
authentication using email OTP: less friction, fewer support tickets, and one less
password to reset at the start of a semester.
Hallways are not labs
Background noise, accents, people who speak before the robot finishes, and someone who
walks away mid-answer. None of that appears in a clean demo. The system that shipped was
the one that recovered gracefully from all of it, not the one with the best benchmark.