«Облако мыслей»: как построить память о пользователе, которая сводит людей и не сливает приватность

Коротко о главном (BLUF)

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

Про сам продукт — «Облако мыслей» в NeuralSpace — мы уже рассказывали: система собирает, что знает о тебе, и по обоюдному согласию сводит тех, у кого совпадают интересы («ищу 3D-моделлера» ↔ «делаю 3D»). Здесь — про инженерную сторону: как сделать так, чтобы полезная память о пользователе не превратилась в утечку. Это оказалось интереснее самой фичи.

Задача с двойным дном

Хочется двух вещей одновременно, и они противоречат друг другу:

1. Богатый профиль. Чтобы сводить людей, надо знать факты: чем занимается, что ищет, что предлагает.
2. Приватность по умолчанию. Никто не соглашался, что его переписка станет публичной. Утечка = потеря доверия и нарушение 152-ФЗ.

Наивная реализация («соберём всё и будем матчить») ломает пункт 2 мгновенно. Правильная архитектура строится вокруг fail-closed: по умолчанию закрыто, раскрытие — только по явному согласию, и это проверяется на уровне кода, а не «мы обещаем».

Слои

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

2. Категории под запретом. Системный запрос сбора исключает чувствительные категории по 152-ФЗ (здоровье, политические и религиозные взгляды и пр.) — они не попадают в облако, даже если всплыли в разговоре. Это не пост-фильтр, а правило на этапе извлечения.

3. Матчинг с двойным согласием. Два человека совпали по интересам — система не показывает контакты автоматически. Она предлагает знакомство обеим сторонам; контакт раскрывается, только когда оба согласились. Это защищает от сценария «мой запрос в чате всплыл у незнакомца вместе с моим телефоном».

4. Исключение для явных объявлений. Тонкий момент. Если человек сам, публично, в чате говорит «продаю услугу, кому надо — пишите @ник» — спрашивать согласие второй раз абсурдно, он уже его дал. Такой публично разрешённый контакт распознаётся отдельно и раскрывается сразу заинтересованному. Контакт при этом распознаётся широко (телеграм с @ и без, телефон в любом формате, ссылки), но условие раскрытия — именно явное публичное разрешение, а не просто наличие контакта в тексте.

Почему fail-closed важнее, чем кажется

Соблазн — сделать защиту флагом «показывать / не показывать» на уровне интерфейса. Это неверно: любой баг в UI-логике = утечка. Мы сделали иначе — факты, на которые нет согласия, физически не попадают в профиль на этапе его сборки. Нет согласия — тексты запросов и референсы в письмо и матчинг не попадают вовсе, а не «попадают, но мы их прячем». Разница фундаментальная: в первом случае забытая проверка = утечка, во втором — просто отсутствие данных.

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

Каналы раскрытия — разной строгости

• В чате, по запросу самого пользователя — обезличенные факты и уже публичные лиды доступны легче: человек сам спросил.
• Проактивная почта (система сама пишет «есть совпадение») — строже, только по подписке и двойному согласию.

Логика простая: чем менее пользователь ожидает раскрытия, тем выше планка согласия.

Итог

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

🇬🇧 English version

We've talked about the product before — Mind Cloud in NeuralSpace shows what the system knows about you and, with mutual consent, connects people whose interests match (“looking for a 3D modeler” ↔ “I do 3D”). This post is about the engineering: how to keep useful user memory from becoming a privacy leak. That turned out more interesting than the feature itself.

The double bind

1. A rich profile — to connect people you need facts: what they do, what they want, what they offer.
2. Privacy by default — nobody agreed to have their chat made public. A leak means lost trust, and under our data-protection law, it's illegal.

The naive build (“collect everything, then match”) breaks #2 instantly. The right architecture is built around fail-closed: closed by default, disclosure only on explicit consent, enforced in code — not “we promise.”

Layers

1. Fact collection. Two sources: structural facts (generation types, activity — de-identified) and extraction from chat. The second is the sensitive one, so it's gated by a separate chat-memory toggle per user. Off means no chat extraction at all. Crucially, that gate is not tied to any paid subscription — privacy must not be for sale.

2. Forbidden categories. The collection system prompt excludes sensitive categories (health, political and religious views, and so on) — they never enter the cloud even if they come up. Not a post-filter; a rule at extraction time.

3. Double opt-in matching. Two people match on interests — the system does not reveal contacts automatically. It offers an intro to both sides, and the contact is disclosed only when both agree. This protects against “my chat request surfaced to a stranger, along with my phone number.”

4. The explicit-listing exception. The subtle bit. If someone publicly says in chat “selling a service, DM @handle if interested,” asking consent a second time is absurd — they already gave it. So a publicly permitted contact is detected separately and revealed immediately to an interested party. Contacts are detected broadly (handles with or without @, phones in any format, links), but the disclosure condition is the explicit public permission, not merely a contact appearing in text.

Why fail-closed matters more than it looks

The tempting fix is a UI flag: “show / don't show.” That's wrong — any bug in UI logic becomes a leak. Instead, facts without consent physically never enter the profile at assembly time. No consent means prompt texts and references don't enter the email or the matching at all, rather than “enter but stay hidden.” The difference is fundamental: in the first case a forgotten check is a leak; in the second, it's just missing data.

The rule we'd give anyone building this: default closed; disclosure is a positive user action; put the check as close to the data source as possible, not near the screen.

Channels graded by strictness

• In chat, on the user's own request — de-identified facts and already-public leads are easier: they asked.
• Proactive email (“we found a match”) — stricter: subscription and double consent only.

The less a user expects disclosure, the higher the consent bar.

Takeaway

The hard part here isn't machine learning — it's data-flow discipline. If you build recommendations or matching on user data, we're curious where you put the consent check. See what the system knows about you in your privacy settings.

Часто задаваемые вопросы (FAQ)

Вопрос: Как получить лучший результат от нейросети?
Ответ: Используйте подробные промпты (описания) на английском языке, задавайте стиль и детали сцены.

Вопрос: Можно ли использовать эти материалы в коммерческих целях?
Ответ: Да, сгенерированный контент полностью принадлежит вам.