A lightweight retrieval-augmented microservice that answers cooking questions grounded in a curated corpus of recipe and technique notes, with per-request latency tracked end to end.
Finding a trustworthy answer to a specific cooking or technique question usually means wading through SEO-bloated blog posts and ads, or asking a general-purpose chatbot that may hallucinate a method. I wanted a small, fast retrieval-augmented system that answers cooking questions grounded directly in a curated set of recipe and technique notes, with real retrieval behind every answer, not just a model's guess, while keeping an eye on response latency since a cooking assistant needs to feel instant.
The corpus, a set of recipe and technique notes, is chunked and embedded once using Google Gemini's embedding API. Vectors are held in a plain numpy array rather than a full vector database. For a small, static corpus this is faster to boot, easier to deploy, and one fewer moving part in the stack.
Each incoming query is embedded on the fly, cosine-scored against the stored vectors, and the top-k matching chunks are pulled as retrieval context. That context, together with the original query, is passed to Gemini's generation model, which produces an answer explicitly grounded in the retrieved passages. If the corpus doesn't contain a relevant answer, that shows up in the retrieval scores rather than as a made-up response.
FastAPI serves the endpoint. Every request logs total latency, retrieval latency, and generation latency separately, so it is obvious where any slowness lives. That made experimenting with retrieval depth and generation temperature much more grounded, tune a knob and see exactly which part of the pipeline moves.
