PageIndex w RAG: zamiana wyszukiwania wektorowego

PageIndex jako alternatywa dla wyszukiwania wektorowego w RAG: analiza i uruchomienie lokalne

PageIndex proponuje zastąpienie wyszukiwania wektorowego w RAG hierarchiczną strukturą dokumentu. Dokument jest segmentowany na strony, LLM buduje drzewo spisu treści z podsumowaniami węzłów. Zapytanie wyszukiwania jest kierowane do LLM w celu wyboru odpowiednich węzłów, po których następują wyodrębnione strony jako kontekst. Bez chunkingu, embeddingów i wektorowych baz danych.

Ograniczenia przy skalowaniu

PageIndex jest zoptymalizowany dla pojedynczych dokumentów. Dla kolekcji proponują:

• Filtrowanie według metadanych (w opracowaniu, analogicznie do magazynów wektorowych).
• Wyszukiwanie według wygenerowanych opisów (dla małej objętości).
• Wyszukiwanie semantyczne (powrót do wektorowych embeddingów).

Spis treści z podsumowaniami kompresuje kontekst 4–5 razy. Alternatywy takie jak TF-IDF lub BM25 wymagają indeksowania. Przechowywanie spisu treści dla tysięcy dokumentów nie zostało rozwiązane. LLM zastępuje tutaj wyszukiwanie według podobieństwa wyszukiwaniem według trafności, analogicznie do czytania złożonego tekstu przez spis treści.

Deklarowana dokładność 98,7% na FinanceBench (w porównaniu z ~90% wyszukiwania wektorowego) jest osiągana dzięki rozumowaniu. Koszt jest dziesiątki razy wyższy. Testowano na gpt-4o i gpt-5.4.

Eksperymenty z modelami lokalnymi

Testowano na artykule akademickim o Cyberpunk 2077 (PDF, ~17k tokenów). Potok Markdown jest analogiczny do MarkdownTextSplitter z LangChain – podział według nagłówków.

Potok PDF automatycznie wyodrębnia nagłówki, ale z problemami:

• Błędy wyjść JSON – przetwarzanie tekstu (usuwanie bibliografii, cudzysłowów).
• Próg dokładności 60% – obniżony przez env ACCURACY_THRESHOLD.
• Niska dokładność z powodu dopasowania węzłów i fragmentów przez LLM – zwiększono MAX_TOKENS z 20k.

Modele:

• gemma3:27b – halucynuje spis treści (dokładność <60%).
• gpt-oss:20b – dokładność 57–63%, stabilnie.
• qwen3:14b – dokładność 69,57%, ale błędy JSON.

Czas na GPU 16GB: ~30 min (korekcja błędów dominuje).

Przykład spisu treści (gpt-oss:20b, dokładność 0.63):

{
  "doc_name": "2077.pdf",
  "structure": [
    {
      "title": "Wprowadzenie",
      "node_id": "0000",
      "start_index": 1,
      "end_index": 3,
      "summary": "Artykuł bada, jak gra wideo Cyberpunk 20...",
      "text": "Perspektywa Cyberpunk 2077 na przewidywanie i..."
    },
    {
      "title": "Przegląd literatury",
      "node_id": "0001",
      "start_index": 3,
      "end_index": 3,
      "summary": "Częściowy dokument przedstawia przegląd literatury ...",
      "text": "umieszczając Cyberpunk 2077 w szerszym kontekście ...",
      "nodes": [
        // ... podwęzły
      ]
    }
    // ... pozostałe węzły
  ]
}

Konfiguracja i uruchomienie lokalne

Instalacja: liteLLM==1.82.0 (nowsze wersje są podatne na ataki). Nie używać pip install pageindex – to dla API.

Notatniki: MinimalPageindexLocalPDF.ipynb, MinimalPageindexLocalMD.ipynb.

Modyfikacje utils.py: OLLAMA_HOST, OLLAMA_TIMEOUT.

page_index.py: ACCURACY_THRESHOLD, MAX_TOKENS.

Proces:

• Ładowanie dokumentu (PDF/MD).
• LLM buduje spis treści (find_toc_pages).
• Segmentacja na strony/wiersze.
• Budowanie drzewa węzłów z podsumowaniami.
• Korekcja dokładności.
• Wyszukiwanie: LLM wybiera węzły według zapytania → wyodrębnianie stron → finalny RAG.

PageIndex integruje LLM w pobieraniu dla śledzonego wyszukiwania z odnośnikami do stron/działów. Nadaje się do złożonych dokumentów, ale jest zasobożerny dla produkcji.

Co jest ważne

• Skalowanie: Brak gotowego rozwiązania dla dużych kolekcji bez wyszukiwania wektorowego.
• Dokładność: Zależy od modelu; lokalne (qwen3:14b) dają 69%, ale z błędami.
• Koszt: +8–9% dokładności za x10–xN zasobów w porównaniu z wektorowym RAG.
• Formaty: PDF z automatycznym wykrywaniem nagłówków; MD według struktury markdown.
• Modyfikacje: Konieczne env dla progów i tokenów na słabym sprzęcie.

— Editorial Team