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

Задача была прикладная: мы переносим интернет‑магазины на свой движок и хотели понять, сколько в зоне .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 виртуализацией управляла сторонняя платформа. Иногда она зависала и переставала принимать задачи. Нагрузку распределили между несколькими экземплярами платформы, но зависания продолжились. До вмешательства операции клиентов не шли.

Привет, Хабр! Я разработчик из Минска (работаю официально, в статусе НПД). Занимаюсь автоматизацией на связке Self‑Hosted n8n + Redis. Внедряю автономных ИИ‑агентов для мессенджеров и связываю их с amoCRM.

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

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

История статьи началась, наверное можно сказать в 2 этапа. На первом этапе, который был ещё наверное в марте этого года, ко мне обратился заказчик с интересным ТЗ: стек Instagram+ amoCRM + Google Sheets при плотном трафике до 5000 диалогов в месяц (таргет что тогда, что по сей день заходит «на ура»). Причём сёстры (заказчик — это семейный бренд ателье дизайнерских украшений) своими силами опробовали «...платформы где платишь подписку и в соответсвии с трафиком выбираешь соответствующий пакет услуг. Итог в который после первого дня триала по самым средним подсчётам вышел бы 1100$ в месяц расхода (!). Поскольку моя статья не о том какая архитектура была в итоге у них развёрнута, так что пойдём дальше.»

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

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

Давайте объясню это на конкретном примере. Система электронных продаж, написанная на Java — как раз такая штука, с которой большинство бэкендеров сталкивались хотя бы раз на протяжении карьеры.

Всем привет! 

Меня зовут Дмитрий Шипилов, с вами команда поиска Uzum Market.

Мы уже рассказывали вам о нашем поисковом движке: о том, как вообще работает ранжирование и что у него под капотом и как мы получаем кандидатов с помощью векторного поиска. 

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

Началось с простого желания: чтобы Claude мог написать письмо коллеге, не заставляя меня переключаться в браузер. Готовые решения есть — Zapier, всякие облачные коннекторы. Но там моя переписка проходит через чужую инфраструктуру, а мне этого не хотелось. Значит, свой MCP-сервер: пара сотен строк, Gmail API, за вечер.

Вечер растянулся на несколько дней и 300 тестов не потому, что задача сложная, а потому, что почта оказалась минным полем, где каждая вторая мелочь ломает всё молча и не сразу. Собрал грабли в кучу. Если будете делать что-то похожее — сэкономите себе несколько вечеров.

Сначала PriceTrack проверял страницы маркетплейса на VPS. Селекторы были корректными, но сервер вместо карточек товара получал 403. В итоге я перенёс браузер и извлечение данных на компьютеры пользователей, а сервер оставил управляющим контуром. В статье рассказываю, как устроена эта архитектура, зачем понадобились базовый профиль и локальный рецепт и какие проблемы появились с фоновыми проверками, треем и несколькими аккаунтами.

Мы решили поручить анализ данных ChatGPT. И быстро поняли, что проблема вовсе не в модели. Оказалось, что LLM может красиво объяснять, но не должна считать. Ошибка была не в промпте, а в архитектуре системы.

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

Привет, на связи Рома Миронов из Авито. Я бывший — хотя бывших не бывает — фронтендер, а сейчас тим- и техлид. Ковыряю AI и больше ничем не занимаюсь — кроме команды, конечно :) В этой статье расскажу, почему фронтенд пока не умер, какие задачи уже можно отдавать агентам, где они красиво ошибаются и почему сначала от AI становится больнее, а не легче.

Лет 6 назад я мог убить вечер в документации или в исходниках фреймворка ради одного метода. Докапывался до ядра, находил способ заменить 15 строк на 3 и ходил довольный неделю. Это был спорт: я знаю платформу глубже, чем ее среднестатистический разработчик.

Сейчас я пишу агенту: подними xhprof на дев-стенде, прогони сценарий оформления заказа, агрегируй, покажи топ виновников. И иду наливать кофе

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

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

В первом сценарии основные точки контроля должны находиться как можно ближе к разработчику, а во втором – должны быть ближе к ИИ-модели.