Presja, by dodawać AI do wszystkiego
Każdy plan rozwoju oprogramowania niesie dziś presję, by uwzględnić AI. Inwestorzy pytają o nią na spotkaniach, konkurenci ogłaszają ją w komunikatach prasowych, a klienci zaczęli się jej w połowie spodziewać. Efektem jest fala funkcji dodawanych dlatego, że technologia jest widoczna i dostępna, a nie dlatego, że wymagał ich jakiś problem w produkcie. Chatbot pojawia się na stronie, która naprawdę potrzebowała czytelniejszego formularza kontaktowego. Funkcja streszczania trafia na ekran, z którego czytaniem nikt nie miał problemu.
To postawienie pytania na głowie. AI to nie strategia ani cel. To narzędzie o konkretnych mocnych stronach i konkretnych kosztach, jak baza danych czy kolejka wiadomości, a żaden kompetentny zespół nie dodaje kolejki do produktu dlatego, że kolejki są modne. Dodaje ją, gdy wymaga tego konkretny problem.
Przydatne pytanie nigdy więc nie brzmi „jak dodać AI”. Brzmi: które problemy w tym konkretnym produkcie naprawdę do niej pasują, a które lepiej rozwiązać tak, jak rozwiązywano je zawsze. Uczciwa odpowiedź na to pytanie jest warta więcej niż jakikolwiek model, bo stanowi różnicę między funkcją, która zarabia na swoje miejsce, a taką, która po cichu kosztuje pieniądze i zaufanie.
W czym AI jest naprawdę dobra
AI zarabia na swoje miejsce przy rozpoznawalnym zestawie problemów. Najwyraźniejszym jest rozumienie nieuporządkowanych danych wejściowych: swobodnego tekstu, obrazów, dźwięku, zeskanowanych dokumentów. Model może przeczytać maila od klienta i skierować go do właściwego zespołu, wyciągnąć kwotę ze zdjęcia paragonu albo przepisać nagraną rozmowę. Zwykły kod jest tu bezradny, bo reguł jest w praktyce nieskończenie wiele.
Jest też mocna w generowaniu i streszczaniu. Napisanie pierwszej wersji opisu produktu, skrócenie długiego wątku obsługi do trzech zdań, zamiana luźnych notatek w czysty tekst: to zadania, w których wystarczająco dobra wersja robocza, przygotowana szybko, naprawdę oszczędza czas. Przydaje się też przy rozmytej klasyfikacji, gdzie granica między kategoriami jest prawdziwa, ale nie da się jej zapisać jako jawnych reguł.
Wspólnym mianownikiem wszystkich tych przypadków jest niejednoznaczność. Gdy dane wejściowe są chaotyczne, a reguł nie da się w pełni określić z góry, model potrafi zrobić to, czego nie potrafi funkcja deterministyczna. To jest prawdziwa granica, którą warto wyznaczyć. Nie nowoczesne kontra staroświeckie, nie sprytne kontra proste. Niejednoznaczne kontra jasno określone, a AI należy zdecydowanie do strony niejednoznacznej.
Co po cichu pogarsza
Ta sama elastyczność, która czyni AI potężną przy niejednoznacznych problemach, czyni ją obciążeniem przy jasno określonych. Obliczanie ceny, stosowanie rabatu, egzekwowanie uprawnień, przenoszenie pieniędzy między kontami, sprawdzanie, czy adres e-mail ma poprawny format: te problemy mają dokładnie jedną poprawną odpowiedź. System, który daje poprawną odpowiedź przez większość czasu, nie jest tu pomocną funkcją. To wada z przyjazną nazwą.
Używanie modelu do takiej pracy zamienia gwarantowany wynik na probabilistyczny i płaci za to obniżenie jakości opóźnieniem i kosztem każdego zapytania. To programistyczny odpowiednik zastąpienia kalkulatora bardzo oczytanym współpracownikiem, który zwykle ma rację. Nikt nie wybrałby tego celowo, a jednak produkty robią to zawsze, gdy AI traktuje się jako ulepszenie, a nie narzędzie o konkretnym zadaniu.
Jest też subtelniejszy koszt. AI utrudnia rozumienie systemów. Funkcja deterministyczna zawodzi za każdym razem w ten sam sposób, więc można ją wyczerpująco przetestować i potem jej ufać. Model może zwrócić inną odpowiedź na te same dane wejściowe w różne dni, co spowalnia debugowanie, utrudnia obsługę i naprawdę zaciemnia odpowiedzialność. Gdy klient pyta, dlaczego system coś zrobił, a nikt nie potrafi odpowiedzieć, to prawdziwy koszt, nawet jeśli nigdy nie pojawia się na fakturze.
Koszt, którego nie widać w demo
Funkcja AI ma nietypowy kształt kosztów. Prototyp jest niezwykle tani, a utrzymanie zaskakująco drogie. Przekonujące demo można zbudować w jedno popołudnie, i właśnie dlatego tak wiele z nich zostaje zatwierdzonych. Demo ukrywa wszystko, co pojawia się dopiero na dużą skalę.
Najważniejsze są trzy ukryte koszty. Pierwszy to pieniądze: inferencja jest rozliczana za zapytanie, więc funkcja darmowa w demo staje się pozycją kosztową, która rośnie z każdym aktywnym użytkownikiem. Drugi to opóźnienie: model może odpowiadać przez odczuwalne sekundy, a użytkownicy czują każdą z nich. Trzeci to dokładność: model ma sufit poniżej stu procent, a przepaść między tym sufitem a doskonałością trzeba uwzględnić w projekcie, a nie wymarzyć sobie, że jej nie ma.
Dlatego ta decyzja należy do etapu projektowania, a nie do etapu marketingu. Pytania, które naprawdę mają znaczenie, są konkretne. Ile kosztuje tu błędna odpowiedź? Kto ją zauważy, gdy się pojawi? Ile ta funkcja kosztuje za użycie, gdy przyjdzie prawdziwa skala? Jeśli odpowiedzi są niewygodne, uczciwy wniosek zwykle brzmi: ta funkcja należy do zwykłego kodu.
Prosty test przed budową
Zanim zdecydujesz się na funkcję AI, jedno pytanie oddziela dobre pomysły od drogich: co się stanie, gdy się pomyli? Nie „jeśli”, tylko „gdy”, bo na pewno się pomyli. Jeśli odpowiedź brzmi, że użytkownik zobaczy nieco słabszą wersję roboczą i ją poprawi, funkcja dobrze pasuje. Jeśli odpowiedź brzmi, że pieniądze zostaną błędnie przelane, jeden klient zobaczy dane innego albo zostanie złożone wiążące zobowiązanie, funkcja w ogóle nie należy do modelu.
Drugie pytanie jest niemal równie przydatne. Czy staranny człowiek, mając te same dane wejściowe, też uznałby to za naprawdę trudne? Jeśli tak, niejednoznaczność jest prawdziwa i AI może być właściwym narzędziem. Jeśli kompetentna osoba uznałaby zadanie za oczywiste i mechaniczne, oczywisty i mechaniczny kod wykona je szybciej, taniej i za każdym razem poprawnie. Zadane wcześnie, te dwa pytania zapobiegają większości żalu.
Projektowanie dla modelu, który czasem się myli
Tam, gdzie AI ma swoje miejsce, system trzeba zbudować wokół pewności, że czasem się pomyli, a nie nadziei, że nie. W praktyce oznacza to kilka twardych zasad. Zostaw człowieka w pętli przy każdej decyzji o konsekwencjach, żeby model proponował, a człowiek rozstrzygał. Spraw, by wynik modelu dało się banalnie łatwo przejrzeć i poprawić. I nigdy nie pozwalaj modelowi po cichu wykonać działania, którego nie da się cofnąć.
Te ograniczenia to nie brak ambicji. To one pozwalają funkcji być ambitną w bezpieczny sposób. Narzędzie do streszczeń, które pisze tekst i pozwala użytkownikowi go edytować, jest naprawdę użyteczne i niesie niemal zerowe ryzyko. Ten sam model podłączony tak, by automatycznie wysyłać streszczenie klientowi, to obciążenie czekające na swój pierwszy zły dzień.
Traktowana w ten sposób AI przestaje być sednem produktu i staje się jednym z wielu komponentów. Używa się jej wszędzie tam, gdzie niejednoznaczność czyni ją najlepszym dostępnym narzędziem, a wszędzie indziej ogranicza się ją zwykłym, przewidywalnym, testowalnym kodem. Produkt zaprojektowany według tej zasady jest zarówno bardziej użyteczny, jak i bardziej wiarygodny niż taki, w którym dodanie AI było celem, a szukanie uzasadnienia przyszło później.
