Разработка под e-commerce *

В прошлой статье (https://habr.com/ru/articles/1076084/) я рассказывал о скрытом баге: ИИ-агент в проде заказчика тратит токены, генерация закрывается со статусом "успех", а клиенту уезжает пустая строка. Тогда я обещал разобраться и починить. Обещание выполнено: причина найдена, правки встали в воркфлоу, счётчик пустых ответов уже 7 дней - чисто. Баг получил имя Reasoning Lock. Теперь подробно о нём: симптомы, "расследование по этажам", механика и "лечение" - в общём в стиле детектива))

Напомню, что строю ИИ-агентов на self-hosted n8n. Герой статьи - агент в проде заказчика: по ночам принимает заявки в Instagram Direct, ведёт диалог, собирает анкету и создаёт/обновляет сделку в amoCRM. Стек агента: n8n + Redis + LangChain, LLM основная - DeepSeek V4 Pro через OpenRouter, резервная - недавно поменял на Qwen3.8 Flash.

Предыстория: два периода, две природы отказов

История началась задолго до самого бага. С конца июня (установил в прод агента в первых числах июня если точнее быть) отказы случались двух периодов, и разница между ними = ключ к пониманию.

Период первый = тесты и запуск: инфраструктура. Первые "пропавшие ответы" пользователям имели вполне земную природу: ограничения Meta - потери вебхуков, окно ответов, двойные доставки. Как это чинилось (мгновенный 200 OK, буфер на Redis, дебаунс) - разобрано в первых двух частях. К продакшену этот класс закрыли.

Период второй - последние два месяца: промпт. Система стабилизировалась, и правки от заказчика посыпались в системный промпт... (( Под живую бизнес-логику: инструкция по пересылке оплаты пользователем, отдельные сценарии ответов для VIP-клиентов (абзаца два , которые под каждое "фи" постоянного клиента меняли по несколько раз), уточнения формулировок после каждого спорного диалога. Каждая правка по отдельности естетсвенно правильная и рабочая. Суммарно же промпт разросся до где то 6.4k токенов, и плотность запретов ("КАТЕГОРИЧЕСКИ ЗАПРЕЩЕНО", "Отправь СТРОГО этот текст") стала максимальной за всю жизнь системы.

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

Что происходит, если строить каталог на миллионах товаров не вокруг PostgreSQL и Elasticsearch, а вокруг mmap, собственных индексов и zero-allocation JSON? Разбираю архитектуру, компромиссы и реальные результаты на работающем агрегаторе: около 50 000 RPS и миллисекундные ответы.

Что, если два небольших автоматизированных процесса возвращают компании больше 160 рабочих часов в месяц?

В одном из проектов я связал внутреннюю Excel-систему компании с маркетплейсами и добавил AI-черновики ответов на обращения покупателей — при этом финальное решение всегда остаётся за сотрудником.

Разобрал, где именно терялось время, что автоматизировал и почему эффект получился примерно на 100 тысяч рублей рабочего времени в месяц на 5 сотрудников.

В статье — цифры, архитектура и экономика внедрения.

Проблема любого онлайн-движка исполнения кода в том, что он должен принять чужой код и выполнить его как есть — а этот код может оказаться вредоносным. Поэтому нужно спроектировать всё так, чтобы при запуске кода мы могли свести к минимуму негативные последствия, которые «враждебный» код может вызвать. Например, если кто-то попытается вызвать команду вроде rm -rf /, то это не удалит нам всю систему.

Можно быть хоть топ-1 в органической выдаче по всем коммерческим запросам, но ни разу не попасть в ИИ ответ от Google или Яндекс.

Я собрал собственный автоматический мониторинг видимости бренда на n8n (43 ноды): раз в месяц опрашиваем Яндекс, GPT, Gemini и Qwen, отделяем цитирование из выдачи от ответов модели по памяти и тратим меньше 100 рублей за полный прогон по всем категориям.

Внутри — разбор механики отслеживания, FNV-1a хэширование ответов, детект без второй LLM и ссылка на открытый GitHub с готовыми воркфлоу и шаблоном таблицы на 17 вкладок.

В финале прошлой статьи я обещал разбор контура генерации ответов с гибридным извлечением данных (LLM‑tools + regex). Но пока немного переиграем планы и переключимся в другую тему — причина практический инженерный эксперимент. Постараюсь вкратце и по существу.:‑)

Казалось бы, что может пойти не так с легковесными векторными анимациями? Вектор в Lottie, JSON весит копейки. Но тестирование на реальном телефоне закончилось фиаско: через пару минут скролла чип раскалился до 42 °C, а интерфейс ушёл в троттлинг.

Оказалось, что покадровый пересчёт кривых Безье в JS на мобильных экранах быстро превращает телефон в печку.

В кейсе разбор того, как мы перешли на аппаратно декодируемые видео‑спрайты, почему IntersectionObserver втихую крутил видео под непрозрачными модалками и как в итоге удалось сбить температуру обратно до стабильных 30 °C.

Первый файл, который я получил при переезде своего магазина с InSales, парсер прочитал как одну длинную строку мусора. Выгрузка заказов оказалась в UTF-16 LE с BOM и табуляцией вместо запятой — ни один разумный дефолт не подошёл.

Тогда это выглядело как разовая неприятность: поправил чтение, написал скрипт, ночь работы, всё уехало, скрипт лёг в репозиторий. На следующем проекте он не переиспользовался — другая платформа, другие колонки, другие правила. На третьем стало видно, что повторяется почти вся работа: связать заказ с клиентом, не создать дублей, не потерять адреса страниц, уметь перезапуститься. Разное только на входе — кодировка, формат, названия колонок, единицы измерения.

Отсюда вывод, к которому стоит прийти раньше, чем на третьем проекте: середина должна быть одна, а платформенная специфика — жить в тонком слое на входе. Ниже — как этот каркас устроен у меня, с кодом из работающего проекта: собственного магазина, который я перевёз с InSales на свой движок на Next.js и PostgreSQL.

Сразу оговорюсь про доставленные миграции: полностью пройдена одна — та, о которой пойдёт речь. Про требования к адаптерам под 1С‑выгрузки и товароучётные API дальше я говорю как о проектных требованиях к каркасу; готовыми кейсами они не являются. Это важно, чтобы вы правильно оценили вес каждого утверждения.

Резонный вопрос до всего остального: почему не готовый инструмент. Airbyte, n8n, коннекторы к товароучётным системам делают ровно это — вытащить, преобразовать, положить. Для регулярной синхронизации они и есть правильный выбор. Разовая миграция магазина отличается тем, что сложность сидит не в перекладывании строк, а в доменных правилах: как собрать заказ из нескольких строк, что делать с позицией, товара которой больше нет в каталоге, как при повторном прогоне не затереть свежие данные старыми. Эти правила всё равно пишутся руками, а в визуальной цепочке трансформаций их неудобно тестировать и нельзя перезапустить кусочком. Поэтому середина своя, а тонкими остаются края.

Задача была прикладная: мы переносим интернет‑магазины на свой движок и хотели понять, сколько в зоне .ru магазинов на каждой платформе и как их находить. Готовые сервисы вроде BuiltWith продают выгрузки по подписке, но нам нужен был воспроизводимый обход, который можно гонять когда угодно и по своим правилам.

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

Всем привет!) Напомню: в первой статье я показал дебаунс на Redis, который склеивает дробные сообщения клиента. Во второй — модуль привязки «чат = сделка» и то, почему вебхуки стоит держать в изолированных ключах. Обе части заканчиваются примерно одинаково: «...и текст уходит ИИ‑агенту». Это, пожалуй, тот финал, на котором обычно ставят точку и заливают демо на GitHub... Но не в данном случае!)

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

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

В прошлой статье я показал, как простой дебаунс на Redis спасает бюджет от дробных сообщений: клиент строчит «привет» — «сколько стоит» — «а есть другой размер» пятью сообщениями подряд, а LLM получает один склеенный промпт.

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

В интернет‑магазинах уже есть поиск, фильтры и карточки товаров. Но этого часто недостаточно, когда человек приходит не с конкретным названием товара, а с задачей. Например: «Мне нужен инструмент для ремонта квартиры» или «Чем отличаются эти два товара и какой подойдет лучше?».

В офлайн‑магазине в такой ситуации можно обратиться к консультанту: объяснить задачу, уточнить детали и получить несколько вариантов. Мы хотели перенести похожий сценарий на сайт. Но довольно быстро стало понятно, что схема «пользователь → LLM → ответ» для этого не подходит.

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

Проект мы разрабатывали командой ASAP, и в этой статье разберем, как мы подошли к проектированию AI‑консультанта: устроили взаимодействие LLM с каталогом более чем из 200 тысяч товаров, какие задачи оставили коду, как работаем с актуальными ценами и остатками и почему вокруг языковой модели в итоге пришлось построить достаточно большой слой классической backend‑логики.

Я работаю аналитиком в e‑commerce крупной FMCG‑компании. В маркетплейсах это иногда ощущается как слон в посудной лавке: несколько юридических лиц на каждой площадке, большие объёмы поставок, ограничения по слотам на складах, сложная логистика, переупаковка и подготовка товаров под требования конкретного канала.

Отдельной болью, которую хотелось автоматизировать, был расчёт заказа на Ozon. Для менеджера маркетплейса это был регулярный и довольно трудоёмкий процесс: сначала нужно было собрать данные из разных выгрузок, а уже потом переходить к расчёту.

Сделал mmap-базу для 4 млн товаров и получил ~35k RPS. Поиск оказался настолько быстрым, что bottleneck пришлось искать уже после базы. В итоге оптимизировал JSON, получил ~1.8× прироста HTTP workload — и упёрся в w.Write.

Внешний счётчик ставится за пять минут, и обычно этого достаточно. Но у модели «сторонний скрипт с чужого домена» есть технический потолок, и на магазине я в него упёрся: запрос к третьему домену режут блокировщики и антитрекинг браузеров, на объёме включается сэмплирование, cookie тянет за собой баннер согласия (а все, кто его отклонил, выпадают из статистики целиком), и главное — поведение ваших покупателей лежит в чужой системе, рядом с которой нет ваших заказов.

Ниже — как устроен свой cookieless‑трекинг в двух проектах на Next.js: интернет‑магазин (Next.js 15.5, TypeScript, Prisma 6, PostgreSQL) и маркетплейс услуг (тот же Next.js, но pg без ORM). Код в статье — из работающих проектов, с теми решениями, которые оказались неочевидными, и с теми, которые пришлось переделать.

Сразу оговорка: это не «Метрика — зло». Для контентного сайта внешний счётчик закрывает вопрос целиком. Разговор начинается там, где аналитика — часть продукта.

В МФТИ 53% бюджетных мест в этом году заняли олимпиадники. На биоинженерии МГУ — все 35 из 35, туда не прошли даже стобалльники. При этом вся инфраструктура олимпиадной подготовки живёт в Москве и нескольких матлицеях, а я живу в городе на сорок тысяч человек. Рассказываю, как мы с супругой — оба бывшие олимпиадники — посмотрели на первый класс сына, посчитали и ушли на семейное обучение.

До AVM виртуализацией управляла сторонняя платформа. Иногда она зависала и переставала принимать задачи. Нагрузку распределили между несколькими экземплярами платформы, но зависания продолжились. До вмешательства операции клиентов не шли.