ai RAG - ghdrako/doc_snipets GitHub Wiki

tags:

  • ai
  • llm
  • rag

Ai RAG

RAG architecture:

  • feature pipeline

    • Cleaning
    • Chunking
    • Embedding

  • vector database - In addition to storing embeddings, the vector database often maintains metadata associated with each document chunk. This metadata can include information such as document source, timestamps, content category, or access permissions. Metadata allows the retrieval system to apply filters during search, improving both precision and relevance.

  • query processing module - In many cases, the original user query may be ambiguous, incomplete, or phrased differently from the language used in the underlying documents.

    • query expansion, where the system generates multiple related query variations, allow the retrieval system to search the knowledge base using different phrasings or semantic interpretations of the original question.
    • self-querying, where the system analyzes the query to infer metadata constraints. For example, a query asking about a specific product or document category may implicitly contain filtering conditions. Self-querying mechanisms can extract these conditions and apply them as structured filters during retrieval.

  • retrieval and ranking system

    • reranking stage - evaluates the candidate chunks and selects the most relevant ones based on the relationship between the query and the retrieved text.
    • top-K ranked document chunks - The final output of this stage that will be used as context for the language model.

  • Prompt Construction typically involves combining several elements:

    • the user query
    • the retrieved document chunks
    • system instructions guiding the model’s behavior

  • language model inference service.

  • https://www.lighthousenewsletter.com/p/rag-is-simpler-than-you-think

  • FTS (np. Elasticsearch, SQLite FTS5) jest bardzo łatwy we wdrożeniu, wysoce skalowalny, przenośny. LLM, RAG nakładają ogromny ciężar operacyjny i koszty utrzymania.

  • Wyszukiwanie semantyczne zawodzi tam, gdzie potrzebna jest precyzja - Podobieństwo semantyczne (wyszukiwanie wektorowe) działa świetnie ogólnikowo, ale w wielu zastosowaniach (np. szukanie konkretnego adresu, numeru telefonu, cen w firmach regulowanych prawnie, dokładnych nazw części) użytkownicy potrzebują dokładnego dopasowania słów kluczowych. Wektory zwracają często nieistotne "podobne" wyniki, co bywa bardzo irytujące dla końcowego użytkownika.

  • Alternatywne (i często lepsze) podejście do RAG: Text-to-SQL zamiast wektorów - zamiast ładować dane wektorem, dużo lepsze rezultaty uzyskuje się, dając LLM-owi strukturę tabel (np. bazy SQLite z indeksem FTS5) i pozwalając, aby model językowy samodzielnie napisał i wykonał zapytanie SQL. Agent doskonale radzi sobie z tworzeniem precyzyjnych zapytań FTS w oparciu o to, o co pyta użytkownik, eliminując potrzebę rozbudowanej wektoryzacji i poprawiając trafność wyników.

  • wysokiej jakości RAG polega na "trasowaniu i podejmowaniu decyzji" (routing). Czasem agent szuka w FTS, czasem z użyciem wektorów, czasem generuje zapytanie bazodanowe. Łączenie wyników deterministycznych (np. cenników, które muszą być w 100% dokładne) z informacjami prawdopodobnościowymi (generowanymi przez LLM) poprzez modułowe podejście daje najlepsze efekty biznesowe.

  • wektory (embeddings) zdecydowanie wygrywają: Wielojęzyczność - gdzie dokumentacja jest wielojęzyczna (np. po francusku, niemiecku i włosku), a użytkownicy przeszukują ją lub zadają pytania w innym języku (np. japońskim, wplatając angielski żargon). FTS dla wielu języków wymaga ogromu pracy (skonfigurowanie tokenizerów, słowników synonimów dla każdego języka osobno, tłumaczenia w locie). Wektory (embeddings) rozwiązują to z automatu, funkcjonując jako jedno matematyczne, w pełni niezależne od języka "tłumaczenie".

RAG = Retrieval-Augmented Generation

To architektura łącząca dwa podejścia:

  • Retrieval – wyszukiwanie informacji z zewnętrznego źródła wiedzy (np. bazy danych, dokumentów, wyszukiwarek).
  • Generation – generowanie odpowiedzi przez model językowy (LLM), z wykorzystaniem wyszukanych informacji.

Cel: Umożliwić modelowi odpowiadanie na pytania w oparciu o aktualne i dokładne dane, które nie znajdują się bezpośrednio w jego wytrenowanej wiedzy.

Ogólny przepływ

  • Input użytkownika (np. pytanie).
  • Moduł Retrieval przeszukuje bazę wiedzy (np. dokumenty PDF, artykuły, wewnętrzne dane firmy).
  • Zwrócone fragmenty są przekazywane jako kontekst do modelu językowego.
  • Model generuje odpowiedź na podstawie pytania i dostarczonych fragmentów.

RAG bez rerankingu

  • Retriever (np. wektorowy, oparty o embeddingi) znajduje np. 10 fragmentów dokumentów najbardziej podobnych do zapytania. *Wszystkie (lub część) tych fragmentów trafiają do modelu generatywnego, który z nich buduje odpowiedź. Problem: embeddingi nie zawsze dają idealną kolejność trafności — np. fragment 5. może być ważniejszy niż fragment 1.

Reranking

Reranking to drugi etap selekcji:

  • Retriever zwraca np. 50 kandydatów.
  • Reranker (np. model typu cross-encoder) ocenia dokładniej, jak bardzo każdy kandydat pasuje do zapytania.
  • Wybierasz np. 5 najlepszych i dopiero one trafiają do modelu generatywnego.

modele do rerankingu:

  • Bi-encoder (embedding retriever) – szybki, ale mniej precyzyjny.
  • Cross-encoder (reranker) – wolniejszy, ale dokładniejszy (porównuje pytanie i fragment razem, nie osobno).

Przykłady popularnych rerankerów:

  • cross-encoder/ms-marco-MiniLM-L-6-v2 (Hugging Face)
  • bge-reranker-large (BAAI)
  • Cohere Rerank (API)

Schemat RAG z rerankingiem

Zapytanie użytkownika
       ↓
 [Retriever] – szybkie wyszukiwanie (np. 50 fragmentów)
       ↓
 [Reranker] – dokładne ocenienie trafności
       ↓
 [Top N fragmentów] – najbardziej trafne
       ↓
 [Generator] – model LLM tworzy odpowiedź