AI bez szumu: poradnik dla pracującego inżyniera

Większość treści o AI w internecie dzieli się na dwie kategorie: apokaliptyczne wizje superinteligencji lub entuzjastyczne twierdzenia, że chatbot zastąpi ci pracę do wtorku. Żadne z nich ci nie pomoże. Ten poradnik omija obie strony i pokazuje, jak rzeczywiście używać obecnego pokolenia narzędzi AI w rzeczywistych projektach, z wyraźnie opisanymi ograniczeniami.

Co LLM faktycznie robi

Wielki model języka taki jak GPT-4 lub Llama 3 przewiduje następny token w sekwencji, trenowany na ogromnej ilości tekstu. Tyle. Nie ma wbudowanego sprawdzacza faktów, nie ma trwałej pamięci między sesjami (chyba że ją zbudujesz), i nie ma rozumienia w sensie, w jakim rozumie człowiek. Kiedy zadajesz mu pytanie, generuje statystycznie wiarygodną kontynuację twojego prompta.

To ma znaczenie praktyczne: model będzie pewnie generować funkcję Python-a, która woła metodę biblioteki, która nie istnieje, bo ta metoda brzmi jak coś, co biblioteka by miała. Zawsze uruchamiaj kod. Zawsze sprawdzaj dokumentację API. Traktuj wynik modelu jako pierwszy szkic od szybkiego, oczytanego stażysty, który czasem kłamie bez wiedzy.

Rzeczywisty workflow: używanie LLM-u do kodu

Oto schemat, który działa zamiast po prostu prosić ChatGPT, aby "zbudował mi aplikację":

1. Sam napisz sygnaturę funkcji i docstring, określając typy i przypadki brzegowe.
2. Poproś model, aby ją zaimplementował według tej dokładnej specyfikacji.
3. Sam napisz testy — nie proś modelu, aby napisał testy dla kodu, który właśnie napisał, będzie miał tendencję do pisania testów, które przechodzą trywialnie.
4. Uruchom testy. Podaj niepowodzenia jako nowe prompty, nie niejasne stwierdzenia "to nie działa".

def parse_duration(text: str) -> int:
    """
    Parse strings like '1h30m', '45s', '2d' into total seconds.
    Raise ValueError on invalid input.
    """

Podanie modelowi takiej dokładnej umowy daje znacznie lepsze wyniki niż luźny opis i daje ci coś konkretnego do przetestowania.

Retrieval-augmented generation, w prostych słowach

RAG jest kolorowym buzzwordem, ale mechanizm jest prosty: zamiast polegać na tym, co model zapamiętał podczas trenowania, pobierasz istotne dokumenty w momencie zapytania i wpychasz je do prompta.

Bazowa konfiguracja:

1. Podziel dokumenty (500-1000 tokenów to wspólny punkt początkowy).
2. Osadź każdy fragment za pomocą modelu takiego jak text-embedding-3-small lub otwartego modelu takiego jak bge-small-en.
3. Przechowuj wektory w czymś takim jak Postgres z pgvector, lub dedykowanym magazynie takim jak Qdrant.
4. W momencie zapytania osadź pytanie użytkownika, uruchom wyszukiwanie podobieństwa (odległość cosinusowa jest standardem) i pobierz top-k fragmentów do prompta obok pytania.

SELECT content FROM docs
ORDER BY embedding <=> '[0.012, -0.045, ...]'
LIMIT 5;

Dlatego chatbot trenowany na danych do określonej daty może wciąż odpowiadać na pytania o twoją wewnętrzną wiki z zeszłego tygodnia. Nie rozumuje o twojej firmie — czyta twoje dokumenty i je podsumowuje.

Gdzie klasyczne ML wciąż wygrywa

Nie każdy problem potrzebuje transformera. Jeśli przewidujesz rezygnację z danych tabelarycznych strukturyzowanych — wiek konta, częstotliwość użycia, zgłoszenia do supportu — model ze wzmocnionym gradientem taki jak XGBoost lub LightGBM zwykle będzie lepszy od podejścia opartego na LLM, trenuje się w minutach zamiast godzin, i kosztuje ułamek do uruchomienia. Sięgnij po RandomForestClassifier scikit-learn lub XGBoost, zanim sięgniesz po API, zwłaszcza gdy twoje dane zmieszczą się w arkuszu kalkulacyjnym i twoja zmienna docelowa jest czystą liczbą lub kategorią.

Koszt i opóźnienie to ograniczenia projektowania, nie retrospektywne myśli

Wywołanie klasy GPT-4 kosztuje prawdziwe pieniądze na token i zajmuje rzeczywiste sekundy na zwrot. Jeśli budujesz funkcję, która uruchamia się przy każdym załadowaniu strony dla każdego użytkownika, to szybko się sumuje i opóźnienie będzie widoczne. Agresywnie cachuj, używaj mniejszego modelu takiego jak GPT-4o-mini lub lokalnego Llama 3 8B na wszystko, co nie wymaga najwyższego poziomu rozumowania, i zarezerwuj kosztowne wywołania modelu dla części pipeline'u, gdzie jakość rzeczywiście się liczy.

Tryb niepowodzenia, o którym nikt ci nie ostrzega

Modele halucynują więcej, nie mniej, kiedy prosisz je o rzeczy nieco poza ich dystrybucją treningową — niejasne wersje bibliotek, wewnętrzny żargon firmy, niedawne numery CVE. Jeśli odpowiedź musi być dokładnie poprawna (porada bezpieczeństwa, cytacja prawna, dawka medyczna), nie ufaj samej generacji. Weryfikuj względem źródła pierwotnego za każdym razem i zbuduj krok weryfikacji w swoim pipeline'u zamiast polegać na przeglądzie człowieka po fakcie.

Narzędzia AI są naprawdę przydatne, kiedy przestaniesz spodziewać się, że będą myślić, i zaczniesz je traktować jako szybki pattern-matcher, który musisz sprawdzić. Zbuduj krok weryfikacji od pierwszego dnia, a otrzymasz rzeczywistą wartość zamiast strumienia pewnych nonsensów.

Jeśli chcesz pójść dalej, sprawdź ścieżki Python i Data Science Korra Studio, aby ugruntować się w podstawach, które sprawiają, że praca z tymi narzędziami jest naprawdę produktywna.