Inwestycja w przetrenowanie modelu na tysiącach plików PDF z oferty firmowej, zakończona rozczarowaniem, gdy dwa tygodnie później zmienia się cennik, a sztuczna inteligencja z niezłomną pewnością siebie podaje klientom przedawnione stawki – to scenariusz, w który wciąż wpada wiele młodych firm. Równie kosztownym błędem jest budowanie bezmyślnego systemu wyszukiwania dokumentów, który wrzuca do indeksu poufne wątki z firmowego komunikatora, po czym udostępnia je użytkownikom zewnętrznym. Jak uniknąć tych pułapek już na samym starcie?
Podejmując decyzję o dostosowaniu sztucznej inteligencji do wewnętrznych zasobów startupu, najczęściej wybierasz między dwoma fundamentalnie różnymi podejściami: Retrieval-Augmented Generation (RAG) oraz fine-tuningiem (dostrajaniem wag modelu). Wybór niewłaściwej ścieżki oznacza nie tylko zmarnowany budżet i czas programistów, ale także ryzyko wdrożenia rozwiązania, które zamiast wspierać zespół, generuje fałszywe informacje i naraża firmę na straty wizerunkowe.
Jaki masz cel, gdy myślisz o wdrożeniu AI w swoim produkcie lub procesach wewnętrznych? Czy model ma przede wszystkim operować na ciągle zmieniających się faktach z Twojej bazy danych, czy raczej opanować bardzo specyficzny, trudny do wymuszenia samą instrukcją sposób myślenia i formatowania odpowiedzi?
Model zna język, ale nie zna Twojej firmy — gdzie zaczyna się problem
Ogólne duże modele językowe (LLM) świetnie radzą sobie z redagowaniem tekstów, tłumaczeniem, pisaniem kodu czy wyciąganiem wniosków ze złożonych poleceń. Posiadają jednak istotną cechę, o której łatwo zapomnieć w fazie fascynacji technologią: ich wiedza faktograficzna jest zamrożona w momencie zakończenia procesu treningowego. Komercyjny model wie, jak zbudowany jest świat, zna gramatykę języka i pojęcia branżowe, ale nie ma zielonego pojęcia o Twoim cenniku SaaS, specyfikacji API czy procedurze obsługi reklamacji wprowadzonej wczoraj rano.
Gdy ogólny chatbot odpowiada pewnie, lecz niezgodnie z polityką firmy
Gdy użytkownik zadaje pytanie dotyczące wewnętrznych spraw startupu, bazowy model językowy próbuje połączyć ze sobą słowa w sposób, który brzmi najbardziej prawdopodobnie. Nie wynika to ze złej woli algorytmu, lecz z samej natury architektury przewidującej kolejny token. Efektem są tak zwane halucynacje — sytuacje, w których system podaje z pełnym przekonaniem nieprawdziwe informacje.
Rozważmy przypadek asystenta wsparcia klienta w startupie technologicznym. Klient pyta o możliwość bezpłatnego zwrotu subskrypcji po 14 dniach. W dokumentacji wewnętrznej widnieje zapis, że zwrot przysługuje wyłącznie do 7 dni, a po tym terminie wymagana jest zgoda działu finansowego. Model ogólny, pozbawiony bezpośredniego dostępu do tej procedury, odwołuje się do ogólnych wzorców z e-commerce i odpowiada klientowi: „Tak, oczywiście, masz 14 dni na bezwarunkowy zwrot środków”. W tym momencie startup staje przed dylematem: złamać własny regulamin lub stracić zaufanie klienta przez błąd bota.
Co już próbowałeś w swoim zespole? Czy pierwszym odruchem było doklejanie całej dokumentacji do promptu systemowego?
Symptomy, że problemem nie jest sam prompt
Wielu founder
Wielu founderów zaczyna od coraz dłuższego promptu: dopisuje wyjątki, wkleja fragmenty regulaminu, dodaje instrukcje dla konkretnych przypadków. To może pomóc przy kilku prostych zasadach, lecz szybko przestaje być skalowalne. Prompt ma ograniczoną długość, trudno go utrzymywać, a model nie odróżnia automatycznie aktualnej procedury od starego fragmentu wklejonego przez kogoś miesiąc wcześniej.
Sygnałem ostrzegawczym jest sytuacja, w której odpowiedź zmienia się zależnie od kolejności instrukcji albo model ignoruje ważny zapis, mimo że formalnie znalazł się on w kontekście. Podobnie dzieje się wtedy, gdy zespół ręcznie aktualizuje prompt po każdej zmianie cennika, polityki bezpieczeństwa czy dokumentacji produktu. Jaki masz cel: jednorazowo poprawić kilka odpowiedzi czy stworzyć mechanizm, który będzie pobierał właściwe źródło w chwili pytania?
Jeżeli problem dotyczy dostępu do bieżących faktów, dokumentów i rekordów z systemów firmowych, sam prompt nie wystarczy. Potrzebny jest kontrolowany sposób wyszukania odpowiednich informacji, sprawdzenia uprawnień użytkownika oraz przekazania modelowi wyłącznie tych danych, które są aktualne i potrzebne do odpowiedzi. To właśnie obszar, w którym RAG zwykle ma przewagę nad próbą „nauczenia” modelu całej firmowej wiedzy na stałe.
Dobra decyzja zaczyna się od prostego rozdzielenia potrzeb: zmienną wiedzę trzymaj poza wagami modelu i udostępniaj ją przez dobrze zabezpieczony mechanizm retrievalu, a fine-tuning rozważaj wtedy, gdy chcesz trwale zmienić styl, strukturę lub sposób wykonywania powtarzalnych zadań. Najpierw nazwij problem, potem dobierz technologię — nie odwrotnie.
Dlaczego sam dostęp do dokumentów nie wystarcza
Podłączenie folderu z dokumentami do aplikacji nie oznacza jeszcze, że model potrafi korzystać z wiedzy firmy. Plik może być nieaktualny, źle opisany, zapisany w nieczytelnym formacie albo zawierać informacje przeznaczone tylko dla określonego zespołu. Sam fakt, że dokument znajduje się w repozytorium, nie mówi jeszcze, czy powinien zostać użyty przy konkretnym pytaniu.
Problem zaczyna się już na etapie przygotowania źródeł. Długi dokument podzielony przypadkowo na fragmenty może stracić kontekst: jeden kawałek zawiera warunek promocji, a kolejny wyjątek obowiązujący dla klientów enterprise. Jeśli do modelu trafi tylko pierwszy fragment, odpowiedź będzie brzmiała logicznie, ale może pomijać kluczowe ograniczenie.
Znaczenie ma również sposób wyszukiwania. Wyszukiwanie wyłącznie po identycznych słowach nie zawsze odnajdzie właściwy zapis. Użytkownik może zapytać o „rezygnację z planu”, podczas gdy dokument używa określenia „dezaktywacja subskrypcji”. Dlatego system powinien rozumieć podobieństwo znaczeniowe, a nie tylko porównywać ciągi znaków.
Dokument musi mieć kontekst, właściciela i datę obowiązywania
W praktyce każdy fragment wiedzy firmowej powinien być opisany metadanymi. Przydatne mogą być między innymi: typ dokumentu, dział odpowiedzialny za treść, data publikacji, wersja, status obowiązywania, grupa odbiorców oraz poziom poufności. Dzięki temu wyszukiwarka może odrzucić starą instrukcję, ograniczyć wyniki do dokumentów dotyczących konkretnego produktu albo nie zwrócić materiału, do którego użytkownik nie ma dostępu.
To ważne szczególnie w startupie, gdzie dokumentacja często powstaje szybko i w wielu narzędziach jednocześnie. Część procedur może znajdować się w narzędziu do zarządzania projektami, część w wiki, a część w repozytorium kodu lub systemie obsługi klienta. Bez ustalenia, które źródło jest nadrzędne, RAG może pobrać kilka sprzecznych odpowiedzi i pozostawić modelowi decyzję, której nie powinien podejmować samodzielnie.
Nie wystarczy też jednorazowe zaindeksowanie danych. Jeżeli zmiana dokumentu nie uruchamia ponownego indeksowania albo usunięcie uprawnień nie aktualizuje dostępu do wyników, system będzie formalnie działał, lecz operacyjnie pozostanie niebezpieczny. Aktualność i bezpieczeństwo retrievalu są częścią funkcji produktu, a nie dodatkami wdrażanymi po zakończeniu projektu.
RAG: gdy model ma odpowiadać na podstawie aktualnej wiedzy firmy
RAG łączy model generatywny z mechanizmem wyszukiwania. Gdy użytkownik zadaje pytanie, aplikacja najpierw analizuje zapytanie i szuka pasujących fragmentów w zatwierdzonych źródłach. Następnie przekazuje modelowi pytanie wraz z wybranym kontekstem, aby odpowiedź powstała na podstawie danych dostępnych w danym momencie.
W takim układzie wagi modelu nie muszą zawierać całej wiedzy operacyjnej startupu. Cennik, instrukcja wdrożenia, polityka reklamacji czy dokumentacja API mogą być aktualizowane niezależnie od modelu. To skraca cykl zmian i ułatwia wskazanie, z którego źródła pochodzi dana informacja.
Jak wygląda bezpieczny przepływ RAG
- Przygotowanie źródeł: dokumenty są oczyszczane, dzielone na sensowne fragmenty i wzbogacane o metadane.
- Indeksowanie: fragmenty trafiają do wyszukiwarki, która może łączyć wyszukiwanie semantyczne z klasycznym wyszukiwaniem słów kluczowych.
- Autoryzacja: system sprawdza, do jakich danych użytkownik lub usługa ma prawo dostępu.
- Retrieval: pobierane są tylko fragmenty pasujące do pytania, zakresu produktu, wersji dokumentu i uprawnień.
- Generowanie: model otrzymuje ograniczony kontekst oraz instrukcję, jak postąpić, gdy źródła nie zawierają odpowiedzi.
- Weryfikacja i monitoring: odpowiedź może zawierać odnośniki do źródeł, a zespół obserwuje błędne wyszukania, brakujące dokumenty i przypadki odmowy odpowiedzi.
Ostatni punkt jest szczególnie istotny. Dobry system RAG nie powinien odpowiadać za wszelką cenę. Jeżeli nie znajduje wiarygodnego źródła, powinien jasno powiedzieć, że nie ma wystarczających danych, poprosić o doprecyzowanie albo przekazać sprawę pracownikowi. Taka odmowa jest często bardziej wartościowa niż płynna odpowiedź oparta na domyśle.
Co RAG rozwiązuje, a czego nie rozwiązuje
RAG dobrze sprawdza się wtedy, gdy najważniejsza jest aktualność i możliwość kontroli źródeł. Ułatwia obsługę dokumentacji produktu, wewnętrznych procedur, katalogów usług, instrukcji technicznych czy materiałów sprzedażowych. Można wymienić dokument bez przebudowy całego modelu, ograniczyć dostęp do określonych danych i analizować, dlaczego system wybrał konkretny fragment.
Nie jest jednak automatycznym lekarstwem na wszystkie problemy. Jeśli dokumenty są sprzeczne, nieuporządkowane lub nie mają właścicieli, wyszukiwarka nie naprawi procesu zarządzania wiedzą. Jeżeli pytanie wymaga obliczeń na danych transakcyjnych, lepsze może być wywołanie kontrolowanego narzędzia lub zapytania do bazy niż przekazanie modelowi kilku tabel w kontekście.
Trzeba również testować jakość retrievalu osobno od jakości generowania. Model może napisać poprawną odpowiedź na podstawie dobrego fragmentu, ale jeśli wyszukiwarka regularnie pobiera niewłaściwe materiały, sama zmiana modelu językowego niewiele pomoże. W praktyce warto mierzyć między innymi, czy właściwy dokument znalazł się w wynikach, czy system respektuje uprawnienia oraz jak często odpowiedź wymaga korekty człowieka.
Fine-tuning: gdy problemem jest zachowanie modelu, a nie brak dokumentów
Fine-tuning ma sens wtedy, gdy model posiada już potrzebne informacje albo może otrzymać je z narzędzi, lecz nie wykonuje zadania w oczekiwany sposób. Dostrajanie wykorzystuje przykłady wejść i pożądanych wyjść, aby utrwalić określony styl, strukturę odpowiedzi, schemat klasyfikacji lub sposób realizacji powtarzalnego zadania.
Przykładem może być model, który ma klasyfikować zgłoszenia klientów do kilkunastu kategorii według wewnętrznej taksonomii. Innym zastosowaniem jest generowanie odpowiedzi zawsze w określonym formacie JSON, tworzenie krótkich podsumowań według firmowego szablonu albo stosowanie charakterystycznego tonu komunikacji w materiałach marketingowych. W takich przypadkach problemem nie musi być brak wiedzy o firmie, lecz brak konsekwencji w zachowaniu.
Dostrajanie może także pomóc, gdy zadanie wymaga powtarzalnej sekwencji decyzji, której nie da się skutecznie wymusić samą instrukcją. Nadal trzeba jednak uważać na granicę między wzorcem działania a danymi, które szybko się zmieniają. Kod produktu, aktualny cennik czy lista aktywnych klientów nie powinny być traktowane jako trwała część parametrów modelu tylko dlatego, że da się je umieścić w zbiorze treningowym.
Fine-tuning wymaga dobrych przykładów, nie tylko dużej liczby przykładów
Skuteczność dostrajania zależy od jakości danych treningowych. Przykłady powinny pokazywać poprawne przypadki, wyjątki, granice decyzji oraz sposób reagowania na brak informacji. Jeśli zbiór zawiera sprzeczne odpowiedzi, nieaktualne reguły lub błędy konsultantów, model może utrwalić właśnie te problemy.
Przed treningiem warto ustalić, które zachowania są mierzalne. Czy chodzi o poprawność etykiety, zgodność ze schematem, długość odpowiedzi, liczbę pominiętych pól, a może styl komunikacji? Bez takiego kryterium trudno ocenić, czy fine-tuning rzeczywiście poprawił produkt, czy tylko zmienił brzmienie odpowiedzi.
Trzeba też zachować osobny zbiór testowy, którego model nie widział podczas dostrajania. Pozwala on sprawdzić, czy system uogólnia regułę na nowe przypadki, a nie tylko odtwarza zapamiętane przykłady. Warto testować również dane nietypowe: niepełne zgłoszenia, sprzeczne informacje, literówki i prośby wykraczające poza zakres zadania.
Fine-tuning nie zastępuje kontroli dostępu, walidacji danych ani logiki biznesowej. Model może nauczyć się zwracać poprawnie sformatowany obiekt, ale aplikacja nadal powinna sprawdzić, czy wartości są dopuszczalne, a użytkownik ma prawo wykonać daną operację. W krytycznych procesach decyzję modelu lepiej traktować jako propozycję podlegającą regułom systemowym niż jako samodzielne źródło prawdy.
RAG czy fine-tuning — decyzja zależy od rodzaju zmiany, której oczekujesz
Najprostsze pytanie brzmi: czy zmieniasz wiedzę modelu, czy jego zachowanie? Jeżeli odpowiedź na pytanie zależy od dokumentu, rekordu lub procedury, która może zostać zmieniona w przyszłym tygodniu, zacznij od RAG albo bezpośredniej integracji z systemem źródłowym. Jeżeli chcesz, aby model konsekwentnie wykonywał to samo zadanie w określonym formacie i na podstawie dostarczonych danych, rozważ fine-tuning.
- Wybierz RAG, gdy liczy się aktualność treści, cytowanie źródeł, możliwość szybkiej aktualizacji i ograniczenie dostępu do dokumentów.
- Wybierz fine-tuning, gdy chcesz utrwalić styl, format, klasyfikację albo powtarzalny sposób reagowania.
- Połącz oba podejścia, gdy model ma zachowywać się według określonego wzorca, ale korzystać z często zmieniających się danych dostarczanych przez retrieval.
- Użyj narzędzia lub integracji z bazą, gdy odpowiedź wymaga aktualnego obliczenia, operacji na rekordach albo wykonania kontrolowanej akcji.
Pułapki, które potrafią podważyć nawet dobrze dobraną technologię
Jednym z częstych błędów jest dostrajanie modelu na dokumentach tylko dlatego, że firma chce „mieć własne AI”. Taki projekt może być kosztowny, trudny do aktualizowania i problematyczny pod względem usuwania danych. Drugim błędem jest wdrożenie RAG bez polityki źródeł: indeksowanie wszystkiego, brak wersjonowania, brak filtrów uprawnień i brak procedury usuwania nieaktualnych treści.
Nie należy również oceniać rozwiązania na podstawie kilku efektownych demonstracji. Startup powinien przygotować zestaw realnych pytań użytkowników, w tym takich, na które system powinien odmówić odpowiedzi. Test warto powtarzać po zmianie modelu, indeksu, sposobu dzielenia dokumentów i reguł autoryzacji.
Praktyczna ścieżka dla większości młodych firm wygląda następująco: najpierw uporządkuj źródła i właścicieli danych, potem zbuduj niewielki, zabezpieczony prototyp RAG, zmierz jakość odpowiedzi i dopiero później sprawdź, czy pozostaje problem z formatem lub zachowaniem modelu. Fine-tuning dodaj wtedy, gdy masz stabilny proces, reprezentatywne przykłady i jasno zdefiniowaną korzyść biznesową.
Nie pytaj więc wyłącznie, która technologia jest bardziej zaawansowana. Zapytaj, co ma się zmienić po wdrożeniu: dostęp modelu do aktualnej informacji, sposób wykonywania zadania czy oba te elementy jednocześnie. W pierwszym przypadku zacznij od kontrolowanego retrievalu, w drugim od dobrze przygotowanych przykładów do dostrojenia, a w procesach wymagających bezpieczeństwa pozostaw ostateczne reguły po stronie aplikacji, nie samych wag modelu.
Jak podjąć decyzję bez kosztownego eksperymentu
W startupie nie warto zaczynać od wyboru dostawcy modelu ani od budowy skomplikowanej architektury. Najpierw trzeba opisać konkretne zadanie i wskazać, gdzie obecne rozwiązanie zawodzi. Czy konsultant nie może znaleźć właściwej procedury? Czy model zwraca poprawne informacje, ale w nieakceptowalnym formacie? Czy odpowiedź musi korzystać z danych z systemu CRM, a może wystarczy dokumentacja produktu?
Pomocne jest rozdzielenie problemu na trzy warstwy:
- Wiedza: skąd mają pochodzić fakty potrzebne do odpowiedzi i jak często się zmieniają?
- Zachowanie: jaką strukturę, ton lub sekwencję działania ma stosować model?
- Decyzja i wykonanie: które reguły powinny pozostać w kodzie aplikacji, systemie uprawnień albo zatwierdzeniu człowieka?
Takie rozbicie ogranicza ryzyko użycia fine-tuningu do problemu z danymi albo RAG do problemu z formatem odpowiedzi. Pokazuje też, kiedy potrzebne jest rozwiązanie hybrydowe: retrieval dostarcza aktualne fakty, fine-tuning utrwala sposób ich wykorzystania, a aplikacja sprawdza wynik przed wykonaniem działania.
Mały test przed decyzją architektoniczną
Przed rozpoczęciem większego projektu przygotuj niewielki zestaw przypadków testowych. Powinny znaleźć się w nim typowe pytania, przypadki graniczne, prośby bez wystarczających danych oraz sytuacje, w których użytkownik nie ma prawa zobaczyć określonej informacji. Dla każdego przypadku zapisz oczekiwany rezultat, wymagane źródło i dopuszczalny poziom błędu.
Następnie porównaj trzy warianty:
- model z dobrze przygotowaną instrukcją i danymi przekazanymi w żądaniu,
- model korzystający z prostego, kontrolowanego RAG,
- model dostrojony na reprezentatywnych przykładach, jeśli problem dotyczy powtarzalnego zachowania.
Porównanie powinno obejmować nie tylko jakość odpowiedzi. Sprawdź także opóźnienie, koszt pojedynczego żądania, łatwość aktualizacji, odporność na niepełne dane, możliwość audytu oraz zachowanie przy próbie dostępu do informacji spoza uprawnień. Rozwiązanie, które wygrywa na demonstracji, ale wymaga ręcznej aktualizacji po każdej zmianie procesu, może być gorszym wyborem produkcyjnym.
Co ustalić przed wdrożeniem
Każdy dokument lub zbiór danych używany przez system powinien mieć właściciela, oznaczenie wersji i regułę wycofania. Warto określić, które źródło ma pierwszeństwo w razie sprzeczności oraz kiedy model ma przerwać generowanie odpowiedzi. Bez tych ustaleń nawet poprawna technologia będzie opierać się na niejasnych zasadach organizacyjnych.
Równie ważne jest zdefiniowanie odpowiedzialności za wynik. Jeśli AI tworzy propozycję odpowiedzi dla pracownika, można dopuścić szerszy zakres automatyzacji niż w przypadku systemu, który samodzielnie zmienia status zamówienia lub wysyła komunikat do klienta. Im większe konsekwencje błędu, tym więcej walidacji powinno znajdować się poza modelem.
Przydatne minimum operacyjne obejmuje:
- logowanie wykorzystanych źródeł i wersji promptu,
- monitorowanie odpowiedzi bez wystarczającego kontekstu,
- regularny przegląd błędów przez osoby znające proces biznesowy,
- testy regresji uruchamiane po zmianie modelu lub indeksu,
- mechanizm szybkiego wyłączenia automatycznej akcji.
Najbezpieczniejsza kolejność dla startupu
W większości młodych firm rozsądny punkt wyjścia to uporządkowanie danych i zbudowanie małego RAG-u dla jednego, dobrze zdefiniowanego przypadku użycia. Taki prototyp powinien korzystać z ograniczonego zbioru źródeł, respektować uprawnienia i jasno sygnalizować brak odpowiedzi. Dopiero wyniki testów pokażą, czy problemem jest jakość wyszukiwania, organizacja dokumentów, instrukcja dla modelu czy jego niekonsekwentne zachowanie.
Jeżeli po poprawieniu źródeł i retrievalu model nadal nie trzyma wymaganego formatu, myli klasy lub nie wykonuje stabilnie powtarzalnej sekwencji, wtedy można ocenić fine-tuning. Dostrajanie powinno być kolejnym krokiem opartym na zmierzonym problemie, a nie sposobem na ukrycie bałaganu w danych.
Rekomendacja jest więc prosta: zmienną wiedzę trzymaj poza wagami modelu i udostępniaj ją przez kontrolowany retrieval lub integrację z systemem źródłowym. Fine-tuning stosuj do trwałych wzorców zachowania, formatu i stylu. Gdy potrzebne są oba elementy, połącz je, ale pozostaw uprawnienia, walidację i krytyczne decyzje po stronie aplikacji. Dzięki temu model może być użyteczny już teraz, a rozwój rozwiązania nie będzie zależał od kosztownego trenowania przy każdej zmianie w firmie.
