Когда ИИ галлюцинирует: типичные ошибки в e-commerce и как их ловить
Языковая модель может с абсолютной уверенностью сказать тебе, что комиссия Ozon в твоей категории 17%, хотя реально 21%. Может рассказать о продажах за прошлую неделю по артикулу, которого вообще нет в природе. Это не баг и не злой умысел — это сама природа технологии. Разбираем почему так происходит, где это особенно опасно для селлера, и какие есть инженерные способы себя защитить.
Что такое галлюцинация на самом деле
Языковая модель не знает фактов в том смысле, как знает их человек. Она знает закономерности языка и научилась предсказывать, какое слово вероятнее всего идёт следующим. Когда ты спрашиваешь «какая комиссия Ozon на одежду в 2026 году» — модель не идёт в справочник, она реконструирует ответ как наиболее правдоподобную последовательность слов. Если в её обучающих данных эта цифра была — она вспомнит. Если нет или была неточно — она достроит правдоподобную, основываясь на похожих случаях.
Галлюцинация — это когда такая реконструкция выглядит уверенно, оформлена грамотно, читается как факт — но в реальности не соответствует действительности. И ключевая проблема в том, что внешне честный ответ и выдуманный ответ выглядят одинаково. Модель не подаёт сигнал «вот тут я не уверена». Этот сигнал должен подавать ты — задавая правильные рамки и проверяя.
Где это особенно больно для селлера
Выдуманные комиссии и тарифы
Самый распространённый случай. Спрашиваешь о комиссии в категории, о ставке логистики, о цене последней мили — модель отвечает уверенно, с цифрой, иногда даже с разбивкой по схемам FBO и FBS. Но цифры взяты не из живого справочника Ozon, а из того, что модель видела при обучении полтора-два года назад. Маркетплейс за это время поменял тарифы три раза. Ты строишь юнитку — она оказывается на семь процентов хуже, чем считал. На большом объёме это десятки тысяч рублей в минус.
Несуществующие SKU и артикулы
Просишь модель «проанализировать карточку артикул такой-то». Если у модели нет доступа к Ozon, она может либо честно сказать «не вижу», либо — гораздо чаще — выдать развёрнутый анализ полностью выдуманной карточки. Описание, ключи, цена, рейтинг отзывов — всё придумано. Ты читаешь, киваешь, делаешь выводы. А карточки с таким артикулом либо нет, либо она про совсем другой товар.
Фантомные продажи
Просишь «посмотри продажи моего магазина за прошлую неделю». Без подключения к Seller API модель ничего не видит. Но если её об этом прямо не предупредить — выдаст таблицу с числами, очень похожими на правду по структуре, но взятыми из воздуха. Особенно опасно, когда селлер делает на этих числах операционные выводы — куда подвозить, что снимать, какую цену ставить.
Несуществующие правила и инструкции
«Можно ли возвращать товар категории такой-то по такой-то схеме» — модель ответит, ссылаясь на конкретный пункт правил. Пункта может не существовать. Или существовать с другим содержанием. Или существовать, но быть отменённым месяц назад. Селлер действует по выдуманной инструкции — получает санкцию.
Почему так происходит — три источника
Первый — устаревшие данные. Модель обучалась к определённой дате, после которой мир продолжил меняться. Комиссии маркетплейсов, правила оформления карточек, ставки налогов, требования к маркировке — всё это динамика, которую обученная неделю или год назад модель не знает.
Второй — отсутствие фактов вообще. Текущие остатки на твоём складе, твои продажи, твои отзывы — этого никогда не было в обучающих данных, потому что это твои частные данные. Модель физически не может этого знать. Но без подключения к API она не понимает, что не понимает — и выдумывает.
Третий — нечёткий запрос. Когда ты задаёшь общий вопрос, модель достраивает контекст самостоятельно — и часто этот достроенный контекст ложный. «Посоветуй, что делать с моим товаром» — модель додумывает, что это за товар, и даёт совет про выдуманный товар.
Как защититься: инженерные приёмы
Источник в каждом ответе
Простое и эффективное правило. Любой ответ с фактической цифрой или ссылкой на правило должен сопровождаться источником. Если модель не может назвать источник — значит, она этот факт реконструировала. Прямо в промпте можно потребовать: «к каждой цифре укажи откуда взял. Если из общих знаний — пометь "ориентировочно, проверь в кабинете". Если нет источника — не пиши цифру, скажи "нужно посмотреть в кабинете"».
Хорошие специализированные агенты делают это автоматически — рядом с каждой цифрой стоит ссылка либо на страницу справки Ozon, либо на конкретный ответ Seller API.
RAG — подача источника прямо в контекст
Аббревиатура RAG расшифровывается как retrieval-augmented generation, по-русски — «генерация с подгрузкой источника». Идея простая: перед тем как модель ответит, в её контекст автоматически подкладывается актуальный фрагмент справки или базы знаний. Модель отвечает уже не «из памяти», а опираясь на этот свежий текст.
Для селлера на практике это выглядит так: у агента есть постоянно обновляемая база актуальных правил Ozon — комиссии, требования к карточкам, регламенты возвратов. Когда ты задаёшь вопрос, система сначала находит в этой базе релевантный кусок, потом подаёт его модели, потом модель формулирует ответ. Вероятность галлюцинации падает в разы — модели уже не нужно реконструировать факт, факт у неё перед глазами.
Live API вместо общих знаний
Для всего, что касается твоих личных данных — продажи, остатки, цены, отзывы — общая модель в принципе не годится. Тут нужен агент, у которого есть прямое подключение к Seller API маркетплейса. Тогда на запрос «покажи продажи за неделю» модель не выдумывает, а буквально достаёт цифры из живого ответа API и показывает их.
Это уже не про языковую магию, это про инженерию. И именно здесь проходит граница между «потыкать ChatGPT» и «настоящий ассистент селлера».
Кросс-проверка
Даже когда у агента есть и RAG, и Live API, для серьёзных решений имеет смысл вторая проверка. Спросил юнитку — открой кабинет, сверь комиссию с реальной для этой категории. Получил отчёт по продажам — открой раздел статистики в кабинете, посмотри ту же цифру оттуда. Сначала это занимает время, потом ты понимаешь, на каких задачах агент стабильно точен, и где-то проверку можно ослабить.
Право сказать «не знаю»
Хорошо настроенный агент должен иметь явное разрешение и инструкцию: если данных нет — не выдумывай, прямо скажи «нет данных, проверь в кабинете» или «нужно подключение к такому-то источнику». Это инженерная задача, которую решают на уровне системного промпта агента. Без неё модель в девяти случаях из десяти попробует придумать ответ — это её базовое поведение.
Где общий ChatGPT просто не годится
Любая задача, где ответ должен быть точным по конкретной актуальной цифре или правилу твоего маркетплейса. Юнитка с реальными комиссиями. Расчёт прибыли с реальной логистикой. Анализ твоих карточек по реальным просмотрам. Проверка того, не нарушает ли твоё описание правил оформления. Расчёт даты, к которой нужно подвезти товар, чтобы не уйти в OOS.
Всё это требует либо живых данных из твоего кабинета, либо актуального справочника правил. Общая модель ничего этого не имеет. Не потому что плохая, а потому что не предназначена.
Где общий ChatGPT работает отлично
Языковые задачи без жёсткой привязки к актуальной фактуре. Переписать черновик описания. Сформулировать ответ покупателю. Сгруппировать отзывы по типу возражения. Придумать варианты заголовков. Помочь со структурой текста. Объяснить общий принцип чего-либо. Тут галлюцинации редки и почти не критичны.
Итог
Галлюцинация — не баг, а свойство технологии. Чем чаще ты задаёшь модели вопросы про точные актуальные факты — тем выше риск. Защита строится тремя слоями: требуй источник в каждом ответе с цифрой, для актуальных правил используй агента с RAG, для своих данных — агента с подключением к Seller API. И всегда оставляй модели право честно сказать «не знаю» вместо красивого выдуманного ответа.
В нашей AI-команде каждый агент работает в связке с актуальной базой правил Ozon и прямым подключением к Seller API. Если данных нет — агент это явно скажет, не выдумывая.