Short answer: RAG is very good at finding what the brewing literature says and quite bad at doing what it says. Point it at your textbooks, papers and lab methods, chunk them so a formula never gets separated from its units, use hybrid search because brewing is full of abbreviations that embeddings blur, and make every answer cite the passage it came from. Then take the arithmetic away from the model entirely. It retrieves the formula for the explanation. A tested tool computes the number.
Ask a general chatbot how to work out the alcohol in a beer from its original extract and real degree of fermentation. You will get a confident paragraph and a formula. Sometimes it is the right formula. Sometimes it is the homebrew shortcut that works on specific gravity, dressed up with Plato numbers it was never meant for. Either way, the number at the end has been worked out in the model’s head, and that is where the trouble starts.
This is the first post in The Brewer’s Agent, a series on building GenAI tools for brewing that a brewer can actually trust. It picks up where The Cellar Ledger left off in the winery: the model is only as good as the data and the tools underneath it.
What RAG actually does
Retrieval-augmented generation is a simple idea. Before the model answers, a search step pulls the most relevant passages from a collection you control. The model then answers from those passages rather than from memory.
For a brewery, that collection might be:
- a few textbooks and the chapters people actually use
- published papers on hop chemistry, mashing and fermentation
- your own lab methods and SOPs
- supplier specifications and certificates of analysis
The payoff is not that the model gets cleverer. It is that the answer comes from a document you chose, and the answer can tell you which one. A brewer can open the page and check. That habit, checking the source, is the whole safety system.
Chunking: where brewing documents break
Documents are split into chunks before they are indexed, and most RAG failures in technical fields start right here.
The default approach splits text every thousand or so characters. Brewing literature is full of formulas followed by a line explaining the symbols, the units and the temperature basis. Split in the wrong place and one chunk holds the formula while the next holds “where OG is in degrees Plato at 20/20 degrees C”. The model retrieves the first and guesses the second.
Rules that fix most of it:
- Keep a formula with its definitions. Split on section boundaries, not character counts, and treat an equation plus the paragraph after it as one unit.
- Keep tables whole. A hop utilisation table without its header row is a list of numbers. Store the whole table, headers, footnotes and all, as one chunk even if it is long.
- Put the conventions in metadata. Store the units, the temperature basis and the source edition alongside each chunk. Plato at 20/20 degrees C and specific gravity at 60/60 degrees F are not interchangeable, and the model needs to see which one it is holding.
- Parent retrieval for long derivations. Index small chunks for precise matching, but hand the model the whole section they came from.
Hybrid search, because brewing speaks in acronyms
Vector search finds passages with similar meaning. That is great for “why does my lager taste of cooked sweetcorn” landing on DMS. It is less good for terms where one letter matters.
RDF and ADF are two different measures of attenuation, and on the same beer they can be more than ten points apart. To an embedding model they look almost identical: short, capitalised, about fermentation. A keyword search (BM25 or similar) treats them as the different words they are.
So run both and merge the results, then let a reranker put the most relevant passages first. Most vector databases and search services now support this out of the box. It is the single cheapest improvement you can make to a technical RAG system.
Retrieval for knowledge, tools for arithmetic
Here is the rule this whole series rests on. The model may explain a formula. It may not evaluate one.
Take the question in the figure. A 13.0 degrees Plato wort fermented to a real degree of fermentation of 64.9%. What is the ABV?
Done properly, that goes through Balling’s relationship between extract consumed and alcohol produced, gives a real extract of about 4.77% and an alcohol of about 4.27% by weight, then converts weight to volume using the beer’s own density. The answer is 5.46% ABV. Every step has a constant with four decimal places and a unit convention attached.
A language model asked to do that in its head will often get close. Close is the problem. It will occasionally drop a step, use the wrong density or swap weight for volume, and it will present 4.3% with exactly the same confidence as 5.46%. Nothing in the prose tells you which answer you got.
The fix is architectural, not a better prompt. The retrieval step supplies the explanation: what RDF is, why weight and volume differ, where the constants come from. A calculation tool, ordinary tested code, supplies the number. The next post builds those tools. For this one, the point is that the RAG system should route the arithmetic out, and say so in the answer: “computed by the ABV tool from OG and RDF”.
Citations are the feature
Every answer should carry its sources: the document, the section and ideally the page. Make it a hard requirement in the system prompt and check it in testing. An answer with no citation should be treated as a failed answer, however good it sounds.
Two small things make citations far more useful:
- Show the passage, not only the title. A brewer glancing at the quoted paragraph will spot a wrong edition or a homebrew source faster than any automated check.
- Say when nothing was found. If retrieval returns nothing relevant, the right answer is “I do not have a source for that”, not a fluent guess from general knowledge. Test that behaviour on purpose, because models are trained to be helpful and will fill the gap if you let them.
Where this breaks
Your corpus has opinions. Textbooks disagree on hop utilisation, homebrew sources use shortcuts that commercial labs would not, and older editions carry superseded methods. RAG faithfully retrieves whichever passage matches best. Curate the collection, tag the source type, and prefer your own lab methods where they exist.
Scanned PDFs lose the maths. OCR turns subscripts, Greek letters and fractions into noise. A formula that reads “E = P/100” in the book may come out as “E - Pl100”. Check the extracted text for your most-used formulas by eye before you trust the index.
Copyright still applies. Indexing a textbook for internal use is one thing. Letting the model quote long passages to people outside the company is another. Know what licence covers the documents you index.
Citations can be fabricated too. A model can produce a reference that looks right and was never retrieved. Build the citation from the retrieval metadata in code, not from the model’s text.
The bottom line
RAG turns a pile of brewing literature into something you can ask questions of, and the answers point back to the page. That is genuinely useful. What it does not do is make the model good at arithmetic, and brewing is mostly arithmetic with conventions attached. Chunk so formulas keep their units, search with keywords as well as meaning, insist on citations, and send every number to a tool. The model reads the book. The calculator does the sums.
For the wider picture of what AI is doing in breweries right now, see What AI in Beer Actually Looks Like in 2026. The full list is on The Brewer’s Agent series page.
Frequently asked questions
What is RAG and why use it for brewing knowledge? Retrieval-augmented generation means the model looks up passages from your own documents before it answers, and answers from those passages. For brewing, that keeps answers tied to the textbooks, papers and lab methods you trust, instead of whatever the model half-remembers from the internet, and it lets every answer cite its source.
Can a RAG system calculate ABV or IBU correctly? It can find the right formula, but it should not do the sums. Language models are unreliable at multi-step arithmetic, and brewing formulas have unit and temperature conventions that are easy to mix up. Retrieve the formula for the explanation and send the numbers to a tested calculation tool.
How should brewing documents be chunked for retrieval? Keep formulas, their variable definitions and their units in one chunk, and keep tables whole with their headers and footnotes. Store metadata such as the temperature basis and units with each chunk. Splitting on a fixed number of characters routinely separates a formula from the line that says what its symbols mean.