Spędziłeś godzinę na jednym prompcie. Dodałeś kontekst, trzy przykłady, instrukcję krok po kroku i listę rzeczy, których model ma nie robić. Odpowiedź wyszła świetna, więc zapisałeś ją sobie w notatniku jako wzorzec. Następnego ranka wkleiłeś dokładnie to samo pytanie i dostałeś coś zupełnie innego: poprawnego, sensownego i kompletnie nie o twojej firmie.
Model nie pamięta wczorajszej rozmowy. Nie wie też, że „klient premium" oznacza u ciebie kogoś z umową ramową, a nie kogoś z dużym koszykiem.
Znasz to? Kolejna wersja promptu tego nie naprawi, bo problem siedzi o poziom niżej. Prompt ustawia sposób, w jaki model odpowiada: ton, format, długość, kolejność argumentów. Nie ustawia natomiast tego, co model wie w chwili, gdy zaczyna pisać. Ta druga warstwa też ma swoją nazwę — context engineering, czyli budowanie systemu, który podsuwa modelowi właściwe dokumenty zamiast lepiej sformułowanego pytania.
Neo4j ujmuje to bez ogródek: prompt engineering ma wyraźne granice wszędzie poza prostymi chatbotami, bo modele gubią kluczowe szczegóły, źle używają narzędzi albo zmyślają. To głos dostawcy bazy danych i warto o tym pamiętać, czytając tak stanowczą diagnozę. Rzecz w tym, że akurat ta jedna daje się sprawdzić na twardych wynikach — i sprawdza się.
Co znajdziesz w artykule?
- Czym prompt różni się od kontekstu i dlaczego lepiej sformułowane pytanie nie zmienia tego, co model ma pod ręką w chwili odpowiadania
- Co pokazał benchmark NoLiMa: przy trzydziestu dwóch tysiącach tokenów jedenaście z trzynastu modeli spadło poniżej połowy własnego wyniku z krótkiego tekstu
- Dlaczego dostrajanie modelu na firmowych dokumentach uczy go stylu, a nie faktów — i kiedy mimo wszystko warto po nie sięgnąć
- Pięć kroków budowy bazy wiedzy: zbiórka dokumentów, podział na fragmenty, embeddingi, baza wektorowa i podpięcie do modelu
- Trzy rzeczy, które psują się dopiero w produkcji — wyszukiwanie po nazwach własnych, nieodświeżane dane i brak kontroli dostępu — oraz tygodniowy plan pierwszego prototypu
Prompt ustawia formę odpowiedzi, nie zasób, z którego ona powstaje
Najłatwiej zobaczyć tę różnicę na dwóch zdaniach, które robią co innego. Prompt brzmi tak: „Jesteś ekspertem od sprzedaży B2B, napisz mail do dyrektora zakupów firmy produkcyjnej, ton rzeczowy, maksymalnie dwieście słów". Kontekst to coś zupełnie innego — system, który przy tym samym pytaniu dokłada modelowi trzy maile, które u ciebie zadziałały w tej branży, notatkę z ostatniej rozmowy z tym klientem i cennik obowiązujący od kwietnia.
Pierwsze podejście da ci dobrze napisany mail o niczym. Drugie da mail, który wie, o czym mówi.
Analogia, która to domyka: prompt jest sposobem, w jaki zadajesz pytanie ekspertowi, a baza wiedzy jest wykształceniem tego eksperta. Możesz doszlifować pytanie do perfekcji i nadal usłyszeć odpowiedź z podręcznika, bo pytany po prostu nie zna twojej firmy. Krzyczenie do kogoś, kto nie mówi twoim językiem, nie sprawia, że zaczyna rozumieć — najwyżej sprawia, że słyszy głośniej.
📖 Ze słownika Noraline RAG (Retrieval-Augmented Generation) — architektura, w której model przed napisaniem odpowiedzi najpierw wyszukuje pasujące fragmenty w twoich dokumentach i dopiero one trafiają do jego kontekstu. Zamiast polegać wyłącznie na tym, co zapamiętał w treningu, dostaje świeże dane z twojej firmy w chwili odpowiadania. Kluczowe rozróżnienie: RAG nie zmienia modelu, tylko to, co model widzi. Dlatego zmiana cennika w środę działa od środy, bez ponownego liczenia czegokolwiek.
Przy 32 tysiącach tokenów wrzucanie całej dokumentacji przestaje pomagać
Skoro okno kontekstowe jest ogromne, wystarczy wkleić do niego całą dokumentację. Benchmark, który celowo utrudnił dopasowanie po słowach, pokazuje coś innego.
Odruch jest zrozumiały i sam go miałem. Skoro model przyjmuje sto dwadzieścia osiem tysięcy tokenów, to po co cokolwiek budować — wkleja się wszystko i gotowe. Kłopot w tym, że deklarowana pojemność okna i użyteczna pojemność okna to dwie różne wielkości, a producenci podają wyłącznie tę pierwszą.
Benchmark NoLiMa, zbudowany przez zespół z Adobe Research i Uniwersytetu Ludwika i Maksymiliana w Monachium, wziął na warsztat trzynaście modeli deklarujących obsługę co najmniej stu dwudziestu ośmiu tysięcy tokenów. Sztuczka polegała na tym, że pytanie i szukany fragment celowo nie miały wspólnych słów, więc model musiał skojarzyć znaczenie zamiast dopasować ciąg znaków. Przy krótkim tekście wyniki były bardzo dobre. Przy 32 000 tokenów jedenaście z trzynastu modeli spadło poniżej połowy własnego wyniku z krótkiego kontekstu, a GPT-4o, jeden z dwóch wyjątków, zjechał z 99,3% do 69,7%.
Tę liczbę trzeba czytać ostrożnie, bo łatwo ją rozdmuchać. Nie oznacza ona, że model przestaje działać powyżej trzydziestu dwóch tysięcy tokenów ani że okna kontekstowe są oszustwem. Oznacza, że w zadaniu wymagającym skojarzenia, a nie dosłownego dopasowania, trafność spada tym mocniej, im więcej niepotrzebnego tekstu leży obok właściwej odpowiedzi.
I tu wychodzi rzecz, która przekłada się wprost na dokumenty leżące na twoim dysku. Autorzy tłumaczą ten spadek tym, że mechanizm uwagi radzi sobie znacznie gorzej, kiedy między pytaniem a odpowiedzią brakuje dosłownego pokrycia słów. A w firmach takiego pokrycia brakuje niemal zawsze. Procedura mówi „zwrot towaru nieuszkodzonego w oryginalnym opakowaniu", handlowiec pyta „czy mogę to przyjąć z powrotem" — i te dwa zdania nie mają ze sobą ani jednego wspólnego słowa.
Stażysta z dostępem do pięćdziesięciu segregatorów nie potrzebuje pięćdziesięciu segregatorów. Potrzebuje jednego, otwartego na właściwej stronie.
Dostrajanie uczy model stylu, wiedzy uczy go dopiero wyszukiwanie
W tym miejscu pada zwykle pomysł, który brzmi mądrzej, niż jest: „to dotrenujmy model na naszych danych i będzie znał firmę". Brzmi to jak skrót omijający całą resztę tego artykułu, więc warto sprawdzić, czy działa.
Sprawdzili to badacze Microsoftu w pracy o wymownym tytule „Fine-Tuning or Retrieval?". Porównali dwie drogi wprowadzania nowej wiedzy do modelu: nienadzorowane dostrajanie na korpusie dokumentów oraz wyszukiwanie w bazie w momencie odpowiadania. Wyszukiwanie wygrało konsekwentnie, zarówno przy wiedzy widzianej wcześniej w treningu, jak i przy całkiem nowej. Modele wyraźnie miały trudność z przyswojeniem nowych faktów przez samo dostrajanie.
| Dostrajanie (fine-tuning) | Wyszukiwanie (RAG) | |
|---|---|---|
| Czego uczy | stylu, formatu, tonu odpowiedzi | niczego — podaje fakty w momencie pytania |
| Nowe fakty | modele mają z tym wyraźną trudność | wchodzą od razu, bez treningu |
| Zmiana danych | kolejny cykl treningu | podmiana dokumentu w bazie |
| Kontrola dostępów | brak, wiedza wtapia się w wagi | zostaje po stronie bazy |
Mechanizm stojący za tym wynikiem jest prostszy, niż się wydaje. Dostrajanie przesuwa wagi modelu i doskonale nadaje się do formy: żeby pisał twoim tonem, trzymał twój układ dokumentu, używał twojego nazewnictwa. Fakt to jednak co innego niż nawyk. Fakt musi dać się podmienić w środę, kiedy zmienia się cennik — a wag modelu nikt w środę nie przelicza.
| Warstwa | Co ustawia | Kiedy po nią sięgasz |
|---|---|---|
| Prompt | Formę odpowiedzi: ton, długość, format, kolejność argumentów | Zawsze. To najtańsza i najszybsza zmiana, jaką możesz wprowadzić. |
| Dostrajanie modelu | Nawyki modelu: styl, terminologię, powtarzalny schemat wyniku | Gdy masz setki przykładów pokazujących, jak wynik ma wyglądać, i ten wygląd się nie zmienia. |
| Baza wiedzy (RAG) | Fakty dostępne modelowi w chwili odpowiadania | Gdy odpowiedź zależy od twoich dokumentów, a te dokumenty żyją i się zmieniają. |
Te warstwy się nie wykluczają i nie ma tu wyboru „albo-albo". Dobry prompt na bazie wiedzy pełnej starych plików wyprodukuje elegancko sformatowany błąd. Świetna baza wiedzy bez promptu odda surowe fragmenty dokumentów sklejone w akapit. Pisałem o agentach AI i tam widać to najostrzej: agent bez bazy wiedzy zmyśla z pełnym przekonaniem, agent z bazą wiedzy cytuje twoje dokumenty i podaje, z którego wziął odpowiedź.
Pięć kroków, po których model odpowiada z twoich dokumentów
Cała architektura sprowadza się do pięciu kroków, z których żaden nie wymaga zespołu badawczego ani osobnej infrastruktury. Dotyczy to wszystkich pięciu kroków opisanych niżej, nie tylko pierwszego.
Krok 1: zbierz dokumenty. Wszystko, co twoja firma wie i co dziś siedzi w rozproszeniu: procedury, odpowiedzi na częste pytania, wzorcowe maile, dokumentacja produktowa, notatki ze spotkań, szablony umów. Na tym etapie nie filtruj, tylko zbieraj. Format nie ma większego znaczenia, bo tekst wyciągniesz i z PDF-a, i z Notion, i z transkrypcji rozmowy.
Krok 2: potnij na fragmenty. Model nie dostanie całego dokumentu, tylko jego kawałek, więc rozmiar tego kawałka jest realnym parametrem systemu. Za duży fragment rozmywa znaczenie, bo jeden wektor musi opisać kilka różnych wątków naraz. Za mały gubi kontekst i zwraca zdanie, którego nikt nie umie zinterpretować bez akapitu obok. Typowy punkt startowy to kilkaset słów, ale traktuj to jako nastawę do sprawdzenia na własnych dokumentach, a nie jako wynik badania.
Krok 3: policz embeddingi. Każdy fragment przechodzi przez model embeddingowy i zamienia się w wektor — długi ciąg liczb reprezentujący znaczenie tekstu. Dwa fragmenty o zbliżonej treści dostają zbliżone wektory, nawet jeśli nie mają wspólnych słów. To jest dokładnie ten mechanizm, którego brakuje zwykłej wyszukiwarce po frazie.
Krok 4: zapisz w bazie wektorowej. Pgvector, Qdrant, Weaviate, Pinecone — wybór zależy od skali i budżetu, nie od ambicji. Na start pgvector, czyli rozszerzenie Postgresa, wystarczy w zupełności i jest darmowe. Osobna infrastruktura pierwszego dnia to koszt, którego jeszcze nie musisz ponosić.
Krok 5: podłącz do modelu. Gdy pada pytanie, system zamienia je na wektor, znajduje kilka najbliższych fragmentów, wkleja je do promptu jako kontekst i dopiero wtedy prosi model o odpowiedź. Model nie odpowiada z pamięci, tylko z materiału, który właśnie dostał. Stąd bierze się możliwość podania źródła przy każdej odpowiedzi — a to ona odróżnia narzędzie od zabawki.
Mniej niż 15% wdrożeń dotyka tego, co psuje się dopiero w produkcji
Do tego miejsca wygląda to na problem inżynierski z gotowym rozwiązaniem i po części tak właśnie jest. Przegląd systematyczny opublikowany w „Applied Sciences", obejmujący sześćdziesiąt trzy prace o firmowych wdrożeniach RAG, pokazuje, jak jednolicie sięga się dziś po te same klocki. Modele z rodziny GPT napędzają 63,6% opisanych wdrożeń. Gotowe biblioteki wyszukiwania w rodzaju FAISS albo Elasticsearcha obsługują 80,5% z nich.
Te dwie liczby nie mówią, że ktokolwiek robi coś źle. Mówią coś innego i ciekawszego: wybór modelu oraz biblioteki przestał być miejscem, w którym powstaje różnica między systemem działającym a bezużytecznym. Wszyscy biorą to samo z półki, więc jakość musi się rozstrzygać gdzie indziej.
Odpowiedź, gdzie dokładnie, leży w tym samym przeglądzie. Mniej niż 15% analizowanych prac w ogóle zajmuje się integracją w czasie rzeczywistym, czyli tym wszystkim, co pojawia się dopiero po wypuszczeniu systemu do ludzi. Autorzy nazywają tę dziurę luką „z laboratorium na rynek" i w praktyce ma ona trzy adresy.
Tydzień wystarczy, żeby sprawdzić, czy to ma u ciebie sens
Najgorsze, co możesz zrobić z tą listą, to rozpisać ją na kwartalny projekt z etapami i komitetem sterującym. Pierwszą wersję buduje się po to, żeby zobaczyć, czy odpowiedzi w ogóle robią się lepsze — a to widać po pięciu dniach.
Zanim zapłacisz za mocniejszy model, sprawdź, czego brakowało poprzedniemu
Kuszące jest myślenie, że kolejna wersja modelu rozwiąże to za ciebie. Czasem faktycznie rozwiązuje — okna rosną, trafność się poprawia, benchmarki idą w górę. Żadna z tych rzeczy nie sprawi jednak, że model dowie się, jak wygląda twój cennik od kwietnia, bo tej informacji nie ma w nim skąd wziąć.
Różnica między „ChatGPT powiedział mi coś ogólnego" a „nasz system odpowiedział na podstawie naszej procedury i podał, z której" to różnica między ciekawostką a narzędziem, na którym da się oprzeć proces. Wytwarza ją dostęp do dokumentów, nie rozmiar modelu. Nie utrzymuj generycznego asystenta tylko dlatego, że już za niego płacisz drugi rok.
Zacznij od jednego pytania, które nie brzmi „który model wybrać". Brzmi ono tak: gdyby twój najlepszy pracownik dostał od klienta to pytanie, do którego dokumentu by sięgnął? Jeśli umiesz go wskazać, masz pierwszy plik do bazy wiedzy i możesz zacząć w poniedziałek. Jeśli nie umiesz, problem jest większy niż AI i zaczyna się tam, gdzie ta wiedza nie istnieje nigdzie poza czyjąś głową.
Sprawdźmy, co da się zdjąć z Twojej głowy
Chcesz zbudować bazę wiedzy dla AI w swojej firmie, ale nie wiesz od czego zacząć? Pomogę Ci zmapować dokumenty, wybrać architekturę i postawić pierwszy prototyp w tydzień.
Napisz do mnie →Najczęściej zadawane pytania
Prompt engineering to praca nad samym pytaniem: lepsze sformułowanie, przykłady, instrukcja formatu. Context engineering to budowa systemu, który dostarcza modelowi właściwe dokumenty w chwili odpowiadania. Prompt ustawia formę odpowiedzi — ton, długość, układ. Baza wiedzy ustawia jej treść, czyli fakty, na których odpowiedź powstaje. Te dwie warstwy się nie wykluczają: dobry prompt na starych danych da elegancko sformatowany błąd, a dobra baza wiedzy bez promptu odda surowe fragmenty dokumentów sklejone w akapit.
RAG (Retrieval-Augmented Generation) to architektura, w której model przed napisaniem odpowiedzi wyszukuje pasujące fragmenty w twoich dokumentach i dopiero one trafiają do jego kontekstu. Zamiast polegać wyłącznie na wiedzy z treningu, dostaje aktualne dane z firmy. Praktyczna korzyść jest podwójna: odpowiedzi opierają się na twoich materiałach, a system może wskazać dokument, z którego je wziął. RAG nie zmienia przy tym samego modelu, tylko to, co model widzi — dlatego zmiana cennika w środę działa od środy.
Bo deklarowana pojemność okna i użyteczna pojemność okna to dwie różne wielkości. Benchmark NoLiMa sprawdził trzynaście modeli deklarujących obsługę co najmniej 128 000 tokenów, przy czym pytanie i szukany fragment celowo nie miały wspólnych słów. Przy 32 000 tokenów jedenaście z trzynastu modeli spadło poniżej połowy własnego wyniku z krótkiego kontekstu, a GPT-4o zjechał z 99,3% do 69,7%. Autorzy tłumaczą to tym, że mechanizm uwagi radzi sobie gorzej, gdy brakuje dosłownego pokrycia słów między pytaniem a odpowiedzią. RAG omija ten problem, podając modelowi kilka trafnych fragmentów zamiast całej dokumentacji.
Do faktów raczej nie. Badacze Microsoftu w pracy „Fine-Tuning or Retrieval?" porównali nienadzorowane dostrajanie modelu z wyszukiwaniem w bazie i wyszukiwanie wygrało konsekwentnie — zarówno przy wiedzy widzianej w treningu, jak i przy zupełnie nowej. Modele miały wyraźną trudność z przyswojeniem nowych faktów przez samo dostrajanie. Dostrajanie ma sens tam, gdzie chodzi o formę: styl, nazewnictwo, powtarzalny układ wyniku. Fakt musi dać się podmienić w środę, a wag modelu nikt w środę nie przelicza.
Pierwszy działający prototyp kosztuje głównie czas. Pgvector, czyli rozszerzenie Postgresa, jest darmowy i na start wystarcza; przeliczenie kilkudziesięciu dokumentów przez API embeddingowe to wydatek liczony w groszach; interfejs może być zwykłym oknem czatu albo skryptem z konsoli. Koszty rosną dopiero ze skalą i z liczbą przeliczeń przy odświeżaniu danych. Dlatego pierwszą wersję warto zbudować na jednym obszarze wiedzy zamiast na całej firmie — po pięciu dniach widać, czy odpowiedzi faktycznie się poprawiły.
Trzy, i wszystkie ujawniają się dopiero w produkcji. Pierwszy: samo wyszukiwanie wektorowe gubi numery katalogowe, symbole zamówień i skróty branżowe, dlatego łączy się je z dopasowaniem po słowach w wyszukiwaniu hybrydowym — benchmark BEIR pokazał, że słownikowy BM25 pozostaje mocnym punktem odniesienia, a modele gęstego wyszukiwania często wypadają od niego gorzej poza swoją domeną. Drugi: nieodświeżane dane, bo raz policzone embeddingi nie starzeją się z żadnym komunikatem błędu. Trzeci: brak kontroli dostępu — filtrowanie musi się dziać przed podaniem fragmentów modelowi, nigdy po wygenerowaniu odpowiedzi.
Od jednego obszaru, w którym ludzie najczęściej pytają o to samo. Dzień pierwszy: zbierz dwadzieścia do trzydziestu dokumentów opisujących ten obszar i wyeksportuj je do zwykłego tekstu. Dni drugi i trzeci: potnij na fragmenty, policz embeddingi, wrzuć do bazy wektorowej. Dni czwarty i piąty: podłącz najprostszy interfejs, w którym działa pętla pytanie — wyszukanie — odpowiedź ze wskazaniem źródła. Drugi tydzień: oddaj to zespołowi i zbieraj konkretne przypadki zamiast ogólnych wrażeń, zwłaszcza te, w których w bazie brakowało czegoś, o czym wszyscy sądzili, że jest spisane.
Szymon Mojsak
Ekspert automatyzacji procesów biznesowych i współwłaściciel RCPonline — systemu rejestracji czasu pracy.
Teoria zastosowana w praktyce — treści opieram na własnych doświadczeniach zdobytych przy wdrożeniach i w relacjach międzyludzkich.
Poszerzam horyzonty — nieustannie rozwijam wiedzę z zakresu marketingu, psychologii i IT.
Zamieniam twórczy chaos w kierunek — najpierw pytanie „po co”, dopiero potem „jak”. Pomagam zrozumieć procesy, by je usprawnić.
Ten materiał powstał z udziałem AI
Narzędzia AI — wspierały research, redakcję tekstu i przygotowanie ilustracji.
Autor — wybiera temat, pisze pierwszą wersję i redaguje całość przed publikacją. Doświadczenia, oceny i punkt widzenia w tekście są jego własne.
Ładowanie komentarzy...