Recipe Recommendation

Problem

Recipe recommendation is more useful when the system can account for context: available ingredients, user preferences, constraints, and previous conversation history. Generic chatbots can answer recipe questions, but they usually lack persistent user state and application-specific retrieval.

The goal of this project was to build a local-first chatbot that combines a mobile interface, a FastAPI backend, persistent storage, and Ollama-powered retrieval-augmented generation.

Approach

Chat-Gptouille was built as a complete application rather than only a notebook experiment. The system combines:

• A Flutter interface for chat and user interaction.
• A FastAPI backend for application logic and model orchestration.
• PostgreSQL for users, conversations, and message persistence.
• Ollama for local LLM inference and embeddings.
• Docker Compose for reproducible local deployment.

This made the project a practical test of how local LLMs fit into a real application stack. A related local-first RAG experiment is Drippy.

Architecture

The backend exposes endpoints for sending messages, loading context, and coordinating model calls. The database stores account data, sessions, and chat history through SQLAlchemy models. The frontend communicates with the API over HTTP and presents a mobile-friendly chat experience.

The local AI layer uses Ollama models such as qwen2.5 for generation and all-minilm for embeddings. Docker Compose ties the services together so the stack can be started consistently across environments.

Results

The prototype proves that a privacy-conscious RAG chatbot can be built with a standard full-stack architecture while keeping inference local.

Key outcomes:

• Implemented a persistent real-time chat flow.
• Connected Flutter, FastAPI, PostgreSQL, and Ollama in one deployable stack.
• Added retrieval and embedding workflows for recipe context.
• Built a reproducible Docker-based development setup.

What I learned

The biggest engineering challenge was not the model call itself, but the surrounding state management: user sessions, message history, retrieval inputs, response formatting, and service orchestration. Local AI applications still need strong product architecture, clear API boundaries, and predictable storage design.

I also learned that containerization is essential when an AI application depends on several services. It makes the project easier to run, debug, and explain.

Next steps

The next version would improve retrieval quality, add better recipe-specific evaluation, and include richer user constraints such as allergies, time available, budget, equipment, and seasonal ingredients. A production version would also need authentication hardening and clearer observability around model latency and retrieval quality.