RAG w praktyce: jak podpiąć dane firmowe do LLM

Co to jest RAG i kiedy ma sens w firmie

RAG jako sposób dopinania własnych danych do LLM

RAG (retrieval augmented generation) to wzorzec, w którym model językowy (LLM) nie „wymyśla” wszystkiego z głowy, tylko przed wygenerowaniem odpowiedzi dostaje świeży kontekst wyszukany z Twoich danych firmowych. Najpierw system wyszukuje relewantne fragmenty dokumentów, a dopiero potem dokleja je do promptu, który trafia do modelu.

W praktyce wygląda to tak:

• użytkownik zadaje pytanie (np. „Jak zgłosić incydent bezpieczeństwa w naszej firmie?”),
• system zamienia pytanie na wektor (embedding) i szuka podobnych fragmentów w bazie wiedzy,
• kilka najlepszych fragmentów (chunków) jest wstrzykiwanych do promptu,
• LLM generuje odpowiedź, opierając się głównie na tym kontekście, a nie wyłącznie na własnym „ogólnym” treningu.

Kluczowa zaleta: nie trenujesz modelu od zera, nie robisz kosztownego fine-tuningu na każdym drobnym update’cie procedury, tylko aktualizujesz dane w bazie wektorowej. Aktualizacja polityki czy regulaminu to zwykle:

• nowa wersja dokumentu,
• ponowne pocięcie na fragmenty,
• ponowna wektoryzacja i podmiana rekordów w bazie.

Fine-tuning, RAG i proste promptowanie – praktyczne porównanie

Do „podpięcia” wiedzy firmowej pod LLM są trzy główne strategie:

W wielu organizacjach rozsądny jest kompromis: RAG jako fundament, a fine-tuning tylko tam, gdzie naprawdę potrzebny jest firmowy styl, dokładna kontrola tonu wypowiedzi lub działasz w środowisku bez dostępu do zewnętrznych API.

Typowe use case’y RAG w firmie

Najczęściej RAG w firmie pojawia się w kilku powtarzalnych scenariuszach:

• Wyszukiwarka po dokumentach – „Google wewnętrzny”, ale z rozumieniem treści, a nie tylko słów kluczowych.
• Asystent wiedzy o produktach – dla działu sprzedaży, customer success, partnerów; odpowiedzi z aktualnych cenników, kart produktów, FAQ.
• Wsparcie helpdesku i IT – RAG zasilany ticketami, procedurami, artykułami w bazie wiedzy, aby odpowiadać na pytania pracowników i klientów.
• Onboarding pracowników – Q&A z polityk HR, regulaminów, instrukcji sprzętowych.
• Asystent prawny / compliance – wyszukiwanie i streszczanie klauzul z umów, polityk, regulacji wewnętrznych.

Realistyczny przykład z PDF-ami procedur

Korporacja ma tysiące PDF‑ów z procedurami: bezpieczeństwo, HR, finanse, IT, BHP. Pracownicy, zamiast wertować SharePointa, chcą zadać pytanie w stylu: „Jak zgłosić utratę służbowego laptopa?”. Manualne szukanie w intranecie trwa długo, a i tak często kończy się pytaniem na Slacku.

RAG pozwala:

• zindeksować treść wszystkich PDF‑ów w bazie wektorowej,
• zachować metadane (dział, wersja, data),
• w odpowiedzi LLM cytować konkretne paragrafy z odpowiednich dokumentów,
• dodać filtr uprawnień, żeby pracownik z działu A nie widział poufnych procedur działu B.

Efekt: realne skrócenie czasu szukania informacji i mniejsza liczba powtarzających się pytań do działów wsparcia wewnętrznego.

Podstawowa architektura RAG – z czego to się składa

Kluczowe komponenty w architekturze RAG

Przy wdrażaniu RAG pomaga myślenie o systemie jak o kilku modułach, które można rozwijać niezależnie. Klasyczna architektura obejmuje:

• Źródła danych – SharePoint, dyski sieciowe, wiki (Confluence, Notion), bazy SQL, CRM, narzędzia ticketowe, Slack/Teams, e‑maile.
• Moduł ekstrakcji – parsowanie PDF‑ów, DOCX, HTML, treści z API; czyszczenie, normalizacja, wykrywanie duplikatów.
• Chunking – dzielenie dokumentów na fragmenty (chunki), które będą wektoryzowane.
• Embeddingi – moduł generujący wektory numeryczne dla każdego fragmentu.
• Baza wektorowa – przechowuje wektory + metadane, pozwala na szybkie wyszukiwanie podobieństwa.
• Warstwa zapytań (retrieval + biznesowa logika) – przyjmuje pytanie użytkownika, stosuje filtry, odpytuje bazę, kontroluje uprawnienia.
• LLM – model generujący odpowiedź na bazie promptu i dostarczonego kontekstu.

Owocny projekt zwykle wymaga klarownego zdefiniowania interfejsów między modułami – np. jak wygląda obiekt DocumentChunk, co dokładnie zapisujesz w metadanych, jak opisujesz uprawnienia.

Przepływ pojedynczego zapytania w systemie RAG

Schemat jednego requestu (wysoko‑poziomowo) wygląda następująco:

1. Użytkownik wysyła pytanie: tekst + kontekst (np. identyfikator użytkownika, język).
2. Warstwa wejściowa normalizuje pytanie: usuwa zbędne białe znaki, ujednolica język, może robić korektę pisowni.
3. Model embeddingowy tworzy wektor dla pytania.
4. Baza wektorowa znajduje najbardziej podobne chunki, stosując filtry po metadanych (np. dział=„HR”, kraj=„PL”, poziom poufności <= poziom użytkownika).
5. Warstwa biznesowa wybiera i układa fragmenty w kolejności, skraca je lub łączy, czasem wykonuje dodatkowe przetwarzanie.
6. Orkiestracja promptów buduje prompt dla LLM: instrukcja systemowa, pytanie użytkownika, kontekst z dokumentów, oczekiwany format.
7. LLM generuje odpowiedź.
8. Post‑processing – np. dodanie listy źródeł, ocena pewności, logowanie zdarzenia do audytu.

RAG „na surowo” vs frameworki (LangChain, LlamaIndex, Haystack)

Można zbudować RAG od zera, korzystając wyłącznie z SDK wybranego LLM i bazy wektorowej. Druga droga to użycie frameworków:

• LangChain – popularny ekosystem w Pythonie i JS, oferuje łańcuchy (chains), narzędzia do integracji z wieloma źródłami danych, gotowe komponenty do RAG.
• LlamaIndex (dawniej GPT Index) – bardzo nastawiony na RAG, indeksy dokumentów, różne strategie chunkingu i retrievalu.
• Haystack – framework z silnym naciskiem na wyszukiwanie i pipeline’y NLP.

Frameworki przyspieszają start, ale niosą koszt złożoności. W małym POC często wystarczy:

• prosty skrypt do ekstrakcji i chunkingu,
• jedna baza wektorowa (np. Qdrant, Pinecone),
• kilka endpointów API po stronie backendu.

Większe wdrożenia zwykle i tak kończą na pół‑customowych rozwiązaniach, z selektywnym użyciem elementów z frameworków, a nie pełnym przyjęciem całego stosu.

Logika biznesowa i filtry uprawnień w architekturze RAG

RAG w firmie musi respektować uprawnienia – inaczej skończy się spektakularnym wyciekiem wewnętrznych dokumentów dla osób nieuprawnionych. Kluczowe miejsca, gdzie powinna pojawić się logika biznesowa:

• Metadane dokumentów – poziom poufności, dział, kraj, typ dokumentu, wersja, tagi RODO itp.
• Warstwa retrievalu – filtry po metadanych na podstawie tożsamości użytkownika i jego ról (RBAC/ABAC).
• Orkiestracja promptów – reguły, czy można cytować pełne fragmenty, czy trzeba je skracać lub anonimizować.
• Post‑processing – sanity check odpowiedzi: czy w odpowiedzi nie padły słowa kluczowe sugerujące wyciek (np. numery PESEL, dane osobowe, tajemnice handlowe).

Typowy wzorzec: baza wektorowa widzi tylko te dokumenty, do których użytkownik ma dostęp. To oznacza, że filtry uprawnień muszą być stosowane przed zapytaniem lub jako część zapytania (np. where department in (…) and clearance_level <= …).

Inwentaryzacja i przygotowanie danych firmowych

Mapa źródeł danych w organizacji

Pierwszy praktyczny krok to spisanie konkretnych źródeł danych, z których RAG ma korzystać. Typowe kategorie:

• Pliki – PDF, DOCX, PPTX, XLSX, teksty na dyskach sieciowych, SharePoint, Google Drive.
• Bazy SQL – systemy ERP, zamówienia, faktury, rejestry projektów, dane konfiguracji.
• Wiki i intranet – Confluence, Notion, portale intranetowe.
• Systemy ticketowe – Jira Service Management, ServiceNow, Zendesk; szczególnie bazy wiedzy i archiwa zgłoszeń.
• CRM – Salesforce, HubSpot, Dynamics; dane o klientach, produktach, historii interakcji.
• Komunikatory – Slack, Microsoft Teams, kanały tematyczne, wątki z często zadawanymi pytaniami.
• Mail – e‑maile do helpdesku, skrzynki zespołowe; raczej jako dodatkowe źródło, z dużą ostrożnością prywatności.

Na tym etapie nie chodzi o dokładne modelowanie, tylko o listę: gdzie jest wiedza, w jakich formatach, kto jest właścicielem danego repozytorium.

Priorytetyzacja: od czego zacząć, aby szybko zobaczyć efekt

RAG da największy efekt tam, gdzie:

• pracownicy lub klienci ciągle zadają powtarzające się pytania,
• istnieją już w miarę aktualne dokumenty (FAQ, instrukcje, procedury),
• czas reakcji jest krytyczny (np. incydenty bezpieczeństwa, awarie systemów),
• typ pytań silnie zależy od aktualnej, specyficznej wiedzy firmy (np. konfiguracje, stany magazynowe, polityki lokalne).

Dobry punkt startu:

• baza wiedzy helpdesku + procedury IT,
• polityki HR i najczęstsze pytania pracowników,
• FAQ produktowe + karty produktów,
• wewnętrzna dokumentacja procesów (procesy zakupowe, rozliczenia delegacji, zgłaszanie incydentów).

Start z jedną dziedziną (np. „wewnętrzne IT”) umożliwia szybkie wdrożenie prototypu, zebranie feedbacku i dopiero potem rozszerzenie na kolejne obszary (HR, finanse, sprzedaż).

Chaos w plikach: nazwy, duplikaty, wersjonowanie

RAG nie rozwiąże automatycznie problemu bałaganu w plikach. Jeśli w repozytorium są dziesiątki wersji tego samego dokumentu (np. Polityka_BHP_final_v2_poprawione_ostateczne(1).pdf), to:

• embeddingi powstaną dla wszystkich wersji,
• retrieval będzie zwracał sprzeczne informacje,
• LLM może mieszać stare i nowe zasady.

Minimalny porządek przed indeksowaniem:

• wybranie źródła prawdy – jedno repozytorium, jedna „oficjalna” wersja dokumentu,
• dodanie jasnego schematu wersjonowania (w metadanych, nie tylko w nazwie pliku),

Metadane jako paliwo dla retrievalu

Techniczny porządek w danych to głównie metadane. Bez nich baza wektorowa staje się tylko drogim „full‑textem na embeddingach”. Przy każdej jednostce treści (dokumencie, sekcji, chunku) dobrze mieć:

• Identyfikator źródłowego dokumentu – np. document_id powiązany z oryginalnym plikiem lub rekordem w systemie.
• Wersję – numer lub znacznik czasu, który pozwala odsiać stare treści.
• Typ treści – polityka, procedura, FAQ, log zmian, komentarz.
• Dział / obszar – HR, IT, finanse, produkcja itd.
• Poziom poufności – klasy bezpieczeństwa spójne z polityką firmy.
• Język – przy wielojęzycznych organizacjach.
• Zakres obowiązywania – kraj, region, produkt, klient.
• Status dokumentu – roboczy, opublikowany, wycofany.

Przydaje się też prosta konwencja: nie usuwaj starych wersji, tylko oznaczaj je jako nieaktualne. Retrieval może mieć filtr status = 'published', a stary materiał wciąż da się odtworzyć na potrzeby audytu.

Proces aktualizacji i usuwania danych w indeksie

RAG jest tak dobry, jak mechanizm aktualizacji indeksu. Scenariusze do ogarnięcia:

• Nowy dokument – pojawia się w repozytorium, pipeline importuje go, parsuje, chunkuje i dodaje embeddingi.
• Aktualizacja dokumentu – trzeba:
  • usunąć lub oznaczyć stare chunki jako nieaktywne,
  • wygenerować nowe chunki i embeddingi,
  • zachować spójność wersji w metadanych.
• Usunięcie dokumentu – embeddingi nie mogą dalej „żyć” w bazie; wymagane jest twarde usunięcie lub przynajmniej flagowanie deleted=true.

Najwygodniej działa mechanizm event‑driven: system plików / DMS / wiki wysyła event typu „document_changed”, a pipeline RAG reaguje i reindeksuje tylko to, co się zmieniło. Awaryjnie można robić nocny batch, ale w dynamicznych środowiskach szybko będzie widać opóźnienia w odpowiedziach.

Ekstrakcja treści z różnych formatów

Warstwa ekstrakcji jako osobny serwis

Ekstrakcja (ingest) jest wystarczająco ważna, żeby miała własny serwis lub microserwis. Jego zadania:

• podłączenie się do źródeł (API, SMB, S3, SharePoint, SMTP),
• wyciągnięcie surowej treści,
• zamiana na uogólniony format wewnętrzny (np. JSON z polami: tekst, struktura, metadane, odnośniki),
• obsługa błędów, timeoutów, ponowień.

Tip: zdefiniuj prosty format typu NormalizedDocument, który jest wspólnym mianownikiem dla DOCX, PDF, HTML i rekordów z bazy. Reszta pipeline’u nie musi wtedy znać specyfiki źródła.

PDF, DOCX i inne „biurowe” formaty

Większość wiedzy firmowej siedzi w PDF‑ach i DOCX‑ach. Problemy:

• PDF bywa tylko obrazem (skan) – trzeba OCR.
• Struktura nagłówków często ginie – konwersja musi próbować odtworzyć hierarchię.
• Tabele i listy potrafią się rozpaść na losowe linijki tekstu.

Praktyczna konfiguracja:

• dla PDF: narzędzie typu pdftotext + OCR (Tesseract, AWS Textract, Azure Form Recognizer, Google Document AI),
• dla DOCX / PPTX: biblioteki typu python-docx, mammoth, python-pptx,
• dla treści z Google Docs / MS365: API dostawcy zamiast ściągania surowych plików.

Jeśli treści są istotne regulacyjnie (polityki, umowy), warto zachować mapowanie: chunk → numer strony / slajdu / rozdziału. To później pozwala pokazać użytkownikowi dokładny kontekst źródła.

HTML, wiki, intranety

HTML potrafi być skarbem (sensownie zrobiona dokumentacja) albo śmietnikiem (stare intranety). Kluczem jest odfiltrowanie „chromu” (nawigacja, stopka) i zostawienie treści właściwej.

Dobrą bazą są parsery typu BeautifulSoup lub gotowe narzędzia do „readability” (wyciąganie głównego artykułu z HTML). Robią:

• usunięcie menu, reklam, powtarzalnych bloków,
• rozpoznanie nagłówków H1–H3, akapitów, list,
• utrzymanie hierarchii dokumentu.

Każdej stronie HTML przypisuj stabilny source_url oraz np. page_type (FAQ, artykuł KB, news). Dzięki temu łatwo odsiać ogłoszenia sprzed lat od aktualnej dokumentacji.

Dane z baz SQL i systemów biznesowych

RAG nie musi widzieć całej bazy. W praktyce wystarczą wybrane widoki:

• „widok na człowieka” – agregacja danych z kilku tabel w jedną czytelną reprezentację,
• „widok na produkt” – parametry produktu, konfiguracje, statusy,
• „widok na zgłoszenie” – opis incydentu, rozwiązanie, kategorie.

Z takich widoków da się budować tekstowe reprezentacje typu:

Produkt: X123
Kategoria: Router
Obsługiwane protokoły: ...
Wersja firmware: ...
Ograniczenia: ...

Taki opis traktujesz jak dokument wejściowy do chunkingu i embeddingu, ale trzymasz powiązanie z kluczem głównym (np. product_id), żeby później móc kliknąć z odpowiedzi w szczegóły w systemie źródłowym.

Komunikacja: Slack, Teams, maile

Historia czatów jest kusząca, ale łatwo wpaść w pułapkę szumu i problemów prywatności. Rozsądne podejście:

• indeksować tylko wybrane kanały (np. #help-it, #faq-hr),
• odfiltrować drobne wymiany typu „dzięki”, „ok”,
• zachować pseudonimizację, jeśli regulacje tego wymagają.

Dla maili – raczej skrzynki zespołowe niż osobiste. I tylko w sytuacjach, gdzie da się obronić to prawnie i etycznie. Np. support@firma z odpowiedziami, które de facto są bazą wiedzy.

Chunking – jak dzielić dokumenty, żeby LLM miało sensowny kontekst

Dlaczego chunking jest krytyczny

Embeddingi działają na fragmentach tekstu, nie na całej dokumentacji naraz. Zbyt duże chunki:

• rozmywają temat (wektor jest „średnią” z kilku tematów),
• łatwo wylecą poza limit tokenów promptu.

Zbyt małe chunki:

• tracą kontekst (sam nagłówek bez treści niewiele znaczy),
• retrieval zwraca strzępy, które LLM musi sklejać na siłę.

Optimum zależy od domeny, ale zwykle waha się między 300 a 1000 tokenów na chunk, z pewnym nakładaniem się.

Chunking oparty na strukturze dokumentu

Najlepiej startować od struktury logicznej, a nie od „sztywnego” licznika znaków. Przykład:

• jeden chunk = nagłówek + kilka kolejnych akapitów,
• osobne chunki dla sekcji, podsekcji, punktów procedury.

Przy parsowaniu dokumentu możesz tworzyć drzewo:

• poziom 1: rozdziały (H1),
• poziom 2: sekcje (H2),
• poziom 3: podsekcje (H3),
• liście: akapity, punkty list.

Chunking polega wtedy na zjeżdżaniu po drzewie i składaniu akapitów w paczki o rozsądnym rozmiarze, z zachowaniem informacji o ścieżce w drzewie (np. chapter=„Bezpieczeństwo”, section=„Hasła”).

Fixed‑size vs sliding window

Dwa popularne podejścia:

• Fixed‑size – tniesz tekst na bloki po X tokenów / zdań. Prosto, ale ignoruje granice semantyczne.
• Sliding window – tworzysz okna z nakładaniem się (overlap), np. 500 tokenów z overlapem 100–150 tokenów.

W praktyce często łączy się oba:

• najpierw chunking po strukturze (sekcje),
• jeśli sekcja jest za duża, stosujesz sliding window w jej obrębie.

Overlap ma sens, bo pytanie użytkownika może zahaczać o przejście między dwoma sekcjami. Dublowanie fragmentu minimalizuje ryzyko przecięcia kluczowej informacji na pół.

Chunking dla FAQ, ticketów i krótkich wpisów

Nie wszystko trzeba chunkować. Dla:

• FAQ,
• pojedynczych ticketów,
• krótkich artykułów KB,

najlepszy chunk to cały wpis. Zamiast dzielić, lepiej:

• spiąć pytanie + odpowiedź w jeden dokument,
• dodać metadane typu faq=true, category=„VPN”.

Przy wyszukiwaniu możesz najpierw odpalić osobny retriever na FAQ (wysoka precyzja), a dopiero później ogólny retriever na „ciężkich” dokumentach.

Metadane na poziomie chunków

Metadany nie kończą się na dokumencie. Część przydaje się na poziomie chunku:

• section_title – tytuł sekcji,
• section_path – np. „Polityka bezpieczeństwa > Hasła > Rotacja haseł”,
• page_number / slide_number,
• valid_from, valid_to – jeśli dana sekcja obowiązuje tylko przez pewien czas.

Da się wtedy zadać bazie wektorowej pytanie typu: „daj mi tylko chunki z sekcji ‘Bezpieczeństwo haseł’ z ostatniego roku” – bez konieczności przeszukiwania całych dokumentów.

Embeddingi i baza wektorowa – wybór, parametry, praktyka

Wybór modelu embeddingowego

Kluczowe parametry modelu embeddingowego:

• wymiar wektora (np. 384, 768, 1024),
• języki, które wspiera,
• optymalizacja pod similarity search vs klasyfikację / clustering,
• model chmurowy vs on‑prem / open‑source.

Praktyczne strategie:

• dla środowisk wielojęzycznych – modele wielojęzyczne (np. rodzina multilingual-e5, LaBSE),
• tam, gdzie liczy się prywatność – modele hostowane lokalnie (SentenceTransformers, Instructor, Jina, itp.),
• dla szybkich POC – hosted embeddings (OpenAI, Azure, Cohere) bez dbania o infrastrukturę.

Tip: nie mieszaj modeli embeddingowych w jednym indeksie. Każda zmiana modelu to de facto reindeks całej bazy.

Parametry wektorów i normalizacja

Dwie rzeczy, na które łatwo machnąć ręką:

• normalizacja wektora – w wielu scenariuszach warto normalizować do długości 1 (L2 norm = 1). Ułatwia to użycie kosinusowej miary podobieństwa i porównań między różnymi batchami.
• pre‑ i post‑processing tekstu – consistent lowercasing, usuwanie kontrolnych znaków, ujednolicenie formatu dat/liczb.

Jeżeli baza wektorowa obsługuje różne metryki, zwykle sensownie sprawdza się cosine similarity lub dot product (dla znormalizowanych wektorów). L2 distance gorzej oddaje podobieństwo semantyczne przy embeddingach z NLP.

Wybór bazy wektorowej

RAG w firmie nie wymaga koniecznie wyspecjalizowanej bazy wektorowej – ale w praktyce ułatwia ona życie. Popularne opcje:

• Qdrant, Weaviate, Milvus – open‑source, obsługują gęste wektory, filtry po metadanych, sharding, replikację.
• Pinecone, Vertex Matching Engine, Azure AI Search – managed, skalowanie i HA po stronie dostawcy.
• Postgres + pgvector – dobre dla mniejszych projektów lub gdy chcesz minimalizować stos technologiczny.

Indeksowanie, aktualizacje i wersjonowanie

Embeddingi i wektory to nie jest jednorazowy zrzut danych. W praktyce pojawia się kilka codziennych problemów: jak często reindeksować, co z wersjami dokumentów, jak usuwać dane z RAG (np. przy „prawie do bycia zapomnianym”).

Podstawowe strategie indeksowania:

• batch – okresowe pełne lub przyrostowe indeksacje (np. raz dziennie w nocy),
• near‑real‑time – event‑driven, po zmianie dokumentu w DMS/CRM od razu leci job aktualizujący embeddings,
• hybryda – krytyczne systemy (np. baza wiedzy dla supportu) w trybie near‑real‑time, reszta w batchu.

Żeby nie zwariować przy aktualizacjach, przydaje się prosty model wersjonowania:

• każdy chunk ma document_id, chunk_id, version,
• przy edycji dokumentu tworzysz nową wersję, stare chunki oznaczasz is_active=false lub trzymasz w osobnym indeksie archiwalnym,
• w query zawsze filtrujesz po is_active=true albo po version=current.

Jeśli regulacje wymuszają fizyczne usunięcie danych, samo oznaczenie is_active=false nie wystarczy. Trzeba mieć:

• mechanizm „hard delete” w bazie wektorowej po kluczu (np. kombinacji document_id + user_id),
• log, który pozwoli udowodnić, że dane zostały faktycznie usunięte (audit trail).

Tip: część zespołów trzyma osobne indeksy per domena (np. hr_index, security_index, marketing_index). Ułatwia to zarządzanie cyklem życia danych i różne okresy retencji.

Filtry po metadanych i segmentacja indeksów

Sama baza wektorowa nie wystarczy, jeśli retrieval ma ignorować dokumenty spoza kontekstu użytkownika czy procesu. Do gry wchodzą filtry po metadanych (tzw. filtered vector search).

Typowe metadane do filtrowania:

• locale / language – unikasz mieszania PL/EN, gdy użytkownik chce odpowiedź po polsku,
• department, region, customer_segment – pozwalają przyciąć dokumenty do właściwej części organizacji,
• confidentiality_level – np. public / internal / restricted,
• valid_from, valid_to – ograniczenie do aktualnych procedur.

Segmentacja indeksów (kilka indeksów wektorowych zamiast jednego) sprawdza się, gdy:

• wymagania prawne różnią się między domenami (np. HR vs marketing),
• chcesz łatwo odpalać różne parametry HNSW/IVF (inne dla krótkich FAQ, inne dla ciężkiej dokumentacji technicznej),
• masz zupełnie różne języki lub rodzaje treści (np. kod źródłowy vs umowy prawne).

Uwaga: nadmierna fragmentacja indeksów zwiększa złożoność pipeline’u – każdy indeks to osobny deployment, monitoring, backupy. Lepiej mieć 3–4 sensownie zdefiniowane indeksy niż 20 mikro‑indeksów, których nikt nie ogarnia.

Parametry ANN i kompromisy dokładność <> wydajność

Większość nowoczesnych baz wektorowych korzysta z przybliżonego wyszukiwania najbliższych sąsiadów (ANN). W praktyce i tak trzeba podjąć kilka decyzji:

• jak duży ma być indeks (liczba wektorów, np. parametry ef_construction, M w HNSW),
• jak agresywnie szukać (np. ef_search / nprobe),
• ile kandydatów zwracać (np. top_k=20 lub więcej).

Prosty workflow strojenia:

1. tworzysz mały eval set (zestaw pytań + oczekiwane dokumenty/chunki),
2. odpalasz retrieval z różnymi parametrami ANN,
3. mierzysz recall@k (czy w top‑k jest jakiś chunk z poprawną odpowiedzią) oraz latency.

Jeżeli system będzie korzystany interaktywnie (chat dla pracowników), latency powyżej kilkuset milisekund za sam wektorowy search zaczyna być odczuwalne. W takich sytuacjach:

• redukujesz wymiar wektorów (niższy wymiar = szybsze indeksowanie i zapytania),
• filtrujesz po metadanych przed search’em, żeby przeszukiwać mniej kandydatów,
• trzymasz hot‑index (ostatnie/ulubione dokumenty) w szybszej konfiguracji, a resztę w wolniejszej.

Od pytania użytkownika do odpowiedzi – pipeline zapytań w RAG

Warstwa wejścia – co naprawdę dostaje system

Użytkownik nie wysyła „czystego” zapytania NLP. Zazwyczaj jest kontekst:

• historia czatu (kilka ostatnich wiadomości),
• tożsamość i uprawnienia użytkownika,
• kanał (Slack, portal, plugin w CRM),
• tryb pracy (chat vs pytanie ad‑hoc w polu wyszukiwarki).

Warstwa wejścia powinna:

• wyciągnąć „rdzeń” pytania (np. ostatnią wiadomość użytkownika + ewentualny skr