Wenn Sie Ihren eigenen ChatGPT-ähnlichen Open-Source-Chatbot bauen möchten
(hacks.mozilla.org)- Ein kleines Team der Mozilla-Innovationsgruppe baute in einem einwöchigen Hackathon einen internen Chatbot-Prototypen und experimentierte mit einer Konfiguration, in der ein Open-Source-LLM ohne Drittanbieter-API innerhalb der Mozilla-Cloud betrieben wird
- Weil externe AI-SaaS ausgeschlossen wurden, mussten die Server direkt im GCP-Konto von Mozilla aufgebaut werden; statt Hugging Face text-generation-inference wechselte das Team zu dem schneller lauffähigen llama.cpp
- Die Modellauswahl war zunächst stärker an Lizenz- und Laufzeitkompatibilität gebunden als an Qualität; nach einer manuellen Bewertung kommerziell nutzbarer Kandidaten aus der LLaMA-Familie fiel die Wahl auf LLaMA 2
- Die Anbindung internen Wissens wurde über Embeddings und Vektorsuche umgesetzt; mit all-mpnet-base-v2, SentenceTransformers, LangChain und FAISS wurde ein Teil des Firmen-Wikis für Antworten nutzbar gemacht
- Der Prototyp wurde fertig, doch um einen vertrauenswürdigen Open-Source-Chatbot zu bauen, muss man viele Bereiche selbst beurteilen, von Hosting, Modellevaluierung und Bias über Prompts bis hin zur UI
Der interne Chatbot, den Mozilla bauen wollte
- Mozilla vertritt trustworthy-AI-Prinzipien, nach denen AI-Systeme bei den verwendeten Daten und Entscheidungen transparent sein, die Privatsphäre, Selbstbestimmung und Sicherheit der Nutzer respektieren sowie Bias verringern und Fairness erhöhen sollen
- Für viele Nutzer sind generative AI-Chatbots wie ChatGPT und Bard der wichtigste Zugang zu aktueller AI; die dominierenden Dienste werden oft von mächtigen Tech-Unternehmen betrieben und beruhen häufig auf proprietärer Technologie
- Mozilla sieht Open Source als einen Weg, Nutzer zu stärken, Transparenz zu erhöhen und zu verhindern, dass sich Technologie nur nach den Weltbildern und finanziellen Motiven einiger weniger Unternehmen entwickelt
- Das unmittelbare Ziel des Hackathons war es, einen internen Chatbot-Prototypen zu bauen, der die folgenden Bedingungen erfüllt
- Läuft vollständig auf der Mozilla-Cloud-Infrastruktur und ist nicht auf APIs oder Dienste Dritter angewiesen
- Besteht aus freien Open-Source-LLMs und -Tools
- Spiegelt das Mozilla Manifesto und die trustworthy-AI-Prinzipien wider
- Integriert etwas internes Mozilla-Wissen, damit Mitarbeiterfragen beantwortet werden können
Hosting: eigener GCP-Server statt externem SaaS
- Es gibt viele Hosting-Dienste für Machine-Learning-Apps, aber MLOps ist schwierig, und schlecht konfigurierte AI-Apps können langsam, teuer oder qualitativ schwach sein
- Ein ausdrückliches Ziel des Teams war Sicherheit und Privatsphäre, sodass keine externe Partei mithören, Nutzerdaten sammeln oder die Verwendung einsehen kann
- Deshalb wurde kein AI-SaaS-Hosting eines Drittanbieters genutzt; stattdessen richtete das Team eigene virtuelle Server im bestehenden Google Cloud Platform-Konto von Mozilla ein
- Diese Entscheidung bedeutete zwar, MLOps selbst zu übernehmen, erlaubte Mozilla aber, das System unter eigener Kontrolle und privat zu halten
Laufzeit: Wechsel von Hugging Face zu llama.cpp
- Eine LLM-App braucht eine Runtime-Engine, um Modelle auszuführen; wegen des Zeitlimits konzentrierte sich das Team auf llama.cpp und das Hugging-Face-Ökosystem
- Hugging Face bietet eine Modellbibliothek, Dokumentation, Tutorials und gehostete Inference-APIs
- Statt der gehosteten API versuchte das Team die Open-Source-Lösung text-generation-inference
- text-generation-inference unterstützt verschiedene Modelle und Modellarchitekturen und kann per Docker bereitgestellt werden, hatte beim Serverbetrieb aber große Probleme bei der Umgebungskonfiguration
- Als GPU-Beschleunigungstool musste es zur Kombination aus Server-OS, Hardware und Treibern passen
- Das NVIDIA-CUDA toolkit wurde benötigt
- Ein erheblicher Teil eines Tages ging für die Einrichtung drauf, und selbst danach war die Ausgabe langsamer als erwartet und die Ergebnisse nicht gut
- Wegen des Zeitdrucks wechselte das Team zu llama.cpp, das von Georgi Gerganov gestartet wurde
- llama.cpp macht es einfach, bestimmte LLM-Familien auf Consumer-Hardware auszuführen
- Es kann statt High-End-GPUs CPUs nutzen und führt insbesondere kleinere aktuelle Open-Source-Modelle auf Apple-Silicon-CPUs wie M1 und M2 vergleichsweise gut aus
- llama-cpp-python bietet eine Implementierung der OpenAI API specification, wodurch sich statt ChatGPT leicht ein eigenes LLM einsetzen lässt
- Am Ende lief llama.cpp schnell auf einem virtuellen Server mit AMD-Multicore-CPU, statt sich mit CUDA-Versionen und teuren Hosting-GPUs zu befassen
Modellauswahl: Lizenz- und Architekturgrenzen
- Mit der Wahl von llama.cpp beschränkten sich die nutzbaren Modelle auf Modelle auf Basis der LLaMA-Architektur
- Facebook stellte LLaMA Ende 2022 vor; LLaMA lässt sich in Modelldaten und Architektur aufteilen
- Die LLaMA-Architektur wurde als Open Source veröffentlicht, die Modelldaten, also die weights, waren jedoch nicht Open Source
- Für die Nutzung der weights musste eine Genehmigung beantragt werden, und sie war auf nichtkommerzielle Zwecke beschränkt
- LLaMA löste viele Modellinnovationen aus, etwa Alpaca von Stanford und Vicuna von LMSYS
- Da diese Modelle jedoch unter Verwendung von Facebooks weights entwickelt wurden, erbten sie die rechtlichen Beschränkungen der ursprünglichen weights
- Für kommerzielle Zwecke waren sie nicht nutzbar und schieden daher für das Mozilla-Team aus
- Weil die LLaMA-Architektur selbst Open-Source-Code ist, konnten andere Gruppen Modelle von Grund auf trainieren und unter MIT-, Apache-2.0- oder Creative-Commons-Lizenzen veröffentlichen
- Modelle auf Basis anderer Architekturen wie MPT, Falcon oder Open Assistant liefen damals nicht in llama.cpp und fielen daher weg
Bewertung von Modellqualität, Bias und Sicherheit
- Die Modellauswahl wirkt sich nicht nur auf Lizenz und Kompatibilität aus, sondern auch direkt auf Vertrauenswürdigkeit
- LLMs werden mit riesigen Datenmengen trainiert und anschließend mit zusätzlichen Eingaben feinabgestimmt, um bestimmtes Verhalten und bestimmte Ausgaben zu erzeugen
- Schon die Auswahl dieser Daten ist eine Form der Kuratierung und enthält verschiedene Biases
- Je nach Trainingsquellen zeigen Modelle unterschiedliche Eigenschaften
- Sie können unsinnige Antworten erzeugen, also halluzinieren
- Sie können toxische Inhalte, Desinformation oder die Weitergabe gefährlicher oder schädlicher Informationen begünstigen
- Sie können Bias gegenüber Konzepten oder Personengruppen zeigen
- Dass die meisten Online-Lernmaterialien auf Englisch sind, beeinflusst, wie gut sich das Tool nutzen lässt und welchen Weltbildern man begegnet
- Es gibt Ressourcen zur Bewertung von Leistung und Qualität, etwa das Open LLM leaderboard von Hugging Face, aber Modelle anhand von Herkunft und Bias zu vergleichen, bleibt weiterhin schwierig
- Das Mozilla-Team grenzte die Auswahl auf offene Modelle ein, die kommerziell nutzbar sind und auf der LLaMA-Architektur laufen, und führte dann eine manuelle Bewertung mit verschiedenen Fragen durch, um Toxizität, Bias, Desinformation und Widerstand gegen gefährliche Inhalte zu prüfen
- Die endgültige Wahl fiel auf Facebooks LLaMA 2, doch die Evaluierungsmethodik unter Zeitdruck könnte Mängel haben, und auch mit den Lizenzbedingungen fühlte man sich nicht ganz wohl, weshalb dies kaum als Empfehlung gelten kann
Integration internen Wissens: Embeddings und Vektorsuche
- Das Mozilla-Team wollte einige interne Mozilla-Daten an den Chatbot anbinden, auf die Mitarbeiter zugreifen können, die ein allgemeines LLM aber nicht kennt
- Der gewählte Ansatz war Embeddings und Vektorsuche, um externe Dokumente für die Antwortgenerierung zu nutzen
- Der grundlegende Ablauf war wie folgt
- Die zu verwendenden Daten werden aus ihrem ursprünglichen Repository geholt und in ein Embedding-Modell eingespeist
- Die Embeddings werden in einer Vektordatenbank indexiert, auf die der Chatbot zugreifen kann
- Wenn ein Nutzer eine Frage stellt, durchsucht der Chatbot die Vektordatenbank nach relevanten Inhalten
- Die gefundenen relevanten Inhalte werden in das Kontextfenster des Basismodells eingefügt und zur Antwortgenerierung verwendet
- Um die Datenkontrolle zu behalten, nutzte das Team weder einen Embedding-Dienst noch eine Vektordatenbank eines Drittanbieters
- Die selbst in Python gebaute Lösung nutzte die folgenden Tools
- Das Embedding-Modell all-mpnet-base-v2
- Die Embedding-Bibliothek SentenceTransformers
- LangChain
- Die Vektordatenbank FAISS
- Es wurden nur einige Dokumente aus dem internen Firmen-Wiki eingebunden, daher war der Umfang begrenzt, als Proof of Concept funktionierte es jedoch
Prompt Engineering und Kontextfenster
- LLMs beginnen jedes Mal, ohne sich an frühere Gespräche oder den Nutzer zu erinnern; damit ein Chatbot ein Gespräch fortsetzen kann, müssen Entwickler die Speicherverwaltung übernehmen
- Der System-Prompt ist die anfängliche Anweisung in Klartext, die die Funktionen und das Verhalten des Chatbots festlegt
- Das Mozilla-Team entwarf den System-Prompt so, dass der Chatbot dem Mozilla Manifesto, respektvollem Verhalten und Nichtdiskriminierungsrichtlinien folgt
- Bei einer Frage nach der Apollo-Mondlandungsverschwörung antwortete das Modell, dass die Mondlandung nicht gefälscht war, wenn die Anweisung enthalten war, Desinformation abzulehnen
- Entfernte man in demselben Modell die Formulierung gegen Desinformation, lieferte es eine übliche Liste von Apollo-Leugnungsargumenten
- Der System-Prompt umfasste den Namen Mozilla Assistant, die Einhaltung der Prinzipien des Mozilla Manifesto, Respekt, Professionalität und Inklusivität, die Ablehnung schädlicher, unmoralischer, unethischer oder möglicherweise illegaler Handlungen sowie ein Verbot von Desinformation und diskriminierender Sprache
- Jedes LLM hat ein Kontextfenster, also die maximale Länge, die es sich in einem aktuellen Gespräch merken kann
- Dieses wird meist beim Training festgelegt und lässt sich später nicht ändern
- Je größer das Kontextfenster, desto länger kann auf frühere Fragen und Antworten Bezug genommen werden
- Außerdem können größere Inhaltsblöcke aus der Vektorsuche eingefügt werden
- Das Kontextfenster von LLaMA 2 betrug 4096 Token, also ungefähr 3000 Wörter
- Um Kontextfenster zu sparen, kürzte das Team den System-Prompt wiederholt und plant künftig, Modelle mit größeren Kontextfenstern zu prüfen
Orchestrierung und UI-Auswahl
- Für den gesamten Chatbot ist Orchestrierung nötig, um verschiedene Ebenen zu koordinieren, darunter Agent-Prompt-Injection, Verwaltung des Kontextfensters, Embedding interner Inhalte sowie LLM-Aufrufe und Antwortverarbeitung
- LangChain, eines der bekanntesten Tools im LLM-Bereich, ist leistungsfähig und flexibel, bringt aber auch viel Komplexität mit
- Das Mozilla-Team nutzte LangChain nur minimal für Embeddings und Vektorsuche
- Weil das Projekt kurz und stark eingeschränkt war, wurde das meiste mit selbst geschriebenem Python-Code umgesetzt
- Mit mehr Zeit hätte man vermutlich nicht alles manuell gemacht
- Die UI braucht mehr Funktionen, als es zunächst scheint, etwa die Anzeige von Gesprächen, das Nachverfolgen früherer Threads und den Umgang mit Backend-Verarbeitung, deren Ausgabe mit ungleichmäßiger Geschwindigkeit eintrifft
- Unter den Open-Source-Chatbot-UIs kann chatbot-ui die OpenAI API implementieren und als Ersatz für eine ChatGPT-UI dienen; zugleich lässt es sich leicht als Frontend für ein eigenes LLM-System nutzen
- Das Mozilla-Team hätte normalerweise wohl ein Projekt wie chatbot-ui verwendet, nutzte aber stattdessen den internen Experimentier-Chatbot-Code Companion und dessen Autor, die beide verfügbar waren
- Dank Companion ließ sich die UI schnell iterieren und testen
Ergebnis des Hackathons und verbleibende Aufgaben
- Zum Ende des Hackathons hatte das Mozilla-Team einen internen Prototyp-Chatbot fertiggestellt
- Vollständig innerhalb von Mozilla gehostet
- Sicher und privat nutzbar
- Soll in seinem Verhalten Mozillas Werte widerspiegeln
- Auf dem Weg zur Zielerreichung waren mehrere schwierige Entscheidungen und Kompromisse nötig
- Das Gelernte lässt sich in drei Punkte zusammenfassen
- Open-Source-Chatbots befinden sich noch in der Entwicklung; es gibt viel zu entscheiden, wenig klare Dokumentation und viele Möglichkeiten zu scheitern
- Modelle anhand anderer Kriterien als bloßer Rohleistung zu bewerten und auszuwählen, ist zu schwierig, wodurch auch die richtige Wahl für vertrauenswürdige AI-Apps schwerfällt
- Derzeit ist wirksames Prompt Engineering entscheidend für den Erfolg eines Chatbots
- Mozilla hat begonnen, Wege zu schaffen, damit Entwickler leichter in das Open-Source-Machine-Learning-Ökosystem einsteigen können, und will auf Basis der Hackathon-Arbeit zur Open-Source-Community beitragen
- Wenn Open-Source-LLMs breit verfügbar sind, müssen alle kollektiv und aktiv an ihrer Gestaltung mitwirken, um eine bessere Zukunft zu schaffen
1 Kommentare
Hacker-News-Kommentare
Wenn ich ein Unternehmen kontaktiere, dann weil ich die Antwort auf der Website nicht finden konnte oder weil ich jemanden bitten muss, etwas zu tun, das auf der Website nicht möglich ist. Zum Beispiel einen Dienst kündigen.
Eine sprechende FAQ-Seite wirkt wie der Versuch, eine mangelhafte User Experience zu kaschieren, und wenn ein Unternehmen die Informationen, die ich suche, nicht auf die Website gestellt hat, ist die Wahrscheinlichkeit groß, dass sie auch nicht im Chatbot stehen.
Ein Chatbot kann allerdings dabei helfen, zur richtigen Ansprechperson weiterzuleiten; ihn aber als Barriere vor menschlicher Hilfe aufzubauen, halte ich für ein Antipattern.
Deshalb zeigen viele Websites, bevor man den Support kontaktiert, eine ganze Reihe von Fragen an, die auf Basis der Beschreibung passende Antworten empfehlen; der AWS-Support macht das ebenfalls so.
Bots können nerven, aber sie können auch die Kosten für Kundensupport deutlich senken. Wenn die User Experience gut ist und man schnell zu einem Mitarbeiter durchgestellt wird, wenn der Bot nicht antworten kann, bin ich dafür. Natürlich unter der Voraussetzung, dass der Bot nicht halluziniert und falsche Informationen ausgibt.
Ich habe kein Support-Personal, das Fragen beantworten könnte, also nutze ich einen Chatbot. Ohne Bot gäbe es gar nichts.
Dafür überwache ich die Bot-Logs. Wenn im Produkt oder auf der Website eine Funktion fehlt, füge ich sie hinzu, damit Nutzer das künftig vollständig per Self-Service erledigen können.
Nutzer können ihr Konto jederzeit kündigen oder eine Rückerstattung erhalten.
Für solche Fragen passen Large Language Models nahezu perfekt. Es wäre nur gut, wenn sie besser darin würden zu erkennen, welche Fragen der Bot nicht direkt beantworten kann.
Natürlich gibt es Fälle, in denen ein Chatbot einen Menschen oder eine gut geschriebene FAQ ersetzen kann. Aber diese Selbstzufriedenheit übersieht den Hauptgrund, warum Support so furchtbar ist: Er ist von Anfang an so designt.
Nehmen wir „Kündigung nur telefonisch möglich“ als Beispiel: Anmeldung oder Upsell sind technisch schwierigere Probleme und trotzdem viel einfacher gestaltet. Ziel ist es, bei Handlungen, die kurzfristig wie Kosten oder Verluste aussehen, Reibung einzubauen. Unternehmen wissen, dass viele Menschen bei Reibung aufgeben oder es aufschieben.
Das ist das Paradigma von Nudging und Dark Patterns. Man muss sich nur ansehen, wie „Alle ablehnen“ bei Cookie-Bannern meist versteckt ist. Nudges lassen Unternehmen so aussehen, als würden sie das Gesetz einhalten, während sie den Gesamteffekt auf Kosten der Zeit und Aufmerksamkeit der Nutzer umgehen.
Chatbots sind nur eine weitere Ebene im Support-Labyrinth.
Ich freue mich überhaupt nicht auf eine Zukunft, in der jedes Unternehmen Chatbot-Support hat.
Das ist schon jetzt ziemlich verbreitet und frustrierend, aber immerhin merkt man ungefähr in der Hälfte der Fälle, dass der Bot die Frage nicht versteht, sodass es noch einen Ausweg zu einem Menschen gibt.
Die Ära von „Der Computer sagt nein“ ist bereits da.
Außerdem: Ich will nicht nur negativ sein und vom Thema abweichen; der Artikel selbst wirkt ziemlich gut. Applaus an den Autor. Das Engineering ist cool, ich mag nur nicht, wie es tatsächlich eingesetzt wird.
Chatbots sind kein Allheilmittel, aber sie können viel unnötiges Rauschen reduzieren. Was man braucht, ist etwas, das in einer bestimmten Domäne die grundlegenden Fragen beantworten kann, die durchschnittliche Nutzer stellen.
Mein früherer Arbeitgeber war ein ziemlich großes Unternehmen, und die Confluence-Instanz war riesig. Ich habe viel Zeit damit verschwendet, dort Informationen zu finden. Ein Chatbot, der auf all diesen Informationen trainiert worden wäre, wäre wohl ziemlich nützlich gewesen.
Amazon fällt mir ein. Ich bin seit Langem Kunde und habe vor Kurzem defekte Computer-Peripherie erhalten.
Ich beschrieb dem Chatbot kurz das Problem, und sofort wurde eine neue Bestellung ausgelöst; ich bekam die Antwort, dass ich die bereits erhaltene Ware einfach behalten könne und sie ohne Zusatzkosten per Priority-Versand geliefert werde.
Das war alles, und am nächsten Tag kam sie an und funktionierte einwandfrei.
Natürlich wussten sie vermutlich, dass ich ein langjähriger Kunde bin und bereits viel Geld ausgegeben habe, aber es war so ziemlich die schmerzloseste Erfahrung, die man sich vorstellen kann. Viel besser, als sich durch mehrere Webseiten mit Auswahloptionen zu klicken.
„Euer Ehren, meine gesamte Argumentation war Unsinn und zitierte Gesetze, die gar nicht existieren, aber das lag daran, dass ich ChatGPT benutzt habe“ — das war ein echter Anwalt, und ihm wurde nicht einmal die Anwaltszulassung entzogen.
Die Formulierung „verändert bereits das Web, das wir kennen und lieben“ ist zwar Haarspalterei und klar off-topic, aber ich liebe das heutige Web nicht.
Das Web wird zunehmend von einigen wenigen Unternehmen kontrolliert. Sie entscheiden, welche Inhalte sichtbar sind (Meta, Google) und welche E-Mails im Spamfilter landen (MS, Google).
Das heutige Web hat mit Liebe wenig zu tun. Ich muss ständig darum kämpfen, überhaupt die Menschen zu erreichen, die sich entschieden haben, mir zu folgen.
Am Ende findet der Großteil meiner Kommunikation in der realen Welt oder in privaten Chats statt. Außerdem möchte ich noch erwähnen, wie furchtbar und instabil Messenger für Unternehmen sind.
Mit dem heutigen Web muss etwas passieren. Ich weiß nicht was und nicht wie, aber Veränderung wäre definitiv willkommen.
Man sollte weiterhin alle anderen Wege anbieten, über die Menschen folgen können, aber wenn man den RSS-Feed bewirbt, könnten die Leute anfangen, ihn zu nutzen.
Wenn du technisch etwas ausprobieren willst, kannst du eine ActivityPub-Bridge einrichten, damit man dir auch in sozialen Medien folgen kann. Wenn du Wordpress verwendest, gibt es https://wordpress.org/plugins/activitypub/.
Da die meisten Top-Kommentare gegenüber Chatbots eher negativ zu sein scheinen: Bei der Arbeit hatten wir tatsächlich einen hervorragenden Chatbot.
Für mich war er deutlich besser als die Suche in Confluence und konnte auch Fragen zu dynamischen Daten beantworten, etwa wie viele Urlaubstage noch übrig sind oder wie weit man bei den Arbeitszeiten im Plus oder Minus liegt.
Soweit ich mich erinnere, wurde im Hintergrund Technik clever eingesetzt, sodass er die meisten natürlichsprachlichen Fragen verstand.
Die Suche von Confluence ist ein kompletter Witz, und zwar ein schlechter.
Kunden nutzen Chatbots, weil die UI der Website verwirrend ist. Sie wollen Informationen bekommen, finden aber nicht heraus, wie.
Früher hat man bei Google nach „Dienstname + Telefonnummer“ oder „Dienstname + Abo kündigen“ gesucht.
In neun von zehn Fällen will die Website weder die Telefonnummer leicht herausgeben noch die Kündigung leicht machen. Wenn man von vornherein nicht möchte, dass Kunden eine versteckte Aktion ausführen, wozu ist der Chatbot dann eigentlich da?
Ich habe während des Chatbot-Hypes in dem Bereich gearbeitet und musste mehreren Kunden sagen, dass wir wenig tun können, wenn sie nicht wirklich bereit sind, ihren Kunden zu helfen.
Zumindest bei Unternehmen, die mit Menschen zu tun haben, ist das eigentliche Ziel von Chatbots, Web- und Mobile-App-UIs als ersten Kontaktpunkt zu verdrängen.
Nutzer sollten mit einer einheitlichen Identität per SMS oder einem ähnlichen Chat, oder per Telefonanruf, mit dem Unternehmen kommunizieren können.
Web- und Mobile-Apps sind nur sekundäre oder tertiäre Hilfswerkzeuge, die die grundlegende Kommunikationsform ergänzen.
Der Grund, warum Unternehmen das früher nicht konnten, war, dass die Genauigkeit des Sprachverständnisses nicht ausreichte. Große Sprachmodelle haben diese Grenze überwunden.
Dass der Bot aus Erfahrung einen Teil der Interaktionen mit Support-Mitarbeitern reduziert, ist ein Bonus. Dank besserer großer Sprachmodelle steigt auch die Quote der vermiedenen Weiterleitungen allmählich.
Das nervige Chatbot-Widget unten rechts ist nur eine Übergangslösung, bis eine einzige Telefonnummer angeboten wird und die Kommunikation darüber reibungslos funktioniert.
Abschließend: Der Titel ist irreführend. Es geht nicht darum, einen Open-Source-Chatbot zu bauen, sondern darum, für die Community und schnellere Fortschritte bei AI statt geschlossener/kommerzieller Tools ausschließlich Open-Source-Bibliotheken zum Bau eines Chatbots zu verwenden.
Es hieß: „Wir haben innerhalb des bestehenden Google-Cloud-Platform(GCP)-Kontos von Mozilla einen eigenen virtuellen Server eingerichtet. Damit haben wir uns faktisch dafür entschieden, MLOps selbst zu machen. Wir konnten aber mit der Gewissheit weitermachen, dass das System privat ist und vollständig unter unserer Kontrolle steht.“ Wie ist es privat und vollständig unter Mozillas Kontrolle, wenn man einen Server in Googles Infrastruktur betreibt?
Zu erklären, wie man das auf Bare Metal selbst hostet, würde den Rahmen eines Artikels zum Bau eines Chatbots sprengen, und so zu tun, als sei ein VPS in Google Cloud unsicher, ist etwas weit hergeholt.
ISO 27001 ist ein internationaler Standard für Informationssicherheits-Managementsysteme, und die Compliance von GCP zeigt ein Bekenntnis zur Informationssicherheit.
ISO 27017 ist speziell auf Cloud-Sicherheit ausgerichtet und konzentriert sich auf Kontrollen für Cloud-Service-Provider.
ISO 27018 ist ein Standard zum Schutz personenbezogener Daten in Public Clouds.
SOC-2-Berichte können Gewissheit über Kontrollen in Bezug auf Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und Datenschutz bieten.
Wenn Gesundheitsdaten verarbeitet werden, ist HIPAA-Compliance nötig; wenn Daten aus Europa oder von EU-Bürgern verarbeitet werden, ist GDPR-Compliance wichtig.
Für Kunden der US-Regierung kann FedRAMP-Compliance erforderlich sein, und bei der Verarbeitung von Kreditkartendaten ist PCI-DSS-Compliance wichtig.
Man sollte prüfen, ob die innerhalb von GCP genutzten Dienste vom Zertifizierungsumfang abgedeckt sind, der für die jeweilige Branche oder den Use Case erforderlich ist. Solche Zertifizierungen lassen sich in der Regel auf der Google-Cloud-Website einsehen; offizielle Dokumente kann man bei Bedarf auch über Google Sales oder den Support erhalten.
Falls ihr euch fragt, wie man so ein Vektordatenbank-Chatmodell tatsächlich baut: In einem Livestream letzte Woche habe ich gezeigt, wie man es in einer Colab-Umgebung fast von Grund auf erstellt und Inferenz mit Llama 2 durchführt: https://www.youtube.com/live/kBB1A2ot-Bw?feature=share
Die große Herausforderung bei diesem Aufbau ist semantische Ähnlichkeitssuche in großem Maßstab. Pinecone hat ziemlich gute Dokumentation zu Datenstrukturen für die Skalierung großer Vektordatenbanken.
Ich habe darauf gewartet, dass Mozilla auf diesen Zug aufspringt und ein eigenes großes Sprachmodell entwickelt. Angesichts der Mission der Organisation, „das Internet für alle offen und zugänglich zu halten“, ergibt das sehr viel Sinn. Ich weiß nur nicht, ob sie die Ressourcen oder den Willen dazu haben.
Es hieß: „Es gibt einen Grund, warum Machine-Learning-Operations, also MLOps, ein Wachstumsfeld ist. Solche Apps bereitzustellen und zu verwalten ist schwierig. Es erfordert spezielles Wissen und bestimmte Fähigkeiten, die viele Entwickler und Ops-Verantwortliche noch nicht haben.“ Was daran ist so schwierig oder anders?
Ich hatte es so verstanden, dass man eine Web-API betreibt, die ein Modell lädt, also ein kompiliertes Asset. In dieser Hinsicht wirkt es nicht besonders anders.