arXiv Knowledge Assistant: Automated Paper Retrieval and a Bilingual RAG Q&A Platform

Every day, arXiv publishes more papers than any single researcher could ever hope to read. You go looking for something specific, you're scrolling through endless abstracts, and even once you've found a few relevant papers, actually asking questions across them — comparing what one says against another — is painfully slow. That's the exact bottleneck the arXiv Knowledge Assistant is built to break.

The idea is to build one complete pipeline that runs the whole journey: from pulling in data, to vector retrieval, to a large language model answering your questions, all the way to visualization dashboards. So on one side, you — the user — can just ask questions in plain natural language about paper abstracts, PDFs, or your past Q&A history. And on the other side, if you're a developer, you can configure how papers get ingested, manage the vector index, and keep an eye on how the models are performing.

Now here's a design choice I really appreciate. The whole thing is stitched together with Docker Compose, and the goal is what they call "one-command reproducibility." You prepare your environment file and your Firebase key, you run `make build` and `make up`, and the entire environment just comes to life. No manual wiring of a dozen services by hand.

So what does this platform actually do? A handful of things. It automatically fetches arXiv paper metadata, the PDFs, and abstracts every single day. It handles Chinese and English — both translation and question answering. It runs RAG-style Q&A, meaning it pairs retrieval from a vector database with a language model. You get customizable prompt templates, a dashboard showing your query history, and email subscriptions that push papers to your inbox. And to be honest about it — things like CI/CD, unit tests, and integration tests are still on the roadmap. Planned, not done. I respect a project that's upfront about that.

Let's talk architecture, because this is where it gets interesting. The system is broken into several small, single-responsibility microservices — an arxiv service, a note service, an email service, an API gateway, and a couple reserved for the future like image and speech services. Every one of them gets deployed together through Docker Compose.

If you zoom out, the whole thing really comes down to three flows of data.

The first is daily ingestion. On a schedule, it crawls arXiv, drops the PDFs and metadata into storage, and writes text embeddings into the vector database.

The second is the RAG question-answering flow. When you ask something, it retrieves relevant material, re-ranks it, hands that context to the language model, and the model's answer comes back to your dashboard.

And the third is email subscriptions. Every day it pulls papers, generates summaries, and sends them out to subscribers.

Picture the flow like this: a request from you hits the API gateway, which handles authentication, then passes it to the RAG service. Meanwhile, completely in parallel, a scheduler is constantly fetching from arXiv, parsing, chunking, embedding, and indexing everything into storage. When you ask a question, the RAG service and storage feed into a retrieval pipeline — hybrid search first, then re-ranking, then prompt assembly — and that prompt goes to the local language model, which generates the answer and sends it back through the gateway to you. That's the heartbeat of the system.

Let me break down the ingestion pipeline a little more. The daily schedule is triggered by Prefect 3 — that's the workflow orchestrator. Each paper runs through a chain: fetch, parse, chunk, embed, index. And where things land is deliberate. The PDFs go into MinIO, which is object storage. The paper metadata goes into PostgreSQL. And the text embeddings go into Qdrant, the vector database.

Here's why that separation matters. Because the source, the storage, and the index are each independent, ingestion and querying stay decoupled. You can swap out or extend any one piece later without tearing the others apart. That's clean engineering.

Now the retrieval and Q&A path — this is the real core. When you ask a question, the first thing that happens is query rewriting. Your question gets rewritten and, if needed, translated between Chinese and English, so the retrieval works better regardless of what language you asked in. Then comes hybrid search on Qdrant — and "hybrid" is the key word here, because it leverages both dense signals, which capture meaning, and sparse signals, which capture exact keywords, at the same time. After that, the recalled documents get re-ranked to push the most relevant ones to the top. Only then does the local language model — running on Ollama — actually generate the answer, and it can even evaluate multiple prompt templates. On top of all this, the Q&A strategy pairs RAG with agent reflection, so the system can think about its own output. And throughout the whole process, the prompt traces get recorded by Langfuse, which means you can trace back and evaluate the quality of any answer later. That observability is gold when you're debugging why a model said something weird.

A few more pieces round it out. For login, it uses Firebase Authentication with Google sign-in — you do need to drop your service account key into the right folders, and without it, the Firebase features won't work. Redis handles caching. Email subscriptions go out over SMTP using a Gmail app password. And for monitoring, it's Prometheus and Grafana — Grafana lives on localhost port 3002 by default — which you can pair with Alertmanager to set up alerts.

One nice touch on the front-end: there are actually two interfaces. There's a React and Vite app, and there's also a Gradio interface that works without Firebase at all. So if you just want to kick the tires and you don't feel like setting up a whole Firebase project, Gradio is your low-friction door in.

Quick tour of the tech stack so it all sticks. For infrastructure: Docker Compose, MinIO, PostgreSQL, and Qdrant. On the backend: FastAPI and Prefect 3. Front-end: React with Vite, plus Gradio. Monitoring: Prometheus and Grafana. And the CI/CD and testing layers — GitHub Actions and pytest — those are still planned or in progress.

So where does this leave us? The platform can already run the full end-to-end loop today: daily ingestion, into vector retrieval, into bilingual RAG question answering, out to dashboards and email subscriptions — with real observability from Grafana and Langfuse watching over it. What's still to come: the CI/CD automation, the test coverage, support for multiple language-model backends like OpenAI and Anthropic, and personalized recommendations. It's MIT licensed and open source, so you can go dig into it yourself.

Let me leave you with the three things worth remembering. First, this is fundamentally about decoupling — separating the source, the storage, and the index means every part of the system can evolve on its own. Second, retrieval quality is engineered, not accidental: query rewriting, hybrid dense-plus-sparse search, and re-ranking all stack up before the model ever writes a word. And third, reproducibility and observability aren't afterthoughts here — one command spins the whole thing up, and Langfuse plus Grafana mean you can actually see what your system is doing. Build systems you can trace, and you'll build systems you can trust.