AI w kalkulatorze budowlanym: skan LIDAR od prototypu do produktu

Masz w produkcie funkcję z AI, która na prezentacji robi wrażenie, i zastanawiasz się, czy można ją już dać wszystkim klientom? AI w kalkulatorze budowlanym dobrze pokazuje ten problem, bo błąd w pomiarze albo w wyliczeniu przekłada się wprost na źle policzoną ofertę wykonawcy. W tym tekście opisuję, jak przy kolejnej wersji kalkulatora dla procalc.com.au podchodzimy do pomiaru z telefonu i analizy opłacalności inwestycji oraz jak oddzielamy to, co gotowe do produktu, od tego, co zostaje eksperymentem.

Kalkulator kosztów budowy i co do niego dokładamy

procalc.com.au to kalkulator kosztów budowy dla wykonawców z Australii, rozwijany pod marką Builders Brief. Wykonawca ma szybko przejść od projektu i pomiarów do wyceny, którą może pokazać klientowi.

Wcześniej do produktu trafił odczyt rysunków przez AI z weryfikacją przez człowieka. Opisałem tę drogę w tekście o tym, jak AI czyta rysunki budowlane. Kolejna wersja dokłada dwa kierunki:

• Pomiar z telefonu, czyli skan pomieszczenia czujnikiem LIDAR, który ma część telefonów i tabletów. Wykonawca stoi na budowie i zamiast taśmy dostaje przybliżony model przestrzeni.
• FeasiPro, moduł do analizy opłacalności inwestycji, który pomaga ocenić, czy przedsięwzięcie budowlane w ogóle się spina, zanim ktoś zacznie liczyć szczegóły.

Przy obu kierunkach AI w kalkulatorze budowlanym pełni rolę pomocnika, a nie sędziego. Oba brzmią dobrze w prezentacji. Pytanie, które zadajemy przy każdym z nich, brzmi inaczej: czy wykonawca może na tym oprzeć ofertę bez ręcznej poprawki.

Kiedy AI w kalkulatorze budowlanym jest gotowe do produktu

Funkcja z AI jest gotowa do produktu wtedy, gdy wiemy, kiedy się myli, i użytkownik też to widzi. Sama skuteczność na pokazie nie wystarczy. Przy pomiarze z telefonu i przy analizie opłacalności sprawdzam te same punkty:

1. Czy wynik da się zweryfikować. Użytkownik musi widzieć, skąd wziął się wymiar albo wniosek, i mieć możliwość poprawienia go ręcznie.
2. Czy znamy przypadki, w których funkcja zawodzi. Dla skanu to na przykład słabe światło, lustra, duże przeszklenia albo zagracone pomieszczenie. Te przypadki muszą być opisane, a nie odkryte przez klienta.
3. Czy działa na sprzęcie, który klienci naprawdę mają. Jeśli czujnik jest tylko w części urządzeń, reszta użytkowników musi mieć inną drogę do tego samego wyniku.
4. Czy błąd jest tani. Pomyłka, którą widać od razu i łatwo poprawić, jest akceptowalna. Pomyłka, która po cichu zmienia cenę oferty, nie jest.
5. Czy umiemy to utrzymać. Funkcja zależna od modelu AI wymaga monitorowania, bo model po aktualizacji może odpowiadać inaczej.

Jeśli funkcja nie przechodzi któregoś z tych punktów, nie wyrzucamy jej. Zostaje jako eksperyment, dostępny na przykład dla wybranych użytkowników albo z wyraźnym oznaczeniem, że wynik trzeba sprawdzić.

Prototyp, eksperyment, produkt: trzy różne obietnice

Prototyp odpowiada na pytanie, czy coś w ogóle da się zrobić. Eksperyment sprawdza, czy prawdziwi użytkownicy z tego korzystają i czy rozumieją ograniczenia. Produkt to obietnica, że funkcja działa przewidywalnie, a jeśli nie, to użytkownik wie, co zrobić.

Najczęstszy błąd, jaki widzę w projektach z AI, to przeskok z prototypu od razu do produktu. Prototyp robi wrażenie, więc zarząd chce go od razu w cenniku. Potem pierwsze zgłoszenia od użytkowników pokazują przypadki, których nikt nie testował. Dlatego przy funkcjach z AI planuję etap eksperymentu z góry, z tym samym podejściem, które opisałem w tekście o tym, jak zaplanować MVP.

AI w kalkulatorze budowlanym wymaga tej ostrożności bardziej niż wiele innych zastosowań. Wykonawca, który raz dostał zły wymiar i przez niego stracił na zleceniu, nie wróci do tej funkcji, nawet jeśli później będzie działała lepiej. Zaufanie do narzędzia, które liczy pieniądze, buduje się wolno, a traci po jednej pomyłce.

UX projektowany z pomocą AI: co przyspiesza, czego nie zastąpi

Przy kolejnej wersji kalkulatora korzystamy z AI także przy projektowaniu interfejsu. To realnie przyspiesza wczesne etapy, ale nie zastępuje rozmowy z użytkownikiem ani decyzji projektowych.

Gdzie AI pomaga przy UX:

• szybkie warianty ekranów i układów do porównania,
• pierwsze wersje tekstów w interfejsie, komunikatów błędów i podpowiedzi,
• przegląd ekranów pod kątem spójności nazw i kolejności kroków,
• szkice ścieżek użytkownika, które potem weryfikujemy z ludźmi z branży.

Czego AI nie zastąpi:

• wiedzy, jak wykonawca naprawdę pracuje na budowie, często w rękawicach i w słońcu,
• decyzji, które dane są w danym kroku najważniejsze,
• testu z prawdziwym użytkownikiem, który pokazuje, gdzie się gubi,
• odpowiedzialności za to, że ekran nie wprowadza w błąd przy liczeniu pieniędzy.

W praktyce AI skraca drogę do pierwszej wersji ekranu, ale ostatnie słowo należy do człowieka, który rozumie branżę i użytkownika.

Lista kontrolna przed wejściem funkcji AI do produktu

Zanim funkcja z AI trafi do wszystkich klientów, przechodzę przez krótką listę. Każdy punkt powinien mieć odpowiedź na piśmie:

• opisane przypadki, w których funkcja zawodzi, i komunikat dla użytkownika w takiej sytuacji,
• ręczna ścieżka awaryjna dla urządzeń i danych, których AI nie obsłuży,
• możliwość poprawienia wyniku przed użyciem go w wycenie,
• monitoring jakości po wdrożeniu i kanał na zgłoszenia od użytkowników,
• decyzja, kto odpowiada za funkcję po stronie produktu i po stronie zespołu technicznego.

Jeśli planujesz AI w kalkulatorze budowlanym albo w innym narzędziu do wyceny, zacznij od opisania, kiedy funkcja może się mylić i co wtedy zobaczy użytkownik. To lepsze pierwsze zadanie niż wybór modelu. Przykłady naszych realizacji znajdziesz na stronie z projektami Web Systems, a jeśli chcesz przejść z prototypu do produktu razem ze mną, sprawdź zasady współpracy.