My meal planner chooses a week of dinners from about nine thousand recipes, and until a couple of weeks ago there was no vector database anywhere in it. I was quite pleased about that.
I built it in March: nine thousand markdown files, one per recipe, and a JSON index of titles, ratings and cooking times. Each week the planner reads the standing rules, searches the archive by file name, reads the recipes it picks in full and writes the plan and the shopping list. Left to me, dinner is the same four things on rotation, so it does something I can't, and in the one run I measured it did it with thirteen file searches, nine recipes read in full, about 1.6 million tokens (most of them cached) and about five minutes.
When I built it I assumed I'd be adding embeddings within a month. I never did, because everything it asked was a lookup: chicken, under forty minutes, rated four or better. I checked five weeks of runs and all 47 of its searches were lookups, and a file search answers a lookup exactly where a similarity search gives you the nearest thing. I had most of a post written about systems that have a vector database because the reference architecture had one, and here was one that didn't and worked.
Then I measured it before publishing, which was sensible and inconvenient in about equal amounts. Forty questions the planner asks or is asked to answer: twenty lookups, ten similarity ("something light, not another curry") and ten relationships ("uses up the feta and kale"), with the right answers fixed before any method ran and 330 dishes marked blind by me for the similarity ones. Five methods on the same archive, folded first from nine thousand recipes to about six thousand dishes because it holds thirty versions of spaghetti bolognese: today's file-name search, a lookup over the parsed fields, embeddings from a small open model on my own hardware, a graph of which dish uses which ingredient, and a hybrid of the embeddings with the field filters. A model wrote each tool's query from the tool's description, as a calling agent would.
Today's file search looks fine until you check what it missed. Its top ten was mostly right (0.79, where 1.0 is a perfect ten), but on the narrow questions it found two thirds of the right answers, and on chicken thigh with broccoli a fifth, because most of the chicken recipes have free-range chicken in the file name whatever the cut.
Embeddings on their own lost on all three kinds of question, including similarity, which I hadn't expected: 0.65 overall and 0.1 on "something light, not another curry". It returned curries. A "not" puts the unwanted word into the query and pulls those dishes closer, and saying it more firmly doesn't change the similarity score.
The hybrid won lookups and similarity, 0.99 and 0.89: embeddings rank by what you'd like, field filters carry every must-have and every "not". The graph won relationships at 0.91 and nothing else scored above 0.45. Two tools cover all forty questions, chosen by what the question asks for rather than by what the system happens to have. That is forty questions and one person's marks, and a fresh set of queries with identical wording moved the lookup score five points, so the numbers are directionally right, not precise.
So there is a vector database in the planner now, beside a small graph, and the embedding job I'd avoided for seven months took seven minutes. The harness is on GitHub, code only and no recipes, my first public repo: github.com/adriansaxton/question-shapes
I still think a lot of systems have a vector database because the reference architecture had one and nobody asked what kind of question it would be asked. I'd made the same mistake in reverse: right about the lookups, and never tested the two kinds of question I'd decided didn't matter at seven dinners. Leaving a tool out on an assumption is the same error as putting one in from a diagram, and forty questions is what it cost to find out.
Sources
- My own meal planner: the archive, its index and one measured planning run, October 2026.
- My own test on that archive, October 2026: forty questions (twenty lookups, ten similarity, ten relationships), five retrieval methods, right answers fixed before any method ran, similarity marked blind by me. The figures are from the private run; the recipe data is not published. The harness, code only: github.com/adriansaxton/question-shapes