Strona główna / Artykuły

retrieval-augmented-genllmvector-databasepythonragagents

PageIndex: RAG bez wektorów, oparty na rozumowaniu, z indeksem drzewiastym

PageIndex rezygnuje z bazy danych wektorowej na rzecz indeksu drzewiastego zarządzanego przez LLM. Jak działa ten oparty na rozumowaniu system RAG, wraz z kodem w Pythonie, połączeniem MCP oraz wynikami testów.

Wydawca: REACTAPP.TOP14 min czytania3118 słów

Źródła: PageIndex: The RAG Framework That Threw Out Vector Databases and Still Hit 98.7% Accuracy

Załóżmy framework RAG, który całkowicie rezygnuje z baz danych wektorowych i pokazuje wynik testu wydajności, do którego żaden system oparty na embeddingach nie może się zbliżyć. To PageIndex – projekt otwartego oprogramowania od VectifyAI. W FinanceBench, standardowym teście wydajności dla systemów odpowiadających na pytania dotyczące dokumentów finansowych, zwykłe systemy RAG oparte na wektorach osiągają wyniki na poziomie około 30 do 50 procent. PageIndex pokazuje wynik 98,7 procenta. Udało mu się to nie dzięki lepszemu modelowi embeddingów, lecz dzięki ich całkowitemu pominięciu.

Ten wynik zasługuje na ponowną ocenę, ponieważ odpowiadanie na pytania finansowe na podstawie dokumentów SEC to jeden z najtrudniejszych testów wyszukiwania w praktycznym zastosowaniu sztucznej inteligencji. Wymaga on wieloetapowego rozumowania, przeskakiwania między sekcjami oraz dokładnych liczb. Najlepszy system w tym zestawieniu nie używał wektorów, żadnego dzielenia tekstu na fragmenty ani baz danych wektorowych.

Oto, co robi PageIndex, jak jest zbudowany, przykładowy kod w Pythonie, w czym się wyróżnia, a w czym nie.

Ściana, na którą napotykają długie dokumenty

Każdy, kto budował systemy RAG na materiale dłuższym niż post na blogu, zna ten problem. Użytkownik pyta system oparty na 200-stronicowym raporcie rocznym, jak całkowite przychody netto w roku fiskalnym 2024 porównują się z rokiem 2023. Standardowa procedura wygląda następująco:

  1. Dzieli się dokument na fragmenty o stałej wielkości, zwykle od 300 do 500 tokenów.
  2. Każdy fragment jest embedowany za pomocą modelu takiego jak text-embedding-3-large.
  3. Wektory są przechowywane w Pinecone, Weaviate, Milvus, Chroma, pgvector lub podobnych systemach.
  4. Podczas wyszukiwania pytanie jest embedowane, a następnie pobierane są najbliższe wektory o najwyższej wartości podobieństwa kosinowego.
  5. Te fragmenty są przekazywane do LLM w celu sformułowania odpowiedzi.

Dla krótkiego, nieustrukturyzowanego materiału, takiego jak posty na blogu, zgłoszenia obsługi klienta czy dokumentacja produktu, to jest doskonałe rozwiązanie. Jednak raporty typu 10-K dzielą się w przewidywalny sposób.

Zapytanie nie wygląda jak odpowiedź. Wyszukiwanie wektorowe zakłada, że tekst najbardziej podobny do zapytania jest najbardziej istotny. Jednak zapytanie wyraża intencję, a nie treść. Pytanie o trendy przychodów nie ujawnia żadnego wiersza w tabeli na stronie 47 – pokazuje natomiast każdy akapit, który mówi o przychodach.

Jeden termin, sześćdziesiąt miejsc. W długim rocznym raporcie wyrażenie „przychód operacyjny” pojawia się dziesiątki razy w różnych kontekstach. Algorytmy porównywania podobieństwa traktują je mniej więcej jednakowo, więc fragment, który naprawdę odpowiada na pytanie, może nigdy nie trafić do pierwszej trójki.

Dzielenie na fragmenty psuje struktury tabel. Nagłówek tabeli znajduje się w fragmencie 14, a wiersz, którego potrzebujemy, w fragmencie 15. Żaden z nich sam w sobie nie ma sensu. Przecinające się okna, semantyczne dzielenie na fragmenty oraz parserzy uwzględniające strukturę tabel pomagają, ale żaden z nich nie eliminuje podstawowego problemu.

Brak pamięci między rundami. Jeśli poprzednia wiadomość dotyczyła aktywów, a następna pyta „a co z pasywami?”, system traktuje to jako zupełnie nowe zapytanie. Nic nie wskazuje mu, że użytkownik najprawdopodobniej ma na myśli tę samą sekcję tego samego raportu.

Odnośniki pozostają ukryte. Załóżmy, że strona 12 odsyła czytelników do Dodatku G, który znajduje się na stronie 87. Tekst dodatku nie ma żadnego semantycznego pokrycia z pierwotnym pytaniem, więc system RAG wektorowy nigdy nie będzie podążał za tym odnośnikiem. Wprowadzanie metadanych odnośników do fragmentów tekstu to rozwiązanie tymczasowe, ale jest niestabilne i nie nadaje się do skalowania.

To nie są rzadkie przypadki krawędziowe – wynikają one z samej architektury. Jak powiedział Mingtian Zhang, współzałożyciel VectifyAI, w ogłoszeniu projektu, to, czego naprawdę potrzebuje system wyszukiwania, to istotność, a istotność wymaga rozumowania.

Czym jest PageIndex

PageIndex to bezwektorowe, oparte na rozumowaniu framework RAG opracowane przez VectifyAI we wrześniu 2025 roku, stworzone przez Zhang i Yu Tang. Jest objęte licencją MIT, a repozytorium szybko się rozwijało – do końca marca 2026 roku miało już ponad 23 000 ocen w formie gwiazdek oraz prawie 2 000 klonów.

Jego podstawowa koncepcja pochodzi od AlphaGo. Zamiast wyczerpująco skanować całą przestrzeń, jak to robi porównywanie podobieństwa wektorowego każdego fragmentu, tutaj wykorzystuje się nauczoną strategię do inteligentnego poruszania się po tej przestrzeni. PageIndex stosuje ten podejście do dokumentów, charakteryzując się trzema istotnymi cechami:

  • Brak bazy danych wektorowych. Struktura dokumentów oraz rozumowanie modeli językowych zastępują wyszukiwanie podobieństwa, więc nie ma tu Pinecone, Chromy ani embeddingów.
  • Brak dzielenia na fragmenty. Dokumenty pozostają zorganizowane jako naturalne sekcje, rozdziały, akapity i tabele, a nie arbitralne okna składające się z 500 tokenów.
  • Nawigacja w stylu ludzkim. Działa jak osoba szukająca dokumentu ręcznie: patrzy na spis treści, znajduje sekcję, która najprawdopodobniej zawiera odpowiedź, i ją czyta.

Metoda składa się z dwóch kroków.

Krok 1: hierarchiczny indeks drzewa

Przetwarzanie dokumentu nie tworzy żadnych embeddingów. PageIndex analizuje strukturę dokumentu i tworzy hierarchiczne drzewo, które w istocie stanowi spis treści przyjazny modelom LLM. Każdy węzeł zawiera tytuł, krótkie podsumowanie sekcji, zakres stron oraz węzły potomne dla podsekcji, ułożone tak głęboko, jak to konieczne.

Dokument SEC składający się z 50 stron może dać drzewo składające się z 30 do 50 węzłów, przechowywane jako jeden obiekt JSON. Nic nie znajduje się w bazie danych wektorowej – to wyłącznie JSON. Cały obiekt mieści się w jednym oknie kontekstowym modelu LLM, a można otworzyć dowolny węzeł i go przeczytać. Węzeł wygląda tak:

{
  "node_id": "0006",
  "title": "Financial Stability",
  "start_index": 21,
  "end_index": 22,
  "summary": "Covers the Federal Reserve's financial stability oversight...",
  "sub_nodes": [
    {
      "node_id": "0007",
      "title": "Monitoring Financial Vulnerabilities",
      "start_index": 22,
      "end_index": 28,
      "summary": "Describes the Fed's vulnerability monitoring framework..."
    },
    {
      "node_id": "0008",
      "title": "Domestic and International Cooperation",
      "start_index": 28,
      "end_index": 31,
      "summary": "Federal Reserve collaboration with international bodies..."
    }
  ]
}

Każdy node_id wskazuje na surowy treść danej sekcji: tekst, tabele i obrazy. Model językowy może zażądać treści dowolnego węzła, gdy jest tego potrzebny.

Kluczowym elementem architektury jest to, gdzie znajduje się ten indeks. Baza danych wektorowych przechowuje oddzielny, statyczny indeks embeddingów poza modelem. Tutaj drzewo JSON znajduje się w aktywnym kontekście modelu podczas procesowania zapytań. VectifyAI nazywa to indeksem w kontekście, a model nie tylko go wyszukuje, ale także na jego podstawie rozumuje w czasie rzeczywistym.

Krok 2: wyszukiwanie w drzewie oparte na rozumowaniu

Gdy przychodzi pytanie, PageIndex przekazuje modelowi LLM drzewo zawierające jedynie tytuły i streszczenia, bez surowego tekstu, i w praktyce pyta, gdzie szukać w ramach tej struktury i tego pytania. Model czyta tytuły i streszczenia węzłów, ocenia, które sekcje najprawdopodobniej zawierają odpowiedź, i zwraca listę identyfikatorów węzłów. Następnie system pobiera rzeczywisty treść tych węzłów.

Proces wyszukiwania to pętla:

  1. Przeglądaj spis treści, aby zrozumieć strukturę i zlokalizować potencjalne sekcje.
  2. Wybierz sekcję, która najprawdopodobniej zawiera potrzebną informację.
  3. Przeczytaj ją, pobierając surowy tekst z tego węzła.
  4. Sprawdź, czy to wystarczy. Jeśli tak, napisz odpowiedź. Jeśli nie, wróć do pierwszego kroku i spróbuj innej sekcji.

To zupełnie inna paradygmatyka niż wyszukiwanie wektorowe. Baza danych wektorowych oblicza podobieństwo kosinowe dla każdego fragmentu równolegle, co jest szybkie, ale powierzchowne. PageIndex natomiast wykorzystuje model językowy do ustalenia, gdzie najprawdopodobniej znajduje się odpowiedź. W trakcie tego procesu model może śledzić odniesienia między elementami, rozpoznać, że pytanie dotyczące danych z dodatku powinno być przypisane do węzła tego dodatku, oraz zrozumieć, że pytanie wieloetapowe wymaga treści z dwóch sekcji. Każdy krok pozostawia również ślad rozumowania, dzięki czemu można zobaczyć, które węzły zostały odwiedzone i dlaczego. W ten sposób proces wydobywania informacji przestaje być „czarną skrzynką”.

Przykład z Dodatkiem G

Demo stworzone na bazie integracji MCP firmy VectifyAI pokazuje, dlaczego to ma znaczenie. Ktoś pyta o łączną kwotę aktywów odroczonych w rocznym raporcie Rezerwy Federalnej. Główna część raportu, na stronach 75 do 82, omawia zmiany w aktywach odroczonych, ale nigdzie nie podaje ich łącznej kwoty. Strona 77 zawiera jednak zdanie mówiące, że tabela 5.3 podsumowuje przychody, wydatki i dystrybucje, a za dodatkowymi szczegółami należy sięgnąć do załącznika G.

Vector RAG utyka w tym miejscu. Załącznik G to tabela liczb, która nie ma żadnej semantycznej zgodności z pytaniem dotyczącym aktywów odroczonych, dlatego baza danych ją ignoruje. PageIndex postępuje inaczej – model językowy analizuje strukturę danych, przechodzi do sekcji finansowej, znajduje odniesienie do załącznika G, podąża za nim w strukturze, pobiera odpowiednią tabelę i zwraca dokładną wartość, przy czym ślad rozumowania pokazuje każdy krok.

Python, od początku do końca

Kod poniżej został zaadaptowany z oficjalnego przewodnika PageIndex, z komentarzami wyjaśniającymi jego przebieg. Zacznij od instalacji:

pip install pageindex openai

Importy:

import os
import json
import asyncio
from pageindex import PageIndexClient
from openai import AsyncOpenAI

Następnie dane uwierzytelniające i klienci. Klucz API pochodzi z panelu sterowania PageIndex:

# Grab an API key from https://dash.pageindex.ai/api-keys
PAGEINDEX_API_KEY = os.environ["PAGEINDEX_API_KEY"]
OPENAI_API_KEY = os.environ["OPENAI_API_KEY"]pi_client = PageIndexClient(api_key=PAGEINDEX_API_KEY)
openai_client = AsyncOpenAI(api_key=OPENAI_API_KEY)

Buduj drzewo

Wprowadź narzędzia pomocnicze:

import pageindex.utils as utils

Zaalokuj plik PDF, a PageIndex stworzy drzewo. Indeksowanie zajmuje trochę czasu, więc skrypt sprawdza stan aż do momentu, gdy będzie gotowe, i wyświetla wynik:

# Upload a PDF; PageIndex handles the tree generation
doc = pi_client.upload("annual_report_2024.pdf")
doc_id = doc["doc_id"]# Tree generation takes a bit, so we poll
while not pi_client.is_retrieval_ready(doc_id):
    print("Still indexing...")
    import time; time.sleep(5)# Grab the tree and take a look
tree = pi_client.get_tree(doc_id, node_summary=True)["result"]
print("Document Tree:")
utils.print_tree(tree)

Wydruk pokazuje każdą sekcję, podsekcję oraz zakres stron, dzięki czemu od razu widać, czy drzewo poprawnie odwzorowało układ.

Niech LLM przeszuka drzewo

To jest kluczowy krok. Funkcja otrzymuje drzewo oraz zapytanie:

async def find_relevant_nodes(tree: dict, query: str) -> list:
    """LLM reasons over tree structure to identify relevant nodes."""

Wewnątrz surowy tekst jest usuwany, aby zaoszczędzić tokeny, ponieważ model potrzebuje jedynie tytułów i streszczeń. Prompt przedstawia model jako eksperta od wyszukiwania dokumentów, każe mu kierować się odnośnikami krzyżowymi i prosi o JSON zawierający jego rozumowanie wraz z listą identyfikatorów węzłów:

    # Strip raw text to save tokens; the LLM only needs titles and summaries
    tree_without_text = utils.remove_fields(
        tree.copy(), fields=["text"]
    )    search_prompt = f"""
    You are a document retrieval expert. Given a question and
    a hierarchical tree structure of a document, identify all
    nodes likely to contain the answer.    Each node has a node_id, title, and summary.
    Follow cross-references if a section mentions another.    Question: {query}    Document tree structure:
    {json.dumps(tree_without_text, indent=2)}    Reply in this JSON format only:
    {{
        "thinking": "<reasoning about which nodes are relevant>",
        "node_list": ["node_id_1", "node_id_2"]
    }}
    """    response = await openai_client.chat.completions.create(
        model="gpt-4.1",
        messages=[{"role": "user", "content": search_prompt}],
        temperature=0,
        response_format={"type": "json_object"},
    )    result = json.loads(response.choices[0].message.content)
    print(f"LLM reasoning: {result['thinking']}")
    return result["node_list"]

Pobierz treść i odpowiedź

Następna funkcja zbiera surowy tekst dla wybranych węzłów:

def collect_node_content(tree: dict, node_ids: list) -> str:
    """Pull raw text from the nodes the LLM selected."""
    all_nodes = utils.flatten_tree(tree)
    context_parts = []

Następnie ciało pętli buduje kontekst, przy czym każda sekcja jest oznaczona tytułem i zakresem stron, a cały proces obejmuje wybór węzłów, pobranie treści, utworzenie odpowiedzi z cytatami oraz zwrócenie tej odpowiedzi wraz z użytymi węzłami.

    for node in all_nodes:
        if node["node_id"] in node_ids:
            title = node.get("title", "Untitled")
            pages = f"pages {node.get('start_index', '?')}-{node.get('end_index', '?')}"
            text = node.get("text", "")
            context_parts.append(
                f"[{title} | {pages}]\n{text}"
            )
    return "\n\n---\n\n".join(context_parts)
async def answer_query(tree: dict, query: str) -> dict:
    """Full vectorless RAG pipeline: tree search + answer generation."""    # Step 1: LLM picks the nodes
    node_ids = await find_relevant_nodes(tree, query)    # Step 2: Fetch content from those nodes
    context = collect_node_content(tree, node_ids)    # Step 3: Generate answer with citations
    answer_prompt = f"""
    Answer the question using only the provided context.
    Cite specific pages and sections in your answer.    Context:
    {context}    Question: {query}
    """    response = await openai_client.chat.completions.create(
        model="gpt-4.1",
        messages=[{"role": "user", "content": answer_prompt}],
        temperature=0,
    )    return {
        "answer": response.choices[0].message.content,
        "retrieved_nodes": node_ids,
        "context_length": len(context),
    }
# Run it
query = "What was the total value of deferred assets in 2023?"
result = asyncio.run(answer_query(tree, query))
print(result["answer"])
print(f"Nodes used: {result['retrieved_nodes']}")

Podłączenie do MCP

Dla Claude, Cursor lub dowolnego agenta kompatybilnego z MCP, PageIndex łączy się bezpośrednio za pośrednictwem hostowanego serwera:

{
  "mcpServers": {
    "pageindex": {
      "type": "http",
      "url": "https://api.pageindex.ai/mcp",
      "headers": {
        "Authorization": "Bearer your_api_key"
      }
    }
  }
}

Istnieje również lokalny serwer MCP do przesyłania plików z dysku, który wymaga Node.js 18 lub nowszej wersji:

{
  "mcpServers": {
    "pageindex": {
      "command": "npx",
      "args": ["-y", "@pageindex/mcp"]
    }
  }
}

Liczby w kontekście

Główna liczba pochodzi z FinanceBench, który korzysta z rzeczywistych dokumentów składanych do SEC, w tym 10-K, 10-Q i 8-K, i przyjmuje tylko dokładne odpowiedzi. Mafin 2.5, agent analizy finansowej firmy VectifyAI oparty na PageIndex, został przetestowany na całym zbiorze danych. Odnotowana dokładność:

System Dokładność Zakres benchmarku
Mafin 2.5 (PageIndex) 98,7% 100%
Tradycyjny vector RAG około 50% zmienia się
GPT-4o bez RAG około 31% 100%
Perplexity około 45% zmienia się

Różnica wynosząca około 49 punktów procentowych w porównaniu z tradycyjnym vector RAG to nie mała poprawa – to zupełnie inna klasa wyników. Wciąż pojawiają się trzy kluczowe czynniki:

  • Kolejne odniesienia krzyżowe. Wskazówki wewnątrz dokumentu, takie jak „zobacz Dodatek G”, są nawigowane za pomocą drzewa. Szukanie podobieństw nie bierze ich pod uwagę.
  • Zachowanie struktury. Tabele zawierają nagłówki, przypisy i relacje między komórkami. PageIndex przechowuje je jako węzły drzewa, podczas gdy dzielenie na fragmenty je niszczy.
  • Rozumowanie wieloetapowe. Pytanie porównujące rok budżetowy 2023 z rokiem budżetowym 2024, przedstawione w różnych częściach dokumentu, jest naturalnie obsługiwane przez pętlę iteracyjną.

Gdzie odbiega od ideału

PageIndex jest imponujący w swojej niszy, ale nie zastępuje wektorowego RAG we wszystkich przypadkach.

  • Jest wolniejszy. Każde pobieranie danych wymaga kilku wywołań modeli LLM: odczytania indeksu, analizy węzłów, pobrania treści, sprawdzenia wystarczalności, ewentualnego powtórzenia procesu. Vector RAG odpowiada w milisekundach, natomiast PageIndex – w sekundach. Współzałożyciel zauważył, że ponieważ pobieranie danych odbywa się w trakcie generowania, czas potrzebny na pierwszy token może być porównywalny z czasem zwykłego wywołania modelu LLM, ale całkowita latencja jest nadal wyższa.
  • Kosztuje więcej. W przypadku każdego zapytania wymagane są liczne wywołania modeli do inferencji, zamiast jednego wywołania do znajdowania embeddingów. Przy dużym obłożeniu sytuacja staje się kosztowna.
  • Jest zaprojektowany do głębokiej analizy, a nie do szerokiego przeszukiwania. Doskonale radzi sobie z głębokim wydobywaniem informacji z jednego długiego dokumentu. Przeszukiwanie jednocześnie 10 000 krótkich dokumentów to obszar, w którym bazy danych wektorowych odnoszą sukcesy, a budowanie i analiza drzewa dla każdego z nich nie jest praktyczne.
  • Struktura ma znaczenie. Dokument SEC z czytelnymi nagłówkami tworzy doskonałą strukturę drzewiastą. Źle sformatowana skanerka bez logicznych sekcji daje zdegradowany spis treści, co wpływa negatywnie na całość. Istnieje tryb oparty na rozpoznawaniu obrazu dla takich przypadków, ale dokumenty uporządkowane pozostają najlepszym rozwiązaniem.
  • Rozumowanie modeli LLM również nie jest doskonałe. Metoda Vector RAG daje błędy, ponieważ wektory jedynie przybliżają znaczenie tekstu. PageIndex również popełnia błędy, gdy rozumowanie jest jedynie przybliżone: model może przejść do niewłaściwej sekcji, błędnie odczytać streszczenie lub pominąć istotny podwęzeł. Te błędy są łatwiejsze do zrozumienia i prawdopodobnie łatwiejsze do naprawy, ale nadal się zdarzają.
  • Jeden punkt odniesienia. FinanceBench mierzy jakość weryfikacji w dobrze skonstruowanych dokumentach składanych do SEC. Wyniki dotyczące złożonych, wielodomenowych, niejednoznacznych zapytań w bardzo różnych typach dokumentów nie zostały niezależnie zweryfikowane w takim samym stopniu. 98,7 procent to rzeczywista wartość, ale ważne jest, by wiedzieć, co ona mierzy.

    • Kiedy go używać

    Wybierz PageIndex, gdy:

    • dokumenty są długie, uporządkowane i profesjonalne: raporty roczne, umowy, dokumenty regulacyjne, podręczniki techniczne
    • dokładność ma większe znaczenie niż szybkość, np. gdy błędna odpowiedź kosztuje pieniądze lub stwarza ryzyko niezgodności
    • zapytania wymagają wieloetapowego rozumowania lub przechodzenia między sekcjami
    • potrzebujesz śladów audytowych, ponieważ każda odpowiedź zawiera ślad rozumowania oraz odniesienia do węzłów, co jest cenione w branżach regulowanych

    Wybierz wektorowy RAG, gdy:

    • potrzebujesz odpowiedzi w mniej niż sekundę przy dużym obrocie zapytań
    • szukasz w dużym korpusie krótkich dokumentów
    • dokumenty są nieustrukturyzowane lub mają charakter konwersacyjny
    • 90 procent dokładności jest wystarczające
    • koszt za zapytanie jest głównym ograniczeniem

    Prawdopodobnie niewystarczająco badany jest model hybrydowy. Użyj wyszukiwania wektorowego, aby określić, który dokument w dużym korpusie jest istotny, a następnie przekaż go do PageIndex w celu dokładniejszej ekstrakcji.

    Co nowego od uruchomienia

    Projekt rozwija się szybko od września 2025 roku.

    Agentic vectorless RAG. Najnowsze rozszerzenie łączy samodzielnie hostowany PageIndex z SDK OpenAI Agents. Agent otrzymuje trzy narzędzia (get_document(), get_document_structure() oraz get_page_content()) i sam analizuje strukturę drzewa, wybierając odpowiednie narzędzia oraz pobierając treść bez konieczności ręcznego wybierania węzłów. Jest to przykład, od którego należy zacząć przy tworzeniu zintegrowanych procesów pracy opartych na agentach:

    pip install openai-agents
python3 examples/agentic_vectorless_rag_demo.py

    Tryb oparty na widzeniu, bez OCR. Nowy proces typu „vision-native” pomija OCR. Obrazy stron trafiają bezpośrednio do modelu obsługującego widzenie, a drzewo jest tworzone na podstawie tego, co ten model widzi na stronie. Jest to istotne w przypadku dokumentów finansowych, gdzie układ bilansu ma takie samo znaczenie jak tekst. Wykresy, tabele z połączonymi komórkami oraz przypisy pozostają nienaruszone, ponieważ nic nie jest najpierw konwertowane na tekst.

    SDK w języku TypeScript, pageindex-js-sdk, pojawiło się na początku 2026 roku i służy do integracji z Node.js oraz narzędziami do dokumentów w przeglądarce. Rozszerzenie do biurka typu .mcpb dostępne jednym kliknięciem instaluje PageIndex w Claude Desktop, przy czym autoryzacja OAuth jest obsługiwana automatycznie. ChatIndex, oddzielny repozytorium od stycznia 2026 roku, stosuje tę samą koncepcję indeksowania drzewa do długich historii rozmów.

    Szersza zmiana

    PageIndex stanowi część szerszej zmiany od pasywnej wyszukiwania, która pobiera wszystko, co wygląda podobnie, ku aktywnemu, zorientowanemu na rozumowanie wyszukiwaniu, które decyduje, gdzie szukać. Jest to już widoczne w narzędziach do programowania – Claude Code i Cursor odeszły od wektorowego RAG do kodu na rzecz aktywnego badania bazy kodu, a zespół PageIndex oczekuje, że dokumenty pójdą w tym samym kierunku. W przypadku dokumentów strukturyzowanych to przewidywanie wydaje się prawdopodobne.

    Bazy danych wektorowych nie znikną. Są szybkie, tanie i wystarczająco dobre do rozwiązywania ogromnej liczby zadań. Jednak tam, gdzie poprawność, przejrzystość i głębokie zrozumienie dokumentu są niezbędne, jak w audytach finansowych, badaniach prawniczych, dokumentacji medycznej i przestrzeganiu przepisów, wyszukiwanie oparte na rozumowaniu jest zasadniczo lepszym rozwiązaniem.

    Kod i dokumentacja dostępne są pod adresem https://github.com/VectifyAI/PageIndex, a dokumentacja szczegółowa pod adresem https://docs.pageindex.ai/.

    Powiązane materiały

    ← Wszystkie artykułyWyślij brief