Choosing a RAG technique before anyone has looked at the data is how projects end up paying a model to read fields a database already owns. Angela Shi makes this case with a diagnostic grid over at Towards Data Science, crossing how structured your documents are with how controlled your questions are. The grid matches what I keep seeing on store work: requests for AI product search where a plain query would answer the question.
Choosing a RAG technique when the data is already structured
The article’s document axis has five tiers, from fixed templates where you can pull a field by its position on the page to engineering drawings where the meaning lives in the pixels. The question axis runs from a prompt an engineer wrote and calibrated to a user typing whatever comes to mind. Cross the two and each cell points at a technique: regex, section retrieval, hybrid retrieval, or a vision model.
A WooCommerce catalog sits in the top-left corner by construction. The platform enforces the schema, so every product is a row you address by field name: SKU, price, stock status, category, attributes. The extraction problem that needs a hundred lines of regex on a scanned insurance certificate is a wc_get_products argument here. Shi’s claim that most enterprise workflows land in this corner and get over-engineered there reads like the average store feature request.
Her example is an LLM stack quoted at sixty thousand euros a year for a document set where regex would do. The store version costs less but has the same shape: an embedding pipeline, a vector store, a monthly API bill, all to answer questions the product tables already know.
What the plain query gets you
The article gives three reasons to pick the least powerful technique that works: cost, latency and reliability. All three land on a store. A query costs nothing. It runs in milliseconds, so it survives a bot crawl or a sale-day spike. And it either matches or it doesn’t, which means you can review the rule, write a test for it, and audit it months later. With model output you get answers that are usually right, and no diff to read.
The right instinct is to pick the least powerful technique that solves the actual problem.
Concretely, a request like “find all jackets under 120 that are in stock” is four arguments:
$ids = wc_get_products( [
'category' => [ 'jackets' ],
'price' => [ 'max' => 120 ],
'stock_status' => 'instock',
'status' => 'publish',
'limit' => -1,
'return' => 'ids',
] );
// filter first, no model call anywhereThat’s the documented, data-agnostic way to pull products, per the wc_get_products and WC_Product_Query reference. The argument list covers most requests I get for “smart” product finders. For custom fields there’s WP_Meta_Query over the same rows. The article prescribes this shape for corpus-scale questions anyway: filter first, retrieval second. So the query version you build first stays in production, and the model gets added only where the filter runs out.
The middle band on a store is smaller than the demos
None of this says embeddings are useless on a store. The middle band of the grid is real, and it shows up in two places. First, vocabulary mismatch: a shopper who types “something for a rainy commute” will not hit an attribute called “material shell”. The question is free-form, the answer lives in prose, and no filter tuning fixes that. Second, policy content: shipping terms, care instructions, sizing pages, supplier-written descriptions in six different voices. These are open questions over mixed text, and the answers should cite a section.
This is where the other side has a point, and I want to be fair about it. For open-ended matching, a keyword query misses and looks confident doing it, which is its own failure mode. I’ve written before about where semantic search stops paying for itself in WooCommerce, and if you do build retrieval for this band, precision becomes a separate decision from recall.
The question axis matters as much here. Admin and merchandising questions are usually engineer-templated, tier A, because the person asking knows the fields exist. Shopper questions are tier C or D, free and ambiguous. The article’s example of a system that asks “which coverage did you mean” instead of guessing is the behavior I’d want from store chat before it quotes a return policy at someone.
Long context doesn’t replace retrieval
Every few months someone declares RAG dead because context windows grew. The article leans on Liu et al., Lost in the Middle (TACL 2024), which found that models read the start and end of a long input well and routinely miss the middle. The paragraph you need can sit inside the prompt and still never be read. On a store there’s a second problem: an answer pulled out of a giant prompt has no citation trail. “Yes, we ship to Canada” should link to the policy section it came from, and only retrieval gives you that.
What to test first
Write the query version of the feature first and put it in front of whoever asked for the AI version. Then look at the questions people actually ask (site search logs, support inbox, chat transcripts) and count how many the query answers. That number tends to run high for internal and merchandising features and low for shopper-facing search, and the split tells you where the budget should go. You can run the whole diagnostic for choosing a RAG technique on a whiteboard.
Watch data quality while you’re at it. The deterministic route fails quietly when prices live inside descriptions, or attribute names are typed three different ways across the catalog. That’s the store version of template drift, and it’s why the article’s hybrid shape is the right target: a deterministic core that handles the bulk, with a model as fallback for the rows the filter can’t classify. Decide up front what triggers the fallback. (I’m less sure this holds for marketplaces where suppliers upload raw spec sheets, but those are tier 4 documents in the article’s terms, which is a different build.)
If you’re weighing a feature like this on a store, I’m glad to run the diagnostic against your catalog and tell you which corner of the grid it lands in before anyone writes an embedding job.
The one case for skipping the cheap version entirely is genuinely open questions over prose. A filter that returns nothing looks like an answer, and on a product page that’s worse than a slower answer that cites where it came from. If your questions are free-form and your content is prose, budget for retrieval from day one.
