Open Loyalty potrzebowało agenta obsługującego sprzedaż przychodzącą, który robi więcej niż prowadzi rozmowę. Miał kwalifikować rzeczywiste zapotrzebowanie, odpowiadać na pytania o produkt na podstawie aktualnych materiałów i pozostawiać ustrukturyzowany zapis dla zespołu sprzedaży. Soba Labs zbudowało go i wdrożyło.
Ryzyko produkcyjne tkwiło w punktach przekazania. Błędna informacja o cenie mogła podważyć zaufanie. Słaba kwalifikacja mogła skierować niewłaściwy lead na niewłaściwą ścieżkę. Powtórzona akcja w CRM mogła wygenerować dwie aktualizacje z jednej rozmowy.
Problem
Agent musiał:
- odpowiadać na podstawie aktualnego pozycjonowania produktu Open Loyalty, a nie nieaktualnych dokumentów;
- rozpoznawać, czy odwiedzający jest marką, sprzedawcą, partnerem czy agencją;
- zbierać minimum informacji potrzebnych sprzedaży, nie zamieniając rozmowy w formularz;
- kierować odwiedzającego do samoobsługi, na spotkanie lub do ścieżki wsparcia;
- zapisywać notatki o leadzie, tagi i podsumowanie przekazania w systemach docelowych.
Gdy system zetknął się z rzeczywistym ruchem, pojawiły się dwa problemy.
Dryf jakości. Prompty, które w środowisku staging wyglądały na niezawodne, zawodziły przy chaotycznych, wieloczęściowych pytaniach.
Ukryte awarie narzędzi. Problemy z retrieval-augmented generation i CRM często wyglądały jak dziwna odpowiedź modelu, dopóki nie dało się przeanalizować sekwencji wywołań modelu, wywołań narzędzi, ponownych prób i efektów ubocznych.
Jeden sporadyczny błąd uczynił drugi problem namacalnym. Niewielki odsetek rozmów generował dwie aktualizacje w CRM zamiast jednej. Testy manualne rzadko to wychwytywały, ale zduplikowane rekordy wprowadzały szum operacyjny.
System
Agenta AI zamodelowaliśmy jako maszynę stanów LangGraph. Stan rozmowy przechodził przez jawne etapy: powitanie, kwalifikację, wyszukiwanie, briefing sprzedażowy i zapis w CRM.
class SDRState(MessagesState):
lead_id: str
lead: dict
score: int
next_action: str
kb_context: list[Document]
thread_id: str
graph = StateGraph(SDRState)
graph.add_edge("intro", "qualify")
graph.add_conditional_edges("qualify", needs_product_qa)
graph.add_edge("retrieve_kb", "sales_brief")
graph.add_edge("sales_brief", "crm_write")
graph.add_edge("crm_write", END)Ta struktura miała znaczenie, ponieważ w przypadku agenta produkcyjnego debuguje się sekwencję, a nie pojedynczą odpowiedź. Stan pokazywał, o co zapytał odwiedzający, co zwróciło wyszukiwanie, który prompt został uruchomiony, co zdecydował model i które narzędzie wywołało efekt uboczny.
Co zapewniło niezawodność
Śledzenie każdej tury produkcyjnej
LangSmith zapewnił zespołowi pełny zapis każdej rozmowy. Jego model obserwowalności grupuje wszystkie kroki jednej operacji w jeden trace. Nasz trace obejmował wywołania modelu, wywołania narzędzi, dane wejściowe, wyniki, opóźnienie, wersję promptu i metadane przebiegu.
Dzięki temu awarie stały się odtwarzalne. Na podstawie identyfikatora przebiegu można było ustalić, który prompt wywołał dane zachowanie, jaki kontekst produktowy zwróciło wyszukiwanie i czy wywołanie narzędzia było nowe, czy było ponowną próbą.
Jakość jako test regresji
Na podstawie reprezentatywnych rozmów zbudowaliśmy niewielki zestaw ewaluacyjny agenta AI. Obejmował pytania o ceny, zastrzeżenia, niejednoznaczne intencje, brakujące pola i wieloczęściowe zapytania.
Każdą istotną zmianę promptu, modelu, ustawień wyszukiwania lub schematu narzędzi można było uruchomić na tym samym zestawie. Zespoły produktu i sprzedaży mogły ocenić, czy routing, oparcie na źródłach i ekstrakcja pól poprawiły się w całym zestawie, zamiast dyskutować o jednym transkrypcie.
Pierwsze kontrole były celowo konkretne:
- Czy agent poprawnie skierował leada?
- Czy wyodrębnił wymagane pola?
- Czy trzymał się zatwierdzonych materiałów o produkcie?
- Czy uniknął niebezpiecznego lub zduplikowanego efektu ubocznego?
Awarie produkcyjne jako wkład dla inżynierii
Ustrukturyzowana informacja zwrotna zamieniła rzeczywiste przebiegi w uporządkowaną według priorytetów kolejkę napraw. Zamiast zbierać wyłącznie sygnał kciuk w górę lub w dół, zespół klasyfikował awarie, takie jak błędny routing, twierdzenia bez pokrycia w źródłach, pominięte pola, niedopasowany ton i błędy narzędzi.
Najlepsze przykłady trafiały następnie do zestawu ewaluacyjnego. Problem produkcyjny stawał się przypadkiem testowym dla kolejnego wydania.
Błąd zduplikowanej akcji
Zduplikowana aktualizacja w CRM nie była widoczna w końcowej wiadomości asystenta. Szkoda powstawała w efekcie ubocznym.
Trace pokazał dokładną sekwencję. Zapis w CRM przekroczył limit czasu. Agent ponowił próbę. Drugie wywołanie zakończyło się sukcesem, a pierwsze zakończyło się chwilę później. Jedna rozmowa wygenerowała dwa zapisy.
Granicę z CRM wzmocniliśmy na trzy sposoby:
- Każdy zapis otrzymał klucz idempotencji wyprowadzony z rozmowy i tury.
- Ponowne próby modelu i ponowne próby narzędzi stały się odrębnymi decyzjami.
- Zestaw ewaluacyjny uzupełniono o symulowany przypadek przekroczenia limitu czasu, który weryfikował jedną aktualizację leada na turę.
crm_write.invoke({
"lead_id": state["lead_id"],
"payload": payload,
"idempotency_key": f"{thread_id}:{turn_id}",
})Dlatego LLM observability była czymś więcej niż ułatwieniem przy debugowaniu. Pokazała, która granica systemu wymaga silniejszej gwarancji.
Rezultat
Open Loyalty otrzymało agenta sprzedażowego, który kwalifikuje zapotrzebowanie przychodzące, odpowiada na podstawie identyfikowalnej bazy wiedzy o produkcie i przekazuje ustrukturyzowane wyniki zespołowi sprzedaży. Otaczające go mechanizmy kontrolne sprawiły, że każdą turę produkcyjną można przeanalizować, a każdą istotną zmianę przetestować.
Praktyczny wniosek jest prosty. Jeśli agent dotyka operacji przychodowych, należy oddzielić myślenie od działania. Trzeba śledzić jedno i drugie, zapewnić idempotentność efektów ubocznych i utrzymywać niewielki zestaw ewaluacyjny zbudowany z rzeczywistych rozmów.
Słowami klienta
“Soba Labs put an AI sales agent into production for us. It qualifies inbound leads, answers only from our current product material, and leaves the sales team a structured record of every conversation.”
Karol Bzik, CPO, Open Loyalty
Źródła techniczne
Ostatnia aktualizacja: