스크립트
00:00:00Machen wir kurz ein paar schnelle Fragen und dann legen wir direkt los. Wer von uns im Raum
00:00:19hat hier schon Sprach-KI-Agenten gebaut? Okay, das ist ein ziemlich gutes Publikum hier. Und wie viele von euch
00:00:28haben KI-Agenten gebaut, die in der Produktion eingesetzt wurden? Nicht schlecht. Okay, cool. Also sprechen wir
00:00:38darüber, was typischerweise passiert, oder? Alle reden über Sprach-KI-Agenten. Das, wisst ihr,
00:00:47Allheilmittel für so ziemlich alles auf der Welt heutzutage sind Sprach-KI-Agenten. Also baut jeder
00:00:51einen und versucht, ihn bereitzustellen. Sie klingen toll, wenn man das quasi in seiner
00:00:57Entwicklungsumgebung baut. Und in dem Moment, in dem man das von einem Proof of Concept in die Produktion überführt,
00:01:03fangen die Dinge an zu scheitern. Wir gehen also diese fünf verschiedenen Blickwinkel durch, wie oder was wir
00:01:09bei PLEVO mit Sprach-KI-Agenten gesehen haben. Aber davor noch eine kurze Einführung von meiner Seite. Ich bin Venki,
00:01:19der Gründer und CAO. Sie verwendete den Titel Agent Engineering Manager. Ich nenne mich Chief Agent Officer aus
00:01:28Titelgründen. Okay, also warum, warum sind wir überhaupt qualifiziert für diese
00:01:35Diskussion und was, was sehen wir, was viele Unternehmen nicht zu sehen bekommen? Also ich
00:01:42werde ein bisschen über unsere Reise sprechen, wie wir bisher vorangekommen sind, und dann direkt
00:01:48loslegen. Wisst ihr, wir gibt es schon seit etwa 14 Jahren. Unsere Reise war eine Entwickler-API-Plattform.
00:01:54Und jetzt eben ein KI-Agenten-Geschäft. Wir begannen damals 2011 mit Sprach- und SMS-APIs.
00:02:01Und jetzt konzentrieren wir uns hauptsächlich auf unser KI-Agenten-Angebot, das Full-Stack.
00:02:08Das Full-Stack auf unserer Plattform. Wir verarbeiten weltweit über eine Milliarde Sprachanrufe pro Monat.
00:02:16Äh, und das ist der Grund, warum wir viele dieser Muster gesehen haben, wie,
00:02:20wenn wir mit unseren Kunden arbeiten, was auf deren Sprach-KI-Agenten in der Produktion passiert.
00:02:25Äh, wir sind ein 90-köpfiges Team und haben 50 Millionen an Finanzierung auf der Bank. Fun Fact:
00:02:33Das stammt nicht von externen VC-Investoren. Das kommt alles daher, dass wir ein profitables Unternehmen sind
00:02:38und dieses Geld im Laufe der Jahre auf der Bank angesammelt haben. Äh,
00:02:42einige Kunden, die wir weltweit unterstützen. Äh, wir haben einfach ein paar Logos dort gelassen,
00:02:49aber vom Angebot her würde ich das in drei verschiedene
00:02:54Bereiche einteilen. Das eine ist ein programmierbares KI-Agenten-Angebot. Wir nennen es,
00:03:00ich meine, es ist eine Sprach-Pipeline, noch kein echtes Sprache-zu-Sprache-Produkt, aber das ist ein programmierbares Angebot.
00:03:05Wir haben auch ein KI-Agenten-Studio. Das ist ein visueller No-Code-Builder. Und wie gesagt,
00:03:11wir haben mit Sprach-APIs begonnen. Wir haben dies also in den letzten 14 Jahren offensichtlich weiterentwickelt,
00:03:16das SIP-Trunking und die Audio-Streaming-Schicht. Wir sind also nicht auf andere angewiesen für die Telefonie-
00:03:22oder Carrier-Schicht. Das ist das Kerngeschäft, das wir über all die Jahre aufgebaut haben.
00:03:26Und darauf sitzt unsere KI-Agenten-Plattform.
00:03:32Okay. Kommen wir damit dazu, was ihr, da ihr alle KI-Agenten gebaut habt,
00:03:39sicherlich auf die eine oder andere Weise schon gesehen oder gebaut habt. Wir werden mehr Zeit damit verbringen,
00:03:44wie die gesamte Pipeline aussieht. Was wir bei Kunden sehen,
00:03:51und ich bin sicher, das kommt euch bekannt vor, ist, dass jeder, der über KI-Agenten nachdenkt,
00:03:56eine Reihe dieser Orchestrierungsframeworks nimmt und das ziemlich gut macht, LiveKit oder PipeCat,
00:04:01und darauf ihren KI-Agenten baut. Sie denken,
00:04:06sie können einfach diese vier verschiedenen Schichten orchestrieren: Spracherkennung, LLM und TTS
00:04:13mit Spracherkennung dazwischen, und ab geht die Post. Mein KI-Agent funktioniert in einem POC
00:04:19und er wird auch in der Produktion funktionieren. Typischerweise passiert genau das. Sie messen ihre
00:04:24Latenzen – einige indikative Latenzen auf dieser Folie an jeder Schicht sind zu sehen – und denken sich,
00:04:30ja, das scheint für meine Anforderungen gut zu sein, also bringen wir es in die Produktion. Und dann
00:04:36setzt die Produktion ein und man sieht all die Fehlerarten, mit denen wir uns
00:04:41in diesem Vortrag wohl am meisten beschäftigen werden. Ich habe etwas Zeit am Ende für Q&A eingeplant,
00:04:48falls ihr Fragen habt, aber wir springen direkt hiervon zu den
00:04:53verschiedenen Fehlerarten, die wir beobachten. Fangen wir mit der ersten an, über die
00:05:01jeder spricht. Das ist die am häufigsten besprochene Fehlerart, nämlich Latenz. Ich glaube,
00:05:07wir haben heute ein paar KI-Agenten-Vorträge oder Sprach-KI-Agenten-Vorträge. Ich bin mir ziemlich sicher,
00:05:12dass jeder diesen spezifischen Fehler ansprechen wird, weshalb ich ihn direkt am Anfang bringe,
00:05:17was die gesamte Erfahrung für die Benutzer angeht, oder? Typischerweise
00:05:26messen die meisten Leute dies an der Zeit bis zum ersten Audio. Also der Zeitpunkt, an dem die Benutzer aufhören zu sprechen
00:05:34bis Ihr Agent zu sprechen beginnt, richtig? Und ich denke, das haben Sie wahrscheinlich schon
00:05:39gesehen, wenn Sie Sprachagenten gebaut haben, was sich gut oder natürlich anfühlt, was
00:05:46etwas störend oder spürbar wirkt, und dann, was wirklich nervig ist, also verschiedene
00:05:52Stufen. Wir stellen fest, dass die meisten Leute unter 550 ms sein wollen, weil das von Plattformen
00:06:00oder Lösungen beworben wird, aber die meisten landen schlussendlich zwischen 750 ms und 1,2 Sekunden.
00:06:07Dort landen die Meisten. Die wirklich schlechten Performer landen bei
00:06:13mehr als 1,2 Sekunden, und dann fangen die Benutzer an aufzulegen. Nun, ich werde mit Ihnen
00:06:19teilen, was wir praktisch in der Produktion gesehen haben, wenn Kunden dies auf verschiedenen Ebenen nutzen,
00:06:26und dann eben Lösungen für einige dieser Probleme. Die Art und Weise, wie wir über diese
00:06:33Ebene nachdenken sollten, ist quasi eine Balance zwischen diesen drei Faktoren: Kosten, Intelligenz und Latenz,
00:06:42richtig? Und warum bringe ich diese drei zur Sprache? Weil sie gewissermaßen miteinander zusammenhängen.
00:06:48Eines der Dinge, die ich gerade mit einigen Leuten draußen besprochen habe.
00:06:51Im letzten Jahr haben wir viele Innovationen und einen enormen Anstieg der Intelligenz bei LLMs erlebt,
00:06:58nicht wahr? Und das meiste an Intelligenz kam im Bereich des logischen Denkens, des Reinforcement Learnings
00:07:05und so weiter hinzu. Die Ironie bei Sprachagenten ist jedoch, dass fast immer
00:07:11das LLM oder der sprechende Agent das „Denken“ deaktiviert haben muss, richtig? All die
00:07:19Fortschritte, die wir im letzten Jahr auf LLM-Ebene gemacht haben, finden hier also überhaupt keine Anwendung,
00:07:25oder? Natürlich gibt es bessere Modelle, die Instruktionen besser befolgen
00:07:29oder Tool-Aufrufe tätigen können, aber praktisch die gesamte Intelligenz, die in die
00:07:34Denkschicht eingebaut wurde, ist standardmäßig ausgeschaltet, wenn man schnell genug sein will.
00:07:39Das ist also eine der Ironien, mit denen wir konfrontiert sind. Wie bringt man also Intelligenz, Kosten und Latenz in Einklang?
00:07:44Schauen wir uns einige dieser Optionen an, die es auf dem Markt gibt,
00:07:48richtig? Und ich greife mir speziell das LLM heraus, denn wenn man sich das vorherige Diagramm ansieht, ist das LLM
00:07:55quasi der Bereich mit der höchsten Latenz, der hier hinzukommt, nicht wahr? Und wenn man sich
00:08:02die Frontier-Modelle ansieht, mit denen die meisten standardmäßig beginnen – OpenAI, Claude,
00:08:09Gemini –, liegt die P50 Time to First Token (TTFT) an guten Tagen bei etwa 450 bis 500 ms, und es kann
00:08:17spikig werden, richtig? P90 oder P95 können leicht auf über 1,2 oder sogar 1,3 Sekunden steigen,
00:08:25und das ist nicht gut für das gesamte Agentenerlebnis. Das ist also Ihr Frontier-Modell.
00:08:31Nun gibt es eine andere Option: Cerebras oder Groq, die dafür bekannt und beliebt sind,
00:08:38viele Tokens sehr schnell auszuspucken, richtig? Das funktioniert, aber um eine dedizierte Latenz
00:08:45oder Time-to-First-Token zu erhalten, benötigt man dedizierte Kapazitäten, und das ist wirklich teuer.
00:08:51Daher sprach ich davon, dass die Kosten ausbalanciert werden müssen, richtig? Es ist wirklich teuer.
00:08:56Und wenn man mit jemandem vom Groq- oder Cerebras-Team spricht, werden sie einem sagen,
00:09:01dass man dedizierte Kapazitäten 12 Monate im Voraus buchen muss. Sie sind für die nächsten 12 Monate ausgebucht.
00:09:05Das ist also eine ziemlich teure Option. Und man muss sich wirklich sicher sein, dass das Modell,
00:09:11das man auf diesen Infrastrukturen einsetzt, in 12 Monaten noch da sein wird. Das ist eine
00:09:17große Investition und ein großes Unbekannte. Was ist also eine realistische Option für produktionstaugliche
00:09:27Agenten von guter Qualität, die diese drei Aspekte in Einklang bringen? Das hat für uns funktioniert:
00:09:34Open-Source-Modelle. Es gibt natürlich eine große Auswahl an Varianten und Variationen,
00:09:41für die man sich entscheiden kann. Ich spreche hier speziell über die beiden, mit denen wir arbeiten:
00:09:47Qwen 3.5 und Gemma 4. Das sind quasi hochmoderne Open-Source-Modelle auf dem Markt,
00:09:56die derzeit auf dem Markt sind. Und wir haben diesbezüglich viele Benchmarks durchgeführt, äh, wie sie funktionieren.
00:10:02Es kann einschüchternd sein zu denken: Okay, ich habe die Modelle, jetzt muss ich sie selbst hosten,
00:10:10auf meinen eigenen GPUs laufen lassen usw. Aber wenn man konsequent unter 300 ms anstrebt,
00:10:17haben wir festgestellt, dass dies eine großartige Option ist, um Latenz, Kosten und Intelligenz auszubalancieren.
00:10:23Nun noch ein paar tiefere Einblicke. Wenn Sie nur Englisch machen, funktionieren Qwen 3.5 oder Gemma beide gut.
00:10:29Aber wenn Sie mehrsprachig arbeiten, also ein internationales Publikum und verschiedene Sprachen ansprechen,
00:10:35ist Gemma 4 ein viel besseres Modell dafür. Wir haben Token-Fruchtbarkeits-Evaluierungen durchgeführt.
00:10:44Um das Ganze von Fachjargon zu befreien: Es geht darum, wie viele Tokens benötigt werden,
00:10:48um ein Wort in dieser Sprache zu generieren. Gemma ist also viel, viel besser, mindestens 2,5- bis 3-mal besser als Qwen 3.5
00:10:56aus dieser Perspektive. Ihre Zeit bis zu den Wörtern ist bei Gemma 4 also viel schneller, bei ansonsten gleichen Bedingungen,
00:11:04mehrsprachiger Basis. Nun, welche Größen wählen Sie, ähm, auf der LLM-Ebene? Ähm, das Mixture-of-Experts funktioniert normalerweise
00:11:12ganz gut. Ähm, das Mixture-of-Experts mit drei oder vier Milliarden funktioniert normalerweise ganz gut. Das, das Problem mit
00:11:17Mixture-of-Experts ist, wenn jemand den Weg, den Weg der Feinabstimmung gehen möchte, kann das eine
00:11:22Herausforderung sein, ähm, denn die Feinabstimmung von Mixture-of-Experts-Modellen ist nicht einfach. Ähm, man kann am Ende das
00:11:28Modell sehr oft kaputt machen. Also, das ist eine Herausforderung, die wir bei Mixture-of-Experts sehen, aber von Haus aus
00:11:35bringt es Sie 90 % näher an Ihr Ziel, also auch ohne jegliche Feinabstimmung oder, oder, oder spezifische
00:11:42Anpassungen am Modell. Ähm, das ist also der Vorteil von Mixture-of-Experts. Ähm, wenn Sie nun feinabstimmen wollen,
00:11:48und, und Sie, Sie möchten tiefer gehen und sagen: Schauen Sie, ich arbeite für einen bestimmten Bereich, das Gesundheitswesen,
00:11:53oder was auch immer, richtig, und ich möchte sicherstellen, dass ich mein Modell feinabstimmen kann, sollten Sie zumindest
00:11:58mit, ähm, den 8-Milliarden-, 12-Milliarden-Modellen anfangen, zumindest, ähm, von unserem heutigen Stand aus. Vielleicht, vielleicht in sechs Monaten,
00:12:04schlägt ein 4-Milliarden-, ähm, 4-Milliarden-Modell das 8-Milliarden-Modell, ähm, um Längen, aber für heute, ähm, was wir
00:12:11gesehen haben, ist, ähm, Sie brauchen mindestens ein 8-Milliarden- oder 12-Milliarden-Modell, ähm, denn Sie suchen nach zwei
00:12:16Dingen in diesen Modellen. Erstens natürlich schnelle Tokens, aber, ähm, gute Befehlsbefolgung, okay? Und die
00:12:23zweite Sache ist eine sehr hohe, ähm, Erfolgsquote beim Tool Calling, denn wenn Sie diese beiden Dinge gut
00:12:29können, dann sind Sie schon zu 70, 80 % am Ziel, ohne es überhaupt feinabstimmen zu müssen, irgendein Modell feinabstimmen zu müssen,
00:12:35die Modelle werden also von Haus aus funktionieren, richtig? Ähm, also, das ist, ähm, unser Rezept gewesen. Wir haben tatsächlich,
00:12:42ähm, wir betreiben zwei Varianten, einmal ein feinabgestimmtes Modell für bestimmte Branchen, und dann für, ähm, Sie wissen schon,
00:12:50die meisten allgemeinen Anwendungsfälle, ähm, ähm, funktioniert das MoE-Modell einfach von Haus aus. Ähm, es gibt noch ein paar weitere
00:12:56Tipps und Tricks, über die wir in den kommenden Folien sprechen werden, wo wir Fehlermodelle sehen, aber, aber das ist
00:13:00unser Standpunkt in Bezug auf, auf die Latenz von LLMs. Ähm, in Ordnung, mir rennt
00:13:07die Zeit davon, also werde ich das beschleunigen. Ähm, nun, es gibt noch ein paar andere Varianten davon. Ähm,
00:13:12Leute bauen Agenten mit, ähm, einer Mischung aus Modellen. Was sie tun, ist, wissen Sie, für, ähm, den, den sprechenden
00:13:19Teil davon haben sie ein Konversationsmodell, was ein sehr viel niedrigeres, ähm, kleineres Modell ist, und dann, ähm,
00:13:24wissen Sie, vielleicht sogar ein Drei-Milliarden-Modell, und dann haben sie für das Tool Calling ein viel größeres Modell,
00:13:27so dass sie dort, ähm, eine verbesserte Erfolgsquote beim Tool Calling haben. Ähm,
00:13:35Tut mir leid. Zweitens: Gehen Sie davon aus, dass Transkriptionen fehleranfällig sind. Das ist
00:13:42etwas, wonach man sich beim Erstellen von KI-Agenten richten sollte, selbst wenn man über
00:13:49die beste Transkriptionsengine auf dem Markt verfügt. Ich zeige Ihnen auch gleich, warum, denn die modernsten
00:13:55Transkriptionsengines auf dem Markt erreichen eine Wortfehlerrate von etwa vier bis sechs Prozent,
00:14:02nicht wahr? Und das gilt für bekannte Testdatensätze. Bei realen, rauschbehafteten Anrufen mit
00:14:10verschiedenen Akzenten, die Sprecher haben nun mal unterschiedliche Akzente, Fachvokabular
00:14:15und so weiter, landen diese Werte aus Sicht der Wortfehlerrate meist im zweistelligen Bereich,
00:14:21oder? Man kann natürlich ein Open-Source-Modell nehmen und es optimieren,
00:14:25aber wir sehen typischerweise, was hier oft schiefgeht, und es gibt dabei gewisse Muster.
00:14:31Eigennamen, Fachjargon, Telefonnummern – etwa zufällig fehlende Ziffern in Telefonnummern –
00:14:38sowie falsche Ersetzungen. Ich werde ein paar Beispiele dafür durchgehen, wie man diese Probleme löst.
00:14:43Adressen. Wenn Sie versuchen, eine lange Adresse zu erfassen, kann es passieren, dass die Transkriptionsengine
00:14:48einfach einige Teile davon vergisst. Sprachwechsel (Code-Switching). Ich nehme einfach ein Beispiel aus
00:14:55einer Sprache, die ich spreche, weil das für mich leicht auf die Folie zu bringen war, bei der
00:15:01man quasi Englisch nimmt, aber in einem anderen Alphabet geschrieben, was zum Beispiel für Hindi verwendet wird,
00:15:06nicht wahr? Das ist also Englisch in genau diesem Alphabet geschrieben, während die eigentliche englische Version
00:15:11davon lautet: Hallo, wie geht es dir? Wenn ich also ein Publikum in einem anderen Land anspreche,
00:15:16in dem Sprachwechsel stattfinden und ich mein Englisch in einer anderen Art von
00:15:21Schrift erhalte, fängt von der Transkriptionsengine bis zur LLM-Schicht alles an zusammenzubrechen,
00:15:26weil Ihr LLM dann oft Ausgaben in genau dieser Schrift erzeugt und danach auch Ihre Sprachsynthese versagt.
00:15:32Okay, das ist also sehr wichtig zu beachten, und wenn Sie Ihren Agenten unabhängig von
00:15:38der Transkriptionsengine aufbauen möchten, müssen Sie eine Schicht einziehen, die all das normalisiert,
00:15:44oder? Wir sprechen gleich über Lösungen. Und dann gibt es noch den anderen Fall, nämlich Hindi
00:15:48in lateinischen beziehungsweise römischen Buchstaben, oder? Das heißt, das ist Hindi, liest sich aber
00:15:54wie Englisch, was wiederum nachgelagert alles durcheinanderbringt. Das sind nur Beispiele. Das gilt für
00:15:59Arabisch, Mandarin, Japanisch und so weiter, im Grunde für fast jede Sprache. Also,
00:16:04Was bringt auf Transkriptionsebene tatsächlich etwas? Für Eigennamen
00:16:11empfehlen wir, nicht nur Keyword-Boosting zu nutzen. Viele Transkriptions-
00:16:16engines bieten Keyword-Boosting an, bei dem man bestimmte Wörter in die Engine eingibt,
00:16:21sondern dynamisches Keyword-Boosting. Das bedeutet: Behalte das Keyword nicht für die gesamte Dauer
00:16:26des Anrufs. Füge es einfach dynamisch hinzu, wenn du es als Antwort benötigst, um die höchste
00:16:32Genauigkeit zu erzielen. Das heißt, in verschiedenen Phasen des Anrufs hat die Transkriptionsengine
00:16:38jeweils andere Keywords geboostet, richtig? Und das funktioniert unserer Erfahrung nach am besten, denn wenn man
00:16:43den Kontext der Transkriptionsengine mit Unmengen von Keywords überlädt, fängt sie wieder an zu halluzinieren,
00:16:49nicht wahr? Genau das sehen wir meistens als am effektivsten an. Ja, und verarbeite deine Transkripte
00:16:55nachträglich mit einem LLM, denn dein LLM hat Domainkontext, den deine Transkriptionsengine nicht hat.
00:17:02Deshalb ergeben viele Wörter, die sie ausgibt – ich gebe dir ein paar Beispiele –, vielleicht keinen Sinn. Hier ist
00:17:07eine Transkription, wie zum Beispiel eine Telefonnummer von einer Transkriptionsengine, richtig? Was glaubst du, was dieses E ist?
00:17:13Genau. Wenn man das einem LLM gibt, weiß es, dass das eine Drei ist. Genauso auch bei der Eins, das ist die Ziffer
00:17:18Eins. Deine Transkriptionsengine kann das also oft falsch machen, aber wenn du es mit einer
00:17:24LLM-Schicht nachbearbeitest, korrigiert sie das im Hinblick auf die Sammlung sofort. Ich meine, und die letzte
00:17:30Sache, wie ich schon sagte, Transliteration bedeutet, dass auch deine mehrsprachige STT-Ausgabe irgendwie
00:17:37normalisiert wird, entweder indem du sie zuerst von einem LLM transliterieren lässt oder irgendeine neuronale
00:17:46Transliterations-Engine verwendest. Es gibt viele Open-Source-Lösungen dafür, du kannst dir einfach eine davon
00:17:49aussuchen, richtig? Die diese ganze Arbeit für dich erledigt. Sende stets bereinigte Transkripte,
00:17:55unabhängig von der Transkriptionsengine, an dein LLM.
00:18:00Alles klar. Der dritte Punkt, den wir typischerweise beobachten, ist das Sammeln von Daten. Hier machen schätzungsweise 50 bis 60
00:18:05Prozent der KI-Agenten ziemlich große Fehler. Wir betrachten das gerne als ein UX-Problem,
00:18:14nur eben für Sprache. Man sollte also in Datenmodellen denken und nicht ein Transkript an ein LLM übergeben und versuchen lassen,
00:18:21herauszufinden, was darin stand. Lassen wir uns also inspirieren von – ich nehme an, die meisten von uns sind
00:18:27hier Entwickler –, man lasse sich von Pythons Datenklassen, Pydantic,
00:18:32Zod von TypeScript oder Formularfeldern in der UI inspirieren, richtig? Wenn man das Problem aus dieser Perspektive
00:18:39betrachtet, haben wir gesehen, dass die Genauigkeit bei der Datenerfassung von 30 % auf etwa 95 % steigt,
00:18:46wenn man auf diese Weise denkt. Lege also deine Struktur fest, bevor du fragst, richtig? Anstatt
00:18:52es völlig offen zu lassen, kannst du es einschränken? Kann beispielsweise eine Telefonnummer ein
00:18:58Feld vom Typ Telefonnummer sein? In dem Moment, in dem du das tust, weißt du genau, wie viele Ziffern sie haben
00:19:03muss. Du kannst darüber hinaus Validierungen durchführen und festlegen, welche Werte überhaupt zulässig sind.
00:19:10Wenn also im vorherigen Beispiel mitten in einer Telefonnummer ein E auftaucht und du weißt,
00:19:15dass es sich um eine Telefonnummer handelt, weißt du sofort, dass du das entweder intelligent zu einer Drei raten und beim
00:19:20Benutzer bestätigen musst, oder du erkennst, dass das ein Fehler ist, validierst das und bittest den Benutzer, es zu wiederholen,
00:19:26stimmt's? Das ist meines Erachtens eines der gängigen Muster, die wir hier im Bereich der
00:19:31Erfassungsmuster gesehen haben. Namen sind dabei wohl der interessanteste Fall. Ich habe mir einfach einen
00:19:36schwer auszusprechenden Namen ausgesucht. Es gibt keine Möglichkeit, dass ein Mensch das richtig versteht. Und
00:19:43auch keine Chance, dass unsere Transkriptionsengine das jemals richtig hinbekommt, egal wie oft man es versucht, richtig? Deswegen,
00:19:47in dem Moment, in dem man das als Felder betrachtet und Regeln sowie Bestätigungsmechanismen für das
00:19:53Buchstabieren einführt, erst dann kriegt man es halbwegs hin. Andernfalls
00:19:58geht das bei der Datenerfassung über einen Sprachanruf ziemlich schief. Und das ist nur ein Beispiel
00:20:03für das, was ich bezüglich des Aspekts der Datenerfassung meine.
00:20:11Ein weiterer Bereich, in dem es dramatisch schiefgeht, sind relative Werte, wobei Datumsangaben ein klassisches Beispiel sind.
00:20:18Wenn jemand sagt „nächste Woche Mittwoch um acht“, kann das 8:00 Uhr morgens oder abends bedeuten, und herauszufinden,
00:20:25was dieses Datum tatsächlich ist, wird wiederum zu einem sehr eingeschränkten Problem. Wenn du wüsstest, dass dies ein
00:20:30Datum-Uhrzeit-Feld ist und ich ein solches Feld erfasse, nimmst du das aktuelle Datum und rechnest aus,
00:20:35welcher Wert basierend darauf gemeint ist, richtig? So möchtest du also sicherstellen,
00:20:39dass du dies durch eine Kombination aus LLM und Tool-Aufrufen erreichst, wobei die Tool-Aufrufe
00:20:44einen Großteil dieser schweren Arbeit auf Feldebene für dich erledigen.
00:20:50Ja. Und dann lässt du das aus der Perspektive von Unit-Tests laufen. Alle deine
00:20:58Evaluierungen müssen diese Felder wie Unit-Tests behandeln. Solange deine Unit-Tests
00:21:06ist dein Agent quasi zuverlässig und wiederholbar. Du musst
00:21:10also nicht Hunderte von End-to-End-Agenten-Testfällen durchlaufen, nur um festzustellen,
00:21:15dass die Erfassung eines Feldes fehlerhaft ist. Du machst deine Evals auf Feld- und Unit-Test-Ebene.
00:21:24Und ja, wie gesagt, ich denke, diese Denkweise macht alles strukturierter,
00:21:30anstatt zu hoffen: Ich packe massenhaft Prompts rein und ändere den Prompt jedes Mal
00:21:36um ein paar Zeichen, und irgendwie sorgt mein Prompt-Engineering dafür, dass das LLM instruktions-
00:21:41und anpassungsfähiger wird und diese Dinge auf magische Weise befolgt. Tatsächlich haben wir, wie gesagt,
00:21:47gesehen, dass wir eine Genauigkeit von 95 bis 97 % erreichen, ohne ein Modell feinabstimmen zu müssen.
00:21:53Genau. Und der Trick besteht im Grunde darin, den Kontext aufzuschlüsseln,
00:21:57was der Agent zu diesem Zeitpunkt tut, mit spezifischen Zuständen, die der Agent durchläuft.
00:22:04Alles klar. Ich gehe hier einfach mal kurz im Hinblick auf die
00:22:10Zeit etwas schneller drüber hinweg. Ich sehe, mir bleiben noch drei Minuten. Ähm, hoffentlich ist das ein Bug,
00:22:16aber wir belassen es dabei. Okay. Das ist also der vierte Bereich, in dem wir Probleme auftreten sehen. Die meisten Leute nehmen
00:22:24die LLM-Ausgabe und leiten sie an ein TTS weiter. Offensichtlich gibt es auf dem Markt viele gute TTS-Systeme,
00:22:30die einem viel abnehmen, aber sehr oft geht dabei etwas schief. Was wir empfehlen und
00:22:37bereits gesehen haben, ist, dass man normalerweise eine Normalisierungsschicht zwischen dem LLM und der
00:22:43Zuspielung an das TTS benötigt. Man schickt die LLM-Ausgabe nicht einfach direkt an ein TTS, richtig? Und wir gehen
00:22:50ein paar Beispiele durch. Die Grundlagen: Emojis und Markdown vor jeder Synthese
00:22:58im TTS herauszufiltern. Die meisten Orchestrierungspipelines tun dies, wie LiveCAD oder PipeCAD,
00:23:02wenn man einfach ein paar Flags setzt. Aber stellen Sie sicher, falls Sie diese nicht nutzen oder
00:23:08alles von Grund auf neu bauen, dass Sie das explizit eingestellt haben, denn Sie möchten nicht, dass ein Emoji
00:23:12bei der Sprachausgabe auftaucht oder Markdown vorgelesen wird.
00:23:17Okay. Ein weiteres sehr wichtiges Thema sind benutzerdefinierte Wörterbücher. Die meisten TTS-Engines bieten
00:23:23Ihnen dies an, um festzulegen, wie bestimmte Wörter ausgesprochen werden, seien es Eigennamen, Marken,
00:23:30Akronym und so weiter und so fort. Stellen Sie das ein, wenn Sie vom LLM zur TTS-Ausgabe übergehen,
00:23:36denn wenn Sie das nicht tun, wird es schiefgehen. Und ich zeige Ihnen ein Beispiel, wie wir
00:23:40so etwas testen. Der andere Punkt ist, dass die meisten Engines auch Geschwindigkeitsregler anbieten. Wenn Sie also wissen, dass Sie
00:23:47einen Fachbegriff oder Namen aussprechen, verlangsamen Sie das Tempo, lassen Sie Ihren Agenten langsamer sprechen, auf 0,8x oder 0,7x,
00:23:54auf dieses spezifische Entity zu fokussieren und nicht zu vermasseln, wie es eine E-Mail, eine Telefon-
00:24:00nummer oder einen Namen Buchstabe für Buchstabe ausspricht. Und ja, normalisiert einfach all das unordentliche Zeug, oder? Wie E-Mails,
00:24:09Währungen, Daten. Überlasst das nicht dem TTS. Äh, die meisten tun das zwar, aber überlasst es nicht
00:24:15einfach dem TTS. Sondern baut eure eigene Normalisierungsschicht, damit ihr morgen, falls ihr das Gefühl habt,
00:24:21zu TTS wechseln zu müssen oder aus irgendeinem Grund der erste Dienst ausfällt und ihr
00:24:25ein anderes TTS nutzen wollt, nicht nativ auf die TTS-Engine angewiesen seid, sondern das
00:24:32selbst intern baut, um das zu managen. Und ja, ich glaube, ich habe mein Batch hier nicht,
00:24:39aber ich habe meinen Nachnamen nicht drauf. Mein erster Test ist also, wenn es meinen Nachnamen
00:24:44oder den Namen meiner Firma nicht aussprechen kann, versagt es bereits. Mein Nachname ist also Balasobramanian,
00:24:50und wenn ein KI-Sprachagent das nicht aussprechen kann, ist das für mich ein klares Zeichen. Ich weiß,
00:24:56dass der Agent viele Wörter vermasseln wird, die Tag für Tag buchstabiert oder richtig
00:25:04ausgesprochen werden müssen. Das zweite ist unsere Firma namens Pliwo. Viele Engines sprechen es
00:25:09Pliwo aus oder Pliwo und so weiter. Aber ich denke, es ist extrem wichtig, das in eurer Pipeline
00:25:16kontrollieren zu können. Und wenn ihr ein kundenorientiertes Produkt baut,
00:25:21dann solltet ihr euren Kunden diese Option ebenfalls anbieten. Also,
00:25:26ich gehe jetzt einfach mal schnell durch die letzten zwei Folien. Ich bin zeitlich nämlich massiv im Verzug.
00:25:32Erkennung des Redeendes, ich denke, das ist ein eigenes Thema, aber ich werde einfach
00:25:36schnell alle Punkte einblenden, damit ihr kurz drüber schauen könnt. Und wenn ihr im Anschluss
00:25:41danach können wir, können wir darüber sprechen. Richtig, äh, ich lasse das jetzt einfach so für fünf
00:25:49Sekunden stehen und dann können wir offline darüber quatschen. Ich liege nämlich ziemlich gut in der Zeit.
00:25:53Und das Letzte ist das Unterbrechen und das sogenannte Backchanneling. Es wird ja viel über
00:25:58Sprach-zu-Sprach-Modelle gesprochen, die einen Teil davon übernehmen, aber wir haben gesehen,
00:26:03wie man all das auch in Speech-to-Speech-Pipelines umsetzen kann. Man braucht dafür nicht zwingend ein reines Sprachmodell.
00:26:07Auch hier werde ich das einfach kurz auf die Folie packen und damit abschließen. Ähm,
00:26:15gut. Ich glaube, wir haben keine Zeit mehr für Fragen. Wir können sie im Anschluss klären, falls noch Zeit ist, aber
00:26:19hoffentlich war das hilfreich und hat euch ein paar Einblicke gegeben, was wir in der Produktion erleben,
00:26:24bei Milliarden von Anrufen im großen Stil. Alles klar, danke.
00:26:29Bis zum nächsten Mal.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기