Dane i dostępy do systemów, których projekt AI potrzebuje przed startem

Czego projekt procesowy naprawdę potrzebuje

Zespoły często odkładają prace nad AI, dopóki nie powstanie data lake albo katalog danych. Dla agenta lub asystenta opartego na istniejącym modelu rzadko jest to ograniczeniem. Model jest już wytrenowany. Projekt potrzebuje rekordów, których dotyka jeden proces, zatwierdzonego sposobu ich odczytu i spraw, które pokazują, jak wygląda poprawny wynik. AWS Generative AI Lens wskazuje rozproszone dane, niespójne zarządzanie i niejasną odpowiedzialność jako to, co spowalnia eksperymenty z generatywną AI, a wszystkie trzy dotyczą bardziej ludzi i dostępów niż ilości danych.

Lista startowa z nazwiskiem w każdym wierszu

1. 1

   Właściciel każdego źródła danych

   Osoba, która może zatwierdzić, że te dane wolno użyć w tym celu, w jakim środowisku i na jak długo. O tę zgodę zapyta wasz inspektor ochrony danych.

2. 2

   Konto serwisowe z dostępem do odczytu

   Dostęp przez API w najwęższym zakresie, jakiego wymaga zadanie. Dostęp do zapisu przychodzi później, gdy wyniki zostaną zweryfikowane.

3. 3

   Reprezentatywne zamknięte sprawy

   Zamknięte zgłoszenia, zaksięgowane faktury albo poprawione ekstrakcje, w których zapisano właściwy wynik. Wytyczne Anthropic dotyczące ewaluacji sugerują, by pierwsze zadania testowe brać z prawdziwych porażek w bug trackerach i kolejkach wsparcia.

4. 4

   Ekspert, który ocenia wyniki

   Ktoś z procesu z zarezerwowanym co tydzień czasem na rozstrzyganie niejasnych oznaczeń i czytanie wyników. Bez tego czasu nikt nie potwierdzi, że wynik jest poprawny.

5. 5

   Zatwierdzone miejsce pracy

   Środowisko, w którym wolno przechowywać dane testowe i wywoływać modele, z przepływami danych zatwierdzonymi przez wasz zespół bezpieczeństwa.

6. 6

   Krótki opis każdego zbioru danych

   Skąd pochodzą rekordy, jaki okres obejmują i czego wiadomo, że brakuje. Gebru i współautorzy zaproponowali w tym celu datasheets for datasets, a w pierwszym projekcie wystarczy pół strony na źródło.

Co sprawia, że zestaw spraw jest reprezentatywny

Losowy eksport spraw z ostatniego miesiąca to początek, ale będzie zawierał głównie rutynę i prawie żadnej sprawy sprawiającej kłopot. AWS Lens zaleca próbkowanie warstwowe: podzielcie sprawy na istotne grupy i losujcie z każdej. W hipotetycznym zestawie 300 zgłoszeń serwisowych mogłoby to oznaczać 180 rutynowych zgłoszeń, 75 wyjątków, takich jak brakujące dokumenty czy sporne kwoty, i 45 rzadkich typów, celowo nadreprezentowanych. Proporcje są poglądowe i powinny wynikać z waszego własnego rozkładu spraw. Raportujcie wyniki dla każdej grupy. Ponieważ rzadkie typy są nadreprezentowane, ogólny wynik tego zestawu nie jest waszym odsetkiem błędów na produkcji, a szacunki dla produkcji powinny ważyć każdą grupę jej rzeczywistym udziałem.

Sprawdźcie wyniki, a nie tylko dane wejściowe. Zapisany wynik może być błędny, na przykład gdy zgłoszenie zamknięto, by zmieścić się w celu. Niech ekspert przejrzy próbkę oznaczeń, zanim staną się miarą, według której oceniany jest system.

Gdy nie wolno używać danych produkcyjnych

Niektóre organizacje nie pozwalają testować modeli na danych produkcyjnych. AWS Lens omawia ten przypadek: zestaw referencyjny powinien wtedy zawierać dane funkcjonalnie równoważne, z danymi testowymi i atrapami endpointów dla workflowów agentów. W praktyce oznacza to spseudonimizowane wyciągi w zatwierdzonym środowisku albo syntetyczne sprawy pisane przez ekspertów według prawdziwych wzorców. O tym, czy pseudonimizacja wystarcza, decydują inspektor ochrony danych i prawnicy, a zespół techniczny dostarcza im fakty: które pola, dokąd płyną i jak długo są przechowywane.

Dostępy, które zadziałają też na produkcji

Pilotaże kuszą skrótami: osobisty token API, eksport arkusza wysłany mailem, konto administratora pożyczone na tydzień. Działa to w pierwszym sprincie i blokuje przejście na produkcję, bo nikt nie może tego zatwierdzić na stałe. AWS Lens zaleca traktowanie modelu, który czyta wasze magazyny danych, jak uprzywilejowanego użytkownika i nadanie mu tylko minimalnego dostępu potrzebnego do zadania. Ustawienie tego na początku zużywa czas administratora wcześnie, a nie później na przebudowę integracji.

Decyzja, czy startować teraz

Podzielcie pracę według tego, czego dotyka. Określenie zakresu, projekt testów i prototyp działający na danych syntetycznych lub atrapach mogą ruszyć, gdy wskazani są właściciele danych i ekspert. Wszystko, co czyta prawdziwe rekordy albo wysyła je do modelu, czeka, aż konto serwisowe, zatwierdzone środowisko i przepływ danych zostaną zaakceptowane. Opisy zbiorów danych można pisać równolegle. Jeśli nie ma znanych wyników ani czasu eksperta, w ogóle nie zaczynajcie budowy. Zamiast tego zacznijcie zapisywać wyniki w obecnym procesie. Od takiego określenia zakresu zaczyna się nasza praca w obszarze AI engineering, a pierwsza rozmowa nie wymaga dostępu do waszych systemów ani danych.

Wybór pierwszego procesu do automatyzacjiCo musi wykazać pilotaż AI