Project Info
This project did not submit a demo video on Devpost.
Inspiration
We’ve been researching retrieval-augmented generation (RAG) and storage-efficient embedding systems at Berkeley, and noticed a gap: most retrieval engines are built for the cloud. They’re powerful but bulky—too large for laptops, edge servers, or mobile devices. We wanted to see if we could bring the same high-recall semantic search to the edge, with minimal storage and no loss in quality.
What it does
LiteRAG is a storage-optimized retrieval engine designed for the edge. It compresses indexes to under 5% of raw data, achieving up to 50× smaller footprints than standard vector databases while maintaining comparable recall. LiteRAG can ingest any GitHub repo, build a graph-based index, and let users query side-by-side against a Chroma baseline—with optional Groq acceleration for instant, context-aware answers.
How we built it
We built LiteRAG with a FastAPI backend managing ingestion, indexing, and evaluation, and a Next.js frontend for visualization and benchmarking. Each run creates isolated Chroma stores and reproducible builds to ensure fair comparisons. We experimented with graph compression, text normalization, and quantization strategies to achieve near-lossless retrieval quality in a tiny footprint.
Challenges we ran into
Our biggest challenge was balancing recall quality with aggressive compression. Pushing storage down 50× without breaking semantic precision required iterating on embedding sparsification, graph layouts, and normalization pipelines. We also had to ensure consistent benchmarks across multiple frameworks, which meant designing reproducible evaluation loops from scratch.
Accomplishments we're proud of
We achieved a working retrieval system that’s orders of magnitude smaller than existing solutions—yet delivers nearly identical recall quality. LiteRAG runs cleanly on devices with limited memory, cold-starts instantly, and supports deterministic comparisons with Chroma. Seeing a 50× reduction in storage without measurable loss in accuracy was a huge milestone.
What we learned
We deepened our understanding of graph-based retrieval, index compression, and storage-aware design for RAG systems. We also learned how small architectural decisions—like memory layout or token normalization—can drastically affect both performance and reproducibility. These lessons tie directly into our ongoing research on efficient, adaptive retrieval models.
What's next
If possible we will try to pitch this idea to a couple of VC's! We believe this can be BIG.
LiteRAG
A small Next.js app and Python backend that build tiny LiteRAG and Chroma indexes, show on-disk size, and let you query both. LiteRAG is the focus; Chroma is included solely as a baseline for comparison. Optionally, responses are summarized by a Groq LLM. A separate Flask app demonstrates a local Ollama streaming chat UI.
What’s in here
- Next.js 14 frontend (
app/) with Tailwind UI - FastAPI backend (
backend.py) exposing:GET /setup— builds the LiteRAG index and a persistent Chroma collection (baseline), returns storage statsGET /ask?q=...— searches both and returns results plus optional Groq LLM response
- Optional Flask SSE server (
chat.py) that streams responses from a local Ollama model
Note: Chroma is only used as a familiar baseline to highlight LiteRAG’s advantages (smaller storage footprint with comparable results on this demo dataset).
Prerequisites
- Node.js 18+ and npm
- Python 3.10+
- Optional for Groq summaries: a Groq API key
- Optional for local chat: [Ollama] installed with a local model pulled (e.g.
qwen7b)
Quick start
- Install frontend deps
npm install
- Install Python deps (add missing runtime libs used by the code)
python -m venv .venv && source .venv/bin/activate # optional but recommended
pip install -r requirements.txt
pip install fastapi uvicorn chromadb leann groq flask
- Start the backend (FastAPI)
uvicorn backend:app --reload --port 8000
- Start the frontend (Next.js)
npm run dev
- In the UI
- Click “Download & Build Demo” to run
GET /setupand build both indexes - Ask a question; the app calls
GET /ask?q=...and shows results for LiteRAG (primary) and Chroma (baseline)
API reference (FastAPI)
GET /setup
Builds a tiny LiteRAG index and a persistent Chroma collection (baseline) under demo_data/, then returns storage stats.
Response shape:
{
"leann_size_kb": 1.23,
"chroma_size_kb": 8.45,
"storage_reduction_percent": 85.4
}
Notes
- LiteRAG index path:
demo_data/leann_index.index(field nameleann_*is legacy in code and refers to LiteRAG) - Chroma data dir:
demo_data/chroma_db/
GET /ask?q=...
Searches both backends and includes an optional Groq-generated answer per context.
Response shape (truncated):
{
"query": "your question",
"leann": {
"results": [
{ "text": "...", "score": 0.1234, "metadata": {} }
],
"groq_response": "...",
"context": "..."
},
"chroma": {
"results": {
"documents": [["...", "..."]],
"distances": [[0.12, 0.34]]
},
"groq_response": "...",
"context": "..."
}
}
Optional: Local Ollama streaming chat (separate app)
chat.py runs a minimal Flask server that streams tokens from a local Ollama model via SSE.
Run it (cannot share port 8000 with the FastAPI backend at the same time):
python chat.py
Endpoints
/— simple in-browser chat UI/ping_ollama— health check (non-streaming)/stream_test— SSE smoke test/chat_sse?session_id=...&text=...— main streaming endpoint
Environment
OLLAMA_HOST(defaulthttp://127.0.0.1:11434)MODEL_NAME(defaultqwen7b) — must exist inollama list
Port note: chat.py is hardcoded to 127.0.0.1:8000. If the FastAPI backend is running, stop it first or change the port in chat.py.
Environment and configuration
Groq (optional summaries in backend.py)
- The function
get_groq_response()currently contains a hardcoded API key. Replace it with an env read (e.g.,os.environ.get("GROQ_API_KEY")) before committing or sharing the code. - If Groq is not installed or the key is missing/invalid, the backend returns an error string in
groq_response, and the demo still functions.
Frontend backend URL
- The UI calls
http://localhost:8000. If you change the backend host/port, update the URLs inapp/LiteRAGDemo.tsx(/setup,/ask).
Data locations
- LiteRAG index (legacy name in code):
demo_data/leann_index.index - Chroma DB:
demo_data/chroma_db/ - Delete the
demo_data/folder to reset.
Troubleshooting
- ModuleNotFoundError for
fastapi,uvicorn,chromadb,leann,groq, orflask→ install the packages shown above. - Port already in use (
8000) → stop the other server or change the port (and adjust the frontend URLs if needed). - CORS errors →
backend.pyalready allows all origins; ensure you are calling the correct host/port. - Groq errors in
groq_response→ installgroqand set a valid API key; or ignore if summaries are not needed. - LiteRAG import error → ensure the
leannPython package installs successfully for your platform.
License
No license specified in this repository.
Made for a simple, reproducible comparison that showcases LiteRAG, with Chroma included only as a baseline.
Analysis
View
Metric
- 12
- 4
Figures cover GitHub contributors during the hackathon window. A co-authored commit counts in full for each author, so per-member totals add up to more than the whole-team figures.
Technology
- CSSIn code
- JavaScriptIn code
- Next.jsIn code
- PythonIn code
- ReactIn code
- StreamlitIn code
- Tailwind CSSIn code
- TensorFlowIn code
- TypeScriptIn code
- FastAPIClaimed
9 of 10 appear in the indexed code. 1 claimed on Devpost could not be matched to code, which may simply mean the tool leaves no trace in the repository.
AI coding agents
No AI coding agent signals were found in this repository.
Detected from committed agent config files and commit authorship. Absence of a signal is not proof an agent was unused.
Codebase size
Source size
44 KB
Source files
12
Counts recognized source files only; vendored directories, binaries and lockfiles are excluded, so this is smaller than the repository on disk.
Repository
PvRao-29/liteRAG
39 files · 29.1 MB · @ 7dfddba
Structure
Interface
6 files · 15%Screens, components and styles rendered to the user.
Application logic
9 files · 23%Domain rules, services and shared utilities.
Supporting
Layers are inferred from where files sit in the tree, not from reading the code. A project that names its directories unconventionally will read oddly here — open the file browser to check anything the diagram implies.
Languages
- TypeScript52%
- Python32%
- Markdown11%
- JavaScript3%
- CSS2%
Share of indexed source by file size. Binary and vendored files are excluded.
Dependencies
requirements.txt
pypi · 142- absl-py
- altair
- annotated-types
- anyio
- appnope
- asttokens
- astunparse
- attrs
- beautifulsoup4
- blinker
- bs4
- cachetools
- certifi
- charset-normalizer
- choreographer
- click
- comm
- contourpy
- +124 more
package.json
npm · 12- next
- react
- react-dom
- +9 more
Declared in the repository’s manifests at the indexed commit. A declared package is not proof it is used, and runtime dependencies are listed first.
This project’s features have not been analysed yet.
Export this project's context (description, README, evidence, key source files) to chat with an AI agent elsewhere.