AI-компаньон, который помнит вас: как один диалог заставил переизобрести память бота

Как я в одиночку собрал production-сервис эмоциональной поддержки на современной языковой модели, довёл его до ~3 000 пользователей при LTV/CAC 13,7x — и почему один странный диалог оказался важнее любой фичи.

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

Попробовать вживую: бот @MiraDrug_bot · лендинг miradrug.ru (новая версия).

Аудио-обзор кейса

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

Коротко о продукте

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

Стек: Python 3.10 · python-telegram-bot v21 · Claude Sonnet 4.5 · SQLAlchemy 2.0 (async) · FastAPI · Redis · PostgreSQL · Google Cloud Storage · Docker · systemd.

Метрика	Значение	Ориентир по индустрии
Пользователей	~3 000	—
Сообщений на пользователя	178	~30–50
Retention D7	42%	20–25%
NPS	68	30–40
Рост	+35% в месяц	—
LTV/CAC	13,7x	3x — «здоровый»
Маржинальность	78%	—

Масштаб: 25 000+ строк кода, 100+ улучшений AI-слоя, 13 фаз роста — solo, от идеи и архитектуры до деплоя и питча инвесторам.

---

Проблема, ради которой всё затевалось

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

• 💰 Дорого — от 5 000 ₽ за сеанс, а нужно 10+.
• ⏰ Долго — запись на 3–4 недели вперёд.
• 🙈 Стыдно — стигма вокруг терапии никуда не делась.
• 📍 Недоступно — дефицит специалистов в регионах.

Идея была не в том, чтобы заменить психотерапевта. А в том, чтобы закрыть разрыв между «мне плохо прямо сейчас» и «приём через месяц». Компаньон, доступный 24/7 за цену в разы ниже живого сеанса — который помнит вас и умеет вовремя распознать, что человеку по‑настоящему плохо.

---

Ключевое решение: персона, а не ассистент

Первое, что определило продукт, — отказ от абстрактного ассистента в пользу персоны с биографией. Мира — женщина за сорок, замужем много лет, двое детей, сама прошла через выгорание. Это не косметика: биография зашита в системный промпт и задаёт тон — эмпатичный, без осуждения, с практичными советами вместо шаблонного «я тебя слышу».

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

---

Диалог, который изменил проект

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

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

Для чат‑помощника это терпимо. Для сервиса, который обещает «я помню тебя», — это провал в самой сути продукта. Я сформулировал проблему так: дело не в плохой памяти, а в том, что система не знала, что она забывает. Не было мета‑осознания. Именно этот случай стал катализатором главной инженерной работы проекта — архитектуры «живой памяти».

---

Что происходит за одним сообщением

Самое интересное — не «отправить текст в модель», а конвейер вокруг него. Каждое входящее сообщение проходит цепочку детекторов и сборщиков контекста и только потом попадает в LLM.

flowchart TD
    U[Пользователь<br/>текст / голос] --> TG[Telegram Bot API]
    TG --> SAN[Санитайзер<br/>XSS / SQLi / длина]
    SAN --> RL{Rate limit<br/>Redis}
    RL -- превышен --> LIM[Ответ-заглушка<br/>апселл Premium]
    RL -- ок --> VOICE{Голос?}
    VOICE -- да --> WSP[Whisper<br/>речь → текст]
    VOICE -- нет --> CRISIS
    WSP --> CRISIS{Детектор кризиса}
    CRISIS -- маркер паники/суицида --> PROTO[Протокол помощи<br/>хелплайн, приоритет]
    CRISIS -- норма --> CTX[Сборщик контекста]

    subgraph AI[AI-слой]
        CTX --> MEM[(Живая память<br/>эпизоды / эмоции /<br/>отношения / эволюция)]
        CTX --> SYS[Системный промпт<br/>персона «Мира»]
        MEM --> LLM[Языковая модель<br/>стриминг]
        SYS --> LLM
    end

    LLM --> STREAM[Стриминг в Telegram<br/>обновление сообщения]
    STREAM --> POST[Пост-обработка]
    POST --> MOOD[Анализ настроения<br/>12 эмоций]
    POST --> PROF[Извлечение профиля<br/>парсинг фактов]
    POST --> COST[Учёт стоимости API]
    MOOD --> DB[(PostgreSQL)]
    PROF --> DB
    COST --> DB

Принципы, которые нельзя ломать:

• Детекция кризиса — высший приоритет. Нашёлся маркер — обычный флоу прерывается, человек получает хелплайн. Это важнее любой «красоты» ответа.
• Анализ настроения не блокирует ответ. Настроение считается после генерации или параллельно, чтобы не тормозить стриминг.
• Весь ввод‑вывод асинхронный. База, Telegram API, стриминг модели — никаких блокирующих вызовов, только asyncio.
• Мягкая деградация. Упал внешний API — бот отвечает заготовкой и пишет в лог, а не падает.

Слои системы

graph TB
    subgraph Clients[Клиенты]
        BOT[Telegram-бот]
        MINI[Telegram Mini App]
        ADMIN[Админ-панель]
    end

    subgraph App[Приложение]
        HANDLERS[Хендлеры]
        AISVC[AI-сервисы]
        SVC[Сервисы<br/>оплата, рефералы,<br/>хранилище, планировщик]
        API[FastAPI<br/>webapp + admin]
    end

    subgraph Data[Данные]
        REPO[Репозитории<br/>единая точка доступа к БД]
        PG[(PostgreSQL)]
        RD[(Redis<br/>лимиты, кэш)]
        GCS[(Cloud Storage<br/>фото / голос)]
    end

    BOT --> HANDLERS
    MINI --> API
    ADMIN --> API
    HANDLERS --> AISVC
    HANDLERS --> SVC
    HANDLERS --> REPO
    API --> REPO
    REPO --> PG
    SVC --> RD
    SVC --> GCS

Жёсткое правило проекта: доступ к данным только через репозитории. Ни одного SQL-запроса в хендлерах — даже простого SELECT. Это дало предсказуемость и позволило безболезненно эволюционировать схему через миграции.

---

«Живая память»: почему бот действительно помнит вас

После того случая я перестал думать о памяти как о «длине контекста». Дешёвый бот просто закидывает историю в окно и надеется на лучшее. Здесь память — отдельная подсистема, которая перерабатывает опыт, а не хранит логи. Четыре типа:

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

flowchart LR
    MSG[Новое сообщение] --> PE[Извлечение профиля<br/>AI-парсинг фактов]
    PE --> FACTS{Что извлекли?}
    FACTS --> P1[Партнёр, дети,<br/>работа, хобби]
    FACTS --> P2[Попытки решения<br/>«я уже пробовала...»]
    FACTS --> P3[Триггеры<br/>чувствительные темы]
    FACTS --> P4[Эмоциональная<br/>память]
    P1 & P2 & P3 & P4 --> STORE[(профили<br/>+ таблицы памяти)]
    STORE --> CB[Сборщик контекста]
    CB --> LLM[Модель<br/>Free: 10 сообщений<br/>Premium: 20 + долгая память]

Несколько находок, которыми горжусь:

• Память о попытках. Если человек сказал «я уже пробовала медитировать», бот не будет советовать медитацию снова. Мелочь — но именно из таких мелочей складывается ощущение «меня слышат».
• Личные триггеры. Система помечает чувствительные темы и автоматически их обходит.
• Детектор просьбы о поддержке. Фраза вроде «я же не плохая мать?» — это не вопрос, а просьба о поддержке, и отвечать на неё надо иначе. Такие распознаются отдельно.
• Детектор противоречий — бережно уточняет, если человек рассказывает несовместимые вещи, а не «верит» ошибочному факту.
• Осознанное забывание. Память не копит мусор, а отпускает то, что мешает росту отношений, — забывание здесь часть развития, а не баг.

Итог блока: по внутренним замерам — +40% к удержанию и +50% к мотивации возвращаться.

---

Приоритеты: во что вкладываться первым

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

Главный принцип развития я сформулировал как «не чини — усиль резонанс»: не латать симптомы, а усиливать то, что и так работает хорошо.

---

Анализ настроения

После каждого диалога отдельный модуль классифицирует состояние по 12 эмоциям с оценкой уверенности:

радость · грусть · тревога · злость · спокойствие · воодушевление · одиночество · стресс · перегрузка · благодарность · надежда · разочарование

Данные ложатся в базу и превращаются в график динамики настроения в мини‑приложении. Человек видит свой прогресс — а это само по себе инструмент удержания.

---

Админ‑панель и наблюдаемость

Чтобы управлять живым продуктом, нужна была своя админка — не «pgAdmin поверх базы», а инструмент под задачи проекта: пользователи, воронка онбординга, платежи, рассылки, контекст диалогов, управление персоной, затраты на API. Собрана как SPA на нативном JS с Material Design 3, backend — FastAPI.

Здесь же «наблюдаемость по делу»: логирование 11 событий онбординга, статистика воронки, точки отсева и доля успешного AI-парсинга профиля. Видно не «сколько всего сообщений», а где именно люди спотыкаются.

---

Технические челленджи и решения

1. Стриминг вместо «крутилки». Ждать 8–10 секунд полного ответа — плохой UX. Ответы стримятся и обновляют одно и то же сообщение в Telegram в реальном времени. Пришлось аккуратно работать с лимитами Telegram на редактирование сообщений и с буферизацией по чанкам.

2. Безопасность выше логики диалога. Детектор кризиса стоит до генерации ответа. Ошибка здесь стоит дорого — поэтому это отдельный модуль с высшим приоритетом, а не «ещё один тег в промпте».

3. Стоимость модели под контролем. Каждый вызов трекается, лимит проверяется через Redis до обращения к модели. Результат — предсказуемые затраты и маржинальность 78% при доступной цене подписки.

4. Естественный онбординг вместо анкеты. Первая версия «убивала вайб»: стена текста после старта, кнопки «Соглашение» и «Справка», слэш‑команды как для программистов. Переписал по принципу «один экран — одна мысль — одно действие». AI-парсинг вытаскивает профиль прямо из свободного текста: человек пишет «Мне 34, живу в Москве, работаю маркетологом, люблю йогу» → система извлекает возраст, город, профессию, хобби и сохраняет. 11 пунктов профиля собираются за 4 сообщения, без ощущения анкеты.

5. Production-надёжность. Бот и API живут как systemd-сервисы: автоперезапуск при падении, watchdog, гарантия единственного экземпляра, лимиты памяти, логирование. Медиа пользователей — в облачном хранилище с политикой хранения.

graph LR
    subgraph Server[VPS · systemd]
        BOT[бот<br/>watchdog 60 c<br/>лимит 1 ГБ]
        API[API<br/>лимит 512 МБ]
        MON[монитор здоровья<br/>каждые 5 мин]
    end
    NGINX[nginx<br/>статика Mini App] --> API
    MON -. 3 попытки + рестарт .-> API
    BOT --> DB[(PostgreSQL)]
    API --> DB

---

Продукт и бизнес‑модель

Freemium с понятной воронкой:

flowchart LR
    A[Онбординг<br/>~3 мин] --> B[Trial<br/>3 дня Premium]
    B --> C[Free<br/>10 сообщений/день]
    C --> D[Premium<br/>подписка]
    D --> E[Реферал<br/>+7 дней обоим]
    E --> C

Онбординг собирает расширенный профиль, trial даёт почувствовать Premium, а реферальная программа возвращает людей в воронку. Итоговая юнит‑экономика: маржа 78%, LTV/CAC 13,7x, рост +35% в месяц, удержание D7 42%, NPS 68.

Как это выглядит вживую

Несколько экранов бота и мини‑приложения — приветствие Миры, диалог, анализ настроения, подписка и реферальная программа. Нажмите на любой, чтобы рассмотреть.

---

Что я вынес из проекта

• Один реальный диалог ценнее ста гипотез. Тот случай на четвёртый день дал больше для архитектуры, чем недели планирования. Продукт нужно щупать на живых людях.
• Персона важнее модели. Характер, границы и тон дают вовлечённость. 178 сообщений на пользователя говорят сами за себя.
• Память — это инженерия, а не длина контекста. Закинуть всю историю в большое окно недостаточно; ценность даёт структурированное извлечение фактов, попыток и триггеров — и осознанное забывание.
• Там, где речь о состоянии человека, безопасность — часть архитектуры, а не фича. Кризис‑протокол с высшим приоритетом закладывался с первого дня.
• Solo-разработка требует дисциплины. Слой репозиториев, строгая типизация, тесты и async-only ввод‑вывод — то, что позволило одному человеку тащить систему такого размера в production.

---

Стек одним списком. Backend: Python 3.10, python-telegram-bot v21, SQLAlchemy 2.0 (async), FastAPI, Pydantic. AI: Claude Sonnet 4.5, Whisper (STT), собственные детекторы (кризис, настроение, профиль, триггеры), архитектура «живой памяти». Данные: PostgreSQL, Redis, Cloud Storage, Alembic. Инфраструктура: Docker, systemd, nginx, VPS, health-мониторинг. Качество: pytest + coverage, mypy (strict), black, isort, CI.

---

Посмотреть вживую

Перейти на сайтmiradrug.ru Телеграм‑бот@MiraDrug_bot

Следующий шаг: хотите AI-продукт с характером — бота, который помнит пользователя и ведёт его сам, напишите мне в Telegram.