« Nuage de pensées » : comment construire une mémoire de l'utilisateur qui rassemble les gens et ne perd pas son intimité

En bref sur l'essentiel (BLUF)

Se souvenir de l'utilisateur est une tâche à double sens : connecter les gens avec leurs pensées est utile, mais une seule fuite tue à jamais la confiance dans le produit. Nous montrons comment les couches du « nuage de pensées » sont organisées, pourquoi la fermeture en cas d'échec est plus importante qu'il n'y paraît et quels canaux de divulgation sont plus stricts que d'autres.

À propos du produit lui-même - "Nuage de pensées" dans NeuralSpace — on vous l'a déjà dit : le système collecte ce qu'il sait de vous et, d'un commun accord, rassemble ceux qui partagent les mêmes intérêts (« Je cherche un modeleur 3D » ↔ « Je fais de la 3D »). Ici - à propos côté ingénierie: Comment éviter que la mémoire utilisateur utile ne devienne une fuite. Cela s’est avéré plus intéressant que la fonctionnalité elle-même.

Problème de double fond

Je veux deux choses à la fois, et elles se contredisent :

1. Profil riche. Pour rassembler les gens, il faut connaître les faits : ce qu’il fait, ce qu’il recherche, ce qu’il propose.
2. Confidentialité par défaut. Personne n’était d’accord pour que sa correspondance devienne publique. Fuite = perte de confiance et violation du 152-FZ.

Une implémentation naïve (« rassemblons tout et commençons un match ») brise instantanément le point 2. Une bonne architecture se construit autour fermé par défaut : Fermé par défaut, divulgué uniquement par consentement explicite et vérifié au niveau du code, pas un « nous promettons ».

Calques

1. Rassembler des faits. Deux sources : faits structurels (types de génération, activité - impersonnelle) et extraction des correspondances de chat. La seconde est la plus sensible, elle est donc fermée interrupteur à bascule séparé pour la mémoire de discussion chez l'utilisateur. Désactivé - l'extraction de la correspondance ne se produit pas du tout. Important : ce portail Pas liée à un abonnement à des fonctionnalités payantes - la confidentialité ne doit pas être vendue.

2. Les catégories sont interdites. Demande de collecte du système exclut catégories sensibles sous 152-FZ (santé, opinions politiques et religieuses, etc.) - elles ne tombent pas dans le nuage, même si elles reviennent dans une conversation. Il ne s'agit pas d'un post-filtre, mais d'une règle lors de la phase d'extraction.

3. Correspondance à double consentement. Deux personnes ont les mêmes intérêts – système Pas affiche automatiquement les contacts. Elle propose une introduction aux deux parties; le contact s'ouvre seulement quand les deux convenu. Cela protège contre le scénario « ma demande de chat est apparue sur un inconnu avec mon numéro de téléphone ».

4. Exception pour les déclarations explicites. Point subtil. Si une personne elle-même, publiquement, dans un chat dit "Je vends un service, celui qui en a besoin, écris @nick" - demander son consentement une deuxième fois est absurde, il l'a déjà donné. Un tel contact publiquement autorisé est reconnu séparément et immédiatement communiqué à l'intéressé. Le contact est largement reconnu (télégramme avec et sans @, téléphone sous n'importe quel format, liens), mais condition de divulgation - une autorisation publique précisément explicite, et pas seulement la présence d'un contact dans le texte.

Pourquoi la fermeture en cas d'échec est plus importante qu'il n'y paraît

La tentation est d’assurer la protection avec un indicateur « afficher/ne pas afficher » au niveau de l’interface. C'est faux : tout bug dans la logique de l'interface utilisateur = fuite. Nous l'avons fait différemment - les faits pour lesquels il n’y a pas de consentement ne sont pas physiquement inclus dans le profil au stade de son assemblage. Pas d'accord - textes des demandes et références dans la lettre et correspondance ne frappe pas du tout, et non « ils y arrivent, mais nous les cachons ». La différence est fondamentale : dans le premier cas, un contrôle oublié = une fuite, dans le second - simplement un manque de données.

La règle que nous donnerions à quiconque construit un système comme celui-ci est la suivante : par défaut - fermé, divulgation - action positive de l'utilisateur, vérification - aussi près que possible de la source de données, pas de l'écran.

Canaux de divulgation – de gravité variable

• En chat, à la demande de l'utilisateur lui-même - les faits impersonnels et les pistes déjà publiques sont plus facilement accessibles : la personne elle-même a demandé.
• Courrier proactif (le système lui-même écrit « il y a une correspondance ») - plus strict, uniquement par abonnement et double consentement.

La logique est simple : moins l’utilisateur s’attend à une divulgation, plus la barre du consentement est élevée.

Conclusion

Le plus difficile ici n’est pas l’apprentissage automatique, mais discipline du flux de données. Si vous faites des recommandations ou faites des comparaisons sur les données des utilisateurs, il est intéressant de discuter de l'endroit où vous effectuez la vérification du consentement. Vous pouvez voir ce que le système sait de vous dans la section confidentialité.

Questions fréquemment posées (FAQ)

Question : Comment obtenir le meilleur résultat d’un réseau de neurones ?
Réponse : Utilisez des invites détaillées (descriptions) en anglais, définissez le style et les détails de la scène.

Question : Ces matériaux peuvent-ils être utilisés à des fins commerciales ?
Réponse : Oui, le contenu généré vous appartient entièrement.