Недавно я решал одну интересную, на мой взгляд, задачу – увеличить конверсию и апсейл в интернет-магазине, который и так себя чувствует нормально, то есть его показатели находятся на уровне рынка по бенчмаркам.

Условие: решение должно быть на базе ИИ. Почему на базе ИИ? Да всё просто – протестировать, насколько эффективно сейчас можно внедрять ИИ-агентов.

Дисклеймер. Мы не будем погружаться в споры, а почему не увеличить бюджет на маркетинг, идти в дисрапт рынка и так далее. В этой статье всё-таки про ИИ. Будем говорить про то, может ли ИИ повлиять на рост метрик: средний чек, ретеншен и конверсию в интернет-магазине. Мой опыт будет полезен всем нишам, но в этой статье мы будем внедрять ИИ в классический e-commerce fashion.

Итак, прежде чем приступать к решению, давайте разберёмся, где какие проблемы у нас есть на клиентском пути. Зная метрики и воронку, мы понимаем, на каком этапе у нас падает конверсия или, по-другому, какой этап воронки менее конверсионный.

Основной боттлнек – это конверсия из карточки товара в корзину. Не удивительно, да?))) Речь идёт о конкретном магазине, называть, конечно же, мы его не будем.

Выявляем боли клиентов

Чтобы понять, какое решение должно быть, чтобы добиться ключевых метрик, определяем ключевые боли наших клиентов. Я это сделал с помощью интервью и опросов. Как для опроса посчитать статистически значимую выборку, дисперсию и прочее, я писать не буду. Но скажу, что я использую ИИ-агента как помощника справляется на отлично. Вопросы для опроса, анкету тоже помогает писать мне ИИ, связка из DeepSeek V3 + Perplexity.

Алгоритм у меня такой: 12–15 клиентов по разным GEO, среднему чеку и так далее зовём на интервью, взамен предлагаем скидку. Мы предлагали промокод на 3 000 ₽. После интервью выделяем 3–4 ключевые боли, самые горячие. Теперь нам нужно их количественно подтвердить, тут запускаем опросы. Всё, на этом я заканчиваю с частью дискавери, это вообще отдельная тема.

Итого, вот критические боли наших клиентов, пользователей:

1. Размер, посадка, «сядет ли на меня»
Какой размер взять? Как сядет именно на мою фигуру? 67% покупателей уходят, если непонятно с размером. Таблицы размеров не помогают — одинаковый размер у разных брендов отличается.

2. С чем это носить?
Нашёл джинсы, но что к ним купить? Какую рубашку? Какую обувь? Открывает 10 вкладок, запутывается, устаёт, уходит. 70% добавляют в корзину, но не покупают.

3. Нужна примерка или её аналог
Люди хотят «примерить перед покупкой» как опцию или как уверенность, что не ошибутся.

4. Материал и ощущения
«Ткань мягкая или жёсткая, колется, дышит, просвечивает, тянется, мнётся, скатывается, как ведёт себя после стирки?»

Формулируем гипотезу

Когда понятно, какие боли решать, понятен приоритет, генерируем решение, гипотезу, если быть точнее.

Моя гипотеза будет такая: Если мы добавим ИИ-стилиста, который консультирует по стилю и размеру, отвечает на вопросы по составу и уходу и помогает собрать готовый образ с итоговой ценой, то мы снизим долю брошенных корзин, снизим долю возвратов на и увеличим вовлечённость, например среднюю длительность сессии. Проверим гипотезу через А/Б-тест.

Так, хорошо, гипотеза есть. Теперь надо понять, что конкретно будем разрабатывать. AI стилист должен уметь много всего. Но с чего начнем? Какие функции делать в первую очередь? Все делать не стоит, по крайней мере, я иду иттерационным путем, чтобы не слить весь бюджет на разработку и не добиться никаких результатов.

Приоритизация функций

Для приоритизации фичей я буду использовать фреймворк ICE + добавлю параметр Data Readiness, который использую для всех ИИ-продуктов. Про ICE можно почитать отдельно, а вот Data Readiness – это параметр, который я «внедрил» для большей прозрачности, почему та или иная фича будет делаться в таком порядке.

Data Readiness, готовность данных – это коэффициент от 0,1 до 1,0, который показывает, насколько готовы данные для работы ИИ-агента. Например, как можно будет перевести каталог товаров в векторное представление, чтобы RAG был, есть ли у наших складских учётов MCP или нужно писать самому и так далее.

_{Прикреплю примеры расчёта в виде таблицы, ссылка, как обычно, в конце.}

Архитектура решения

Когда мы определили, что будет в первой версии ИИ-стилиста, давайте приступим к архитектуре, то, как всё будет выглядеть, какие компоненты нам нужны. Разберём общую схему, а потом будем собирать агента

Не буду рассказывать про виджет на фронтенде, я лучше просто запишу скринкаст, как он работает. точкой входа может быть любой интерфейс, да хоть телеграм-бот. Нас интересует сам ИИ-агент: как он думает, откуда берёт факты, где хранит контекст и почему он не «галлюцинирует».

Давайте разберем каждый компонент схемы

1. Input Guardrails

Это защита от того, что может написать клиент, в будущем он же и будет служить нам компонентом маскирования персональных данных. Главная задача сейчас: не дать «взломать» агента через специальные команды или, по-другому, защита от Prompt Injection. Чтоб не уходить в тематику промпт-инжекшена, я коротко расскажу как я реализовал в нашем ИИ-стилисте, если эта тема вам будет интересна напишите, сделаю большую статью, где разберём типы атак и методы защиты.

Как можно реализоват компонент «Guardrails», расммотрим 2 подхода:

1. Сами пишем этот «микросервис» например можно использовать Regex + NER (например Natasha) и другие решения. Долго, надежно, професисионально.

2. Берём готовое решение, я, например, по опыту взял и доработал библиотеку NeMo Guardrails от NVIDIA. Из коробки уже умеет работать с Prompt Injection, маскированием данных, контентом и безопасностью всё что нужно нам, но есть минус: всё на английском языке. Но мы берём конфиги внутри и переделываем на русский язык работает отлично). Проверено.

Как вы могли понять, я остановился на 2 варианте, так использую эту бибиотеку уже не в первый раз.

2. ИИ-агент

Пожалуй, самый главный компонент: он получает запрос клиента, анализирует контекст, решает, какие инструменты вызвать для получения данных, собирает информацию и генерирует персональный ответ.

Кстати, ИИ-агент – это не просто вызов API модели LLM, а полноценная система, у которой есть:

• память (краткосрочная и долгосрочная, можно называть short-term и long-term memory)

• «мозг» (да простят меня все) мозгом будет выступать модель LLM модель

• инструменты (Tools)

• база знаний (векторное хранилище)

• и всё это управляется логикой, то есть оркестрируется.

2.1 LLM-модель

Я взял GPT-4o, очему такой выбор? почему не последняя версия 5.2, например. Критерии выбора такие: не менее 100K контекстного окна, не дороже $3 за миллион токенов, понимание контекстной области из коробки, скорость ответа не более 500 мс и есть Function Calling, то есть может работать с внешними инструментами-функциями, которые у нас обозначены в схеме как Tools.

У LLM модели будет системный промпт, (да действительно капитан очевидность), так вот я хотел поделиться тем, что я промпnы не храню в коде, а храню в отдельном файле config/system_promt21.12.2025.md в репозитории, так удобнее версионировать и менять без правки кода. Плюс при тестировании мы можем проводить А/Б-тесты промптов (промпт, который я использовал, я оставлю в конце).

2.2 Память (short-term и long-term memory)

Мы в MVP делаем только краткосрочную память (short-term), чтобы в рамках сессии сохранять всю историю диалога с клиентом. Сессию идентифицируем по session_id из куки, которые живут у нас около 60 минут. Важный момент: в самих куках храним только session_id (строка типа abc123def456), а вся история диалога лежит в PostgreSQL так данные не теряются при обновлении страницы и можно делать SQL-аналитику (какие вопросы задают чаще, на каком этапе отваливаются клиенты).

А что храним то:

1. Chat history — полная история диалога: все сообщения пользователя и все ответы LLM-модели. Каждое сообщение с ролью (user или assistant), текстом, timestamp. Например: [{role: "user", content: "Какой размер на рост 185?", timestamp: "10:15"}, {role: "assistant", content: "Рекомендую W32/L34...", timestamp: "10:15"}].

2. Current product – на карточке какого товара сейчас клиент. Это приходит от Frontend при каждом запросе (не храним в БД), но нужно для контекста — агент понимает, что клиент уже смотрит на Levi's 501, не будет предлагать этот же товар в похожих.

3. Client params – параметры клиента, которые агент выяснил в процессе диалога: рост (185 см), телосложение (среднее), предпочитаемый стиль (casual). Эти данные агент использует для персонализации рекомендаций не спрашивает повторно «а какой у вас рост», если уже знает.

В какой-то момент мы можем столкнуться с ограничением контекстного окна, на этот случай давайте продумаем, что будем делать. GPT-4o имеет контекстное окно 128 тысяч токенов это очень много, вряд ли мы упрёмся в MVP. Но защиту предусмотрим на случай, если клиент ну очень долго консультируется.

В русском языке я ставлю порог 40 тысяч символов истории чата (это примерно 10–12 тысяч токенов). Когда история достигает этого порога, делаем суммаризацию через LLM: отправляем всю историю модели с промптом «создай краткий саммари диалога в 3–5 предложениях, что клиент хотел, какие параметры выяснили, к каким выводам пришли». Сохраняем саммари в поле conversation_summary в PostgreSQL, оставляем только последние 3–5 сообщений плюс саммари. Освобождаем примерно 80% токенов контекста.

2.3 Инструменты (Tools)

Tools – это обычные Python-функции, которые мы регистрируем для GPT-4o через Function Calling API. По сути мы говорим модели: «У тебя есть три инструмента: get_size_guide, rag_retrieve, search_similar. Вот что каждый делает, вот какие параметры принимает. Используй их, когда нужны данные, которых у тебя нет». Модель видит эти описания и может сама решить, когда нужно вызвать функцию, вместо того чтобы генерировать ответ из своих знаний.

Чтобы LLM-модель (в нашем случае GPT-4o) могла её использовать, мы создаём описание в формате JSON Schema: название функции, что она делает, какие параметры принимает и какие обязательные. Например, для get_size_guide мы пишем: «Эта функция получает размерную сетку бренда. Принимает два параметра brand (название бренда типа Levi's) и category (категория типа Джинсы). Используй, когда клиент спрашивает про размер». Это описание передаётся GPT-4o при каждом запросе вместе с промптом и сообщениями.

Как агент решает вызвать tool?

Агент анализирует запрос клиента и свой контекст. Видит: «Клиент спрашивает, какой размер джинсов Levi's на рост 185 см. У меня в промпте написано, что для размеров нужно использовать get_size_guide. Я знаю, что клиент на карточке Levi's 501 из контекста. Значит, нужно вызвать get_size_guide с параметрами brand='Levi's' и category='Джинсы'». Вместо генерации текстового ответа GPT-4o возвращает специальный ответ tool_calls – это массив, где указывает, какую функцию хочет вызвать и с какими параметрами в формате JSON.

Что происходит после вызова?

Мы получаем ответ от GPT-4o, видим, что там есть tool_calls, парсим, какую функцию и с какими параметрами нужно вызвать. Выполняем нашу Python-функцию, например get_size_guide она идёт в PostgreSQL, достаёт размерную сетку Levi's для джинсов, возвращает структурированные данные. Этот результат мы оборачиваем в специальное сообщение с ролью tool и добавляем в диалог. Отправляем агенту новый запрос уже с этим результатом в контексте. Теперь агент видит: «Окей, я запросил размерную сетку, получил, что на рост 185 см нужна длина L34 и талия W32–W34. Теперь могу сгенерировать ответ клиенту».

Чуть не забыл: Tools возвращают не просто текст, а структурированные данные в JSON. Это критично для точности — агент не интерпретирует свободный текст, где может ошибиться, а получает чёткие поля: размер W32/L34, цена 8 990, в наличии true, количество 5 штук. Можно добавить валидацию через Pydantic это библиотека, которая проверяет, что данные соответствуют схеме перед отправкой агенту. Если размер пришёл в неправильном формате или цена отрицательная, валидация не пропустит и вернёт ошибку. Так мы гарантируем, что агент всегда получает корректные данные и не может сгенерировать ответ на основе битых данных.

В MVP будет у нас 3 инструмента:

• get_size_guide идёт в PostgreSQL и возвращает точную размерную сетку конкретного бренда и категории.

• rag_retrieve делает векторный поиск в Qdrant коллекции knowledge_base и возвращает топ-3 релевантных чанка знаний. Используется, когда нужна информация о стилях одежды, материалах, уходе за вещами, дресс-кодах событий.

• search_similar делает векторный поиск в Qdrant коллекции products, находит похожие товары по семантике, проверяет остатки в PostgreSQL и возвращает топ-10 товаров в наличии. Используется, когда нужны похожие товары, альтернативы, комплекты, образы.

2.4 База знаний (векторное хранилище)

Используем Qdrant. В векторном хранилище у нас будут храниться:

1. Коллекция knowledge_base база знаний о моде и стиле. Здесь будут храниться: правила стиля (smart casual – это тёмные джинсы плюс рубашка плюс кожаная обувь), описания материалов (хлопок дышит, впитывает влагу, может сесть; кашемир мягкий, тёплый, не колется, требует деликатного ухода; лён сильно мнётся — это нормально, идеален для жары), сочетания цветов (тёмно-синий, белый, коричневый – классическая палитра), дресс-коды для событий (деловой ужин, свидание, театр, офис), табу (спортивные кроссовки не сочетаются с деловым костюмом). Данные хранятся как чанки по 200–250 слов.

2. Коллекция products – весь каталог товаров. Каждый товар векторизован: берём название, описание, бренд, категорию, материалы, стиль всё это в один текст и превращаем в вектор. В метаданных лежат структурированные поля: product_id, название, бренд, цена, категория, доступные размеры, цвет, теги стиля, ссылки на изображения, флаг in_stock. Каталог обновляем раз в день.

Давайте ещё коротко расскажу, как векторизуем каталог: мы будем брать всё из 1С.

Пример:

Джинсы Levi's 501 Original Fit
Бренд: Levi's
Категория: Джинсы, Прямые джинсы
Описание: Культовые джинсы прямого кроя из плотного хлопкового денима. Классическая посадка на талии, прямые штанины. Застёжка на пуговицы.
Материал: 100% хлопок деним
Цвет: Тёмно-синий
Стиль: casual, classic, everyday

Этот текст пропускаем через эмбединговую модель и превращаем в числа (векторы) и записываем в векторное хранилище. К каждой записи ещё у нас записываются метаданные (payload). Метаданные не участвуют в векторном поиске, но нужны, чтобы вернуть полную информацию о найденном товаре агенту, то есть если мы нашли нужные нам векторы, то ИИ-агенту возвращаются с векторами и метаданные тоже.

Ещё важно сказать, что я при создании векторной БД для работы с текстовым поиском на русском языке указываю в качестве метрики сходства Cosine (косинусное сходство). Cosine – это параметр, который говорит Qdrant: найди мне максимально похожее по смыслу, игнорируя длину текста. То есть короткий текст «джинсы casual» и длинный «джинсы выполнены в повседневном casual-стиле для ежедневной носки» будут считаться похожими, потому что смысл один, хотя количество слов разное. Для русского языка это особенно важно, потому что у нас богатая морфология — одно слово может писаться в десяти формах (джинсы, джинсов, джинсам, джинсами, о джинсах), предложения могут быть короткими или развёрнутыми, но смысл оставаться тем же.

Есть другие параметры сходства, например «Евклидово», если интересно можете поизучать по ссылке.

На этом про векторизацию всё, чтоб не уходить глубоко в технические термины).

2.5 Логика ИИ-агента. LangGraph

Все вышеперчисленные компоненты ИИ-агента: память, вызов по API модель LLM, RAG должны управляться, то есть иметь логику действий. Для управления всеми этими компонентами я использую фреймворк LangGraph.

LangGraph – это фреймворк от LangChain для создания ИИ-агентов. Если простыми словами: это некий дирижёр, который управляет всеми компонентами. Агент должен думать, вызывать tools, анализировать результаты, думать снова, может вызвать ещё tools — и так несколько раз, пока не получит достаточно данных для ответа, это называется reasoning loop (цикл рассуждений).

Без фреймворка пришлось бы писать всю эту логику вручную: проверять, есть ли в ответе GPT-4o tool_calls, парсить JSON, вызывать нужные функции, формировать правильные сообщения для возврата результата агенту, считать итерации, чтобы не зациклился, сохранять состояние между запросами. Сотни строк кода и куча точек, где можно ошибиться.

LangGraph берёт всю эту механику на себя. Мы просто описываем: какие есть узлы (AGENT, TOOLS), как они связаны, когда переходить от одного к другому. Фреймворк автоматически создаёт JSON Schema описания из docstrings функций (это комментарии в коде, которые объясняют, что делает функция), регистрирует их в GPT-4o, следит за ответами модели, вызывает нужные функции, возвращает результаты обратно агенту, управляет reasoning loop с лимитом итераций, сохраняет состояние через checkpointer.

LangGraph реализует паттерн ReAct – это когда агент чередует рассуждение (Reasoning) и действие (Acting). Не просто вызывает tools подряд по жёсткому сценарию, а думает после каждого шага: достаточно ли данных или нужно ещё что-то узнать.

Самое удобное для меня: LangGraph автоматически создаёт JSON Schema для Function Calling из наших Python-функций. Пишем функцию с docstring (комментарий, который объясняет, что делает функция, какие параметры, что возвращает), LangGraph читает этот docstring и генерирует правильное описание для GPT-4o. Не нужно вручную писать JSON Schema, следить, чтобы описание совпадало с кодом, если меняем функцию, меняем docstring, LangGraph автоматически обновит schema. Позволяет делать меньше ошибок, проще поддержка.

После того как всё это мы сделали, у вас получится ИИ-стилист, котоырй мы начнем тетсировать. В этой статбе не хватило место для опсиания процесса тетсирвоания, сразу пойдемте в продакшен.

---

Запуск в production

После разработки и внутреннего тестирования архитектуры давайте посомтрим как это все выглядит.

Как выглядит для клиента

Кнопка на карточке: под основной информацией о товаре (название, цена, размеры) добавили кнопку «Консультация ИИ-стилиста». Не прячем в угол, не делаем навязчивый поп-ап, кнопка на видном месте, клиент сам решает, нужна ли консультация.

Чат-окно: при клике открывается окно чата справа (на десктопе) или на весь экран (на мобильном). Карточка товара остаётся видна слева клиент не теряет контекст, что смотрел. Первое сообщение от ИИ коротко объясняет, что может помочь: подбор размера, составление образа, консультация по материалам.

Запускаем А/Б-тест

Итак, для проверки нашей гипотезы давайте запустим А/Б-тест. Верхнеуровнево опишу дизайн эксперимента, чтобы было понимание:

Разделили весь трафик на карточки товаров пополам:

• 50% видят обычную карточку (контрольная группа) — всё как раньше

• 50% видят карточку с кнопкой «Консультация ИИ-стилиста» (экспериментальная группа)

Важно: каждый пользователь попадает в свою группу при первом визите и остаётся там на всё время теста.

Критерии успеха

Я сознательно буду обходить расчёты и формулы статзначимой выборки, не буду упоминать MDE и прочее. Давайте оставим это аналитикам).

Основная метрика: Conversion to Purchase (конверсия в покупку с карточки)

• Что было до теста (baseline): примерно 2,5% посетителей карточки покупали товар

• Что ожидаем после теста: минимум 2,65% (прирост +6%). Если конверсия вырастет меньше чем на 6% экономически слабовато, затраты на разработку и API не окупятся быстро. Если прирост 10%+ - отлично, это уже серьёзный бизнес-эффект.

Вторичные метрики (тоже важные):

• Add to Cart Rate (добавление в корзину) ожидаем рост, показывает, что клиенты заинтересовались после консультации

• Return Rate (возвраты товаров) не должен вырасти! Если вырастет значит, ИИ плохо подбирает размеры

• Average Order Value (средний чек) ожидаем рост, если ИИ предлагает образы и клиенты покупают комплектами

• AI Usage Rate минимум 15% должны кликнуть на кнопку, иначе инструмент никому не нужен

Тест считаем успешным, если основная метрика выросла минимум на 6% И при этом возвраты не выросли И хотя бы 15% пользуются ИИ. Если хоть один критерий не выполнен, гипотезу отправляем на доработку и возвращаемся к фазе 0 – исследование.

---

Результаты

Так как тест уже проведён и я знаю результаты, я думаю, было бы преступлением не рассказать вам о результатах, без деталей, но я надеюсь, вам будет полезно при принятии решения внедрять ИИ или нет.

1. Основная метрика выросла на 7,3%

2. AI Usage Rate: 59% открыли чат с ИИ, активно использовали 38%

3. Add to Cart: +23,2%, для меня было очень приятным открытием

4. Топ-5 запросов ИИ-стилисту:
   Какой размер взять?
   Есть ли в наличии?
   Сравнение моделей?
   Как материал себя ведет после стирки ?
   С чем сочетать?

---

Что не разобрали в этой статье

В статье я сознательно упростил некоторые технические детали, чтобы не перегружать:

• Настройка NeMo Guardrails под русский язык как доработали конфиги, какие правила добавили для prompt injection detection

• Детали векторизации chunking-стратегии, оптимизация embedding-модели, тюнинг параметров Qdrant

• Мониторинг и алерты через LangSmith: какие метрики отслеживаем, как настроили дашборды, когда срабатывают алерты

• Prompt engineering как итеративно улучшали системный промпт, А/Б-тестирование разных формулировок

• Cost optimization как снизили расходы на API calls в три раза через кеширование и батчинг

Если эти темы интересны напишите в комментариях или личку в телеграмме, сделаю отдельные статьи с глубоким погружением в каждую.

Заключение

Построили ИИ-стилиста, который реально решает боли клиентов в e-commerce: подбор размера, сочетаемость, консультации по материалам. Архитектура показала измеримый бизнес-эффект: конверсия выросла на 7,3%, использование инструмента превысило ожидания (59% открыли чат).

Кому подойдёт такое решение:

• Fashion e-commerce (размеры, образы, материалы)

• Мебель (стиль интерьера, размеры, сочетания)

• Техника (характеристики, совместимость)

• Косметика (подбор по типу кожи)

• Спорттовары (экипировка, программы)

• Стройматериалы (расчёты, совместимость)

Главное: понять боли клиентов, собрать базу знаний, правильно спроектировать под домен.

Спасибо, что потратили время и прочитали. ❤️

Полезные ссылки: Telegram-канал: «ИИ-заметки продакта» рассказываю про ИИ, лайфхаки, полезные инструменты, а ещё каждую неделю выходит дайджест с самыми важными новостями в мире ИИ без инфошума, только всё самое важное.