The problem

PDFs and long documents are where information goes to become hard to find. Ctrl+F only works if you already know the exact word you are looking for, and skimming a fifty page report for one answer wastes time every single time you need it. I wanted a document assistant you could actually ask questions, with answers grounded in the source and traceable back to it, not something that guesses when it does not know.

Approach

DocuLume is a Retrieval-Augmented Generation platform, built as a FastAPI backend with a Next.js frontend rather than a single script. Documents (PDF, TXT, DOCX, and Markdown) are ingested, chunked, embedded, and stored in ChromaDB as the vector index, with PostgreSQL holding the transactional data (users, documents, conversation history) and Redis backing the cache and the Celery task queue that runs ingestion and processing asynchronously rather than blocking a request while a large document gets indexed.

At query time, retrieval pulls the most relevant chunks and passes them to the language model alongside the conversation history, with multi-provider support (OpenAI, Anthropic, Google) rather than being locked to a single vendor. The whole thing runs through Docker Compose, with auth handled through token based sessions, CSRF protection, and rate limiting, since document content is often private and the system needed to treat it that way from the start rather than bolting security on afterward.

Outcome

DocuLume handles authenticated, multi-format document ingestion and multi-turn Q&A with source-grounded answers, running as a proper deployed service rather than a local notebook. The architecture (async processing, a real task queue, a persistent vector store) is more infrastructure than a simple chatbot needs, which was deliberate: I wanted to build and understand the parts of a RAG system that only show up once you try to run it reliably for more than one user at a time.