A requested feature that ships and then goes unused is usually a delivery problem, not a quality problem. I compare three surfaces for store-owner data in WooCommerce: a standalone dashboard page, a scheduled email, and a column inside the orders list, with the HPOS hooks for the last one.
Embeddings handle synonyms and typos, then quietly fail on SKUs, product tiers, and anything private to your store. A long Towards Data Science piece on RAG failure modes explains why, and most of it maps straight onto WooCommerce search.
Clients keep asking for AI product search on stores where the catalog is already a database. Before anyone writes an embedding job, run the plain query and see what it answers. Here is where RAG genuinely fits on a store, and where a filter wins.
DAX lineage is a tag that says which model column a value came from. Break it with a little arithmetic and your filter stops filtering, with an error that points at the wrong line. I cover what breaks, what TREATAS does, and when the model needs a relationship instead.
The Chatbot Arena ranks language models with one question: which answer is better? The Bradley-Terry model explains how that works, and it maps onto store ranking jobs nicely. I walk through the math, a PHP fit, and the failure modes to expect.
An agent answering store questions is only as good as the definitions underneath it. Before wiring one to a WooCommerce database, know where the numbers actually come from: post tables or HPOS, lookup tables or raw orders, and what revenue even means.
Adding a cross-encoder reranker to store search sounds like the obvious upgrade. The tests I read suggest it rarely beats a better embedding, costs hundreds of milliseconds per query, and only clearly wins when answers sit buried in long text. Filters, synonyms and SKU lookups come first.
A RAG pipeline on WordPress lives or dies on what post_content actually contains. This post covers the three parsing traps behind most retrieval misses, a short function to clean content for indexing, and how to debug failures by tracing queries instead of tuning models.
Smashing Magazine’s June wallpaper drop includes 4K files, and WordPress will quietly scale them to 2560px unless you stop it. Here’s what the big image threshold does to downloads, why the usual one-line fix is too broad, and what I’d do instead.
WordPress has no Markdown parser in core, so the rendering is always yours to wire up. The tempting shortcut is to echo the parsed HTML straight out. On a WordPress site that string usually comes from user input, so it needs wp_kses before it reaches the page.