O co w ogóle chodzi
Duży model językowy wie dużo o świecie i nic o twojej firmie. Nie zna twojego cennika, procedur reklamacji ani tego, co uzgodniliście z klientem w zeszłym tygodniu. RAG (Retrieval-Augmented Generation) to sposób, żeby to zmienić bez trenowania własnego modelu: przed odpowiedzią system wyszukuje w twoich dokumentach kilka pasujących fragmentów, dokleja je do pytania i dopiero wtedy prosi model o odpowiedź.
Brzmi prosto i w wersji demo jest proste. Kłopoty zaczynają się, gdy dokumentów jest dziesięć tysięcy, połowa to skany, a pytanie brzmi „ile mamy jeszcze reklamacji otwartych u klienta X”, na które żaden dokument nie odpowiada wprost.
Co się zmieniło od 2025
Okno kontekstu urosło i część RAG stała się zbędna
Dwa lata temu model mieścił kilkanaście stron tekstu. Dziś Gemini bierze milion tokenów, czyli kilka tysięcy stron, a inne modele kilkaset tysięcy. Do tego doszło cache'owanie kontekstu, więc wrzucenie tych samych dokumentów przy każdym pytaniu nie kosztuje za każdym razem pełnej ceny.
Wniosek praktyczny: jeśli twoja „baza wiedzy” to regulamin, cennik i 30 procedur, nie buduj RAG. Wklej to wszystko do kontekstu i gotowe. RAG ma sens, gdy danych jest za dużo, zmieniają się codziennie albo nie każdy użytkownik może widzieć wszystko.
Samo wyszukiwanie wektorowe to za mało
W 2024 wszyscy opowiadali o embeddingach i bazach wektorowych, jakby to była cała magia. Okazało się, że wyszukiwanie po podobieństwie znaczeniowym pięknie znajduje „jak reklamować produkt” dla pytania „procedura reklamacji”, ale gubi numer faktury, kod produktu albo nazwisko. Dlatego dziś standardem jest wyszukiwanie hybrydowe: wektory plus klasyczne wyszukiwanie po słowach (BM25), a wyniki łączy się i przepuszcza przez reranker, czyli mniejszy model, który ocenia, które fragmenty naprawdę odpowiadają na pytanie. Ten jeden krok poprawia jakość bardziej niż zmiana modelu językowego na droższy.
Bazy wektorowe przestały być osobnym produktem
Pinecone, Weaviate, Qdrant nadal istnieją, ale w małych i średnich wdrożeniach wystarcza to, co już masz. PostgreSQL z rozszerzeniem pgvector, MySQL 9 z typem VECTOR, Meilisearch z wyszukiwaniem hybrydowym. Jedna baza mniej do utrzymania to jedna awaria mniej w nocy.
RAG stał się „agentowy”
Pierwsze systemy robiły jedno wyszukanie i odpowiadały. Dzisiejsze potrafią zadać sobie pytanie pomocnicze, przeszukać kilka źródeł, sprawdzić, czy znalazły wystarczająco, i dopiero odpowiedzieć. Przy pytaniu „który z naszych klientów z Katowic ma zaległą fakturę i otwartą reklamację” agent odpyta CRM, system faktur i bazę zgłoszeń osobno, a potem złoży wynik. To już nie jest „wyszukaj i streść”, to jest asystent z dostępem do narzędzi.
GraphRAG i pamięć
Microsoft pokazał w 2024 podejście, w którym z dokumentów buduje się graf pojęć i relacji, a pytania „jakie są główne tematy w naszych reklamacjach z tego roku” zadaje się grafowi, nie fragmentom tekstu. Działa świetnie na pytania przekrojowe, ale budowa grafu kosztuje. W małej firmie rzadko się opłaca. Wspominam, bo klienci o to pytają po konferencjach.
Jak to wygląda u mnie w praktyce
Każde wdrożenie zaczynam od tego samego pytania: na jakie trzy pytania system ma odpowiadać na pewno? Nie „na wszystko o firmie”, tylko trzy konkretne. Na przykład: „jaki jest status zlecenia numer X”, „jakie warunki gwarancji ma produkt Y”, „co ustaliliśmy z klientem Z w ostatniej rozmowie”. Dla tych trzech pytań układam zbiór 30 do 50 przykładów z poprawnymi odpowiedziami i to jest mój test. Każda zmiana w systemie przechodzi przez ten test, inaczej nie wiem, czy coś poprawiłem, czy popsułem.
Dalej idzie to tak:
- Dane. Skąd pochodzą, kto ma do nich dostęp, jak często się zmieniają. Skan faktury wymaga OCR, mail wymaga wycięcia stopek i cytowań, baza CRM wymaga zapytań SQL, nie wektorów. Tu schodzi połowa czasu i nie da się tego pominąć.
- Uprawnienia. Jeśli handlowiec nie może widzieć wynagrodzeń, to asystent też nie może mu ich zacytować. Filtrowanie wyników po uprawnieniach użytkownika projektuję przed pierwszą linijką kodu, bo doklejanie tego później zawsze zostawia dziury.
- Wyszukiwanie. Hybrydowe, z rerankerem, z metadanymi (data, typ dokumentu, klient). Fragmenty tnę po strukturze dokumentu, nie po liczbie znaków.
- Odpowiedź ze źródłem. Każda odpowiedź ma link do dokumentu, z którego pochodzi. Jeśli model nie znalazł nic sensownego, mówi „nie wiem”, a nie zmyśla. To ustawienie, nie cecha modelu.
- Koszt. Liczę go na zapytanie, zanim system trafi do zespołu. Cache, mniejszy model do rerankingu, większy tylko do końcowej odpowiedzi. Różnica między przemyślanym a naiwnym układem to często dziesięciokrotność rachunku.
- Człowiek na końcu. Asystent proponuje odpowiedź na reklamację, pracownik ją zatwierdza. Asystent nie wysyła niczego sam. Przynajmniej przez pierwsze miesiące.
Kiedy RAG nie ma sensu
- Gdy dane mieszczą się w kontekście. Patrz wyżej.
- Gdy pytania są tak naprawdę raportami. „Ile sprzedaliśmy w maju” to zapytanie SQL, nie wyszukiwanie w dokumentach. Model może je napisać, ale to inny mechanizm.
- Gdy dane są bałaganem. RAG nie uporządkuje dokumentów, tylko pokaże bałagan szybciej. Czasem lepszą inwestycją jest tydzień porządków w folderach.
- Gdy nikt nie będzie tego używał. Sprawdzam to pilotażem na pięciu osobach, zanim ktoś zapłaci za system dla pięćdziesięciu.
Narzędzia, jeśli chcesz zajrzeć głębiej
Stary wpis miał listę dwudziestu produktów. Zostawiam cztery, bo tyle naprawdę używam: LlamaIndex albo LangChain do łączenia klocków (jedno z dwóch, nie oba), pgvector albo Meilisearch do wyszukiwania, Ragas do oceny jakości odpowiedzi i jakikolwiek reranker (Cohere, Jina albo otwarty bge-reranker). Reszta to kwestia gustu i tego, w jakiej chmurze już jesteś.
Jeśli rozważasz coś takiego u siebie, zacznij od tych trzech pytań, na które system ma odpowiadać na pewno. Z tym można przyjść na rozmowę. Bez tego każda wycena jest zgadywaniem.