Довожу задачу до работающего сервиса

Как устроен цикл

• Блогер регистрируется и добавляет свои площадки — VK, Instagram, YouTube, TikTok
• Площадки проходят модерацию оператором
• Блогер берёт задачу и получает видео — каждая копия уникализируется под алгоритмы площадки
• Публикует пост и отдаёт ссылку
• Система ежедневно парсит просмотры по каждому посту
• Выплата считается от накопленных просмотров
• Антифрод сигналит о подозрительной динамике — алерты идут в очередь на разбор

Ключевая деталь — уникализация видео

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

Что было сделано

Продуктовая логика и экономика выплат, бот и Mini App, пайплайн обработки видео, backend с ежедневным парсингом четырёх платформ, правила антифрода, модерация площадок, очередь выплат и админка оператора — целиком.

Масштаб на скриншоте

450 блогеров, 606 подтверждённых площадок, ₽171 940 выплачено, очередь из 24 заявок на вывод и 1 923 открытых алерта антифрода.

Ограничение, определившее решение

Доступа к серверам админки не было и развернуть инфраструктуру возможности не было тоже. Поэтому — userscript в браузере: встраивается в интерфейс, забирает из карточки название, ингредиенты, теги и категорию, отдаёт в LLM и вставляет результат обратно.

Что решалось неочевидно

• Форма на фреймворке игнорировала прямую запись в поле — вставка идёт через нативный сеттер с эмуляцией событий
• Few-shot промпт на языке ответа, чтобы стиль не плыл между локалями
• Опции заказа осознанно исключены из состава — иначе описание засорялось
• Промпт вынесен на централизованный webhook в n8n: формулировки правятся для всей команды из одной точки, API-ключ не лежит в браузерах

Задача

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

Решение

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

Где проходит граница

RAG отвечает по документам и описаниям. Цены, статусы и расчёты берутся через SQL и API — модель не придумывает числа, а подставляет их.

Моя роль

Постановка задачи, архитектура, реализация, вывод в эксплуатацию и поддержка.

Сценарий

Менеджер открывает шахматку в разговоре с клиентом, видит актуальные лоты и цены, ставит бронь — руководитель получает уведомление в Telegram и утверждает в один тап.

Результат

Убран двойной ввод между шахматкой и CRM, статусы лотов и сделок не расходятся, у каждой брони есть агент, клиент и контакт.