A catalog is more than a text task

A small retailer’s catalog may have accumulated over years: supplier names differ, units are inconsistent, attributes are missing, and one item may appear under several descriptions. Managers manually adapt listings for a website, marketplace, or internal accounting system. The work is repetitive, but errors do not have equal consequences: a wrong color may be spotted quickly, while a wrong size, material, or compatibility claim can trigger a return or complaint.

A language model is useful here not as an autonomous editor that receives the entire catalog and a publish button, but as an assistant for parsing inconsistent inputs. It can propose a canonical name, extract attributes from descriptions, and map them into predefined fields. Yet a model’s suggestion is not a verified fact and should not automatically overwrite the master record.

First define the unit economics

Count one approved listing that has passed your rules and is ready to publish—not “how many listings the model processed.” Include:

  • model or API charges and retries;
  • staff time spent checking, correcting, and resolving exceptions;
  • preparation and cleanup of source data;
  • integration, monitoring, and operating the system;
  • sample-based checks after changing a prompt, model, or product rule.

A simple pilot formula is:

cost per approved listing = (inference + review + corrections + allocated infrastructure and integration) / number of accepted listings.

To compare against manual work, measure the current minutes per listing and the fully loaded hourly staff cost. Less generation time is not a saving if review takes longer. Conversely, even partial automation can help if it frees specialist time for exceptions, supplier discussions, and quality control.

A hypothetical example—only to demonstrate the method, not a market rate: suppose manual preparation takes 6 minutes and the loaded staff cost used for the calculation is RUB 600 per hour. Direct labor is about RUB 60 per listing before overhead. In an AI-assisted flow, assume one minute of review, an average of 20 seconds for corrections, and RUB 8 for processing and infrastructure. That is roughly RUB 20 in direct cost per listing. If review instead takes 4 minutes, the total becomes about RUB 50. This is why human time must be measured separately rather than hidden behind token prices.

Architecture: the model proposes, rules validate, a person approves

A pilot can use a CSV export or catalog copy without immediately connecting a live accounting system:

1. Preserve the original ID, name, description, SKU, and existing attributes. Do not let the model change keys or create records.
2. Prepare a reference list of allowed categories, units, values, and completion rules. Where information is absent, define an explicit “unknown” value instead of asking the model to guess.
3. Send one listing or a small batch with instructions to extract only supported facts. Ask for structured fields and a short source-text excerpt for each disputed value.
4. Accept the response only after programmatic schema and business-rule checks. JSON Schema can describe required fields, types, and value constraints; that helps reject malformed output, but does not prove that the content is true.
5. Show the operator a “before / proposed / evidence / warning” comparison. The employee approves or corrects the result. The original listing remains unchanged until explicit approval.
6. Record the accepted version, decision-maker, model, prompt version, and rejection reason. Keep the source file and a rollback path.

In a local setup, Ollama supports formatting output according to a JSON Schema through its API and Python/JavaScript libraries. This is an example of an available mechanism, not a guarantee that a particular model will be accurate: check the server and library versions, model compatibility, and whether outputs actually satisfy your schema. Then run an independent application validator and business rules. A cloud API can follow the same “structure plus checks” principle, but data location and contractual terms differ.

What to measure

Do not start by normalizing the entire assortment. Take 300–500 SKUs of one type with similar structure, while retaining difficult and incomplete records. Separately set aside 50–100 listings whose correct values staff have established in advance: this is a holdout set, not prompt-training data.

Track several measures rather than one overall percentage:

  • share of proposed values accepted without edits;
  • missing values and cases where the model guessed at absent information;
  • accuracy of critical attributes—size, material, compatibility, pack quantity;
  • review time and the share of listings sent for manual clarification;
  • duplicates, reference-list conflicts, and import errors;
  • cost per accepted listing and time from export to publication.

Use deterministic rules for numbers and units wherever possible: format conversion, range checks, and reference matching. Leave ambiguous text matching and context extraction to the model. Its own confidence score does not replace measurement on a labeled sample.

Deciding whether to scale

A pilot succeeds not when its JSON looks tidy, but when it reduces the total cost per approved listing without lowering quality and while meeting the required turnaround time. Set thresholds beforehand: for example, critical attributes must exactly match the reference, while disputed listings always go to a person. Choose thresholds based on the consequences of errors, not on a desire to report a high automation percentage.

If the catalog contains many scans, tables, or images, OCR or image processing becomes an additional stage with its own validation and cost. If source data is systematically wrong, a model will not fix the cause—it may only reproduce inconsistencies faster. Fix reference data and rules first, then broaden coverage.

Limits and safeguards

Structured output constrains the shape of a result, not its truth. A model can return a valid value from the wrong field, miss an important qualifier, or confidently fill a gap. Therefore, price, composition, certification, medical purpose, compatibility, and other consequential claims should not be accepted without verifiable evidence and the planned specialist review.

For a local deployment, separately calculate equipment, electricity, updates, and support; local does not mean free and does not remove access-control requirements. In any setup, minimize personal data in the workflow, limit access to exports, keep source catalogs out of logs, and set a retention period for test files. Review the diff before import, not just the number of processed rows.

A practical next step

Choose one category, save a copy of the source catalog, and annotate a holdout sample with a staff member. Compare the manual process and AI suggestions on time, corrections, critical errors, and cost per accepted listing. If the measured benefit is real, move to the next step: batch preparation with operator approval, then only safe fields and controlled write-back.