Przejdź do głównej zawartości

7 postów z tagiem "RAG"

Retrieval-Augmented Generation — chunkowanie, retrieval i jakość odpowiedzi asystentów opartych o własne dokumenty.

Wyświetl wszystkie tagi

Generative AI Design Patterns #7: prefix cache skrócił TTFT 40 razy, cache semantyczny pomylił sobotę z niedzielą

· 20 min aby przeczytać
Przemysław Majdak
Full-Stack Developer, Automation Engineer & Web Security Specialist

Rozdział 8 „Generative AI Design Patterns" dotyczy ograniczeń: kosztu, latencji, sprzętu i pamięci rozmowy. Większość liczb z tego rozdziału się zestarzeje, ale dwa wzorce są trwałe: test degradacji i pamięć długoterminowa. Sprawdziłem cztery tezy na Gemmie 4 26B na stacji z RTX 5090. Prefix cache skrócił czas do pierwszego tokenu przy prompcie 35 tys. tokenów z 2,4 s do 59 ms. Cache semantyczny na bge-m3 nie odróżnił „sklep w sobotę" od „sklep w niedzielę": żaden próg nie oddzielił parafraz od pytań różniących się jednym słowem. Przy ruchu o 20% większym, niż serwer przerabia, p95 czasu do pierwszego tokenu wyniósł 13 s. Test, który czeka na odpowiedź przed wysłaniem kolejnego zapytania, pokazał przy dwukrotnym przeciążeniu 3,5 s. Profil faktów wyciągany z rozmowy odpowiadał tak dobrze jak pełna historia (21 i 20 na 21) przy prompcie ponad sześć razy krótszym.

Cztery modele w RAG-u na RTX 5090: najszybszy nie wygrał, a pomiar szybkości znów kłamał

· 11 min aby przeczytać
Przemysław Majdak
Full-Stack Developer, Automation Engineer & Web Security Specialist

Sprawdziłem, czy obecny model w firmowym RAG-u, Qwen3.8-27B w INT4, da się zastąpić czymś szybszym. Kandydaci to Gemma 4 12B, Gemma 4 26B-A4B (MoE) i Qwen3.5-9B. Wszyscy działali na tej samej karcie RTX 5090, w tym samym vLLM i z tym samym zestawem pytań. Najszybszy kandydat, Gemma 4 26B-A4B, przy 16 zapytaniach naraz dał 4,1 raza więcej tokenów na sekundę i 11 razy krótszy czas do pierwszego tokenu. Mimo to obecny model zostaje, bo tylko on zaliczył wszystkie 52 tury w obu kanałach. W pierwszym pomiarze ta przewaga w czasie do pierwszego tokenu wyszła 85-krotna, bo kandydatom pomagał prefix cache, a obecnemu modelowi nie. To ten sam błąd, który opisałem tydzień temu, tylko tym razem w drugą stronę.

Reranker czy sędzia-LLM na prawdziwych danych: lepsza kolejność przegrała z kolejką na GPU

· 13 min aby przeczytać
Przemysław Majdak
Full-Stack Developer, Automation Engineer & Web Security Specialist

We wpisie o rozdziale 4 „Generative AI Design Patterns" reranker bge oddzielił pytania spoza domeny od pozostałych na sztucznym korpusie. Ostrzegłem wtedy, że ten rozdział zniknie, gdy w bazie pojawią się fragmenty z tematów sąsiednich. Teraz powtórzyłem pomiar na prawdziwej bazie wiedzy w firmie, na stacji z RTX 5090, i rozdział zniknął. Sędzia-LLM nadal układał fragmenty lepiej niż wyspecjalizowany reranker (MRR 0,87–0,95 wobec 0,84), ale ten sam pomysł w dwóch implementacjach dał dwa różne wyniki. Gdy karta równolegle przetwarzała długie konteksty, sędzia potrzebował 9–14 s, a reranker 0,12 s. Próg odmowy na ocenie rerankera wyglądał na odporny, dopóki liczyłem go na 21 pytaniach z etykietą źródła. Na wszystkich 37 pytaniach z odpowiedzią nie oddziela pytań spoza bazy żaden model. Ten błąd złapałem dopiero przy weryfikacji tego wpisu.

Generative AI Design Patterns #3: HyDE, reranking, Trustworthy Generation i Deep Search, czyli podobieństwo to nie trafność

· 35 min aby przeczytać
Przemysław Majdak
Full-Stack Developer, Automation Engineer & Web Security Specialist

Rozdział 4 „Generative AI Design Patterns" dokłada do RAG-a cztery wzorce: przepisywanie zapytania (w tym HyDE), przetwarzanie pobranych fragmentów z rerankingiem, sygnalizowanie wiarygodności odpowiedzi i iteracyjne wyszukiwanie. Sprawdziłem wszystkie cztery na fikcyjnej polskiej instrukcji serwisowej i lokalnych modelach. Najmocniej potwierdziło się zastrzeżenie, które autorzy sami stawiają przy HyDE: w domenie, której model nie zna, hipotetyczna odpowiedź jest zmyślona, a wyszukiwanie po niej trafiło właściwy fragment w 10 przypadkach na 20 zamiast w 17. Reranking poprawił kolejność, ale lepszy okazał się wolny sędzia-LLM niż wyspecjalizowany reranker. Pętla Deep Search z promptem z książki w trzech pytaniach na pięć kończyła pracę po pierwszym kroku z odpowiedzią niepełną, bo jej ewaluator uznawał „brakuje informacji" za odpowiedź kompletną.

Generative AI Design Patterns #2: Basic RAG, Semantic Indexing i Indexing at Scale, czyli co psuje się przed modelem

· 32 min aby przeczytać
Przemysław Majdak
Full-Stack Developer, Automation Engineer & Web Security Specialist

Rozdział 3 „Generative AI Design Patterns" buduje RAG w trzech krokach: wyszukiwanie po słowach, wyszukiwanie po znaczeniu i metadane, które pozwalają bazie przetrwać wzrost. Sprawdziłem wszystkie trzy na polskiej instrukcji serwisowej i lokalnych modelach. Dwie tezy książki potwierdziły się w formie mocniejszej, niż je zapisano: surowe BM25 w języku fleksyjnym trafia na pierwszej pozycji 2 z 10 zapytań, a usunięcie starych biuletynów z bazy zmieniło poprawną odpowiedź na błędną. Trzecia teza okazała się zależna od modelu. bge-m3 bez BM25 rozróżnił 24 z 24 kodów części różniących się jednym znakiem, gdy kod był zapisany tak jak w katalogu, a naiwna hybryda wypadła od niego gorzej.

Generative AI Design Patterns (Lakshmanan, Hapke): recenzja i mapa 32 wzorców

· 9 min aby przeczytać
Przemysław Majdak
Full-Stack Developer, Automation Engineer & Web Security Specialist

„Generative AI Design Patterns" Valliappy Lakshmanana i Hannesa Hapkego (O'Reilly) katalogizuje 32 wzorce projektowania aplikacji na modelach generatywnych: od maskowania logitów, przez RAG i agentów, po guardrails. Przeczytałem całość z jednym pytaniem przy każdym wzorcu: czy odpowiada na trwałą własność modeli, czy obchodzi brak funkcji w API z 2025 roku. Mój werdykt: część katalogu się zestarzeje, ale kryteria wyboru zostaną, bo autorzy przy większości wzorców piszą, kiedy go nie stosować, a przy kilku podpierają to liczbami. Ten wpis to recenzja i mapa serii — w dziesięciu kolejnych rozbieram wzorce grupami.

Dlaczego firmowy asystent RAG „nie ma tej informacji — chunkowanie strukturalne zamiast liczenia znaków

· 10 min aby przeczytać
Przemysław Majdak
Full-Stack Developer, Automation Engineer & Web Security Specialist

Najczęstsza przyczyna, dla której wewnętrzny asystent RAG odpowiada „nie mam tej informacji w bazie wiedzy" na pytanie o dokument, który ewidentnie w tej bazie jest, nie leży w modelu, promptcie ani w wyszukiwaniu wektorowym. Leży w chunkowaniu: dzielenie tekstu po liczbie znaków odcina nagłówek sekcji od jej treści, a fragment bez nagłówka jest dla modelu treścią bez informacji, czego dotyczy. W zmierzonym korpusie dotyczyło to 47-73% fragmentów.