AI 运营 ·
The data problem hiding behind most "AI didn't work for us" stories
An AI tool given inconsistent product data will produce confident, inconsistent output. The fix is almost always upstream of the tool, in fields most SMEs have never had a reason to standardise.
英文原文 — 本篇文章的中文版本尚未发布。
An SME that points an AI tool at its live product catalogue and gets inconsistent or wrong output is usually diagnosing the wrong layer of the problem. The model did not misunderstand the request. It was handed data that does not mean the same thing from one row to the next, and it produced a confident answer regardless, because that is what these tools do with any input — at the point of output, confident and wrong looks identical to confident and right. In most cases we see, the fix is not a better tool. It is the catalogue underneath it.
What "clean enough for AI" actually requires
Google's product data specification for Merchant Center is useful here — not because most SMEs feed Merchant Center directly, but because it is a fully worked example of what a machine consuming product data at scale needs in order to function at all: a stable unique ID per item, a structured title and description within defined length limits, a price in the prescribed numeric-and-currency format, an availability status from a fixed set of allowed values (in_stock, out_of_stock, preorder, backorder — not free text), a brand field when the item requires one, and a group identifier that ties size or colour variants of the same product together. The document is explicit about what breaks the pipeline: missing required product information can prevent a product from serving, inaccurate information can create approval and quality problems, and Google's price guidance separately requires the feed price to match the landing page, structured data, and checkout — three systems having to agree on one fact.
That list is a reasonable checklist for any AI tool an SME plugs into its catalogue, not just a shopping feed. An agent asked to answer a customer's stock question, generate a product description, or route a return needs the same things Google's spec needs: one stable identifier per product that every system agrees on, a status field with a fixed set of allowed values rather than whatever text a staff member typed that day, and one source of truth for price rather than three spreadsheets that drift apart after the first manual edit to any of them.
Where SME catalogues actually break
The pattern we see most often is not missing data. It is data that exists in three places and means something slightly different in each. A price updated in the storefront admin panel but not in the spreadsheet an agent was pointed at. A "color" field that is a controlled dropdown on one channel and free text on another, so "Navy," "Navy Blue" and "深藍" become three values for one product. A stock status accurate at the moment of a manual count and stale for the two weeks until the next one. None of these are AI problems. They are the ordinary data-quality problems SME operations have always carried. What changed is who reconciles them: a person working the catalogue did it quietly, by judgment, and an automated tool reconciles nothing — it takes the field at face value and acts on it.
The variant-attribute case deserves calling out on its own, because it compounds. Google's spec requires an Item Group ID to tie size and colour variants of one product together. Get that identifier wrong or inconsistent and every downstream system built on the catalogue, AI-driven or not, inherits variants that look like separate products, or products that look like duplicate variants. This is exactly the mapping-layer failure described in a companion note on where automation pays off: the API validates the shape of the data, not whether the shape means the right thing.
What to do before adopting a tool, not after
Pick the one field most AI tools will touch first — usually stock status or price — and confirm there is exactly one place it lives that every system reads from, not three that get synced by hand. Standardise the vocabulary for any field an automation will branch on: a fixed status list rather than free text, one canonical spelling per attribute value rather than three variants of the same word across channels. And assign one stable ID per product that survives a re-listing, a channel migration, or a rename, because every automation built afterward — AI or not — is only as reliable as the identifier it uses to find the same product twice.
So what
Before evaluating a new AI tool against the catalogue, run the smaller test first: pick ten products and check whether their price, stock status, and variant grouping agree across every system that currently touches them. If they do not agree today, no tool will make them agree once it is layered on top — it will simply produce a confident answer built on whichever version of the data it happened to read. That data-readiness check, run before a tool is chosen rather than after it disappoints, is the first step ELELAND AI (in development at eleland.ai) walks SME sellers through.