BI-аналитик и Python-разработчик: данные, кубы, ИИ-агенты

Задача: отвечать покупателям строго по официальному каталогу и FAQ, не выдумывая свойства товаров.

• База знаний: каталог на 251 товар и 212 записей FAQ → смысловой чанкинг по разделам (описание / применение / состав) → 689 фрагментов.
• Эмбеддинги мультиязычной модели, индекс FAISS; на запрос — поиск top-12 фрагментов, контекст уходит в промпт модели.
• Один FastAPI-сервис обслуживает и виджет на сайте, и Telegram-бота: логика и база знаний не дублируются.
• Защита: rate-limit по IP и по сессии, авто-бан при флуде, ограничение длины сообщения, фильтр промпт-инъекций на русском и английском, история диалога с обрезкой контекста.

Задача: система, которая отвечает на вопросы по объёмной нормативной базе и показывает, из какого документа взят ответ.

• Индексация смешанного корпуса: текстовые главы и PDF (извлечение текста через PyMuPDF).
• Чанкинг 500 символов с перекрытием 50 → 59 121 фрагмент (14 185 из текстов, 44 936 из PDF).
• Поиск top-15 с порогом похожести: отсекает нерелевантный контекст вместо того, чтобы подмешивать его в ответ.
• Пересборка индекса одной командой — база обновляется без правки кода.

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

• Платежи: платёжный шлюз, схема «баланс с холдами»: клиент пополняет счёт, стоимость фиксируется при постановке в очередь, списание — только после успешной генерации. Проверка подписи вебхука, идемпотентность, ledger как единственный источник правды по деньгам.
• Очередь: PostgreSQL, FOR UPDATE SKIP LOCKED, полосы local/cloud, приоритеты, ограничение параллельности по полосе — локальная карта не должна захлёбываться.
• Генерация: локально ComfyUI + LTX на своей GPU, облачные провайдеры как вторая полоса — маршрутизация по типу задачи и по загрузке.
• Услуги в проде, каждая проверена сквозным прогоном: звук → видео (25/25), фото → видео (30/30), сжатие видео (47/47 + 17 краевых; вход до 5 ГБ), караоке с титрами (28/28; 40 с трека → 1080p за 18 с), доступ к закрытому разделу бота по оплаченному коду (67/67).
• Файлы крупные: приём до 5 ГБ через nginx без буферизации на диск (proxy_request_buffering off) — тяжёлое тело сразу идёт в приложение, которое обрывает чтение на своём лимите и объясняет причину раньше, чем клиент увидит сухой 413.

Оркестратор GPU — отдельная технология проекта. Пять GPU-сервисов (удаление фона, транскрибация, OCR, синтез речи, музыка) живут на одной видеокарте и не влезают в память одновременно. Написан арбитр: у каждого сервиса есть приоритет, пиковая и простойная память, TTL и флаг always_on; перед загрузкой тяжёлой модели арбитр выгружает более «дешёвые», а выгрузка — это HTTP-запрос к самому сервису, а не убийство процесса.

• Координация через POSIX-лок: арбитр вызывается каждым сервисом перед загрузкой модели, поэтому гонки исключены — и никакого WebSocket и дёрганья systemd (транзитные состояния ловить нельзя).
• Свободная память считается с поправкой на неизбежный резерв драйвера: «свободно по nvidia-smi» ≠ «доступно сервису».
• Реестр сервисов в JSON + отдельный таймер-reaper, который снимает зависшие отметки о занятости.

Задача: из фотографии товара на любом фоне получать вырезанное изображение для карточки интернет-магазина — быстро и без Photoshop.

• Две модели сегментации (BiRefNet и BEN2) с прогревом при старте, чтобы первый запрос пользователя не ждал загрузки весов.
• Замеренное время обработки — 190–200 мс на фото 900×1200.
• Отдача в PNG с прозрачным фоном и JPEG на белом; второй формат досчитывается по требованию, а не сразу.
• Найден и устранён баг скачивания (рекурсивный вызов обработчика клика), скачивание переведено на временный элемент, добавлена защита от двойного клика и освобождение памяти. Проверено автоматизированным тестом в реальном браузере.
• Переезд на другой сервер без простоя: подняли новый инстанс, прогрели, переключили прокси, погасили старый.

Задача: превращать длинные видео в готовые вертикальные ролики с субтитрами, переводом и очисткой речи.

• Транскрибация: faster-whisper с таймкодами на каждое слово (на них строятся караоке-субтитры и вырезание слов-паразитов), VAD-фильтр отсекает музыку и тишину, экспорт в TXT / SRT / JSON.
• Нарезка 9:16: размытый увеличенный фон и кадр по центру (ffmpeg), субтитры ASS с подсветкой активного слова; до 12 фрагментов за раз по точным меткам.
• Перевод фраз батчами через LLM и чистка речи с группировкой соседних слов в один вырез.

Задача: собрать все организации города, а не «топ-50», который сервис отдаёт на один поисковый запрос.

• Диагностика: один центр города на общем зуме → 49 организаций. Это не «все», а лимит выдачи.
• Решение — сетка: область разбивается на ячейки 1–2 км с перекрытием 30 %, поиск идёт по каждой ячейке на детальном зуме, где лимит не срабатывает.
• Геометрия Web Mercator (метры на пиксель, длина градуса долготы по широте) вынесена в отдельный модуль и тестируется без запросов к сервису.
• Дедупликация по ID, отброс служебных вкладок, чекпойнт после каждой ячейки и запись результата сразу на диск — обрыв не теряет собранное, прогон возобновляется.
• Устойчивость к блокировкам: внешний SOCKS5 с авторизацией и локальный мост-прокси, ротация адресов.

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

• Задачи и прогресс: постановка в очередь, отмена, статусы по каждой ячейке сетки (у большого прогона — тысячи ячеек), история и возобновление после обрыва.
• Выгрузки: XLSX с результатом; длинные запросы не режутся таймаутом прокси (300 с на чтение и запись).
• Вход по коду на почту, с жёстким лимитом на ручки авторизации: каждый запрос — это письмо, поэтому флуд давится отдельной зоной лимитов. Лимиты вынесены в conf.d, потому что зоны limit_req живут только в http-контексте и внутри server роняют nginx.
• Живой лог — через SSE, а не опросом: раньше браузер каждые 3 секунды тянул лог целиком и каждые 5 секунд — список задач. С ростом числа вкладок нагрузка росла линейно.

Что сделано с нагрузкой (проект v35-bus, этап 1): поднят Redis 7 с AOF и noeviction, воркер публикует события (job_started, job_log_line, job_progress, cell_done, busy_changed) в Stream через XADD … MAXLEN, фронт читает их одним долгоживущим соединением /api/events. Выбраны именно Streams, а не pub/sub: pub/sub не хранит историю, и вкладка, открытая на секунду позже, теряет прогресс.

• Порядок подключения: курсор (Last-Event-ID) → снимок текущего состояния → чтение строго после курсора. Поэтому перезагрузка страницы не теряет прогресс.
• Публикация событий никогда не бросает исключение и после сбоя уходит на паузу: упавший Redis не должен добавлять ожидание в каждую строку лога.
• Лог отправляется пачками через pipeline: один сетевой round-trip на десятки строк.
• Резервный путь сохранён: при недоступном Redis клиент получает событие degraded и возвращается к редкому опросу, а не к пустому экрану.

Кубы данных поверх сырых таблиц. Сырые данные в панели — это нормализованные таблицы: город, ячейка сетки, организация, связь «организация ↔ ячейка», прогон. Считать по ним «сколько объектов в квадрате» каждый раз заново нельзя: на большом городе это тысячи ячеек и сотни тысяч связей. Поэтому поверх них — агрегированные таблицы-кубы с готовыми разрезами:

• геометрия: город × ячейка (строка, колонка, координаты, статус, признак кромки) — из этого рисуется карта без единого JOIN-а;
• покрытие: счётчики по статусам ячейки (done, empty, partial, banned, pending) — прогресс прогона читается одним запросом;
• плотность: число найденных объектов и ссылок на ячейку — именно эти числа задают цвет квадрата и легенду 0 / 1–3 / 4–10 / 11–25 / 26–50 / 50+;
• разрез по прогонам: таблица city_run хранит счётчики по каждому поисковому запросу (задач всего / выполнено / с ошибкой, ячеек пройдено / пустых / частичных, ссылок) — из неё видно, какой именно прогон закрыл квадрат.

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

Задача: дать LLM-клиентам (Claude, Cursor и любым другим агентам) штатный способ искать в Яндексе, а не подсовывать им "сам напиши запрос и попробуй угадать".

• Сервер на FastMCP, поднят на американском VPS (82.38.69.191), версия 1.29.0. Транспорт — Streamable HTTP по адресу /mcp, авторизация Bearer-токеном.
• Полный рукопожатие MCP: initialize → сессия Mcp-Session-Id → notifications/initialized → tools/list → tools/call. Сервер умеет отдавать ответ и чистым JSON, и через SSE (text/event-stream) — именно последнее ждёт большинство клиентов.
• Тул yandex_search с параметрами query и max_results, внутри — Yandex Search API v2; в ответ идёт готовый текст с заголовками, ссылками и сниппетами.
• Написан и клиент (mcp_yandex.py): разбор SSE-кадров, ручное управление сессией, вызов тула из командной строки — чтобы проверять шлюз без чужого фреймворка.

Задача: у торговой программы своя СУБД «FC» на файлах .trd и никакого API. Нужно было читать данные снаружи и строить обмен с 1С.

• Разобран формат файлов без документации: таблицы, смещения полей, типы чисел (BCD/double) — и поверх них написан read-only HTTP API FenixTradeAPI/2.0 на Python 3.14.
• 15 эндпоинтов: /api/meta, /api/documents (222 792), /api/items (1,25 млн позиций), /api/products (89 798), /api/customers (16 720), /api/payments, остатки, склады, счета, связи.
• Честность про качество данных: шапки документов читаются верно (суммы, авторы, контрагенты), а текстовые и числовые поля товаров, позиций и клиентов пока читаются со смещением — это зафиксировано в статусе проекта, а не спрятано.
• Обмен с 1С: разобран готовый контракт выгрузки (ExportTradeTN_to1C.csv: артикул, наименование, цена, партия, НДС, ГТД) и конфиги батч-выгрузки trade50.exe @cfg.

Часть 1 — панель для отладки скрипта обзвона. Разговор идёт письменно: оператор отвечает по скрипту, а модель играет собственника — с возражениями, сомнениями и торгом. Так скрипт проверяется на десятках разговоров без единого реального звонка.

• Две роли и 9 типажей собственника; в шапке видно, по какому промпту идёт каждая сторона, и можно сравнивать два набора промптов.
• Подстановки собираются разбором документов, а не генерацией — модель, придумывающая реплики, придумает и цифры; здесь 43 фразы из скрипта и готовые отработки возражений, плюс отдельная группа «пробелы в базе».
• Версионность промптов и базы знаний с откатом, разбор прогона, вход по коду на e-mail с allowlist администратора.

Часть 2 — голосовой контур через GSM-шлюз. Железный шлюз Yeastar/NeoGate TG100 (GSM/3G ↔ VoIP, одна SIM) заведён в сеть и оживлён с нуля:

• Восстановление доступа: сброс кнопкой только при подаче питания, вход через CGI. Главная ловушка — поле secret: устройство считает его само как base64(md5(пароль)), а затем сдвигает каждый символ на +2 по ASCII. Обычный base64 не подходит и даёт &error:1;.
• Маршруты проверены в обе стороны: SIP → GSM (абонент ответил) и GSM → SIP (входящий принят, номер звонящего передан).
• Голосовой бот целиком: звонок → SIP INVITE → RTP (PCMU 8 кГц) → VAD с адаптивным порогом → STT faster-whisper → LLM-консультант с RAG → TTS Silero → RTP обратно. В живом разговоре 3 реплики подряд: рекомендация шампуня, уточнение про окрашивание, вопрос «где купить».
• Замеры на живом звонке: распознавание 0,1–0,2 с, ответ консультанта 1,6–3,2 с, синтез короткой версии 1,1–1,5 с — до начала ответа 2,9–6,9 с.

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

1. Обход лимитов, а не «серфинг по страницам».

• Гео-сервис отдаёт только топ-50 на запрос — значит разбиваем город на сетку ячеек 1–2 км с перекрытием 30 % и обходим поквадратно; получилось 1 104 организации вместо 49.
• Маркетплейс закрыт капчей на прямые URL — идём через индексированную поисковую выдачу с операторами site: и поиском по ID карточки.
• У другого маркетплейса найден параметр API, отдающий карточки конкретного продавца за 1–2 запроса вместо перебора десятков тысяч SKU.
• ЕГРИП ФНС блокирует серию запросов — работают мобильные прокси с ротацией каналов и пауза при капче.

2. Неполные источники и дедупликация. Один каталог магазина дал 248 карточек, а реально их 3 997. Метод: три независимых источника (пагинация каталога, 20 категорий магазина, поиск по магазину), затем объединение по ID. Воронка по другому маркетплейсу: 1 365 кандидатов → 188 витрин → 50 подтверждённых.

3. Верификация, а не доверие. Каждая карточка открывается отдельно: проверяется продавец, h1, бренд в разметке и жив ли товар. Результат в отчёте: 190 активных карточек Keune и 0 удалённых — то есть цифра проверена, а не найдена регуляркой. Скриншот каждой карточки — 190 снимков — доказательная база, которую не оспорить «страница поменялась».

4. Реквизиты и документы. Выписки ЕГРИП по ОГРНИП скачиваются с подписью УКЭП и разбираются: парсер ищет значения по названию показателя, а не по номеру строки — выписки бывают двух разных вёрсток, и наивный парсер ломается на второй. Дальше — генерация комплекта: заявление в DOCX, сводный PDF для печати, реестр в XLSX на 23 графы.

5. Устойчивость длинных прогонов. Обход идёт часами: чекпойнт после каждой ячейки, запись результата сразу на диск с flush(), возможность возобновления с произвольной точки. Обрыв связи или блокировка не обнуляют два часа работы. Дедупликация по ID, отброс служебных вкладок (/reviews, /gallery, /prices), лог с прогрессом и скриншотом каждой проверки.

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

• Яндекс.Маркет: 50 продавцов и 1 506 карточек; воронка от 1 365 кандидатов до 50 подтверждённых витрин.
• Проверка актуальности карточек: 1 357 из 1 422 актуальны (95,4 %), отчёт с прогресс-файлом и возможностью перезапуска после сбоя.
• Wildberries: 18 продавцов и 1 555 карточек; найден способ получать карточки конкретного продавца за 1–2 запроса вместо перебора десятков тысяч SKU.
• Выписки ЕГРИП с сайта ФНС: запрос → статус → скачивание подписанного PDF; парсер ищет значения по названию показателя, а не по номеру строки — иначе ломается на второй вёрстке документа.
• Генерация комплекта документов: папка на каждого ИП, заявление в DOCX, выписка, карточки, сводный PDF для печати и реестр в XLSX на 23 графы.

Что это: не один бот, а парк из 17 сервисов в продакшене, каждый под своим systemd-юнитом: 10 на американском VPS (нужен для части API и для обхода гео-ограничений) и 7 на домашнем сервере с GPU.

На американском VPS (82.38.69.191):

• MCP-шлюз поиска (mcp-yandex, порт 8081) — тот самый Yandex Search Gateway из отдельного кейса.
• Анализатор сайтов — оркестратор в три потока: доступность и скорость (HTTP-проба + PageSpeed Insights), техническое SEO (robots, sitemap, title, meta, H1, SSL) и позиции в Яндексе по ключевым фразам.
• Мониторинг доступности — проверяет список сайтов по интервалу и присылает в Telegram, когда сайт упал и когда поднялся; состояние в state.json, подписчики отдельным списком.
• Генератор HR-статей, обработчик изображений, помощник, бот отеля и три юридических бота (включая споры с СНТ).

На домашнем сервере с GPU (7 сервисов):

• MAX-ассистент (MAX Bot API) — самый большой: 56 функций в одном боте. Умеет: диалог с LLM и историей, разбор присланных изображений, транскрибацию голосовых, генерацию чертежей (рендер математики и геометрии в картинку), раздел тренажёра с вопросами и отдельный раздел тестов.
• Платный доступ кодом: клиент покупает на сайте код из 8 цифр на 1 час — бот проверяет его отдельным сервисом и пускает в закрытый раздел; админский пароль работает всегда.
• Платёжный бот СДЭК (webhook, БД, QR и ссылка на оплату, хранение согласий на обработку ПД), школьный бот с админ-правами по Telegram ID, боты-консультанты для сайтов (FastAPI + LLM, антифлуд, фильтр инъекций, уведомления менеджеру).

• Два сервера (i9, Ubuntu, NVIDIA): nginx-прокси на одном, инференс на другом; доступ к порту инференса закрыт фаерволом для всех, кроме прокси.
• Управление видеопамятью как ресурсом: посчитан бюджет, сервисы разнесены по машинам, предусмотрен «предохранитель» — переключение тяжёлого сервиса на CPU, чтобы не было конфликта портов и crash-loop.
• Автоматическая двусторонняя синхронизация документов между машинами: сначала pull, потом push (исключает «пинг-понг»), разрешение конфликтов по времени файла, проигравшая версия не удаляется, а уходит в отдельную папку.
• Обслуживание: ротация логов и лимиты (диск перестал переполняться), плановые задачи, диагностика после сбоев питания, клонирование системы на второй диск через rsync.

• Локальный запуск LLM и веб-интерфейса к ним: свои модели, свой интерфейс, обновление без потери данных.
• Генерация видео локально: ComfyUI + LTX, работа в 16 ГБ видеопамяти, офлоад тяжёлых компонентов, математика кадров.
• Сравнение стоимости: локально / напрямую у вендора / через посредника — посредники накручивают до ×2–2,9.
• OCR-сервис: изображение → текст, автовыбор GPU или CPU.
• Отдельный эксперимент: разблокировка вычислительных блоков у карты, предназначенной для майнинга, — 68,55 TFLOPS FP16 на тензорных ядрах, стабильность под 100 % нагрузкой.

• Магазины и сайты на Webasyst/Shop-Script: собственная тема, шаблоны, плагины, каталог, миграции с бэкапами.
• Ускорение: разбор Lighthouse и точные правки — отложенная загрузка скриптов, приоритет для главного изображения, перегенерация логотипа с 7,7 КБ до 2,3 КБ, сброс кэша шаблонов. Каждая правка — с проверкой, что страница отвечает 200 и в логе ошибок пусто.
• Аналитика: собственный счётчик уникальных посетителей по дням.
• Баги, которые видны только на живом трафике: растянутые изображения каталога, падение на пустом значении во вспомогательном методе, неправильный ID блога.