AI czyta rysunki budowlane: jak powstał AI Plan Reader

Czy AI czyta rysunki budowlane na tyle dobrze, żeby oprzeć na tym wycenę? Na tyle dobrze, żeby przejąć żmudne przepisywanie danych z planu, ale nie na tyle, żeby wynik trafiał do kosztorysu bez sprawdzenia. Z tego założenia wyrósł AI Plan Reader, moduł, który budowaliśmy dla procalc.com.au, australijskiego kalkulatora kosztów budowy dla wykonawców: AI odczytuje plan, a człowiek weryfikuje wynik. Poniżej opisuję drogę od prototypu do funkcji w produkcie i miejsca, w których ta technologia ma granice.

Klient i problem: ręczne liczenie z planów PDF

procalc.com.au to kalkulator kosztów budowy dla wykonawców w Australii. Żeby przygotować wycenę, wykonawca musi przenieść do kalkulatora dane z rysunków, które zwykle dostaje jako pliki PDF. Ręczne liczenie z planów zajmuje czas. To praca powtarzalna, wymagająca skupienia i podatna na pomyłki przy przepisywaniu. Do tego plany pochodzą z różnych biur projektowych, więc każdy wygląda trochę inaczej i za każdym razem trzeba się w nim od nowa odnaleźć.

Pytanie produktowe brzmiało więc tak: czy da się skrócić drogę od pliku PDF do danych w kalkulatorze, nie tracąc kontroli nad tym, co trafia do wyceny. To typowy punkt wyjścia dla projektu AI w firmie: istnieje zadanie, które ludzie wykonują ręcznie, i jasne kryterium, kiedy jest wykonane dobrze.

Rozwiązanie: AI odczytuje rysunek, człowiek zatwierdza

AI Plan Reader łączy dwa kroki. AI odczytuje rysunek i proponuje dane do kalkulatora, a wykonawca je przegląda, poprawia i zatwierdza, zanim trafią do wyceny. Odpowiedzialność za kosztorys zostaje po stronie człowieka, a AI zdejmuje z niego przepisywanie.

Ten podział nie jest kompromisem z braku lepszej technologii. Rysunki budowlane zawierają skróty, oznaczenia i konwencje, które różnią się między biurami projektowymi. Błąd w odczycie przekłada się wprost na pieniądze w ofercie, więc weryfikacja jest częścią produktu, a nie zabezpieczeniem na wszelki wypadek.

Podobny wzór, w którym AI przygotowuje dane, a człowiek je zatwierdza, sprawdza się przy innych dokumentach firmowych. Pisałem o tym w tekście o automatyzacji obiegu dokumentów z AI.

Etapy: od prototypu do funkcji w produkcie

Praca nad modułem przeszła przez trzy etapy. Każdy z nich odpowiada na inne pytanie i każdy da się zakończyć wnioskiem, że dalej nie warto iść.

1. Prototyp. Ma odpowiedzieć na jedno pytanie: czy AI w ogóle wyciąga z rysunku dane, które przydają się do wyceny. Na tym etapie liczy się szybkość sprawdzenia, a nie wygląd.
2. Testy na prawdziwych planach. Zamiast czystych, przykładowych rysunków: plany, z którymi wykonawcy faktycznie pracują. Ten etap pokazuje, gdzie odczyt jest pewny, a gdzie zawodzi.
3. Wejście do produktu. Odczyt połączony z kalkulatorem, miejsce na weryfikację przez wykonawcę i obsługa przypadków, w których AI nie radzi sobie z planem.

Najwięcej uczy etap drugi. Prototyp działający na kilku wybranych plikach łatwo przecenić, bo dobrze wygląda na prezentacji. Dopiero zróżnicowane plany pokazują, jak rozwiązanie zachowa się u klientów. Przy testach tego typu porównuje się odczyt AI z tym, co z tego samego planu odczytałby doświadczony wykonawca, i zapisuje każdy przypadek rozbieżności razem z przyczyną. Taka lista jest cenniejsza niż ogólna ocena, że działa dobrze, bo pokazuje, które rodzaje rysunków trzeba obsłużyć inaczej i o czym uprzedzić użytkowników. Takie podejście opisuję szerzej w tekście o tym, jak zaplanować MVP produktu.

Granice: kiedy AI czyta rysunki budowlane z błędami

AI czyta rysunki budowlane dobrze wtedy, gdy plan jest czytelny i zbliżony do typowych. Dwie grupy przypadków wymagają szczególnej ostrożności:

• Skany słabej jakości: rysunek wydrukowany, zeskanowany, krzywy, z rozmytymi liniami i nieczytelnymi opisami.
• Plany nietypowe: niestandardowe oznaczenia, wiele rzutów na jednym arkuszu albo konwencja rysunku, z którą model wcześniej się nie zetknął.

W takich sytuacjach produkt powinien uczciwie powiedzieć, że odczyt jest niepewny, i oddać pracę człowiekowi, zamiast podawać dane, które tylko wyglądają na poprawne. Dla wykonawcy gorszy jest wynik błędny i przekonujący niż brak wyniku. Dlatego granice warto opisać w produkcie i w komunikacji z użytkownikami, a nie zostawiać ich do odkrycia przy pierwszej nieudanej wycenie.

Co z tego wynika dla firm, które myślą o AI na dokumentach technicznych

Ten projekt dotyczy budownictwa, ale te same zasady obowiązują przy kartach technicznych, specyfikacjach, fakturach czy formularzach. Gdybym miał je zebrać w krótką listę, wyglądałaby tak:

• Zacznij od jednego, dobrze opisanego zadania, które ludzie dziś wykonują ręcznie.
• Testuj na prawdziwych dokumentach, z całą ich różnorodnością i bałaganem.
• Zaprojektuj ekran weryfikacji tak samo starannie jak sam odczyt.
• Ustal z góry, co produkt robi, gdy dokument jest nieczytelny.
• Nie obiecuj użytkownikom pełnej automatyzacji tam, gdzie błąd kosztuje pieniądze.

Szerszy obraz tego, jak podchodzę do takich projektów, opisałem w tekście o wdrażaniu aplikacji AI w firmie. Inne realizacje znajdziesz na stronie z projektami, przy których pracowałem.

Jeśli w Twojej firmie ktoś codziennie przepisuje dane z rysunków, specyfikacji albo skanów do systemu, to dobry kandydat na pierwszy projekt AI. AI czyta rysunki budowlane i inne dokumenty techniczne na tyle dobrze, żeby przejąć przepisywanie, ale wartość daje dopiero połączenie odczytu z weryfikacją w miejscu, w którym człowiek i tak pracuje. Jeżeli chcesz sprawdzić, czy to zadziała u Ciebie, napisz do mnie przez formularz.