“Gedachtenwolk”: hoe je een herinnering aan de gebruiker opbouwt die mensen samenbrengt en de privacy niet verliest

Kort over het belangrijkste (BLUF)

Het onthouden van de gebruiker is een dubbele taak: mensen in contact brengen met hun gedachten is nuttig, maar één lek doet het vertrouwen in het product voorgoed de das om. We laten zien hoe de lagen van de ‘Cloud of Thoughts’ zijn gerangschikt, waarom fail-closed belangrijker is dan het lijkt, en welke openbaarmakingskanalen strenger zijn dan andere.

Over het product zelf - "Wolk van gedachten" in NeuralSpace — we hebben het u al verteld: het systeem verzamelt wat het over u weet en brengt, met wederzijds goedvinden, degenen samen die dezelfde interesses hebben (“Ik ben op zoek naar een 3D-modelleur” ↔ “Ik maak 3D”). Hier - ongeveer technische kant: hoe u kunt voorkomen dat nuttig gebruikersgeheugen lekt. Dit bleek interessanter dan de functie zelf.

Dubbel bodemprobleem

Ik wil twee dingen tegelijk, en ze spreken elkaar tegen:

1. Rijk profiel. Om mensen bij elkaar te brengen, moet je de feiten kennen: wat hij doet, waar hij naar op zoek is, wat hij biedt.
2. Standaard privacy. Niemand was het ermee eens dat zijn correspondentie openbaar zou worden. Lekkage = verlies van vertrouwen en schending van 152-FZ.

Een naïeve implementatie (“laten we alles verzamelen en een match starten”) doorbreekt punt 2 onmiddellijk. Er wordt goede architectuur omheen gebouwd mislukt gesloten: Standaard gesloten, alleen openbaar gemaakt met uitdrukkelijke toestemming en geverifieerd op codeniveau, niet een ‘we beloven’.

Lagen

1. Feiten verzamelen. Twee bronnen: structurele feiten (soorten generatie, activiteit - onpersoonlijk) en extractie uit chatcorrespondentie. De tweede is het meest gevoelig, dus deze is afgesloten aparte chatgeheugen-tuimelschakelaar bij de gebruiker. Uitgezet - extractie uit correspondentie vindt helemaal niet plaats. Belangrijk: deze poort Niet gebonden aan een abonnement op betaalde functies - privacy mag niet worden verkocht.

2. Categorieën zijn verboden. Systeemverzamelingsverzoek sluit uit gevoelige categorieën onder 152-FZ (gezondheid, politieke en religieuze opvattingen, enz.) - ze vallen niet in de cloud, ook al komen ze ter sprake in een gesprek. Dit is geen nafilter, maar een regel tijdens de extractiefase.

3. Dubbele toestemmingsmatch. Twee mensen hebben dezelfde interesses - systeem Niet toont automatisch contacten. Ze biedt een introductie aan beide partijen; het contact wordt alleen geopend wanneer beide overeengekomen. Dit beschermt tegen het scenario “mijn chatverzoek verscheen bij een vreemde samen met mijn telefoonnummer”.

4. Uitzondering voor expliciete verklaringen. Subtiel punt. Als iemand zelf in het openbaar in een chat zegt: "Ik verkoop een dienst, wie het ook nodig heeft, schrijf @nick" - een tweede keer toestemming vragen is absurd, hij heeft het al gegeven. Dergelijk openbaar toegestaan ​​contact wordt afzonderlijk erkend en onmiddellijk aan de belanghebbende bekendgemaakt. Het contact wordt algemeen herkend (telegram met en zonder @, telefoon in elk formaat, links), maar openbaarmakingsvoorwaarde - juist expliciete publieke toestemming, en niet alleen de aanwezigheid van contact in de tekst.

Waarom fail-closed belangrijker is dan het lijkt

De verleiding is om bescherming te bieden met een ‘show/don’t show’-vlag op interfaceniveau. Dit is niet waar: elke bug in de UI-logica = lek. Wij hebben het anders gedaan - feiten waarvoor geen toestemming bestaat, worden niet fysiek in het profiel opgenomen in het stadium van de montage ervan. Geen akkoord - teksten van verzoeken en referenties in de brief en matching helemaal niet slaan, en niet “ze komen daar, maar wij verbergen ze.” Het verschil is fundamenteel: in het eerste geval = een vergeten controle = een lek, in het tweede geval eenvoudigweg een gebrek aan gegevens.

De regel die we iedereen zouden geven die een systeem als dit bouwt, is: standaard - gesloten, openbaarmaking - positieve gebruikersactie, verificatie - zo dicht mogelijk bij de gegevensbron, niet bij het scherm.

Openbaarmakingskanalen - van verschillende ernst

• In de chat, op verzoek van de gebruiker zelf - onpersoonlijke feiten en reeds openbare leads zijn gemakkelijker toegankelijk: de persoon zelf vroeg het.
• Proactieve mail (het systeem zelf schrijft “er is een match”) - strenger, alleen bij abonnement en dubbele toestemming.

De logica is simpel: hoe minder de gebruiker openbaarmaking verwacht, hoe hoger de lat voor toestemming.

Kortom

Het moeilijkste hier is niet machine learning, maar datastroomdiscipline. Als u aanbevelingen doet of gebruikersgegevens matcht, is het interessant om te bespreken waar u de toestemmingscontrole plaatst. In de sectie kunt u zien wat het systeem over u weet privacy.

Veelgestelde vragen (FAQ)

Vraag: Hoe haal je het beste resultaat uit een neuraal netwerk?
Antwoord: Gebruik gedetailleerde aanwijzingen (beschrijvingen) in het Engels, stel de stijl en details van de scène in.

Vraag: Kunnen deze materialen gebruikt worden voor commerciële doeleinden?
Antwoord: Ja, de gegenereerde inhoud is geheel van jou.