RAG-Powered Assistant for Wine Pairing: What to Cook with the Bottle You Were Given

TL;DR

This publication presents a retrieval-augmented generation (RAG) assistant that answers one
question: "I have this bottle of wine, what should I cook?" It retrieves facts about the wine
from 49 Wikipedia pages, picks matching recipes from 51 Wikibooks Cookbook recipes, and writes a
short answer that cites its sources. You can extend the knowledge base with your own recipes and
pairing notes. When the wine is not in its knowledge base, it says so instead of inventing facts. The assistant runs fully locally with qwen2.5:7b through Ollama, or
with OpenAI, Groq or Google Gemini, and passes all 8 questions of its end-to-end evaluation.

You will learn how the pipeline is built (three LLM calls and four filtered vector searches), why
each design decision was made, and how a small local model can be kept from hallucinating with
checks in code rather than in the prompt.

Purpose and objectives

People are often given a bottle of wine as a gift and do not know what to cook with it.
This is a shame, because gift bottles are often special wines that need the right dish to show
their full potential. This project builds an assistant that solves exactly that problem, in one
direction only: wine → dish. The assistant also explains why the wine pairs well with the
dish, which is a great way to learn more about wine and how to pair it with food.

The objectives were to build an assistant that:

1. Answers from a knowledge base only. Every wine fact and every dish in an answer comes from
   retrieved text, with numbered citations the user can check.
2. Suggests dishes the user can actually cook. Suggestions are limited to recipes in the
   knowledge base, so a full recipe is always available.
3. Admits what it does not know. For a wine outside the knowledge base, the answer says so
   and falls back to general pairing principles.
4. Stays within its scope. Dish → wine questions and off-topic questions get a fixed redirect
   instead of an answer.
5. Is measurable and debuggable, with an evaluation script and a script that traces one
   question through every step.
6. Is easy to extend with your own recipes and pairing notes. With the template in
   data/pairing_notes/_template.md, you can write down, in your own words, pairings you have
   enjoyed in restaurants or read about elsewhere.

Objectives 1 to 4 are tested in the end-to-end evaluation, objective 5 is covered by the
evaluation and trace scripts; see Evaluation.

Who this is for

• Home cooks who have a bottle and want a dinner idea with a reason behind it. They need no
  technical knowledge to ask a question, but someone has to install the tool (Python and a
  terminal).
• Developers and learners building their first RAG system. The code is small (about 1,500
  lines including scripts), documented and tested, and shows several fixes for problems that tutorials rarely
  cover: query rewriting, metadata filtering, a coverage check and scope routing. Familiarity
  with Python and basic LLM concepts is assumed.

The problem

Wine pairing advice is easy to find, but it is a poor fit for the "gift bottle" situation. The
advice online is also usually very general, and it cannot include your own experiences that you
would like to recreate.

• Pairing charts and articles start from a grape or style. The user still has to work out
  what their bottle is, which traits it has, and which recipe fits those traits.
• General-purpose chatbots answer any wine question fluently, but they mix facts with
  invented details, cannot show where a claim comes from, and confidently describe wines they
  know little about. LLM hallucination is a well-documented problem [5].
• Commercial pairing sites and apps cannot be used as a data source: the terms of use of
  sites such as Wine Folly and Vivino forbid copying and automated access.

RAG addresses the first two problems by grounding the answer in retrieved documents [1, 2]. The
third is solved by using only openly licensed text (CC BY-SA 4.0).

Success criteria: the assistant must suggest a suitable dish for well-known wines, refuse to
describe wines it has no information about, and redirect questions outside its scope.

Related work

Retrieval-augmented generation was introduced by Lewis et al. [1] to combine a parametric
language model with a non-parametric document index; Gao et al. [2] survey the many variants
since. Two ideas from that literature shaped this project:

• Query rewriting. A user question is often a poor search query. Ma et al. [3] rewrite the
  query with an LLM before retrieval, and HyDE [4] searches with a generated hypothetical
  document instead of the question. This project uses the same idea twice: once to turn the
  question into a wine search, and once to turn the wine's traits into a food search, which
  bridges a vocabulary gap that the literature describes in general terms (recipes never mention
  wine names).
• Hallucination. Huang et al. [5] show that LLMs ignore or override retrieved context,
  especially when it is incomplete. Prompt instructions alone did not prevent this with a 7B
  model here, which is why the coverage check is done in code.

The gap this project fills is small but practical: most RAG tutorials use one retrieval step over
one document type. A pairing question needs two different kinds of knowledge (wine facts and
recipes) that never mention each other, so a single similarity search cannot connect them.

How it works

Knowledge base

In total: 100 documents, about 1.1 million characters, split into 2,199 chunks with an average
length of 545 characters.

A download script fetches the pages through the MediaWiki API, removes reference and link
sections, and saves each page as Markdown with a metadata header (title, category, URL, revision
ID, license, download date). It respects Wikimedia's rate limits and writes an attribution file
listing every page.

Pipeline

Every question goes through three LLM calls and four vector searches:

question ──► 1. classify + wine search query (LLM)
               │  "wine"  → continue      "dish" / "other" → fixed redirect, no search
               ▼
             search wine knowledge with the question AND the rewritten query
               ├─ 4 chunks about the wine (grapes, regions, styles)
               └─ 2 chunks of general pairing principles
               ▼
             coverage check (code): is the named wine in the retrieved chunks?
               ▼
             2. wine traits → food search query (LLM)
               ▼
             search recipes ─► 4 recipe chunks
               ▼
             3. answer from the 10 numbered chunks + coverage instruction (LLM)

Step 1: classify and rewrite. The LLM replies in a fixed three-line format:

TOPIC: wine
WINE: Barolo
SEARCH: Barolo food pairing, body, tannin, acidity

dish and other questions stop here with a fixed answer. If the model labels a question
wine but finds no wine and no search query, the code treats it as other.

Step 2: retrieve wine knowledge. Two searches with a ChromaDB metadata filter: one for
grape, style and region pages (4 chunks), and one for pairing principles (2 chunks). Both the
original question and the rewritten query are searched, and the best distinct chunks are kept,
so a poor rewrite cannot take over the results.

Step 3: coverage check. The code checks whether the named wine appears in the retrieved
chunks (accent-insensitive) and whether the best cosine distance is below 0.5. The result is one
of three instructions for the final prompt: covered, loose match, or "the knowledge base contains
NO information about Saperavi; say so and do not describe it".

Step 4: food search. The LLM reads the retrieved wine chunks and replies in two lines:
TRAITS (body, acidity, tannin, sweetness, flavors) and SEARCH (at most 12 words of dishes or
ingredients that suit those traits). For Chablis, the search became
Grilled fish, shellfish, goat cheese, salad. The recipes are searched with that query
(4 chunks).

Step 5: answer. The final prompt contains the coverage instruction, the 10 numbered chunks
and the question. The model describes the wine, suggests one or two of the retrieved recipes,
explains the pairing in terms of the wine's traits, and cites chunk numbers.

Example

$ python src/app.py "I was given a bottle of Chablis, what should I cook?"

(wine search: Chablis food pairing, body, acidity)
(recipe search: Grilled fish, shellfish, goat cheese, salad)
(coverage: The wine knowledge covers this question)

Given your Chablis, you might want to consider a Greek Salad [7]. Chablis is known for its high
acidity, which can cut through the richness of the olive oil and the saltiness of the feta cheese
in the salad. [...]

If you prefer something heartier, you could also try Fish and Chips [10]. [...]

Sources:
  [1] Chablis (AOC) (distance 0.40) https://en.wikipedia.org/wiki/Chablis_(AOC)
  [3] Chardonnay (distance 0.46) https://en.wikipedia.org/wiki/Chardonnay
  [7] Greek Salad (distance 0.49) https://en.wikibooks.org/wiki/Cookbook:Greek_Salad
  ...

Design decisions

Almost every decision below was made after a test question failed.

Assumptions

• The user names the wine, grape, region or style in the question. Bottle labels are not read.
• The traits on Wikipedia pages describe the typical wine. Individual producers and vintages vary.
• The 51 recipes cover the main pairing cases: red meat, poultry, fish and seafood, pasta and
  rice, vegetarian dishes, spicy food and desserts.
• A dish is "suitable" if it follows the classic pairing principles in the knowledge base; taste
  is personal and was not tested with users.

Implementation

The local model runs with a context window of 8,192 tokens: Ollama's default is smaller and
silently truncates the prompt (about 3,000 tokens with 10 chunks). Temperature is 0 and random
seeds are fixed (42).

Environment: developed and tested on an Apple M1 with 16 GB of memory, macOS, Python 3.13 and
Ollama 0.40. No GPU is needed. The dependencies take about 2 GB because sentence-transformers
installs PyTorch. Building the index takes about a minute.

Installation and usage

git clone https://github.com/KaiHoogenhoud/wine-pairing-rag-assistant.git
cd wine-pairing-rag-assistant
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env              # then set OLLAMA_MODEL=qwen2.5:7b or an API key

python src/app.py "A friend brought a Riesling, what can I make for dinner?"

The knowledge base is included in the repository, so no download is needed. Full instructions,
the configuration options and the project structure are in the repository README.

Evaluation

Method

• Unit tests (28, pytest) cover document loading (including broken and empty files),
  chunking, page cleaning, parsing of the LLM replies and the coverage check. They need no LLM.
• End-to-end evaluation runs 8 questions through the full pipeline and checks each answer:
  • scope: wine questions are answered; dish → wine and off-topic questions are redirected
  • dish: the answer names at least one suitable dish (keyword list per question)
  • coverage: for a wine missing from the knowledge base, the answer says so

The questions cover a full-bodied red (Barolo), a crisp white (Chablis), an aromatic white
(Riesling), a light red (Pinot noir), a style without a grape (sweet dessert wine), a wine outside
the knowledge base (Saperavi), a dish → wine question and an off-topic question.

Results

With qwen2.5:7b on the Apple M1, all 8 questions pass.

The keyword check confirms that a sensible dish is suggested, not that the explanation is right,
so all answers were also read by hand and their claims checked against the source text.

What the results show

• The fixes in code mattered more than prompt wording. The Saperavi, capital-of-France and
  curry questions all failed before the coverage check, the scope fallback and the double search
  were added. Rewording the prompts did not fix them with a 7B model.
• Retrieval needed a bridge between two vocabularies. Wine pages talk about tannin and
  acidity, recipes about beef and cream. The trait → food step is what makes the recipe search
  work.
• Tracing finds problems that a pass/fail evaluation misses. The evaluation passed while two
  of the six wine-knowledge chunks for Saperavi were irrelevant text about tannins in plants.
  Only the trace script showed it. After removing those pages, the Saperavi answer cites a real
  principle from the knowledge base ("fats and proteins can soften the perception of tannins").

Limitations

• Small knowledge base. 24 grapes, 13 regions and 51 recipes. Wines outside it get only
  general advice, and suggestions are limited to these recipes.
• Reasoning slips with a 7B model. Dish choices are usually good, but explanations can
  contain errors, for example that roast lamb "features beef". A larger hosted model makes fewer.
• Imprecise citations. The model sometimes cites a neighboring chunk instead of the one that
  contains the fact.
• Model knowledge in the search queries. The LLM writes the food search query and can add
  ideas that are not in the knowledge base. For Saperavi, the answer then called the wine
  "tannic", which the knowledge base does not say.
• Name-based coverage check. A synonym that the pages never mention is reported as missing.
• Speed. Three LLM calls take about 40 seconds with a local 7B model, a few seconds with a
  hosted model.
• Small evaluation. Eight questions and keyword checks show that the pipeline works, not how
  good the pairings taste; there was no user study.
• One direction, no memory. Wine → dish by design; each question stands on its own.

Deployment and maintenance

This is a working prototype for learning and demonstration, run locally from the command line.
Running it as a service for home cooks would need:

• A simple web interface (for example Streamlit or a small FastAPI app) instead of the terminal.
• A hosted LLM to bring answers down from about 40 seconds to a few seconds. The index itself
  is small (about 2,200 chunks) and the embedding model runs on a CPU, so a small server is enough.
• API keys kept on the server in environment variables, never in the code or the repository.
• Logging of questions, retrieved sources and answers, to spot failures such as wrong coverage
  verdicts or irrelevant chunks. The trace script already shows what to log.
• Re-running the evaluation after every change to the prompts, the model or the knowledge base.
• Refreshing the knowledge base now and then: re-run the download script, which records the
  revision of every page, and rebuild the index with --rebuild.

Future work

• Read the bottle label. Photograph a bottle and let a vision model extract the wine, grape
  and region, then run the existing pipeline. (Vivino's data cannot be used for this.)
• Write my own pairing notes. The data/pairing_notes/ folder and its template are ready,
  but no notes have been written yet. They would improve answers for wines with little food
  information on Wikipedia.
• A larger knowledge base and evaluation set, with an LLM-as-judge check of the explanations.
• A simple web interface for home cooks who do not use a terminal.

Access, license and support

• Code: github.com/KaiHoogenhoud/wine-pairing-rag-assistant,
  public. Version 0.1.0, built for the Ready Tensor Agentic AI Essentials program and maintained
  during the program.
• Code license: CC BY-NC-SA 4.0, because the project is derived from the Ready Tensor project
  template under that license. You may use, change and share the code for non-commercial
  purposes, with attribution and under the same license.
• Data license: the Wikipedia and Wikibooks texts are CC BY-SA 4.0. Every page is listed with
  its URL, revision and download date in data/SOURCES.md.
• Models: all-MiniLM-L6-v2 is Apache 2.0. The LLMs are not distributed with the project;
  their own terms apply.
• Questions and bugs: open an issue on the GitHub repository.

References

1. Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.
   NeurIPS 2020. https://arxiv.org/abs/2005.11401
2. Gao, Y. et al. (2023). Retrieval-Augmented Generation for Large Language Models: A Survey.
   https://arxiv.org/abs/2312.10997
3. Ma, X. et al. (2023). Query Rewriting for Retrieval-Augmented Large Language Models.
   EMNLP 2023. https://arxiv.org/abs/2305.14283
4. Gao, L. et al. (2023). Precise Zero-Shot Dense Retrieval without Relevance Labels (HyDE).
   ACL 2023. https://arxiv.org/abs/2212.10496
5. Huang, L. et al. (2023). A Survey on Hallucination in Large Language Models.
   https://arxiv.org/abs/2311.05232
6. Reimers, N. & Gurevych, I. (2019). Sentence-BERT: Sentence Embeddings using Siamese
   BERT-Networks. EMNLP 2019. https://arxiv.org/abs/1908.10084
7. Qwen Team (2024). Qwen2.5 Technical Report. https://arxiv.org/abs/2412.15115
8. Ready Tensor. RAG-Based AI Assistant Template.
   https://github.com/readytensor/rt-aaidc-project1-template