Blog
AI jako materiał konstrukcyjny, nie dodatek
Większość „integracji AI”, które widzimy w istniejących systemach, wygląda tak samo: gotowa aplikacja, a na niej okienko czatu. Model dostaje dostęp do fragmentu danych i odpowiada na pytania. Robi wrażenie na demie, a po kwartale nikt z niego nie korzysta. Powód jest konstrukcyjny, nie marketingowy. AI dołożono wtedy, gdy wszystkie ważne decyzje już zapadły.
W budownictwie materiał decyduje o konstrukcji. Stal pozwala na inne rozpiętości niż drewno, beton wymaga innego fundamentu. Nikt nie projektuje budynku „neutralnie materiałowo”, żeby na końcu wybrać, z czego go postawić. Z AI jest tak samo. Jeśli na etapie rysunku wiesz, że model językowy poradzi sobie z klasyfikacją, wyszukiwaniem po znaczeniu i generowaniem treści, rysujesz inną architekturę, a nie tę samą z dodatkowym ekranem.
Wdrożenie AI w firmie — od czego zacząć?
Od jednego procesu, w którym człowiek dziś czyta, klasyfikuje albo przepisuje dane z miejsca w miejsce. Nie od wyboru modelu ani dostawcy. Najpierw sprawdź, czy wynik tego procesu da się opisać twardą regułą. Jeśli da się — napisz regułę. Jeśli się nie da, bo wejściem jest tekst pisany przez ludzi albo dokument w dowolnym układzie, masz kandydata na AI.
Drugi krok to policzenie skali. Ile razy dziennie ten proces się powtarza, ile minut zajmuje jedno przejście, ile kosztuje pomyłka. Proces wykonywany trzy razy w tygodniu przez jedną osobę zwykle nie zwróci kosztu budowy i utrzymania. Proces powtarzany kilkaset razy dziennie zwraca go szybko, nawet przy skuteczności dalekiej od stu procent.
Trzeci krok jest architektoniczny i najczęściej pomijany. Trzeba zdecydować, gdzie trzymamy kontekst podawany modelowi, gdzie zapisujesz jego decyzję z uzasadnieniem i co robi aplikacja, kiedy model odpowie źle albo nie odpowie wcale. Te trzy odpowiedzi zmieniają schemat bazy danych. Dlatego zapadają przed pierwszą linijką kodu, a nie po niej.
Czym różni się AI jako materiał od AI jako dodatku?
Momentem decyzji i tym, co za nią idzie. Materiał wybierasz przed rysunkiem i on kształtuje model danych, koszty oraz sposób utrzymania. Dodatek montujesz po odbiorze, więc musi zmieścić się w tym, co już stoi. Różnicy nie widać na demie. Widać ją w drugim roku eksploatacji, kiedy trzeba coś poprawić.
| Kryterium | AI jako materiał | AI jako dodatek |
|---|---|---|
| Moment decyzji | Etap architektury, przed schematem bazy | Po wdrożeniu, jako osobny moduł |
| Dane i kontekst | Model danych z miejscem na kontekst, historię i embeddingi | Kontekst sklejany doraźnie z tego, co akurat zwraca API |
| Koszt | Policzony w projekcie: budżet tokenów na operację, cache, model dobrany do zadania | Rachunek za żądania, rosnący liniowo z ruchem |
| Audyt | Każda decyzja zapisana z wejściem, wersją promptu i wynikiem | Brak śladu; po dwóch tygodniach nie wiadomo, skąd wzięła się odpowiedź |
| Tryb awaryjny | Ścieżka bez modelu wpisana w proces: reguła, kolejka, człowiek | Awaria dostawcy zatrzymuje funkcję |
| Utrzymanie | Zmiana modelu to podmiana warstwy i testy regresji na zebranych przypadkach | Zmiana modelu to przepisanie modułu i ręczne sprawdzanie |
| Efekt dla użytkownika | Krótsza droga do wyniku, mniej pól do wypełnienia | Jeszcze jedno okno, które trzeba obsłużyć |
Gdzie AI zmienia architekturę, a nie tylko interfejs?
W czterech miejscach, które występują w większości systemów biznesowych: kierowanie zgłoszeń, wyszukiwanie, wprowadzanie danych i tworzenie treści. W każdym z nich model nie dokłada ekranu, tylko usuwa warstwę kodu, którą inaczej trzeba napisać i utrzymywać przez lata.
Klasyfikacja i routing zamiast drzewa reguł
Klasyczne rozwiązanie to lista warunków: jeśli w temacie jest słowo „faktura”, kieruj do księgowości. Taka lista rośnie, zaczyna sobie przeczyć i po dwóch latach nikt nie chce jej ruszać. Model klasyfikujący treść zgłoszenia zastępuje ją tabelą kategorii i zestawem przykładów. Architektura zmienia się naprawdę: zamiast silnika reguł masz rejestr decyzji, próg pewności i osobną ścieżkę dla przypadków niepewnych.
Wyszukiwanie semantyczne zamiast filtrów
Filtry wymagają, żeby użytkownik znał strukturę danych. Wyszukiwanie po znaczeniu wymaga, żeby system znał treść. To inny magazyn: potrzebujesz osadzeń, indeksu wektorowego i procesu, który przelicza je przy każdej zmianie dokumentu. Tego nie da się dokleić w piątek po południu, bo dotyka warstwy przechowywania danych.
Ekstrakcja z dokumentów zamiast formularzy
Formularz często istnieje tylko dlatego, że ktoś musiał przenieść dane z PDF-a do bazy. Jeśli robi to model, formularz przestaje być punktem wejścia i staje się ekranem weryfikacji. Zmienia się cały przepływ: dokument trafia do systemu w oryginale, wyodrębnione pola dostają status „do potwierdzenia”, a interfejs pokazuje wartość obok fragmentu źródła. Inne ekrany, inne uprawnienia, inny model danych.
Generowanie wariantów zamiast szablonów
Szablon z miejscami do podstawienia to sztywna struktura, którą utrzymuje marketing albo dział prawny. Generowanie wariantów wymaga czegoś innego: zestawu ograniczeń, wersjonowania i akceptacji przed publikacją. Warstwa treści przestaje być plikiem, a staje się procesem z historią zmian.
Co się psuje, gdy AI doklejasz na końcu?
Cztery rzeczy, zawsze te same. Żadnej nie widać na demie, każda boli po pierwszych miesiącach na produkcji.
- Nie ma gdzie trzymać kontekstu. Model odpowiada tym lepiej, im więcej istotnych danych dostanie na wejściu. Jeśli baza nie została zaprojektowana pod to, kontekst sklejasz z kilku zapytań, a jakość odpowiedzi staje się losowa.
- Nie ma logu decyzji. Bez zapisu wejścia, wersji promptu i wyniku nie wykażesz, dlaczego system zaklasyfikował sprawę tak, a nie inaczej. To problem nie tylko techniczny, ale i formalny.
- Nie ma trybu awaryjnego. Dostawca ma przerwę, limit zostaje przekroczony, odpowiedź przychodzi w złym formacie. Jeśli w procesie nie przewidziano ścieżki zapasowej, funkcja po prostu przestaje działać.
- Koszt jest zmienną, nie parametrem. Doklejone AI płaci się od żądania. Zaprojektowane AI ma policzony budżet tokenów na operację, cache dla powtarzalnych zapytań i mniejszy model tam, gdzie duży nie jest potrzebny.
Kiedy AI nie jest właściwym materiałem?
Częściej, niż wynika to z prezentacji konferencyjnych. Model językowy jest dobry w zadaniach nieostrych i kosztowny w zadaniach ostrych. Jeśli problem da się opisać regułą, reguła będzie szybsza, tańsza i powtarzalna. W czterech sytuacjach odradzamy AI wprost.
- Reguła jest deterministyczna. Naliczanie stawki, walidacja numeru, przeliczanie jednostek. To kod, nie model. Model doda tu tylko koszt i niepewność.
- Wymóg audytowy jest twardy. Jeśli każda decyzja musi być odtwarzalna znak w znak, generatywny model jest złym wyborem tam, gdzie decyzja jest ostateczna. Może natomiast przygotować materiał dla człowieka, który ją podpisuje.
- Skala jest za mała. Kilkadziesiąt spraw miesięcznie zwykle nie pokryje kosztu budowy, testów i utrzymania. Lepiej uprościć formularz.
- Nie ma danych. Bez przykładów nie zbudujesz zbioru testowego, a bez zbioru testowego nie wiesz, czy zmiana modelu coś poprawiła, czy zepsuła.
Reguła jest tańsza od modelu wszędzie tam, gdzie da się ją napisać. Model ma sens tam, gdzie reguły trzeba by pisać w nieskończoność.
Jak podejmujemy tę decyzję we własnych produktach?
Budujemy cztery własne produkty i w każdym pytanie „gdzie AI, a gdzie zwykły kod” pada na etapie architektury, nie po wdrożeniu. Granica przebiega zwykle tam, gdzie kończy się jednoznaczność danych.
W BARVEA, naszej platformie BIM i CDE, kontrola jakości modeli IFC dzieli się na dwie części. Część sprawdzeń jest twarda: czy atrybut istnieje, czy status mieści się w zakresie S0–S6, czy plik odpowiada wymaganiom ISO 19650. To zwykły kod i tak ma zostać, bo wynik musi być powtarzalny. Miękka część zaczyna się przy nazwach i opisach wprowadzanych przez ludzi, gdzie ta sama rzecz bywa nazwana na kilka sposobów. Tam warstwa językowa ma sens, a model danych musi z góry przewidywać miejsce na kontekst i na status „do weryfikacji przez człowieka”.
W ClimaBox, urządzeniu IoT z panelem live, surowe odczyty temperatury, wilgotności i CO₂ to szeregi liczb. Progi alarmowe zostają regułami, bo muszą działać natychmiast i lokalnie. Interpretacja, czyli jedno zdanie o tym, co te odczyty razem znaczą, to zadanie dla warstwy językowej. Rozdzielenie jednego od drugiego zaplanowaliśmy przed napisaniem panelu. Alarm ma działać niezależnie od tego, czy warstwa opisowa w ogóle jest dostępna.
Nie mamy jeszcze długiej listy referencji, więc dowodem są nasze produkty. Opisaliśmy je na stronie projekty.
Czy warto dodać AI do aplikacji, która już działa?
Warto, jeśli potraktujesz to jak przebudowę, a nie montaż. Pytanie nie brzmi „gdzie wstawić czat”, tylko „który fragment obecnej architektury istnieje wyłącznie dlatego, że kiedyś maszyna nie potrafiła czytać tekstu”. Zwykle są to formularze, silniki reguł i rozbudowane filtry. To one są prawdziwym miejscem na zmianę.
Praktycznie oznacza to jeden proces, jedną miarę skuteczności i zbiór testowy zebrany zanim cokolwiek trafi na produkcję. Potem rozszerzanie, jeśli liczby się zgadzają. Bez wielkiego „wdrożenia AI” w całej firmie naraz.
Nie robimy body leasingu, samego hostingu bez projektu ani stron z gotowego szablonu. Zakres znajdziesz w ofercie. Jeśli chcesz sprawdzić, czy w Twoim procesie AI jest materiałem, czy tylko dodatkiem, opisz ten proces w formularzu kontaktowym. Wycena zwykle wraca w jeden dzień roboczy.