On a recent architecture assessment assignment, we got the opportunity to review a proposed solution for an established ecommerce platform.
The business goal was straightforward enough. The company had accumulated a large amount of content over the years:
- product information
- recipes
- blogs
- podcasts
- buying guides
- customer preferences
They wanted to introduce more personalization and AI-assisted experiences into the platform.
Things like:
- “What can I use as a substitute?”
- “What am I missing from this recipe?”
- “People like me also bought…”
- “Related recipes and products”
- “What should I buy next?”
The proposed solution was equally straightforward. Take all the content, generate embeddings, store them in a vector database and place an LLM in front of it.
This is increasingly the default instinct industry-wide: if a system touches unstructured content, especially in a variety of forms, reach for agentic and retrieval-based patterns before asking whether the problem is actually generative at all.
A lot of that instinct is justified.
Over the last few years, our industry has become very good at identifying places where AI can be applied.
We have become less disciplined about identifying places where AI shouldn’t/needn’t be applied.
A lot of the requested features looked intelligent on the surface but were surprisingly deterministic underneath.
Consider a few examples.
- “What am I missing from this recipe?”
If the ingredients required are known and the ingredients available are known, this is largely a comparison problem.
- “What can I use as a substitute?”
If substitution rules already exist and can be curated, this is primarily a lookup problem.
- “People who bought this also bought…”
This has been solved using recommendation techniques long before LLMs existed.
- “Related products” and “Related recipes”
If relatedness can be defined by shared tags, category, or purchase history, this is a ranking problem, not a generation problem.
None of these requirements become better simply because a vector database is involved. Most of them were recommendation, ranking or lookup problems masquerading as AI problems.
In fact, forcing retrieval and generation patterns into deterministic workflows can introduce problems that were never there in the first place.
- Costs increase because every request now involves retrieval and model execution.
- Latency increases because simple lookups become multi-stage AI workflows.
- Explainability becomes harder because recommendations are now based on similarity scores rather than explicit business rules.
- Every feature becomes dependent on a model and a vendor, including features that were perfectly capable of running as a database query.
After a healthy amount of discussion, we arrived at a much simpler (and cost effective) architecture.
- Relational data and curated tags handled most recommendation and substitution scenarios.
- Precomputed similarity relationships were generated offline and served as simple lookups.
- Existing recommendation techniques handled “people also bought” style features.
- AI was reserved only for places where the signal was genuinely unstructured.
Interestingly, we still ended up using embeddings.
Recipe narratives and customer reviews contained information that never existed in structured product data. The ingredient list might tell you what is in a recipe. The description and reviews often tell you why people choose it.
Whether it is:
- quick and convenient
- kid friendly
- suitable for diabetics, etc.
Those signals are rarely captured as structured attributes. This is where embeddings genuinely added value, trying to extract meaning from unstructured human language.
So, embeddings survived the architecture review. The vector database didn’t.
We often speak about embeddings, vector databases and RAG in the same breath, but they are not the same thing. One does not automatically require the other.
The result was a system that was simpler, cheaper, faster and easier to explain.
It is a mistake to assume that every problem involving content automatically becomes a retrieval problem and every retrieval problem automatically needs AI.
| Requirement | Initial AI-Heavy Approach | What We Actually Needed |
|---|---|---|
| What am I missing from this recipe? | Embeddings + Retrieval + LLM | Compare required ingredients with available ingredients |
| What can I use as a substitute? | RAG over recipes and products | Curated substitution rules and lookups |
| People who bought this also bought… | Vector similarity search | Traditional recommendation engine |
| Related recipes and products | Embeddings + semantic retrieval | Ranking using tags, categories and purchase history |
| What should I buy next? | AI-powered assistant | Recommendation and ranking logic |
| Recipe moods and use-cases (“comfort food”, “quick weekday meal”, “kid friendly”) | Structured tagging | Embeddings over recipe narratives and reviews |
Good architecture has always been about choosing the simplest solution that adequately solves the problem. And that principle has not changed, only our toolbox has expanded.
This architecture was balanced and optimized for the problem that existed today, for this client, at this scale.
A future version of the platform may well justify embeddings, retrieval, memory and agentic workflows. The interesting question is what would need to change before those become the right tools for the job.
We’ll come back to that.
Team Cennest