Mentionsy

Będziemy badać wielkie starcie, czyli RAG kontra Cache.

Czy w dzisiejszych czasach zespoły produktowe naprawdę potrzebują skomplikowanego systemu RAG?

I tak narodził się RAG.

Używa baz wektorowych, by znaleźć fragmenty zewnętrznych danych i dopiero potem łączy je z naszym zapytaniem.

I wiesz, to co jest tutaj fascynujące, to fakt, że RAG osiągnął 51% wskaźnika adopcji w przedsiębiorstwach.

RAG to szukanie w bibliotece za każdym razem, a CAG to sytuacja, w której po prostu wykuliśmy cały podręcznik na blachę przed egzaminem i odpowiadamy z pamięci.

Tradycyjny RAG generuje odpowiedź w ponad 9 sekund.

RAG wydaje mi się strasznie skomplikowany z tymi wszystkimi bazami.

Wymaga utrzymania baz wektorowych jak Pinecone czy QDrant, ciągłej synchronizacji, co prowadzi do tego, że aż, uwaga, 72% implementacji RAG w firmach po prostu zawodzi w pierwszym roku.

A kiedy RAG jest nadal niezbędny?

RAG jest niezastąpiony przy ogromnych i szybko rotujących danych.

RAG tu wygrywa.

Ale RAG zostaje królem, gdy mamy ogromne zasoby, powiedzmy, globalnego SharePointa w korporacji.

Często spotkasz się z nazwami typu Selfroot, Turborag czy Harag.

Używamy CIG jako takiego błyskawicznego poziomu pierwszego dla wiedzy fundamentalnej, a jeśli tam nie ma odpowiedzi, system odpala RAG jako poziom drugi dla tych rzadszych, specjalistycznych zapytań.

No dobrze, a wady Raga?

RAG to rurociąg.

Jeśli algorytm na początku źle podzieli tekst albo baza wektorowa zwróci Ci zupełnie nieistotne fragmenty, to ten nasz genialny LLM na samym końcu dostanie śmieci.

Pierwsze to, czy przypadkowo nie przekombinowujesz, budując RAG do analizy zaledwie 50-stronicowego dokumentu?

agentic RAG, i takiej pełnej integracji multimodalnej.

Aha, czyli różnica między czak i rag powoli zacznie się zacierać,