Milestone: RAG-Powered AI App

bhaleraoneha — Tue, 29 Sep 2026 10:18:17 +0000

This project is a Retrieval-Augmented Generation (RAG) web application built to demonstrate how a large language model can be made to answer questions reliably from a specific set of documents, rather than relying solely on its general training knowledge. The system was developed as part of an internship task requiring the integration of four core AI engineering skills: LLM API usage, prompt engineering, retrieval pipeline construction, and full-stack deployment, combined into a single, working, publicly accessible product.
At a technical level, the application follows the standard RAG architecture. Source documents are first split into overlapping text chunks to preserve semantic specificity. Each chunk is converted into a numerical vector representation using Google's Gemini embedding model. When a user submits a question, that question is embedded using the same model, and cosine similarity is computed against every stored chunk to identify the most semantically relevant sections of the source material. These top-matching chunks are then inserted into a carefully constrained prompt and passed to Gemini's chat model, which generates a response using only the retrieved context, explicitly declining to answer when the necessary information isn't present in the documents.
The application is built with Next.js and deployed on Vercel, using entirely free-tier infrastructure: no paid API subscriptions, no dedicated backend server, and no external vector database. Retrieval is handled through a lightweight in-memory similarity search, which is sufficient for small-to-medium document sets and avoids unnecessary infrastructure overhead for a project of this scope.
A key design decision was transparency and verifiability. Rather than presenting a black-box chatbot, the interface explicitly displays which documents currently ground the assistant's answers, and includes a live upload feature: any user can add their own .txt file at runtime and immediately query it, without needing to redeploy the application or access its codebase. This makes the system's retrieval behaviour independently testable, a user can confirm, in real time, that answers are actually derived from the supplied content rather than the model's pre-existing knowledge.
Several practical lessons emerged during development. Retrieval quality, driven by chunking strategy and the number of chunks returned, had a greater impact on answer accuracy than adjustments to the prompt itself. Effective prompt engineering proved to be less about clever phrasing and more about imposing strict behavioural constraints, particularly instructing the model to acknowledge uncertainty rather than fabricate an answer. Meeting production, readiness standards also required attention beyond the core AI logic: graceful error handling for failed API calls, clear loading states during retrieval and generation, and secure handling of API credentials outside of version control.
The resulting application demonstrates that a functional, trustworthy retrieval-grounded AI system can be built and deployed end-to-end using freely available models and infrastructure, without requiring a dedicated backend, paid API access, or a managed vector database, making the approach accessible for small-scale, resource-constrained projects.

Building a Chatbot Taught Me About LLM APIs

bhaleraoneha — Sat, 22 Aug 2026 12:23:24 +0000

Most people's first experience with an LLM API is deceptively simple: send a prompt, get a reply. It feels like magic, and for a single question-answer exchange, it basically is. But the moment you try to build something that holds an actual conversation one where the model remembers what you said three messages ago you run into a problem that isn't obvious until you hit it: LLM APIs are stateless. Every request is a blank slate unless you explicitly hand the model its own memory.

That was the core challenge behind a recent project I built during my internship a chatbot backed by a real LLM API ([OpenAI / Gemini]) with genuine multi-turn conversation support, not just a scripted request-response loop.

*The problem nobody mentions upfront
*
You can't just "turn on" memory. Every conversation turn has to be manually tracked and resent with each new API call, which means the developer, not the model, is responsible for deciding what counts as context. And that decision has real consequences: send too little history and the bot forgets things it should remember; send too much, and you run into token limits and rising costs as the conversation grows.

This is where most simple chatbot tutorials stop short. They show you how to get a reply from an API, but not what happens once a conversation runs long enough that you can't keep resending everything forever.

*Where the actual engineering happens
*
Solving that meant implementing a context management strategy deciding what to keep, what to drop, and eventually exploring smarter approaches like summarising older parts of a conversation instead of just discarding them. It also meant thinking about the bot's identity through a system prompt, handling API failures gracefully instead of letting the UI break, and treating credentials properly by keeping API keys out of source code entirely.

None of this is complicated in isolation. What's interesting is how much of it is invisible until you actually build the thing yourself. Using a chatbot every day gives you zero insight into how much deliberate design goes into something as basic-sounding as 'remembering the conversation.'

*Why this matters beyond one project
*
LLM APIs are increasingly the backbone of real products: support bots, coding assistants, internal tools, and almost all of them face this same underlying problem: statelessness. Understanding how to manage context, memory, and failure gracefully isn't a niche skill anymore; it's close to a prerequisite for building anything serious with these models.

I wrote up the full technical breakdown, including my actual implementation approach, the mistakes I made along the way, and what I'd improve next — in a longer post here:

ai #llm #chatbot #webdev #internship

Read the full article: https://valentiuskryptix.com/building-a-powerful-ai-chatbot-with-an-llm-api/

DEV Community: bhaleraoneha

Milestone: RAG-Powered AI App

Building a Chatbot Taught Me About LLM APIs

ai #llm #chatbot #webdev #internship