Jak przygotować dane firmy pod AI — cztery rzeczy do zrobienia najpierw

Pierwsze pytanie zadane agentowi AI podłączonemu do firmowych danych rzadko kończy się błędem. Kończy się czymś gorszym: odpowiedzią, która brzmi poprawnie, a dotyczy klienta, który odszedł dwa lata temu.

Model nie widzi kontekstu, którego nie ma w danych. Nie wie, że plik „cennik_final_v3" jest nieaktualny, że ta sama firma figuruje w bazie trzy razy pod trzema nazwami i że kolumna „status2" znaczy coś innego niż „status". Zbiera wszystko, co znajdzie, i podaje jedną gładką odpowiedź.

To jest realna zmiana, którą AI wnosi do bałaganu w danych: bałagan przestaje być widoczny. Człowiek, który otwiera folder i widzi trzy wersje cennika, wie, że musi się zastanowić. Człowiek, który dostaje jedno zdanie od modelu, nie ma o czym myśleć.

Poniżej cztery rzeczy do zrobienia, zanim podłączysz model do czegokolwiek — i sposób, żeby nie zamienić tego w projekt na pół roku.

Jedno źródło prawdy dla każdej encji#

Encja to po prostu rzecz, o którą będziesz pytać: klient, zlecenie, pracownik, dokument, faktura. Zasada jest jedna — każda z nich mieszka w dokładnie jednym miejscu.

Brzmi banalnie do momentu, w którym zaczniesz sprawdzać. Klient jest w CRM-ie, w arkuszu handlowca, w podpisie maila i w systemie fakturowym. Cztery adresy, dwa numery telefonu, trzy warianty nazwy.

Człowiek, który pyta trzy osoby i dostaje trzy różne odpowiedzi, wie, że temat wymaga wyjaśnienia. Model wybierze jedną wersję, zwykle tę znalezioną najpierw, i nie doda przy niej żadnego zastrzeżenia.

Praktycznie: dla każdej encji wskaż system nadrzędny i zapisz tę decyzję tam, gdzie widzi ją cały zespół. Pozostałe kopie albo znikają, albo przestają być miejscem, w którym ktokolwiek coś zmienia.

Nazewnictwo zrozumiałe bez tłumacza#

W każdej firmie działającej dłużej niż kilka lat istnieje warstwa wiedzy, której nie ma nigdzie zapisanej. Że „status 7" znaczy „czeka na odbiór". Że zlecenia z przedrostkiem „W-" są wewnętrzne i nie liczą się do przychodu. Że pole „uwagi2" powstało wtedy, kiedy w „uwagi" skończyło się miejsce.

Nowy pracownik uczy się tego przez pierwszy miesiąc, pytając osobę obok. Model nie ma kogo zapytać. Zinterpretuje nazwę dosłownie i policzy zlecenia wewnętrzne razem z resztą.

Trzy rzeczy warte poprawienia:

Nazwy pól mówią, co jest w środku. „Data zakończenia" zamiast „data2". Zmiana nazwy kolumny to zwykle jedno kliknięcie, a usuwa całą klasę cichych pomyłek.

Statusy słowem, nie liczbą. Jeżeli w systemie są kody numeryczne, warto mieć obok nazwę czytelną dla człowieka. Model, który czyta „czeka na odbiór", nie musi zgadywać, co znaczy siódemka.

Skróty rozwinięte przynajmniej raz. Wystarczy jedno miejsce, w którym zapisane jest, że „PZ" to przyjęcie zewnętrzne. Model korzysta z tego tak samo jak nowa osoba w zespole.

Nie chodzi o przepisanie całej bazy. Chodzi o tę warstwę, do której model dostanie dostęp.

Jawne oznaczenie tego, co nieaktualne#

Druga rzecz, której model nie zgadnie: co jeszcze obowiązuje.

Data ostatniej modyfikacji nie rozstrzyga niczego — plik poprawiony w zeszłym tygodniu może zawierać warunki sprzed dwóch lat, a dokument nietknięty od roku może być jedynym obowiązującym. Model nie ma podstaw, żeby to rozróżnić, więc potraktuje oba tak samo.

Dwie rzeczy wystarczą w większości przypadków:

Pole statusu zamiast intuicji. Aktualny, archiwalny, roboczy. Trzy wartości, jedno pole, ustawiane przy każdym dokumencie i rekordzie, który ma wersje.

Data obowiązywania tam, gdzie ma sens. Cenniki, umowy, procedury. Jeżeli w danych jest zapisane, do kiedy coś obowiązuje, model przestaje odpowiadać na podstawie nieważnych warunków.

Kuszące jest usunięcie starych rzeczy — to najprostszy sposób, żeby model przestał je widzieć. Jest też nieodwracalny i zwykle koliduje z obowiązkiem przechowywania dokumentów. Oznaczenie działa równie dobrze i da się je cofnąć.

Usunięcie duplikatów#

Duplikaty są z tej czwórki najbardziej podstępne, bo psują nie treść odpowiedzi, tylko liczby.

Model zapytany o liczbę otwartych zleceń klienta policzy te rekordy, które znajdzie pod nazwą, o którą zapytałeś. Jeżeli ten sam klient siedzi w bazie jako „ABC", „ABC sp. z o.o." i „A.B.C.", odpowiedź będzie zaniżona — i nic w niej nie zasygnalizuje, że czegoś brakuje.

Kolejność, która działa:

1. Zacznij od encji, o którą będziesz pytać najczęściej. Zwykle to klienci albo zlecenia, rzadko wszystko naraz.
2. Posortuj alfabetycznie i przejrzyj. Duplikaty stoją obok siebie i widać je gołym okiem szybciej, niż zajęłoby skonfigurowanie narzędzia do ich wykrywania.
3. Ustaw pole, które nie może się powtórzyć. NIP dla firm, adres e-mail dla osób. To jest część, która sprawia, że nie robisz tego samego za kwartał.

Bez trzeciego kroku odduplikowanie jest pracą cykliczną. Z nim jest jednorazowe.

Jak zrobić to etapami#

Pełne uporządkowanie danych firmy to projekt, który nigdy się nie kończy. Cel jest węższy: doprowadzić do porządku ten fragment, który model faktycznie zobaczy.

Tydzień pierwszy: jeden obszar. Wybierz jedną encję i przejdź przez cztery punkty wyżej wyłącznie dla niej.

Tydzień drugi: model tylko czyta. Zadaj mu dwadzieścia pytań, na które znasz odpowiedź. To najtańszy audyt danych, jaki istnieje — błędna odpowiedź prawie zawsze wskazuje konkretny rekord albo plik.

Tydzień trzeci: popraw to, co wyszło. Nie wszystko, tylko to, co realnie psuło odpowiedzi.

Potem następny obszar. Miesiąc na encję i tylko te obszary, o które faktycznie będziesz pytać — to praca rozłożona na pojedyncze godziny zamiast harmonogramu, którego nikt nie dotrzyma.

Podsumowanie#

Cztery rzeczy: jedno źródło prawdy dla każdej encji, nazwy zrozumiałe bez tłumacza, jawnie oznaczona nieaktualność, brak duplikatów. Żadna nie wymaga programisty ani nowego narzędzia — wymagają decyzji i kilku godzin na obszar.

Ta praca zwraca się jeszcze przed podłączeniem modelu, bo te same cztery rzeczy utrudniają pracę także ludziom. AI tylko sprawia, że przestają być widoczne. O tym, jak wygląda samo podłączenie i o co pytać dostawcę, piszemy w przewodniku integracja AI z danymi firmy.