RAG Tool Playground

RAG retrieves relevant passages from a document and gives those passages to a language model as context. This playground demonstrates that flow: extract text, split it into chunks, create vectors, search for relevant chunks, and use them to generate a grounded answer.

The guided workflow moves through five steps: document extraction, chunking, embeddings, semantic search, and the RAG assistant. Each step uses the output from the previous step, making it easier to see how the pieces of a RAG system fit together.

The browser sends the file to `/api/document-extract`, where the server validates the file type and size and extracts readable text. The extracted document is kept in the current browser session; this application does not save the uploaded file or extracted text.

PDF files are read with `pdf2json`, DOCX files with Mammoth, and TXT or Markdown files with UTF-8 decoding. The server trims the extracted text and returns metadata such as the file type and, for PDFs, the page count.

Chunks are smaller passages that can be searched and supplied as focused context instead of sending the entire document every time. This demo supports fixed, overlap, sentence, paragraph, recursive, Markdown, code, and semantic chunking, with a default size of 1,000 characters where supported.

An embedding is a numeric vector representing text. The demo converts each chunk and your query into vectors so it can compare their similarity and rank the passages most related to your question.

It uses a deterministic demo model called `local-hash-embedding`, rather than a hosted neural embedding model. Words are hashed into a normalized 384-dimensional vector. The demo embeds up to the first 200 chunks in a run, and the vectors are kept in the browser session.

The query is embedded using the same hash function used for the document chunks. The server calculates cosine similarity against the stored chunk vectors, removes scores below 0.1, sorts the remaining chunks from highest to lowest, and returns up to the selected result limit.

Cosine similarity measures how closely two vectors point in the same direction. Because the vectors in this demo are normalized, their dot product can be used as the similarity score for ranking retrieved passages.

The answer prompt includes the user's question and up to five retrieved chunks as context. It instructs the model to answer using only that context. When the generation endpoint is invoked with a Gemini API key, the prompt is sent to the configured Gemini model.

Each retrieved chunk is labeled as `[Source 1]`, `[Source 2]`, and so on, and the model is instructed to cite factual statements using those labels. The citations point back to the retrieved document chunks used as evidence.

The prompt instructs the model not to guess or use outside knowledge. If the retrieved context is insufficient, it should reply: `I couldn't find that information in the uploaded notes.` Retrieval can also return no passages when all similarity scores are below the demo threshold.

No. RAG supplies relevant document chunks as context when generating an answer; it does not change the model's weights. The hash embeddings in this demo are also used only for retrieval, not for training.

RAG gives a model relevant information at answer time, so the source content can change without retraining the model. Fine-tuning updates the model's weights using training data, while this playground uses retrieval and prompting without fine-tuning.

Not in the current playground flow. It processes one uploaded document at a time, and uploading another document replaces the current document data and clears its chunks, embeddings, and search results. A multi-document RAG system would typically maintain a shared index with document identifiers so results can come from multiple sources.