Technologia sama w sobie nie gwarantuje przyjęcia: Lekcje z budowy wewnętrznego czatu AI

Gdy przyjęcie sztucznej inteligencji przyspieszyło w różnych branżach, wdrożenie czatu do wsparcia nowo uruchomionej aplikacji wewnętrznej wydawało się logiczną decyzją. Jednak sama aplikacja wyzwała konwencjonalne oczekiwania użytkowników. Wprowadziła nowe przepływy pracy oparte na wschodzącej technologii, której większość użytkowników nie znała.

Aby zmniejszyć tarcie i poprawić przyjęcie, czatbot został zaprojektowany, aby odpowiadać na pytania dotyczące aplikacji i podstawowej technologii. Celem było pomoc użytkownikom w zrozumieniu nie tylko tego, co należy robić, ale także dlaczego system zachowywał się w określony sposób. Wierzyliśmy, że dostarczanie kontekstowych wyjaśnień przyspieszy uczenie i zmniejszy zakłopotanie.

Od samego początku agent AI został postrzegany jako rozwiązanie o ograniczonym zakresie. Został zaprojektowany ściśle do wsparcia dokumentacji i pomocy użytkownikom. Pojęciowo czatbot miał służyć jako dynamiczna замiana tradycyjnego dokumentu z często zadawanymi pytaniami, oferując rozmowne, przeszukiwalne i ciągle dostępne interfejsy z rozszerzoną funkcjonalnością poza statyczną zawartością.

Aby zintegrować agenta z wewnętrznym środowiskiem czatu organizacji, musieliśmy zrozumieć, jak są renderowane komunikaty strukturalne, jak jest przechowywana historia rozmów i jak system identyfikuje uczestników w wątkach. To pozwoliło nam określić podstawowe zmienne niezbędne do rozpoczęcia przetwarzania pytań użytkowników.

Ugruntowanie modelu: Od halucynacji do niezawodnego kontekstu

Duże modele językowe są potężne, ale bez kotwiczenia kontekstowego są skłonne do halucynacji. Aby rozwiązać ten problem, wdrożyliśmy technikę wektorowego osadzania.

Przewodniki użytkowników, dokumentacja wewnętrzna i wizja produktu zostały przekształcone w numeryczne reprezentacje wektorowe tekstu. Te osadzania uchwyciły znaczenie semantyczne, pozwalając systemowi dopasować pojęcia, a nie polegać na prostym dopasowaniu słów kluczowych.

Gdy użytkownik zadał pytanie, system przekształcił zapytanie w reprezentację wektorową i porównał ją z przechowywanymi osadzaniami. Pobrał najbardziej semantycznie istotne dokumenty i wstrzyknął je do promtu modelu. Model wygenerował odpowiedź ugruntowaną w tych konkretnych dokumentach, często podsumowując istotne informacje.

Ten podejście znacznie poprawiło dokładność odpowiedzi. Zamiast generować odpowiedzi oparte wyłącznie na ogólnej wiedzy, model odpowiedział, korzystając z własnej dokumentacji organizacji jako kontekstu.

Ukryta złożoność zarządzania kontekstem

Było niezbędne, aby uwzględnić historię rozmów w promcie, aby bot mógł interpretować pytania następcze i utrzymywać ciągłość. Bez historii interakcje stały się fragmentaryczne i powtarzalne. Użytkownicy często udoskonalali swoje pytania stopniowo, a bez kontekstu bot nie mógł interpretować odniesień, takich jak „ta opcja” lub „poprzedni krok”.

Jednak uwzględnienie zbyt dużej ilości historii stworzyło inny problem: limity tokenów. Zdarzają się one, gdy modele językowe truncate dane wejściowe, które przekraczają ich maksymalne okno kontekstowe. Jeśli pytanie lub rozmowa stały się zbyt długie, istotne informacje mogły zostać utracone. To nie spowodowało jawnej błędu, ale raczej obniżyło jakość odpowiedzi lub wpłynęło na dokładność pobierania.

Aby złagodzić to, wdrożyliśmy strategie, aby kontrolować rozmiar promtu, priorytetować istotną zawartość i monitorować długość pytań. Eksperymentowaliśmy z podsumowywaniem starszych wiadomości i selektywnym uwzględnianiem tylko najbardziej istotnych części rozmowy. Kontekst był kluczowy, ale musiał być starannie zarządzany.

Rozszerzanie możliwości i tworzenie zakłopotania

Poza odpowiadaniem na pytania dotyczące dokumentacji, rozszerzyliśmy możliwości bota, dodając funkcje serwerowe, które mogły pobrać pewne publiczne informacje bezpośrednio z aplikacji. To pozwoliło użytkownikom pobrać dane z czatu bez logowania się do samej aplikacji. Pomysł polegał na zmniejszeniu tarcia i wzmocnieniu czatbota jako użytecznego interfejsu, a nie tylko warstwy wiedzy statycznej.

Ten dodatek wywołał zakłopotanie u niektórych użytkowników. Gdy bot zaczął pobrać dane na żywo, użytkownicy zaczęli pytać go o wykonanie działań, które wymagały bezpośredniej interakcji wewnątrz platformy. Założyli, że czatbot może zastąpić operacyjne kroki, w tym te, które wymagały uwierzytelnienia lub celowego wykonania wewnątrz platformy.

Bot nie został zaprojektowany do wykonywania tych działań, ale różnica między pomocą informacyjną a wykonaniem operacyjnym nie była zawsze jasna.

Integracja danych na żywo wprowadziła nowe rozważania techniczne. Musieliśmy określić, kiedy pytanie powinno przejść przez pobieranie oparte na osadzaniu i kiedy powinno wywołać wywołanie serwerowe. Ta logika decyzyjna wymagała starannego zaprojektowania. Dodatkowo musieliśmy dostosować odpowiedzi, aby łagodnie obsłużyć wyjątki techniczne i uniknąć eksponowania surowych błędów systemu użytkownikom.

Wielojęzyczność nie jest automatyczna

Podczas testowania zrealizowaliśmy, że bot konsekwentnie działał lepiej w języku angielskim niż w innych językach używanych wewnątrz Jalasoft. Głównym powodem był strukturalny: większość dokumentacji użytej do generowania osadzań została napisana w języku angielskim, a model osadzania, który wybraliśmy, został zoptymalizowany pod kątem angielskiej podobieństwa semantycznego.

Nie obsługiwał on pobierania międzyjęzykowego ani porównań semantycznych między językami. W rezultacie zapytania w języku nieangielskim często pobierały mniej istotną dokumentację, prowadząc do słabszych odpowiedzi.

To podkreśliło ważną wiedzę: wielojęzyczność nie jest automatyczna.

Gdy oczekiwania przekraczają zakres

Aby kontrolować koszty użycia, wdrożyliśmy dzienny limit liczby pytań, które użytkownicy mogli zadać. Jednak nie wyraźnie ograniczyliśmy zakresu tych pytań. Użytkownicy byli wolni pytać o cokolwiek.

Otwartość ta doprowadziła do nieoczekiwanych wzorców użycia. Niektórzy użytkownicy zaczęli wchodzić w interakcje z botem do celów osobistych lub eksploracyjnych niezwiązanych z aplikacją. Z czasem oczekiwania przerosły rolę bota, tworząc lukę między tym, co użytkownicy spodziewali się, a tym, co zostało zaprojektowane do obsługi.

To stopniowo zmniejszyło jego postrzeganą użyteczność. Użycie zmalało, a czatbot został ostatecznie wycofany, a wysiłki zostały przekierowane na ponowne zaprojektowanie samej aplikacji, aby uczynić ją bardziej intuicyjną i łatwiejszą w użyciu.

Rzeczywista lekcja: Projektowanie interakcji

Z punktu widzenia inżynieryjnego system działał rozsądnie. Pobrał dokumentację, uwzględnił historię rozmów, zmniejszył halucynacje za pomocą osadzań, obsłużył wywołania serwerowe i zarządzał rozmiarem promtu. Architektura działała zgodnie z zamierzeniem.

Ale brakowało mu zamierzonego projektowania interakcji.

Bot nie klarownie ukształtował rozmów. Nie konsekwentnie wzmocnił swojego zakresu. Nie prowadził użytkowników przykładami strukturalnymi tego, co mógł i nie mógł zrobić. Odpowiadał na pytania, ale nie ustanawiał oczekiwań.

Nauczyliśmy się, że systemy sztucznej inteligencji konwersacyjnej wymagają więcej niż silne modele i uporządkowane dane. Wymagają starannie zaprojektowanych oczekiwań. Użytkownicy potrzebują jasności co do roli agenta, jego granic i jego siły. System musi proaktywnie dostarczać przykładowe prompty, wyjaśniać ograniczenia i kierować pytania poza zakresem w sposób ciągły.

Bez tego zamierzonego ramowania nawet technicznie poprawna implementacja może mieć trudności z utrzymaniem wartości. Użytkownicy mogą przecenić możliwości lub rozłączyć się, gdy nieujawnione oczekiwania nie są spełnione.

Kluczowa wiedza jest prosta, ale potężna.

Budowanie sztucznej inteligencji konwersacyjnej nie jest tylko wyzwaniem technicznym. Jest to również wyzwanie projektowania interakcji.

Silny kontekst, dokładne pobieranie i solidna architektura są niezbędne, ale niewystarczające. Skuteczność systemu zależy równie od tego, jak definiuje swoją rolę, komunikuje swoje granice i kształtuje oczekiwania użytkowników.

Technologia sama w sobie nie gwarantuje przyjęcia. Jasne projektowanie interakcji tak.