Як Wayfair масштабує catalog quality і supplier support з OpenAI

Wayfair працює з каталогом приблизно у 30 млн товарів і десятками тисяч постачальників. У такому масштабі дві проблеми швидко стають системними: некоректні або неповні product attributes погіршують пошук і довіру до покупки, а supplier support створює великий потік неструктурованих ticket-ів, які треба зрозуміти, збагатити контекстом і правильно маршрутизувати. Окрема custom model на кожен із десятків тисяч tags — архітектурний шлях до дорогого зоопарку.

Wayfair пішов у бік reusable AI architecture: один model-driven framework для catalog classification та agentic Wilma flows для supplier operations. Для відтворення важливо розділити два контури: data-quality automation може змінювати product metadata лише за визначених confidence/risk умов, а support automation може читати ticket, добирати context і маршрутизувати або пропонувати next step, але не отримує необмежену authority на фінансові чи policy-sensitive рішення.

Catalog trigger — новий або проблемний attribute, зміна definition, supplier correction чи scheduled reprocessing. Input — canonical tag definition, product data, category context, approved external definitions і risk class. Supplier-support trigger — створення або новий comment у SupportHub. Input — ticket text, sender role, supplier/product identifiers, historical context і task-eligible database records.

AI stage для catalog: definition agent формує contextual meaning tag-а, classifier застосовує його до product data, confidence/risk gate визначає autopublish або supplier confirmation. Для Wilma: intent/language classification, database lookup/tool use, ticket enrichment, routing або case-specific recommendation. Integrations — OpenAI API, internal product data, BigQuery/operational databases, Pub/Sub/eventing та SupportHub/Jira-like ticket system. Output — corrected attribute із trace або structured ticket metadata, route, reason і draft next step.

• Trigger → catalog event або supplier ticket event.
• Input → authoritative product/supplier context + task-specific evidence.
• AI → define/classify або classify/retrieve/tool-call/synthesize.
• Integrations → OpenAI, data warehouse, event bus, SupportHub.
• Output → verified metadata change або support routing/recommendation з audit trace.

OpenAI описує staged Wayfair pattern від co-pilot до autopilot, коли рекомендації моделі стабільно збігаються з фінальними рішеннями людей за внутрішнім alignment threshold. Це сильний operational signal: autonomy підвищується не за презентацією vendor-а, а після вимірюваної поведінки на конкретному workflow.

Для production reproduction alignment недостатній як єдиний gate. Потрібні slice-specific thresholds для high-risk tags, supplier identity, refunds/financial implications, rare classes і no-answer. Навіть висока середня alignment може приховувати катастрофічну помилку в малому, але дорогому сегменті. Authority matrix має бути детермінована application layer: які fields можна overwrite, які лише suggest, які завжди потребують supplier/associate confirmation.

Wayfair не обмежився model-vs-human review у таблиці. Для частини catalog changes команда використовувала hands-on audits із фізичним оглядом товарів і supplier validation. Це важливий pattern: коли ground truth існує поза текстовими джерелами, evaluation має дістатися до нього, а не замкнутися у LLM-as-a-judge.

Людина лишається owner-ом exception policy, high-risk classification і disputed changes. У supplier support associate втручається для складних або чутливих випадків; у catalog — supplier confirmation є fallback, якщо confidence/risk gate не дозволяє автоматичний overwrite. HITL черга повинна ранжуватися за severity і expected impact, інакше вона просто перетворює automation на новий backlog.

Критичні failure modes: ticket прив’язаний до неправильного supplier ID, lookup повернув неоднозначний результат, event доставлено повторно, catalog definition застаріла, model upgrade змінив decision boundary, SupportHub update timeout-нув після фактичного запису або catalog write застосувався частково. Blind retry після write тут небезпечніший за звичайний timeout.

Кожен write отримує idempotency key та expected version. Після timeout система спочатку читає authoritative state, звіряє ticket/catalog version і лише потім retry-ить. Ambiguous identity переводиться у clarification/manual queue. Якщо source definition stale або conflict-ить із supplier evidence, automation знижує authority до suggestion. Model fallback не може тихо розширювати перелік writable fields.

Eval corpus має slices для popular/rare tags, ambiguous attributes, multilingual supplier tickets, missing identifiers, adversarial text, conflicting database records, stale definitions, duplicate events і tool timeouts. Graders окремо оцінюють intent, supplier identity, reason code, tool arguments, unsupported claims та authoritative postcondition після write.

Wayfair Tech Blog для real-time intervention Wilma описує precision, recall, reason accuracy і timeliness, але ці company-reported результати належать конкретному STP workflow, а не всій Wayfair AI architecture. Для reproduction release gate має включати business cost: false negative, що пропустив escalation, і false positive, що дарма відправив кейс людині, мають різну вагу. Production incident мінімізується в test case і назавжди входить у regression suite.

Wayfair повідомляє про 41 тис. automated supplier tickets на місяць і production processing понад мільйона товарів. На такому масштабі cost model — це inference плюс event processing, database queries, data pipelines, support system writes, observability, eval infrastructure, human exception review і model/definition maintenance. Дешевий token не компенсує дорогий false write.

Scalability починається з deterministic prefilters: не все треба відправляти frontier model-у. Простий sender role, known ID або exact rule вирішуються без LLM. Batch reprocessing для catalog відділяється від latency-sensitive support events. Cost-per-verified-correction і cost-per-correctly-routed-ticket корисніші за cost per API call.

Крок 1 — обрати один supplier intent або один низькоризиковий catalog attribute з чітким oracle. Крок 2 — shadow mode без writes. Крок 3 — co-pilot із structured rationale та human decision capture. Крок 4 — додати tools і idempotent ticket enrichment. Крок 5 — autopilot лише для reversible/low-risk cases, які стабільно проходять slice gates. Крок 6 — canary model upgrades, drift monitoring і rollback до pinned configuration.

Підходить marketplaces, retail catalog, procurement networks і B2B support, де є великий repetitive stream та authoritative systems. Не підходить для процесу, де немає чіткого source of truth або owner-а, який може визначити наслідки помилки. 80/20 старт — triage/enrichment, а не автоматичні refund-и, catalog rewrites і supplier sanctions в одному спринті.