JioStars Chief Architect über KI-Suche für 500 Mio. Menschen

In unserer Reihe Executive Function teilen Führungskräfte ihre Perspektiven darauf, wie sie mit KI Veränderungen vorantreiben.

JioStar betreibt Unterhaltungs- und Live-Sport-Plattformen, die mehr als 500 Millionen Menschen nutzen. Bei Live-Sportübertragungen erreichte das Unternehmen bereits bis zu 72,5 Millionen Menschen gleichzeitig. Bei dieser Größenordnung muss KI schnell, zuverlässig und für den Produktivbetrieb bereit sein.

Mit der OpenAI API hat JioStar einen dialogbasierten Assistenten zum Finden von Videos und Cricket-Statistiken in JioHotstar integriert. Über natürliche Sprache kann das Publikum Filme und Serien, frühere Highlights, Szenen aus laufenden Spielen oder Cricket-Statistiken finden. Die Ergebnisse werden visuell und im Dialog präsentiert.

Beim Executive Summit von OpenAI in Singapur sprach Sidharth Sharma, Head of Go-to-Market for ASEAN bei OpenAI, mit Vijay Seshadri, Chief Architect bei JioStar. Im Gespräch ging es darum, wie das Team dieses Angebot in etwa acht Wochen für mehr als 15 Sprachen entwickelte und was Führungskräfte daraus lernen können, wenn sie KI von der Demo in den Produktivbetrieb bringen.

Die Art, wie wir Inhalte entdecken, hat sich in den vergangenen 25 Jahren kaum weiterentwickelt. Empfehlungen waren die letzte große Veränderung. Vieles danach war eine Weiterentwicklung derselben Idee.

Aber die Entscheidung, was man sich ansieht, ist sehr persönlich. Jemand könnte sagen: „I’m feeling sad. Show me something that will cheer me up.“ Schon in dieser einfachen Bitte stecken viele Nuancen. Was für eine Art von Traurigkeit ist es? Was heitert diese Person normalerweise auf? Möchte die Person eine Komödie, etwas Vertrautes zum Wohlfühlen oder etwas, das sie völlig ablenkt?

Ein herkömmliches Empfehlungssystem kann Schwierigkeiten haben, diese Situation zu verstehen. Im Gespräch kann die Person erklären, was sie gerade braucht. Wir nennen das eine sprachgesteuerte visuelle Oberfläche.

Im Oktober und November begannen wir, das Konzept auszuarbeiten. Im Februar stand ein großes Cricket-Turnier an. Wir hatten etwa zwei Monate Zeit und zwei sehr unterschiedliche Zielgruppen: Menschen, die Unterhaltung suchen, und Cricket-Fans.

Wer Unterhaltung sucht, sagt vielleicht: „It’s Friday evening—surprise me“, oder beschreibt einen Film, ohne seinen Titel zu kennen. Sportfans möchten vielleicht gezieltere Informationen, etwa zu gefallenen Wickets, einer Serie von Sechsern oder dem Spiel, in dem jemand eine bestimmte Anzahl von Runs erzielt hat. Menschen mit fundiertem Cricket-Wissen möchten vielleicht Statistiken zu jedem Ball.

Dabei stellen sich ganz unterschiedliche Anforderungen an die Suche. Wir arbeiteten daran, Unterhaltung, Sportszenen und detaillierte Cricket-Statistiken in kürzester Zeit in einem gemeinsamen, mehrsprachigen Angebot zusammenzuführen.

Schon sehr früh haben wir das Problem als einen Zielkonflikt zwischen Genauigkeit, Latenz und Kosten betrachtet. Bei jeder technischen Entscheidung mussten wir alle drei Aspekte gleichzeitig abwägen.

Durch die Spracheingabe war das besonders wichtig. Mehr als 60 % der Menschen, die unser Angebot nutzen, wählen Sprache statt Text: Sie sagen lieber, was sie sehen möchten. Die Antwort muss trotzdem relevant sein, schnell kommen und sich auch bei hoher Nutzung wirtschaftlich bereitstellen lassen.

Ich sehe dabei zwei Bestandteile: einen Evaluationsrahmen und eine Validierungsebene. Vor dem Produktivbetrieb sollte der Evaluationsrahmen den Anstoß für Änderungen geben. Im Produktivbetrieb sollte eine Feedbackschleife aus dem Nutzungsverhalten und auftretenden Fehlern neue Evaluationsfälle ableiten.

Dieser Kreislauf kann sich selbst verstärken. Ihn richtig aufzusetzen, ist aber äußerst schwierig.

Fachleute sind unverzichtbar. Für die Evaluationen zu Sportstatistiken arbeiteten wir unter anderem mit Menschen aus Sportredaktionen zusammen, die wussten, welche Fragen besonders interessierte Fans stellen könnten. Ein Prompt allein reicht für den Anfang nicht aus. Du musst dem System fundiertes menschliches Fachwissen als Grundlage mitgeben.

Eine gute Entscheidung war die Zusammensetzung des Teams. Wir starteten mit einem kleinen Team aus Datenwissenschaft und Entwicklung sowie einer klar definierten Problemstellung. Das direkt mit uns arbeitende Entwicklungsteam von OpenAI half uns, noch genauer zu bestimmen, welche wenigen Dinge unbedingt stimmen mussten.

An erster Stelle stand der Funktionsumfang. Über eine Sprach- oder Textoberfläche können Menschen fast alles fragen. Deshalb legten wir zunächst fest, welche Fragen das System nicht beantworten sollte. Schutzmechanismen hatten Vorrang.

Für die Evaluationen begannen wir mit einem Ausgangsdatensatz, den wir mithilfe von Modellen um weitere Varianten ergänzten. Wir entwickelten etwas, das man heute vielleicht als Erstellungs- und Prüfmuster bezeichnen würde: Ein Modell half dabei, die Antwort auf eine Frage zu bestimmen. Ein anderes prüfte sie mit einer gegenläufigen Zielsetzung, also ein LLM als Bewertungsinstanz.

Das warf eine weitere Frage auf: Wer prüft die Bewertungsinstanz? Die Gestaltung dieser Prüfinstanz war selbst eine Evaluationsaufgabe. Codex half dem Team, Arbeiten wie das Erstellen von Evaluationsfällen und das Aktualisieren des Systems zu beschleunigen. Doch eine schnellere Entwicklung machte Urteilsvermögen und Validierung nicht überflüssig.

Ich würde früher in die Überwachung der Modellwirksamkeit im Produktivbetrieb investieren.

Klassische Infrastrukturkennzahlen wie die P99-Latenz bleiben wichtig, reichen aber nicht aus. Du musst auch überwachen, wie wirksam das Modell im Produktivbetrieb ist.

Erstens besteht eine große Lücke zwischen den technischen Möglichkeiten und der Realität im Unternehmen. Wenn dein Unternehmen nicht mit jeder Ankündigung eines Frontier-Modells Schritt gehalten hat, bist du damit nicht allein.

Zweitens: Konzentriere dich weiterhin auf Ergebnisse statt auf Aktivitäten. Sichtbare Aktivität lässt sich leicht mit echtem Fortschritt verwechseln, besonders wenn Unternehmen vor allem den Aufwand messen. Die Anzahl generierter Codezeilen sagt zum Beispiel nicht aus, ob du einen echten Mehrwert geschaffen hast.

Und schließlich unterschätzen die meisten Unternehmen, wie viel menschliche Kompetenz und eigenständiges Handeln nötig sind. Ein allgemeines Weiterbildungsprogramm allein reicht dafür nicht aus. Führungskräfte brauchen Menschen, die diese Werkzeuge mit Urteilsvermögen einsetzen können. Gib einer versierten Entwicklungsfachkraft ein Werkzeug wie Codex, und die Wirkung kann sich vervielfachen. Fehlt jedoch das Urteilsvermögen, um Produktivsysteme zu validieren, vervielfacht sich auch das Risiko.

Du hast eine Rakete in der Hand. Gerade bei Produktivsystemen brauchst du Validierung und Schutzmechanismen. Und du musst die Steuerung den richtigen Menschen überlassen.