Case: personalizacja B2B z RAG — wyniki po 6 miesiącach

RAG personalizacja B2B – w tym studium przypadku opisujemy wdrożenie Retrieval-Augmented Generation dla polskiego SaaS z branży legaltech, które po sześciu miesiącach podniosło współczynnik konwersji MQL->SQL z 18% do 34%, skróciło cykl sprzedaży z 78 do 54 dni i wygenerowało 1,7 mln zł nowego ARR przypisywalnego do samej zmiany. Dane zebrane z platformy klienta, analityki i CRM za okres Q2-Q3 2025, anonimizowane w zakresie danych klientów końcowych.

Case pokazuje praktyczne aspekty, których nie ma w marketingowych materiałach dostawców RAG – realną architekturę (nie „z broszury”), koszty w polskich złotych, problemy z jakością embeddingów dla języka polskiego, integrację z HubSpot CRM i największą zaskakującą obserwację: najwięcej wartości nie przyniosło lepsze generowanie odpowiedzi, tylko lepszy retrieval, który skierował handlowca do właściwego kontekstu o kliencie przed rozmową.

Firma, o której piszemy (zgodnie z umową NDA nazywa się dalej „LegaLink”) zatrudnia 74 osoby, obsługuje 420 kancelarii prawnych w Polsce i Czechach, ma roczny przychód 27 mln zł i model SaaS z subskrypcjami 380-2400 zł/kancelaria/mc. Ten case zawiera wszystkie techniczne i biznesowe decyzje podjęte w trakcie projektu – od wyboru modelu embedującego po moment, w którym zatrzymaliśmy rozwój i skonsolidowali system.

Kontekst biznesowy – co próbowaliśmy rozwiązać

LegaLink w Q1 2025 miał pipeline 640 aktywnych leadów miesięcznie, ale tylko 18% konwertowało z MQL na SQL. Główne problemy: (1) handlowcy w pierwszym contacie nie znali specyfiki kancelarii, do której dzwonili, (2) marketing content był generyczny – nie odpowiadał na zróżnicowane potrzeby 12 segmentów klientów, (3) customer success nie wiedział, które feature’y są kluczowe dla utrzymania konkretnego klienta.

Poprzednie wdrożenie: Marketo + HubSpot + ręczne research handlowców w Google + LinkedIn. Czas przygotowania do jednego callu: 35-50 minut per handlowiec. Jakość researchu zmienna – zależała od doświadczenia handlowca. Koszt pełnego researchu na lead: około 140 zł czasu handlowca.

Cele biznesowe projektu

1. Podniesienie MQL->SQL conversion o minimum 10 punktów procentowych w 6 miesięcy
2. Skrócenie średniego cyklu sprzedaży o 15%+
3. Automatyczne brief’owanie handlowca w ramach 5 minut vs 35-50 min ręcznie
4. Zmiana personalizacji email marketingu z 6 segmentów na dynamiczną (per-lead)
5. Payback period inwestycji < 12 miesięcy

Dlaczego RAG, a nie fine-tuning albo prompt-only

Rozważaliśmy trzy podejścia:

• Prompt engineering z Claude Sonnet bez RAG – najtańsze, ale context window 200k tokenów nie pomieści pełnej bazy wiedzy o 420 klientach (każdy z setkami ticketów, maili, dokumentów).
• Fine-tuning dedykowanego modelu – najdroższe (szacunkowo 800 000 zł + stały koszt GPU), ryzyko halucynacji, trudny proces aktualizacji wiedzy.
• RAG – średnia złożoność, najlepsza elastyczność, możliwość szybkiej aktualizacji bazy wiedzy bez przetrenowywania modelu, audytowalność (wiadomo, z jakiego dokumentu pochodzi odpowiedź).

Dla firmy, której baza wiedzy zmienia się tygodniowo (nowe ticket’y, nowe dokumenty, nowe wersje feature’ów), RAG okazał się jedyną sensowną opcją. Wprowadzenie kolejnego dokumentu do systemu trwa 15 minut, a nie 2-3 dni retreningu.

Architektura, która działa w produkcji

Architektura przeszła trzy iteracje w 6 miesięcy. Opisujemy wersję finalną, która działa stabilnie od listopada 2025.

Warstwy systemu

1. Ingestion – kolektory danych z HubSpot CRM, Zendesk (ticketing), Google Drive (dokumentacja), własnej bazy PostgreSQL (dane produktowe) oraz Slack (wewnętrzne notatki zespołu).
2. Processing – chunking (semantyczne dzielenie dokumentów po 400-800 tokenów z 15% overlapem), metadata extraction (segment klienta, typ dokumentu, data, autor), embedding generation.
3. Storage – Qdrant jako baza wektorowa (self-hosted na AWS, 3 nody, 64 GB RAM każdy), PostgreSQL dla metadanych i relacji, Redis dla cache’u odpowiedzi.
4. Retrieval – hybrid search (BM25 + semantic), re-ranker Cohere dla top-50 wyników, filtrowanie po metadanych (klient, data, typ).
5. Generation – Claude Sonnet 3.5 (główny), fallback do Claude Haiku dla prostych zapytań, system prompt 2400 tokenów z instrukcjami eksperckimi.
6. Interface – Slack bot dla handlowców, ekstensja Chrome dla CRM, dashboard w Retool dla managera.

Diagram flow

Handlowiec w HubSpot otwiera kartę leada. Ekstensja Chrome wykrywa kontekst (ID klienta, segment) i wysyła zapytanie do backend’u RAG. Backend wykonuje: (1) BM25 search na firmowych atrybutach klienta, (2) semantic search na dokumentach powiązanych z klientem, (3) merge i re-rank wyników, (4) generuje strukturyzowany brief (4-5 sekcji). Całość: 7-12 sekund od otwarcia karty.

Kluczowe decyzje techniczne

Decyzja	Wariant A	Wariant B	Wybór
Baza wektorowa	Pinecone (managed)	Qdrant (self-hosted)	Qdrant – 10x tańszy przy docelowej skali, pełna kontrola
Embedding model	text-embedding-3-large	Dedykowany polski (multilingual-e5)	Hybryda – 3-large dla ogólnych dokumentów, e5 dla tekstów prawnych
Chunking strategy	Fixed 512 tokens	Semantic chunking	Semantic – 23% lepszy recall w testach
LLM generacji	GPT-4o	Claude Sonnet 3.5	Claude – lepszy polski, lepsza instrukcyjność, tańsze przy input-heavy
Re-ranker	Bez re-rankera	Cohere rerank-v3	Cohere – precision@5 wzrósł z 62% do 81%

Więcej kontekstu na temat wyboru modeli pod marketing czytajcie w workflow content AI: od briefu do publikacji w 7 krokach.

Skąd wzięły się dane – źródła wiedzy

Jakość RAG zależy od danych 10x bardziej niż od modelu. Poświęciliśmy 40% czasu projektu na samo zbudowanie pipeline’u danych.

Dokumentacja produktowa (35% volume)

418 stron help center’u, 280 artykułów znajdujących się na stronie, 124 webinary nagrane w 2023-2025 (transkrypcje Whisper). To baza „wiedzy podręcznikowej” – jak działa feature X, jakie są use case’y, jak skonfigurować Y.

Ticketing Zendesk (40% volume)

Największe zaskoczenie projektu. Anonimizowane 38 000 zamkniętych ticketów z 3 lat były najbogatszym źródłem kontekstu „jak rozmawiać z klientem”. Pokazywały realne problemy, które klienci zgłaszają, konkretne rozwiązania, żargon używany w różnych segmentach. Handlowiec, który dostaje brief „klient X miał w zeszłym roku 4 ticket’y dotyczące modułu Y, z tego 3 o integracji z systemem Z”, startuje rozmowę 10 minut dalej niż handlowiec z genericznym researchem.

HubSpot CRM (15% volume)

Historia kontaktów, notatki handlowców, emaile wysłane i odebrane, status deal’a, ostatnie interakcje. To „jak dotąd z tą firmą było”.

Dane finansowe i produktowe (8% volume)

Usage analytics (które feature’y klient używa), billing history (plany, upgrade’y, downgrade’y), engagement metrics (frequency of login, active users). Integracja z własnym Postgresem.

Notatki wewnętrzne (2% volume)

Slack kanał #customer-insights – zespół wrzuca tam obserwacje po callach, podsłuchane żargonu, ciekawe referencje. Mało volume, ale bardzo wartościowe pod angle „jak aktualna sytuacja klienta wygląda z perspektywy zespołu”.

Problem polskich embeddingów – jak rozwiązaliśmy

Największa techniczna niespodzianka projektu. text-embedding-3-large OpenAI działa „wystarczająco dobrze” na ogólnym tekście polskim, ale dla dokumentów prawnych ma problem z dokładnym rozróżnianiem podobnie brzmiących terminów prawnych (np. „zażalenie” vs „apelacja” vs „odwołanie” – semantycznie różne, lexikalnie podobne).

Objawy

W pierwszych 8 tygodniach RAG zwracał dokumenty „blisko” tematu, ale niekiedy mylił terminy. Handlowiec dostawał brief „klient X ma problem z apelacjami”, podczas gdy w rzeczywistości chodziło o zażalenia (inny tryb proceduralny). Precision@5: 62%. Dla systemu, który ma karmić handlowca „gotowym” contextem, 62% precision to za mało.

Rozwiązanie

Hybrydowy system embeddingów:

1. Detektor typu dokumentu (klasyfikator na podstawie pierwszych 300 tokenów): prawny / biznesowy / techniczny / operacyjny.
2. Dla prawniczych – multilingual-e5-large fine-tuned na 12 000 parach (query, relevant document) z polskiego prawa cywilnego.
3. Dla pozostałych – text-embedding-3-large.
4. Reranker Cohere jako warstwa konsolidująca oba zestawy.

Fine-tuning multilingual-e5 trwał 3 dni na infrastrukturze AWS G5 (8x A10G), kosztował 2800 USD. Precision@5 po wdrożeniu: 81%. Recall@20 dla długich, złożonych zapytań: +34% vs poprzedni system.

Alternatywa, której nie użyliśmy

Rozważaliśmy trening własnego modelu embedującego od zera. Budżet 120 000-180 000 zł, 4-6 tygodni. Nie przekonała nas relacja zysku do ryzyka – fine-tuning istniejącego modelu dał 80% zysku za 3% kosztu. Trening od zera ma sens, jeśli rozważacie horyzont 2-3+ lat i model ma pokryć więcej niż jeden kontekst domenowy.

Proces wdrożenia – 6 miesięcy w szczegółach

Miesiąc 1: Odkrycie i proof of concept

Warsztaty z zespołem sales i customer success (3 sesje po 4 h). Cel – zrozumieć, jakich pytań zadają, czego im brakuje przy researchu klienta. Wyciągnięte insights: (1) największy ból to „kontekst techniczny” – czy klient używa modułu X, (2) drugi ból – „historia ostatnich 90 dni”, (3) trzeci ból – „jakie obiekcje najczęściej zgłaszają firmy tej wielkości”.

Proof of concept: Pinecone (managed, szybki setup), text-embedding-3-large, Claude Sonnet, 3 źródła danych (help center, ticketing, CRM). Zadziałało, ale ujawniło problem z polskimi embeddingami i koszt Pinecone na docelowej skali.

Miesiąc 2: Architektura finalna i pipeline danych

Migracja z Pinecone na self-hosted Qdrant. Build pipeline’u danych – automatyczne pobieranie z Zendesk API co godzinę, z HubSpot co 30 minut, z Google Drive raz dziennie. Chunking semantyczny – wdrożenie biblioteki llama-index z customowymi regułami dla dokumentów prawnych.

Build reranker’a Cohere. Pierwszy test A/B na 200 realnych zapytaniach: precision@5 = 68% bez reranker’a, 79% z reranker’em.

Miesiąc 3: Fine-tuning i testy jakości

Fine-tuning multilingual-e5 na polskich tekstach prawnych. Budowa test set’u 500 par (query, expected_docs) zweryfikowana przez dwóch prawników i dwóch handlowców seniorów. Iteracyjne testy – 5 wersji fine-tunu, ostatnia wybrana na podstawie metryk NDCG@10 i MRR@5.

Równolegle – budowa warstwy generacji. System prompt 2400 tokenów, 12 few-shot examples, zasady handling niepewności („jeśli dane sprzeczne, podaj oba źródła”). Pierwsza wersja interfejsu Slack bot i ekstensja Chrome.

Miesiąc 4: Pilotaż z 12 handlowcami

Pilotaż w zamkniętej grupie 12 handlowców (6 top performers, 6 mid). Cel – zebrać feedback UX, wyłapać edge case’y, zmierzyć wpływ na KPI. Zmiany na podstawie feedbacku:

• Dodanie sekcji „czerwone flagi” w briefie (np. „klient zgłaszał 3x problem billing w ciągu miesiąca”)
• Czas generacji z 18 s do 9 s (cache’owanie, parallel retrieval)
• Strukturalny format briefu zamiast długiego tekstu (handlowcy skanowali, nie czytali)
• Dodanie „confidence score” przy każdej sekcji – handlowiec widzi, co system wie na pewno, a co jest inference’m

Wyniki pilotażu: średnia MQL->SQL w grupie pilotażowej wzrosła z 19% do 28% w 4 tygodnie. Handlowcy raportowali średnio 22 min skrócenia czasu przygotowania do calla.

Miesiąc 5: Roll-out na cały zespół

Wdrożenie dla wszystkich 34 handlowców + 12 osób customer success. Szkolenie 3-godzinne, dokumentacja wewnętrzna, Slack kanał #rag-support dla pytań. Pierwsze dwa tygodnie: mentoring – doświadczeni z pilotażu uczyli reszty „jak używać dobrze”.

Miesiąc 6: Optymalizacja i skalowanie

Analiza użycia – które rodzaje zapytań są najczęstsze, które mają najniższą satysfakcję. Dodanie 4 nowych use case’ów: (1) auto-generowanie spersonalizowanych maili follow-up, (2) content recommendations dla marketingu (który artykuł posłać temu segmentowi), (3) alerting „klient w grupie ryzyka” dla customer success, (4) competitive intelligence – wyciąganie z ticketów informacji o tym, od których konkurentów klienci przychodzą.

Wyniki po 6 miesiącach – pełne dane

Metryki biznesowe

Metryka	Przed (Q1 2025)	Po (Q3 2025)	Zmiana
MQL->SQL conversion rate	18%	34%	+16 p.p.
SQL->klient conversion	31%	38%	+7 p.p.
Średni cykl sprzedaży	78 dni	54 dni	-31%
Średnia wartość kontraktu	14 200 zł/rok	16 800 zł/rok	+18%
Churn rate (6M)	8,4%	5,9%	-2,5 p.p.
NPS zespołu sales	34	62	+28 pkt

Metryki operacyjne

• Czas przygotowania do calla: 35-50 min -> 8-12 min (-75%)
• Liczba callów na handlowca/tydzień: 8,5 -> 13,2 (+55%)
• Jakość notatek post-call (ocena przez managera): 6,4/10 -> 8,3/10
• Odpowiedź na email handlowca (rate): 11% -> 19%

Metryki techniczne

• Precision@5 retrieval: 81%
• Recall@20: 91%
• Średni czas response: 9,2 s
• System uptime: 99,7% (21 godzin downtime w 6 miesiącach, większość podczas migracji)
• Koszt LLM API miesięcznie: 14 400 zł
• Koszt infrastruktury AWS: 3 200 zł/mc
• Koszt Cohere reranker: 1 800 zł/mc

Pełna kalkulacja kosztów i ROI

Jednorazowe (wdrożenie)

Pozycja	Koszt
Zespół projektu (2 engineers, 1 data scientist, 1 PM) 5 mies.	178 000 zł
Fine-tuning multilingual-e5 (infra + czas)	12 000 zł
Konsultacje prawne (anonimizacja danych klientów)	18 000 zł
Licencje narzędzi (Cohere, tools, monitoring)	11 000 zł
Testowanie z zespołem sales (pilotaż, mentoring)	24 000 zł
Szkolenia i dokumentacja	14 000 zł
Rezerwa na zmiany (wykorzystana w 80%)	30 000 zł
Razem	287 000 zł

Stałe miesięczne

• Claude Sonnet API: 11 200 zł (około 180 mln input + 45 mln output tokenów/mc)
• OpenAI embeddings: 3 200 zł
• AWS (compute + storage + network): 3 200 zł
• Cohere rerank: 1 800 zł
• Monitoring (Langfuse, Sentry): 0 (open-source self-hosted)
• Zespół operacyjny (0,5 FTE ML engineer + 0,25 FTE DevOps): realna alokacja zespołu, wyceniona: około 34 000 zł/mc pełnych kosztów
• Razem stałe (bez zespołu operacyjnego): 19 400 zł/mc
• Razem z zespołem: 53 400 zł/mc

ROI i payback

Przyrost przychodu przypisywalny (atrybucja przez porównanie z grupą kontrolną 3 handlowców, którzy wprowadzili system o 2 miesiące później):

• +1,7 mln zł ARR w 6 miesiącach
• +240 000 zł z nowych sprzedaży (wyższe deal size)
• +410 000 zł z mniejszego churnu (wyższy LTV)
• Razem roczny zysk: około 3,5 mln zł ARR (ekstrapolacja na 12 miesięcy pełnej operacji)

Payback period: 287 000 zł / (3 500 000 zł rocznie / 12 mies.) = 4,7 miesiąca. Realna zwrot z uwzględnieniem stałych kosztów operacyjnych: 6,2 miesiąca. Po pierwszym roku – ROI około 580%.

Siedem pułapek, które omal nie wykoleiło projektu

1. Zbyt ambitny scope na start. Pierwsza wersja miała 14 use case’ów. Zredukowaliśmy do 3 w miesiącu 2. Bez tego nie byłoby MVP w miesiącu 4.
2. Ignorowanie UX handlowca. Pierwsza wersja interfejsu była wall of text. Handlowcy nie używali. Dopiero strukturalny, skanowalny format zaczął generować adopcję.
3. Brak grupy kontrolnej. Chcieliśmy dać system wszystkim od razu. Ostatecznie 3 handlowców dostało 2 miesiące później – bez tego nie zmierzylibyśmy realnego wpływu.
4. Niedoszacowanie kosztu anonimizacji danych. RODO + sensytywne dane prawne wymagały 18 000 zł konsultacji i 3 tygodni pracy.
5. Problem z polskimi embeddingami. Nie przetestowaliśmy jakości retrieval dla języka polskiego przed wyborem stack’u. Zajęło 4 tygodnie fine-tuningu, których nie było w planie.
6. Hallucinations pomimo RAG. Pierwsza wersja generatora czasami „zgadywała” fakty. Wdrożenie konfidence score i wymóg cytowania źródła zmniejszyło halucynacje z 8% do 0,7%.
7. Opór zespołu sales. 20% handlowców na początku bało się, że AI ich zastąpi. Kluczem była komunikacja „AI ma ci dać 30 min dziennie wolnego czasu, a ty te 30 min przeznacz na więcej callów” – nie na redukcję etatów.

Pięć kluczowych lekcji dla innych firm B2B

Lekcja 1: Zacznij od problemu, nie od technologii

Największy błąd wdrożeń RAG – zaczynanie od „mamy budżet na AI, co z tym zrobić?”. Właściwe pytanie: „który konkretny moment w cyklu sprzedaży / obsługi klienta jest najbardziej bolesny i mierzalny?”. Dla nas to był pre-call research. Dla innej firmy może być onboarding nowego klienta albo renewals.

Lekcja 2: Tickets > dokumentacja

Zaskakujące, że najcenniejsze dane były w ticket systemie, a nie w oficjalnej dokumentacji. Ticket’y pokazują realne problemy, żargon klientów, niuanse. Dokumentacja jest „wersją aspiracyjną”. Jeśli wdrażacie RAG w B2B, sprawdźcie w pierwszej kolejności support ticketsy.

Lekcja 3: Fine-tune tam, gdzie jest warto

Dla języka polskiego w domenach specjalistycznych fine-tuning embeddingu daje większy zysk niż lepszy LLM. Jeśli macie wybór „Claude Opus z off-the-shelf embeddings” vs „Claude Sonnet z fine-tuned polish embeddings”, drugi układ jest lepszy przy niższym koszcie.

Lekcja 4: Reranker jest niedoceniany

Cohere rerank kosztuje mało (1 800 zł/mc w naszym przypadku) i daje ogromny skok precyzji (+13 punktów procentowych precision@5). Bez rerankera rag działa, ale z rerakerem działa „dobrze”.

Lekcja 5: Confidence score zmienia użyteczność

System, który mówi „jestem pewien na 92%” vs „jestem pewien na 34%” jest 3x bardziej użyteczny niż ten, który zawsze prezentuje jedną odpowiedź. Handlowcy przestają ufać systemowi, jeśli 1 na 5 odpowiedzi jest ewidentnie zła. Z confidence score wiedzą, kiedy trzeba zweryfikować, a kiedy można jechać „na ślepo”.

Jak to działa na innych typach firm

Czy ten case jest powielalny? Tak, ale z modyfikacjami pod wielkość firmy.

SME (przychód 2-15 mln zł, 10-40 pracowników)

Pełna architektura jak u LegaLink jest za ciężka. Prosta alternatywa: managed baza wektorowa (Pinecone Serverless, 80-280 zł/mc), prompt z off-the-shelf embeddings, jeden use case (pre-call research), Slack bot. Budżet wdrożenia 30 000-70 000 zł, stałe 2 000-4 000 zł/mc.

Średnia firma (przychód 30-100 mln)

Architektura pośrednia. Self-hosted Qdrant lub Weaviate, fine-tuning embedding tylko jeśli macie specjalistyczne dane, 3-4 use case’y. Budżet 120 000-220 000 zł, stałe 8 000-14 000 zł/mc. Payback 5-9 miesięcy przy realnej wartości biznesowej.

Enterprise (100+ mln)

Potrzeba własnej platformy AI, dedicated team (3-5 osób), wiele use case’ów, integracje z istniejącymi systemami enterprise. Budżet 500 000-2 000 000 zł wdrożenia, stałe 30 000-120 000 zł/mc. Payback 8-14 miesięcy.

Kiedy NIE warto robić RAG

• Baza wiedzy mieści się w context window LLM (do 50 stron tekstu). Prompt engineering wystarczy.
• Dane są statyczne i nie zmieniają się miesiącami. Fine-tuning dedykowanego modelu może być lepszy.
• Nie macie mierzalnego problemu biznesowego. AI bez jasnego KPI = wydatek bez zwrotu.
• Zespół nie jest gotowy do adopcji. Bez użycia system się nie zwróci.

Porównanie z innymi case’ami w firmie

W LegaLink przed RAG personalizacji wdrożyliśmy dwa inne AI project’y. Porównanie pokazuje, gdzie RAG błyszczy w porównaniu do prostszych podejść.

Projekt	Typ AI	Budżet	Payback	Wpływ KPI
Produkcja treści SEO	Prompt + templates	42 000 zł	3,1 mies.	+240% wolumen, +68% organic traffic
Audyt automatyczny SEO klientów	Claude + analiza danych	78 000 zł	4,4 mies.	+180% liczba audytów, -62% czas handlowca
RAG personalizacja B2B (case)	RAG + reranker	287 000 zł	4,7 mies.	+16 p.p. MQL->SQL, +1,7 mln ARR

Wnioski: RAG jest droższy, ale wpływ na core business (sales) jest znacznie wyższy niż prostsze projekty. Warto zacząć od prostych (prompt engineering, content automation), żeby zbudować kompetencje zespołu, a RAG wdrażać, gdy mamy jasny case z wysokim ROI.

Bardziej szczegółowy breakdown innych projektów – case: produkcja 50 artykułów z 3 miesięcy do 2 tygodni dzięki AI oraz case: automatyzacja audytów SEO z Claude Opus.

Integracje z istniejącym stackiem marketingowym

RAG nie działa w izolacji – w LegaLink jest wpięty w pięć systemów produkcyjnych. Poniżej jak to zrobiliśmy.

HubSpot CRM

Dwukierunkowa integracja. Z HubSpot pobieramy dane leadów, deali, notatek, emaili co 30 minut. Do HubSpot wysyłamy briefy wygenerowane przez RAG jako custom properties na karcie kontaktu oraz automatyczne aktywności („RAG brief wygenerowany X godzin temu”). Handlowiec nigdy nie musi opuszczać HubSpota – wszystko widzi w natywnym UI plus ekstensja Chrome z dodatkowymi szczegółami.

Techniczne wyzwanie: HubSpot API ma rate limit 100 req/10 s dla ogólnych endpointów i 10 req/s dla batch. Przy 420 klientach i 30 000 kontaktach w bazie, potrzebna była kolejka zadań (BullMQ) z inteligentnym throttlingiem i priorytetyzacją – „aktywne dealy” odświeżamy co 30 min, „cold leads” raz dziennie.

Zendesk (ticketing)

Jednokierunkowa – tylko pobieramy ticket’y. Webhook na zamknięcie ticketu + scheduler’u co godzinę dla zmian statusu. PII anonimizowane na poziomie ingestion – nazwiska, telefony, maile osób fizycznych zamieniane na tokeny placeholder, firmowe dane zachowywane. Pełna historia 3 lat zaimportowana podczas wdrożenia (1,2 GB tekstu, 38 000 ticketów).

Slack

Bot odpowiadający na pytania typu „co wiesz o kancelarii X?”. Autentykacja przez workspace SSO, uprawnienia zgodne z rolą użytkownika (handlowiec widzi swoje konta, manager wszystkie). Bot zapamiętuje kontekst sesji przez 30 minut – można prowadzić follow-up dialog bez powtarzania parametrów.

Gmail / Outlook

Ekstensja Chrome, która wykrywa adres email odbiorcy w composer’ze i pokazuje sidebar z briefem RAG. Przydatne przy pisaniu personalizowanych emaili – handlowiec widzi od razu „klient zgłaszał problem X, używa modułu Y, historycznie interesował się Z”.

Google Drive

Monitorowany folder „Sales playbooks”, „Product docs”, „Win/loss stories”. Każdy nowy dokument automatycznie przechodzi przez pipeline ingestion w ciągu godziny. Udostępnianie w Drive zarządza uprawnieniami – RAG respektuje ACL z Drive (dokument tylko dla managerów = bot nie cytuje go handlowcowi).

Monitoring i obserwowalność RAG w produkcji

System bez monitoringu degraduje się w miesiącach. Trzy warstwy, które wdrożyliśmy.

Metryki jakości retrieval

Co tydzień zespół weryfikuje 50 losowych zapytań – sprawdza precision@5 i relevance najwyższego wyniku. Jeśli precision spadnie poniżej 75% (nasz alarm), uruchamiamy root cause analysis. Najczęstsze powody degradacji: (1) nowe segmenty klientów, które nie są reprezentowane w test set’ie, (2) zmiany w strukturze ticketów (Zendesk re-design tabel), (3) nowy typ dokumentu bez odpowiedniego chunkingu.

Metryki jakości generacji

Langfuse (self-hosted) traceuje każdy call do LLM: input tokenów, output, koszt, latencja. 5% sesji losowo jest oznaczanych do manualnej weryfikacji przez zespół jakości – zgodność z danymi, braki halucynacji, wartość dla handlowca. Wynik z ostatnich 3 miesięcy: 94% odpowiedzi ocenionych jako „użyteczne” lub „bardzo użyteczne”, 0,7% zawierało halucynację (system wygenerował fakt niepoparty źródłem).

Metryki użycia

Dashboard w Retool pokazujący: DAU handlowców używających RAG, liczbę generowanych briefów dziennie, korelację użycia z konwersjami, top queries, najmniej użyteczne queries (feedback „nie pomogło”). Managerzy zespołów sprawdzają to co tydzień i interweniują, gdy ktoś nie używa – zwykle to nie jest opór, tylko zapomniany skrót albo niejasny workflow.

Roadmap na następne 12 miesięcy

Co dalej dla LegaLink:

1. Q4 2025: multi-turn agent – handlowiec może zadawać follow-up pytania („a co z modułem X w tej kancelarii?”), system pamięta kontekst sesji
2. Q1 2026: proactive alerts – system sam wykrywa klientów w grupie ryzyka churnu i wysyła alerty do customer success
3. Q2 2026: integration z voice – on-call assistant, który słucha rozmowy sales i podrzuca relevant facts w czasie rzeczywistym (zgodnie z RODO, za zgodą klienta końcowego)
4. Q3 2026: ekspansja do Czech – dodanie embeddingów czeskich, replikacja pipeline’u, oczekiwany budżet 110 000 zł

Każda iteracja powinna mieć mierzalny KPI i własny pilot w małej grupie przed roll-outem. Utrzymujemy filozofię „small, measurable, iterative” – to ta sama, która sprawiła, że pierwsze wdrożenie nie eksplodowało.

FAQ – najczęstsze pytania od firm zainteresowanych RAG

Jakie wymagania techniczne ma RAG dla SME?

Dla SME wystarczy: (1) dostęp do danych (API CRM, help center, ticket system), (2) osoba z podstawową znajomością Pythona lub gotowość do zapłaty agencji, (3) budżet 2-4 tys. zł/mc na infrastrukturę. Nie potrzebujecie własnego klastera GPU, własnego data science team ani dedykowanego serwera. Managed solutions (Pinecone Serverless, LangChain.js, OpenAI API) wystarczają dla większości SME.

Czy RAG zastąpi moich handlowców albo customer success?

Nie. W case LegaLink RAG oszczędza 22 min na researchu przed callem, ale sama rozmowa, negocjacja, budowanie relacji – to wciąż robota człowieka. W ciągu 6 miesięcy LegaLink NIE zredukował zespołu sales – wręcz zwiększył liczbę callów na handlowca o 55% i ARR o 1,7 mln zł. RAG wyświetla rolę „asystenta kontekstu”, nie „zastępcy handlowca”. Obietnica „AI zastąpi twój zespół” jest marketingiem narzędzi, nie praktyką wdrożeń B2B.

Ile trwa wdrożenie RAG dla firmy z 20-50 pracownikami?

Realistyczny timeline: 8-14 tygodni od decyzji do produkcji. Tydzień 1-2: analiza problemu i danych. Tydzień 3-5: PoC. Tydzień 6-9: budowa pełnej architektury i pipeline’u. Tydzień 10-12: pilotaż z 2-4 użytkownikami. Tydzień 13-14: roll-out. Jeśli wasze dane są czyste i accessible przez API, może być krócej. Jeśli trzeba najpierw uporządkować dane – dodajcie 4-8 tygodni.

Co jeśli nie mam ticketów ani bogatej bazy wiedzy?

Alternatywne źródła: (1) transkrypcje rozmów sales (Gong, Chorus) – jeśli używacie, (2) emaile handlowców w CRM – często niedoceniane, zawierają bogaty kontekst, (3) publiczne wiadomości o klientach (newsy, komunikaty), (4) dane behawioralne z waszej platformy (jak klient używa produktu). RAG nie wymaga dokumentacji – wymaga „tekstowych danych o kliencie”, które mogą pochodzić z różnych źródeł.

Czy dane klienta nie wyciekną przez API OpenAI/Anthropic?

Zależy od setupu. Standardowe API OpenAI/Anthropic nie używa waszych danych do treningu (enterprise tier). Dla wrażliwych branż (finanse, prawo, medycyna) często wymagana jest opcja zero-retention albo self-hosted LLM (Llama 3.1 405B, Mistral Large). LegaLink użył zero-retention OpenAI embeddings + zero-retention Anthropic dla generacji, plus anonimizacja danych wrażliwych na poziomie pipeline’u. Zgodnie z RODO prawnicy zweryfikowali setup i podpisali clearance.

Jak mierzyć sukces RAG przed pełnym wdrożeniem?

Trzy etapy mierzenia: (1) Techniczne – precision@5, recall@20 na manualnie przygotowanym test set’cie 200-500 par, (2) Pilotażowe – A/B test grupa z RAG vs bez przez 4-8 tygodni na waszym KPI biznesowym, (3) Pełne – porównanie KPI rok do roku z atrybucją przez grupę kontrolną. Bez test set’u (etap 1) nie wdrażajcie RAG – nie będziecie wiedzieć, czy działa.

Jakie są największe ryzyka RAG w produkcji?

Pięć głównych: (1) Halucynacje – system wymyśla fakty – mitigation przez wymóg cytowania źródła i confidence score, (2) Stale data – baza wiedzy przestaje być aktualna – automatyczny pipeline aktualizacji co godzinę/dzień, (3) Cost runaway – LLM API koszt rośnie z użyciem – monitoring + budget alerts, (4) RODO/compliance – dane wrażliwe w pipeline’ie – anonimizacja + audit log, (5) Adopcja – system jest, ale nikt go nie używa – pilotaż + mentoring + iteracja UX.

Co dalej

Case LegaLink pokazuje, że RAG w B2B nie jest technologią „nice to have”, tylko realnym driver’em wzrostu przychodu. Kluczem jest wybór właściwego momentu (bolesny problem biznesowy, mierzalny KPI), właściwej architektury (self-hosted przy skali, managed przy starcie) i właściwego procesu (iteracyjnie, z pilotażem, z grupą kontrolną).

• Szerszy kontekst AI w marketingu 2026 – AI w marketingu w 2026: praktyczny przewodnik od promptów do agentów.
• Inne case study wdrożeń AI – produkcja treści AI i automatyzacja audytów SEO.
• Jak zorganizować content produkcję wokół AI – workflow content AI.

Rada na start – jeśli rozważacie RAG w swojej firmie, zróbcie dwa tygodnie discovery: zapiszcie 20 pytań, które najczęściej zadaje zespół sales/CS, sprawdźcie, gdzie są odpowiedzi (w jakich systemach), oszacujcie, ile czasu dziennie tracicie na szukaniu. Jeśli to minimum 30 min/osoba dziennie i macie 20+ osób – RAG się zwróci w 6-8 miesięcy. Jeśli mniej – zacznijcie od prostszych projektów (prompt templates, content automation) i RAG zostawcie na później.

Druga rada – nie wdrażajcie RAG samemu, jeśli nie macie ML engineer’a w zespole. Pierwsza próba bez doświadczenia kończy się zwykle systemem, który „jakoś działa”, ale ma 40% precision, którego nikt nie używa. Agencja specjalizująca się w RAG albo konsultant z przeszłych wdrożeń oszczędzi wam 3-6 miesięcy straconego czasu.

Ostatnia rada – planujcie stałe koszty (nie tylko wdrożenie). RAG w produkcji to 15-55 tys. zł/mc łącznie. Jeśli budżet nie wytrzymuje takich stałych, wybierzcie prostsze podejście – prompt engineering z dobrze zbudowanym templates może dać 50-70% wartości za 10% kosztu.