DocMind AI
DocMind AI is a Retrieval-Augmented Generation (RAG) assistant built around one idea: reading everything yourself doesn't scale. Upload a PDF, drop in a document, or point it at a YouTube video, and it builds a searchable knowledge base you can question directly, summarizing, extracting key points, and answering follow-up questions grounded in the actual source material instead of a generic model response. It's currently in active development and doesn't have a public repository or live demo yet; the write-up below reflects the real architecture and feature set as it's being built.
Why I Built This
Most of what I read for research, coursework, or side projects is a PDF, a doc, or a long YouTube video, and re-opening the same source later just to find one detail is a genuinely bad use of time. I wanted a tool that lets me interact with that content directly instead of manually combing back through it.
Retrieval-Augmented Generation specifically, not just a wrapper around a model's own general knowledge, was the point: an answer has to trace back to something I actually uploaded, not whatever the model already happened to know about the topic.
How the RAG Pipeline Works
Every source (PDF, document, or YouTube video) goes through the same core pipeline: extract the raw text (or transcript), split it into overlapping chunks, embed those chunks, and store them for retrieval. When a question comes in, the system retrieves the chunks most relevant to it and passes them to the model alongside the question, so the answer is generated from the actual source material rather than from the model's own memory of the topic.
Treating Video Like Any Other Document
YouTube videos are handled the same way as any uploaded document: instead of asking the user to watch or manually transcribe anything, the video's transcript is pulled and fed through the same extract-chunk-embed-retrieve pipeline as a PDF. The practical result is that a long lecture or interview becomes just as searchable and summarizable as a two-page document.
File Processing
PDFs and text-heavy documents go through extraction, chunking, and embedding before a single question can be answered against them, none of that work happens lazily at query time, since retrieval quality depends entirely on how well the source was broken up beforehand.
The chunking strategy is one of the parts still actively being tuned: too small and a chunk loses context, too large and irrelevant text gets pulled in alongside the useful part, and getting that balance right matters more for answer quality than almost anything else in the pipeline.
User Experience
The interaction model is deliberately conversational rather than a search box, someone should be able to ask a follow-up question the way they'd ask a person who'd already read the material, without re-stating context the assistant should already have from earlier in the conversation.
That's also the hardest UX problem in the project so far: RAG naturally treats each question somewhat independently, so keeping a conversation feeling continuous (not just individually correct answers in a row) takes deliberate work on top of the retrieval pipeline itself.
Planned Improvements
The next real milestone is a public repository and a live demo once the core pipeline is stable enough to hand to someone else. Beyond that, better handling of messy, auto-generated YouTube transcripts and a chunking strategy that adapts to source length are the two improvements most likely to move answer quality noticeably.
Key Decisions
RAG was chosen over relying on the model's own training data, so every answer is grounded in the specific document or video the user uploaded, a factual question about a 40-page PDF should never quietly get answered from the model's general knowledge instead of the actual file.
YouTube analysis and document analysis are designed to share the same underlying pipeline (extract text, chunk it, embed it, retrieve the relevant chunks, generate an answer) rather than building two separate systems for what's fundamentally the same retrieval problem with a different source format.
Architecture and exact tooling choices are still being finalized as the build progresses; this section will be updated with the real decisions once they're locked in, rather than filled with specifics that haven't actually been implemented yet.
What I Learned
Getting retrieval right matters more than getting the language model right; a strong model with weak retrieval still gives confidently wrong answers, because it's reasoning from the wrong chunks of context.
Still early in this build, so the deeper lessons (chunking strategy, handling YouTube transcripts that are often auto-generated and messy, keeping conversational context across follow-up questions) are still being worked through. This section will be filled in honestly as development continues.