Ring, znana marka systemów bezpieczeństwa domowego należąca do Amazona, ujawniła szczegóły techniczne chatbota obsługi klienta, który działa dziś w 10 krajach jednocześnie. Kluczem do sukcesu okazało się podejście RAG oparte na Amazon Bedrock Knowledge Bases, które pozwoliło firmie ograniczyć koszty skalowania do każdego nowego rynku o 21%.
Jeśli chcesz otrzymać raport przed oficjalną premierą oraz zobaczyć nazwę swojej firmy wśród uczestników badania – zostaw adres email na końcu ankiety.
Skąd w ogóle wziął się ten problem?
Zacznijmy od początku. Ring przez lata działał na prostym chatbocie opartym na regułach, zbudowanym w Amazon Lex. System działał, ale miał poważne ograniczenia. Nie radził sobie z pytaniami, których wcześniej nie przewidziano, a w szczytowych momentach aż 16% rozmów wymagało przekierowania do żywego konsultanta. Inżynierowie spędzali 10% swojego czasu na utrzymaniu reguł systemowych. Kiedy firma zaczęła wchodzić na kolejne rynki europejskie, było jasne, że ten model się nie skaluje.
Nie wystarczyło przetłumaczyć treści. Każdy rynek to inne specyfikacje produktów, inne normy prawne, inne scenariusze awarii. Niemcy mają inne wymagania dotyczące napięcia niż Wielka Brytania, a rozwiązania dla jednego rynku nie zawsze pasują do drugiego. Potrzebna była architektura, która poradzi sobie z tą różnorodnością bez mnożenia infrastruktury.
RAG zamiast reguł
Ring przeszedł na model oparty na Retrieval-Augmented Generation. W skrócie: zamiast z góry definiować odpowiedzi, system wyszukuje relevantne fragmenty dokumentacji w bazie wiedzy i na ich podstawie generuje odpowiedź w czasie rzeczywistym. To fundamentalna zmiana sposobu myślenia o chatbocie.
Cała architektura opiera się na kilku usługach AWS:
- Amazon Bedrock Knowledge Bases jako główny silnik bazy wiedzy wektorowej
- AWS Lambda do przetwarzania zapytań i logiki biznesowej
- AWS Step Functions do orkiestracji codziennych procesów
- Amazon S3 jako magazyn danych źródłowych i metadanych
- Amazon OpenSearch Serverless jako vector store
Kluczowym elementem jest obsługa wielu rynków z jednej, scentralizowanej bazy wiedzy. Każdy dokument jest otagowany metadaną contentLocale (np. en-GB), co pozwala przy każdym zapytaniu filtrować wyniki tylko do treści relevantnych dla danego rynku. Klient z Wielkiej Brytanii dostaje odpowiedź bazującą wyłącznie na dokumentacji dla brytyjskiego rynku.
Dwa procesy, jeden system
Architektura Ring rozdziela zarządzanie treścią na dwa osobne przepływy pracy.
Pierwszy to ingestion i ewaluacja. Zespół treści przesyła dokumenty do S3, Lambda przetwarza je automatycznie, a Step Functions każdej nocy tworzy nową wersję bazy wiedzy. Ta wersja przechodzi przez zestaw testów: system uruchamia zestawy pytań ewaluacyjnych i mierzy jakość odpowiedzi. Do oceny jakości Ring używa modelu Claude Sonnet 4 jako „sędziego” – czyli jeden model AI ocenia wyniki innego. Wyniki trafiają do dashboardów Tableau.
Drugi przepływ to promocja do produkcji. Jeśli nowa wersja bazy wiedzy przejdzie testy i okaże się lepsza od poprzedniej, zostaje awansowana do tzw. Golden Data Source, z której korzystają klienci. System utrzymuje historię wersji przez 30 dni, co pozwala na rollback jeśli coś pójdzie nie tak. Przy 200 aktualizacjach treści tygodniowo to nie jest kwestia teorii.
Przypadek Ring to dobry przykład tego, jak AI może realnie zmienić skalowalność operacji wsparcia klienta. 21% redukcji kosztów przy ekspansji na kolejne rynki to liczba, która robi wrażenie. Ale warto zadać sobie pytanie: co z jakością tych odpowiedzi? Automatyczna ewaluacja oparta na LLM-as-a-judge to wciąż metoda niedoskonała. Model oceniający może dziedziczyć te same błędy co model oceniany. Ring wspomina o dashboardach Tableau i metrykach jakości, ale nie poznamy szczegółów dotyczących tego, jak firma weryfikuje, czy chatbot faktycznie rozwiązuje problemy klientów, a nie tylko generuje odpowiedzi, które brzmią przekonująco. To pytanie, które powinien zadać sobie każdy, kto planuje podobne wdrożenie.
Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl
Szczegół, który robi różnicę: latencja i koszty
Ring dokonał ciekawego odkrycia podczas analizy architektury. Okazało się, że opóźnienia związane z przesyłaniem danych między regionami AWS stanowią mniej niż 10% całkowitego czasu odpowiedzi. To pozwoliło firmie przyjąć architekturę scentralizowaną, zamiast budować osobną infrastrukturę w każdym kraju. Efekt? Koszt skalowania do każdego kolejnego rynku spadł o 21%.
Przy docelowym czasie odpowiedzi chatbota na poziomie 7-8 sekund, oszczędność kilkuset milisekund na transferze danych to margines, który można poświęcić w zamian za znacznie prostszą architekturę.
Co dalej?
Ring zapowiada, że kolejnym krokiem będzie przejście na model agentowy. Zamiast jednego chatbota, który stara się odpowiadać na wszystko, planuje wdrożyć sieć wyspecjalizowanych agentów. Jeden agent zajmie się diagnostyką urządzeń, inny obsługą zamówień, jeszcze inny rekomendacjami produktów. System dynamicznie będzie kierował zapytanie klienta do właściwego agenta.
To kierunek, który obserwujemy w całej branży. Single-agent chatbot powoli ustępuje miejsca systemom multi-agent, gdzie każdy komponent robi jedno, ale dobrze.
Dla firm rozważających podobne wdrożenia, przykład Ring pokazuje kilka praktycznych lekcji:
- Scentralizowana architektura z filtrowaniem metadanych to efektywna alternatywa dla replikowania infrastruktury per region
- Automatyczna ewaluacja z rollback to nie opcja, lecz konieczność przy tej skali aktualizacji
- Wybór strategii chunkowania dokumentów ma bezpośredni wpływ na jakość odpowiedzi i warto poświęcić mu uwagę na etapie projektowania
Nie każda firma działa w skali Ring, ale wzorce architektoniczne tu opisane są równie wartościowe dla mniejszych organizacji, które chcą zbudować wielojęzyczny system wsparcia bez wielokrotnego powielania kosztów.
