- Kierowca dostępny teraz
- całą dobę, 7 dni w tygodniu
- Dojazd do 1 h w promieniu 40 km
- Diagnoza laptopa 0 zł
Lokalne AI wspierające pracę z bazami danych SQL pozwala analizować dane firmowe bez wysyłania ich do zewnętrznych usług.
Usługa obejmuje skonfigurowanie lokalnego AI wspierającego zapytania i analizę danych w bazach SQL na komputerze firmowym.
Usługa jest przydatna dla firm chcących analizować dane w bazach SQL z pomocą AI bez wysyłania ich na zewnątrz.
Konfiguracja mieści się z reguły w standardowym czasie do 3 dni.
Diagnoza wstępna i wycena są bezpłatne, a usługa objęta jest gwarancją do 12 miesięcy.
Lokalne AI konfigurowane jest pod konkretny silnik bazy danych używany w firmie. W praktyce najczęściej spotykane są Microsoft SQL Server (typowy dla Comarch ERP XL, Comarch ERP Optima w wersji sieciowej czy enova365), Firebird (baza wykorzystywana m.in. przez InsERT GT i InsERT nexo, czyli Subiekta, Rewizora, Rachmistrza czy Gratyfikanta), a także PostgreSQL, MySQL lub MariaDB spotykane w rozwiązaniach webowych, sklepowych i integracjach z Allegro, BaseLinkerem lub własnymi aplikacjami firmowymi. Konfiguracja zaczyna się od rozpoznania, jaki silnik i jaka wersja bazy działa w firmie, ponieważ od tego zależy dobór sterownika łączącego model AI z danymi.
Lokalny model językowy (LLM, czyli duży model językowy odpowiedzialny za rozumienie zapytań w języku naturalnym i przekładanie ich na zapytania SQL) potrzebuje odpowiednich zasobów komputera, na którym ma działać. Znaczenie ma ilość pamięci operacyjnej RAM, wolne miejsce na dysku SSD pod pliki modelu oraz, w przypadku większych modeli, karta graficzna wspierająca obliczenia równoległe (GPU). Przed konfiguracją sprawdzany jest sprzęt firmowy i dobierany model o rozmiarze dopasowanym do jego możliwości, tak aby działał płynnie, a nie tylko teoretycznie się uruchamiał.
Proces zaczyna się od instalacji środowiska uruchamiającego lokalny model AI na komputerze firmowym, bez połączenia z zewnętrznymi serwerami dostawcy modelu. Następnie konfigurowane jest połączenie z bazą danych, najczęściej przez sterownik ODBC (Open Database Connectivity, czyli standardowy interfejs pozwalający aplikacjom komunikować się z różnymi bazami danych w jednolity sposób) lub natywny sterownik danego silnika bazy. Kolejny etap to utworzenie osobnego konta dostępowego do bazy z uprawnieniami ograniczonymi do odczytu, żeby model AI mógł analizować dane, ale nie mógł ich modyfikować ani usuwać. Na końcu przeprowadzane są testowe zapytania w języku naturalnym, sprawdzające, czy odpowiedzi AI zgadzają się z rzeczywistą zawartością bazy.
Ponieważ większość baz SQL w małych i średnich firmach należy do konkretnego systemu księgowo-magazynowego, konfiguracja lokalnego AI uwzględnia specyfikę takiego oprogramowania. Obsługiwane są bazy używane przez InsERT GT i nexo (Subiekt, Rewizor, Rachmistrz, Gratyfikant, Gestor, Biuro), WAPRO ERP (Mag, Fakturka, Gang, Kaper, Fakir, JPK), Comarch ERP (Optima, XL, Altum), Sage Symfonia, RAKS, WF-Mag, enova365 oraz rozwiązania oparte o Microsoft SQL Server i Azure. W przypadku systemów działających w chmurze lub przez API, takich jak iFirma, wFirma czy Fakturownia, zakres integracji jest ustalany indywidualnie, ponieważ dostęp do samej bazy danych bywa tam ograniczony przez dostawcę usługi.
Główny powód, dla którego firmy decydują się na lokalne AI zamiast rozwiązań chmurowych, to kontrola nad danymi. Dane finansowe, kadrowe czy handlowe nie opuszczają komputera ani sieci lokalnej firmy, ponieważ model AI działa offline i nie wysyła zapytań do zewnętrznych usług. W konfiguracji uwzględniane jest też odseparowanie modelu od dostępu do internetu, jeśli nie jest on potrzebny do jego działania, co dodatkowo ogranicza ryzyko wycieku danych. Konto dostępowe do bazy ograniczone do odczytu jest tu drugim, niezależnym zabezpieczeniem — nawet błędnie sformułowane zapytanie do AI nie może naruszyć integralności danych.
Zakres konfiguracji może się różnić w zależności od potrzeb firmy. Prostszy wariant to lokalne AI działające wyłącznie w trybie odczytu, generujące podsumowania, raporty i zestawienia na podstawie pytań zadawanych w języku naturalnym, na przykład o stan magazynu czy zaległe płatności. Bardziej rozbudowany wariant obejmuje dodatkowo generowanie gotowych zapytań SQL na podstawie opisu potrzeby, które użytkownik może następnie uruchomić samodzielnie lub które trafiają do zatwierdzenia przed wykonaniem. Trzeci wariant to konfiguracja dla kilku baz jednocześnie, na przykład osobno dla systemu księgowego i osobno dla bazy sklepu internetowego, z rozdzielonymi uprawnieniami dostępu dla każdej z nich.
Część klientów próbuje skonfigurować lokalne AI samodzielnie, zanim zdecyduje się na pomoc serwisu, i najczęściej powtarzają się te same problemy. Pierwszy to pobieranie modeli językowych zbyt dużych w stosunku do możliwości sprzętu — komputer zaczyna działać bardzo wolno albo model w ogóle się nie uruchamia z powodu braku pamięci RAM. Drugi częsty błąd to podłączenie modelu AI do bazy danych przez konto administracyjne z pełnymi uprawnieniami, zamiast konta ograniczonego do odczytu, co w razie pomyłki w zapytaniu może doprowadzić do zmiany lub usunięcia danych. Trzeci błąd to otwieranie portu bazy danych na zewnątrz w przekonaniu, że jest to konieczne do działania lokalnego AI — w rzeczywistości cała komunikacja powinna odbywać się wewnątrz sieci firmowej, a otwarty port naraża bazę na nieautoryzowany dostęp z internetu.
Konfiguracja lokalnego AI do pracy z bazami SQL to usługa odrębna od wdrożenia samego systemu ERP czy księgowego — zakłada, że system i baza danych już działają, a AI jest dodawane jako warstwa analityczna korzystająca z istniejących danych. To również nie jest budowa rozbudowanych systemów raportowych klasy BI (Business Intelligence) od podstaw, choć lokalne AI może współistnieć z takimi narzędziami. Jeśli problemem jest sama wydajność serwera bazodanowego, uszkodzony plik bazy albo błędy w samym oprogramowaniu ERP, to są to osobne usterki wymagające innego rodzaju naprawy niż konfiguracja AI.
Nie. Lokalne AI ułatwia formułowanie zapytań i analizę wyników, ale nie zarządza strukturą bazy, kopiami zapasowymi ani uprawnieniami użytkowników — to nadal pozostaje w gestii administratora lub osoby odpowiedzialnej za system.
Nie, jeśli model działa w pełni lokalnie, do jego codziennej pracy internet nie jest potrzebny. Dostęp do sieci bywa wykorzystywany jedynie przy aktualizacji samego modelu lub oprogramowania.
Przy konfiguracji lokalnej model działa na komputerze firmowym i nie przesyła danych do zewnętrznych serwerów — to główna różnica względem usług chmurowych opartych na modelach dostępnych przez internet.
Zależy od wybranego modelu i wielkości bazy danych. Mniejsze modele językowe potrafią działać na samym procesorze, choć wolniej niż z odpowiednią kartą graficzną — dobór modelu jest dopasowywany do konkretnego sprzętu podczas konfiguracji.
Jeśli w ramach naprawy lub konfiguracji laptop musi zostać na dłużej, zapewniany jest bezpłatny laptop zastępczy z systemem Windows, bez kaucji i limitu czasowego, tak aby praca w firmie mogła być kontynuowana.
Technicznie jeden model może obsługiwać kilka źródeł danych, ale w praktyce lepiej sprawdza się rozdzielenie połączeń — osobne konto dostępowe i osobna konfiguracja dla bazy systemu księgowego, osobna dla bazy sklepu internetowego. Ułatwia to kontrolę nad tym, kto i do jakich danych ma dostęp, oraz upraszcza rozwiązywanie problemów, jeśli pojawią się one tylko w jednym z systemów.
Po wdrożeniu lokalnego AI warto pamiętać, że model językowy oraz sterowniki łączące go z bazą danych od czasu do czasu wymagają aktualizacji, podobnie jak każde inne oprogramowanie firmowe. Nowsze wersje modeli zwykle lepiej radzą sobie z formułowaniem zapytań SQL i trafniej interpretują pytania zadawane w języku naturalnym, dlatego przegląd konfiguracji po pewnym czasie pozwala ocenić, czy nie warto zmienić modelu na nowszy, zwłaszcza jeśli w międzyczasie zmienił się też sprzęt, na którym działa. Objęta jest to bezpłatnym przeglądem pogwarancyjnym, podobnie jak pozostałe usługi konfiguracyjne na komputerach firmowych.
Konfiguracja lokalnego AI do pracy z bazami SQL to przede wszystkim dobór modelu i sposobu połączenia dopasowany do konkretnego silnika bazy, konkretnego systemu ERP i konkretnego sprzętu w firmie — nie ma tu jednego uniwersalnego ustawienia, które pasuje do każdej instalacji.