Serverless RAG Chatbot on AWS
An NSF-funded project teaching algebra in virtual reality hired me to build its website. I left it with a retrieval-augmented AI assistant that answers a visitor's questions from the project's own research, grounded so it cannot invent an answer, on infrastructure that costs almost nothing when no one is asking.
Hired for a website, not a chatbot
Algeverse is an NSF-funded research project, a recipient of the NSF Award for Broadening Participation in STEM, that teaches algebra in virtual reality to close equity gaps at HBCUs. The research is real and it is working: a context-aware AI supports students inside the VR experience, and the pilots have logged thousands of events with high action accuracy.
I was brought in for something more ordinary. The project needed a public-facing website that explained the work to funders and collaborators, and a way for the team to publish updates as the research progressed. I designed and shipped that, and set up a publishing workflow so the team could post news on their own without routing every change through me.
The project stuck with me. It is a serious AI effort aimed at a problem I care about, and a plain brochure site felt like a missed opportunity, so I proposed building an assistant on top of it that used the same kind of technology the research itself was about.
A research site asks too much of a visitor
A research project's substance is scattered by nature: across landing pages, blog updates, quarterly progress reports, and annual findings, much of it in PDFs. A funder checking in, a collaborator evaluating a partnership, or a student who is simply curious has to read most of it to find the one answer they came for. Most people will not. The work is excellent and largely unread.
The question I wanted to answer was narrow: could someone get a trustworthy answer in one sentence instead of thirty minutes of reading? On a research project, "trustworthy" is the entire difficulty. An assistant that answers confidently from thin air is worse than no assistant at all, because here the content is the credibility.
Retrieval first, generation second
"Retrieval-augmented generation" is two problems sharing one name: find the right context, then write a careful answer from it. The system solves each on its own path, and they meet at a single store.
Retrieval-augmented generation
Ingestion splits the site's content into passages, turns each one into an embedding (a numeric fingerprint of its meaning) with Amazon's Titan model, and stores it in a vector index. When the team publishes or edits something, it flows into that index.
A query embeds the visitor's question the same way, matches it against the index to pull the handful of most relevant passages, and hands them to a language model with a strict instruction: answer using only this context, and admit when it is not enough. Retrieval keeps the answer grounded; generation makes it readable. The model is the least important part of the system.
Serverless, and silent when idle
The entire backend is serverless and event-driven. There is no server to keep running and nothing billing by the hour when no one is chatting.
The stack at a glance
One design choice is worth calling out. The chat widget in the visitor's browser never holds the credential that talks to the backend. The browser calls WordPress, and WordPress attaches the secret key on the server side and forwards the request. That same server-side hop is where the assistant picks up which page the visitor is on, so it can answer in context. The key stays off the client, and the answer still has page context.
The decisions that actually mattered
The decisions that mattered were the forks where two reasonable options pulled in opposite directions. Here were the main ones.
On-demand models over always-on endpoints
The default way to serve embeddings is a dedicated inference endpoint, which bills around the clock whether or not anyone uses it. For a research site with uneven traffic, that is wasted spend on an idle service. I moved embeddings and generation to on-demand Bedrock calls. Cost scales with usage, not time. The trade is a little cold-path latency, which a chat can absorb and a trading system could not.
A pay-per-use vector store over a managed cluster
The usual home for embeddings is a managed search cluster with a monthly floor in the hundreds of dollars before the first query. For one site that is indefensible. I used S3 Vectors, which has no idle cost at all. At rest, the whole system costs effectively nothing. The trade is a newer service with fewer knobs, which this workload simply does not need.
A small model, made reliable by retrieval
I did not reach for the largest, most expensive model. Because every answer is grounded in retrieved passages, a lean model like Nova produces accurate, on-topic replies at a fraction of the cost. With good retrieval, a small model is enough. The trade is less open-ended reasoning, which a factual Q&A assistant never exercises.
Grounding over fluency
A bot that answers everything confidently is easy to build and dangerous to ship on a research project. I constrained the model to the site's own content and to saying "I don't have that" when the content runs out. I traded some fluency for answers you can trust.
The admin panel is the product
A chatbot only I can maintain becomes a liability the day I move on. Algeverse is run day to day by a rotating group of volunteer research students, most of them not engineers. The hardest part of the build was not the AI. It was the admin experience.
From the WordPress dashboard, a student connects the site once, then clicks a single Sync button to pull every page and post into the assistant's knowledge base. Publish a new update and it flows in on its own. To add something the site does not already say, a policy, an FAQ, a one-page explainer, they drag a PDF into an uploader and it becomes part of what the assistant knows. A dashboard shows exactly what is indexed, and a test box lets them try a question before anyone else can. No command line, no keys to paste, no retraining to schedule.
The goal was to take the complex part, the generative AI, and make it feel like one button for the people who run it, then put the engineering effort into making that button reliable.
Live, maintained by the team, nearly free to run
The assistant is live on algeverse.com today. The team keeps it current through the same dashboard they publish with, the answers stay anchored to what the project actually says, and the infrastructure sits near zero cost whenever no one is asking. The marketing site now answers questions from the project's own material.
A few things I took from it: