Як avatarin і Yamada Denki запустили 24/7 retail voice agent на GPT‑Realtime

Японський ритейл побутової техніки має незручну економіку: покупцю часто потрібна консультація саме тоді, коли він порівнює моделі вдома, а досвідчених продавців неможливо нескінченно масштабувати по годинах, мовах і каналах. avatarin разом із Yamada Holdings взяла конкретний шматок customer journey — вибір товару — і перетворила знання консультантів на доступний 24/7 AI-інтерфейс.

Kurashi-Marugoto AI Agent працює не як FAQ, що чекає правильне ключове слово. За описом OpenAI, він веде природний голосовий діалог, враховує зміну вимог, ставить уточнювальні питання і супроводжує людину від discovery до рішення про покупку. Це важлива межа: джерела підтверджують консультацію та recommendation flow, але не дають підстав стверджувати, що модель самостійно оформлює або оплачує замовлення.

Trigger простий: покупець відкриває онлайн-досвід на PC, tablet або smartphone і починає діалог голосом або текстом. Input — не лише назва товару, а природний контекст: склад сім’ї, розмір кухні, бюджет, сумніви, бажані функції й зміни пріоритетів у процесі. OpenAI окремо зазначає, що GPT‑Realtime поєднує voice, text та image understanding у спільному conversational loop.

AI stage має дві різні задачі, які не варто змішувати. Перша — conversational reasoning: зрозуміти намір, поставити наступне корисне питання, пам’ятати поточні constraints і тримати розмову в домені покупки. Друга — grounding: отримати актуальну інформацію про товари через retrieval-augmented generation, щоб не перетворювати знання моделі на імпровізований каталог.

• Trigger → початок shopping conversation;
• Input → голос/текст, потреби, бюджет, контекст і за потреби зображення;
• Dialogue policy → які питання треба зібрати для конкретної категорії;
• Retrieval → актуальні product facts із контрольованого джерела;
• Recommendation → порівняння варіантів і пояснення trade-offs;
• Feedback → коротке голосове опитування після сесії.

З customer story відомо, що avatarin використовувала RAG для product information і вбудувала досвід продавців Yamada Denki в prompts та сценарії діалогу. Раніше команда вже застосовувала OpenAI API для speech recognition, inquiry analysis і employee training. Саме application layer, а не модель, має вирішувати, які каталоги читати, яку версію даних вважати актуальною і що робити, якщо inventory або price source недоступний.

Для повторення AI‑Magister рекомендує workflow `session → intent/context → category-specific questions → retrieval → grounded shortlist → clarification → recommendation → handoff/exit → survey`. Якщо згодом додати бронювання, кошик чи оплату, це вже інший authority tier: function call має пройти schema validation, identity/tenant checks, explicit confirmation та authoritative postcondition. Гарний голос не є платіжним дозволом — навіть якщо демо виглядає так, ніби майбутнє вже оформило кредит.

Для цього кейсу коректний рівень автономності — A3: система самостійно веде консультацію і формує next-best recommendation, але фінальна комерційна дія не делегована моделі у підтверджених джерелах. Yamada/avatarin у public campaign прямо попереджали, що AI-generated responses можуть бути неточними, неповними або неактуальними, і радили окремо перевіряти важливу інформацію.

Production error handling має розрізняти щонайменше чотири класи: немає релевантного товару, джерело каталогу застаріло/недоступне, модель невпевнено інтерпретує constraint, користувач просить дію поза consultation scope. У перших трьох сценаріях потрібні abstention або уточнення; у четвертому — чіткий handoff на офіційний checkout/support flow. Guardrail, який просто повторює «я AI», але дозволяє вигадати наявність товару, — це декор, а не контроль.

OpenAI повідомляє, що двотижневим public experience скористалися приблизно 30 000 людей, а 92% post-use survey responses були позитивними. avatarin окремо повторює 92% позитивного feedback. Це корисні adoption/satisfaction сигнали, але вони не є незалежним виміром recommendation accuracy, conversion uplift, incremental revenue або економії FTE.

Для production rollout потрібен ширший scorecard: grounded-product accuracy, unsupported-claim rate, clarification success, recommendation acceptance, session completion, handoff rate, latency p50/p95, cost per completed consultation, conversion after assisted session і return/cancellation quality. Survey score без denominator, sampling details та контрольної групи не варто перетворювати на магічний ROI.

Цей клас workflow природно високочастотний: кожен новий shopping session може запускати десятки realtime turns і кілька retrieval operations. Масштабування впирається не лише в requests per minute, а в concurrent audio sessions, latency retrieval layer, cache hit rate, довжину контексту, peak traffic і обсяг product catalog. Сам Yamada/avatarin public campaign мав загальний processing-capacity limit і попереджав, що нові розмови можуть тимчасово бути недоступними при піку.

Вартість треба рахувати як `realtime audio/text tokens + retrieval/index + application infrastructure + observability + eval/review + human escalation`. Поточні OpenAI model pages показують окрему ціну для audio, text і cached input, тому «ціна одного запиту» тут майже беззмістовна. 80/20 оптимізації: коротший system prompt, category-specific context замість всього каталогу, retrieval лише коли потрібен factual lookup, truncation strategy і model routing для дешевших простих turns — але кожну економію проганяти через voice-quality та task-success evals.

Почніть з однієї товарної категорії, де рішення потребує 4–8 стабільних параметрів і каталог має надійний source of truth. Зберіть 50–100 реальних діалогів продавців, виділіть questioning policy, hard constraints і ситуації, де консультант відмовляється радити. Після цього підключіть realtime conversation до read-only retrieval і забороніть будь-які mutating actions у першому pilot.

Release sequence: offline replay на історичних сценаріях → shadow/employee pilot → обмежений public canary → масштабування за success/failure budgets. Для кожної сесії зберігайте versioned trace: model/snapshot, prompt, retrieval documents/versions, latency, errors, final recommendation і feedback. Новий catalog schema, prompt або model revision — це зміна behavior envelope; вона має проходити той самий eval set, а не їхати в production під традиційним прапором «ми лише трошки підправили промпт».

• Визначити одну категорію, outcome і authority boundary.
• Оцифрувати playbook сильного продавця та refusal rules.
• Підключити read-only product retrieval із freshness metadata.
• Зібрати eval set: happy paths, conflicting constraints, stale/no-result і adversarial inputs.
• Виміряти task success, groundedness, latency, cost і handoff quality.
• Лише після стабільного pilot додавати checkout/tool actions окремим контрольованим tier.