Pokaz to tania część. Jak zabudżetować resztę

Pokaz poszedł dobrze. Zbudowany w dwa tygodnie, odpowiedział na pytania zadane na sali, a oczywistym następnym pytaniem było, ile potrwa wdrożenie. Uczciwa odpowiedź jest zwykle wyraźnie dłuższa, niż sugeruje pokaz — i nie dlatego, że pokaz był sztuczką.

Prototypy AI są nietypowo łatwe do zbudowania, bo widoczną część robi model. Nie robi natomiast tego, co pozwala ludziom polegać na wyniku: stwierdzenia, czy jest poprawny, znalezienia właściwego dokumentu, zmieszczenia się w koszcie, przestrzegania tego, kto co może zobaczyć, i przetrwania zmiany. Ta praca to większość projektu, a w pokazie prawie jej nie widać.

Co leży pod pokazem

Nie jako techniczna lista kontrolna, tylko w kategoriach, które osoba dysponująca budżetem może sprawdzić.

Sposób, żeby wiedzieć, czy jest dobrze. Zestaw prawdziwych przypadków ze znanymi odpowiedziami, oceniany przy każdej zmianie. Bez niego nikt nie powie, czy wersja z przyszłego miesiąca jest lepsza od obecnej, a projekt zwalnia, aż ktoś przestanie go w ogóle dotykać.

Wyszukiwanie, które znajduje właściwą rzecz. Pokaz dostał starannie wybraną garść dokumentów. Produkcja ma każdą wersję każdego dokumentu, łącznie z nieaktualnymi. Większość złych odpowiedzi zaczyna się tutaj.

Koszt i szybkość w budżecie. Mierzone na żądanie i na zadanie, bo funkcja kosztująca grosze w pokazie przy produkcyjnym wolumenie potrafi kosztować prawdziwe pieniądze — a rachunek przychodzi po podjęciu zobowiązania.

Uprawnienia i zachowanie przy awarii. Kto może zobaczyć którą odpowiedź i co system robi, gdy nie umie odpowiedzieć: odmawia, przekazuje sprawę człowiekowi czy produkuje coś wiarygodnego, czego nikt nie wyłapie.

Możliwość zmiany. Monitoring, dokumentacja i wdrożenie, które Wasz zespół potrafi prowadzić. System, który może modyfikować tylko jego autor, jest zależnością, a nie aktywem.

Infografika

Co leży pod pokazem

1. 01PokazModel odpowiadający na dobrze dobrane pytania. Część widoczna.
2. 02EwaluacjaPrawdziwe przypadki ze znanymi odpowiedziami, oceniane przy każdej zmianie.
3. 03WyszukiwanieZnalezienie właściwego dokumentu spośród wszystkich jego wersji.
4. 04Koszt i opóźnieniaMierzone na żądanie i na zadanie, w ramach budżetu.
5. 05Uprawnienia i awarieKto może co zobaczyć i co się dzieje, gdy brak odpowiedzi.
6. 06WłasnośćWdrożenie, monitoring i dokumentacja, które Wasz zespół utrzyma.

Finansujcie etapami, a nie jedną liczbą

Typowy błąd to prośba o jedną wycenę od pokazu do pełnego wdrożenia. Nikt nie poda uczciwej, więc dostajecie albo napompowaną, albo optymistyczną — i obie są gorsze niż rozłożenie decyzji na etapy.

Układ, który działa: krótki pierwszy etap, który buduje zestaw ewaluacyjny i wprowadza jedną kompletną ścieżkę na produkcję dla małej grupy. Jest dość mały, żeby wycenić go uczciwie, i wyciąga niewiadome — nieporządne dane, model uprawnień, którego nikt nie spisał, koszt na żądanie przy prawdziwym wolumenie — póki są jeszcze tanie. Decyzję o poszerzeniu podejmujecie potem na podstawie tego, co ten etap zmierzył, a nie tego, co zasugerował pokaz.

Ile to kosztuje Was w czasie i uwadze

Więcej niż pokaz, mniej, niż ludzie się obawiają. Praca wymaga właściciela produktu, który może rozstrzygnąć, co jest poprawną odpowiedzią, kilku ekspertów dziedzinowych do budowy przypadków ewaluacyjnych, dostępu do prawdziwych danych na prawdziwych uprawnieniach i Waszych inżynierów zaangażowanych od początku, jeśli macie to potem prowadzić sami.

Najtrudniej zwykle o ekspertów. To ich czas zamienia „odpowiedzi wyglądają dobrze” w zestaw przypadków ze znanymi odpowiedziami, a mają też swoją codzienną pracę. Zarezerwujcie ich godziny, zanim projekt ruszy, a nie wtedy, gdy zespół zacznie na nie czekać.

Jak ocenić tego, kto to zbuduje

Zapytajcie, co budują najpierw. Jeśli funkcje, projekt będzie szybki przez trzy miesiące, a potem wolny. Jeśli sposób mierzenia jakości — robili to już wcześniej.

Zapytajcie, skąd będą wiedzieć, że zmiana pogorszyła sprawę. Konkretna odpowiedź mówi o przypadkach i ocenach. Mglista — o starannym testowaniu.

Zapytajcie, co dostarcza pierwszy etap. Coś działającego na produkcji dla małej grupy, a nie raport. Raport po etapie, który miał coś uruchomić, oznacza, że ryzyko przesunięto, a nie zmniejszono.

Zapytajcie o koszt na zadanie, a nie na token. Dostawca, który po pierwszym etapie nie umie go podać, nie zmierzył go.

Jak wygląda dobry wynik

Nie większy pokaz. System na produkcji, na prawdziwych danych, z miarą jakości, która drgnie, gdy coś się zmieni, kosztem na zadanie czytelnym dla działu finansów i zespołem po Waszej stronie, który potrafi go zmieniać bez dzwonienia do kogokolwiek.

To zakres inżynierii aplikacji AI-native: część po pokazie, która stanowi większość pracy i rozstrzyga, czy pokaz był wart zbudowania.