Reinventing AI: Vom Such- zum Entscheidungs‑Engine – Ein technischer Deep‑Dive zu Philipp Wissgotts Vision bei danube.ai

Kontext: Warum „Reinventing AI“ mehr als ein Buzzword ist

In „Reinventing AI“ mit Speaker Philipp Wissgott (danube.ai) zeichnet sich ein klarer technischer Spannungsbogen ab: Nach zwei Jahrzehnten Suchmaschinen‑Dominanz stellt sich die Frage, was danach kommt. Wissgott setzt die These, dass der nächste Schritt nicht „noch bessere Suche“, sondern ein vollkommen anderes Paradigma ist: Entscheidung statt Suche. Seine zentrale Beobachtung: Suchmaschinen filtern – sie entscheiden nicht. Genau hier setzt danube.ai mit einem Entscheidungs‑Engine an, das sich bewusst von maschinellem Lernen abgrenzt und stattdessen auf einen mehrdimensionalen Sortieralgorithmus setzt.

Als DevJobs.at‑Redaktion haben wir diesen Vortrag als Anstoß verstanden, über die Architektur gängiger „AI‑Produkte“ nachzudenken und sie gegen menschliche Entscheidungsprozesse zu spiegeln. Im Folgenden fassen wir die Kernideen zusammen – mit Fokus auf das „Wie“: Datenflüsse, Personalisierung, Abgrenzung zu Machine Learning, und das iterative Heranführen an Entscheidungen in realen Szenarien.

Von Yahoo zu Google – und warum „Filtern“ nicht „Entscheiden“ ist

Wissgott beginnt historisch: Vor Google prägten Yahoo und AltaVista das Web. Googles Durchbruch erfolgte durch einen hierarchischen Algorithmus, der das Web skalierbar und schneller durchsuchbar machte. Wichtig ist die Trennung: Das ist vor allem Datenverarbeitung und Ranking in großem Maßstab – nicht notwendigerweise „Intelligenz“ im Sinne von menschlicher Entscheidungsunterstützung.

Die Stärken klassischer Suche:

• Sie wird durch Nutzung besser: „Google gets better with every search.“ Nutzersignale fließen in das Ranking ein.
• Sie personalisiert – auf grober Ebene. Ein Beispiel: Standortbasierte Treffer („Autohändler in der Nähe“).
• Sie liefert Mikroservices, die uns alltäglich beschleunigen (Maps, Kalender, Suche). Kleine Verbesserungen multipliziert mit Milliarden Nutzern ergeben enorme Wirkung.

Die Grenzen:

• Der Suchschlitz und die Ergebnisliste sind „nur“ ein Filter. Es geht um Datenbeherrschung, nicht um Entscheidungslogik.
• Die erste Ergebnisseite ist entscheidend; was dahinter liegt, bleibt oft ungesehen.
• Nutzer müssen „Experten“ werden, um gute Kaufentscheidungen zu treffen (TVs, Laptops, Autos). Das kostet Zeit – die im Alltag fehlt.

Die Konsequenz: Es klafft eine Lücke zwischen „Information finden“ und „gute Entscheidung treffen“. Genau dort verortet Wissgott das Feld der Entscheidungs‑Engines.

Entscheidungs‑Engine: Die Vision im Alltag

Wissgott illustriert die Zielrichtung mit einem konkreten Szenario. Nicht „Auto kaufen Tipps“, sondern: „Welches Auto soll ich kaufen?“ Die Antwort soll nicht eine Liste von Artikeln sein, sondern wenige, persönlich passende Optionen – mit echter Handlung

smöglichkeit.

• Personalisierung nutzt persönliche Präferenzen: Lebensstil, Urlaubsgewohnheiten, Marken‑ und Farbvorlieben.
• Der Output ist kompakt: „fünf Ergebnisse“ – Fahrzeuge, die man in „einer Stunde“ im Laden um die Ecke probefahren kann.
• Semi‑Automation statt Vollautomation: Die Engine reduziert und kuratiert; die finale Entscheidung bleibt beim Menschen.

Ein weiterer Punkt ist der Datenschutz. Laut Wissgott soll die Engine dem Nutzer Wahlfreiheit geben:

• „Alle Daten bleiben bei mir“: Speicherung im Cookie bzw. im lokalen Browser‑Speicher.
• Optionaler Account: Wenn gewünscht – aber nicht erforderlich.

Damit adressiert die Vision zwei technische Spannungsfelder zugleich: Personalisierung ab der ersten Interaktion und Souveränität über Daten.

Wie Menschen entscheiden – ein Bauplan für Software

Der Talk leitet den technischen Ansatz aus einem kognitiven Modell menschlicher Entscheidungen ab. Die Schritte, die sonst unbewusst und in Millisekunden ablaufen, werden explizit gemacht:

1) Erinnerungen sammeln: Vollständige Sammlung verfügbarer Erfahrungen.

2) Irrelevantes filtern: Nur Kontextrelevantes bleibt (z. B. Autofahrten, Pannen als relevante Erinnerungen beim Autokauf).

3) Pro‑/Contra‑Liste erstellen: Ereignisse werden in Nutzen und Risiko übersetzt.

4) Gewichtung festlegen: Nicht jedes Pro/Contra ist gleich wichtig (Panne im Urlaub vs. einmalige Handbremsen‑Anomalie).

5) Optionen sortieren: Nach persönlicher Kosten‑ und Wertfunktion (z. B. Preisempfindlichkeit, Audioqualität im Auto).

Wesentlich: danube.ai fokussiert nach Wissgott heute die Schritte 3–5. Die Schritte 1–2 – Datensammlung und ‑filterung – adressierte Google in den letzten 20 Jahren auf beispiellosem Skalenniveau. In aktuellen Kundenprojekten kommt die Datenbasis typischerweise vom Kunden (Vorverarbeitung), und danube.ai steigt bei der Bewertung und Sortierung ein.

Für Engineering‑Teams ist diese Trennung lehrreich: Wer Entscheidungsunterstützung bauen will, braucht nicht zwingend das gesamte Web. Stattdessen kann ein konzentrierter, kuratierter Datensatz ausreichen – solange die Schritte 3–5 robust, personalisiert und effizient implementiert sind.

Abgrenzung zu Machine Learning: Ein anderer Pfad, kein Modelltraining

Der Kernunterschied wird explizit gemacht. Wissgott betont:

Das hat mehrere Implikationen:

• Kein zentrales Trainingsmodell: Bei klassischem maschinellem Lernen aggregiert ein zentraler Server Daten, trainiert Modelle und bedient Anfragen aus einem gelernten Zustandsraum.
• Personalisierung „on demand“:

• Kein starres Lernfenster: Machine Learning unterscheidet oft Trainings‑ und Betriebsphase; hier entsteht die „KI“ pro Anfrage neu, aus dem persönlichen Profil.

Technisch heißt das: Statt ein schwergewichtiges globales Modell zu betreiben, instanziiert das System pro Nutzer und pro Interaktion eine maßgeschneiderte Bewertung, die eine mehrdimensionale Sortierung der Optionen vornimmt. Diese Architektur verschiebt Komplexität von „Offline‑Training + globaler Inferenz“ hin zu „Online‑Instanziierung + individuelle Gewichtung“ – mit Konsequenzen für Latenz, Skalierung, und Datenflüsse.

Nutzerähnlichkeit statt Inhaltsähnlichkeit: Das Netflix‑Beispiel

Um den Unterschied greifbar zu machen, wählt Wissgott ein bekanntes Pattern. Streaming‑Empfehlungen basieren häufig auf Inhaltsähnlichkeit: Wer Kochshows schaut, sieht als Vorschlag weitere Kochshows. Das Problem: So konsumieren viele Menschen Inhalte nicht. Es gibt implizite, soziale oder zeitliche Korrelationen, die Inhalts‑Metriken nicht einfangen.

Der Ansatz von danube.ai:

• Fokussiert ausschließlich auf Nutzerverhalten und Nutzerähnlichkeiten.
• Konstruktion eines persönlichen Profils aus feinkörnigen Ähnlichkeiten („Ich bin 5 % ähnlich zu Person X, 5 % zu Person Y …“).
• Daraus entsteht „die persönliche künstliche Intelligenz nur für dich“, die die nächsten Vorschläge steuert.

Wissgott betont hierzu:

Für Engineering‑Teams bedeutet das: Empfehlungslogik kann aus minimaler Interaktion heraus starten und muss sich nicht auf content‑basierte Features stützen. Entscheidend ist die robuste Ableitung eines individuellen Profils aus Aggregaten vieler kleiner Ähnlichkeiten.

Mehrdimensionale Sortierung: Was wir dazu aus dem Talk ableiten

Der Begriff „mehrdimensionaler Sortieralgorithmus“ fällt mehrfach, ohne dass mathematische Details genannt werden. Dennoch lassen sich die Eckpfeiler aus dem Vortrag herausarbeiten:

• Mehrdimensionale Kriterien: Kosten, persönlicher Wert, Erfahrungsgewichte (Pro/Contra) bilden Achsen eines Bewertungsraums.
• Gewichtete Aggregation: Pros/Contras werden nicht gleich behandelt, sondern nach persönlicher Relevanz skaliert.
• Sortierung statt Klassifikation: Ziel ist eine Rangliste weniger, passender Optionen – nicht die Zuordnung zu statischen Kategorien.
• Instanziierung zur Laufzeit: Pro Klick wird die Entscheidungsmatrix personalisiert aufgebaut und auf das aktuelle Kandidatenset angewandt.

Diese Eigenschaften sind besonders dann nützlich, wenn die Abschlussaktion klar ist (z. B. Probefahrt buchen) und die Ergebnisliste klein bleiben soll.

Datenhaltung und Privatsphäre: Wahlfreiheit als Architekturprinzip

Der Vortrag macht deutlich, dass Personalisierung nicht im Widerspruch zu Datensouveränität stehen muss. Die vorgesehene Wahl:

• Lokale Speicherung beim Nutzer (Cookie bzw. lokaler Browser‑Speicher), wenn man keine zentrale Ablage möchte.
• Alternativ: Konto anlegen – optional, nicht zwingend.

Technisch betrachtet zwingt das Systeme dazu, mit kurzlebigen, lokalen Profilen zu arbeiten. Kombiniert mit der „on demand“‑Instanziierung des Entscheidungsmodells entsteht ein Pfad, der ohne dauerhafte serverseitige Profile auskommen kann – und dennoch personalisiert.

Architektur in der Praxis: Schritte 3–5 als Servicebausteine

Auch wenn der Talk keine API‑Signaturen oder Komponentenlisten zeigt, sind die Funktionsbausteine klar umrissen. Für Teams, die ähnliche Engines bauen möchten, lassen sich folgende Schichten ableiten:

1) Kandidatensammlung (extern/Upstream): Datenbereitstellung und Vorfilterung (heute oft durch den Kunden). Das entspricht den Schritten 1–2 im menschlichen Modell.

2) Pro‑/Contra‑Extraktion: Ableitung von Nutzen/Risiko‑Signalen aus Nutzerverhalten und Kontext.

3) Gewichtung: Personalisierte Skalierung entlang persönlicher Kosten/Werte.

4) Mehrdimensionale Sortierung: Ranking der Optionen zu einer kompakten Shortlist.

5) Aktionsschnittstelle: Übergang zur nächsten Handlung (z. B. Probefahrt buchen) – Semi‑Automation statt Vollautomation.

Wissgott verortet danube.ai heute klar in 2)–4). Dieser Fokus ist scharf gewählt und – aus Engineering‑Perspektive – gut modularisierbar.

Semi‑Automation: Warum weniger mehr ist

Ein wichtiger Designpunkt ist der bewusst gewählte Grad der Automatisierung. Die Engine reduziert Komplexität, ohne die Entscheidung abzunehmen. Das ist mehr als eine Philosophiefrage – es wirkt zurück auf:

• Verantwortlichkeit: Die finale Wahl liegt beim Nutzer.
• UX und Vertrauen: Kleine, relevante Ergebnislisten statt „Black‑Box‑Abgabe“.
• Fehlertoleranz: Semi‑Automation ist robuster gegen Einzelirrtümer als Vollautomation mit harten Autopiloten‑Entscheidungen.

Gerade bei persönlichen Konsumentscheidungen ist diese Balance entscheidend.

Skalierung über Ähnlichkeiten: Personalisierung ab dem ersten Klick

Die Aussage „funktioniert nach dem ersten Klick“ ist ambitioniert – und aus dem Modell heraus plausibel. Statt auf strukturierte Inhaltsmerkmale zu warten, reichen schwache Signale aus dem Nutzerverhalten, um erste Ähnlichkeiten zu rechnen. Daraus folgt ein dichterer Startpunkt für die Sortierung, der sich schnell verfeinert.

Für die Implementierung bedeutet das:

• Erfassung minimaler Interaktionssignale (z. B. getroffene Auswahl, Verweildauer kann je nach Kontext relevant sein – im Talk fokussiert auf Auswahl/Klick).
• Kontinuierliche Aktualisierung des persönlichen Profils aus Mikro‑Ähnlichkeiten.
• Anwendung dieses Profils als Gewichtungsmaschine für die Sortierung.

Die betonte „exponentielle“ Verbesserung basiert auf dem Umstand, dass jede weitere Auswahl direkt die nächsten Gewichte kalibriert – statt indirekt über ein globales, träges Modell zu laufen.

Grenzen und offene Aufgaben: Schritte 1–2 und die Produktreife

Wissgott macht keinen Hehl daraus, dass die allgemein zugängliche Endnutzer‑Variante noch Zukunftsmusik ist. Heute läuft die Engine in Kundenprojekten im Hintergrund. Außerdem steht die spätere, eigene Lösung für die Schritte 1–2 (Datensammlung, Relevanzfilterung) als nächste Hürde im Raum – jedoch ohne „Google kopieren“ zu wollen.

Für uns ist das ein ehrlicher Blick auf Roadmaps: Ein fokussierter Kern (3–5) kann einen erheblichen Mehrwert schaffen, selbst wenn die vorgelagerten Schritte aus Partner‑Systemen stammen.

Engineering‑Takeaways: Was Teams aus „Reinventing AI“ mitnehmen können

Aus dem Vortrag lassen sich mehrere praktische Leitplanken für Tech‑Teams ableiten, die Entscheidungsunterstützung bauen wollen:

• Starte beim menschlichen Entscheidungsmodell: Pro/Contra, Gewichtung, Personalisierung – nicht beim Datenvolumen.
• Trenne Datensammlung und Entscheidung: Es ist legitim, Schritte 1–2 an bestehende Systeme anzulehnen und 3–5 als klaren, modularen Kern zu bauen.
• Denke in Sortierung statt Klassifikation: Ziel sind kurze, umsetzbare Shortlists – nicht bloß Trefferlisten oder Cluster.
• Personalisierung ohne Big Data: Nutze Verhaltensähnlichkeiten und beginne nach dem ersten Klick.
• On‑Demand‑Instanziierung: Verschiebe Intelligenz an den Rand („vom Server zu dir“), wo Datenschutz und Personalisierung zusammenfinden.
• Semi‑Automation bewusst wählen: Reduziere Auswahl, erhalte Autonomie.

Diese Punkte sind im Vortrag nicht als Checkliste formuliert, ergeben sich aber stringent aus der technischen Erzählung.

Zitate und Kernformulierungen, die hängen bleiben

Einige Aussagen Wissgotts verdichten die Architektur in knappen Formulierungen:

Solche Sätze markieren die Absetzbewegung vom gewohnten ML‑Denken hin zu einer gewichts‑ und sortierorientierten Architektur.

Ausblick: Entscheidung statt Suche als nächster Schritt

„Reinventing AI“ setzt eine klare These: Nach der Suchmaschinen‑Ära kommt die Entscheidungs‑Ära. Das heißt nicht, dass Indexierung, Ranking und Web‑Skalierung „gelöst“ und obsolet sind – im Gegenteil. Aber die Wertschöpfung verschiebt sich: von „Was gibt es?“ zu „Was passt für mich – jetzt?“

Die Vision, in einer Stunde eine Probefahrt mit einem aus fünf passenden Autos fahren zu können – inklusive Terminbuchung – ist bewusst konkret formuliert. Sie zwingt Technik, UX und Datenhaltung auf das Ziel der Entscheidung auszurichten. Und sie stellt Privatsphäre als wählbares Standardverhalten neben Personalisierung – statt dagegen.

Schluss: Was wir von „Reinventing AI“ gelernt haben

Für uns als DevJobs.at‑Redaktion ist die Quintessenz dieses Talks von Philipp Wissgott (danube.ai): Wenn man Entscheidungsunterstützung ernst nimmt, muss man den Schritt von globalen, vortrainierten Modellen hin zu personalisierten, mehrdimensionalen Sortierern denken, die pro Interaktion instanziiert werden. Das entkoppelt Personalisierung von Big‑Data‑Zentralismus und schließt an das an, was Menschen real tun: Pros und Contras abwägen, gewichten, sortieren – und dann entscheiden.

Die gezeigte Architektur ist bewusst unaufgeregt: kein Training, keine Modell‑Zyklen, keine Inhalts‑Features. Stattdessen: Nutzerverhalten, Ähnlichkeiten, Gewichte – und eine Shortlist, die zur Handlung einlädt. Genau deshalb bleibt „Reinventing AI“ im Gedächtnis: Es ist weniger „neue Magie“ als eine saubere Übersetzung menschlicher Entscheidung in Software.

• 

  

  How danube.ai built: "Eine Upselling-AI als API für Geizhals"

  Das Unternehmen danube.at berichtet in einem TechTalk mit devjobs.at darüber, wie sie eine Upselling AI für einen Kunden entwickelt haben.

  Jetzt ansehen