Kiedy firmy wdrażają AI Communication Center, popełniają ten sam błąd. Mają dobry model, dobrą platformę, ale źle przygotowaną bazę wiedzy. Wynik? Bot odpowiada źle na pytania użytkowników. Klienci są sfrustrowani. Projekt zostaje spisany na straty.
Historia, którą zaraz opowiem, zdarzyła się naprawdę. Zmienię tylko nazwę firmy, bo nikt nie lubi być negatywnym przykładem.
Firma, nazwijmy ją "TechShop", sprzedaje elektronikę online. 2000 zamówień dziennie, 400 zapytań do obsługi klienta, 8 konsultantów na zmianie. Postanowili wdrożyć AI. Wybrali dobry model językowy, podłączyli go do czatu na stronie, a potem zrobili to, co robi większość firm: wzięli swój wewnętrzny dokument "Baza wiedzy obsługi klienta.docx" – 180 stron, wszystko w jednym pliku – i wrzucili go do systemu.
Przez pierwszy tydzień wyglądało obiecująco. Bot odpowiadał na proste pytania. Zespół świętował wdrożenie sztucznej inteligencji.
W drugim tygodniu zaczęły się problemy. Klient zapytał o zwrot słuchawek Bluetooth. Bot odpowiedział procedurą zwrotu telewizorów, bo w tym samym dokumencie, kilka stron dalej, była sekcja o zwrotach dużego AGD, i system uznał ją za bardziej pasującą. Inny klient zapytał o gwarancję na laptopa. Bot podał warunki gwarancji na smartfony, bo oba fragmenty zawierały słowo "gwarancja" i "elektronika", a system nie potrafił rozróżnić kontekstu.
W trzecim tygodniu dyrektor operacyjny dostał raport: bot poprawnie odpowiadał na 43% zapytań. Reszta to były odpowiedzi nieprecyzyjne, nieaktualne lub po prostu błędne. Konsultanci spędzali więcej czasu na prostowaniu pomyłek bota niż na obsłudze klientów bezpośrednio. Sztuczna inteligencja nie działa tak, jak oczekiwano.
Co poszło nie tak? Nie chodziło o model czy technologię, lecz o niewłaściwe przygotowanie bazy wiedzy.
Zanim powiemy, jak przygotować bazę wiedzy w odpowiedni sposób, musimy zrozumieć, jak działa mechanizm, który z niej korzysta. Bez zrozumienia tego pojęcia każda rada będzie abstrakcyjna.
RAG, czyli Retrieval-Augmented Generation to architektura, która łączy dwa światy: wyszukiwanie informacji i generowanie odpowiedzi. Brzmi technicznie, ale idea jest prosta. Wyobraź sobie eksperta, który zamiast odpowiadać z pamięci, najpierw sięga po odpowiedni podręcznik, znajduje właściwy rozdział, czyta go, a dopiero potem formułuje odpowiedź na zadawane pytania. Dokładnie tak działa RAG.
Proces wygląda następująco. Klient zadaje pytanie, powiedzmy: "Kupiłam buty tydzień temu, są za małe, co mogę zrobić?". System zamienia to pytanie na embedding – wektor matematyczny, ciąg liczb, który reprezentuje znaczenie tego zdania w przestrzeni wielowymiarowej.
To nie jest wyszukiwanie słów kluczowych. System nie szuka dokumentu, który zawiera słowo "buty". Szuka dokumentu, którego znaczenie jest najbliższe znaczeniu zapytania użytkownika. To jest fundamentalna różnica między tradycyjnym wyszukiwaniem a wyszukiwaniem semantycznym.
Następnie system porównuje ten wektor z wektorami wszystkich dokumentów w bazie wiedzy. Każdy dokument został wcześniej przetworzony w ten sam sposób – podzielony na fragmenty (chunki), zamieniony na embeddingi i zapisany w bazie wektorowej. System znajduje fragmenty o najwyższym podobieństwie semantycznym, te, które "znaczą" coś najbliższego pytaniu klienta.
Te fragmenty trafiają do modelu językowego jako kontekst. Model czyta pytanie klienta, czyta znalezione fragmenty wiedzy i na tej podstawie generuje odpowiedź. Nie halucynuje, odpowiada na podstawie konkretnych dokumentów. A przynajmniej tak powinno być, jeśli baza wiedzy zawiera aktualne informacje i jest dobrze przygotowana.
I tu dochodzimy do sedna problemu.
Wróćmy do TechShopu i ich 180-stronicowego pliku. Co się dzieje, gdy system RAG próbuje z niego korzystać?
Najpierw plik jest dzielony na fragmenty – zazwyczaj po 500-1000 tokenów (mniej więcej pół strony tekstu). Ze 180 stron powstaje około 400 fragmentów. Każdy fragment jest zamieniany na embedding i trafia do bazy wektorowej.
Fragment o zwrotach słuchawek Bluetooth i fragment o zwrotach telewizorów mają bardzo podobne embeddingi, bo oba mówią o "zwrotach elektroniki". System nie wie, że to są zupełnie różne procedury z różnymi warunkami. Widzi tylko, że oba fragmenty są semantycznie blisko zapytania użytkownika.
W jednym wielkim dokumencie procedura zwrotu sąsiaduje z cennikiem, który sąsiaduje z FAQ, który sąsiaduje z regulaminem gwarancji. Fragmenty z różnych sekcji mieszają się. Model językowy dostaje pięć fragmentów "kontekstu", z których dwa dotyczą zwrotów, jeden cennika, jeden gwarancji i jeden regulaminu sklepu. Musi sam zdecydować, co jest istotne – czasem trafia, częściej nie.
Zmienił się regulamin zwrotów? Musisz otworzyć 180-stronicowy dokument, znaleźć właściwą sekcję, zmienić ją, a potem przeindeksować cały plik, żeby zawierał aktualne informacje. Wszystkie 400 fragmentów musi zostać ponownie przetworzonych na embeddingi. To kosztuje – dosłownie, bo za każde przetworzenie płacisz dostawcy modelu embeddingowego.
Porównaj to z podejściem, w którym masz osobny dokument "Procedura zwrotu – słuchawki i akcesoria" (2 strony) i osobny "Procedura zwrotu – duże AGD i TV" (2 strony). System RAG od razu wie, który dokument jest bliższy pytaniu klienta i z którego źródła wiedzy skorzystać. Nie ma szumu. Nie ma pomyłek. A gdy zmieni się procedura zwrotu słuchawek, przeindeksowujesz tylko ten jeden mały dokument i w ten sposób dodajesz do systemu najnowsze informacje.
Skoro wiemy, czego nie robić, porozmawiajmy o tym, jak wygląda przygotowanie treści, które sprawią, że RAG działa jak szwajcarski zegarek.
Dobry dokument dla RAG ma trzy warstwy:
Na początku dokumentu umieszczasz blok informacji: kategoria, priorytet, słowa kluczowe, symptomy (czyli jak klient opisuje problem swoimi słowami). Te metadane działają jak "wzmacniacze" (boostery) wyszukiwania. Gdy klient mówi "nie mogę się zalogować", system nie tylko szuka dokumentów semantycznie bliskich temu zdaniu, ale też sprawdza, czy któryś dokument ma w symptomach dokładnie taką frazę. Jeśli tak – ten dokument dostaje wyższy priorytet.
Słowa kluczowe powinny zawierać synonimy i potoczne określenia. Klient nie powie "procedura resetu hasła". Powie "nie pamiętam hasła", "nie mogę wejść na konto", "zablokował mi się login". Każda z tych fraz powinna znaleźć się w metadanych dokumentu o resetowaniu hasła.
I tu jest fundamentalna zmiana w myśleniu, której wymaga RAG. Jeśli kiedykolwiek budowałeś bazę wiedzy dla tradycyjnego chatbota lub systemu IVR, przyzwyczaiłeś się do formatu "krótkie hasło → krótka odpowiedź". Reset hasła → Kliknij "Nie pamiętam hasła" na stronie logowania. Zablokowane konto → Konto odblokuje się po 30 minutach.
Ten format jest nieskuteczny w systemach RAG. Dlaczego? Bo embeddingi potrzebują kontekstu. Krótkie hasło "reset hasła" to za mało informacji, żeby system zrozumiał, o czym jest dokument. Może to być reset hasła do sklepu, do panelu administracyjnego, do aplikacji mobilnej, do Wi-Fi w biurze. Bez kontekstu embedding jest "rozmyty" – pasuje do wielu zapytań, ale do żadnego precyzyjnie.
Odpowiedni dokument RAG opisuje problem pełnymi zdaniami: co się dzieje, dlaczego, jakie są przyczyny, jakie kroki podjąć, jak zweryfikować rozwiązanie. Im bogatszy kontekst, tym precyzyjniejszy embedding, tym trafniejsze dopasowanie do pytania klienta.
Może brzmi to nieituicyjnie – "więcej tekstu = lepsza precyzja?" – ale tak właśnie działają embeddingi semantyczne. Dłuższy dokument z opisem problemu, przyczynami i rozwiązaniem daje silnikowi więcej punktów dopasowania. Krótkie hasło "reset hasła" może pasować do 20 różnych kontekstów. Pełny opis procedury z symptomami i krokami trafia precyzyjnie.
Teorii było dużo. Zobaczmy teraz, jak to wygląda w praktyce na przykładzie, który mógłby się zdarzyć w dowolnym sklepie internetowym.
Klient dzwoni i mówi: "Kupiłem u was odtwarzacz multimedialny dwa tygodnie temu. Od wczoraj nie chce mi się ładować. Podłączam kabel, dioda miga raz i gaśnie. Próbowałem innym kablem – to samo."
To jest realne pytanie. Naturalny język, emocje, szczegóły techniczne, kontekst czasowy. Zobaczmy, jak na to pytanie odpowie system RAG w zależności od tego, jak przygotowaliśmy bazę wiedzy.
Wiele firm przygotowuje bazę wiedzy tak, jak przygotowywało ją dla tradycyjnych chatbotów – w formie lakonicznych punktów:
Co widzi system RAG? Cztery krótkie fragmenty. Embedding pytania klienta, który mówi o odtwarzaczu, ładowaniu, diodzie, kablu, dwóch tygodniach, musi zostać dopasowany do jednego z tych fragmentów. Problem w tym, że hasło "Problemy z ładowaniem: Sprawdź kabel i zasilacz" ma embedding semantycznie bliski, ale jednocześnie hasło "Zwrot produktu – 14 dni" też jest blisko, bo klient wspomniał o dwóch tygodniach. A "Reklamacja" też pasuje, bo klient opisuje usterkę.
System nie wie, co wybrać. Embeddingi tych czterech haseł są zbyt krótkie, żeby system mógł zrozumieć różnice między nimi. Wynik? Model dostaje trzy fragmenty o podobnym score, z których żaden nie daje mu wystarczającego kontekstu, żeby odpowiedzieć precyzyjnie. Odpowiada więc ogólnikowo: "Proszę sprawdzić kabel i zasilacz. Jeśli problem się powtarza, prosimy o wypełnienie formularza reklamacyjnego."
Klient jest sfrustrowany. Już sprawdził kabel. Chce wiedzieć, co dalej – czy to reklamacja, czy zwrot, czy wymiana. Bot nie pomógł.
Trafność: 43% (jak w przypadku TechShopu)
Teraz ten sam scenariusz, ale z bazą wiedzy napisaną tak, jak powinno się ja napisać dla systemu RAG. Zamiast czterech haseł, mamy osobny dokument:
Symptomy zgłaszane przez klientów: nie ładuje się, nie włącza się, dioda miga i gaśnie, szybko się rozładowuje, nie trzyma baterii, ładowanie nie działa. Klienci często zgłaszają problemy z ładowaniem urządzeń elektronicznych. Najczęstsze objawy to: urządzenie nie reaguje na podłączenie kabla ładującego, dioda ładowania miga krótko i gaśnie, urządzenie nie włącza się mimo ładowania przez kilka godzin, bateria rozładowuje się znacznie szybciej niż na początku użytkowania.
Krok 1. Diagnostyka wstępna.
Poproś klienta o sprawdzenie, czy używa oryginalnego kabla i zasilacza dołączonego do urządzenia. Jeśli klient próbował już innym kablem i problem się powtarza, przejdź do kroku drugiego.
Krok 2. Ustalenie ścieżki obsługi.
Jeśli produkt został zakupiony w ciągu ostatnich 14 dni, klient ma prawo do zwrotu bez podania przyczyny (formularz na stronie w zakładce "Zwroty"). Jeśli minęło więcej niż 14 dni, ale produkt jest na gwarancji (24 miesiące od daty zakupu), klient powinien złożyć reklamację. Poinformuj klienta, że reklamacja zostanie rozpatrzona w ciągu 14 dni roboczych.
Krok 3. Reklamacja.
Poproś klienta o numer zamówienia. Wyjaśnij, że po złożeniu reklamacji otrzyma etykietę zwrotną na e-mail w ciągu 24 godzin. Urządzenie zostanie zdiagnozowane w serwisie, jeśli usterka zostanie potwierdzona, klient otrzyma nowe urządzenie lub zwrot pieniędzy. Ważne: Nie sugeruj klientowi, że usterka wynika z jego winy (np. "pewnie używał Pan złego kabla"). Traktuj każde zgłoszenie jako potencjalną usterkę fabryczną.
Co widzi system RAG teraz? Embedding tego dokumentu jest nasycony kontekstem. Zawiera słowa kluczowe, których klient faktycznie używa: "nie ładuje się", "dioda miga i gaśnie", "próbowałem innym kablem". Symptomy w metadanych pokrywają się z opisem klienta niemal dosłownie. Score dopasowania jest wysoki i jednoznaczny, a system nie ma wątpliwości, który dokument wybrać.
Model językowy dostaje ten jeden, precyzyjny dokument i generuje odpowiedź: "Rozumiem, że odtwarzacz nie chce się ładować mimo próby z innym kablem. Skoro minęły dwa tygodnie od zakupu, najlepszą ścieżką będzie reklamacja gwarancyjna. Czy mogę prosić o numer zamówienia? Po jego podaniu wyślemy Panu etykietę zwrotną na e-mail w ciągu 24 godzin, a nasz serwis zdiagnozuje urządzenie."
Klient dostaje konkretną odpowiedź w czasie rzeczywistym. Wie, co się stanie dalej. Czuje się zaopiekowany.
Trafność: 89% (wynik po optymalizacji bazy wiedzy)
W wariancie A system RAG miał do dyspozycji 30 słów kontekstu. W wariancie B ponad 200 słów, z symptomami, procedurą krok po kroku i tonem rozmowy. To kwestia tego, że embeddingi semantyczne potrzebują punktów zaczepienia – słów i fraz, które pokrywają się ze sposobem, w jaki klienci opisują swoje problemy.
Klient nigdy nie powie "reklamacja urządzenia elektronicznego" i to ma kluczowe znaczenie. Powie "kupiony odtwarzacz nie chce się ładować, dioda miga". Jeśli Twoja baza wiedzy nie zawiera takich fraz to system ich nie znajdzie. Nie dlatego, że model jest niewłaściwy. Problem leży w tym, że nie zapewniłeś mu odpowiednich warunków do skutecznej pracy.
To jest dokładnie ta sama zasada, która obowiązuje w wyszukiwarkach internetowych. Google nie rankuje stron z tytułem "Buty". Rankuje strony opisujące "czarne skórzane buty do biegania rozmiar 43". RAG działa identycznie.
RAG nie jest darmowy, a korzystanie z niego wymaga podejmowania świadomych decyzji. Każdy element pipeline'u generuje koszty i warto wiedzieć, gdzie dokładnie, żeby móc je optymalizować.
Każdy dokument w bazie wiedzy musi zostać zamieniony na embedding – wektor matematyny. Za tę operację płacisz dostawcy modelu embeddingowego (np. OpenAI, Cohere, lokalne modele). Koszt jest niewielki per dokument, rzędu ułamków grosza, ale rośnie z liczbą dokumentów i częstotliwością aktualizacji.
Jeśli masz 500 dokumentów i aktualizujesz 50 z nich dziennie, to 50 operacji embeddingowych dziennie. Przy dużych bazach i częstych zmianach warto zaplanować strategię aktualizacji, na przykład synchronizacja raz dziennie zamiast w czasie rzeczywistym.
Embeddingi zajmują miejsce w bazie wektorowej. To nie są duże koszty, ale rosną liniowo z rozmiarem bazy. 500 dokumentów to nic. 50 000 dokumentów w 10 językach wymaga już planowania.
Każde zapytanie klienta wymaga wygenerowania embeddingu pytania i porównania go z bazą. To jest koszt per-zapytanie. Przy 1000 zapytań dziennie jest pomijalny, przy 100 000 zaczyna się liczyć.
Gdy system RAG znajdzie pasujące fragmenty, wysyła je do modelu językowego jako kontekst. Im więcej fragmentów, im dłuższe dokumenty, tym więcej tokenów. A tokeny w GPT-4 czy Claude to najdroższa część pipeline'u.
Dlatego dobrze przygotowana baza wiedzy – z krótkimi, precyzyjnymi dokumentami zamiast jednego wielkiego pliku – bezpośrednio obniża koszty i może przynieść znaczne korzyści. Zamiast wysyłać modelowi 5000 tokenów kontekstu (bo fragmenty z wielkiego pliku są rozmyte i system musi wysłać więcej, żeby "trafić"), wysyłasz 1500 tokenów z precyzyjnie dopasowanego dokumentu.
Query rewriting (przepisywanie zapytania, żeby lepiej pasowało do bazy), re-ranking (ponowne sortowanie wyników wyszukiwania), tłumaczenie zapytań w kontekście wielojęzycznym – każda z tych technik poprawia jakość, ale dodaje latencję i koszty. W kontekście czatu tekstowego dodatkowe 200-300 milisekund jest niezauważalne. W kontekście rozmowy głosowej, gdzie każda sekunda ciszy jest odczuwalna, to istotny kompromis.
Dobrze przygotowana baza wiedzy to nie tylko lepsza jakość odpowiedzi w czasie rzeczywistym. To też niższe koszty operacyjne. Precyzyjne dokumenty = precyzyjne dopasowanie = mniej tokenów wysyłanych do modelu = niższy rachunek na koniec miesiąca.
Jest pytanie, które słyszymy od niemal każdego klienta: "Czy nie mogę po prostu wrzucić całej wiedzy do system promptu?"
Technicznie możesz, ale praktycznie to droga donikąd.
System prompt to instrukcja, którą model językowy otrzymuje na początku każdej rozmowy. Definiuje, kim jest agent, jak ma się zachowywać, jakim tonem mówić, czego nie wolno mu robić. To "osobowość" i "regulamin pracy" agenta.
Baza RAG to "podręcznik", z którego agent korzysta w razie potrzeby. Nie nosi go cały czas w głowie, sięga po niego, gdy potrzebuje konkretnej informacji.
Różnica jest fundamentalna. System prompt jest wysyłany do modelu AI przy każdym zapytaniu. Każde słowo w nim to tokeny, za które płacisz. Jeśli wrzucisz do system promptu 50 stron procedur, każda rozmowa z klientem zaczyna się od przetworzenia tych 50 stron, nawet jeśli klient pyta tylko o godziny otwarcia.
RAG działa odwrotnie, pobiera tylko te fragmenty wiedzy, które są istotne dla konkretnego pytania. Klient pyta o zwrot? System pobiera procedurę zwrotu. Klient pyta o godziny? System pobiera informacje kontaktowe. Reszta bazy wiedzy nie jest przetwarzana i nie generuje kosztów.
Zasada kciuka jest prosta. Jeśli informacja jest stała i dotyczy zachowania agenta – "zawsze mów po polsku", "nie obiecuj rabatów", "przy reklamacjach eskaluj do konsultanta" – umieść ją w system prompcie. Jeśli informacja jest zmienna i dotyczy wiedzy merytorycznej – procedury, cenniki, FAQ, opisy produktów – umieść ją w RAG. Dzięki temu system prompt pozostaje lekki (200-500 tokenów), a koszty są pod kontrolą.
Jeśli Twoja firma obsługuje klientów w kilku językach, Retrieval-Augmented Generation stawia przed Tobą wyzwanie, o którym większość dostawców próbuje przemilczeć.
Model językowy (GPT-4, Claude, Gemini) potrafi generować odpowiedzi w praktycznie dowolnym języku. Klient pisze po niemiecku? Model odpowie po niemiecku. Nawet jeśli baza wiedzy jest po polsku. To działa, bo modele językowe są z natury wielojęzyczne.
Ale RAG to nie duży model językowy, RAG to wyszukiwarka semantyczna i tu zaczyna się problem.
Embeddingi – te wektory matematyczne, o których mówiliśmy – są wrażliwe na język. Pytanie po niemiecku "Wie kann ich mein Passwort zurücksetzen?" i dokument po polsku "Reset hasła użytkownika" to dwa różne punkty w przestrzeni wektorowej. Modele embeddingowe były trenowane głównie na danych anglojęzycznych i dopasowanie cross-language (np. niemiecki → polski) ma znacznie niższy score niż dopasowanie w tym samym języku.
Co to oznacza w praktyce? Że klient z Niemiec może nie dostać właściwej odpowiedzi – nie dlatego, że wiedza nie istnieje w bazie wiedzy, ale dlatego, że system jej nie znalazł.
Są trzy strategie radzenia sobie z tym problemem:
Każda z tych strategii ma swoje kompromisy, ale najgorsza strategia to brak strategii – czyli udawanie, że problem nie istnieje i liczenie, że "jakoś to będzie".
Jest jeszcze jedna rzecz, o której firmy zapominają po wdrożeniu: baza wiedzy żyje. Produkty się zmieniają. Regulaminy się aktualizują. Procedury ewoluują. Nowe pytania klientów wymagają nowych dokumentów, najnowszych informacji, aktualnych danych.
Aktualizacja dokumentu w bazie RAG to nie jest proste "wrzucenie nowego pliku". Każda zmiana wymaga konwersji dokumentu do ustandaryzowanego formatu, ponownego podziału na fragmenty (chunking) i co najważniejsze reindeksacji embeddingów, czyli ponownego przeliczenia wektorów semantycznych. To generuje realne koszty.
Dlatego potrzebujesz procesu. Kto jest odpowiedzialny za aktualizację wiedzy? Jak często? Skąd bierze informacje o zmianach? Jak weryfikuje, że agent udziela trafnych odpowiedzi po aktualizacji?
Najlepsze firmy, z którymi pracujemy, wyznaczają "opiekuna wiedzy AI" – osobę, która regularnie przegląda rozmowy agentów, identyfikuje przypadki błędnych odpowiedzi, aktualizuje dokumenty i testuje zmiany. To nie musi być inżynier. To może być doświadczony menedżer obsługi klienta, który rozumie, czego potrzebują klienci i potrafi przełożyć to na dokumenty zrozumiałe dla systemu RAG.
Jeśli Twoja firma korzysta z SharePoint, Confluence lub innego systemu zarządzania dokumentami, warto rozważyć automatyczną synchronizację. Zmiana dokumentu w SharePoint automatycznie aktualizuje bazę RAG. Bez ręcznego kopiowania i bez ryzyka, że agent odpowiada na podstawie nieaktualnej wersji.
Wróćmy do naszej historii. TechShop, po trzech tygodniach rozczarowujących wyników, nie zrezygnował z AI. Zamiast tego zmienił podejście w codziennej pracy.
Wzięli swój 180-stronicowy dokument i rozbili go na 47 osobnych dokumentów z różnych działów. Każdy dotyczył jednego tematu: "Zwrot – duże AGD", "Gwarancja – laptopy", "Gwarancja – smartfony", "Status zamówienia — FAQ", "Zmiana adresu dostawy". Każdy dokument miał 1-3 strony, jasne metadane, słowa kluczowe i symptomy opisane językiem klienta.
Dodali metadane YAML na początku każdego dokumentu: kategorie, priorytety, synonimy. Napisali treść pełnymi zdaniami, z kontekstem, zamiast telegraficznych haseł.
Efekt? Po dwóch tygodniach od przebudowy bazy wiedzy, trafność odpowiedzi wzrosła z 43% do 81%. Po miesiącu iteracji, drobnych poprawek na podstawie wyników i analizy prawdziwych rozmów, osiągnęli 89%. Konsultanci zajmowali się już tylko złożonymi reklamacjami i klientami VIP, a bot obsługiwał resztę.
Nie zmienili modelu językowego. Nie zmienili platformy. Zmienili bazę wiedzy i zyskali wyjątkową obsługę klienta w swojej organizacji.
Jeśli po przeczytaniu tego artykułu lepiej rozumiesz zastosowania RAG i myślisz: "OK, muszę przejrzeć naszą bazę wiedzy" – to dobrze. To pierwszy krok, w drugim możesz zgłębić temat jeszcze bardziej i sprawdzić - TALK Playbook: kompletny przewodnik po budowaniu Centrum Komunikacji AI. Znajdziesz tam szczegółowe instrukcje przygotowania bazy wiedzy, formatowania dokumentów dla RAG, projektowania system promptów, integracji z SharePoint i wiele więcej. 17 rozdziałów, a w nich same konkrety i najlepsze praktyki.
