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

Автор сознательно отказался от стандартного подхода с векторной базой и RAG. Переписка плохо делится на фрагменты: один факт часто собирается из десятка реплик в разных чатах, а нарезка по 500 токенов разрывает историю. Человек в одном чате может быть «Саша», в другом — «Александр», в третьем — под непонятным ником, и поиск возвращает пять почти одинаковых фрагментов вместо одного знания. С актуальностью ещё хуже: в марте договорились об одном, в июне передумали, а в индексе лежат оба варианта с одинаковым весом. Вместо фрагментов автору нужны были карточки: люди, проекты, темы, факты, задачи и связи между ними, с обязательной привязкой каждого факта к исходному сообщению.

Техническая схема выглядит так. Telethon забирает сообщения по выбранным источникам — можно подключить как отдельный чат, так и целую папку. Каждое сырое сообщение получает запись в таблице состояния (ожидает, в процессе, обработано, ошибка). Планировщик в следующий прогон берёт только то, чего нет в этой таблице, чтобы не платить дважды за обработку одного и того же. Сообщения группируются по ключу «источник:чат», сортируются по дате и режутся на куски по 100 штук. Внутри куска только один чат, чтобы модель видела связный диалог. Из куска собирается транскрипт вида «[дата] Отправитель: текст» с обрезкой по 30 тысячам символов. На каждый кусок идёт один вызов DeepSeek, который должен вернуть строгий JSON с полями daily_note, topics, people, projects и links. В промпт подкладывается список уже известных сущностей пользователя, чтобы один и тот же проект не назывался каждый раз по-новому. Когда все куски задания готовы, запускается merge: сущности ищутся по ключу (пользователь, тип, каноническое имя), повторные упоминания не плодят дубликаты, а обновляют summary. Факты и задачи привязываются к сущностям, связи уходят в отдельную таблицу, и каждая запись ссылается на id исходных сообщений. Последний шаг — выгрузка в markdown-файлы Daily, Knowledge, People, Projects. Ссылки между заметками оформлены как [[wiki-links]], так что vault открывается в Obsidian. Экспорт идемпотентный: перед записью блока считается его sha256, и если такой блок уже выгружался, он пропускается.

Сейчас в базе несколько пользователей, на одного в среднем приходится по 7 источников (3 папки и 4 отдельных чата). Даже за пару месяцев теста они сгенерировали десятки тысяч сообщений в 34 чатах. Из этого получилось 281 сущность: 147 тем, 108 человек, 26 проектов. Плюс 1815 фактов, 184 задачи и 133 дневные заметки. По токенам вышло всего 10,05 млн: 3028 тысяч на входе и 7027 тысяч на выходе. Ответы дороже входа более чем вдвое, потому что JSON со схемой занимает много места. По тарифам DeepSeek это меньше десяти долларов на все сообщения. Одно задание (обработка всех новых сообщений одного пользователя за прогон) идёт в среднем 205 секунд, самое долгое заняло почти 12 минут. Поскольку всё работает ночью, такие задержки приемлемы.

В процессе эксплуатации выявились и проблемы. Часть заданий отменилась на середине, в базе остался текст «cancelled - model changed to v4-flash». Автор менял модель на лету, а задание в этот момент выполнялось, поэтому часть чанков посчитана одной моделью, часть другой. Данные не сломались, но такого лучше избегать. Агент иногда отвечал «ничего не найдено», хотя файлы были на месте. Оказалось, у OpenClaw есть баг: инструмент memory_search возвращает ложные нулевые результаты, пока внутренний поисковый движок работает нормально. Причина — в закэшированном memory manager. Помогает принудительная переиндексация командой openclaw memory index --force. После этого автор прибил версию образа гвоздями и запретил себе обновлять её на «latest»: мажорные версии меняют и схему конфигов, и схему внутренней базы. Сессии Telegram тоже живут не вечно: Telethon-сессия может отвалиться, и тогда пользователю нужно заново авторизоваться. Сделан отдельный флоу с кодом из Telegram и сообщением в бота «переподключите аккаунт». В дашборде при повторной авторизации список чатов пересобирается, иначе остаются мёртвые ссылки на чаты, к которым уже нет доступа. Отдельная головная боль — недоступность Telegram из России, что требует дополнительных обходных решений.

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

Сравнивая с альтернативами, можно отметить, что стандартные RAG-системы на векторных базах требуют меньше усилий на старте, но плохо работают с длинными диалогами и часто выдают нерелевантные фрагменты. Подход автора с извлечением сущностей и фактов напоминает граф знаний, но реализован на реляционной базе с выгрузкой в markdown. Это даёт прозрачность и возможность ручной правки, однако требует тщательной проработки промптов и логики слияния. Среди конкурентов можно вспомнить Notion AI, который тоже умеет искать по заметкам, но не строит автоматически связи между людьми и проектами из переписки. Сервисы вроде Mem.ai или Rewind пытаются решать похожие задачи, но они ориентированы на западный рынок и не поддерживают Telegram так глубоко. Российские разработки в этой нише пока единичны. В дальнейшем автор планирует развивать проект, но открытые вопросы остаются. Насколько хорошо система будет масштабироваться на сотни пользователей? Как обеспечить приватность и безопасность переписок при обработке через сторонние API? Будет ли поддержка других мессенджеров, кроме Telegram? Пока сервис работает в режиме эксперимента, и его создатель не раскрывает сроков возможного релиза. Тем не менее, кейс показывает, что даже без больших бюджетов и сложной инфраструктуры можно построить полезный инструмент второй памяти, который экономит время и помогает не терять важные договорённости. Возможно, вскоре мы увидим больше подобных решений, ориентированных на русскоязычных пользователей.