ArXiv ChatGuru: A Topic-Scoped Redis Vector Index for Paper Q&A
Use ArXiv ChatGuru to talk to research papers. This app uses LangChain, OpenAI, Streamlit, and Redis as a vector database/semantic cache.
At a glance
- What is it?
- ArXiv ChatGuru is a Streamlit learning project that fetches arXiv papers, chunks them, embeds them with OpenAI, and stores them in a Redis vector index so you can ask questions against the papers you loaded. It is explicitly not a production research assistant, and the README says so.
- Who is it for?
- Adopt ArXiv ChatGuru if you want a small, readable example of Redis as a vector store inside a RAG loop, and you are comfortable editing Python and running Docker Compose. Do not adopt it if you need multi-user isolation, citation-level provenance, or a retrieval pipeline you can tune without touching app code, since the README lists metadata filters, chunking, and chat memory as planned rather than shipped.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Activity is slowing. The repository last received commits 6 months ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem ArXiv ChatGuru actually solves
Reading a paper with a chat model usually means pasting text into a window and hoping the model does not invent a section that was never there. ArXiv ChatGuru takes a narrower approach. You give it a topic and a paper count, it pulls matching papers from arXiv, and it answers questions only from the chunks it stored. The README describes the result as a topic-scoped Redis vector index, which is the important phrase: each topic you load gets its own index rather than sharing one global pile of embeddings. That scoping is what makes the app useful as a teaching artifact. You can load two unrelated topics and inspect each index separately from the stats page. The audience is developers who already know what retrieval-augmented generation is and want to see where Redis sits in the loop. The README is direct about the scope: this is a learning project for academic RAG, intentionally simple, not a production-ready research assistant. Take that sentence seriously. There is no user model, no document permissions, and no evaluation harness in the repository description.
The five-step pipeline and where Redis sits
The README lays out the flow in five numbered steps, and the division of labour is clean. The app pulls papers from arXiv and splits them into chunks. OpenAI generates embeddings for those chunks. Redis stores the chunks and embeddings in a topic-scoped index. LangChain retrieves the closest chunks for each question and passes that context to the chat model. So Redis is doing retrieval, not generation, and LangChain is the glue between the vector search and the chat call. The README lists three jobs for Redis: storing topic-specific paper chunks and embeddings, powering vector search, and letting you inspect the active index from the stats page. That third job is unusual for a demo. Most sample apps hide the vector store behind an abstraction, which makes debugging retrieval failures painful. Here the stats page exposes index metadata, indexed fields, and Query Engine stats for the active topic. If a question returns a bad answer, you can check whether the right chunks were indexed before you blame the model. That inspection surface is the most practically useful part of the design.
Getting it running with make and a .env file
The repository ships a Makefile, and Docker is described as the primary local path. Start by copying the environment template, then set your key. The README gives these commands: cp .env.template .env, then set OPENAI_API_KEY=your_key_here. The template defaults are OPENAI_CHAT_MODEL=gpt-4.1-mini, OPENAI_EMBEDDING_MODEL=text-embedding-3-small, REDIS_INDEX_BASENAME=arxiv, and REDIS_URL=redis://arxivchatguru-redis:6379. Note that the default Redis hostname is a Compose service name, so it will not resolve if you run the app outside Docker without changing it. Bring the stack up with make docker-up and open http://localhost:8501. Tear it down with make docker-down. The local path needs Python 3.13, Poetry installed via python3 -m pip install --user poetry, then python3 -m poetry env use python3.13, make install, and make dev. The README warns that if you run locally outside Docker, REDIS_URL must point at a reachable instance such as redis://localhost:6379. Other targets are make format, make test, and make build. The Makefile is the real interface here; there is no published package, and the README lists no releases.
Where the design choices will bite you
Three limitations are visible without running anything. First, chunking. The README's planned follow-ups include improving the chunking strategy for long papers, which tells you the current strategy is a known weak point. Papers with dense notation, long proofs, or figures whose meaning lives in the caption are exactly where naive chunk boundaries lose context, and the app does not claim to solve that. Second, filtering. Better metadata filters such as year or author are also on the planned list, so retrieval today is pure vector similarity over your loaded set. Ask about a specific author and you are relying on the embedding to surface the right chunks, not on a filter. Third, conversation state. Chat history or memory features are listed as conditional, to be added only if the tutorial needs them. Each question is therefore answered against retrieved context without prior turns. The cost model is the other constraint: every load spends OpenAI embedding calls proportional to paper count and chunk count, and every question spends a chat completion. Nothing in the repository description mentions caching embeddings across runs, so reloading a topic likely repeats that spend. Treat it as the wrong tool for a shared service or for anything where a wrong answer carries consequences.
How it differs from a general-purpose RAG framework
The obvious alternative is a general framework such as LlamaIndex, or building the same loop directly on LangChain with a different vector store. The difference is not capability, it is where the opinion lives. A framework gives you configurable node parsers, metadata extractors, and retrievers you swap without touching application code. ArXiv ChatGuru hardcodes its choices: arXiv as the source, OpenAI for embeddings and chat, Redis for storage, Streamlit for the interface. That narrowness is the point of a tutorial. You can read the whole pipeline in one sitting and see the Redis index, which is harder when a framework hides the store behind three layers of abstraction. The trade is flexibility. If you want to swap the embedding model, add a reranker, or filter by publication year, you are editing app code rather than changing a config value. If your goal is to learn how Redis fits into RAG, the constrained version teaches that faster. If your goal is a system you will extend for months, start from a framework and use this repository as a reference for the Redis portion.
Maintenance, licence, and what MIT means here
The licence is MIT, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are included. That is a permissive licence, and it places no copyleft obligation on your own code. It also means the authors offer no warranty, which matches the README's own framing of the project as a learning exercise. On maintenance, the repository is not archived and the last push is dated 2026-03-18, so it is active as of that date, but the README lists no releases, so there is no versioned artifact to pin. You are tracking the main branch. That matters for upgrade cost: a Poetry lockfile pins dependencies for reproducible installs, yet the app itself has no release tags, so a git pull can change behaviour with no version number to compare against. The Python 3.13 requirement is stricter than many projects and will constrain environments still on older interpreters. Before depending on it, check the lockfile for the LangChain and Redis client versions it resolves, since those two libraries move quickly and the app's retrieval behaviour follows them. Do not treat the MIT grant as legal advice; review the LICENSE file and your own obligations.
Editorial conclusion
Adopt ArXiv ChatGuru if you want a small, readable example of Redis as a vector store inside a RAG loop, and you are comfortable editing Python and running Docker Compose. Do not adopt it if you need multi-user isolation, citation-level provenance, or a retrieval pipeline you can tune without touching app code, since the README lists metadata filters, chunking, and chat memory as planned rather than shipped. Before you build on it, verify three things: that your OpenAI key has access to the models named in .env.template, that REDIS_URL points at a reachable Redis instance when you run outside Docker, and that the stats page reports the index and Query Engine fields you expect after loading a topic.
Community notes