Project Info

LiteRAG

Devpost

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.

Analysis

Compare with all teams

View

Metric

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

Found in codeClaimed only
  • 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.

0 stars