Jak sztywne zapytania SQL podsycają halucynacje związane ze sztuczną inteligencją

Podłączasz błyszczącą sztuczną inteligencję do swojego starego systemu ERP, oczekując cudów. Zamiast tego, ona bezczelnie kłamie ci w twarz. Prawdziwy winowajca? Nadal przeszukujesz historyczne dane, jakby był rok 2005.

Jako konsultant ERP nieustannie czytam o takich scenariuszach. Kadra kierownicza spieszy się z wdrażaniem generatywnej sztucznej inteligencji (AI) w systemach korporacyjnych, licząc na natychmiastowe, konwersacyjne wnioski. Kierują duże modele językowe do starych jezior danych i czekają na rezultaty.

Jednak podejście to zwykle zawodzi w chwili wejścia na halę fabryczną.

Próba wyodrębnienia znaczenia semantycznego przy użyciu sztywnych metod opartych na słowach kluczowych w celu zasilania nowoczesnej sztucznej inteligencji to niemal błaganie o halucynacje.

Przyjrzyjmy się bliżej sposobowi, w jaki obecnie przeszukujemy dane korporacyjne i dokąd zmierzają architektury gotowe na sztuczną inteligencję. Błędne podejście do tej kwestii może zniweczyć całą strategię AI.

Ograniczenia tradycyjnych zapytań ERP

Bazy danych w systemach typu Infor LN są fenomenalne pod względem tego, do czego faktycznie służą: precyzji i integralności transakcyjnej.

Są zaprojektowane tak, aby szybko i bezbłędnie wykonywać określone reguły. Jeśli dokładnie wiesz, czego szukasz, klasyczny SQL jest idealny. Gdy potrzebujesz dokładnego statusu konkretnego zlecenia produkcyjnego, wystarczy proste polecenie SQL. Wskazujesz tabelę tisfc001, mapujesz klucze podstawowe i pobierasz dokładny rekord bez żadnych niejasności.

Jednak analiza historyczna rzadko jest tak precyzyjna.

Kiedy menedżer łańcucha dostaw pyta: „Dlaczego ciągle spóźniamy się z tą konkretną linią produktów?”, standardowe zapytanie SQL nie jest w stanie udzielić na to bezpośredniej odpowiedzi. Wymaga ręcznego połączenia pięciu różnych modułów z działów zakupów, magazynowania i produkcji. Co ważniejsze, wymaga interpretacji nieustrukturyzowanych notatek pozostawionych przez różne osoby z różnych działów.

Wyobraź sobie, że badasz powtarzającą się awarię maszyny i analizujesz wady jakościowe. Piszesz standardowe zapytanie SQL, szukając opisu WHERE LIKE '%overheating%'. Twoja dotychczasowa baza danych posłusznie zwróci tylko dokładne dopasowania.

Co pomija? Wszystko inne. Całkowicie ignoruje krytyczne zapisy, w których pośpieszny operator wpisał „wysoka temperatura”, „przegrzanie”lub „płonące” komponenty pod koniec zmiany.

Tradycyjny SQL nie rozumie semantyki. Widzi tylko sztywne znaki. Kiedy wprowadzasz te niekompletne, przefiltrowane według słów kluczowych wyniki do sztucznej inteligencji, model wyciąga wnioski na podstawie rozbitej rzeczywistości. Właśnie w tym miejscu umierają spostrzeżenia biznesowe.

Zaleta semantyczna

Jeśli zachodzi potrzeba analizy danych historycznych w celu znalezienia niejasnych korelacji, baza danych wektorowa zapewnia wyraźną przewagę strukturalną.

Wektoryzacja danych polega na tłumaczeniu tekstu ludzkiego na współrzędne liczbowe zwane osadzeniami. Grupuje to dane na podstawie kontekstu i rzeczywistego znaczenia matematycznego. Wyobraź sobie osadzenie jako współrzędną GPS dla określonego pojęcia.

Zamiast dopasowywać litery, baza danych dopasowuje znaczenie. Jeśli planista wpisze „ opóźnienie z powodu dostawcy” , a operator magazynu zarejestruje oczekiwanie na części, klasyczne zapytanie SQL wykryje dwa niezwiązane ze sobą problemy. Baza danych z wektorem rozpoznaje, że są to dokładnie te same problemy.

W wektorowej bazie danych terminy przegrzania i wysokiej temperatury są umieszczone matematycznie tuż obok siebie.

Przenosząc dane transakcyjne do bazy danych obsługującej wektory, takiej jak Google AlloyDB, przestajesz dopasowywać ciągi znaków, a zaczynasz dopasowywać znaczenie. Zazwyczaj wykorzystuje to potoki strumieniowe do bezpiecznego przenoszenia danych z rdzenia ERP.

Zyskujesz możliwość wyszukiwania danych historycznych z wielu lat za pomocą języka naturalnego. System rozumie intencje. Użytkownicy nie muszą już zapamiętywać skomplikowanej składni SQL, nawigować po niezrozumiałych tabelach ani zgadywać starych skrótów.

Właściwa architektura na początek: RAG i izolacja rdzenia

Możesz mieć ochotę na zastosowanie generatywnej sztucznej inteligencji bezpośrednio w swoim transakcyjnym systemie ERP. Nie rób tego. To poważnie obniży wydajność operacyjną i narazi na ryzyko zablokowania głównego systemu.

LLM-y są niezwykle ciężkie. Jeśli skierujesz konwersacyjną sztuczną inteligencję bezpośrednio na swoje tabele transakcyjne w czasie rzeczywistym, sparaliżujesz swoje codzienne operacje. Pracownik magazynu próbujący wysłać ciężarówkę pełną towarów nie powinien czekać na system, ponieważ kierownik prosi sztuczną inteligencję o analizę dziesięciu lat danych konserwacyjnych.

Nowoczesne rozwiązanie opiera się na technologii Retrieval-Augmented Generation (RAG) i izolacji rdzenia. Doskonałym przykładem jest przejście firmy Infor z przestarzałego systemu Coleman ML. Obecnie firma wykorzystuje LangChain do tworzenia agentów zdolnych do głębokiego rozumowania semantycznego, bezpiecznie opartych na logice biznesowej.

Zazwyczaj przebieg prac RAG obejmuje następujące kroki operacyjne:

• Odciążanie: Dane ERP są przesyłane strumieniowo z rdzenia transakcyjnego. Za pomocą narzędzi takich jak Infor Data Fabric, dane te są przesyłane do wektorowej bazy danych. Dzięki temu system główny działa płynnie.
• Pobieranie: Użytkownik zadaje pytanie w języku naturalnym. Baza danych wektorowych AlloyDB przeprowadza szybkie wyszukiwanie w celu znalezienia koncepcyjnie istotnych rekordów historycznych.
• Ekstrakcja: Tylko te prawidłowe rekordy są wysyłane jako kontekst prawdy do zewnętrznego Dużego Modelu Językowego, takiego jak Vertex AI. LLM przetwarza je i generuje precyzyjną odpowiedź bez konieczności interakcji z systemem ERP na żywo.

Ten przepływ pracy RAG stanowi obecnie właściwą podstawę dla każdej inicjatywy w zakresie sztucznej inteligencji w przedsiębiorstwie. Traktuj go jednak jako punkt wyjścia, a nie cel.

Branża już teraz zmierza w kierunku wyszukiwania agentowego: architektur, w których sztuczna inteligencja nie wykonuje pojedynczego, statycznego wyszukiwania semantycznego, lecz autonomicznie decyduje, jak i gdzie szukać. Przechodzi przez wiele strategii wyszukiwania (wyszukiwanie wektorowe, zapytania strukturalne, systemy plików, grafy wiedzy) w zależności od złożoności pytania.

Andrej Karpathy niedawno zwrócił uwagę na pokrewny wzorzec: LLM Wiki. Agent AI wstępnie kompiluje surowe dane źródłowe w ustrukturyzowaną, powiązaną bazę wiedzy. Zamiast za każdym razem pobierać fragmenty tekstu, agent odpytuje czysty, uporządkowany artefakt, który już zbudował, kumulując inteligencję w czasie.

W większości współczesnych środowisk ERP dobrze zbudowany potok RAG to właściwe posunięcie. Jednak ograniczenia okna kontekstowego, które wymuszały dzielenie wektorów na fragmenty, szybko się kurczą. Jeśli zaprojektujesz swoją architekturę bez żadnego wyjścia w kierunku wzorców agentowych, będziesz musiał ją ponownie zaktualizować za osiemnaście miesięcy.

Zabijanie halucynacji

Halucynacja AI występuje, gdy model LLM generuje dane wyjściowe, które są płynne, przekonujące, ale absurdalne pod względem faktów. Modele te nie „znają” faktów; po prostu przewidują prawdopodobieństwa na podstawie swojej podstawowej architektury.

W złożonych środowiskach przemysłowych halucynacja jest poważną awarią. Sztuczna inteligencja może śmiało wymyślić harmonogram konserwacji, który pasuje do wzorca statystycznego, ale nie istnieje w rzeczywistości. Może sugerować zamawianie części, które zostały wycofane z produkcji dekadę temu, tylko dlatego, że często pojawiały się w starych rejestrach.

Nie możemy matematycznie wyeliminować halucynacji, ale musimy je ograniczyć, aż staną się statystycznie nieistotne. Oto surowe zasady, których należy przestrzegać:

• Wymagaj ścisłego uziemienia: Wymuś, aby LLM polegał wyłącznie na kontekście RAG dostarczanym przez bazę danych wektorów. Jawnie zablokuj jego wstępnie wytrenowaną wiedzę internetową, aby wymusić ścisłe uziemienie przedsiębiorstwa.
• Wdrożenie zerowej temperatury: Ustaw temperaturę modelu na zero. Odetnij kreatywność od sztucznej inteligencji, aby zapewnić deterministyczne i wysoce powtarzalne wyniki. Chcemy chirurgicznej precyzji, a nie kreatywnego pisania.
• Zbuduj obowiązkową wersję zapasową: poprzez rygorystyczną i szybką inżynierię wymuś na LLM komunikat „Dane nie znaleziono”, jeśli odpowiedź opiera się na danych spoza pobranego kontekstu.
• Priorytetowa jakość danych: Żadna z tych zaawansowanych architektur nie ma znaczenia, jeśli dane źródłowe są bezużyteczne. Dane ERP przesyłane do wektorowej bazy danych muszą być czyste i znormalizowane.

Praktyczne spostrzeżenia dla liderów IT

Przestań gonić za szumem medialnym. Samo kupienie licencji na sztuczną inteligencję nie naprawi zepsutej architektury przedsiębiorstwa. Jeśli Twój system ERP to dziś chaos nieustrukturyzowanych obejść, przekazanie go sztucznej inteligencji jedynie zautomatyzuje zamieszanie.

Połącz precyzję transakcji swojego systemu ERP z semantyczną wiedzą bazy danych wektorowych, a w końcu uniemożliwisz sztucznej inteligencji zgadywanie.

Zanim kupisz jakiekolwiek narzędzia AI, zacznij od oceny aktualnej dojrzałości danych. Oceń, jak Twoi użytkownicy obecnie rejestrują problemy i czy te opisy są wystarczająco ustandaryzowane, aby można je było skutecznie wektoryzować.

Następnie oceń bazy danych Vector DB pod kątem analizy historycznej. Zmapuj intencje zapytań, a przede wszystkim chroń system bazowy, budując odseparowaną architekturę RAG. Na koniec zaprojektuj z rampą wyjściową. Zbuduj warstwę pobierania jako modułowy komponent, a nie monolit. Gdy wzorce agentowe dojrzeją do użytku korporacyjnego, powinieneś móc zamieniać lub rozszerzać strategię pobierania bez konieczności przebudowywania wszystkiego od podstaw.

Jeśli Twój system ERP nadal ma problemy z dostarczaniem podstawowych, czystych danych, dodanie do niego semantycznej sztucznej inteligencji tylko przyspieszy jego awarię.

Jeśli Twoja baza danych jest uszkodzona, sztuczna inteligencja zautomatyzuje jedynie zamieszanie na dużą skalę. Napraw architekturę przed zakupem licencji.

Napisane przez Andreę Guaccio 

5 maja 2026 r