Я собирал её сам с помощью AI-агентов: схема БД, миграции, API, серверный интерфейс, интеграции, плановые задачи, Docker, автодеплой и правила для AI-агентов. Это основной рабочий проект последних месяцев. Я использую его в операционной работе своего бизнеса.

Масштаб системы

36 таблиц, 33 Alembic-миграции, 18 роутеров FastAPI, 186 API-эндпоинтов, 16 страниц серверного интерфейса на Jinja. Бэкенд на Python/FastAPI + PostgreSQL, фронт серверный, визуализация — встроенный Metabase.

Данные

Синхронизация с OneBox CRM: около 82 000 заказов в истории. 510 реестров NovaPay и примерно 15 000 платежей сопоставляются с заказами автоматически. Курсы НБУ по USD/EUR подтягиваются ежедневно, рекламные данные FB/TikTok приходят через Airbyte Cloud в Postgres.

Интеграции

OneBox CRM, Nova Poshta, Airbyte для FB/TikTok, Gmail OAuth для реестров NovaPay, НБУ, OpenAI для GPT и Whisper, Metabase, Railway для размещения и запуска.

Качество и доступ

25 автопроверок целостности данных, RBAC на трёх уровнях, ручные правки по клиентам хранятся отдельно и не перезаписываются при синхронизации. 6-уровневая логика определения пола клиента по справочнику из 10 514 имён — неизвестных меньше 0.5% по всей базе.

AI в контуре

Один агент анализирует рекламу FB/TikTok через SQL-представления и подсвечивает проблемы в воронке. Второй работает как бизнес-аналитик по продажам, финансам и товарам. Голосовой ввод — через Whisper.

Дисциплина проекта

CLAUDE.md — рабочая инструкция для AI-агента, которую я обновляю после изменений. Формулы оборота, маржи и логистики защищены от случайных правок, SQL-представления восстанавливаются после сбоев Airbyte.

Приём и обработка резюме

Резюме приходят в разных форматах — PDF, DOCX, HTML, Markdown, текст, в том числе трудные сканы и многоколоночные макеты. Приём отделён от обработки, как сырые заявки в CRM: сначала загрузил пачку, потом запустил обработку — она идёт фоновой очередью с живым прогрессом. Разные форматы обрабатываются по-разному: PyMuPDF проверяет структуру файла (есть ли текстовый слой, колонки, картинка), простые форматы читает MarkItDown, а сложные напрямую читает claude -p. Из текста модель достаёт базовые данные кандидата и до 10 широких ролей в порядке приоритета — по ним потом идёт предварительный отбор.

Профиль вакансии и модель баллов

Текст вакансии — печатью, документом или голосом — система разбирает в портрет и критерии в трёх группах: навыки, опыт и стоп-факторы. Вес критерия — это его важность по шкале 1–10. Балл критерия — это доля его важности от ста, поэтому сумма по всем плюсовым критериям всегда равна ста. Стоп-факторы считаются отдельно: они идут в минус, и у штрафа есть потолок. У каждого критерия описаны наблюдаемые «отлично» и «неприемлемо», а не абстрактное «соответствие высокое». У профиля есть версии: правка веса создаёт новую версию и сохраняет историю для калибровки.

Предварительный отбор и оценка

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

Доказательства и калибровка

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

Воронка, интервью и аналитика

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

Логика проекта

Архитектурно это тот же скелет, что в Aroma Dashboard, но с другой предметной областью: FastAPI, серверный интерфейс, фоновые очереди, доступ к моделям через сменный адаптер — локально через claude -p бесплатно или облачные модели через OpenRouter. Главный принцип у меня повторяется из проекта в проект: модель делает то, что меняется от случая к случаю — читает смысл, формулирует, — а то, что должно быть предсказуемым, держится в коде: расчёт баллов, проверка цитат, стаж, даты, сведение оценок нескольких моделей.

Стратегия

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

Аудитория разделена на два слоя: массовая B2C-аудитория с бытовыми, военными, семейными и кризисными юридическими вопросами; и B2B/премиум-сегмент — бизнес, собственники и люди с высокими юридическими рисками. Логика воронки: короткие видео и полезный контент → доверие и подписка → консультация → продажа абонемента или индивидуальной услуги.

Сайт и SEO

Сайт должен был стать центральной точкой проекта: туда должны вести соцсети, реклама, лид-магниты, блог и будущие AI-сценарии. Я собрал основную техническую базу на Next.js: двуязычие, canonical, hreflang, sitemap, Open Graph, оптимизация изображений, breadcrumbs, авторские страницы, юридические страницы и базовая SEO-инфраструктура.

Отдельно добавлены элементы, которые помогают пользователю проверить проект: Schema.org, разметка эксперта, организации, юридической услуги, контактов и статей. FAQ-хаб закрывает 114 вопросов на двух языках — всего 228 карточек. Его задача простая: отвечать на реальные тревожные запросы пользователей, усиливать SEO и давать сайту больше точек входа из поиска.

Контентная система

Я спроектировал модель первого месяца контента на 92 карточки: AI-avatar video, статичные посты, карусели, premium video и статьи. Контент разделён по себестоимости: дешёвый, средний и дорогой. Так бюджет можно объяснять через конкретную роль каждого формата: что даёт дешёвый, средний и дорогой контент.

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

AI / RAG / автоматизация

В проекте описана AI-инфраструктура: юридическая база знаний, Smart Chunker + Qdrant для векторизации, SEO-RAG-эксперт на 3000 чанков и AI Safety workflow для проверки юридического контента.

Также я спроектировал будущий n8n-контур для обработки входящих сообщений. Логика: соцсети → n8n → история диалога → RAG-запрос к юридической базе → Claude → safety-фильтр → ответ клиенту или передача горячего лида в Telegram/CRM. Этот блок зафиксирован как обязательный перед запуском таргета, чтобы не терять входящие обращения и не обрабатывать поток вручную.

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

Документация

Подготовлена операционная база: Operations Handbook, Recovery Playbook, RACI-матрица, link-building playbook, monitoring templates, article playbook и AI Content Safety workflow. Это нужно, чтобы проект не зависел от памяти одного человека и его можно было спокойно передать другим исполнителям.

Итог

За месяц у проекта появились сайт, SEO-база, FAQ-хаб, блоговая структура, контентная модель, AI/RAG-архитектура, n8n-концепт, план парсинга аудитории и конкурентов, а также операционные правила. Такой набор уже можно использовать как базу для контента, рекламы и дальнейшей автоматизации.

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

База знаний и инструкции

В системе есть материалы по работе с основными AI-инструментами для видео и голоса: Nano Banana, Seedance 2, Veo 3, HeyGen, ElevenLabs и другими. Отдельно собраны правила по камере, сценариям, визуалу, текстам, обложкам и монтажной логике. Поэтому агент видит и тему ролика, и подходящий инструмент для каждого шага.

Клиентская ниша

Для консалтингового клиента в юридической нише я собрал базу знаний по теме и контент-план на 3000+ тем. Дальше тема по расписанию попадает в пайплайн: система берёт её из очереди, создаёт рабочую карточку, запускает агентные шаги и ведёт состояние до финального файла.

Производственный цикл

• Claude Code делает из одной темы три разных угла подачи. Каждый вариант собирается в 5 публичных блоков: зацепка, текст озвучки, подпись к посту, текст обложки и описание визуала для обложки.
• Через Fal.ai создаётся обложка, обычно на Nano Banana.
• ElevenLabs делает озвучку голосом клиента с тегами интонации и эмоций.
• HeyGen создаёт AI-аватар по готовой озвучке.
• По alignment-файлу Claude Code собирает карту видео: где остаётся A-roll с аватаром, где нужны B-roll вставки, какие эффекты и какие промпты нужны для каждого фрагмента.
• Fal.ai параллельно генерирует видеоряд для B-roll.
• Python-скрипт вместе с ffmpeg собирает финальное видео, накладывает субтитры и приводит материалы к единому формату.

Что получается на выходе

Одна тема превращается в три видео с разными углами подачи. В среднем полный цикл занимает около 15–20 минут, а себестоимость одной единицы получается примерно $1.5–3 в зависимости от качества и количества B-roll. Логику можно перестроить под другой формат: карусели, серийные видео со статичными персонажами, AI-аватары с B-roll или рекламные креативы для другого бизнеса.

Почему это важно

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

Админ-агент

Внутри есть агент-администратор: он доступен из терминала и через Telegram. Он знает активный проект, режим работы, проектные папки, библиотеку скиллов и помогает запускать фазы для субагентов. Когда появляется новая идея, я обсуждаю её с ним, а он ведёт её по протоколу: сначала уточняет смысл, потом фиксирует границы, потом помогает разложить работу на фазы.

1. Vision

Первый шаг — собрать видение. На входе сырая идея голосом или текстом. Агент пересказывает, как понял, задаёт вопросы, ищет слабые места и собирает документ видения. В нём 11 блоков, включая суть, решение, MVP и то, что сознательно не входит в первую версию. Дальше система может сама предложить следующий шаг цепочки.

2. Plan

Второй шаг — технический план. Агент берёт утверждённое видение и превращает его в план реализации: 5–10 этапов, задачи внутри этапов, артефакты на выходе и чеклисты аудита. Он не расширяет задачу и держится в согласованных границах.

3. Pipeline

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

Результат

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

Задача пайплайна — сохранить материал так, чтобы с ним мог работать агент: убрать дубли, воду и разрозненность, разложить знания по темам, категориям и устойчивым ID. Для сбора и подготовки источников используются Tavily, Firecrawl, Apify и Whisper; после этого агент работает с базой через индекс и точечную подгрузку нужных тем.

Сбор и извлечение

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

Оркестрация агентов

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

Формат базы

Knowledge Base — это 9 широких Markdown-блоков: маркетинг, продажи, контент, AI-визуал, пайплайны, бизнес-операционка, психология влияния и когнитивные искажения. INDEX.md даёт карту блоков, категорий и тем, а ID темы остаётся устойчивым даже при переименовании.

Дедубликация и качество

Новая тема проходит фильтр дублей и воды. Если мысль уже есть в базе — пропуск. Если добавляет нюанс — объединение. Если это новая применимая идея — расширение. Спорное уходит в review, но не блокирует всю работу. В базе должны оставаться знания, которые помогают агенту принимать решения, без накопления лишнего текста.

Готовность к RAG

Markdown остаётся главным источником правды, но структура уже подготовлена для гибридного поиска: темы имеют ID, каждая тема достаточно самостоятельна, есть служебный векторный слой для поиска дублей. Когда нужно подключить агента к базе через RAG, эту архитектуру можно быстро перегнать в векторную БД с чанками до 2000 символов.

Когда я начал работать с AI-агентами, быстро стало видно две вещи. Первая — контекстного окна мало для регламентов, цен, внутренних правил и других специализированных знаний. Вторая — общие знания модели часто нормальные, но недостаточно глубокие для узкой задачи. Значит, нужная информация должна быть подготовлена и доступна агенту в правильном виде.

Почему понадобился свой инструмент

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

Детерминированное ядро

Smart Chunker парсит Markdown в дерево заголовков H1/H2/H3 и применяет 7 правил: границы родителя, допустимый диапазон размера, объединение маленьких соседних секций, деление больших секций по абзацам, спуск к детям, жёсткие min/max границы и обработка документов без заголовков. Overlap не используется: лучше видеть проблемный чанк и поправить источник, чем плодить дубли.

Автоподбор и контроль качества

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

AI-обогащение

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

Загрузка в векторную базу

Последний этап — подготовка к Qdrant: dense-векторы через embeddings, sparse-векторы через локальный BM25, создание коллекции, Smart Match для обновления существующих чанков и загрузка с прогрессом. API-ключи не сохраняются на сервере: они задаются в интерфейсе и живут только в браузере.

Я использую этот сервис вместе с Knowledge Pipeline: один пайплайн собирает и очищает базу знаний, второй превращает подготовленные Markdown-документы в качественные чанки для RAG и векторной базы.

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

Одна доска для человека и агента

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

Из чего собрана доска

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

Артефакты как контракт между разделами

Отдельный слой — артефакты, то есть данные, которые один раздел передаёт другому. Артефакт описан один раз в каталоге, а на доске стоят его ярлыки в разных точках потока. Один и тот же объект, например «Резюме», на входе стоит как «Сырой», а на выходе как «Нормализован» — так видно, как он меняет состояние, и правка описания сразу видна везде.

Вся конкретика прямо на узле

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

Один источник правды

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

Инструменты для агента

Агент работает с доской через 23 MCP-инструмента. Часть из них — на создание: добавить раздел, связь, артефакт или область, разложить схему автоматически. Часть — на чтение: компактная карта проекта, поиск по названию и тексту, чтение одного раздела вместе с его вложениями. Читающие инструменты отдают ровно нужный кусок, поэтому агент разбирается даже в большом проекте, не выгружая всё подряд.

Идея простая: под любую задачу сначала искать готовое решение у себя в базе, а не заново прочёсывать весь GitHub. Для этого поток интересных репозиториев нужно собрать, разобрать и разложить так, чтобы по нему можно было искать и фильтровать.

Топ-агрегаторы вместо всего GitHub

Следить за всем GitHub невозможно, поэтому на входе не весь GitHub, а пять источников, которые уже делают отбор за меня: телеграм-каналы, которые находят и разбирают самые заметные проекты, и зеркало GitHub Trending, которое ловит то, что набирает звёзды прямо сейчас. Поток сразу отфильтрован до «стоит внимания», а новинки на росте попадают в базу автоматически.

ИИ-разбор каждого репозитория

Коллектор собирает репозитории и убирает дубли, затем по GitHub API добираются факты — звёзды, язык, размер реального кода. Дальше каждый репозиторий проходит через модель, которая делает карточку: краткое описание простыми словами по-русски, тип (приложение, сервис, библиотека, CLI, модель и так далее), сценарии использования и теги. Вместо сырой ссылки с англоязычным readme у меня понятная карточка, по которой сразу ясно, что это и зачем.

Ранжирование по скорости роста

База ранжирует репозитории не по общему числу звёзд, а по скорости роста — сколько звёзд и форков репозиторий набирает за день своего возраста. Поэтому наверх выходят не старые проекты с большими цифрами, а то, что набирает популярность прямо сейчас: хайп и быстрый рост. Балл считается по перцентилю внутри категории (0–100), поэтому быстрорастущий нишевый проект виден рядом с гигантами, а один гигант не перекашивает соседей. Это сортировка по умолчанию в каталоге.

Единые теги и 25 групп навигации

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

Два вида базы и два способа поиска

База хранится сразу в двух видах. Обычная, в PostgreSQL, со структурой из 46 полей — по ней точный поиск и фильтры: язык, звёзды, тег, группа, тип. И векторная, в Qdrant, — по ней смысловой поиск: пишешь запрос по-русски «чем транскрибировать голос», а не подбираешь ключевые слова. Смысловой поиск гибридный: плотный вектор плюс поиск по словам, потом переранжирование через Jina, чтобы наверх выходило самое релевантное.

Обновление и веб-интерфейс

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

С чего началось

Первый заход был через n8n. Я хотел собрать универсального ассистента, который принимает текст, голос, аудио и документы, умеет работать с Telegram, Google Drive, CRM, Postgres и OpenAI, а часть памяти хранит в векторной базе. В n8n было собрано 6 workflow разной сложности, включая крупного мультимодального Telegram-бота примерно на 172 узла.

Переход к Digital Persona

Дальше стало понятно: если ассистент должен быть полезнее обычного чат-бота, ему нужно лучше понимать человека. Так появилась Digital Persona — MVP идеи о цифровом профиле человека через структурированную диагностику, чтобы агент мог адаптировать коммуникацию под конкретного пользователя.

Технически это был FastAPI backend + Next.js 14, PostgreSQL, Qdrant, Docker и деплой на Railway. Внутри — 5 диагностических модулей, 86 вопросов, 47% адаптивных вопросов через RAG, голосовой ввод через Whisper, админка для YAML-модулей и системных промптов, логирование LLM-вызовов.

Что было важным технически

Главный урок — разделение LLM и детерминированной логики. LLM извлекает свидетельства из ответов в JSON-формате, а оценка считается кодом: веса по типу вопроса, уверенность, специфичность, согласованность, ограничения на вклад одного свидетельства. AI помогает извлекать смысл, но финальная оценка не отдаётся модели целиком.

Почему это не рабочий продукт

Продуктовую ветку я сознательно остановил. Сейчас я не пользуюсь этой системой как готовым продуктом. Но как R&D-проект она была полезна: здесь появились паттерны, которые потом перешли в Aroma Dashboard, Content Pipeline, Knowledge Pipeline и Smart Chunker.

Что осталось полезным

Соционическая Qdrant-коллекция примерно на 900 чанков живёт как domain RAG и может подключаться из других проектов. n8n я продолжаю использовать для узких регулярных автоматизаций, интеграций и связок между сервисами, особенно когда его можно соединять с более сильным кодовым и агентным стеком.

С чего началось

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

Как это работает для гостя

QR на столе → мессенджер без установки приложений и без регистрации → диалог на родном языке текстом или голосовыми. Помощник уточняет формат визита, бюджет и ограничения по питанию, потом даёт 2–4 точных рекомендации с пояснением, а не список из 80 позиций. Дальше — логичная мягкая допродажа: напиток, гарнир, соус, десерт. Гость приходит к официанту уже определившимся.

Почему мессенджер, а не приложение или веб-меню

Выбор мессенджера был не случайным. Мобильное приложение упирается в установку, регистрацию и слабый возврат после разового визита. Веб-меню по QR — это статичный список, такой же как бумажный, только на экране, диалога в нём нет. Мессенджер закрывает оба ограничения: минимум трения на входе (камера → код → знакомый интерфейс), естественный формат диалога с голосом, и переписка остаётся у гостя. Ресторан может позже аккуратно вернуться к диалогу.

Как формируется рекомендация

Рекомендация собирается из четырёх частей. Первая — профиль гостя из диалога: формат визита, вкусовые предпочтения, бюджет, аллергии и ограничения. Вторая — жёсткие фильтры: стоп-лист по позициям, стоп по ингредиентам в базовой версии, ограничения по бюджету и аллергиям. Третья — бизнес-приоритеты ресторана: продвигаемые позиции, маржинальность, время дня, событие. Четвёртая — короткий набор из 2–4 вариантов с понятным объяснением, почему эти блюда подходят. LLM работает на первом и четвёртом слое — извлечение смысла и формулировка. Фильтры и приоритеты — детерминированная логика, чтобы поведение системы было предсказуемым и управляемым со стороны ресторана.

Две версии продукта

MVP (пилот) — один мессенджер, два языка, текст и голос, учёт бюджета и аллергий, рекомендации блюд и напитков, стоп-лист, ручное продвижение приоритетных позиций, простая таблица управления без техзнаний. Этого достаточно, чтобы проверить гипотезу в реальном зале.

Базовая подписка — несколько мессенджеров, четыре языка, умный апселл с учётом блюда и времени дня, стоп по ингредиентам (один ингредиент скрывает все связанные блюда), карточка заказа для официанта с номером стола и пожеланиями, перевод ключевых фраз гостя персоналу, базовая аналитика запросов и оценка визита.

Дополнительные модули

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

Модель внедрения с низким риском

Модель внедрения простая: ресторан сначала проверяет MVP в реальном зале и только потом обсуждает оплату. Шесть этапов: подготовка (ресторан передаёт меню, составы, приоритетные позиции — техническая часть на стороне команды) → бесплатный запуск MVP в реальном зале → сбор обратной связи от гостей, официантов и управляющего → улучшение сценариев на реальных диалогах → обсуждение условий подписки на данных пилота → переход к базовой версии. Решение о платном этапе принимается после того, как ресторан уже увидел инструмент в работе.

Роль официанта и работа с залом

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

Риски, которые я учитываю

Первый риск — поведенческий: часть гостей просто не воспользуется помощником, и это нормально. Использование добровольное, классический формат «официант + меню» остаётся работать параллельно. Второй риск — сопротивление персонала, его снижает дизайн продукта (см. выше) и то, что MVP не требует отдельного обучения команды. Третий — техническая среда: работа зависит от интернета и доступности мессенджера, но это не влияет на кухню и кассу; в худшем случае ресторан просто работает в обычном режиме. Четвёртый — нет гарантий роста выручки: инструмент усиливает процесс, но результат зависит от меню, кухни и сервиса. Поэтому модель — бесплатный пилот, а не предоплата за обещание.

Почему это пока R&D

Концепт и продуктовая спецификация готовы: структура из 117 пунктов, презентационная версия для собственника, таблица функций по версиям и модулям. Технически продукт собирается из уже знакомых мне блоков — мессенджер-канал, LLM с RAG по меню, голосовой ввод, простая админка. Чего пока нет — пилотного ресторана. Запуск имеет смысл только в реальном зале с реальными гостями, синтетический тест эту гипотезу не закроет.

Логика проекта

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

Зачем он нужен

В трейдинге легко обмануть себя красивым графиком или удачным отрезком истории. Smart Backtester прогоняет гипотезу через полный цикл проверки: исторические свечи → индикатор → торговые сигналы → симуляция сделок → статистика → оптимизация параметров → сохранение результата → повторная проверка. Если число меняется, это должно быть объяснимо, а не “так получилось после правки”.

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

Система читает бинарные RVDF-файлы со свечами, прогоняет их через 13 индикаторов и приводит сигналы к единому формату через Power Engine. Дальше Zero Exit решает, когда выходить из позиции, бэктестер симулирует сделки, а статистический слой считает 40+ метрик: equity curve, MTM, MAE/MFE, PnL, просадку, сделки, комиссии, свопы и другие параметры.

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

Один из выводов: режим SAR был полностью удалён после анализа 50 CSV-файлов оптимизации. В прямом сравнении Zero Exit выиграл 21 из 25 случаев, поэтому система стала проще и стабильнее: один режим выхода, меньше ветвлений, меньше мест для ошибки.

Оптимизатор параметров

Grid-оптимизатор перебирает комбинации параметров, поддерживает ограничения, чекпоинты и возобновление, ранжирует результаты по перцентилям и оценивает плато — то есть смотрит на лучший пик и на устойчивость соседних параметров. Это снижает риск выбрать настройку, которая хорошо выглядит только на одном отрезке истории и ломается при небольшом изменении рынка или периода. Оптимизатор запускается отдельным процессом, а прогресс виден в интерфейсе в реальном времени.

Дашборд и база результатов

Интерфейс собирает результаты в матрицу 13 индикаторов × 5 групп таймфреймов: ULTF, LTF, MTF, HTF, MACRO. Это 65 зон проверки: видно, где параметры уже подобраны, где есть сильные результаты, а где ещё пусто. Для каждого индикатора и группы можно открыть оценку, параметры и метрики.

Результаты сохраняются в PostgreSQL: история бэктестов, пресеты, оптимизированные параметры, запуски оптимизатора, реестр индикаторов и история оптимизаций. Поверх этого работает REST API: backtest, symbols, timeframes, indicators, optimized-params, dashboard, optimizer, history, presets, health/ready.

Защита от случайных изменений

Отдельный блок проекта — защитные правила. В проекте есть 13 эталонных golden-тестов: если изменение кода ломает эталонный результат индикатора, этап не считается завершённым. Защищены бэктестер, статистика, индикаторы, чтение RVDF и логика проверки результатов. Эталонные фикстуры нельзя менять, чтобы “подогнать” зелёный тест.

Процесс работы с AI-агентами

В проекте есть правила агента, текущее состояние, handoff, worklog, спецификация, план реализации и отчёты по этапам. AI-агент может писать код и выполнять этапы, но не принимает продуктовые и бизнес-логические решения самостоятельно. Всё, что влияет на расчёты, сигналы, сделки, статистику или пользовательскую логику, согласуется отдельно.

Логика проекта

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

Контекст и роль

Это был мой первый технический проект, где я оплачивал и вёл разработку системы с нуля. До этого я в основном пользовался готовыми инструментами. На этом проекте я выступал владельцем продукта и архитектором: модель рынка, индикаторы, язык описания стратегий, правила бэктеста, логика live-исполнения, постановка задач, ревью, проверка гипотез и решения по границам проекта. Реализацию вёл внешний разработчик.

Собственная онтология рынка

Под гипотезу мы сделали свой доменный язык разметки вместо набора стандартных индикаторов. Базовые элементы — фракталы (FP), структурные точки (SP), вложенные диапазоны Macro / Micro / Sub, имбалансы (IMB / Fresh IMB), их деактивация через Full Fill, манипуляции SFP и RAID, Break of Structure. Поверх этого — формации Quasimodo (QM) и Entry QM (EQM) с фильтрами по ликвидности, переход от структуры к точкам интереса (POI) и дальше к Genesis, FTA и сигналу. Спецификация всей модели и стратегического слоя — 3 222 строки документа, который писался и поддерживался параллельно с кодом.

Walk-forward бэктест без заглядывания в будущее

Архитектурное ядро — поминутная имитация формирования свечей. В обычном бэктесте бар часто уже сформирован, и алгоритм незаметно “видит” больше, чем видел бы в реальной торговле. Здесь свеча собирается шаг за шагом, как в live-режиме, и стратегия принимает решение только на той информации, которая была бы доступна в этот момент. Это дороже по вычислениям, но убирает один из главных источников самообмана — расхождение между бэктестом и реальной торговлей.

JSON-конфиги стратегий с перебором параметров

Стратегии описывались через свой JSON-формат с разными типами параметров, фильтров и условий. Это давало перебор контекста без правки кода и отделяло логику стратегии от конкретных настроек. 12 JSON-конфигов были примерами стратегий, а не пределом системы. Такая архитектура позволяла быстро добавлять разные интерпретации рынка и проверять новые гипотезы.

Live-режим и приложение

Поверх бэктеста собран live-режим через MT5 с параллельной работой нескольких стратегий и Windows-приложение с графическим интерфейсом: панель инструментов, боковая панель, графики на pyqtgraph, статистика, Excel-репорты на десятки и сотни колонок. Сборка в отдельный .exe через PyInstaller / Nuitka, чтобы запускать без Python-окружения.

Почему направление закрыто

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

Я не считаю проект провалом: он закрыт, но его можно использовать как основу для новых проверок. В будущем его можно совместить со Smart Backtester или переупаковать в платформу для тестирования и анализа торговых идей.

Главные выводы из проекта

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

Второй вывод касается формата работы. Зависимость от внешнего разработчика оказалась дорогой в трёх вещах: сроках, границах проекта и стоимости. Именно после этого проекта я перешёл на самостоятельную разработку через AI-агентов: архитектура, темп и границы остаются у меня, а реализация ускоряется. Smart Backtester вырос из этого решения: та же область, но я уже собираю систему сам с помощью AI-агентов.