Launching GraphSearch-rag: a GraphQL API for RAG, zero infra required

I just shipped GraphSearch to PyPI — a GraphQL API server for retrieval-augmented generation over your own documents. pip install graphsearch-rag, ingest some files, and you've got a typed Q&A endpoint over them. No API keys required to get started, no vector DB cluster, no queue.

Why I built it

Every RAG setup I've put together has the same shape underneath — chunk documents, embed them, retrieve, generate an answer, cite the sources — but wiring it up always meant standing up a vector database, picking an embedding provider, and writing a REST layer on top before you could even ask it a question. I wanted something where the entire loop — ingest, ask, get a cited answer — works the moment you pip install, and then scales up piece by piece as you need it.

How it works

pip install graphsearch-rag
graphsearch-ingest data/example_docs
graphsearch                            # → http://localhost:8000

That's the whole setup. Under the hood it's FastAPI + Strawberry serving GraphQL, with a paragraph-aware chunker, a pluggable embedder, and SQLite doing double duty as the store for documents, chunks, and vectors. The default mode runs fully offline — hashing-trick embeddings and extractive answers — so it works in CI or air-gapped environments with zero setup.

From there, every stage is swappable via env vars:

• GRAPHSEARCH_EMBEDDINGS: hash (offline) → local (sentence-transformers, still offline) → openai
• GRAPHSEARCH_LLM: extractive (offline) → openai → anthropic

The API surface is small and typed — answer(question, topK) for full RAG with cited sources, search(query, topK) for raw retrieval, plus mutations for uploading documents or PDFs directly. There's also a Playground UI at / for testing without writing any client code, and a generated TypeScript SDK that fails CI if it drifts from the schema.

What's next

Hybrid keyword + vector search (SQLite FTS5 + BM25, merged via reciprocal rank fusion) is on the roadmap along with Qdrant/pgvector/FAISS backends, streaming answers, and an evaluation harness. Most open items are filed with implementation notes if anyone wants to jump in — a good chunk of it is genuinely good-first-issue sized.

This sits alongside a couple of other things I've been building — ContextBuddy (context middleware for LLM calls) and a few MCP servers — all around the same theme: making the retrieval/context layer of LLM systems cheap and easy to stand up without reaching for heavy infrastructure by default.

PyPI: pypi.org/project/graphsearch-rag
Repo: github.com/mohithgowdak/graphsearch

Would love feedback — especially from anyone who's hit the "just let me ask a question about these docs" wall and had to stand up more infrastructure than the problem deserved.