Einführung von Atlas Stream Processing – Vereinfachung der Reise zu reaktiven, reaktionsfähigen, ereignisgesteuerten Apps

MongoDB
September 14, 2023 | Updated: September 21, 2023

Wir freuen uns, heute den Private Preview von Atlas Stream Processing ankündigen zu können!

Die Welt wird immer schneller und Ihre Anwendungen müssen mithalten. Reaktionsfähige, ereignisgesteuerte Anwendungen erwecken digitale Erlebnisse für Ihre Kunden zum Leben und verkürzen die Zeit, in der das Unternehmen Einblicke erhält und Maßnahmen ergreifen kann. Denken Sie mal darüber nach:

  • Benachrichtigung Ihrer Benutzer, sobald sich ihr Lieferstatus ändert,

  • Blockierung betrügerischer Transaktionen während der Zahlungsabwicklung,

  • Analyse der erzeugten Sensortelemetrie, um potenzielle Geräteausfälle zu erkennen und zu beheben, bevor es zu kostspieligen Ausfällen kommt.

In jedem dieser Beispiele verlieren die Daten im Laufe der Sekunden ihren Wert. Es muss kontinuierlich und mit geringer Latenz abgefragt und ausgeführt werden. Um dies zu erreichen, greifen Entwickler zunehmend auf ereignisgesteuerte Anwendungen zurück, die durch Streaming-Daten betrieben werden, damit sie sofort agieren und auf die sich ständig verändernde Welt um sie herum reagieren können. Atlas Stream Processing wird Entwicklern dabei helfen, schneller auf ereignisgesteuerte Apps umzusteigen.

Im Laufe der Jahre haben Entwickler die MongoDB Datenbank übernommen, weil sie die Flexibilität und Benutzerfreundlichkeit des Dokumentmodells sowie die MongoDB Query API lieben, die es ihnen ermöglicht, mit Daten als Code zu arbeiten. Diese Grundprinzipien verringern die Reibungsverluste bei der Entwicklung von Software und Anwendungen erheblich. Jetzt übertragen wir dieselben Prinzipien auf das Streaming von Daten. Atlas Stream Processing definiert die Entwicklererfahrung für die Arbeit mit komplexen Streams mit hoher Geschwindigkeit und sich schnell ändernden Daten neu und vereinheitlicht die Art und Weise, wie Entwickler mit Daten in Motion und at Rest arbeiten.

Während bestehende Produkte und Technologien viele Innovationen für Streaming und Stream-Verarbeitung mit sich gebracht haben, glauben wir, dass MongoDB natürlich gut geeignet ist, Entwicklern bei einigen wichtigen verbleibenden Herausforderungen zu helfen. Zu diesen Herausforderungen gehört die Schwierigkeit, mit variablen, großen Datenmengen und schnell getakteten Daten zu arbeiten; der Overhead beim Erlernen neuer Tools, Sprachen und APIs; und die zusätzliche betriebliche Wartung und Fragmentierung, die durch Punkttechnologien in komplexe Stack eingeführt werden können.

Einführung in die Atlas Stream Processing

Atlas Stream Processing ermöglicht die Verarbeitung von High Velocity Streams komplexer Daten mit einigen einzigartigen Vorteilen für das Entwicklererlebnis:

  • Es basiert auf dem Dokumentmodell und ermöglicht Flexibilität beim Umgang mit den verschachtelten und komplexen Datenstrukturen, die im Event Streaming üblich sind. Dies verringert die Notwendigkeit von Vorverarbeitungsschritten und ermöglicht Entwicklern gleichzeitig, natürlich und einfach mit Daten zu arbeiten, die komplexe Strukturen aufweisen. So wie es die Datenbank zulässt.

  • Es vereint die Erfahrung der Arbeit mit allen Daten und bietet eine einzige Plattform – für alle APIs, Abfragesprachen und Tools –, um umfangreiche, komplexe Streaming-Daten neben den kritischen Anwendungsdaten in Ihrer Datenbank zu verarbeiten.

  • Und es wird vollständig in MongoDB Atlas verwaltet und basiert auf einer bereits soliden Auswahl an integrierten Diensten. Mit nur wenigen API-Aufrufen und Codezeilen können Sie einen Stream-Prozessor, eine Datenbank und eine API-Deployment-Schicht bei jedem der großen Cloud-Anbieter einrichten.

Wie funktioniert Atlas Stream Processing?

Atlas Stream Processing stellt eine Verbindung zu Ihren kritischen Daten her, unabhängig davon, ob diese in MongoDB (über change streams) oder in einer Event-Streaming-Plattform wie Apache Kafka gespeichert sind. Entwickler können mithilfe des Kafka-Wire-Protokolls einfach und nahtlos eine Verbindung zu Confluent Cloud, Amazon MSK, Redpanda, Azure Event Hubs oder Managed Kafka herstellen. Und durch die Integration mit dem nativen Kafka-Treiber bietet Atlas Stream Processing als Grundlage eine native Leistung mit geringer Latenz.

Zusätzlich zu unserer langjährigen strategischen Partnerschaft mit Confluent freuen wir uns, zum Start auch Partnerschaften mit AWS, Microsoft, Redpanda und Google bekannt zu geben.

Atlas Stream Processing bietet dann drei Schlüsselfunktionen, die erforderlich sind, um aus Ihrer Fülle an Streaming-Daten eine differenzierte Kundenerfahrung zu machen. Lassen Sie uns diese einzeln durchgehen.

Kontinuierliche Verarbeitung

Erstens können Entwickler jetzt das Aggregation Framework Framework von MongoDB verwenden, um umfangreiche und komplexe Datenströme von Event-Streaming-Plattformen wie Apache Kafka kontinuierlich zu verarbeiten. Dadurch werden leistungsstarke neue Möglichkeiten eröffnet, Streaming-Daten kontinuierlich abzufragen, zu analysieren und darauf zu reagieren , ohne dass es zu Verzögerungen kommt, die mit Batch Processing einhergehen. Mit dem Aggregation Framework können Sie Daten filtern und gruppieren, High Velocity Event Streams über Stateful-Time- Windows zu umsetzbaren Erkenntnissen aggregieren und so umfassendere Echtzeit-Anwendungserlebnisse ermöglichen.

Kontinuierliche Validierung

Zunächst bietet Atlas Stream Processing Entwicklern robuste und native Mechanismen zur Bewältigung Probleme mit falschen Daten, die andernfalls zu Schäden in Anwendungen führen könnten. Zu den potenziellen Problemen gehören die Weitergabe ungenauer Ergebnisse an die App, Datenverlust und Ausfallzeiten der Anwendung. Atlas Stream Processing löst diese Probleme, um sicherzustellen, dass Streaming-Daten zuverlässig verarbeitet und zwischen ereignisgesteuerten Anwendungen geteilt werden können.

Atlas Stream Processing:

  • Bietet eine kontinuierliche Schemavalidierung, um vor der Verarbeitung zu überprüfen, ob Ereignisse ordnungsgemäß gebildet werden – beispielsweise das Ablehnen von Ereignissen mit fehlenden Feldern oder ungültigen Wertebereichen

  • Erkennen von Nachrichtenbeschädigungen

  • Erkennt verspätet eintreffende Daten, die ein Verarbeitungsfenster verpasst haben.

Atlas Stream Processing Pipelines können mit einer integrierten Dead Letter Queue (DLQ) konfiguriert werden, in die Ereignisse, die die Validierung nicht bestehen, weitergeleitet werden. Dadurch wird vermieden, dass Entwickler ihre eigenen benutzerdefinierten Implementierungen erstellen und verwalten müssen. Probleme können schnell behoben werden, während das Risiko fehlender oder beschädigter Daten, die zum Ausfall der gesamten Anwendung führen, minimiert wird.

Kontinuierlicher Merge

Ihre verarbeiteten Daten können dann kontinuierlich in Ansichten materialisiert werden, die in der Atlas Collection verwaltet werden. Wir können uns das als Push-Abfrage vorstellen. Anwendungen können Ergebnisse (über Pull-Abfragen) aus der Ansicht abrufen, indem sie entweder die MongoDB Query API oder die Atlas SQL-Schnittstelle verwenden. Das kontinuierliche Zusammenführen von Aktualisierungen der Collection ist eine wirklich effiziente Möglichkeit, neue analytische Ansichten der Daten zu erhalten und so automatisierte und menschliche Entscheidungen und Maßnahmen zu unterstützen. Neben materialisierten Ansichten haben Entwickler auch die Flexibilität, verarbeitete Ereignisse wieder in Streaming-Systemen wie Apache Kafka zu veröffentlichen.

Erstellen eines Stream-Prozessors

Wir zeigen Ihnen, wie einfach es ist, einen Stream-Prozessor in MongoDB Atlas zu erstellen. Mit Atlas Stream Processing können Sie für einen Stream-Prozessor dieselbe Aggregation Pipeline Syntax verwenden, die Sie aus der Datenbank kennen. Im Folgenden stellen wir eine einfache Stream Processing Instanz von Anfang bis Ende vor. Es sind nur wenige Codezeilen erforderlich.

Zuerst schreiben wir eine Aggregation Pipeline , die eine Quelle für Ihre Daten definiert, eine Validierung durchführt, um sicherzustellen, dass die Daten nicht von der IP-Adresse localhost/​127.0.0.1 stammen, ein rollierendes Fenster erstellt, um jede Minute gruppierte Nachrichtendaten zu sammeln, und diese dann zusammenführt neu verarbeitete Daten in eine MongoDB Collection in Atlas.

Dann erstellen wir unseren Stream-Prozessor namens „netattacks“ und geben dabei unsere neu definierte Pipeline p sowie dlq als Argumente an. Dadurch wird unsere gewünschte Verarbeitung durchgeführt und mithilfe einer Dead Letter Queue (DLQ) werden alle ungültigen Daten sicher zur späteren Überprüfung, Fehlerbehebung oder erneuten Verarbeitung gespeichert.

Zuletzt können wir das Ganze starten. Das ist alles, was Sie brauchen, um einen Stream-Prozessor in MongoDB Atlas zu erstellen.

Fordern Sie den Private Preview an

Wir freuen uns, dieses Produkt in Ihre Hände zu bekommen und zu sehen, was Sie damit entwickeln. Erfahren Sie mehr über Atlas Stream Processing und fordern Sie hier frühzeitig Zugang an, um am Private Preview teilzunehmen, sobald er für Entwickler geöffnet ist.

Neu bei MongoDB? Beginnen Sie noch heute kostenlos, indem Sie sich für MongoDB Atlas anmelden.

Absicherungserklärung

Entwicklung, Freigabe und zeitliche Planung der beschriebenen Funktionen oder Features für unsere Produkte liegen in unserem alleinigen Ermessen. Diese Informationen dienen lediglich dazu, unsere allgemeine Produktrichtung zu umreißen, und sollten nicht als Grundlage für eine Kaufentscheidung herangezogen werden. Dies ist auch keine Selbstverpflichtung, Zusage oder rechtliche Verpflichtung zur Lieferung von Material, Code oder Funktionalität irgendwelcher Art.

← Previous

Présentation d'Atlas Stream Processing - Simplifier le chemin vers des applications réactives et event-driven

Aujourd'hui, nous sommes heureux d'annoncer l'avant-première privée (Private Preview) d'Atlas Stream Processing ! Le monde évolue de plus en plus vite et vos applications doivent pouvoir tenir le rythme. Les applications réactives et event-driven donnent vie à des expériences numériques pour vos clients et accélèrent le temps de compréhension et d'action pour l'entreprise. Pensez à : avertir vos utilisateurs dès que l'état de leur livraison change, bloquer les transactions frauduleuses lors du traitement des paiements analyser la télémétrie des capteurs au fur et à mesure qu'elle est générée afin de détecter les défaillances potentielles de l'équipement et d'y remédier avant les pannes coûteuses. Dans chacun de ces exemples, les données perdent de leur valeur au fil des secondes. Elles doivent être requêtées et faire face à une action en continu et ce avec une faible latence. Pour ce faire, les développeurs se tournent de plus en plus vers des applications event-driven alimentées par des données en continu, de manière à ce qu'elles puissent instantanément réagir et répondre à l'évolution constante du monde qui les entoure. Atlas Stream Processing aidera les développeurs à passer plus rapidement à des applications event-driven. Au fil des ans, les développeurs ont adopté la base de données MongoDB parce qu'ils apprécient la flexibilité et la facilité d'utilisation de document model, ainsi que l'API de requête MongoDB qui leur permet de travailler avec des données en tant que code. Ces principes fondamentaux éliminent radicalement les frictions liées au développement de logiciels et d'applications. Aujourd'hui, nous appliquons ces mêmes principes aux données en continu. Atlas Stream Processing redéfinit l'expérience des développeurs qui travaillent avec des streams complexes de données à haute vitesse et à évolution rapide, et unifie la façon dont les développeurs travaillent avec des données en mouvement et au repos. Bien que les produits et technologies existants aient apporté de nombreuses innovations en matière de flux et de traitement des flux, nous pensons que MongoDB est naturellement bien adapté pour aider les développeurs à relever certains défis clés restants. Ces défis comprennent la difficulté de travailler avec des données variables, à fort volume et à grande vitesse, les frais généraux contextuels liés à l'apprentissage de nouveaux outils, langages et API, ainsi que la maintenance opérationnelle supplémentaire et la fragmentation qui peuvent être introduites par des technologies ponctuelles dans des piles d'applications complexes. Présentation de l'Atlas Stream Processing Atlas Stream Processing permet de traiter des flux de données complexes à grande vitesse avec quelques avantages uniques pour le développeur : Atlas Stream Processing est basé sur le modèle documentaire, ce qui lui confère une grande souplesse dans le traitement des structures de données imbriquées et complexes qui sont courantes dans les streams d'événements. Cela évite les étapes de prétraitement et permet aux développeurs de travailler de façon intuitive et facile avec des données aux structures complexes. Tout comme la base de données le permet. Cela unifie l'expérience de travail à travers tout type de données, en offrant une plateforme unique - à travers l'API, le langage de requête et les outils - pour traiter des données de streams riches et complexes, parallèlement aux données d'application critiques de votre base de données. Atlas Stream Processing est entièrement managé dans MongoDB Atlas , en s'appuyant sur un définisseur de services intégrés déjà robuste. Quelques appels d'API et quelques lignes de code suffisent pour mettre en place un processeur de flux, une base de données et une couche de service d'API sur l'ensemble des principaux fournisseurs cloud. Atlas Stream Processing est entièrement managé dans MongoDB Atlas , en s'appuyant sur un définisseur de services intégrés déjà robuste. Quelques appels d'API et quelques lignes de code suffisent pour mettre en place un processeur de flux, une base de données et une couche de service d'API sur l'ensemble des principaux fournisseurs cloud. Comment fonctionne Atlas Stream Processing ? Atlas Stream Processing se connecte à vos données critiques, qu'elles se trouvent dans MongoDB (via change stream ) ou dans une plateforme de streaming comme Apache Kafka. Les développeurs peuvent se connecter facilement et de manière transparente à Confluent cloud, Amazon MSK, Redpanda, Azure Event Hubs, ou à l'auto-managé Kafka en utilisant le protocole Kafka wire. En s'intégrant au pilote Kafka natif, Atlas Stream Processing offre des performances natives à faible latence. En plus de notre partenariat stratégique de longue date avec Confluent, nous sommes heureux d'annoncer les partenariats avec AWS, Microsoft, Redpanda et Google, dès le lancement. Atlas Stream Processing fournit ensuite 3 fonctionnalités clés nécessaires pour transformer votre stream de données en une expérience client différenciée. Examinons-les un par un. Traitement en continu Tout d'abord, les développeurs peuvent désormais utiliser le modèle d'agrégation de MongoDB pour traiter en continu des flux de données riches et complexes provenant de plateformes de streaming d'événements telles qu'Apache Kafka. Cela ouvre de nouvelles voies puissantes pour le requêtage, l'analyse et l'accès aux données en continu sans aucun des retards inhérents au traitement par lots. Avec modèle d'agrégation, vous pouvez filtrer et grouper les données, agréger les streams d'événements à grande vitesse en informations exploitables sur le temps d'état Windows, ce qui permet d'enrichir les expériences d'application en temps réel. Validation continue Ensuite, Atlas Stream Processing offre aux développeurs des mécanismes robustes et natifs pour traiter les problèmes de données incorrectes qui peuvent autrement causer des ravages dans les applications. Les potentiels problèmes comprennent la transmission de résultats inexacts à l'application, la perte de données et les temps d'arrêt de l'application. Atlas Stream Processing résout ces problèmes afin de garantir le traitement et le partage des données en continu de manière fiable entre les applications event-driven. Atlas Stream Processing : Apporte une validation en continue du schéma afin de vérifier que les événements sont correctement formés avant d'être traités, par exemple en rejetant les événements dont les champs sont manquants ou qui contiennent des plages de valeurs non valides. Détecte l'altération des messages Détecte les données arrivées tardivement qui ont manqué une fenêtre de traitement. Les pipelines d'Atlas Stream Processing peuvent être configurées avec une Dead Letter Queue (DLQ) dans laquelle les événements qui échouent à la validation sont acheminés. Cela évite aux développeurs d'avoir à construire et à maintenir leurs propres implémentations personnalisées. Les problèmes peuvent être rapidement résolus et le risque que des données manquantes ou corrompues entraînent l'arrêt de l'ensemble de l'application est minimisé. Fusion continue Les données traitées peuvent ensuite être matérialisées en continu dans des vues gérées dans des collections de bases de données Atlas. On peut considérer qu'il s'agit d'une requête "push". Les applications peuvent extraire les résultats (via des requêtes) de la vue en utilisant l'API de requête MongoDB ou l'interface Atlas SQL. La fusion continue des mises à jour des collections est un moyen très efficace de maintenir des vues analytiques fraîches des données pour soutenir la prise de décision et l'action humaine et automatisée. Outre les vues matérialisées, les développeurs ont également la possibilité de publier les événements traités dans des systèmes de diffusion en continu tels qu'Apache Kafka. Création d'un Stream Processor Nous allons vous montrer à quel point il est facile de construire un processeur de flux dans MongoDB Atlas. Avec Atlas Stream Processing, vous pouvez utiliser la même syntaxe de pipeline d'aggrégation pour un stream processor que celle que vous connaissez pour la base de données. Nous présentons ci-dessous une instance de traitement de stream simple, du début à la fin. Il suffit de quelques lignes de code. Tout d'abord, nous allons écrire une pipeline d'agrégation qui définit une source pour vos données, effectue une validation pour s'assurer que les données ne proviennent pas de l'adresse IP localhost/​127.0.0.1, crée une fenêtre de basculement pour collecter des données de messages groupés toutes les minutes, puis fusionne ces données nouvellement traitées dans une collection MongoDB dans Atlas. Ensuite, nous allons créer notre Stream Processor appelé "netattacks" en spécifiant notre pipeline nouvellement définie p ainsi que dlq comme arguments. Ceci lancera le traitement souhaité et, grâce au Dead Letter Queue (DLQ), stocke en toute sécurité les données non valides en vue d'une inspection, d'un débogage ou d'un nouveau traitement ultérieur. Enfin, nous pouvons le démarrer. C'est tout ce qu'il faut pour construire un stream processor dans MongoDB Atlas. Demander un aperçu privé Nous sommes impatients de mettre ce produit entre vos mains et de voir ce que vous en ferez. Pour en savoir plus sur Atlas Stream Processing et demander un accès anticipé ici pour participer à l'aperçu privé une fois qu'il sera ouvert aux développeurs. Nouveau sur MongoDB ? Commencez gratuitement dès aujourd'hui en créant votre compte MongoDB Atlas . Sphère de sécurité Le développement, la publication et le calendrier des caractéristiques ou fonctionnalités décrites pour nos produits demeurent à notre entière discrétion. Cette information est simplement destinée à décrire l'orientation générale des produits et ne doit pas être invoquée pour prendre une décision d'achat, et n'est pas un engagement, une promesse ou une obligation légale de fournir un matériel, un code ou une fonctionnalité.

September 14, 2023
Next →

AI-Powered Call Centers: A New Era of Customer Service

Customer satisfaction is critical for insurance companies. Studies have shown that companies with superior customer experiences consistently outperform their peers. In fact, McKinsey found that life and property/casualty insurers with superior customer experiences saw a significant 20% and 65% increase in Total Shareholder Return , respectively, over five years. A satisfied customer is a loyal customer. They are 80% more likely to renew their policies, directly contributing to sustainable growth. However, one major challenge faced by many insurance companies is the inefficiency of their call centers. Agents often struggle to quickly locate and deliver accurate information to customers, leading to frustration and dissatisfaction. This article explores how Dataworkz and MongoDB can transform call center operations. By converting call recordings into searchable vectors (numerical representations of data points in a multi-dimensional space), businesses can quickly access relevant information and improve customer service. We'll dig into how the integration of Amazon Transcribe, Cohere, and MongoDB Atlas Vector Search—as well as Dataworkz's RAG-as-a-service platform— is achieving this transformation. From call recordings to vectors: A data-driven approach Customer service interactions are goldmines of valuable insights. By analyzing call recordings, we can identify successful resolution strategies and uncover frequently asked questions. In turn, by making this information—which is often buried in audio files— accessible to agents, they can give customers faster and more accurate assistance. However, the vast volume and unstructured nature of these audio files make it challenging to extract actionable information efficiently. To address this challenge, we propose a pipeline that leverages AI and analytics to transform raw audio recordings into vectors as shown in Figure 1: Storage of raw audio files: Past call recordings are stored in their original audio format Processing of the audio files with AI and analytics services (such as Amazon Transcribe Call Analytics ): speech-to-text conversion, summarization of content, and vectorization Storage of vectors and metadata: The generated vectors and associated metadata (e.g., call timestamps, agent information) are stored in an operational data store Figure 1: Customer service call insight extraction and vectorization flow Once the data is stored in vector format within the operational data store, it becomes accessible for real-time applications. This data can be consumed directly through vector search or integrated into a retrieval-augmented generation (RAG) architecture, a technique that combines the capabilities of large language models (LLMs) with external knowledge sources to generate more accurate and informative outputs. Introducing Dataworkz: Simplifying RAG implementation Building RAG pipelines can be cumbersome and time-consuming for developers who must learn yet another stack of technologies. Especially in this initial phase, where companies want to experiment and move fast, it is essential to leverage tools that allow us to abstract complexity and don’t require deep knowledge of each component in order to experiment with and realize the benefits of RAG quickly. Dataworkz offers a powerful and composable RAG-as-a-service platform that streamlines the process of building RAG applications for enterprises. To operationalize RAG effectively, organizations need to master five key capabilities: ETL for LLMs: Dataworkz connects with diverse data sources and formats, transforming the data to make it ready for consumption by generative AI applications. Indexing: The platform breaks down data into smaller chunks and creates embeddings that capture semantics, storing them in a vector database. Retrieval: Dataworkz ensures the retrieval of accurate information in response to user queries, a critical part of the RAG process. Synthesis: The retrieved information is then used to build the context for a foundational model, generating responses grounded in reality. Monitoring: With many moving parts in the RAG system, Dataworkz provides robust monitoring capabilities essential for production use cases. Dataworkz's intuitive point-and-click interface (as seen in Video 1) simplifies RAG implementation, allowing enterprises to quickly operationalize AI applications. The platform offers flexibility and choice in data connectors, embedding models, vector stores, and language models. Additionally, tools like A/B testing ensure the quality and reliability of generated responses. This combination of ease of use, optionality, and quality assurance is a key tenet of Dataworkz's "RAG as a Service" offering. Diving deeper: System architecture and functionalities Now that we’ve looked at the components of the pre-processing pipeline, let’s explore the proposed real-time system architecture in detail. It comprises the following modules and functions (see Figure 2): Amazon Transcribe , which receives the audio coming from the customer’s phone and converts it into text. Cohere ’s embedding model, served through Amazon Bedrock , vectorizes the text coming from Transcribe. MongoDB Atlas Vector Search receives the query vector and returns a document that contains the most semantically similar FAQ in the database. Figure 2: System architecture and modules Here are a couple of FAQs we used for the demo: Q: “Can you explain the different types of coverage available for my home insurance?” A: “Home insurance typically includes coverage for the structure of your home, your personal belongings, liability protection, and additional living expenses in case you need to temporarily relocate. I can provide more detailed information on each type if you'd like.” Q: “What is the process for adding a new driver to my auto insurance policy?" A: “To add a new driver to your auto insurance policy, I'll need some details about the driver, such as their name, date of birth, and driver's license number. We can add them to your policy over the phone, or you can do it through our online portal.” Note that the question is reported just for reference, and it’s not used for retrieval. The actual question is provided by the user through the voice interface and then matched in real-time with the answers in the database using Vector Search. This information is finally presented to the customer service operator in text form (see Fig. 3). The proposed architecture is simple but very powerful, easy to implement, and effective. Moreover, it can serve as a foundation for more advanced use cases that require complex interactions, such as agentic workflows , and iterative and multi-step processes that combine LLMs and hybrid search to complete sophisticated tasks. Figure 3: App interface, displaying what has been asked by the customer (left) and how the information is presented to the customer service operator (right) This solution not only impacts human operator workflows but can also underpin chatbots and voicebots, enabling them to provide more relevant and contextual customer responses. Building a better future for customer service By seamlessly integrating analytical and operational data streams, insurance companies can significantly enhance both operational efficiency and customer satisfaction. Our system empowers businesses to optimize staffing, accelerate inquiry resolution, and deliver superior customer service through data-driven, real-time insights. To embark on your own customer service transformation, explore our GitHub repository and take advantage of the Dataworkz free tier .

November 27, 2024