Warsztaty AI discovery: jak odebrać wyniki przed wdrożeniem

Warsztaty AI discovery powinny dać osobie odpowiedzialnej za budżet podstawę do decyzji: budować, integrować, zmienić założenia czy zatrzymać projekt. Odbierz wyniki wtedy, gdy Twój zespół potrafi powiązać rekomendację z powtarzalnymi testami, dostępem do danych, założeniami kosztowymi i odpowiedzialnością za dalsze prace.

Poniższa karta pomoże Ci przeprowadzić spotkanie podsumowujące. Oddziela odbiór analizy od zgody na udostępnienie funkcji AI klientom.

Ustal, na co zgadzasz się przy odbiorze

Możesz przyjąć wyniki analizy, jeśli odpowiadają na ustalone przy zleceniu pytanie i pozwalają zdecydować, czy finansować dalsze prace. Wynik może być negatywny. Rekomendacja zatrzymania projektu, poparta dowodami, też może uzasadniać odbiór prac.

Przed prezentacją zapisz pytanie: „Czy warto sfinansować asystenta, który przygotowuje projekty odpowiedzi na podstawie zatwierdzonej dokumentacji, a konsultant sprawdza każdą z nich?”. To znacznie węższy zakres niż „Czy możemy zautomatyzować obsługę klienta?”.

W protokole rozdziel trzy decyzje:

• Przyjmujemy wyniki analizy: dowody odpowiadają na uzgodnione pytanie, również gdy odpowiedź jest niekorzystna.
• Finansujemy następny etap: określony zakres budowy lub integracji ma właściciela i warunki rozpoczęcia.
• Dopuszczamy funkcję do użytkowania: wdrożone rozwiązanie przeszło sprawdzenia właściwe dla środowiska, w którym będzie działać.

Działający prototyp może pomóc w pierwszej decyzji, nie spełniając jeszcze warunków ostatniej.

Karta odbioru wyników discovery AI

Przy każdym wierszu wpisz odnośnik do dowodu, osobę odbierającą oraz wynik: przyjęte, do uzupełnienia albo poza uzgodnionym zakresem. Zakres wymaganych dowodów ustal przy zlecaniu analizy, zamiast dokładać nowe obowiązki na spotkaniu końcowym.

1. Efekt dla użytkownika

• Potrzebny dowód: Jeden proces, jego stan wyjściowy i zmiana uzasadniająca inwestycję.
• Poproś o uzupełnienie, gdy: celem jest „użyć AI”, bez mierzalnej zmiany w pracy użytkownika lub zespołu.

2. Dostęp do danych

• Potrzebny dowód: Spis źródeł, reprezentatywne próbki, granice dostępu i nierozstrzygnięte uprawnienia.
• Poproś o uzupełnienie, gdy: eksperyment korzystał z danych niedostępnych dla docelowego użytkownika.

3. Ocena jakości

• Potrzebny dowód: Dane testowe, oczekiwane zachowanie, zasady oceny, zapis wyników i błędnych przypadków.
• Poproś o uzupełnienie, gdy: pokazano wskaźnik bez zbioru testowego lub definicji.

4. Rozwiązanie techniczne

• Potrzebny dowód: Przepływ danych, punkty integracji, alternatywy i założenia.
• Poproś o uzupełnienie, gdy: zespół przejmujący prace nie wie, co trzeba zmienić w obecnych systemach.

5. Koszty działania

• Potrzebny dowód: Założenia o użyciu, koszty modeli i narzędzi, pracy osoby sprawdzającej oraz utrzymania.
• Poproś o uzupełnienie, gdy: kalkulacja uwzględnia wywołania modelu, ale pomija sprawdzanie odpowiedzi.

6. Ryzyko i tryb awaryjny

• Potrzebny dowód: Skutki błędu, eskalacja, ścieżka ręczna i warunki zatrzymania.
• Poproś o uzupełnienie, gdy: nie wiadomo, co się dzieje przy braku źródła lub awarii usługi.

7. Odpowiedzialność i dalszy zakres

• Potrzebny dowód: Osoba podejmująca decyzję, właściciel realizacji, otwarte prace i warunki finansowania.
• Poproś o uzupełnienie, gdy: rekomendacja „przechodzimy do MVP” nie wskazuje zakresu ani odpowiedzialnej osoby.

Nie chodzi o zamówienie siedmiu dokumentów. Wystarczy zwięzła rekomendacja z odnośnikami do materiałów, jeśli ktoś spoza zespołu prowadzącego analizę potrafi z niej skorzystać.

Sprawdź, czy test można powtórzyć

Przy funkcji opartej na modelu językowym poproś o możliwość ponownego przeprowadzenia oceny. Wytyczne OpenAI dotyczące ewaluacji zalecają określenie celu, zebranie danych testowych, wybór miar i porównywanie wyników. Uwzględniają przypadki brzegowe, ocenę człowieka i dalsze testowanie po zmianach systemu.

Dla asystenta obsługi klienta przejdź z zespołem przez następujące sytuacje:

• odpowiedź znajduje się w aktualnym źródle dostępnym dla użytkownika;
• źródła nie zawierają odpowiedzi;
• dokumenty są sprzeczne albo nieaktualne;
• pytanie dotyczy danych innego klienta;
• wyszukiwanie nie działa lub model jest niedostępny;
• projekt odpowiedzi brzmi wiarygodnie, ale nie ma pokrycia w źródłach i wymaga odrzucenia.

Zachowaj dane wejściowe, wersje źródeł, istotną konfigurację, odpowiedzi i oceny. Uwzględnij też przykłady, których nie używano do dopracowywania prototypu. Zapytaj, które błędy wykluczają dalsze prace, a które można ograniczyć przez zawężenie zastosowania.

Nie przenoś progu jakości z cudzego produktu. Ustal kryterium z osobą, która zna skutki błędnej odpowiedzi. NIST AI RMF Core wskazuje na dokumentowanie testów i ocenę w warunkach zbliżonych do docelowych, a także rozważenie rozwiązań bez AI i decyzji o kontynuacji prac.

Przykład: integracja, zmiana zakresu albo zatrzymanie

Załóżmy, że zespół rozwijający SaaS zleca analizę asystenta przygotowującego odpowiedzi dla działu obsługi. Poniżej są warianty decyzji, nie wyniki wdrożenia u klienta.

Zleć ograniczoną integrację. Uzgodnione testy potwierdzają przydatność projektów odpowiedzi opartych na zatwierdzonej dokumentacji. Kontrola dostępu pasuje do obecnego produktu, a kierownik obsługi odpowiada za sprawdzanie treści. Kolejny etap obejmuje przygotowywanie propozycji bez automatycznej wysyłki, odnośniki do źródeł i ręczną obsługę spraw, w których asystent nie pomoże. Nierozstrzygnięte wymagania wdrożeniowe trafiają do zakresu realizacji.

Zawęź zastosowanie. Proste pytania o dokumentację wypadają dobrze, ale odpowiedzi dotyczące kont klientów wymagają uprawnień i bieżących danych, których eksperyment nie sprawdził. Przyjmij ten wniosek, jeśli odpowiada na uzgodnione pytanie discovery. W następnym etapie zleć asystenta korzystającego wyłącznie z dokumentacji; możliwość pobierania danych z kont klientów sprawdź osobno, zanim zamówisz tę funkcję.

Zatrzymaj proponowaną budowę. Materiały źródłowe są niespójne albo poprawianie odpowiedzi pochłania tyle pracy, że dowody nie uzasadniają spodziewanej korzyści. Zamknij analizę z uzasadnieniem i warunkiem powrotu do pomysłu. Lepszą inwestycją może być uporządkowanie dokumentacji lub poprawa zwykłej wyszukiwarki.

Każdemu z tych wariantów może towarzyszyć podobne demo. O decyzji przesądzają dowody i warunki działania rozwiązania.

Sprawdź przekazanie prac zespołowi wdrożeniowemu

Poproś inżyniera i właściciela procesu, którzy nie prowadzili eksperymentu, aby przeanalizowali jeden test, w którym asystent popełnił błąd. Czy potrafią znaleźć źródło, wyjaśnić oczekiwane zachowanie, powtórzyć test i wskazać osobę decydującą o dalszym postępowaniu?

Jeśli nie, poproś o brakujące wyjaśnienie lub dostęp w ramach uzgodnionego przekazania. Osobno ustal dostęp do kodu, danych, konfiguracji i dokumentacji. Specyfikacja do wykorzystania przez inny zespół wymaga użytecznych materiałów i uzgodnionych uprawnień, a nie samego pliku PDF z taką nazwą.

Przed zleceniem realizacji zapisz krótki zakres: co się zmieni, co pozostaje ręczne, jakie wyniki trzeba poprawić, kto odbiera funkcję i co może wstrzymać jej uruchomienie. Jeśli rozwijasz istniejący produkt, skorzystaj z poradnika jak zaplanować pierwszy proces z AI w SaaS. Po pozytywnej decyzji integracja AI z produktem jest osobnym etapem prac.

Zacznij od decyzji, którą musisz podjąć

Awakast prowadzi discovery, gdy dane, wykonalność lub uzasadnienie inwestycji są jeszcze niejasne, oraz realizuje integracje z istniejącymi produktami. Przynieś pytanie biznesowe, opis procesu, dostępne dane i skutki błędnej decyzji. Na tej podstawie możemy ustalić zakres analizy.

Omów z Awakast zakres analizy przed wdrożeniem AI.