Inspiration
Every student we know already has an AI chatbot open next to their notes. Almost none of them trust it.
You ask a question the night before an exam, you get back a fluent and confident paragraph, and you have no way to tell whether it came from your syllabus or from somewhere the model invented. Verifying the answer takes longer than looking it up yourself, so most people either trust it blindly or stop using it for anything that matters.
The second problem is quieter but costs more. A chatbot has no memory of your mastery. It will explain the same concept the same way for the tenth time and never notice that you keep failing the same question. Flashcard and quiz apps have the opposite weakness: they track your streak, but they cannot reason over the specific PDF in front of you.
We wanted one tool that closed both gaps at once. Answers you can check, tied to the page they came from, and a study plan built from what you actually got wrong.
What it does
Synapse AI turns any study document into an interactive knowledge workspace. You upload a PDF of your notes or textbook chapter, and the system parses it, chunks it, embeds it into a vector index, and extracts 8 to 15 core concepts that become a navigable knowledge graph.
From there, six modules cover the full study loop:
- Grounded AI Tutor. Retrieval augmented question answering where every response is generated from passages pulled out of your own document, and every claim is cited back to the page and passage it came from.
- Grounding strength ratings. Each answer carries a High, Medium, or Low grounding score, so you can see how well supported it is instead of guessing. Weak retrieval is surfaced rather than hidden behind confident prose.
- Synapse Knowledge Graph. An interactive concept map showing how ideas in the material depend on one another, so you can see the prerequisite you skipped rather than just the topic you failed.
- Adaptive Quiz Engine. Question difficulty tracks your current mastery per concept, and every generated question passes through an LLM validator before it is ever shown to you.
- Mastery Tracking. Scores are computed from real attempt data, including what you answered and how consistently, not from self reporting.
- Smart Learning Path. A ranked study plan generated from your mastery scores combined with the concept dependency graph, so the next thing you study is the thing that unblocks the most.
The point of the whole system is that nothing is generated in a vacuum. Retrieval happens before generation, which is what makes the citations real rather than decorative.
How we built it
Frontend: React 18 with Vite, Tailwind CSS, and Framer Motion for the workspace UI, deployed on Vercel. Authentication is wired for both Google Sign In and email.
API layer: FastAPI with async endpoints and CORS, chosen because the whole pipeline is Python and we did not want a language boundary between the API and the machine learning work.
Ingestion pipeline: PyMuPDF parses the uploaded PDF, a chunking pass splits it into retrievable passages, and those passages are embedded into a FAISS index. A Gemini call then extracts the core concepts and their dependencies to build the knowledge graph.
Retrieval and reasoning: A question hits FAISS for top k similarity search, the retrieved passages are scored for relevance to produce the grounding strength rating, and only then does Google Gemini generate an answer constrained to those passages, with citations attached.
Pedagogy layer: Quiz generation is scoped to specific concepts, a separate LLM validation pass rejects malformed or ambiguous items, attempt data updates the per concept mastery score, and the learning path re-ranks from there.
Data: SQLite in WAL mode, holding concepts, attempts, mastery scores, and generated paths.
Deployment status, stated plainly: the frontend is deployed and reachable on Vercel. The FastAPI backend is not hosted yet. It runs locally with the build verified, and the API is served from localhost during the demo. Hosting the API is the first item on our roadmap, and we would rather say that than let a judge discover it.
Challenges we ran into
Naive RAG still hallucinates. Wiring up retrieval and generation did not solve the trust problem by itself. When the index returns weakly related passages, the model will still produce a confident answer built on them. Rather than pretend that never happens, we made the system score how well the retrieved evidence actually supports the question and expose that as a High, Medium, or Low rating. Showing the weak cases turned out to be more valuable than trying to eliminate them.
LLM generated quiz questions are unreliable by default. Early generations produced items with two defensible answers, questions whose answer did not appear anywhere in the source document, and prompts that were simply ambiguous. Better prompting helped but never got us to reliable. Adding a separate validator pass that rejects bad items before they reach the learner was cheaper and far more effective than trying to make generation perfect.
Calibrating concept extraction. Too few extracted concepts and the knowledge graph is trivial and tells you nothing. Too many and it turns into noise you cannot navigate. Landing on a target of 8 to 15 per document took several rounds of tuning against real material.
Mastery scoring on sparse data. At the start of a session there are almost no attempts to reason from, so a single wrong answer can swing a concept score wildly and send the learning path chasing something that was just a slip. Getting the scoring to move meaningfully without overreacting to one data point was harder than expected.
Concurrency on SQLite. Quiz sessions produce interleaved reads and writes, and the default journaling mode started throwing lock errors under that pattern. Switching to WAL mode resolved it and kept the local footprint simple.
Deployment shape. The React frontend deploys cleanly to Vercel. A Python API carrying a FAISS index and PyMuPDF is not a Vercel shaped workload, so the two halves have different hosting needs, and the split origin also meant working through CORS configuration. This is why the frontend is live and the backend is still local.
Rebranding mid build. The project started as Mentra and became Synapse AI. That meant sweeping the rename through the UI, the copy, the metadata, the favicon, and the visual identity while the underlying architecture kept moving.
Accomplishments that we're proud of
The full loop actually closes. Upload a document, get a concept graph, ask a question and receive a cited answer, take a quiz, watch mastery update, and see the learning path reorder itself. It is one continuous system rather than six demos stitched together.
Grounding strength is a visible feature, not a hidden metric. Most AI study tools optimise for sounding certain. We decided the more useful product tells you when it is on thin evidence, and built the interface around that.
Validation before generation reaches the learner. The quiz validator is unglamorous and it is the reason the quizzes are usable.
A complete visual identity. The Mentra to Synapse AI rebrand carried through the whole product, and the deployed frontend looks like a finished tool rather than a hackathon prototype.
We can describe exactly what is and is not running. Frontend deployed, backend local, no cohort study run yet. Being precise about that was a deliberate choice.
What we learned
Retrieval quality is the product. We spent early effort on prompt engineering when the real leverage was in chunking, indexing, and how relevance gets judged. A well grounded prompt over bad passages still produces a bad answer.
Exposing uncertainty builds more trust than hiding it. We expected the grounding rating to make the tool feel weaker. It does the opposite. A Medium rating tells you to go look at the source, which is exactly the behaviour we wanted to encourage.
A cheap validator beats an expensive prompt. Adding a second model pass to reject bad output was faster to build and more reliable than iterating on the prompt that generated it.
Different parts of a stack want different homes. Assuming one deployment target for the whole application cost us time. The frontend and a retrieval heavy Python service have genuinely different requirements.
Pedagogy is a design problem, not just an ML one. Deciding what counts as mastery, how fast it should move, and what the learner should study next were harder questions than any of the model integration work.
What's next for Synapse AI
Near term: from single user to shared. Host the FastAPI backend so the entire stack runs from one link, move from local SQLite to multi user accounts with persistent study history, and add spaced repetition scheduling to the Smart Learning Path so review timing is driven by forgetting curves rather than by what you happen to click.
Mid term: from one document to a syllabus. Multi document ingestion with synthesis across sources, conflict detection for when two of your sources disagree with each other, and exportable concept graphs and mastery reports you can hand to a tutor or bring to office hours.
Long term: from learner to classroom. A classroom mode with instructor cohort dashboards, teach back and spoken explanation modes so learners can be tested on explaining rather than only on recognising, and curriculum gap analysis that uses aggregate mastery data to show which parts of a syllabus the material itself explains badly.
Each phase widens the evidence base without loosening the grounding requirement. If Synapse AI ever answers something it cannot point at, it has stopped being the thing we set out to build.
Log in or sign up for Devpost to join the conversation.