Hierarchiczna mapa koncepcji inżynierii sztucznej inteligencji oraz sytuacji, w których są istotne
Dowiedz się, które koncepcje inżynierii sztucznej inteligencji decydują o tym, czy system w ogóle funkcjonuje, które są ważne podczas tworzenia rozwiązań do użycia w produkcji, a które mogą poczekać.
Lista rzeczowników traktuje wszystkie dwadzieścia pozycji jako równoważne, podczas gdy w rzeczywistości tak nie jest. Sześć z nich decyduje o tym, czy twój system w ogóle będzie funkcjonować. Kolejne siedem staje się istotne, gdy zaczynasz tworzyć coś do użycia w produkcji. Ostatnie siedem to elementy, które powinieneś być w stanie rozpoznać podczas rozmowy, ale których naukę można bezpiecznie odłożyć o rok – i co niefortunne, to zazwyczaj te właśnie tematy ludzie studiują w wolnym czasie.
Następna część omawia te same kwestie, ale do każdego pojęcia dodaje trzy informacje: to, co faktycznie daje, moment, w którym zaczyna mieć znaczenie, oraz sposób sprawdzenia, czy naprawdę go rozumiesz, a nie tylko rozpoznajesz termin.
To właśnie te sprawdzenia są najważniejsze. Większość ludzi dowiaduje się, że od miesięcy tylko udaje zainteresowanie danym tematem, dopiero gdy po raz pierwszy próbuje go wyjaśnić na głos.
Poziom 1: Sześć elementów decydujących o poprawności działania systemu
1. Embeddingi i wyszukiwanie wektorowe
Co to daje: Prawie wszystko związane z wydobywaniem informacji opiera się na tym koncepcie, a błędy w jego zastosowaniu powodują awarie, które nie wywołują żadnych błędów.
Kontrola: Dwa modele embeddingowych generują wektory o wymiarze 1024. Wyjaśnij, dlaczego klasyfikator wyszkolony na wynikach jednego z modeli nadal będzie generował błędne wyniki, otrzymując wektory z drugiego modelu.
Jeśli uważasz, że zgodne wymiary wektorów to oznaka kompatybilności, to jest to właśnie błąd rozumienia. Model embeddingowy definiuje własną geometrię. Dwa różne modele umieścą identyczną frazę w zupełnie innych miejscach w przestrzeniach, które przypadkowo mają tę samą strukturę. Nic w Twoim stacku nie ostrzeże Cię przed tym.
2. Jakość wydobywania informacji, która nie jest tym samym co RAG
Co to daje: Prawie całą jakość odpowiedzi w systemie opartym na wyszukiwaniu — a praktycznie żadna z tej jakości nie pochodzi od samego modelu językowego.
Kontrola: Wymień trzy sytuacje, w których proces RAG może zawieść się jeszcze przed uruchomieniem modelu językowego.
Odpowiedzią są dzielenie na fragmenty, tworzenie wektorów reprezentacji i sortowanie. Jeśli podzielisz dokument w niewłaściwym miejscu, stracisz dokładne zdanie, które odpowiedziało na pytanie. Jeśli użyjesz modelu wektorowego wyszkolonego na niewłaściwym dziedzinie, twój żargon znajdzie się w niewłaściwej części przestrzeni wektorowej. Jeśli pominiesz etap ponownego sortowania, narzędzie wyszukiwania zwróci wyniki tematycznie powiązane, ale faktycznie nieistotne. Zespoły, które uważają, że mają problem z halucynacjami, zazwyczaj mają problem z wyszukiwaniem, i często spędzają miesiąc na dostosowywaniu zapytań, zanim to sprawdzą.
3. Ocena
Co to daje: Możliwość stwierdzenia, czy zmiana rzeczywiście coś poprawiła, co odróżnia inżynierię od domysłów.
Kontrola: Opisz złoty zestaw, według którego dokonujesz oceny — ile przykładów, skąd pochodzą, na co są oceniane oraz kto sprawdza te wyniki.
Jeśli nie możesz odpowiedzieć konkretnymi liczbami, to, co masz, to nie ocena, lecz subiektywne wrażenia plus demonstracja, która akurat zadziałała we wtorek. Rozsądnym punktem wyjścia jest od dwustu do pięciuset rzeczywistych par prompt–odpowiedź pobranych z prawdziwego ruchu użytkowników, ocenianych według kilku określonych kryteriów, przy czym część wyników jest sprawdzana przez człowieka. Warto również wiedzieć, że jeśli używasz modelu jako sędziego, ten sędzia również wymaga własnej oceny — to problem rekurencyjny, który jest nieprzyjemny, ale nieunikniony.
4. Strukturyzowany wynik i wykorzystanie narzędzi
Co to daje: Połączenie między systemem, który generuje tekst, a systemem, który faktycznie wykonywać czynności.
Kontrola: Model zwraca JSON, który nie przechodzi walidacji według Twojego schematu. Opisz dokładnie, co robi dalej Twój system.
Większość ludzi kończy na stwierdzeniu „spróbujemy ponownie”, ale właśnie wtedy zaczynają się prawdziwe pytania. Ile prób powtórnego uruchomienia, z jaką strategią opóźniania, i czy próba ponowna zawiera błąd walidacji, aby model miał szansę poprawić swój błąd? Co dzieje się po ostatecznej nieudanej próbie — czy użytkownik widzi komunikat błędu, czy zaniżoną jakość, ale nadal użyteczną odpowiedź? Wywołanie narzędzia to w istocie wezwanie funkcji za granicą, która może tworzyć iluzje, więc wszystkie standardowe zasady dotyczące walidacji niezaufanych danych mają tu takie samo znaczenie.
5. Kontrola kosztów i opóźnień
Co to daje: Różnicę pomiędzy funkcją, która faktycznie trafia do użytkowników, a wersją demonstracyjną odrzuconą z powodów finansowych.
Kontrola: Podaj obecny koszt za zapytanie, a następnie wymień pięć sposobów na jego zmniejszenie o połowę, uszeregowanych według stopnia wpływu każdego z nich.
Należy mieć pod ręką pięć różnych podejść. Zamiast używać domyślnego modelu, wysyłaj proste zapytania do tańszego, mniejszego modelu. Przechowuj w pamięci tymczasowej odpowiedzi na zapytania semantycznie podobne do tych, które już rozstrzygnąłeś, a nie tylko identyczne. Odcinaj lub kompresuj wszystko to, co wkładasz do promptu. Grupuj elementy, które nie wymagają natychmiastowej odpowiedzi, w partie i przetwarzaj je offline. Skracaj również wyniki generowane przez model, ponieważ tokeny, które on tworzy, zazwyczaj kosztują więcej niż te, które wysyłasz. Według doniesień Stripe zapłaciło w tym miesiącu ponad 7 miliardów dolarów za OpenRouter – firmę, której główny produkt w zasadzie automatyzuje pierwsze dwa z tych rozwiązań – co wskazuje, że branża przestała traktować kontrolę kosztów jako błahostkę.
6. Zarządzanie kontekstem
Co to daje: Przewidywalne zachowanie, gdy dane wejściowe przekraczają rozmiar okna kontekstowego – co zdarza się ciągle w środowisku produkcyjnym, a prawie nigdy w demonstracjach.
Kontrola: Gdy okno kontekstowe się wypełni, co zostanie odrzucone i kto podjął tę decyzję?
Poprawna odpowiedź wymienia konkretną zasadę: najpierw odrzucić najstarsze wpisy, najpierw te fragmenty o najniższej ocenie, streszczając część środkową lub odrzucić żądanie całkowicie. Niepokojąca odpowiedź brzmi, że framework sam się tym zajmuje, ponieważ zazwyczaj oznacza to, że coś ważnego jest po cichu odrzucane, a nikt tak naprawdę nie sprawdził, co to jest.
Poziom 2: Siedem kwestii, których dowiadujesz się podczas tworzenia czegoś rzeczywistego
Są one istotne, gdy system jest już w użyciu i z nim interagują rzeczywiści użytkownicy. Nie ma nic złego w badaniu ich wcześniej, ale analiza przed etapem Tier 1 umieszcza wysiłki w niewłaściwej kolejności.
7. Prompty jako wersjonowane artefakty
Umiejętność tworzenia skutecznych promptów przyciąga znacznie więcej uwagi, niż na to zasługuje, podczas gdy dyscyplina inżynieryjna związana z promptami otrzymuje znacznie mniej uwagi. W rzeczywistości potrzebny jest rejestr, zaznaczone wersje, porównanie side-by-side oraz możliwość cofnięcia zmian, ponieważ prompt jest w istocie kodem, który trafia do produkcji bez przechodzenia przez kompilatora.
8. Strategia dzielenia na fragmenty
Rozbieranie tekstu na okna o stałej wielkości, dzielenie go według granic semantycznych oraz dodawanie nakładania się fragmentów to różne kompromisy pomiędzy dokładnością a trafnością wyników. Prawidłowy wybór zależy od sposobu strukturyzacji podstawowych dokumentów, a nie od domyślnych zaleceń zawartych w instrukcjach.
9. Ponowna klasyfikacja
Zwykłym podejściem jest najpierw uzyskanie szerokiego, taniego wykazu kandydatów, a następnie przeprowadzenie droższego procesu oceny tego wykazu. Pominęcie tego drugiego kroku jest prawdopodobnie najczęstszą przyczyną, dla której proces wyszukiwania daje wyniki, które wydają się prawie poprawne, ale nie do końca.
10. Zasady bezpieczeństwa i iniekcja poleceń
To wymaga wielowarstwowych zabezpieczeń: tanich filtrów w punkcie wejścia oraz droższych sprawdzeń bliżej samego modelu. Każdy tekst pochodzący od użytkownika lub z dokumentu pobraanego przez system powinien być traktowany jako potencjalnie wrogie dane wejściowe, a nigdy jako wiarygodne instrukcje.
11. Obserwowalność w systemach niedeterministycznych
Tutaj potrzebne są ślady działania systemu, a nie zwykłe logi. Kluczowe pytanie brzmi: które fragmenty danych zostały pobraane i która wersja promptu była aktywna, gdy trzy dni temu pojawiła się konkretna zła odpowiedź – tylko szczegóły na poziomie śladów mogą na to odpowiedzieć.
12. Wybór między generowaniem promptów, pobieraniem danych a dopasowywaniem modelu
To rozstrzygnięcie ma znacznie większe znaczenie niż opanowanie jakiejś pojedynczej techniki. Wyodrębnianie informacji dostarcza wiedzy, dopasowywanie kształtów, zachowania i formatu wyjściowego, a sterowanie promptami obejmuje wszystko inne, z czym można sobie poradzić bez tych metod. Powszechnym błędem jest uciekanie się do dopasowywania, by rozwiązać problem, który w rzeczywistości wynika z braku umiejętności wyodrębniania informacji.
13. Pętle agentów i wybór narzędzi
Jeden agent wyposażony we dobrze dobrane zestaw narzędzi oraz ograniczoną pętlę wykonywania potrafi rozwiązać zaskakująco dużą liczbę problemów, podczas gdy ludzie często szukają rozwiązań w architekturach wielu agentów.
Poziom 3: Siedem elementów wartych rozpoznania i odłożenia
Na tym poziomie wystarczy dobrze znać słownictwo, by móc uczestniczyć w rozmowie na ten temat. Głębsze poznanie może poczekać, aż konkretny problem zmusi do zajęcia się tym tematem – dla wielu praktyków ten moment nigdy nie nadejdzie.
14. Orkiestracja wielu agentów
To najbardziej przesadzany punkt na liście. Coraz więcej publikacji analizuje, dlaczego te systemy przestają działać po wdrożeniu, a powtarzającym się wnioskiem jest to, że koszty koordynacji oraz rosnące tempo błędów sprawiają, że w większości przypadków radzą sobie gorzej niż pojedynczy, dobrze zaprojektowany agent. Wiedz, do czego odnosi się ten termin, i uciekaj się do tego podejścia tylko w ostateczności.
15. Kuantyzacja i optymalizacja dostarczania
Jest to niezwykle ważne, jeśli sam zarządzasz wagami modelu, natomiast praktycznie nie ma znaczenia, jeśli po prostu korzystasz z API.
16. Wewnętrzna struktura Transformerów
Mechanizmy uwagi, kodowanie pozycji oraz pozostała część architektury pojawiają się znacznie częściej na rozmowach kwalifikacyjnych niż w codziennej pracy. Warto je poznać raz, ale głębokie zrozumienie niewiele zmienia w sposobie budowania systemów.
17. Destylacja
To staje się przydatne, gdy masz już działający, ale drogi system i musisz obniżyć koszty – to problem, który powstaje z biegiem czasu, a nie od samego początku.
18. Cacheowanie semantyczne
Mocna technika o poważnych ograniczeniach: trafienie do cache’u przy zapytaniu o podobny wzorzec zwraca błędną odpowiedź podawaną z pełnym przekonaniem.
19. Grafy wiedzy i GraphRAG
Oferują one rzeczywiste korzyści, gdy leżące u ich podstaw dane są naprawdę relacyjne, ale wymagają znacznej dodatkowej złożoności, aby je wykorzystać.
20. Dostosowywanie preferencji i rodzina RLHF
Jest to przede wszystkim istotne dla zespołów, które faktycznie szkolą modele, a nie dla tych, które budują aplikacje na bazie już istniejących rozwiązań.
Niewygodna część
Gdy spojrzysz na te trzy poziomy, zauważysz coś nie tak.
Orchestracja wielu agentów, wewnętrzne mechanizmy modeli typu transformer oraz sformułowanie promptów to tematy, które pochłaniają największą część wysiłków edukacyjnych ludzi, przy czym wszystkie trzy należą do poziomu 2 lub 3. Tymczasem to ocena, jakość wyszukiwania informacji oraz kontrola kosztów faktycznie decydują o tym, czy system naprawdę funkcjonuje, lecz otrzymują jedynie niewielką uwagę, głównie dlatego, że żaden z nich nie stanowi atrakcyjnej demonstracji.
Istnieje oczywisty powód tego rozbieżności, i warto to jasno przedstawić, zamiast traktować jako krytykę. Tematy poziomu 3 są łatwe do przyswojenia – możesz czytać o orkiestracji wielu agentów w drodze do pracy i odejść z poczuciem, że czegoś się nauczyłeś. Ocena natomiast zmusza cię do stworzenia idealnego zbioru danych, do dyskusji z kolegą z zespołu na temat tego, co właściwie oznacza „dobrze”, a czasami do przyjęcia faktu, że twój system nigdy nie był tak silny, jak wyglądał w demonstracji. Jedna z tych czynności jest przyjemna, a druga naprawdę pomaga.
Jak faktycznie się tego nauczyć, a nie tylko je gromadzić
Pojemnością takiej listy jest traktowanie jej jako programu nauczania do przeczytania od deski do deski. Czytanie pozwala jedynie na rozpoznanie, a to rozpoznanie znika w momencie, gdy ktoś zadaje dodatkowe pytanie.
Dwie nawyki działają znacznie lepiej niż samo czytanie.
Najpierw stwórz od podstaw jeden mały system, a następnie celowo go zepsuj. Skieruj proces wyszukiwania na dokumenty, które naprawdę cię interesują, i umyślnie sabotuj każdy etap. Podziel tekst w niewłaściwy sposób i obserwuj, jak spada jakość odpowiedzi. Usuń mechanizm ponownego rankowania i zobacz, jakie zmiany nastąpią. Wprowadź do systemu próbę iniekcji promptu i sprawdź, co wycieknie. Tydzień spędzony w ten sposób nauczy więcej niż miesiąc czytania, ponieważ pozostają ci wspomnienia konkretnych niepowodzeń, a nie abstrakcyjne definicje.
Za drugim razem sprawdź tę wiedzę na przykładzie realistycznych pytań. Sprawdzenia opisane w tym tekście są inspirowane typem pytań, które faktycznie pojawiają się w praktyce, a rozwiązywanie rzeczywistych zadań typu projektowania systemów to najszybszy sposób na wykrycie luk w twojej znajomości tematu, głównie dlatego, że prawdziwe pytania często zawierają dodatkowe kwestie, a właśnie wtedy powierzchowne rozpoznawanie już nie wystarcza.
Gdzie mogę się mylić
To rankowanie jest subiektywną oceną kształtowaną przez konkretne systemy omówione tutaj, a nie wynikiem formalnego badania, więc uczciwiej nazwać je uzasadnionym uporządkowaniem niż ostatecznym rankingiem.
Istnieją dwa miejsca w rankingu, które warto otwarcie omówić. Orkiestracja wielu agentów znajduje się w poziomie 3 częściowo dlatego, że obecne dane na temat zachowania tych systemów w warunkach rzeczywistych nie są pomyślne, a solidna platforma, która pojawi się w najbliższej przyszłości, mogłaby łatwo podnieść ją wyżej. Wewnętrzne mechanizmy Transformerów plasują się tu nisko, ponieważ praca z modelami AI jest coraz bardziej dyscypliną integracyjną niż modelową, a osoby pracujące bezpośrednio z samymi modelami powinny umieścić ten temat znacznie wyżej.
Miejscem, które należy najtwardziej bronić, jest ocena na trzecim miejscu, choć istnieją poważne argumenty za umieszczeniem jej na pierwszym miejscu. Bez niej każdy inny punkt na tej liście staje się domysłem, ponieważ nie można ulepszyć tego, czego nie da się zmierzyć, a bardzo niewiele zespołów budujących na bazie modeli potrafi faktycznie stwierdzić, czy zmiana z zeszłego tygodnia poprawiła sytuację, czy ją pogorszyła.
Jeśli chciałbyś przeorganizować tę listę, najciekawsze spory prawdopodobnie dotyczą granicy pomiędzy poziomem 1 a poziomem 2. Bardziej przydatną dyskusją jest określenie, który element chciałbyś przenieść wyżej i co ta zmiana faktycznie przyniosła, zamiast tworzenia kolejnej listy dwudziestu pozycji.
Literatura pokrewna
- Zarządzanie systemem LLM-as-a-Judge jako żywym systemem produkcyjnym — Dowiedz się, jak czterostopniowy cykl życia Netflixa – dane oparte na faktach, szkolenie dostosowane do kryteriów oceny, bezpieczne wdrożenie oraz ciągłe monitorowanie – zapewnia dokładność systemu LLM-as-a-Judge na dużą skalę.