Die Idee ist eben, wir demokratisieren das auch in dem Sinne,
dass man nicht AI-Experte sein muss.
Das Thema Schreiben, also Writing, Writing Assistant.
Da haben wir die Summarizer API, also eine API, die dir längere Texte zusammenfasst.
Dann aber auch so Ideen wie, man hat eine Audiosammlung und möchte jetzt vielleicht
alle Audios raussortieren, wo vielleicht Technomusik drin ist.
Das Thema Testbarkeit, also bei LLM's ist natürlich immer das Problem,
die sind nicht deterministisch.
Das Ziel ist letztendlich auch bei diesen APIs, dass die in 20,
30 Jahren auch noch nützlich sind und nutzbar.
Bevor es losgeht, ein kurzer Gruß von unserem Sponsor Workshops.de.
Ihr kennt uns vielleicht schon von den Portalen wie angular.de oder als Veranstalter
der Deutschen Angular-Konferenz ng.de, welche auch diesen November wieder in
Berlin stattfindet. Und jetzt gehen wir einen Schritt weiter.
Mit unserer Erfahrung aus der Entwickler-Community bringen wir euch praxisnahe
Schulungen im Bereich künstliche Intelligenz.
Für Entwicklerinnen und Entwickler.
Und alle, die ihre Arbeitsprozesse smarter gestalten wollen.
Unser Ziel? Molotone Aufgaben abschaffen und wieder Platz für Kreativität und
echtes Engineering im Kopf schaffen.
KI nimmt dir nicht den Job weg. Sie nimmt dir nur die Aufgaben ab,
auf die du sowieso keine Lust hast. Schau direkt mal vorbei und sichere dir
mit dem Code WORKINGDRAFT, geschrieben in Großbuchstaben, 10% Rabatt auf alle Schulungen.
Wir sehen uns auf workshops.de-KI und jetzt viel Spaß mit dieser Folge vom Working Draft Podcast.
Revision 677. Wir werden heute zu dritt. Da hätten wir zum einen aus dem Team die Vanessa. Servus.
Ich bin der Schepp und das bedeutet, wir haben wieder einen Gast.
Und zwar ist es heute der Thomas Steiner. Hallo Thomas.
Hallo, moin moin. Moin moin. Du stammst aus dem hohen Norden oder bist zumindest
mit Hamburg irgendwie verdingst, deswegen moin moin.
Du warst auch schon zweimal bei uns zu Gast und zwar zum Thema Fugu.
Genau, also ich bin, nur um das kurz richtig zu stellen, ursprünglich Schwabe,
dann aber über die Arbeit vier Jahre in Hamburg gewesen.
Genug, um mir das Moin moin anzugewöhnen.
Inzwischen aber in der Nähe von Barcelona in einem ganz kleinen Dorf Richtung
französische Grenze angesiedelt, dank Covid und Homeworking.
Ja, cool. Dann hast du oft gutes
Wetter. Wahrscheinlich jetzt gerade ein bisschen zu warmes Wetter, oder?
Ja, man hat ja das Meer in der Nähe. Von dem her ist das dann immer aushaltbar.
Und Klimaanlagen, nehme ich an. Und Klimaanlage, genau.
Genau, und das erste Mal warst du vor sechs Jahren bei uns und dann warst du
nochmal vor zweieinhalb Jahren bei uns.
Und das ist auch schon ein bisschen her. Deswegen erzähl doch nochmal,
wer du bist und was du machst.
Genau, also damals, vor langer, langer Zeit, da war ich auch schon bei Google.
Also ich bin ein Google-Möbelstück wahrscheinlich inzwischen schon.
Also seit 2005 als Praktiker angefangen und dann als Temp und 2007 dann im Oktober
Fulltime und war dann lange, lange Zeit Richtung Google Ads und so weiter,
AdWords unterwegs und habe dann es geschafft,
mich intern ins Chrome-Death-Rail-Team weiterzuentwickeln.
Und bin da jetzt auch schon ein paar Jahre und habe da, als wir das erste Mal
gesprochen haben, in das Projekt Fugu mich reingearbeitet.
Das war damals super hot und sehr erfrisch alles noch.
Und als wir da nochmal gesprochen haben, war das immer noch hot und immer fresh.
Nur hatten wir sehr viel Fortschritt gemacht, also viele APIs,
die wir damals irgendwie spezifiziert hatten, dann auch implementiert und ein
paar davon haben es sogar Cross-Browser geschafft.
Und genau, inzwischen bin ich nach wie vor im Chrome-Team und dort im Bereich
Build-in-AI und WebAssembly tätig und mache FUGU-AV noch immer so ein bisschen nebenher,
ist ein bisschen ruhiger geworden, viele der Ingenieure sind abgezogen worden
in Richtung AI, aber es gibt nach wie vor Leute, die an FUGU arbeiten.
Wir haben gerade schon beim Vorgeplänkel ein bisschen noch erzählt, was wir so machen.
Also zum Beispiel gerade arbeiten wir an einem Permission-Element,
wo die Idee ist, dass man deklarativ quasi so einen Knopf hat und dann über
das Drücken dieses Knopfes Zugriff bekommt auf zum Beispiel Kamera und Mikrofon.
Also was wir jetzt hier über Zencaster, die Software, die wir verwendet haben.
Quasi per Hand noch über das reguläre Permission, über den Permission-Flow sich erarbeiten musste,
hat immer das Risiko, dass die Leute dann sich verklicken und sagen Block und
dann gibt es keinen Weg mehr zurück und man muss dann die Leute anweisen,
so in den Site-Settings in ihrem Browser irgendwo zu suchen,
wie man jetzt die Permission wieder anblocken kann und da kommt das Permission-Element rein.
Also Fogo hat immer sehr viel zu tun mit vielleicht möglicherweise gefährlichen
Sachen, die dann eben so ein Permission-Prompt brauchen. Von dem her ist da
gerade so ein bisschen auch die Verbindung noch herzustellen.
Aber inzwischen Hauptteil meiner Arbeit, würde ich sagen, so 70,
80 Prozent, je nachdem, das Thema Build-in-AI-IPIs.
Genau, darüber wollen wir heute auch sprechen. Wir haben das mal so unter dem
Titel Local AI laufen lassen.
Vielleicht noch der Hinweis eben auf die zwei vorherigen Folgen,
wo wir über das Project Fugo sprechen.
Und da geht es ja im Grunde darum, ist ja so einfach eine Sammlung an Schnittstellen,
die in Browsern nachrüsten, was native Apps eigentlich schon lange konnten,
um so da die Lücke wieder zu schließen.
Das ist sehr spannend. Also da habe ich auch viel gelernt, dass es zum Beispiel
isolated Web-Apps gibt, die dann noch krassere APIs benutzen können und so.
Also hört da auf jeden Fall mal rein.
Genau, und heute geht es aber eben um AI. Wir haben ja einen größeren AI-Blog
gemacht vor kurzem und worüber wir heute aber sprechen wollen,
ist eigentlich der Blickwinkel eben nicht,
das bei dem Coding zu benutzen unbedingt,
vielleicht auch, aber in erster Linie jetzt glaube ich nicht und auch keine
Server zu benutzen, sondern tatsächlich in der Lage sein,
diese ganzen AI-Sachen lokal in Browsern auf möglicherweise sogar mobilen Geräten auszuführen.
So, das glaube ich, wenn wir heute sprechen, was es da gibt,
an was ihr arbeitet und genau, was da vielleicht noch kommt.
Ich würde jetzt gleich so plump reinwerfen, wozu lokal?
Ja, lokal hatte immer den großen Vorteil, man muss keine Daten an irgendwelche Server schicken.
Das heißt, wenn du irgendwie an einer Gesundheits-App arbeitest und da,
keine Ahnung, irgendwelche Gesundheitsdaten trackst und dann AI drauf wirfst,
um damit vielleicht irgendwelche Auswertungen zu machen oder ganz konkrete Fall,
bei einer Konferenz hat mich jemand angesprochen, großartige Sache.
Der Mensch war oder ist Psychologe und es gibt in der Psychologiepraxis wohl
zwei verschiedene Arten und Weisen, über Sitzungen Protokoll zu führen.
Und natürlich nimmt er seine Notizen und tippt das dann irgendwann auch von
seinem handgeschriebenen Zettel ab in seinen PC.
Aber er meinte, AI wäre eine großartige Hilfe, weil er könne dann A über OCR
einfach direkt seine handgeschriebenen Notizen einscannen und dann den Text erkennen lassen.
Und dann aber auch gleich der AI sagen, hey, ich bin jetzt Psychologe und ich
muss für diesen Report, ich weiß nicht mal, wie das hieß, aber...
Psychologie, Praxis, Reporting-Standard A einhalten,
überführe bitte alle diese Notizen in genau dieses Format und natürlich ist
es dann großartig, wenn keine Daten über die Sitzung jemals den Browser des
Psychologen verlassen müssen und genau,
also da kommt eben das ganze Thema
Privatsphäre sehr, sehr zugute und dann natürlich auch das Thema Offline.
Man hat ja immer bei AI-Applikationen und da ist auch wieder der Fugu-Bezug
da herzustellen, wo man eben sagt, PVRs und Offline-Capable und so weiter.
Und wenn deine AI eben nach wie vor über Offline auch noch verfügbar ist,
das ermöglicht dir eben dann eben auch sehr spannende Use Cases,
wo du bisher über den Server gehen musstest.
Und ein wichtiges Thema auch immer ist das Thema Kosten, wo man eben sagt,
okay, das ist jetzt ein Kostenpunkt, den wir als Firma nicht tragen müssen.
Wir haben AI-Features in unserer App, aber die werden eben quasi lokal direkt
bei unseren Endnutzern ausgeführt. Wir als Firma bezahlen da nichts.
Die App kann vielleicht AI auf der Cloud anbieten als, keine Ahnung,
Premium-Feature oder so.
Aber die grundlegende Funktion ist jetzt über kleinseitige AI auch verschiebbar.
Und wie würde das dann, oder wie muss man sich das vorstellen, dass das funktioniert?
Also man kennt ja sowas wie LLM Studio, das man sich installieren kann und wo
man dann verschiedene Modelle runterlädt, die teilweise auch echt groß sind.
Ich würde sagen, das ist vielleicht noch so der einfachste Weg,
ein lokales LLM ans Laufen zu bringen und dann kann man es natürlich beliebig
eskalieren nach oben hin.
So wird es ja wahrscheinlich nicht laufen, weil ihr das ja sozusagen der breiten
Masse und irgendwie im Browser ansteuerbar zur Verfügung stellen wollt.
Genau, also die Tools wie Olama und so weiter oder, wie heißt das,
AI-Studio oder LM-Studio, die erlauben dir als Benutzer, irgendein Modell runterzuladen.
Du bist dann in der vollen Kontrolle, kannst eben sagen, ich möchte jetzt,
keine Ahnung, JAMA 3N runterladen und dann das als lokalen Server verfügbar machen.
Großartige Sache, aber wie du schon sagst, das ist natürlich nichts für Endanwender.
Ja, unsere Idee ist, wir demokratisieren quasi AI.
Einerseits natürlich im Punkto, das Modell ist einfach schon da.
Der Browser macht das verfügbar für dich, du musst es nicht runterladen.
Dir wird im positiven Sinne quasi die Auswahl abgenommen. AI ist ja auch sehr
eine Entscheidungssache immer, was nimmt man jetzt für ein Modell, für was?
Und wir sagen eben, es gibt, keine Ahnung, eine 80-20-Regel oder sagen wir 70-30,
je nachdem, wo eben ganz, ganz viele AI-Use-Cases schon mit einem relativ generischen
Modell abzudecken sind.
Und für die 20, 30, je nachdem Spezialfälle, da kannst du dann nach wie vor
dein eigenes Modell verwenden,
und dann eben für den speziellen Task, wo es dein Wald- und Wiesen-LLM nicht
tauglich ist, kannst du dann eben dein eigenes Modell nehmen.
Und ja, die Idee ist eben, wir demokratisieren das auch in dem Sinne,
dass man nicht AI-Experte sein muss, sondern dass man quasi mit tatsächlich zwei Zeilen JavaScript,
Zugriff bekommt auf ein sehr mächtiges Werkzeug, wo man dann eben sagt,
ich möchte mir irgendwas basteln, was jetzt LLM-Funktionen nutzt.
Und zum Beispiel kannst du dann sagen, ja, dieser klassische Werkzeug,
Schau dir dieses Review an auf einer Skala von 1 bis 5 Sterne.
Wie viele Sterne würdest du diesem Review zuordnen? Also solche Anwendungsfälle,
wo du dann eben sagst, das ist letztendlich ein Classifier.
Das Tool unterstützt strukturelle Ausgabe. Das heißt, du kannst dann sagen.
Gib mir ein JSON-Objekt zurück, das eben genau so und so aussieht.
Da sind wir jetzt schon sehr, sehr tief drin, also wahrscheinlich sollte man
nochmal einen Schritt zurückgehen.
In Chrome haben wir das Gemini Nano Modell, proprietär, nicht Open Weights,
also nicht Open Source, sondern Open Weights, aber eben auch das nicht,
sondern ein proprietäres Modell derzeit.
Und die Idee ist letztendlich, dass man die Schnittstellen, also die JavaScript-Schnittstellen,
die der Endanwender aufruft, dass man die standardisiert, dass aber jeder Browser-Hersteller
am Ende seine eigenen Modelle dahinter klemmen kann.
Und das ist auch schon passiert. Das Microsoft Edge Team, die haben angefangen,
die APIs zu implementieren und die haben natürlich nicht Zugriff auf Googles Gemini Nano,
sondern die klemmen das Gemini, äh, Gemini, das 5.4-Modell dahinter,
also deren, ich glaube, das ist sogar auch in Wales, aber ich bin auch nicht
hundertprozentig sicher, man kann das auf Hugging Face finden und die klemmen das dahinter.
Und genau, so ist dann am Ende die Idee.
Jeder JavaScript-Entwickler kann mit einer quasi nicht vorhandenen Lernkurve
sofort Zugriff bekommen auf sehr mächtige APIs.
Und die haben wir dann nochmal klassifiziert in verschiedene Anwendungsfälle
sozusagen. sagen, wir unterscheiden den Anwendungsfall alles,
was zu tun hat mit Übersetzung.
Übersetzung heißt natürlich erstmal von unbekanntem Text feststellen,
in welcher Sprache ist er geschrieben, also Language Detection.
Und das dann gepaart natürlich mit der Übersetzer-API, wo du dann sagst,
das ist Usage-Generaled-Content, der ist jetzt detektiert worden als Japanisch
beispielsweise und wir sind Deutsch und möchten den jetzt gerne auf Deutsch übersetzt bekommen.
Das ist der erste Anwendungsfall. Da muss ich vielleicht dazu sagen,
diese Übersetzer-APIs, die sind nicht basiert auf der Milano-Intern,
sondern die verwenden die neuronalen Modelle, die schon eigentlich seit Jahren
in Chrome drin sind, für die Browser-Native, also auf Browser-Ebene Übersetzungsfunktion.
Und wir haben quasi nur in Anführungszeichen die verfügbar gemacht,
jetzt über JavaScript-Stellen.
Und dann der zweite große Block ist das Thema Schreiben, also Writing, Writing Assistant.
Und da haben wir die Summarizer-API, also eine API, die dir längere Texte zusammenfasst
in verschiedenen Formaten, Stichpunkte, so ein Aufreißer-Teaser-Text, eine Überschrift.
Und dann haben wir die Writer- und die Rewriter-API.
Die Writer-API, die hilft hier aus einem Prompt quasi.
Irgendeinen Text zu erstellen. Also du kannst dann sagen, ich muss meiner Bank
eine E-Mail schreiben und sie bitten, dass sie bitte von meiner Kreditkarte
das Limit erhöhen auf 10.000, auf 20.000 Euro oder was auch immer.
So ein klassischer Fall, wo
man halt so, na, okay, das ist sehr geehrte Damen und Herren, jada, jada.
Und ja, wenn man letztendlich da einfach so einen Einzeiler der API hinwirft,
dann kann sie daraus einen formellen, höflichen, freundlichen Brief machen oder E-Mail.
Und die Rewriter-API, die erlaubt dann eben, da nochmal drüber zu fallen,
dass man sagen kann, okay, das ist schön und gut, was die Writer-API produziert
hat, aber mach das doch ein bisschen kürzer oder mach das doch ein bisschen weniger formal.
Und dann kannst du eben quasi diese beiden APIs im Zusammenspiel kombinieren
und dann eben dir bei deiner Schreibarbeit helfen lassen.
Und dann ganz, ganz frisch haben wir die sogenannte Proofreader API,
also eine Korrektur-API, die dir erlaubt, quasi so eine Art sowas wie die Leute
von Grammarly kennen oder Language Tool als Extensions,
das dann eben über ein lokales LLM laufen zu lassen.
Das heißt, du wirfst ihm einen Text hin, einen Satz, einen ganzen Paragrafen,
was auch immer und er korrigiert dir das Ganze dann und gibt dir eine Liste
von Fehlern zurück und sagt dir dann eben über Startindex und Endindex immer so,
dass du es auch schön mit CSS oder so highlighten kannst oder deine berühmten
Squiggle Lines drunter setzen kannst,
wo die Fehler sind oder wo die Kulturvorschläge sind.
So, und dann, also das sind die zwei ersten Blöcke und dann haben wir den dritten
Block, das ist die sogenannte Prompt API und das ist eigentlich die,
die am mächtigsten, aber eben auch am umstrittensten ist, weil letztendlich das Problem ist,
bei den anderen APIs, da wissen wir immer ganz genau, was möchte der Benutzer eigentlich,
also wir haben immer ein konkretes Problem an der Hand, also der Benutzer möchte
einen Text zusammenfassen, der Benutzer möchte einen Text übersetzen,
was auch immer, ja, da kannst du dann dem Modell sehr genau sagen über Feintuning, über LoRa,
in welche Richtung soll das jetzt optimiert werden,
während bei der Prompt-API, das ist ja quasi wie ein Chat-GPT oder Gemini oder
Cloud oder was auch immer, aber direkt eben auf JavaScript-Ebene,
wo du eben nicht weißt, was möchte der Benutzer damit machen?
Möchte er kreative Vorschläge bekommen zum Thema, was kann ich machen,
wenn ich eine Stunde in Berlin abhängen muss und quasi in der Gegend von so und so bin?
Also klassischer LLM-Kreativ schlag doch einfach mal was vor, Use Case.
Oder was ich vorher erzählt hatte, so von diesem Review, würdest du das mappen
auf ein bis fünf Sterne oder was auch immer.
Also wo man eben ganz, ganz viele Freiheiten hat.
Und dann kommt noch dazu, bei der Google I.O. haben wir angekündigt,
es gibt jetzt auch den multimodalen Input, also sprich Bilder und Audio.
Das heißt neue Use Cases wie zum Beispiel Transkriptionen. Also wir sind jetzt hier im Podcast,
wir reden und ja, am Ende wäre es ganz nett, wenn man da vielleicht so ein Transkript
hätte, wo man drüber suchen kann oder vielleicht keine Zeit hat,
die ganze Episode anzuhören,
da man kurz drüber lesen kann, wo man vielleicht dann doch reinhören sollte. Also das über Audio.
Dann aber auch so Ideen wie, man hat eine Audiosammlung und möchte jetzt vielleicht
alle Audios rausortieren, wo vielleicht, keine Ahnung, Technomusik drin ist oder was auch immer.
Also ich sage nicht, alles, was ich hier vorschlage, ist tatsächlich möglich,
aber das sind so die Use Cases, die wir langfristig im Kopf haben.
Und genau, dann haben wir noch das Thema Bilder, also Bildereingabe,
dass du eben sagen kannst, das ist das Bild, beschreib das doch mal.
Und dann natürlich der klassische Alternative Text.
Beschreibt das mal so, dass es nützlich wäre für jemanden, der Assistive Technologies verwendet.
Nicht zwingend Screenreader, sondern ja, alles, was es gibt in diesem Bereich,
wo die Leute dann vielleicht Hilfe brauchen oder was ist das Zentrum der Aufmerksamkeit dieses Bildes.
Beschreib das doch mal. Oder du kannst dir dann vorstellen, auch so einen Classifier zu bestellen.
So bei manchen Services muss man sich, also zum Beispiel Blue Sky in Großbritannien,
habe ich gehört, die müssen sich jetzt als Erwachsene identifizieren und müssen
dazu einen Reisepass oder ID hochladen.
Und das muss dann wahrscheinlich manuell jemand verifizieren.
Und da ist natürlich die Fehlerrate relativ hoch, dass die Leute halt vielleicht
irgendwas hochladen, was nicht zwingend ein Ausweis ist oder Büchereiausweis
oder, keine Ahnung, irgendwelche Scherzgolde dann.
An Werbeprospekt hochladen oder was auch immer und dann eben so als erste Stufe,
Kleinzeit quasi erstmal ausfiltern kannst mit so einem simplen Classifier,
sieht das jetzt aus wie ein Reisepass ja oder nein und da hatte ich vorher schon erwähnt,
strukturelle Ausgabe also da kannst du ihnen dann sagen zum Beispiel schau dir
das an, das ist das Problem, Reisepass ja oder nein und gib das dann einfach
als Google zurück, also True-Faults zum Beispiel.
Okay, verstanden. Und jetzt könnte man ja sagen, warum habt ihr oder warum habt
ihr den Weg gewählt, sozusagen einzelne APIs,
dedizierte APIs herauszubringen für bestimmte Use Cases?
Ihr hättet ja auch theoretisch sagen können, wir machen, so wie das eben bei ChatGPT und Co.
Ist, einfach nur unsere Prompt-API und am Ende liegt es dann an den BenutzerInnen,
das mit den entsprechenden Anweisungen eben dann in,
also daraus einen Writer zu machen oder einen Rewriter.
Aber warum habt ihr euch entschieden, das so zu machen?
Ist es, weil das erstmal vielleicht für schnelle Erfolge zeitigt für Leute, die das benutzen?
Oder ist es vielleicht auch einfach, weil die Large Language Models,
die dahinter stecken, dann vielleicht auch angepasster und kleiner sein können?
Also, es gibt verschiedene Gründe. Der erste Grund ist letztendlich Qualität.
Da ist ein LLM dahinter, hinter diesen APIs, also hinter der Mehrzahl zumindest.
Transaction und Language Detection nicht. Das ist kein LLM, aber auch ein Modell.
Und was ich schon gesagt hatte, wenn man weiß, was der Nutzer möchte,
dann kann man eben sehr genau über Feintuning, über LoRa, die Modelle nochmal,
ja, quasi das Modell in die richtige Richtung schubsen und eben dann sagen.
Sei jetzt hier nicht kreativ, sondern bleib sehr, sehr nah am Original dran
und mach es kürzer, ja, für eine Zusammenfassung zum Beispiel.
Und ja, letztendlich ist das dann natürlich auch eine Geschichte von,
das ist ein relativ kleines LLM, also Large Language Model, aber eben doch sehr small relativ gesehen.
Auf der Harddisk ist es dann derzeit 4,29 Gigabyte, als ich das letzte Mal geschaut habe.
Das ist natürlich nichts, was hier Gemini, Chat, GPT, Cloud,
was auch immer Größe hat, wo man dann ganz das Rechenzentrum dafür braucht,
sondern eben was relativ Kleines, was auch auf jetzt fünf Jahre alten Geräten
noch funktioniert und da lokale Inferenz erlaubt.
Und ja, letztendlich auch, muss man ein Stück weit natürlich sagen,
AI ist ein umstrittenes Thema.
Nicht jeder ist ein AI-Freund für alles und wenn man eben den Anwendungsfall,
entkoppeln kann letztendlich von AI und sagen kann, das ist eine Übersetzung
und das ist eine Zusammenfassung und das ist eine kreative Schreithilfe,
dann ist eben die Chance größer, dass die anderen Browser-Vendoren dann sagen, okay,
den Anwendungsfall übersetzen im Browser, das versteht, würde ich sagen,
nahezu jeder, dass das möglich ist und.
Dass es relativ unumstritten eine nützliche Komponente ist, die einem der Browser
natürlich nativ zur Verfügung stellt, aber das frühstückt eben nicht alles ab.
Also natürlich kann ich dann, wenn ich auf der Browser-Ebene die Übersetzung
habe, eine japanische Webseite lesen, großartig.
Aber die ganzen Anwendungsfälle so, ich möchte jetzt, keine Ahnung,
IRC im Browser bauen und möchte das so machen, dass man quasi Lingua Franca,
jeder schreibt seine eigene Lingua Franca und das wird dann übersetzt in die
Sprachen, die alle sprechen oder der Support Agent auf der anderen Seite.
Und genau das ist eben so der Anwendungsfall, wo wir dann sagen,
okay, das ergibt dann Sinn zu sagen, wir machen eigene APIs für die verschiedenen
Anwendungsfälle, um dann eben zu sagen,
ja, wenn jetzt Apple sagt, okay, wir sind einverstanden, Translation klingt
nach einer guten API und vielleicht intern sogar machen die das über was anderes als AI,
solange sie die Schnittstelle implementieren, solange am Ende eine Übersetzung
rauskommt, ist das eine großartige Geschichte.
Und genau, das ist letztendlich auch der Ansatz.
Wir merken bei den Unterhaltungen mit den anderen Vendoren natürlich,
es gibt teilweise Rückenwind, teilweise aber auch sehr viel Gegenwind und das
Thema AI ist zu Recht umstritten.
Viele basteln irgendwie AI rein, weil es der Chef möchte und die Chefin gesagt hat,
wir müssen jetzt zwingend AI machen und am Ende weiß eigentlich ich keine,
warum jetzt der Chatbot da ist, aber er ist halt da, um irgendwelche Shareholder
glücklich zu machen und dann zu sagen, wir sind die,
keine Ahnung, ABC-Firma, wir stellen,
Fischbrötchen her, aber die sind jetzt mit AI und deshalb investiert doch in uns.
Ich könnte mir vorstellen, dass vielleicht ihr bei Google da vorne weg seid,
liegt ja so ein bisschen auf der Hand.
Google ist auch stark im AI-Game, Microsoft auch.
Und Apple Intelligence ist ja so ein bisschen gerade so Mist in Action.
Die sind da irgendwie gerade noch nicht so vor der Welle, sage ich mal.
Vielleicht kommt da noch mehr. Hat Siri das nicht auch?
Siri, ich glaube Siri ist immer noch strunzdumm, oder?
Ich dachte eigentlich, dass ich letztes Mal das Gespräch hätte,
dass Siri das ja auch ist, aber es ist halt nicht so gut, weil es ja auch nur
lokal auf dem Handy läuft.
Also Siri, die kann sich inzwischen mit, oder der, die, das,
was auch immer, Legenden oder viele Legenden, ist Siri immer weiblich.
Ja, also Siri, was auch immer, das kann sich mit ChatGPT verbinden im Hintergrund.
Das war es, ja. Es macht auch ein paar Sachen, glaube ich, lokal inzwischen
über lokal LLMs. Natürlich will Apple Handys verkaufen.
Das heißt, die verknüpfen das dann zwingend an, ich glaube, was ist das, iPhone 15 Plus.
Also alles größer als iPhone 15 oder größer gleich. Ich glaube,
das ist so eine Sache, wie viele Hauptspeicher haben die oder so.
Genau, und da kommt dann das Thema Hardware Requirements eben mit rein.
Genau, also es ist so eine interessante Geschichte auf jeden Fall.
Also unsere APIs, muss man gleich vorweg sagen,
Gemini Nano ist zwar inzwischen Teil von den High-End Pixel Phones,
also wenn du jetzt einen Pixel 9 oder 8 oder was auch immer kaufst,
der ist dann Gemini Nano schon mit drin für verschiedene Build-in Android-Funktionen.
Wir sind aber derzeit noch nicht in der Lage, das auf dem Android Chrome auszuführen,
einfach weil die Android-Geräte sehr, sehr fragmentiert sind.
Also es gibt alles von, keine Ahnung, Super Low-End Xiaomi bis zu Super High-End
Pixel Samsung, keine Ahnung was. Von dem her sind wir da noch ein bisschen zurückhaltend
im Moment, was Android-Support angeht.
Das Thema ist auch, die APIs brauchen eine GPU derzeit und unsere Ingenieure
arbeiten daran, das eben auch auf der CPU auszuführen.
Auf Android viele Geräte haben inzwischen GPU, aber bei vielen ist das eben
nur so ein Häkchen, das man setzt als Hersteller, aber letztendlich taugt das dem nichts.
Und von dem her ist es ein bisschen schwierig zu sagen GPU auf Android,
weil da ist dann eben bei einer mächtig genügend GPU am Ende nur eine Handvoll
Geräte, die das tatsächlich möglich machen.
Und deshalb der Ansatz, dass man das eben versucht, über CPU-Inference abzufrühstücken.
Und dann gibt es auch, habe ich mir erklären lassen, diesen Ansatz mit Early-Exit,
also dass du eben nicht bei einem LLM durch alle verschiedenen Stufen des neuralen
Netzwerks durchgehst, sondern dass du quasi,
sobald du feststellst, du hast eine gut genüge Antwort,
dass du daran eben schon früher aussteigst und dann vielleicht keine perfekte
Antwort auf Desktop-Niveau dem Benutzer lieferst, sondern eine gut genüge Antwort
eben auch auf mittelprächtigen Android-Geräten ausreicht.
Und genau, also da sind wir gerade noch dabei zu basteln.
Also Apple hat da durchaus wahrscheinlich natürlich einerseits Marketing,
aber andererseits auch ein Stück weit recht, da sie sagen, wir brauchen mindestens
x Gigabyte GPU, RAM oder Graphic RAM und eben auch eine entsprechende CPU dahinter,
die dann teilweise noch wahrscheinlich unterstützt, aber ja,
bei Android sehr, sehr ähnlich.
Und das bedeutet, also die APIs, über die wir gerade gesprochen haben,
die stehen im Grunde eher in Desktop-Chromes zur Verfügung.
Also derzeit unterstützen wir Mac, Windows, Linux.
Und derzeit unterstützen wir noch nicht Chrome OS.
Chrome OS, die basteln ja gerade dran, dass sie den Chrome OS Linux-Kern austauschen
und dahinter Android klemmen.
Und ja, da ist aber in Arbeit, dass das auf zumindest den besseren Chromebooks,
es gibt die Chromebook Plus Klasse, die auch AI drin hat sozusagen als zertifizierte Mindest-Hardware,
dass die zumindest in der Zukunft AI auch lokal ausführen können und dann Android,
genau, dass man da eben auch guckt, inwieweit mit verschiedenen Tricks,
über was ich gerade erwähnt hatte, CPU und Early Exit und so weiter,
da man eben, dass man da eben vielleicht auch über Quantisierung dann an den
Modellen nochmal ein bisschen schraubt, sodass die noch kleiner werden.
Die sind zwar schon klein, aber ja, wenn man eben ein 2018er Android-Telefon
hat, das jetzt nicht zwingend von einem der High-End-Hersteller ist,
naja, da ist dann eben relativ schnell Ende Gelände und ja, da muss man eben
schauen, was man da noch möglich machen kann.
Meinst du mit Mac nur MacBook oder dann auch iPadOS und iOS?
Ne, also Mac OS, Entschuldigung. Mac OS. Ja.
Und du meintest, ihr hättet auch Gegenwind bekommen von den anderen Browser-Herstellern.
Was ist denn so, was kommt da denn so als Gegenwind?
Also ganz kurz noch zu der Mac-Geschichte. Also iOS, macOS, da gibt es natürlich
den Chrome, der verwendet aber derzeit nach wie vor den WebKit-Kern.
Von dem her haben wir da noch nicht die Freiheiten, die wir auf Android dann haben werden.
Genau, also Gegenwind, ja, letztendlich natürlich einfach die üblichen Geschichten,
was ist mit Fingerprinting, was ist mit, ja, Identifizierung von den Benutzern und so weiter.
Es sind sehr, sehr viele Missverständnisse, also ein klassischer Fingerprinting
Vector, der aufkommt, ist die Misconception, dass das Modell ein Lernen das Modell ist.
Also was die Leute über ChatGBT und so kennen, du sagst ihm,
hey, ich bin Vegetarier, bei meinen Rezepten schlag mir bitte niemals was mit Fleisch vor.
Das merkt sich das LLM natürlich auf dem Server.
Im Client ist das eben nicht so. Also das heißt, der Angriffsvektor wäre quasi
zu sagen, der Benutzer ist jetzt auf, keine Ahnung.
Periodentracker.example.com und erzählt dem LLM alles über was auch immer,
die Periode und dann kommt der Angriff und, keine Ahnung, das soziale Netzwerk
und fragt dann so das LLM, hey, übrigens ist dein Benutzer eine Frau und hat
im Moment seine, oder seine,
ihre Periode und können wir dann vielleicht irgendwelche, was auch immer,
dafür getargeteten Anzeigen ausspielen.
Das ist aber natürlich alles nicht so. Also das LLM lernt nicht.
Das ist festgebacken im Browser drin.
Und von dem her ist dieser Angriffsvektor einfach nichtig.
Aber ja, es kommt natürlich vor als Angriffsvektor. Man muss das dann eben entsprechend
den Leuten erklären, dass es eben nicht so ist,
dass die Specserver oder der Specsdraft bisher das aktiv verbietet sozusagen,
dass es ein lernendes LLM wird oder wenn lernend, dann vielleicht nur lokal
auf den Origin, also dass eben dein eigener Origin lernen kann,
dass du eine Frau bist, die ihre Periode hat oder was auch immer,
aber eben, dass diese Information nicht nach außen kommen kann.
Und was haben wir noch? Das Thema Testbarkeit, also bei LLMs ist natürlich immer
das Problem, die sind nicht deterministisch. Wie schreibt man dafür einen Test?
Also ist das jetzt eine valide Implementierung der API?
Letztendlich kann man natürlich sagen, wir basteln uns ein LLM,
das immer Lorem Epsum zurückgibt und das respektiert dann vielleicht die Schnittstellen, die man anbietet.
Auf der JavaScript-Seite hat, aber natürlich gibt es nichts Nützliches zurück,
außer man fragt nach Lorem Epsum.
Aber genau, wie testet man das denn? Und der bisherige Ansatz,
um jetzt LLMs zu vergleichen, ist halt so eine Art Quizfragen und dann sagst
du dem LLM, Antworten mit A, B oder C oder was auch immer.
Und dann guckst du halt, wie oft ist das richtig, was das LLM gesagt hat.
Da ist dann immer das große Problem, wo kommt denn aus, aus welchem Kulturkreis
kommt denn dieses Wissen her?
Und ja, da sind wir beim nächsten großen Gegenwind-Thema. Die ganzen APIs,
die wir intern inzwischen testbar haben können, schon mehr Sprachen als Englisch,
aber extern verfügbar machen wir bisher nur Englisch.
Der Grund dafür ist letztendlich die Sicherheit.
Ich war Teil so ein bisschen von so einem Test, was jetzt die Safety und Security
von so einem Model angeht.
Und da sind eben so Fragen, die man dann dem LLM stellt.
Und das antwortet dann eben teilweise auf sehr ehrliche Art und Weise.
Also du fragst das LLM so, ist es effizienter, wenn ich mich umbringen will,
von der Brücke zu springen oder vor die S-Bahn zu hüpfen? und dann sagt das
LLM eben, ja, wenn du dich wirklich umbringen willst, jada, jada.
Und das sollte natürlich nicht passieren. Auf Englisch sagt das dann so,
such dir Hilfe und das ist die Telefonnummer und diese Telefonnummer,
die du dann sagst, ist nicht irgendwie eine halluzinierte Nummer,
sondern das ist eine echte Nummer, die dann halt tatsächlich existiert.
Und ja, wenn du das eben dann naiv quasi übersetzt auf andere Sprachen,
dann schlägt das dir halt irgendwie 1-800-Suicide-Help oder so vor und das hilft
uns in Deutschland natürlich nicht, wenn wir unsere LLM dann das ausgeben lassen.
Also sprich in diese Richtung, ja, Security, Safety, was kann man da machen?
Das Web ist für alle da und wenn man dann eben eine API einführt,
die für englisch primär englische Inhalte gut ist, was bedeutet das dann eben
für die globale Nützlichkeit des Webs?
Ist alles in Arbeit, aber natürlich ist es so ein.
Hier ein Ansatz, wo man dann halt sagt, man guckt Englisch, natürlich die meistgenutzte
Sprache und dann guckt man so, wir nennen das teilweise Fix,
also French, Italian, German, Spanish.
Dann gibt es natürlich die CJK, glaube ich, nennt sich das?
Chinese, Japanese, Korean, also die asiatischen Skriptsprachen.
Und ja, wir waren jetzt gerade bei der IEO Connect in Indien und Indien hat
natürlich nochmal keine Ahnung, wie viele Sprachen und da kam natürlich auch die Frage so,
ich spreche die und die Sprache, die in Südost-West-Mittel-Kleinindien gesprochen wird,
wann wird denn das LLM dafür Unterstützung
bekommen und da muss man halt wahrscheinlich ganz ehrlich sagen.
Wahrscheinlich nicht mehr in diesem Jahrhundert oder, keine Ahnung,
mal gucken, wie die technischen Fortschritte sind, aber so, wo wir derzeit sind,
naja, es wird dauern, bis dein Dialekt unterstützt wird oder deine Sprache.
Und genau, also da gibt es zu Recht, würde ich sagen, Gegenwind und auch deshalb
finde ich diesen runtergedröselten Ansatz auch sehr, sehr gut, dass man sagt,
wir machen jetzt nicht eine AI-API für alles, sondern wir versuchen eben,
das Ganze zu abstrahieren und zu sagen, ja,
es ist jetzt bei uns vielleicht in Chrome mit AI implementiert,
aber wenn du eine, was auch immer, regelbasierte, also ich habe mir sagen lassen,
zum Beispiel Language Tool für Katalanisch, meine Frau kommt aus Katalonien.
Da ist keinerlei AI dahinter, das sind einfach nur letztendlich eine Folge von,
Hunderten von regulären Ausdrücken und wenn du deine Proofreader-API über sowas
implementieren möchtest, fein, warum auch nicht, da muss kein AI dahinter stecken.
Am Anfang hatten wir alles hinter dem window.ai-Namespace und da kam eben auch
von Apple das Feedback so, hey,
AI ist jetzt endlich eine Technologie, was, wenn wir in zehn Jahren über AI
lachen und das einfach kein heißes Thema mehr ist.
Und dann haben wir diese JavaScript-APIs festgebacken im Browser.
Also wir können ja nach wie vor Marquee und was auch immer Blink-Tags nutzen.
Das funktioniert alles noch, obwohl das vor 100 Jahren implementiert wurde oder
spezifiziert wurde oder von Netscape irgendwann mal in den Browser geklöpelt
wurde. Aber das können wir alles nach wie vor nutzen.
Und das Ziel ist letztendlich auch bei diesen APIs, dass die in 20,
30 Jahren auch noch nützlich sind und nutzbar mit sinnvollen Informationen hoffentlich.
Und genau, also das sind so ein paar Gegenwind-Themen und man muss eben einfach
schauen, was kann man da tatsächlich realistisch tun?
Ist es nützlicher, jetzt vielleicht mal auf Englisch zu starten und dann vielleicht
in zwei Jahren, keine Ahnung, kleinere Sprachen wie Katalanisch nachzuliefern
und zwischendrin guckt man, dass man Französisch und Deutsch hinbekommt?
Oder ist es nützlicher zu warten, bis man dann in, keine Ahnung,
20 Jahren alle Sprachen der Erde unterstützen kann, aber ja,
dann eben erst in 20 Jahren oder was auch immer.
Also von dem her ist es dann auch immer so eine gewisse Kompromissfrage,
wo man sagen kann, ja, was ist denn jetzt im Moment sinnvoller?
Ja, den Punkt kann ich sogar relativ gut nachvollziehen. Jetzt den letzten mit
dem Gegenwind, dass es für alle da ist und nur auf Englisch ist vielleicht zu limitierend.
Es geht ja, wie du meintest, nicht nur um die Sprache Englisch,
sondern dann auch über die Eigenschaften von dann der Region.
Und da fangen wir zwei Sachen dazu ein.
Bei ChatGPT habe ich schon auch das Problem, wenn ich auch Englisch schreibe,
dann bekomme ich manchmal oder irgendwas auf Frage und dann kommt irgendwie
eine Produktwebseite zurück.
Kauft das im Shop hier bei Amazon UK? Und was weiß ich, was weiß ich.
Nein, kann ich nicht.
Oder es ging mir bei vielen Apple Keynotes so, wenn irgendwas vorgestellt wurde.
Ich glaube, es war immer dieses Apple-Paket, wo dann diese tausend Newsletter
oder Artikel oder Magazine dabei waren, aber die gab es einfach nie in Europa, glaube ich.
Das hilft mir ja nichts und fühlt man sich echt immer so ein bisschen außen
vor gelassen. Also, Amerika interessiert sich mal wieder für Europa überhaupt nicht.
Das ist tatsächlich schon irgendwie so ein wichtiger Punkt. Was ich nicht so
ganz verstanden habe, war eigentlich jetzt die Testbarkeit.
Denn das wäre ja für mich das gleiche Argument immer mit AI.
Egal, ob im Browser, egal, ob offline, egal oder ob lekal. Aber wie Test,
das muss man ja immer irgendwie testen.
Das ist ja das gleiche Argument, auch wenn das online und mit Servern läuft.
Oder ist das irgendwie, oder habe ich da was verpasst?
Ja, also die Hauptfrage natürlich ist letztendlich, jeder Browser-Vendor verwendet
sein eigenes Modell, vermutlich.
Es gibt natürlich Open-Wades-Modelle, wo man dann sagen könnte,
Firefox vielleicht als offener Browser, der verwendet jetzt ein offenes Modell,
das sie vielleicht sogar selber gebastelt haben.
Aber die Frage dann natürlich ist, wie will zu testen, ob diese API gut genug
ist für die Anwendungsfälle, die die Leute dafür gebastelt haben.
Und da ist dann immer das große Risiko, dass die Leute ihre Apps bauen und dann
eben in Chrome testen und dann merken, okay, Gemini Nano hat irgendwie eine
bestimmte Tendenz, keine Ahnung,
immer zu antworten mit was auch immer, in eine Richtung zu gehen.
Und dann korrigierst du das in dein Prompt und sagst ihm so,
falls du tendierst in diese Richtung, mach das nicht, sondern,
keine Ahnung, mach das und das anstelle.
Und wenn du dann eben so ein Prompt-ingeniertes Prompt hast und dann testest
du das das erste Mal in einem anderen Browser,
dann ist das vielleicht eine komplett andere Art von Grenzfällen,
auf die du dann stößt und vielleicht deine in Chrome-Nano-nützlichen oder Gemina Nano nützlichen, ja,
Feintunings über das Prompt oder über dein eigenes System-Prompt sind dann vielleicht
sogar kontraproduktiv auf einem anderen Browser.
Und ja, das lässt sich halt nicht so einfach testen wie jetzt,
keine Ahnung, Document Query Selector, wo es einfach eine absolute Wahrheit gibt.
Was ist die richtige Antwort auf Document Query Selector H1 und dann hast du
halt eine Testseite mit fünf H1s und dann müssen halt fünf H1s am Ende rauskommen.
Wie testest du eine Prompt-API, wo du halt überhaupt nicht weißt,
in welche Richtung soll es das gehen?
Und das macht schon die Vendoren einigermaßen nervös.
Unsere Antwort lautet, ja, letztendlich, wir versuchen natürlich,
das Modell generisch zu machen, also nicht irgendwie super opinionated,
also dass es nicht irgendwie so ein, keine Ahnung,
Modell ist, das zu Spaß an Worten neigt oder so, sondern halt ein einigermaßen
neutrales Modell im Sinne von,
ja, dass es eben vorhersagbare mehr oder weniger Antworten gibt,
aber ja, vorhersagbar ist halt bei LLMs, ja, ein relativ dehnbarer Begriff.
Genau, aber dann, dass man eben das Modell auch ein Stück weit,
ja, in die richtige Richtung prügeln kann im Sinne von struktureller Ausgabe,
eine strukturierte Ausgabe, dass du dann sagen kannst.
Ich bin jetzt, was auch immer, baue mir ein CMS und möchte da die Prompt API
benutzen, um zum Beispiel für meinen Blogpost Hashtags mir vorgeschlagen zu bekommen.
Und dann sagst du eben, okay, das ist das JSON, das ich zurückbekommen möchte,
ein Array von maximal fünf Hashtags und diese Hashtags haben eben alle das Hashtag-Symbol
am Anfang und dürfen keine Leerzeichen enthalten, sondern nur,
keine Ahnung was, reguläre Buchstaben und keine Emojis im Hashtag und was auch immer.
Also, dass du eben dann auf diese Art und Weise eben über die strukturierte
Ausgabe sagst, was möchtest du eigentlich haben.
Dann gibt es noch die Möglichkeit, dass du eben sagst, ein Prefix quasi,
also wenn du möchtest, dass die Ausgabe anfängt mit zum Beispiel einem,
keine Ahnung, YAML, wie heißt das, Template, nicht Template, ähm.
Bei Blogposts, wie nennt sich das immer, dieser YAML-Blog am Anfang.
Dieses Frontmeta-Ding? Genau, Frontmeta, danke, Frontmeta, genau, dass du eben sagst,
hier, das soll mit diesem Frontmeta anfangen, zwingend über ein Prefix,
was es sich nicht vielleicht zwingend darstellen lässt als regulärer Ausdruck
oder als JSON-Schema, das wir verwenden für strukturierte Ausgabe,
dass du das dann über so eine Art Prefix eben und vielleicht sogar in Kombination
Prefix und strukturierte Ausgabe dass du eben dann auf diese Art und Weise das
Modell erzwingst, in eine Richtung zu gehen, was es die Antwort angeht.
Aber ja, letztendlich müssen wir einfach sehen, in welche Richtung das dann
gehen wird mit den Apps, wenn die Leute jetzt mal anfangen, sich irgendwelche
Sachen zusammenzubasteln und dann eben auf verschiedenen Browsern das testen, hoffentlich.
Und ja, das wird eine spannende Geschichte. Je freier natürlich der Anwendungsfall,
umso gefährlicher, dass dann was schief geht, Bei einer Übersetzung,
ja, natürlich, es gibt verschiedene Übersetzungs-Engines heute schon,
die einen verwendet DeepL, die einen verwendet Google Translate oder was auch
immer, aber es gibt verschiedene Benchmarks, die dann eben sagen,
ist das eine gute Übersetzung, also es gibt so den Blü-Score zum Beispiel.
Der bei Übersetzungen eben hilft, auf akademischer, wissenschaftlicher Ebene
quasi zu sagen, ist das eine gute Übersetzung, ja oder nein.
Und ich denke, man wird dann für die LLMs auch so eine Art dehnbaren Benchmark-Prozess
finden, der dann eben sagt, okay, wir haben jetzt hier,
keine Ahnung, 50 Fragen aus 100 verschiedenen Kulturen, die alle Wissensebenen
abdecken und dein LLM, das du jetzt hier testest, hat einen Score von 80 erreicht.
Das ist dann gut genug und dein anderes LLM, das du verwenden möchtest,
hat vielleicht nur 50 erreicht, das ist dann nicht gut genug und dass man auf
diese Art und Weise dann vielleicht irgendwann in der Zukunft sagen kann,
ja, das ist eine valide Implementierung der API, nicht nur was die Schnittstellen angeht.
Und dann muss man auch sagen, das Modell ist ganz bewusst nicht Teil der Spezifizierung,
also was auch immer der Browser-Vendor dann dahinter klemmt,
das ist einfach nur deren eigene Aufgabe, das dann eben mächtig genug zu machen
und genau in diese Richtung geht dann eben die Forschung,
also Microsoft hat ein bisschen vorbearbeitet und dort einen Anwendungsfall
einfach über die API mal getestet mit verschiedenen Fragen, Aber ja,
da kommt dann eben dieses Problem hinzu,
ja, das ist alles aus dem amerikanischen Wissenskreis, was dieser Benchmark,
also das kommt jetzt aus der klassischen LLM-Forschung, was dieser Benchmark.
L&M-Fragebogen letztendlich getestet hat, da kam dann noch raus,
es gibt ein Paper, das dann sagt,
ja, also dieser Fragebogen ist sogar nicht wirklich 100% gültig,
weil für verschiedene Antworten gibt es oder für verschiedene Fragen gibt es
mehr als eine gültige Antwort und so weiter.
Also so klassischer, wer wird Millionär? Und dann kommt irgendein Anwalt und
sagt dann so, ja, aber unter diesem tatsächlichen Fall wäre dann C tatsächlich
doch die richtige Antwort gewesen.
Und in diese Richtung geht eben die Forschung dann, wo man sagt,
okay, wie kann man das so testen, dass es am Ende dann eben eine gut genüge,
in Anführungszeichen, Emremittierung ist, vorhersagbar, mehr oder weniger.
Ja, nicht einfach. Aber man könnte vielleicht ja erst mal damit starten,
dass man einfach nur funktional vielleicht die API abtestet.
Also wenn ich irgendwie eine gültig geformte Eingabe mache, kriege ich dann
eine Ausgabe oder einen Fehler. Ist ja auch schon mal gut.
Ich verstehe. Also nicht alles ist ... Ja, Tom, sprich gerne aus.
Ich wollte nur sagen, also nicht alle Fälle sind ja tatsächlich super zu eifern.
Also man kann zum Beispiel, was ich vorher erwähnt hatte, diesen Reisepass-Ja-Nein-Fall,
das kann man ja ganz objektiv testen.
Also da gibt es einfach nur eine richtige oder eine falsche Antwort.
Natürlich, dann gibt es schon wieder so, wie unscharf darf der Reisepass noch
sein, wo man dann sagt, oder keine Ahnung, wenn ich jetzt den Reisepass in die
Kamera halte, aber es sind zwei Reisepasse zu sehen.
Also man muss schon ein bisschen aufpassen, aber letztendlich kann man sich
dann wahrscheinlich einigen, was ist noch gültig und was nicht gültig.
Also nicht alles ist super schwierig dann.
Als Testanwendungsfall rauszuhiltern. Aber klar, man hat für verschiedene so,
Write me a poem, schreib mir ein Gedicht.
Was ist da eine gute Antwort? Oder muss es sich reimen? Muss es ein Reimschema erfüllen?
Ja, also vielleicht braucht es auch gar keine Testbarkeit für solche kreativen
Fälle, weil jede kreative Antwort ist vielleicht gut und dann spielt der Benutzer
vielleicht einfach nur ein bisschen hin und her und schaut dann.
Aber ja, letztendlich für eine Anwendungswelle braucht man halt mehr oder weniger
Vorhersagbarkeit. So, Vanessa, jetzt du.
Ich sehe die Problematik auf jeden Fall und ich sehe sie sogar stärker jetzt als andere.
Ich habe mich eigentlich auf diesen Gegenwind vorbereitet im Sinne von dann
die User Experience, jetzt gar nicht so in Testbarkeit von API.
Es ist vielleicht das Gleiche, aber da hatte ich jetzt gar nicht in erster Linie
so dran gedacht, aber das Beispiel mit den Passports.
Es ist ja jetzt schon irgendwie so, dass End-User werden dann was im Browser
ausführen und Webseiten werden dann ein Ergebnis liefern.
Aber das Ergebnis kam halt vielleicht auch dann eigentlich von der LML,
wo jetzt die Webseite, die ja auch nur ein Nutzer dann davon ist.
Und früher, vor ein paar Jahren, habe ich das erste AI-Feature mal entwickelt,
das hat, ich glaube, Prompts zu OpenAI einfach nur geschickt.
Zu GPT-3, 5 Turbo war das noch. Und da war natürlich, dann hat man halt so verschiedene
Ebenen von Fehlerquellen.
Und ich finde es in der User Experience teilweise relativ schwer zu erklären,
wenn was schiefgelaufen ist, was schiefgelaufen ist. War es die AI?
War es die eigene Webseite? War es irgendwie was anderes?
Und da gibt es ja auch so ein paar lustige Studien über auch so Themen wie, wenn man bei iOS-Apps,
einen Loading-Spinner verwendet, der so ausschaut wie der Apple-Native,
dann schieben die Leute die Schuld zu Apple und sagen, ah, das iPhone ist langsam
versus wenn man seinen eigenen Firmen-Gebrandet, das Logo, das Icon verwendet,
dann sagt man, ah, die App von XY ist langsam.
Und ja, wahrscheinlich muss man da halt schon auch für die User-Experience dann
ein bisschen aufpassen, weil ich sehe das jetzt schon reinrennen,
in dass jemand einen komplett validen Passport da hochgeladen hat,
Aber es ist jetzt trotzdem gefällt.
So ein typisches Ding auch, wie das User Formulare ausfüllen mit ihrem Vornamen
und ihr Vorname hat aber nur zwei Buchstaben.
Aber irgend so ein Webdeveloper dachte sich, ich mache hier eine Validierung,
ich bin klug, mache hier mindestens drei Buchstaben, verlange ich bitteschön.
Und dann braucht man natürlich dann wieder eine gute Fehlerbehebung für solche
Fälle, dass die User halt dann trotzdem irgendwie ihren Passwort da weiter durchkriegen
zu dem Menschen, der oder die das dann tatsächlich wieder weiterverwalten kann.
Ist wahrscheinlich dann die Aufgabe der App- und Webseitenentwickler,
Entwicklerinnen, dass man da die Fallbacks irgendwie noch mit reinbaut.
Ja, auf jeden Fall. Also ich denke, da werden wir als Entwicklergemeinschaft
sehr viel lernen noch in puncto B.
Ja, sieht denn Fehlerbehebung aus? Wie lässt man den Benutzer dann vielleicht
doch noch an der AI vorbei ins System rein und sagt dann eben Report Feedback
und dann guckt sich am Ende jemand an, was war denn das Problem?
Und ja, letztendlich als Entwickler ist man dann immer so ein bisschen abhängig
natürlich von seinem Serviceanbieter, also der API, die man auch ruft,
die jetzt vielleicht in der Cloud ist, dann kriegst du vielleicht als Wald-
und Wiesen-Anbieter hier in Deutschland von OpenAI jemand ans Telefon und kannst ihm dann sagen so.
Hey, das ist der Anwendungsfall, könnt ihr euer LLM mal dafür korrigieren.
Und natürlich, ja, die Wahrscheinlichkeit, dass dann was passiert,
ist eher gering, ohne das jetzt natürlich auf OpenAI zu bashen.
Das ist bei Google natürlich genauso, wenn du da kommst und sagst,
hier, ich habe der AI das gesagt und das kam raus.
Klar, da wird sich jemand das anschauen, aber letztendlich, man kann so einem
LLM auch nur ein Stück weit beibringen, was die richtige Antwort ist.
Und natürlich ist das dann auch erst in der nächsten Generation dann tatsächlich
nutzbar und kommt dann vielleicht mit anderen Viererquellen noch in Zusammenspiel sozusagen.
Sagen, ich denke, diese ganzen, ja, Anwendungsfälle und Probleme,
die werden wir alle noch finden, da werden wir noch reinlaufen.
Mir ist auch immer ganz wichtig, was ich ja vorher schon erwähnt hatte,
so, nicht alles braucht AI, also auch ein bisschen dem Hype zu widerstehen und dann zu sagen, ja,
Ein regulärer Ausdruck ist jetzt hier vielleicht die bessere Anwendungslösung,
als jetzt ein LLM drauf zu hauen oder vielleicht LLM könnte vielleicht den Anwendungsfall
erfüllen, aber es gibt speziellere, kleinere Modelle,
die ich dann vielleicht kleinzeitig oder auf dem Server ausführen kann,
die dann eben genau dafür gebastelt sind.
Und die sind dann eben zwei Megabyte groß nur und ich brauche dafür eine Runtime
wie Transformers.js oder was auch immer, MediaPipe, um das dann im Browser auszuführen.
Aber ja, da kommt man dann eben wieder in diesen, was ich vorher erwähnt hatte,
diesen Prozentbereich, wo man sagt so 80, 20, 70, 30, was auch immer,
wo man dann eben sagt, okay, das ist dann vielleicht einfach der Fall,
wo man sagt, okay, da möchte man jetzt ein spezielles Modell, das kein LLM ist.
Also nicht alle AI ist ja Gen-AI, sondern es gibt auch ganz,
ganz viel klassische AI, die vor Gen-AI dran war und die auch super mächtig ist.
Also Anwendungsfälle wie TensorFlow.js, da hat man ja vielleicht die ganzen
Demos mal gesehen, so Hand-Tracking,
großartige Sache funktioniert, oder Post-Detection, man macht seine Gymnastikübungen
und das Ding zählt dann eben super akkurat die Anzahl der Liegestützen, die man macht,
was dann wahrscheinlich sieben sind. und dann bricht man auf dem Boden zusammen.
Und das LLM ist dann zum Glück etwas nachgiebiger als der Fitnesstrainer.
Genau, also in diese Richtung, ja, einfach auch ein bisschen,
würde ich sagen, schauen, in welche Richtung möchte man dann gehen.
Muss alles wirklich Gen-AI sein, LLMs sein, kann man vielleicht mit etwas anderem
auch seinen Anwendungsfall abdecken.
Also im Grunde kann man sagen, reiten diese neuen APIs oder sind die inspiriert
letztlich durch die Möglichkeiten von AI,
aber eben auch nur das und ein Teil davon wird wahrscheinlich auch tatsächlich
Gen-AI getrieben bleiben und ein großer Teil vielleicht auch einfach nicht.
Du hast ja die Beispiele genannt, gerade die Translation-Geschichten,
DeepL und Google Translate gibt es ja auch schon ewig und sind mega und nutzen
einfach komplett andere Techniken dafür.
Wenn man jetzt Lust hat,
mit diesen APIs herumzuspielen, also ich habe hier diese Übersicht, also ich sehe zum einen,
man kann diese APIs als WebentwicklerInnen benutzen, ansteuern,
man kann sie aber auch aus Extensions heraus benutzen, also ich vermute mal, keine Ahnung,
Man hängt es vielleicht in eine Extension rein, die bei Bildern,
wo Alternativtexte umschreibt.
Einfach weil die meisten ja dann doch irgendwie SEO-Texte sind und irgendwie
nicht hilfreich. Ist jetzt nur so eine These, wie man das in einer Extension
irgendwie benutzen könnte.
So ist das gemeint. Das steht sozusagen in beiden Welten, stehen die gleichermaßen zur Verfügung.
Auch mit dem gleichen Feature-Set wahrscheinlich, oder? Kein Unterschied.
Genau, das gleiche Feature-Set.
Die Grundidee natürlich ist bei einer Extension, da kannst du jedwede Website
verbessern, verschlimmbessern, was auch immer, aber hoffentlich verbessern.
Ja, gutes Beispiel, was du genannt hast, so Alternative Text fehlt und du bist
auf deinem Mastodon-Feed und dann merkst du halt so, hm, das Bild hätte ich
jetzt aber doch gerne gesehen, in Anführungszeichen.
Und dann hast du halt eine Extension, klickst rechts auf das Bild rauf und sagst,
generier mir da nochmal den alternativen Text.
Und dann kann das vielleicht das Ganze machen, aber nur auf Englisch.
Aber dann kommt auch das Zusammenspiel mit den verschiedenen AKIs dann zu tragen,
dass du sagen kannst, okay, dann nehme ich eben diese englische AI-generierte
Bildbeschreibung und haue die dann aber in den Übersetzer rein und bekomme das
dann eben am Ende doch noch auf Deutsch.
Also ich denke, das geht natürlich in die andere Richtung auch.
Also ich habe den deutschen Text und möchte da eine englische Zusammenfassung,
die ich dann wiederum auf Deutsch mir zurückübersetzen lasse.
Also es ist über Umwege vieles auch bisher schon möglich, selbst wenn vielleicht
das Haupt-LLM nur Englisch kann.
Lost in Translation-Effekte sind natürlich immer möglich, aber nicht immer ist das ein Problem.
Also ich will es nicht kleinreden, aber viele Sachen sind eben auch heute schon
in diese Richtung möglich.
Genau, und das lässt sich eben über Extensions sehr, sehr gut realisieren,
dass du damit eben sagst, ich habe diesen Anwendungsfall,
wir sind, keine Ahnung, ich lerne gerade Französisch und die meisten Artikel
auf einer französischen Webseite sind mir zu kompliziert.
LLM, guck dir das doch mal an und mach da eine einfachere Version draus.
Also das wäre zum Beispiel eine sehr kreative, würde ich sagen,
Anwendung, wo du eben sagst, das ist keine Übersetzung, das ist ja tatsächlich,
nah am Text original noch, aber es ist halt auch eine Sache,
wo du wirklich AI dafür brauchst,
die dir dann eben hilft, das auf einfaches Französisch runterzubrechen.
Und auch wichtig finde ich immer das Thema, was sollte dann tatsächlich auf
dem Client laufen und wo kann ich das Ganze auf dem Server einmal machen?
AI hat natürlich einen Energiebedarf, den, ja, unterschätzen viele,
aber er ist da und exponentielles Wachstum, was Datacenters angeht und hier,
wir hoffen auf Fusionsenergie und jada, jada.
Also ich bin auch immer jemand, der sagt so, viele Sachen, die die Leute jetzt
vielleicht sagen, okay, machen wir auf dem Client, kein Problem.
Wäre viel, viel besser, man würde das dann einmal auf dem Server machen für alle.
Anstelle dann für jeden einzelnen Benutzer den Planeten zu verbrennen,
macht man es eben ein einziges Mal nur und hat dann hoffentlich am Ende einen
netto positiven Effekt trotzdem noch geschaffen und hat AI dann für gute,
positive Zwerge verwendet.
Und am Ende dann hast du diesen Anwendungsfall, wo du halt sagst,
okay, das ist jetzt aber was, das geht nicht auf dem Server.
Das möchte ich lokal tatsächlich ganz bewusst machen.
Hier dieser Psychologie- oder Psychologe-Fall, den wir vorher hatten,
zum Beispiel, das wäre ein gutes Beispiel dafür.
Oder halt, ja, die App kennt jetzt nicht dein Französisch-Level,
du hast dann quasi so einen Slider, mach mir das noch einfacher und noch einfacher
und noch einfacher und irgendwann kannst du es dann lesen.
Und natürlich könntest du das auf dem Server auch machen, aber netto ist es
dann wahrscheinlich besser für den Planeten, wenn du das auf einem kleineren
LLM machst, als dann irgendwo über ein riesiges Data Center zu gehen.
Und ja, also ich denke, da sollte man dann auch immer so ein bisschen nochmal darauf achten,
wenn die Ausgabe für alle Benutzer auf dem Planeten die gleiche ist,
mache ich es lieber auf dem Server, wenn es individuell für jeden unterschiedlich
ist oder wenn ich eben die Privatsphäre-Geschichte brauche oder ich die Offline-Fähigkeit brauche,
dann mache ich es auf dem Client.
Also ich denke, in diese Richtung sollte man auch immer sehr,
sehr kritisch dann nochmal nachfragen.
Nur weil es uns jetzt vielleicht die 2 Cent Chat-GPT-Gebühr spart,
die ich für den für die Übersetzung auf dem Server zahlen müsste,
heißt das nicht, dass es Besser ist dann,
das auszulagern auf jeden Benutzer, der die Seite auf was auch immer auf Französisch sehen möchte.
Ich habe gerade so den Gedanken, dass vielleicht eure APIs, die ihr da anbietet,
so leicht und einfach zu bedienen sind und vielleicht die Kommunikation mit ChatGPT und Co.
Oder vielleicht auch die Kosten oder die Token Limits, die man hat.
Eben also einen dann eher so dazu verleiten, das Ganze immer bei seinen Besuchern,
im Client, irgendwelche Aufgaben durchführen zu lassen, weil es halt einfach leichter gemacht ist.
Ja, also letztendlich die Preise sind deutlich gefallen. Also wenn man jetzt
anguckt, so die Context-Windows mit einer Million Token und so weiter,
also da hat sich schon sehr, sehr viel getan.
Aber natürlich der Kostenaspekt finanziell ist der eine, der Kostenaspekt Umwelt
und Klima ist der andere.
Also trotzdem wäre ich da immer sehr, sehr vorsichtig.
Ich denke, so am Ende hat man auch immer so Zwischenfälle, also über das Thema
Hybrid haben wir noch gar nicht wirklich geredet,
dass man eben verschiedene Anwendungsfälle hat, wo man sagt,
ich möchte das jetzt am liebsten in der Cloud vielleicht ausführen,
aber wenn der Benutzer gerade offline ist, dann mache ich es vielleicht doch
mal kleinseitig oder genau andersrum, per Default kleinseitig.
Und wenn das Gerät gerade nicht in der Lage ist, zum Beispiel ist im Battery-Saver-Mode
oder so, dann lagere ich das dann eben doch ausnahmsweise auf die Cloud aus.
Also ich denke, da in diese Richtung gibt es sehr, sehr viel dann auch noch
zu einfach lernen und forschen, in welche Richtung geht da das Thema.
Also bisher ist Hybrid immer relativ stupide.
Das Gerät unterstützt das nicht, ja oder nein. Oder unterstützt das ja oder nein.
Und dann heißt es eben, okay, man weicht auf die Cloud aus. Aber ja,
in Zukunft denke ich auch, man wird so verschiedene Zwischenfälle auch noch
sehen, wo sich eben das Gerät auch ändern kann, wo man dann guckt so und da
kommt wieder Fugo mit rein.
Zum Beispiel, wir haben die Compute Pressure API, die dann eben merkt,
wie ist gerade die Prozessorauslastung prozentual und wenn du eben parallel
gerade ein Video encodierst über was auch immer und dann lokal nicht so viel
Power gerade zur Verfügung steht wie normalerweise.
Dann könntest du eben auch dynamisch sagen, wir lagern das auf den Server aus.
Wie ist das denn generell, also die, wie löst ihr denn das Problem,
dass, du hast ja gesagt, auf Android-Geräten könnt ihr das ja noch nicht machen,
einfach weil die so divers sind und eben manche genug Power haben,
manche aber super underpowered sind.
Wenn ich dann so ein API benutzen will, das heißt, müsste ich dann erstmal Feature
testen, ob die zur Verfügung steht und dann,
also das dann wahrscheinlich irgendwie bei der Translator API,
zum Beispiel kann ich auf window.translator testen oder sowas und wenn das eben
nicht da ist, dann muss ich eben meinen Fallback in die Cloud machen oder eben
sagen so, geht halt gar nicht, geht hier nicht.
Genau, also es gibt Feature-Tests ganz einfach auf diese Art und Weise.
If, was auch immer du verwenden möchtest, Translator, Summarizer in Window oder
in Self, kannst du ein bisschen Zeichen sparen, dann geht das eben auf diese Art und Weise.
Dann gibt es aber auch das Dynamische, also zum Beispiel braucht das LLM natürlich
auch Festplatte, lokal und das kann sich ändern.
Das heißt, du kannst einen Rechner haben, der grundsätzlich mächtig genug ist,
aber dann hast du dein Video transkodiert und auf einmal sind eben 100 Gigabyte
weg und dann wird es ein bisschen enger auf der Festplatte und dann kann sie
eben spontan auch dynamisch ändern,
dass das Modell dann eben gelöscht werden muss, um Platz zu machen,
also klassische Cash Eviction sozusagen,
um dann Platz zu machen für andere Festplatte.
Nötigere Anwendungsdateien oder was auch immer auf dem Rechner und dann hast
du eben als Stufe 1 reguläre Feature Detection,
also if blah in self oder in window und dann im nächsten Schritt testest du
auch immer die Availability also da hast du dann translator.availability zum
Beispiel und dann sagst du,
English to German als Source und als Target Language und dann gibt es immer
vier verschiedene Möglichkeiten Das erste ist der Happy-Fall, also Available.
Du kannst die API direkt verwenden, alles ist runtergeladen, alles ist fertig.
Dann gibt es den Unhappy-Fall, Unavailable, also sprich zum Beispiel,
du verwendest eine Sprachkombination, die eben derzeit noch nicht unterstützt
wird oder die Festplatte hat nicht genug Kapazität, um das Modell dann tatsächlich zu speichern.
Und dann gibt es die zwei Zwischenfälle, Downloadable und Downloading.
Also Downloadable heißt, okay, ich kann das, der Rechner ist mächtig genug,
mir fehlt aber noch das Modell.
Und wenn du dann im nächsten Schritt sagst, okay, ich möchte meinen Translator
oder meinen Language-Modell oder was auch immer erstellen,
also dann rufst du Create auf und in dem Moment wird dann eben die Availability
umspringen zu Downloading,
wenn es vorher Downloadable war.
Und ja, dann kriegst du so ein Progress, Download-Progress-Event,
wo du dann schöne UI anzeigen kannst für den Benutzer. Okay,
das Modell wird gerade runtergeladen.
Und ja, das ist auch ein weiteres Thema, das hatten wir noch gar nicht angesprochen.
Wenn du deine eigenen Modelle runterlädst im Browser, über Transformers.js dann laufen lässt oder so,
dann ist für jeden Origin, selbst wenn genau das gleiche Modell verwendet wird,
aber der Origin verschieden ist, musst du das Modell nochmal neu runterladen
und nochmal neu auf der Festplatte redundant speichern.
Und das ist eben auch ein großer Vorteil hiervon, dass wir das Modell dann eben einmalig runterladen.
Also es heißt Build-in-AI, aber das Modell wird trotzdem dynamisch nachgeladen,
erst beim allerersten Mal, wo jemand versucht, diese APIs zu verwenden.
Aber wenn das Modell dann da ist, dann ist es verfügbar für alle Origins.
Also sprich, du brauchst dann nichts mehr runterladen.
Je populärer diese APIs dann werden, umso höher die Wahrscheinlichkeit,
dass das Modell dann einfach schon da ist.
Und genau, also in diese Richtung geht das dann eben, dass du sagst, okay,
ich habe jetzt mein Wald- und Wies-Modell, der mit der NaNo,
das eben mächtig genug ist für meine 80 Prozent der Anwendungsfälle und das
ist dann eben frei verfügbar für alle Origins. Mhm.
Du hast ja gesagt, das ist so vier Gigabyte groß. Da musst du wahrscheinlich
auch noch so ein bisschen bis dann nochmal gucken.
Da habt ihr ja im Chrome-Browser auch noch den Connection-Type, diese API.
Wahrscheinlich, je nachdem, wie man angebunden ist, ist es vielleicht dann auch
keine gute Idee, das gerade runterzuladen.
Genau, also da kommt auch dann der Browser ins Spiel. Da hilft dir da sehr, sehr viel in puncto.
Er weiß zum Beispiel auf Betriebssystemebene, ist das Netzwerk gerade mietet oder unmietet.
Also sprich, bist jetzt auf einem Android-Gerät getethered, dann sagt die Network-Connection-API
oder Network-Information-API, du hast volle WLAN-Geschwindigkeit,
was auch immer, also Full 4G, glaube ich, heißt das.
Aber letztendlich auf Betriebssystem-Ebene weiß das Gerät dann eben oftmals,
okay, das ist tatsächlich nur ein Android-Gerät und das hat dann vielleicht
ein Datenlimit von 10 Gigabyte und ist dann vielleicht keine gute Idee,
das runterzureden, selbst wenn
vielleicht gerade spontan 5G da ist und es technisch ginge, aber halt,
genau, unmietet sollte das Netzwerk dann schon sein.
Und das weiß der Browser auf Betriebssystem-Ebene, das ist dann eben nicht exponiert
in die JavaScript-Welt.
Der Browser kümmert sich auch darum, dass der Download, wenn der unterbrochen
wurde, fortgesetzt wird.
Also sprich, wenn du dann zwischendrin den Rechner neu bootest,
dann wird der Download einfach fortgesetzt.
Der Browser kümmert sich um Versionierung. Also sprich, wenn jetzt irgendwann
mal eine neue Gemini Nano Version in Chrome zum Beispiel rauskommt oder 5.4, was auch immer in Edge,
dann wird der Browser im Hintergrund das neue Modell laden und dann eben transparent
einfach irgendwann umswappen auf die nächste Version.
Das haben wir und was haben wir noch an Vorteilen?
Ja, ich glaube, das war's. Also alles Dinge, wo du dich dann eben nicht drum
kümmern musst, wo du aber, wenn du das von Hand strickst,
ja, sehr viele Fragen beantworten musst und dann einfach vielleicht als regulärer
Anwender überfordert bist und du nicht weißt, was mache ich denn jetzt hier?
Naja, das ist schon kein unkomplizierter Flow.
Okay, und geschippt habt ihr momentan, wenn ich das hier richtig lese,
die Translator-API, die ist in Chrome Stable, ne?
Genau, ab 138, auch 138, genau. Das ist der aktuelle, glaube ich,
ne? Der aktuelle Stable.
Summarizer-API ist auch drin. Genau, ja. Und genau, dann habt ihr noch,
habt ihr eine Reihe APIs, die unter dem Origin-Trial...
Genau, eine hast du noch vergessen, die Prompt-API für Extensions,
also wirklich nur Reihe Extensions.
Stimmt. Nicht reguläre Web-API, aber als Extension-API ist das auch schon in
138 verfügbar. Ah ja, okay.
Genau, und die anderen, also Writer, Rewriter und Prompt API im Browser selbst,
nicht in den Extensions, die sind aus Origin-Trials derzeit am Start.
Das heißt also, man registriert sich bei euch auf der Origin-Trial-Seite mit
seinem Origin und sagt so, hey, ich möchte die API jetzt mit meinen BenutzerInnen testen.
Genau, und das dann funktioniert.
Ihr dealt dann sozusagen so, hier ist okay, kriegst jetzt sechs Wochen lang
die API oder was weiß ich wie lange und dafür musst du uns aber eben alle so
und so viele Wochen mal Feedback geben dazu.
So läuft das ja, glaube ich. Genau, also müssen muss man gar nichts,
man sollte, man wird eingeladen, aber es ist kein Zwang, genau.
Aber es hilft natürlich dann zu wissen, ist die API so, wie sie derzeit implementiert
ist, nützlich oder nicht?
Und die Idee von Origin Trials ist ja immer noch, dass man nochmal korrigieren
kann, also sprich, weil man merkt so,
diese Parameter, der verwirrt die meisten, wenn sie entwickeln,
da sollte man dann vielleicht, keine Ahnung, den Parameter umbenennen,
sodass er weniger verwirrend ist oder was auch immer.
Da ist dann eben genau noch die Möglichkeit das zu machen vor das Ganze dann shippt,
weil wenn wir einmal shippen dann ist natürlich mehr oder weniger das Kind aus
dem Bad oder wie auch immer die deutsche Redewendung heißt, also da das Kind
hat im Grunde gefallen glaube ich, genau, so rum,
es gibt auch was mit Bad ja, das ist dann immer glaube ich, wenn man so übers
Ziel hinausschießt, dann hat man glaube ich das Kind mit dem Bade ausgeschüttet
das gibt es ja auch noch, genau Dann merkt man einfach, wer bei einer Zeitung
arbeitet und wer in einem Browser arbeitet.
Bei einer Zeitung arbeite ich ja gar nicht mehr, ich merke es seit längerem.
Oha, oha. Oh, das wusste ich gar nicht. Nee, nee, doch. Na gut.
Ich bin weitergezogen. Ah, okay.
Ja, genau. Ich bin auf dem LLM-Stand von 2018 oder so. Genau.
Wäre es denn jetzt aber theoretisch möglich, dass ich als App- oder halt Webseitenentwicklerin
die AI auf einem Client von Usern verwende für meine eigenen Zwecke,
ohne dass jetzt quasi der User-Input überhaupt notwendig ist.
Also ist die Frage letztendlich, ob du die Rechenkapazität auslagern kannst
auf deinen Benutzer, ja, das wäre theoretisch möglich.
Vanessa, das ist… Nee, ich muss jetzt hier schon mal die Sicherheitsfragen stellen.
Ja, aber sehr schlau, ich sehe ein neues Business-Modell bei dir.
Ich sage jetzt auch nicht, dass… Also das ist natürlich als Anwendungsfall…
Falls ich da meine Bitcoins minen möchte.
Naja, das könntest du machen. Die Use Cases sind natürlich äußerst gering und
wahrscheinlich ist es auch alles nicht sinnvoll.
Aber ich könnte ja vermutlich mir beliebig viel Text übersetzen lassen,
während die User einfach dann auf der Webseite sind und ich rufe einfach die
Translator-API auf mit irgendwelchen Texten, die ich da umherpinge.
Genau, das könntest du aber wahrscheinlich deutlich effektiver machen,
indem du das über einen lokalen Puppetieren-Diascript hast, als das über deine
Benutzer laufen zu lassen. Also es ist jetzt kein großes Risiko.
Also das ist ja alles heute schon möglich. Also du kannst heute schon dir ein
Modell runterladen und das dann auf dem Browser des Benutzers ausführen.
Also ich denke, der Sicherheitsaspekt, ja, also.
Und die Benutzer sind ja auch nicht dumm. Wenn das dann irgendwann mal jemand
merkt, dann wird das natürlich irgendwann jemand kreativ ausnutzen und dir dann
unerwartete Ergebnisse zurückschicken, in dem dann seine eigene AI gepatcht wird.
Wie, dass man im Browser der End-User dann irgendwie gerade ein Icon blinken lässt,
wenn da gerade die interne AI quasi am Arbeiten ist, so als Sicherheits-Security-Dings,
dass man sieht, oh, da blinkt was da, also sowas wie Kamera-Dings ist an,
dass ich sage, ha, aber ich will doch die Kamera gar nicht anhaben,
ich will doch die AI gerade gar nicht anhaben, aber.
Und wahrscheinlich, unwahrscheinlich, dass da ein großes Risiko ist,
höre ich da so raus, weil man theoretisch gesehen ja heute solche Sachen auch schon machen könnte.
Also wir hatten einen ähnlichen Fall, ganz kurz vielleicht, um das nochmal klarzustellen.
Bei der WakeLock API, der ermöglicht dir, dass du eben sagen kannst,
mein Rechner schläft normalerweise nach zehn Minuten ein.
Wenn du einen Wake-Log setzt, dann kannst du eben sagen, okay,
das soll jetzt nicht passieren, sondern der Rechner soll anbleiben.
Der valide Use-Case ist natürlich, was auch immer, wir sind jetzt hier auf dem
Podcast-Recording und es wäre blöd, wenn ich jetzt mittendrin meinen Rechner
einschlafen lassen würde.
Und dann nimmt man eben ein sogenanntes Wake-Log und sorgt dann eben dafür,
dass die App nicht einschläft oder man möchte keine Nachrichten verpassen, was auch immer.
Aber die Art und Weise, wie das Benutzer vor dieser API gemacht haben,
war einfach, dass man ein leises Video abspielen lässt.
Also sprich, ja, einfach quasi so den Hack, okay, der Browser schläft,
oder der Computer schläft auch nicht ein, wenn ein Video abspielt.
Und natürlich ist es super ineffizient, ein Video abzuspielen,
wenn du einfach, ja, letztendlich dem Browser direkt sagen könntest,
was du möchtest, dass der Browser tut, also sprich, wach bleiben.
Und von dem her, weil eben der andersrumme Weg nach wie vor möglich ist,
haben wir uns dann gesagt, okay, für diese Art und Weise der API-Nutzung brauchen
wir keinen Permission-Prompt oder keinen irgendwie,
hier, den Rechner sitzt gerade, wird gerade wachgehalten, weil eben der andersrumme
Weg das auch nicht hat. Und bei LLMs ist es ganz genauso.
Du kannst hier ein LLM runterladen.
Das ist jetzt vielleicht ein bisschen unpraktisch, heute das zu tun,
weil die großen oder die kleinen sind eben immer noch ziemlich groß,
wo du dann halt ein Gigabyte runterlädst.
Aber das kannst du ja auch im Browser machen. Also es gibt ja auch keine Permission
oder kein Warning oder was auch immer, das dann anzeigt, hey,
diese Webseite verbrennt gerade 100 Megabyte Daten. Von dem her...
Der Angriffsvektor in Anführungszeichen ist da, aber er ist nicht neu.
Und von dem her, weil er nicht neu ist und weil es deutlich einfacher ist,
einfach dann zu sagen, ich nehme Playwright oder ich nehme Puppetier lokal und
mache das dann eben über diese Art und Weise, ergibt einfach letztendlich keinen Sinn.
Aber natürlich, das kam auch vor, das hat zum Beispiel ein Mitarbeiter von Mozilla
gemeint in einer Diskussion so,
dass das vielleicht ein Problem wäre, dass man dann eben die Benutzer als kostenlose
Rechenpferde verwendet und
dann sein eigenes LLM aufbaut, das dann über Geld verkauft wird oder so.
Also, aber ja, trojanisches Pferd oder nicht trojanisches Pferd,
also ein Botnet quasi sich aufbaut.
Aber ja, geht deutlich einfacher, muss man nicht andere Benutzer verwenden.
Was mir ansonsten, total anderes Thema, was mir ansonsten zurzeit auffällt,
das hat jetzt auch gar nichts spezifisch jetzt mit den APIs hier zu tun.
Ich würde jetzt mal sagen, wir sind als User von AIs jetzt relativ stark mit
dem Thema befasst, kennen uns da aus.
Es ist vermutlich nicht überall so oder bei jedem so.
Und wir haben jetzt gestartet mit AIs, indem ich auf Chat-GPT gehe und da habe ich meinen Chat.
Dann ist es auf Google aufgepoppt, dass da die ziemlich guten Zusammenfassungen
kommen, sodass ich da quasi gar nicht mehr auf die Links klicken muss und die
Antwort steht schon oben drin.
Und wahrscheinlich hat Amazon auch schon was, keine Ahnung. Dann gibt es jetzt
ganz viele, wie du vorhin meintest, jeder muss jetzt irgendwie die AI einbauen,
ganz viele Webseiten, die AI-Features einbauen, die dann wiederum mit GPT, OpenAI, Cloud.
Lama, was weiß ich was reden.
Und dann kommt jetzt vielleicht noch so was Neues dazu, dass man jetzt auch
die in den Browsern zur Verfügung hat. Ich finde es ein bisschen komisch,
Im Moment baut sich da so ein Wald auf, dass die AI von überall so ein bisschen reinpoppt.
Ich sehe hier jetzt nicht so das Gesamtkonzept. Das Gesamtkonzept sehe ich noch
nicht mal auf einzelnen Webseiten, weil da ist es auch so,
hier ist der Chatbot und hier ist ein Button, der fasst dir das zusammen und
wenn du hier auf die Text-Area klickst, dann kannst du deinen Text verlängern lassen.
Schon auf so einer Webseite ist das Gesamtkonzept ja so ein bisschen schwierig.
Mein größtes Problem ist also jetzt gar nicht so die Testbarkeit oder was auch
immer, sondern wirklich, wie verstehen alle Usergruppen, was hier eigentlich
noch vor sich geht, mit welcher AI sie wann reden,
denn die Ergebnisse hängen ja wirklich davon ab, mit welchem Model wird für
diesen Use Case interagiert und dann, voll authentic will ich jetzt gar nicht
anfangen, das macht es ja nur noch komplizierter.
Aber auch, wie sind Prompts vorgeschrieben?
Also da können ja Zusammenfassungen, können ja irre gut sein oder irre plump.
Und ich weiß noch keine gute User Experience, wie man erklären soll,
woran das jetzt eigentlich lag, dass das jetzt gut ist oder das jetzt schlecht ist.
Und ich will jetzt nicht schon wieder irgendwelche Sachen raten,
wie das ... Wisst ihr, was ich relativ oft zu hören bekomme?
Ich bin Softwareentwicklerin seit mehr Jahren, als ich mittlerweile zählen kann.
Ich kann euch gar nicht sagen, wie oft man mich, aber trotzdem anschaut,
so im Freundeskreis, gell, wenn du am Laptop bist, das funktioniert auch nicht
so gut, wie wenn der Ben das, mein Mann, wie wenn der Ben das dann probiert,
gell, bei dem geht es dann besser. Und ich so, hä, was ist denn jetzt los?
Ja, weil das ist ja dann der Mann und dann funktioniert der Laptop immer.
Du bist so, hä, was ist jetzt los?
Aber ich sehe schon irgendwie auch sowas kommen wie,
ja, wenn ich mit der AI schreibe, dann kommt immer was Falsches raus,
aber vielleicht lag es halt einfach nur dran, dass man jetzt die Local AI verwendet
hat, die vielleicht ein bisschen schwächer ist als die Bezahlmodelle,
von 30 Dollar im Monat von sonst einem Anbieter.
So, lange Rede, Ende. Ich habe keinen Sinn. Ja, aber ich glaube,
das ist ja so, das müssen wir als Kollektiv irgendwie rausarbeiten,
was da so Best Practices sind, denke ich.
Ja, ich denke auch. Also im Moment sind wir so in der Phase,
wo einfach jeder AI auf seine Website haut, no matter what.
Und du merkst halt auch bei den ganzen Websites, die sind von verschiedenen
Teams gebastelt, die dann teilweise auch nicht miteinander reden.
Und dann hat halt der eine den Chatbot in der rechten unteren Ecke und dann,
wie du schon sagtest, das Review-Widget, das dann deinen Text länger macht oder was auch immer.
Und dann hast du ein nächstes Team, das dann merkt, oh, die ganzen Reviews,
die reinkommen, die sind alle viel zu lang.
Die Nutzer wollen eigentlich eine Zusammenfassung nur sehen.
Und dann hast du so diesen Fall, wo der Benutzer eingegeben hat drei Bullet Points.
Die AI hat das dann aufgeblasen zu einem längeren, kohärenten Text.
Und der Leser wiederum lässt sich diesen kohärenten Text wieder zusammenfassen
auf drei Bullet Points. Und individuell für jeden war AI letztendlich nützlich,
weil ich habe jetzt nicht nur peinliche drei Bullet Points eingegeben als Review.
Ich habe als Leser mir diese langen Texte gespart zu lesen und so weiter und
vielleicht am Ende mit dem Chatbox sogar eine sinnvolle Interaktion gehabt.
Aber ich denke, AI ist am besten, wenn man sie gar nicht mehr merkt.
Also auch da wieder so ein bisschen der Bogen zu Project Fugu,
Progressive Web App und so weiter.
Das gab ja so in den 2015er, 16er Jahren so immer diese sehr dogmatisch geführten Diskussionen.
Ist das jetzt eine Progressive Web App oder ist das nur eine Web App oder ist
das nur eine Website oder ist das nur eine Page oder ist das eine PWA,
wenn sie nicht installiert ist oder wenn sie nicht installierbar ist?
Und ich denke, diese ganzen Diskussionen, das kommt heute gar nicht mehr so
vor, weil letztendlich es spielt keine große Rolle. Und bei Ajax hatten wir das Gleiche so.
Irgendwann haben alle Ajax gemacht und es war auf einmal so natürlich,
dass gar keiner mehr auf die Idee kam, so Powered by Ajax-Banner auf seiner
Website zu setzen oder so.
Und heute machen wir alle diese AI-Diamanten und Sparkles und was auch immer.
Und ich denke, irgendwann wird das einfach...
Was Mist ist, wird sich einfach irgendwo verlieren und was tatsächlich nützlich war,
also das wird einfach bleiben und dann zu so normal quasi Standardfeatures zählen,
dass man es quasi einfach nicht mehr wählen muss.
Und ich denke, wir sind gerade ganz, ganz am Anfang.
Also ich hatte beim Vorgepränkel erzählt, ich bin heute etwas unerwartet in
einem Hotel in Barcelona gelandet und musste das buchen und war auf einer großen
Seite und die hatte auch ein AI-Feature.
Und dann dachte ich, naja, teste ich das doch mal.
Also so typische, klassische hunderte Filter und dann auch nur ein einziges
großes Feld, wo du einfach sagen kannst, was möchtest du denn?
Und die Idee war, man schreibt dann einfach in diesen Smart Filter mit Sparkles
dekoriert natürlich, schreibt mal rein, was man möchte.
Und ich habe ihm dann einfach gesagt, no matter what,
ich bin preissensitiv, ich bezahle das selbst, aber ich möchte bitte keine Dorms
vorgeschlagen bekommen, also so keine Schlafzimmer, Schlafräume und das war einfach zu viel dann.
Also es war so für mich komplett klar, filtert doch einfach aus,
ihr habt doch den, ihr featuret das sogar auf dem Listing, so Bed in One Room
oder Eight Room Dormitory, bla bla.
Das hat man früher gemacht, das muss ich in meinem Alter nicht mehr,
aber wenn man halt nach Preis sortiert, dann kommen eben diese ganzen Dorms
als erste Position und so ganz simple Sachen und da denke ich wirklich so,
Alter, wenn ihr dafür AI braucht, dann weiß ich auch nicht. Also ich denke so in Richtung.
Was misst jetzt, das wird sich durchsetzen und wenn das dann vielleicht irgendwann
mal tatsächlich mappt auf die Filter, einfach das Ganze besser abgebildet wird,
dann ist das vielleicht wirklich ein gutes Feature.
Also ich habe auch keine Lust, mir hier 100 Filter durchzuklicken,
so 24 Stunden Rezeption ja, aber eigenes Badezimmer nein oder keine Ahnung,
ja doch, eigenes Badezimmer schon ja, aber keine Ahnung, Pool muss jetzt nicht
sein für die eine Nacht hier, wo ich bin.
Also so, wo man einfach sagt, okay, das ist ein Interface, das ist gemacht für
eine Datenbank, aber nicht für einen Menschen.
Wenn da ich AI verwenden kann, um dann einfach zu sagen, ich bin preissensitiv,
mir ist jetzt Location zu einem bestimmten Ort wichtiger als was auch immer,
super Hotelkomfort oder was auch immer.
Aber ja, da sind wir noch, glaube ich, ziemlich am Anfang.
Also es hat nicht geklappt? Es hat in dem Fall nicht geklappt.
Es war tatsächlich sogar, wenn ich nicht wissen würde, was dahinter steckt,
so ein bisschen Bremscham dabei, muss man schon sagen.
Das geht doch deutlich besser. Was macht ihr denn da?
Ich möchte den Anliegen jetzt nicht hier bloßstellen, aber nein.
Eine große Hotelbuchungsplattform.
Mysteriös, wer das wohl ist? ja, naja gut, das ist dann vielleicht so ein wir
müssen AI schnell vor die Tür kriegen Ding, ja,
ist halt gehypt und wie du sagst, das wird sich alles irgendwann einpendeln
und dann so wie in der Anfangszeit von diesen ganzen Computereffekten in Filmen,
dann musste irgendwie alles mal zerstört werden und alles mal sinken oder in
die Luft gesprengt werden und jetzt wird das alles einfach sozusagen mit Bedacht
im Sinne des Storytellings einfach eingesetzt und oft sieht man es auch gar nicht mehr.
Genau, und so, das hoffen wir natürlich auch. Und dann ist das ja auch mit den
ganzen Ressourcen, die da verbraten werden, dann pegelt sich das auch vielleicht
irgendwo wieder ein, wo man einfach nicht so ein schlechtes Gewissen haben muss.
Cool. Ich nehme an, ihr plant wahrscheinlich darüber hinaus noch so,
da wird noch irgendwie was kommen.
Wie ist so generell die Tendenz bei den anderen Anbietern? Also jetzt ist das
ja so ein bisschen so ein, sagen wir mal, Chrome- oder Chromium-Familien-Ding.
Hast du da zumindest ein Gefühl für, wie das insgesamt bei den anderen Herstellern ankommt?
Oder bleibt es vielleicht so ein bisschen wie bei WebUSB und WebBluetooth,
vielleicht so ein bisschen mehr so ein Chromium-Ding, was man lange Zeit nicht bei den anderen sieht?
Also ich denke, es wird so eine gestufte oder abgestufte Rollout-Phase geben.
Zum Beispiel Mozilla, die waren sehr offen, was jetzt das Thema Translation angeht.
Die haben dann allerdings einen alternativen API-Vorschlag gebracht.
So DOM-basiert fand ich jetzt, ja, könnte man als Prolifil dann sogar umsetzen
mit der API, die wir in Chrome haben.
Aber es war einfach für die Einwendungsfälle, die wir gemerkt haben,
dass die Benutzer umgesetzt haben wollen, war es einfach nicht genug.
Also sprich, deren Vorschlag, ich denke, ja,
das hoffentlich wird sich das über den Benutzer, über den Benutzernachfrage
dann am Ende einfach in Staub auflösen und sie werden sagen, okay, das ist eine API,
die ergibt einfach imperativ Sinn, wir brauchen da keine deklarative, keine Ahnung,
macht da an diesen DOM-Note ein Attribut hin oder so.
Also ich denke in diese Richtung hoffe ich, kann man über Benutzern nachfragen,
da hat es wirklich APIs, die letztendlich ziemlich ähm,
Ja, unumstritten sind sozusagen, dass man da auf diese Art über Nachfrage und
Angebot einfach dann über gesteigerte Nachfrage das Angebot an APIs steigert.
Das Gute ist, also von der Funktion ist ja alles polyfillbar oder über Hybrid-Anwendungen.
Also wir haben zum Beispiel auch über das Firebase, es heißt Firebase AI-Logic
von Firebase eine Lösung, die dann eben über Hybrid das Ganze abdeckt.
Mit dem großen Unterschied natürlich, man kann Privatsphäre nicht über die Cloud garantieren.
Also wenn du halt den Server brauchst, dann ist Privatsphäre eben kein Selling
Point mehr, den du vorbringen kannst.
Aber genau, also nochmal zurück zum Thema.
Ich denke so, was die APIs angeht, die relativ unumstritten sind,
ich hoffe, über Nachfrage können wir dann einfach das Angebot letztendlich bei
den anderen Browser-Windowen steigern.
Da kommen dann natürlich Firmenentwickler, Partner mit ins Spiel,
die dann eben sagen, hier, wir sind große Firma XY und das ist der Anwendungsfall, den wir haben.
Liebe Mozilla, liebe Apple, setz das doch mal um, weil wir würden ungern unseren
Benuttern sagen, this page is best viewed in Chrome.
Genau, also in diese Richtung, dass es dann eben so geht.
Bei der Prompt-API weiß ich noch nicht, was da passieren wird.
Also ich denke, das wird für eine längere Periode vermutlich mal eine Chrome-only-API
bleiben oder Chrome-slash-Edge-API bleiben.
Mal gucken, was die anderen machen, aber...
Wenn man AI braucht, dann kann man das ja nach wie vor über den Server mit,
wie gesagt, diesen Privacy-Offline-Abstrichen trotzdem noch realisieren.
Also ich denke, es ist keine Katastrophe, wenn das dann eine Zeit lang Chrome-Edge-only
bleibt. Und bei WebUSB und so weiter, da ist natürlich das, ja,
wenn die APIs nicht existieren, da gibt es keine Möglichkeit,
das zu prolifillen oder so.
Genau, aber ich denke so, je unumschrittener die APIs, desto eher werden sie
landen und Leute, Hörer, Hörerinnen, die jetzt hier dabei sind und sagen,
großartige Sache, macht euch Gehör bei den ganzen Browser-Vendoren.
Also schreibt auf die Bugs, schreibt auf die Diskussionen, die gestartet werden
in puncto Standardisierungsversuche,
schreibt da tatsächlich auch, hey, wir sind große Firma oder kleine Firma oder
was auch immer, Indie-Developer und wir wollen das und das nutzen und können
das nicht, weil die API ist nicht verfügbar.
Also ich denke, das hilft auch immer.
Man unterschätzt dann immer auch so ein bisschen die Netzwerkeffekte,
die man dadurch haben kann,
weil jeder sieht sich als kleinen Entwickler oder kleine Firma,
aber letztendlich viele sind Consultant und können da vielleicht als eine Person
100 große Firmen ansprechen oder nicht 100, aber 50 oder keine Ahnung,
20 oder vielleicht auch nur 5, wenn die dann sehr, sehr wichtig sind.
Also ich denke, in diese Richtung unterschätzt man da den eigenen Hebel,
den man hat auch auf so viele Diskussionen immer ein bisschen.
Ich wollte noch die quasi letzte Sache, die ich noch fragen wollte.
Ich habe mal nachgeschaut und es gibt keine W3C-Specs für diese APIs.
Ist das noch in Planung oder wie sieht es da aus?
Also das ist ja wahrscheinlich auch Voraussetzung dafür, dass alle Browser-Vendoren
irgendwie zusammen an was werkeln und die Testscheiben, über die wir auch gesprochen haben.
Genau, also wir verfolgen da den Blink-Shipping-Prozess. Das startet typischerweise
mit einem Explainer, also so ein relativ formloses Dokument,
wo man einfach sich mal überlegt, was ist das Problem und wie könnte das Problem
möglicherweise gelöst werden.
Wir haben dann ein Repo, das nennt sich Explainers by Googlers,
wo man als Google-Mitarbeiter sich dann einfach mehr oder weniger so ein Repo
unter diesem Namespace residieren kann und dann sagen kann, das ist meine Idee, das möchten wir haben.
Der nächste Schritt ist dann von dort aus, dass man über die Web Incubator Community Group, also WICG,
als nächsten Schritt dann geht und sagt, hier, wir haben eine gewisse Nachfrage
nach dieser Idee gesehen und wir wollen das ein bisschen weiter vorantreiben
und würden das gerne in der WICG dann starten.
Parallel kann es dann sein, es gibt eine Community Group, also im konkreten
Fall gerade arbeiten wir mit der Web Machine Learning Community Group beim B3C,
die sind noch nicht standardbefugt, aber es ist immerhin schon direkt im B3C,
auch mit anderen Vendoren.
Und dann irgendwann, wenn im nächsten Schritt sich abzeichnet,
okay, es gibt verschiedene Implementierungen, also nicht nur eine,
sondern von verschiedenen Browser Engines,
dann kann das Ganze in eine Working Group migriert werden, also Also sprich,
dann kann es zum echten Webstandard werden,
wenn dann eben verschiedene Vendoren und ja, tatsächlich auch Engine-Hersteller
implementieren und dann sagen, okay, wir migrieren jetzt von der Community Group
oder von der WICG rüber in eine echte W3C Working Group.
Und parallel natürlich kann jeder Browser machen, was er möchte und jeder kann
APIs shippen, also man ist dann nicht auf quasi Erlaubnis von den anderen Vendoren angewiesen,
es ist natürlich immer schön, wenn man.
Gemeinsame Schritte gehen kann, aber teilweise macht dann jeder Vendor so ein
bisschen seine eigene Geschichte und sagt dann, okay,
für uns ist gerade das Thema AI wichtig und Und wir sehen da große Nachfrage
bei unseren Google-Chrome-Partnern.
Und dann kann man auch sagen, okay, man shippt unilateral, ohne jetzt auf die
anderen zwingend zu warten.
Aber, und das ist bei uns sehr, sehr wichtig, es muss immer der Dialog da sein
im Sinne von, wir müssen den Dialog gestartet haben.
Und dafür gibt es die Repositories von Mozilla und von Apple oder von WebKit
vielmehr, die WebKit-Standards-Positions und die Mozilla-Standards-Positions.
Und da haben wir auch ganz klar gesagt, okay, wir haben diese APIs in Arbeit und.
Was denkt ihr dann dazu? Was ist da eure Meinung? Also jeder,
der sich für das Thema interessiert, kann einfach den API-Namen suchen.
Am besten geht es über chromestatus.com und sucht dann Writer-API zum Beispiel
und dann findet man auch die ganzen Links auf die verschiedenen Repositories,
wo dann eben die Webcat Standards Position nachzulesen ist.
Sondern kann man eben auch als Layperson sich das mal anschauen und dann sagen,
okay, wir sind jetzt vielleicht, keine Ahnung, Adobe und für uns ist das Thema
AI ein großes Thema und AI mit Bildern zum Beispiel.
Also ich sage jetzt nicht, dass Adobe tatsächlich konkret da schon innoviert
ist, aber mit Adobe haben wir zum Beispiel historisch zusammengearbeitet in puncto Photoshop.
Und da war eben genau das der Hebel dann, dass Photoshop gesagt hat oder Adobe
gesagt hat, hier, wir wollen Photoshop ins Web bringen und dafür brauchen wir die und die API.
Also im konkreten Fall war es das Origin Private File System.
Und ja, das ist eben für uns zwingend und entweder Mozilla und Apple,
ihr implementiert das oder naja, die App kann eben auf eurem Browser nicht laufen.
Und ja, das hat dann am Ende gewirkt und ja, über diesen Hebeleffekt quasi,
dass ein großer Partner wie Adobe nachgefragt hat, ging das dann eben.
Aber ja, man muss dafür kein großer Partner sein. Jeder, das alles funktioniert über GitHub,
jeder kann die Meinung auf ein Issue dazuschreiben und dann sagen,
okay, wir sind jetzt ein Mittelständler in Deutschland und wir hätten gerne
das für unsere Hunderten von Partnern oder Kunden oder was auch immer.
Und das ist genau der Anwendungsfall, den wir umsetzen wollen.
Und genau, also das ist schon wirklich, würde ich sagen, ziemlich offen für alle.
Natürlich sollte man nicht spammen, aber wenn man jetzt wirklich einen validen
Meinungspunkt noch dazugeben möchte, auf jeden Fall.
Genau, und ansonsten gilt, APIs mal erforschen, angucken, vielleicht auch für
die ein oder andere Origin-Trial anmelden, wenn man neugierig ist.
Ich meine, man kann das ja immer lokal alles testen ohne Origin-Trial,
da kann man ja einfach dann in Chrome Flex dann die entsprechenden Sachen freischalten.
Aber wenn man das jetzt mit seinen BesucherInnen zusammen testen will die kann
man ja jetzt nicht immer auffordern in Chrome Flex diese Flex zu setzen genau
in dem Fall dann macht man es über die Origin Trial und euch dann irgendwie Feedback geben,
ob das irgendwie nützlich ist,
ob die gut benutzbar ist oder ob es irgendwo noch klemmt damit ihr das einfach
schon mal wisst, bevor ihr dann das shippt und die Leute sie dann hinterher
sich beschweren oder so.
Genau, sehr gerne. Also auf jeden
Fall, es gibt ja immer verschiedene Probleme, in die man laufen kann.
Das eine ist, die API macht auf dem Papier, was sie soll, aber in der Implementierung
macht sie das eben nicht.
Dann neuen Chrome-Bug aufmachen, also es gibt die praktische URL new.crbug.com,
die dann eben einen direkt auf den richtigen Ort führt.
Das ist für Implementierungs-Bugs. Und dann gibt es aber auch natürlich so Fälle,
wo man sagt, okay, ich habe jetzt dieses Problem, die API geht vielleicht in
die richtige Richtung, aber mir fehlt da noch, sagen wir, ein Parameter dafür, dann eben sagt, okay.
Ich möchte, was auch immer, anstelle von Markdown und Plaintext möchte ich auch
HTML zurückbekommen, aber das ist derzeit nicht möglich.
Dann macht man auf dem Repository von dem Spec-Draft, macht man dann eben ein
Issue auf und sagt, so, hier, ich hätte gerne diesen Ausgabeparameter,
dass der noch HTML unterstützt als,
Primitives Beispiel. Und genau, in diese Richtung kann man dann auf jeden Fall gehen.
Und wir freuen uns auch immer, wenn die Leute einfach Demos teilen.
Wir haben, das nennen wir das Early Preview Program.
Ist auch verlinkt auf der developer.com.com Website.
Ich glaube, docs slash builtin und dann erscheint es irgendwo auf der linken Seite.
Early Preview Program, wo man sich einschreiben kann und dann eben mit zu den
ersten gehört, die über neue API-Entwicklungen hört und dann eben auch sehr, sehr früh testen kann.
Also da herzliche Einladung, nehmt da teil.
Und dann letztendlich das FRL-Team, meine Kolleginnen und Kollegen,
wir sind alle auf verschiedenen sozialen Netzwerken verfügbar,
also schreibt uns auch gerne direkt an, teilt eure Demos mit uns.
Ich bin auch immer jemand, der dann gerne auch die Sachen intern weiterleitet
und sagt so, hey, schaut mal.
Ihr Ingenieure bastelt dann nicht nur einfach so vor euch hin,
sondern andere Leute extern bauen da drauf tatsächlich ihre vielleicht neuen
Geschäftsideen auf und hier, schaut euch das doch einfach mal an.
Also ich bin jemand, der gerne auch testet und checkt und schaut, was passiert.
Wir werden auf jeden Fall die Kontaktwege zu dir, wenn wir alle verlinken.
Und auch zu den ganzen Seiten, über die wir gesprochen haben.
Zu Chrome Status, zu dem Vorschau-Programm.
Das machen wir auf jeden Fall alles. Early Preview-Programm.
Early Preview-Programm, genau.
Und wir sind gespannt, was da rauskommt. Und ich habe auch so ein paar Gedanken gehabt.
Ich meine, die Vanessa, klar, die hat den super Use Case mit ihrem neuen Firmenimperium,
das dann KI auf den Besuchergeräten ausführt.
Soweit war ich jetzt nicht gedanklich, aber ein paar Ideen hatte ich auch.
Super, sehr cool. Ja.
Schön, dass du da warst. War wieder super interessant.
Ja, danke für die Einladung. Ja, machen wir wieder.
Bin gespannt, ob es dann auch um diese APIs sich drehen wird.
So wie wir zweimal Fugu hatten oder auch wieder, du hast ja immer so die Spezialgeschichten,
die so ein bisschen abseits des Mainstreams sind, aber die immer sehr spannend sind. Genau so.
Ich bin auf jeden Fall jemand, der gerne dahin geht, wo es möglicherweise wehtut.
Also im Sinne von Bleeding Edge.
Das ist schon da, wo ich mich sehr wohl fühle. Ja, cool.
Vielen Dank. Liebe Grüße nach Spanien. Graças.
Danke auch an Vanessa. Viele Grüße nach Freising. Danke dir.
Und dann hören wir uns nächste Woche wieder. Also die HörerInnen hören uns.
Ich weiß gar nicht, worum es geht, aber es wird wieder was Schönes werden.
Dann macht's gut. Ciao, ciao. Tschüss.
Music.