»Ok, help me understand. Why is #Google buying #Nest seen as bad for privacy/data control/etc.?
I don’t get it, the data Google already has about individuals is better. Is it because Google is seen tied to objects that just exist around us (and are not our direct extensions such as smartphones)? Is it the usual underspecified feeling of „creepyness“?«
I went for the creepiness option. This is my reply, which I recycle here:
Maybe it’s because we’re mentally still living in the pre-cloud and in the database paradigm. Google represents like no other organization – maybe except the NSA – a technological progress that’s hard to grasp. We have no appropriate conception of information risk and risk management for a world in which a single organization can process various data about the wealthier half of the planet’s population and draw inferences from these data. Google represents this development, working at its forefront and pushing the limits.
We have no intuition what may, could, or will happen to us in the long run due to this new technology, and we have no idea ho to manage the risks (or non-risks) that we don’t understand. In a way we are in a similar situation as those who drafted our first data protection laws back in the seventies and early eighties: having to manage not only the uncertainty inherent in any risk consideration, but rather an uncertainty about the uncertainty. Back then, the tentative conceptual and legal solution was to ban all storing and processing of personally identifiable data and grant permission only on a case-by-case basis.
Progress has turned this approach into a delusion, but we lack a convincing replacement. We don’t know what’s risky and what isn’t; most of us don’t even understand what creates value in an Internet-scale data processing business. We project all our uncertainties on the pioneers.
»The desire for security and the feeling of insecurity are the same thing. To hold your breath is to lose your breath. A society based on the quest for security is nothing but a breath-retention contest in which everyone is as taut as a drum and as purple as a beet.«
Die obere Anzeige betitelt ihren Link einfach mit Zum Download. Genau danach habe ich gesucht, nach einem Download, diese Anzeige wird an dieser Stelle sicher hervorragend funktionieren, gerade weil nicht aus ihr hervorgeht, was sich eigentlich dahinter verbirgt. Für so eine Optimierung braucht man gewissenloses, nüchtern-rationales Personal, zum Beispiel einen Computer, dessen einzige Mission in der Klickratenoptimierung besteht.
Über mich weiß Google offensichtlich, dass ich Deutsch spreche. Das erzählt mein Browser allerdings jeder Website und ich mache auch sonst kein Geheimnis daraus.
Über die bisherigen Folgen dieser Serie haben wir ein Modell von Google als lernender Maschine etabliert. Vermutlich ist dieses Modell nicht die reine Lehre hinter Googles Werbediensten, da Google vor einigen Jahren Doubleclick und damit fremde Technologie gekauft hat. Gleichwohl lohnt es sich, anhand unseres Modells über optimierte (volkstümlich: personalisierte) Werbung nachzudenken. Weit hergeholt wird es nicht sein; dass Google Techniken wie die skizzierten zur Optimierung von Suchergebnissen und Empfehlungen einsetzt, können wir mit unserem Vorwissen aus den Changelogs herauslesen. Technisch macht es keinen großen Unterschied, ob wir das beste Suchergebnis, die beste Empfehlung zu irgend etwas oder die beste Werbung für einen Anzeigekontext suchen. Aber der Reihe nach.
Personalisierung ist Optimierung
Werbung ist ein Optimierungsproblem. Ziel des Werbers ist, genau dort aufzutreten, wo seine Werbung wirkt, und auch nur dafür zu bezahlen. Klassisch, ob offline oder online, tut man dies, indem man Zielgruppen klassifiziert und seine Werbung bzw. sein Produkt einerseits und die verfügbaren Medien andererseits in dieses Modell abbildet. Erreicht ein Medium möglichst genau die anzusprechende Zielgruppe, schaltet man seine Werbung dort. So kommt die Telefonsexwerbung ins Nachtprogramm von Privatsendern, die Werbung für Pay-TV-Sportsender in die Sportzeitschrift und das ThinkGeek-Banner auf Slashdot. Erscheinen die Streuverluste zu hoch, versucht man die Zielgruppendefinition zu verfeinern. Dieses Vorgehen entspricht dem regelgestützten Ansatz der klassischen KI.
Gemäß der Google-Philosphie würde man hingegen aus allen verfügbaren Daten über die Werbung, den Anzeigekontext und, soweit verfügbar, den Nutzer vor dem Bildschirm alle denkbaren Merkmale extrahieren. In diesem Datenraum würde man einen lernenden Klassifikator auf die Frage ansetzen, welche Cluster die Klickrate als Hilfsmetrik oder besser noch die werbebezogenen Umsätze des Kunden maximieren. Man würde also das tun, was ich in Folge 4 beschrieben habe, nur mit einem Pool von Anzeigen anstelle von Tanksäulen und Abrufereignissen anstelle von Autos mit Fahrern. Seinen Kunden würde man ein Interface zur Verfügung stellen, mit dem sie neue Zapfsäulen aufstellen und bezahlen können. Selbst müsste man nur noch seine Einnahmen kassieren und verbuchen und alte Zapfsäulen wegräumen. Alles andere liefe komplett automatisch ab.
Die tatsächlichen Regeln, nach denen die Einblendung erfolgt, wären wieder Sache des Klassifikators und von Fall zu Fall verschieden. Zur Entscheidung könnte der Inhalt der Anzeige ebenso beitragen wie der Kontext der Einblendung oder Informationen über den Nutzer. Vielleicht sind Anzeigen mit bestimmten Merkmalen besonders erfolgreich bei europäischen Nutzern des Browsers Firefox ohne Flash Player zwischen 19:23 Uhr und 20:42 Uhr an Samstagen, sofern diese Nutzer nicht in ihren Google-Account eingeloggt sind, die Werbeeinblendung auf einer bestimmten Website erfolgt und der Nutzer diese Anzeige zuvor höchstens zweimal gesehen hat. Eine andere Anzeige könnte bei Nutzern aus einem bestimmten Universitätsnetz gut ankommen, unabhängig vom verwendeten Browser und der Uhrzeit, eine weitere in einem bestimmten Anzeiogekontext gut funktionieren. Dem lernenden Klassifikator ist egal, ob solche Regeln für uns einen Sinn ergeben. Er optimiert stur auf die Daten, die man ihm zeigt.
Textanzeigen enthalten dabei genau jene Art von Merkmalen, mit denen Google ohnehin bereits gut umgehen kann. Für Werbebanner wird man etwas länger nachdenken müssen, welche Merkmale nützlich sind. Wer weiß, vielleicht hat ja die Blinkfrequenz einen Einfluss auf die Klickrate, oder Metadaten aus der klassichen Zielgruppendefinition erweisen sich als nützlich. Grundsätzlich funktioniert das Prinzip auch dann, wenn wir die verschiedenen Anzeigen lediglich unterscheiden können und sonst keine Einzelheiten kennen. Ein Klassifikator hätte dann kein Ähnlichkeitsmaß für Anzeigen zur Verfügung, könnte aber immer noch lernen, unter welchen Begleitumständen Anzeige Nummer 703744 am besten funktioniert.
Was führt zum Klick?
Alltagsbeobachtungen sind mit diesem Erklärungsmodell kompatibel. Nehmen wir zum Beispiel tortoisesvn.net. TortoiseSVN ist ein SVN-Client für den Windows-Explorer; die Website besuchen vermutlich viele Leute, die diesen Client erstmals oder als Update herunterladen möchten. Google blendet dazu Werbung für andere SVN-Clients ein. Was’n Quatsch?! Gar kein Quatsch, sondern folgerichtig.
Wer sich die Seite durch seine Usability-Brille anschaut, wird schnell bemerken, dass ihr Design einige Schwächen hat. Diese Schwächen führen dazu, dass der Nutzer von der Downloadfunktion ab- und auf die Werbung hingelenkt wird. Die echten Download-Buttons sind die grünen Kästen unten. Die wirken in ihrem Format und in ihrer knalligen, vom Rest der Seite abweichenden Farbe optisch wie ein typisches Werbebanner. Das Web hat uns über Jahre darauf trainiert, typische Werbebanner mental auszublenden und zu ignorieren. Hinzu kommt, dass über den Google-AdSense-Anzeigen der Titel Downloads steht und dann außer den Anzeigen kein Inhalt folgt, und die dass Anzeigen farblich der Seitengestaltung angepasst sind. Ist unter den Anzeigen nun noch eine, die einen SVN-Client anbietet, liegt ein versehentlicher Klick auf die Anzeige nahe – alles wirkt auf den Nutzer so, als könne er damit sein Ziel erreichen.
Nach einigen zufälligen Einblendungen, die zu Klicks führen, lernt das auch ein Klassifikator, der Klickraten optimiert. Stehen ihm die nötigen Parameter zur Verfügung, wird er fortan in diesem Kontext bevorzugt Werbung für SVN-Clients anzeigen, falls er welche im Pool hat. Über den einzelnen Nutzer muss er dazu nichts wissen, er lernt nur etwas über eine spezifische Auswirkung allgemeiner Psychologie in einem spezifischen Kontext. Auf ähnliche Weise dürfte SEO-Werbung in einen SEO-Artikel gelangen:
Persönliche Informationen über den Betrachter sind für diese Einblendungen nicht erforderlich – sie können jedoch jederzeit in die Entscheidung einfließen, wenn sie verfügbar und relevant sind. Ob und wo das der Fall ist, erfährt Google nach unserem Modell aber nicht aus den Daten, die wir uns als unser Nutzerprofil vorstellen, sondern aus unseren Werbeklicks. Wer nie Werbung anklickt, schafft keine Möglichkeit zur Personalisierung; Google muss sich dann auf eine optimierte und automatisierte Anwendung der herkömmlichen Targeting-Praktiken beschränken. Zwar werden die Eingabedaten in den Klassifikator genauer, je mehr Google vorher über mich weiß. Google kann aber nicht herausfinden, ob mich diese Details im Hinblick auf das Klassifikationsziel von anderen Teilen der Population unterscheiden. Mit jedem Nichtklick übermittle ich dem Klassifikator nur die Information: »Sorry, das war nicht die richtige Lösung.« Ich bekomme meine Werbung dann gemäß der Populationsstatistik so wie diejenigen die in denselben Clustern landen.
So füttert man Datenkraken
Klicke ich dagegen regelmäßig Werbung an, liefere ich nach und nach ein Modell dafür, wie der Werbeerfolg von meiner Person abhängt. Auch wenn es anders wirkt, erfährt Google dabei immer noch wenig über mich. Google kann dann vorhersagen, wie meine Anwesenheit im Verglich zu anderen Nutzern oder zur Populationsstatistik das Relevanzmodell für Werbeeinblendungen in einem bestimmten Kontext modifiziert. Wenn Google sich anstrengt, gibt der Klassifikator vielleicht auch noch eine – für Googles Zwecke bedeutungslose und in der Begriffswelt des Klassifikators ausgedrückte – Erklärung seiner Entscheidung her. Um systematisch solche Erklärungen über mich zu erheben, müsste Google aber schon wieder zusätzliche Daten neben der Konfiguration des Klassifikators erfassen und speichern.
Zieloptimierte Werbung a la Google funktioniert also wahrscheinlich nicht so, wie es die naiven Modelle aus Folge 2 suggerieren. Wenn mein Verständnis richtig ist, gilt es gleichermaßen auch für andere personalisierte Funktionen und nicht nur für die Werbung. Im letzten Teil der Serie betrachten wir die Auswirkungen solcher Technologien auf den Datenschutz.
Die vorige Folge dieser Artikelserie behandelte die Frage, wie Maschinen lernen können. Diese Technik ist für Google ein zentrales und dienstübergreifendes Paradigma (freies PDF). Im Vorbeigehen bekommen wir damit eine Erklärung, warum die Metapher von Google+ als Facebook-Konkurrenz nicht funktioniert (vgl. Teil 1). Facebook (der Dienst) ist für Facebook (die Firma) der Kern des Geschäftsmodells. Für Google dagegen ist maschinelles Lernen aus allen Daten dieser Welt der Kern des Geschäftsmodells – und Google+ vor allem eine weitere Quelle interessanter Daten. Wer interagiert wie mit wem? Welche Inhalte verbreiten sich in welchen Kreisen? Wie reagieren Nutzer auf personalisierte Suchergebnisse? Welche Transformationen durchläuft ein Gerücht? Welche Merkmale unterscheiden ein Mem von einem Shitstorm? Alleine die Liste der Fragen, zu denen man mit Googles Philosophie der Datenverarbeitung in Google+ nach Antworten suchen könnte, scheint endlos. Mit Facebook hat Google+ deshalb nur einige oberflächliche Funktionen gemeinsam, es dient aber – mutmaßlich – einem ganz anderen Zweck.
Künstliche Intelligenz, diesmal richtig
Doch funktioniert das überhaupt? Ist die KI nicht tot? Das ist sie, aber Google macht gerade keine klassische KI. Anfangs versuchte man in der KI, alle wesentlichen Aspekte eines Problems in nachvollziehbare Regeln zu fassen. Man versuchte also, Gehirne sich selbst beschreiben zu lassen. Das war ungefähr so schlau wie der Versuch, eine Turing-Maschine Aussagen über Turing-Maschinen machen zu lassen, aber irgendwo musste man ja anfangen und das Internet als reichhaltige Datenquelle gab es auch noch nicht.
Letztlich geht es auch im Google-Ansatz um Regeln, aber formuliert werden sie nun unter Verwendung aller verfügbaren Daten und ohne die Notwendigkeit, dass ein Mensch diese Regeln nachvollziehen kann. Dass dabei bessere Regeln herauskommen können als aus menschlichen Gehirnen, gerade wenn das Problem kompliziert ist, zeigt ein Beispiel aus der IT-Sicherheit.
Bozorgi et al. beschäftigen sich in ihrem Paper Beyond Heuristics: Learning to Classify Vulnerabilities and Predict Exploits (freies PDF) mit der Vorhersage der Exploit-Wahrscheinlichkeit aus Verweundbarkeitsmeldungen. Gefundene Verwundbarkeiten in Software dokumentiert die Security-Community in Datenbanken, zum Beispiel der CVE oder der OSVDB. Ein Bewertungsschema für Verwundbarkeiten ist der CVSS-Score, ein Wert zwischen 0 und 10, der die Schwere des Problems angibt. 10 ist ganz schlimm, 0 völlig harmlos. Dieser Score wird auf eine nachvollziehbare und sinnvoll erscheinende Weise aus einer Reihe von Parametern gebildet. Für eine gegebene Verwundbarkeit in einer Software oder in einem System kann man sich den Score aus einigen Einschätzungen zusammenklicken und das Ergebnis stimmt meistens mit der Intuition des Fachmanns überein.
Computer schlägt Experten
Man sollte meinen, dass dieser Wert einen Anhaltspunkt liefert, ob ein Security-Bug nach seiner Entdeckung auch für Angriffe ausgenutzt wird – die mit dem Score 10 oft, die mit dem Score 0 nie. Bozorgi et al. zeigen jedoch, dass der CVSS-Score darüber wenig voraussagt, und stellen dem ihm einen angelernte Klassifikatoren gegenüber. Diese Klassifikatoren benutzt die gesamte Verwundbarkeitsdokumentation und liefert weit bessere Vorhersagen darüber, ob und wie schnell eine Verwundbarkeit ausgenutzt wird oder nicht.
Der verwendete Merkmalsraum hat 93.578 Dimensionen, die meisten abgeleitet aus Textfeldern wie den Namen der betroffenen Produkte oder den Freitextbeschreibungen des jeweiligen Sicherheitsproblems. Viele Dimensionen sind binär und geben einfach an, ob bestimmte Worte, zum Beispiel Buffer, in bestimmten Teilen eines Berichts vorkommen. Klassifikator lernt Cluster für ausgenutzte sowie für nicht ausgenutzte Verwundbarkeiten. Nebenbei liefert dieser Klassifikator noch einen Score, der sich daraus ergibt, wie weit eine Verwundbarkeitsmeldung nach der Merkmalsextraktion von der Clustergrenze entfernt liegt. Was tief im Cluster liegt, ist den anderen Punkten dort sehr ähnlich; was nahe der Grenze liegt, könnte nach kleinen Änderungen auch auf der anderen Seite, im anderen Cluster landen.
Das wirkt alles ein wenig wie Zauberei. Im Grunde genommen tut Google aber nichts anderes als unser Gehirn, nur ohne den Filter unserer Sinnesorgane, ohne Abgleich mit Lehrbuchwissen und mit viel mehr Daten und Aspekten dieser Daten als uns normalerweise bewusst werden. Google lernt Sprachen – oder Expertenintuition – wie wir, nur schneller und ohne den Umweg über Übungen und explizite Regeln direkt aus Beispielen und Feedback. Und wir sind die Lehrer.
Im nächsten Artikel werden wir uns damit beschäftigen, wie man mit lernenden Maschinen Werbeeinblendungen optimiert.
In der dritten Folge der Artikelserie haben wir betrachtet, dass Google aus Crowdsourcing und Statistik nützliche Funktionen und Dienste baut und dabei aus dem Netz und von seinen Nutzern lernt. Wie funktioniert dieses Lernen?
Eine globale Tankstelle
Stell Dir vor, wir wären die Tankstelle der Welt. Wir verkaufen jede Sorte Treibstoff, die jemals irgendwo entwickelt, benannt und angeboten wurde, jeweils an einer eigenen Zapfsäule. Bei uns tanken deutsche Autofahrer Diesel, Super und Super Plus, Spanier 95 sin plomo und gasóleo, Japaner Hai-oku und Keiyu, Ossis in alten Trabis ihr Zweitaktgemisch VK 88 1:33 und afghanische Taliban brennbare Flüssigkeit aus Fässern und Flaschen.
Unsere Tankstelle ist riesig und unübersichtlich. Wie schicken wir jeden Fahrer mit seinem jeweiligen Fahrzeug an die richtige Säule? Wir könnten unsere Kunden nach ihren Wünschen fragen, aber dazu müssten wir all ihre Sprachen sprechen. Manche Kunden wüssten auch gar nicht, was sie tanken wollen, weil sie gerade in einem geliehenen Fahrzeug sitzen oder weil sie vergesslich sind oder weil ihre robuste russische Technik alles schluckt, was flüssig ist und brennt.
Unsere Kunden hätten zudem unterschiedliche Präferenzen, die teils mit ihren Fahrzeugen zusammenhängen, teils aber auch nicht. Während Mutti ihren Kleinwagen immer genau so betanken möchte, wie es ihr der nette Mann in der Werkstatt schon dreimal aus gegebenem Anlass erklärt hat, ist das Verhalten von Top-Verkäufer Johannes E. komplizierter. Gewohnheitsmäßig kippt er Super++ in seinen Audi, geht eh‘ auf Spesenrechnung und man gönnt sich ja sonst nichts. Ist er aber spät dran und ein Kunde wartet, nimmt er die erstbeste freie Säule, an der er sein Auto nicht kaputtmacht. Dann ist 95 sin plomo eine Alternative zur Schlange an der Super++-Säule, das kennt er aus seinem Urlaub auf Mallorca. Wenn Du mit Johannes E. redest, wirst Du davon allerdings nichts erfahren, weil ihm das selbst nicht so bewusst ist. Seine Bedürfnisse zeigen sich erst, wenn Du sein Verhalten beobachtest. Seine Verhaltensmuster können sich übrigens jederzeit ändern, zum Beispiel weil Johannes E. die Firma und damit den Firmenwagen gewechselt hat. Plötzlich sitzt Johannes E. in einem Mercedes und ein anderer in seinem Audi.
Eine Datenbank hilft uns nicht
Eine klassische Datenbank hilft uns in dieser Situation wenig. Führen wir sie über Fahrzeuge oder Fahrezugtypen, verlieren wir die Fahrerpräferenzen; führen wir sie über Fahrer, bekommen wir deren Wechsel vom Diesel zum Erdgas nicht mit. Bilden wir Paare von Auto und Fahrer, haben wir lauter Spezialfälle in der Datenbank und scheitern jedesmal, wenn eine unbekannte Paarung vorfährt, etwa weil Johannes E. eine Panne hatte und heute einen Mietwagen betankt. Was wir stattdessen haben wollen, ist ein Klassifikator, der fast immer die richtige Entscheidung trifft und dabei vorhandene Informationen generalisiert. Außerdem möchten wir, dass sich unser Klassifikator anpasst, wenn sich die Welt verändert. Wir möchten ihm nicht jede Woche die neuesten Gerüchte aus der Auto BILD und deren Auswirkungen auf seine Tätigkeit einprogrammieren, das soll er schön selbst lernen.
Merkmalsextraktion
Solch einen Klassifikator können wir bauen, und wir können ihn lernfähig machen. Dazu überlegen wir uns zunächst, welche beobachtbaren Merkmale ein Auto nebst Fahrer hat: Farbe, Kennzeichen, Abmessungen, Motor- und Fahrgeräusche, Felgen- und Reifentyp, Anhängerkupplung, Dachgepäckträger, Sauberkeit, Anzahl der Türen, Spoiler, Spracheinstellung des Navigationssystems, eingestellter Radiosender; beim Fahrer Hautfarbe, Körpergröße, Haarschnitt, Gesichtsbehaarung, Kleidung, Gesichtsausdruck und so weiter. Wir sammeln also erst mal alle Merkmale ein, die wir messen können. Welche dieser Daten wir am Ende wirklich brauchen, wissen wir noch nicht genau, voraussichtlich von allen ein bisschen.
Jedes messbare Merkmal liefert uns eine Dimension in einem vieldimensionalen Raum. Fährt ein Auto an unserer Tankstelle vor, können wir es in allen Dimensionen messen und danach als Punkt in diesem Raum darstellen. Kleine Abweichungen, zum Beispiel durch den Wechsel von Winter- zu Sommereifen, führen zu kleinen Verschiebungen im Raum. Große Unterschiede, etwa zwischen Muttis Kleinwagen und Bennos Umzugslaster mit ihren jeweiligen Fahrern, führen zu großen Abständen.
Merkmalsraum in den Dimensionen Farbe und Länge mit Datenpunkten für einige Fahrzeuge. In Wirklichkeit würde man die Farbe als Hue/Saturation/Value darstellen und zur Länge noch die Breite und die Höhe nehmen. Das wären bereits sechs Dimensionen und immer noch ein vereinfachtes Modell.
Unser Klassifikator soll uns zu jeder Eingabe – einem Punkt im Raum, der unsere Messwerte zu einem Fahrzeug repräsentiert – eine oder mehrere wahrscheinlich passende Zapfsäulen ausgeben.
Feedback
Wenn unsere Kunden mitdenken und ohne Einweisung oder nach einer falschen Empfehlung selbständig eine für sie richtige Zapfsäule aufsuchen, können wir ihr Verhalten beobachten und daraus lernen. Jedesmal wenn jemand bei uns tankt, bekommen wir ein Datensample, einen Punkt im Raum und die für diesen Punkt richtige Entscheidung. Diese Samples sammeln wir sortiert nach richtigen Entscheidungen. Diese Sammlung könnten wir uns noch als Datenbank vorstellen, in der für jede Zapfsäule sämtliche Merkmale der dort beim Tanken gesehenen Auto-Fahrer-Paare hinterlegt sind. Das sind aber nur Rohdaten und wir werden gleich sehen, dass wir sie gar nicht auf Vorrat in einer Datenbank speichern müssen.
Automatische Verallgemeinerung
Unser Klassifikator soll diese Rohdaten generalisieren können, das heißt auch für solche Datenpunkte gute Entscheidungen treffen, für die bisher keine Beobachtungen vorliegen. Repräsentiert unser Datenraum alle oder die meisten für die Klassifikation relevanten Merkmale, so bilden die Rohdaten zu jeder möglichen Entscheidung einen Cluster: sie liegen näher beieinander als sie zu den Datenpunkten anderer Cluster liegen. In den Randbereichen kann es zu Überschneidungen kommen. Das liegt entweder an verrauschten Daten aufgrund von Messfehlern, oder an fehlenden Merkmalen. Beispielsweise könnten uns einige Parameter fehlen, die das Verhalten unseres Tankchaoten Johannes E. erklären würden, weil wir seinen Terminkalender nicht kennen.
Die maßgebliche Nachbarschaft zwichen den Datenpunkten eines Clusters besteht dabei oft nur in ausgewählten Merkmalsdimensionen, da nicht alle Merkmale gleichermaßen relevant sind. Welche Dimensionen das sind, kann sich von Cluster zu Cluster unterscheiden. Wir könnten an unserer Tankstelle zum Beispiel beobachten, dass rote deutsche Sportwagen fast immer Super tanken, während Lkw sowie silbergraue und schwarze Mittelklassewagen Diesel bevorzugen. Dieser Cluster ließe sich mit den Merkmalen Farbe und Größe recht genau beschreiben. Gleichzeitig könnten wir beobachten, dass Japaner unabhängig von Autotyp und Farbe stets die Säule Hai-oku bevorzugen, weil es ihnen als unhöflich gilt, öffentlich billigen Diesel zu tanken. Daraus ergibt sich wiederum für die anderen Cluster, dass dort das Merkmal Nationalität eine Rolle spielt, und sei es nur die, Japaner aus dem Cluster auszuschließen.
Repräsentanten für Cluster
Damit unser Klassifikator gut funktioniert, benötigt er Beschreibungen der einzelnen Cluster, ihrer Clustergrenzen und ggf. der Überschneidungen mehrerer Cluster. Um einen Datenpunkt zu klassifizieren, also eine Entscheidung zu treffen, müssen wir ihn dem passendsten Cluster zuordnen. Erweist sich eine Klassifikation als falsch, so wollen wir außerdem die betroffenen Clusterbeschreibungen anpassen, ohne uns jedoch von einzelnen Ausreißern unsere Statistik kaputtmachen zu lassen. Anstelle der Rohdaten im Datenbankformat verwendet man dafür Repräsentanten: für jeden Cluster bestimmt man einen Satz von Punkten, der diesen Cluster gut repräsentiert. Diese Repräsentanten liegen irgendwo zwischen den Rohdatenpunkten; ihre Anzahl ist in der Regel geringer.
Für das Beispiel von eben bekämen wir als Repräsentanten des Clusters zur Zapfsäule Hai-Oku gemittelte Erkennungsmerkmale japanischer Fahrer, für Super die gemittelten Merkmale von Sportwagen mit Fahrern, in deren Land Sportwagen Super tanken, und für Diesel gemittelte Merkmale von Lastern sowie von langweilig kolorierten Mittelklassewagen. Die Cluster können komplizierte Formen haben und müssen nicht zusammenhängen, deswegen mehrere Repräsentanten.
Repräsentanten der Klassen Diesel und Super im vereinfachten Merkmalsraum. Datenpunkte – durch Kreuze dargestellt – lassen sich anhand ihrer Entfernung zu den Repräsentanten einer Klasse zuordnen. Ein roter Kleinbus mit Anhänger würde an der Diesel-Säule landen.
Um einen neuen Datenpunkt zu klassifizieren, suchen wir uns den oder die n nächstgelegenen Repräsentanten zu diesem Punkt und bestimmt daraus die Wahrscheinlichkeit der Clusterzugehörigkeit. Wir schicken das Fahrzeug an die Zapfsäule, deren Cluster die höchste Wahrscheinlichkeit hat. Klasse (d.h. Zapfsäule) und Wahrscheinlichkeit die Ausgaben des Klassifikators. Erweist sich die Entscheidung als falsch, analyisieren wir den Fehler und berechnen Korrekturen für die betroffenen Repräsentanten. Diese Korrekturen halten wir klein, Repräsentanten werden nur ein Stückchen in die richtige Richtung verschoben. Das macht unseren Klassifikator robust gegen einzelne statistische Ausreißer. Erst wenn systematische Fehler auftreten, akkumulieren sich viele gleichartige Korrekturen zu einer nennenswerten Verschiebung der Repräsentanten und Clustergrenzen. Beginnen können wir mit zufällig verteilten Repräsentanten; unser Klassifikator wird dann anfangs viele Fehler machen und schnell lernen.
Die Nutzerdaten werfen wir weg
Die ursprünglich erfassten Rohdaten, die gemessenen Merkmalswerte, können wir nach Verwendung wegwerfen. Dass Mutti beim Betanken ihres Kleinwagens immer eine Alditüte mit Einkäufen auf dem Beifahrersitz liegen hat, geht vielleicht als Merkmal in die Klassifikation ein – steht am Ende aber in keiner Datenbank. Wir brauchen diese Information nicht, unseren Klassifikator interessiert nur, ob der das Merkmal Alditüte berücksichten muss und falls ja, was es über die Clusterzugehörigkeit aussagt.
Wer genauer wissen möchte, wie statistische Inferenz und maschinelles Lernen funktioniert, und sich von Formeln nicht abschrecken lässt, findet im Buch Information Theory, Inference, and Learning Algorithms von David MacKay eine hervorragende und umfangreiche Einführung; das komplette Buch mit seinen 600 Seiten gibt es online als PDF-Datei. [Bevor Ihr jetzt anfangt zu drucken: die Amazon-Lieferung dauert auch nicht viel länger.]
In der nächsten Folge schauen wir uns die Leistungsfähigkeit und einige Implikationen dieses Ansatzes an.
Im vorigen Teil dieser Serie haben wir uns einige mentale Modelle angeschaut, die genau wie viele unserer Datenschutzkonzepte von der Informationstechnik des vorigen Jahrhunderts ausgehen. Jetzt nähern wir uns der Realität von heute, zunächst anhand einiger Dienste und Funktionen, die in Sachen Privatsphäre weniger kritisch sind.
Strategische Position
Google sitzt auf der Content-Schicht in der Mitte des Netzes. Alle online veröffentlichten Informationen kommen dort vorbei, und das inzwischen sehr schnell. Obendrein bietet Google mit der Suche einen Dienst an, den fast jeder Internet-Nutzer verwendet. Und die Google-Suche muss mit verrauschten Informationen umgehen können, um aus der Datenhalde Internet jeweils die relevanten Informationen herauszufiltern. Google setzt dafür auf Statistik, auf maschinelles Lernen und auf Crowdsourcing. Das illustrieren Funktionen der Suche sowie der Dienst Google Translate.
Wie baut man eine Rechtschreibkorrektur oder eine Suchbegriff-Autocompletion, wenn man in Googles Position ist? Wäre man Microsoft, würde man Wörterbücher und Grammatik-Engines in die Schachtel packen, in der man sein Office-Paket verkauft. Als Microsoft muss man alles vordenken, was der Nutzer jemals tun wird. Die einzigen Rückkanäle sind die Support-Hotline, gelegentliche Crash-Reports sowie der Markt. Ist man dagegen Google, so interagiert man bei jedem Tastendruck mit seinem Nutzer.
Homöopathisches Crowdsourcing
Darauf lassen sich Crowdsourcing-Modelle stützen. Crowdsourcing bedeutet in etwa andere arbeiten lassen. Das ist gar nicht so einfach wie es klingt. Verlangt man zu viel für zu wenig Gegenleistung, fühlen sich die anderen ausgenutzt und spielen nicht mit. Ein früher Versuch in dieser Richtung war Googles Image Labeler. Er verpackte das Finden von Schlagworten zu Bildern als Spiel – das schnell langweilig wurde. Am besten funktioniert andere arbeiten lassen, wenn die anderen damit gar keine Arbeit haben oder die Arbeit sowieso machen.
Eingabekorrekturen sind ein Beispiel. Wer sich vertippt und seinen Fehler bemerkt, der wird ihn korrigieren. Sind wir nun Google und haben wir einen interaktiven Kanal zu jedem einzelnen Internet-Nutzer, so bekommen wir täglich Millionen, vielleicht sogar Milliarden von Tippfehlern samt den zugehörigen Korrekturen frei Haus geliefert. Mit anderen Worten, Google erhält eine umfangreiche Tippfehler- und Korrekturstatistik über einen beachtlichen Teil der Weltbevölkerung. Der einzelne Fehler, die einzelne Korrektur oder auch das Profil eines einzelnen Nutzers sind dabei belanglos, während die Aggregation dieser Daten fast alles enthält, was man über Tippfehler und und ihre Berichtigungen wissen kann.
Wenn man Google ist, zapft man diese Datenquelle an und baut einen Mechanismus, der von den Nutzern lernt, wie Tippfehler zu korrigieren sind. [Das Teufelchen auf meiner linken Schulter unterbricht mich gerade und schlägt vor, einen Google-Korrektur-Flashmob zu organisieren, der Google einen falschen Korrekturvorschlag für Hommingberger Gepardenforelle antrainiert. Das Engelchen auf der rechten weint leise in einen Facepalm hinein.] Funktioniert so ein Mechanismus einmal, müssen wir uns um keine Rechtschreibreform mehr kümmern. Das übernehmen alles die Nutzer, indem sie sich ganz natürlich verhalten. Das ist etwas vereinfacht, weil Google außerdem auch noch das ganze Web kennt und auch daraus eine Menge über alle möglichen Sprachen lernen kann (freies PDF).
Welche Vervollständigungen für teilweise eingetippte Suchbegriffe in Frage kommen, können wir an Googles Stelle auf ähnliche Weise ermitteln. Wir beginnen mit einer Statistik über die eingegebenen Suchbegriffe und die Texte im Web und bieten Vervollständigungen an. Mit dem Nutzerfeedback – welche Vorschläge werden angeklickt? – verfeinern wir unser Modell. In diesem Fall ist es manchmal nützlich, zum Beispiel den ungefähren Aufenthaltsort des Nutzers genauer zu kennen, wie ihn die IP-Adresse oft verrät.
Von der EU lernen heißt Übersetzen lernen
Wie weit solche Ansätze der automatischen Sprachverarbeitung heute führen können, zeigt uns der Übersetzer Google Translate. Dessen Übersetzungen erfolgen nicht anhand von Regeln, die ein Programmierer vorgegeben hat. Das wäre die Microsoft-Methode für Firmen, die Software in Schachteln packen. Die Google-Methode funktioniert nach demselben Prinzip wie eben erläutert. Aus dem Web bekommt Google laufend Beispiele für Übersetzungen, etwa von der EU mit ihren 23 Arbeitssprachen, in die alle offiziellen Dokumente übersetzt werden. Diese Übersetzungen stammen von Menschen; Google lässt daraus Maschinen lernen.
Weil das alleine noch recht fehleranfällig ist, berücksichtigt Google wieder auch das Feedback von seinen Benutzern. Sie können für die Übersetzung einzelner Wörter oder Wortgruppen zwischen Alternativen wählen, eigene Korrekturen eingeben und die Übersetzung insgesamt bewerten:
Die Korrekturen und Bewertungen liefern Google auch hier eine Statistik zur Optimierung.
Verhaltensforschung ohne Privacy-Problem
Um solche Funktionen und Dienste realisieren zu können, muss Google seine Nutzer ein wenig beobachten. Google benötigt eine Aufzeichnung der Nutzerinteraktion über einen Nutzungskontext hinweg, der sich über eine Folge von Klicks (Nutzersicht) oder HTTP-Requests (Googlesicht) erstreckt. Informationen über den Nutzer als Person sind Google dabei egal, das beobachtete Nutzerverhalten liefert lediglich Datenpunkte für eine Statistik über die gesamte Nutzerpopulation. Google möchte an dieser Stelle nicht wissen, wer wir sind oder wofür wir uns interessieren, sondern welche Verhaltensweisen häufig und welche selten vorkommen.
Unerwünschte Nebenwirkungen, zum Beispiel das Erstellen persönlicher Rechtschreibprofile beim Dienstanbieter, sind nicht per se ausgeschlossen. Sie sind nur uninteressant und lassen sich durch mittlere Sorgfalt im Umgang mit Daten recht zuverlässig vermeiden. Unterwegs besteht noch das Risiko einer Datenverkehrsanalyse, aus der jemand trotz Verschlüsselung Rückschlüsse auf Eingaben ziehen könnte, aber das ist ein (kleines) inhärentes Risiko des Netzes, dafür kann Google nichts. Sollte so etwas als Angriffsszenario praktisch relevant werden, ließe es sich zudem technisch verhindern.
Google baut also Dienste, die mit implizitem Feedback aus dem statistischen Nutzerverhalten optimiert werden. In der nächsten Folge werden wir noch etwas tiefer in die Welt der lernenden Maschinen eintauchen. Es wird dann darum gehen, wie eine Maschine überhaupt lernen kann. Keine Angst, Formeln gibt es keine.
Google macht ein Riesengeschäft mit unseren Daten. Das stimmt. Google legt dazu gigantische Datenbanken an, aus denen man alles über uns herauslesen kann, und führt sie jetzt auch noch dienstübergreifend zusammen. Das stimmt so wahrscheinlich nicht, die Sache ist komplizierter.
Um Google ranken sich Mythen und Missverständnisse, manche halten Google gar für »eine der am meisten mißverstandenen Firmen auf diesem Planeten«. Diese Missverständnisse gehen oft darauf zurück, dass wir die einzelnen Ausprägungen von Google – Dienste wie die Suche, GMail, Google+ usw. – isoliert mit ihren jeweiligen Konkurrenten identifizieren, statt die Leitideen dahinter zu betrachten.
Repräsentativ für diese Art von Missverständnis ist die Betrachtung von Google+ als »Googles Angriff auf Facebook«, die uns oft Hand in Hand mit Untergangsprognosen begegnet. Dieselben Wahrsager können auch der Integration von Google+ und Google-Suche nichts abgewinnen. Doch im Google-Paradigma betrachtet ergibt alles einen Sinn: Google+ und die Dienstintegration liefert Google Daten genau jener Art, die Google braucht, um noch googliger zu werden. Womit wir wieder bei den Datenbanken wären, die Google nicht führt, weil Datenbanken ein Konzept aus der Welt vor Google sind.
Was also tut Google eigentlich mit unseren Daten? Diese Frage versucht meine Artikelserie zu beantworten. Sie wird aus aus öffentlichen Informationen und einer Portion Informatikerbauchgefühl ein Bild davon skizzieren, was Google (mutmaßlich) mit unseren Daten macht und wieso diese Nutzung nicht per se böse ist. Das soll weder eine Glorifizierung noch eine Verteufelung werden, sondern eine neutrale Darstellung technischer und philosophischer Aspekte sowie einiger daraus folgender Fragen zu unseren aus der Mainframe-und-PC-Ära überlieferten Datenschutzkonzepten. Um konstruktiv über Datenschutz-Fails, Post-Privacy und Spackeria-Positionen diskutieren zu können, brauchen wir korrekte Modelle dessen, worüber wir reden.
Wer eine Stunde Zeit hat, sich mit Googles unkommentierter Sicht der Dinge zu beschäftigen, dem sei der Vortrag »Secrets of Search« von Douglas Merrill empfohlen. Merrill erklärt darin, was Google mit den vielen Daten im Netz und von seinen Nutzern eigentlich tut. Meine Betrachtungen sind zum Teil spekulativ, wo sie über die Aussagen der verlinkten Quellen hinausgehen. Ich habe kein Insiderwissen und kann mich in meinen Schlussfolgerungen irren. Aber aus lückenhafter Dokumentation, beobachteten Verhaltensweisen und Experimenten Rückschlüsse auf die Funktionsweise von Systemen zu ziehen, ist schließlich mein Beruf. Auf technische Details kommt es mir hier nicht an, mir geht es um Funktionsprinzipien und Paradigmen, die Googles Herangehensweise zugrunde liegen.
In Folge 2 werden wir landläufige Vorstellungen von Nutzerprofilen betrachten und die Exceptions skizzieren, die der Legacy-Code unseres Datenschutzes bei der Interaktion mit dem Phänomen Google wirft.
Der Screenshot unten kommt aus Google Maps. Das gelbe Sternchen über dem Label „Darmstadt“ geht weg, wenn ich alle Google-Cookies lösche, und erscheint wieder, nachdem ich mit bei Google eingeloggt habe. Hat jemand eine Idee, woraus Google diese Information extrahiert? Es scheint sich nicht um den aktuellen Aufenthaltsort zu handeln.
Es gibt noch einige andere Funktionen, die sich ähnlich verwenden lassen. Klicks auf einzelne Treffer im Suchergebnis gehen auch über einen Google-Redirect, von dem man normalerweise nichts merkt.
Sicher ist sicher? 