RAG bez wektorów: Jak PageIndex odczytuje dokumenty bez embeddingów
RAG bez wektorów z PageIndex: dlaczego wyszukiwanie wektorowe w fragmentach traci kontekst w długich raportach, oraz jak indeks drzewiasty oparty na rozumowaniu znajduje odpowiedź, wraz z kodem.
Źródła: I Deleted My Vector Database and My RAG System Got Better
Zapytaj kogoś, co wydarzyło się w rozdziale 7, a on nie będzie czytał całej książki. Otworzy spis treści, przejdzie do rozdziału 7 i przeczyta tylko tę część. To szybkie i dokładne.
Większość systemów wyszukiwania dokumentów w AI nie funkcjonuje w ten sposób. Dzielą one tekst na dowolne fragmenty, przekształcają każdy fragment w liczby i porównują pytanie z tymi liczbami, które są najbliższe. Czasami to wystarcza. Czasami odpowiedź znajduje się pomiędzy granicami fragmentów, a system jej nie dostrzega. Nowszy podejście zwane vectorless RAG rezygnuje z tego sposobu i każe modelowi analizować strukturę dokumentu tak, jak robiłby to człowiek. Podobno osiągnęło ono 98,7% skuteczności w trudnym teście finansowym, podczas gdy tradycyjne metody ledwo osiągały 50%. To, co następuje, wyjaśnia ten wynik, wychodząc od podstaw.
Co robi RAG
RAG to skrót od retrieval-augmented generation. W praktyce oznacza to umożliwienie modelowi dostępu do twoich własnych dokumentów, dzięki czemu jego odpowiedzi pochodzą z twoich danych, a nie tylko z danych treningowych.
To ma znaczenie, ponieważ modele takie jak GPT czy Claude mają określony zakres wiedzy. Nigdy nie widziały wewnętrznych raportów, umów prawniczych ani dokumentów medycznych żadnej konkretnej organizacji. RAG wypełnia tę lukę, pobierając istotne fragmenty i umieszczając je przed modelem tuż przed udzieleniem odpowiedzi. Obietnica jest prosta: zadaj pytanie i otrzymaj odpowiedź opartą na twoich materiałach. Rzeczywistość jest jednak bardziej skomplikowana.
Wersja siłowa
Najprostszy sposób polega na wklejeniu całego dokumentu do promptu razem z pytaniem i pozostawieniu modelowi zadania jego przetworzenia. Bez baz danych, bez skomplikowanych mechanizmów.
from openai import OpenAI
import PyPDF2
client = OpenAI(api_key="your-api-key")
# Extract all text from a PDF
def extract_pdf_text(pdf_path):
reader = PyPDF2.PdfReader(pdf_path)
full_text = ""
for page in reader.pages:
full_text += page.extract_text() + "\n"
return full_text
document_text = extract_pdf_text("annual_report.pdf")
user_question = "What was the total revenue in 2024?"
response = client.chat.completions.create(
model="gpt-4.1",
messages=[
{"role": "system", "content": "Answer based on the provided document."},
{"role": "user", "content": f"Document:\n{document_text}\n\nQuestion: {user_question}"}
]
)
print(response.choices[0].message.content)
To w porządku dla pięciostronicowego PDF. Raport roczny liczący 200 stron szybko napotyka takie ograniczenia.
- Ograniczenia kontekstowe. Modele mogą przyjąć tylko określoną ilość tekstu naraz, a dokument 200-stronicowy może zawierać aż 300 000 tokenów, co przekracza możliwości nawet największych modeli.
- Strata jakości. Nawet jeśli wszystko zmieści się, odpowiedzi stają się niejasne. Prośba o znalezienie jednej igły w całym stogu siana sprawia, że model traci koncentrację.
- Koszt. Usługodawcy pobierają opłatę za każdy token, więc wysyłanie 300 000 tokenów za każde pytanie, nawet jeśli odpowiedź mieści się na jednej stronie, szybko się kumuluje.
RAG został stworzony właśnie po to, by obejść te ograniczenia.
Jak działa wektorowe RAG
Idea jest prosta. Dokument przetwarza się raz, a jego inteligentne reprezentacje przechowuje się w bazie danych; przy zadawaniu pytania pobiera się tylko istotne fragmenty. Proces składa się z pięciu etapów:
- Podział na fragmenty. Dokument dzieli się na mniejsze części, na przykład co 500 słów lub po jednym akapicie.
- Wbudowanie. Specjalistyczny model przekształca każdy fragment w listę liczb, wektor, który oddaje jego znaczenie. Podobne koncepcje otrzymują podobne liczby.
- Przechowywanie. Wektory trafiają do specjalnie stworzonej bazy danych, takiej jak ChromaDB, Pinecone lub Weaviate. Inne popularne opcje to Milvus, Qdrant oraz rozszerzenie PGVector dla PostgreSQL.
- Wyszukiwanie. Pytanie również jest wbudowywane, a baza danych zwraca te fragmenty, których wektory są najbliższe. To właśnie jest wyszukiwanie podobieństw.
- Generowanie. Pobrane fragmenty wraz z pytaniem trafiają do modelu, dzięki czemu może on pracować na podstawie skoncentrowanego kontekstu.
Pełna wersja działająca z użyciem ChromaDB i OpenAI wygląda następująco:
from openai import OpenAI
import chromadb
import PyPDF2
client = OpenAI(api_key="your-api-key")
# Step 1: Extract and chunk the document
def extract_and_chunk(pdf_path, chunk_size=500):
reader = PyPDF2.PdfReader(pdf_path)
full_text = ""
for page in reader.pages:
full_text += page.extract_text() + "\n"
words = full_text.split()
chunks = []
for i in range(0, len(words), chunk_size):
chunk = " ".join(words[i:i + chunk_size])
chunks.append(chunk)
return chunks
chunks = extract_and_chunk("annual_report.pdf")
# Step 2 and 3: Embed and store in ChromaDB
chroma_client = chromadb.Client()
collection = chroma_client.create_collection("my_documents")
collection.add(
documents=chunks,
ids=[f"chunk_{i}" for i in range(len(chunks))]
)
# Step 4: Search for relevant chunks
user_question = "What was the total revenue in 2024?"
results = collection.query(
query_texts=[user_question],
n_results=5
)
relevant_chunks = "\n\n".join(results["documents"][0])
# Step 5: Generate answer with focused context
response = client.chat.completions.create(
model="gpt-4.1",
messages=[
{"role": "system", "content": "Answer based only on the provided context."},
{"role": "user", "content": f"Context:\n{relevant_chunks}\n\nQuestion: {user_question}"}
]
)
print(response.choices[0].message.content)
Większość firm dzisiaj używa czegoś podobnego. Dobrze radzi sobie z prostymi pytaniami dotyczącymi zwykłych dokumentów, ale pojawiają się u niej słabe punkty, gdy dokumenty stają się skomplikowane.
Trzy sposoby, w jakie zawodzi
Części, które dzielą ideę na pół
Wyobraźmy sobie akapit w raporcie mówiący, że przychody operacyjne w trzecim kwartale osiągnęły 4,2 miliarda dolarów, co oznacza wzrost o 12% w porównaniu z poprzednim rokiem, głównie dzięki usługom chmurowym, które przyniosły 2,8 miliarda dolarów przychodów powtarzalnych (szczegóły w Załączniku C). Jeśli okno o długości 500 słów zakończy się akurat w środku tego zdania, jedna część zachowa liczbę, ale straci wyjaśnienie, podczas gdy druga zachowa wyjaśnienie, ale straci liczbę. Żadna z nich nie przedstawia pełnego obrazu sytuacji.
Tę usterkę łatwo odtworzyć:
paragraph = """The company's Q3 operating income was $4.2 billion,
representing a 12% increase over the prior year period. This growth
was primarily driven by the expansion of cloud services, which
contributed $2.8 billion in recurring revenue as detailed in the
segment breakdown in Appendix C."""
# Simulating a chunk boundary at word 20
words = paragraph.split()
chunk_1 = " ".join(words[:20])
chunk_2 = " ".join(words[20:])
print("Chunk 1:", chunk_1)
print("---")
print("Chunk 2:", chunk_2)
Zadaj pytanie o przyczynę wzrostu zysku operacyjnego w III kwartale, a wyszukiwanie może zwrócić fragment dotyczący usług chmurowych bez żadnych danych lub fragment z danymi, ale bez wskazania przyczyny. W obu przypadkach odpowiedź jest niekompletna.
Dzielenie tekstu na akapity nie rozwiązuje tego problemu. Niektóre akapity składają się z dwóch zdań, inne zajmują połowę strony, a trzy kolejne akapity mogą opowiadać jedną historię, która ma sens tylko gdy są czytane razem.
Odnośniki, które nic nie dają
Umowy i dokumenty finansowe opierają się na wskazówkach typu „To reguluje rozdział 4.2.1” lub „Szczegółowe tabele znajdują się w Załączniku G”. Pytanie dotyczące czegoś na stronie 12, które odnosi się do danych na stronie 87, najprawdopodobniej skończy się na stronie 12, ponieważ słowa kluczowe się pokrywają, ale żaden mechanizm wyszukiwania wektorowego nie prowadzi do strony 87, gdzie znajdują się te dane.
Szybka symulacja pokazuje ten problem:
# Simulating a cross-reference failure
documents = {
"page_12": "The company's debt-to-equity ratio improved significantly in 2024. For a full breakdown of long-term obligations, see Appendix G on page 87.",
"page_45": "Marketing expenses increased by 15% due to new campaigns.",
"page_87": "Appendix G: Long-term debt stands at $12.4B. Senior notes: $8.1B. Credit facility: $4.3B. Maturity schedule: 2026-2034."
}
# Vector RAG would likely return page_12 for a debt question
# but miss page_87 where the actual numbers live
# because "debt-to-equity ratio" is more similar to the query
# than "Senior notes" and "Credit facility"
To jest powszechne w umowach, dokumentach regulacyjnych i pracach naukowych. Odpowiedź często znajduje się jednocześnie w dwóch miejscach, a system, który nie potrafi ich połączyć, zawsze zwróci niekompletne wyniki.
Słownictwo, które się nie pokrywa
Podobieństwo wektorowe w dużej mierze zależy od tego, jak sformułowane są słowa użytkownika w porównaniu z tekstem dokumentu. Jeśli w raporcie mowa jest o EBITDA dostosowanym według standardów non-GAAP, a użytkownik pyta o dostosowane zyski, wektory mogą nie być na tyle zgodne, by wyświetlić odpowiedni fragment tekstu. Ludzie nie znają dokładnej terminologii dokumentu i nie powinni jej znać.
Sytuacja pogarsza się w dziedzinach technicznych. Lekarz szukający protokołów leczenia zawału serca może przeoczyć fragmenty opisane jako metody postępowania przy zawałach mięśnia sercowego. Znaczenie jest identyczne, ale wektory mogą być na tyle od siebie oddalone, że odpowiednie fragmenty nigdy się nie pojawią.
To nie są rzadkie przypadki krawędziowe. W długich, zstrukturyzowanych dokumentach w środowisku produkcyjnym zdarzają się one regularnie.
Wprowadzenie do RAG bez wektorów
W wrześniu 2025 roku zespół z VectifyAI opublikował framework o nazwie PageIndex, który obiera inną drogę. Nie dzieli on dokumentów i nie porównuje numerów. Zamiast tego tworzy zstrukturyzowaną mapę dokumentu, umożliwiając modelowi AI analizę jego treści.
Natychmiastowym źródłem inspiracji jest sposób, w jaki faktycznie pracują eksperci. Analityk otrzymuje 200-stronicowy raport – osoba potrzebująca jednego wykresu nie czyta wszystkich stron. Sprawdza spis treści, wybiera sekcję najprawdopodobniej zawierającą odpowiedź i czyta ją uważnie. Jeśli jest tam napisane „zobacz Dodatek G”, przechodzi do tego dodatku.
PageIndex sprawia, że model zachowuje się w ten sam sposób. Kluczowym spostrzeżeniem jest to, że najbardziej podobny tekst nie zawsze jest najbardziej istotny. Baza danych wektorowych zwraca to, co najbardziej przypomina pytanie, jednak odpowiedź czasami znajduje się w sekcji, która w ogóle do niego nie przypomina. Potrzebne jest rozumowanie na temat tego, gdzie powinna znajdować się odpowiedź, a nie dopasowywanie wzorców.
System działa w dwóch krokach.
Krok pierwszy: indeks drzewiasty
Zamiast dzielenia na fragmenty i tworzenia wektorów, dokument jest przekazywany modelowi rozumującemu, który przedstawia go w formie drzewa. Wyobraźmy sobie zdolnego stażystę, który czyta cały raport i tworzy wielopoziomową strukturę spisów treści, w której każda pozycja zawiera tytuł, krótkie streszczenie, zakres stron oraz linki do podpozycji. Raport finansowy mógłby wyglądać w ten sposób:
Root: Annual Report 2024
|-- Executive Summary (pages 1-3)
| Summary: "Overview of company performance, key metrics..."
|-- Financial Statements (pages 15-45)
| |-- Income Statement (pages 15-20)
| |-- Balance Sheet (pages 21-30)
| +-- Cash Flow Statement (pages 31-45)
|-- Risk Factors (pages 46-60)
+-- Appendices (pages 80-120)
|-- Appendix A: Segment Data (pages 80-95)
+-- Appendix G: Detailed Tables (pages 96-120)
Brak wektorów i embeddingów – tylko struktura logiczna odpowiadająca sposobowi uporządkowania dokumentu. Model wykorzystuje swój proces rozumowania do wykrywania naturalnych granic, takich jak rozdziały, zmiany tematu i nowe sekcje, zamiast dzielić tekst według ustalonej liczby słów.
Krok drugi: wyszukiwanie oparte na rozumowaniu
Podczas wyszukiwania model widzi tylko drzewo strukturalne, a nie cały dokument. Przegląda tytuły i streszczenia, wykorzystuje swoją wiedzę specjalistyczną i wybiera węzły, które najprawdopodobniej zawierają odpowiedź.
Rozważmy pytanie dotyczące zmiany marży operacyjnej z roku na rok. Rozumowanie modelu wygląda mniej więcej w ten sposób: marże to wskaźnik finansowy, więc istotny jest rachunek zysków i strat, ale porównanie z roku na rok może wymagać również wcześniejszych danych, być może zamieszczonych w załączniku. Model odpowiada identyfikatorami węzłów obu sekcji, system pobiera wyłącznie oryginalny tekst tych dwóch sekcji, a ostateczna odpowiedź jest tworzona na podstawie tego wąskiego kontekstu.
Aby pokazać ten koncept w praktyce, wystarczą zwykłe wywołania OpenAI:
import json
from openai import OpenAI
import PyPDF2
client = OpenAI(api_key="your-api-key")
# Extract text page by page
def extract_pages(pdf_path):
reader = PyPDF2.PdfReader(pdf_path)
pages = {}
for i, page in enumerate(reader.pages):
pages[i + 1] = page.extract_text()
return pages
pages = extract_pages("annual_report.pdf")
all_text = "\n".join([f"--- Page {k} ---\n{v}" for k, v in pages.items()])
# Step 1: Build the tree index using AI reasoning
tree_prompt = f"""You are a document analyst. Read this document and create
a hierarchical table of contents as a JSON tree. Each node should have:
- "title": section name
- "summary": 2-3 sentence description of what this section covers
- "pages": [start_page, end_page]
- "children": array of child nodes (or empty array)
Document:
{all_text[:80000]}
Return ONLY valid JSON. No other text."""
tree_response = client.chat.completions.create(
model="gpt-4.1",
messages=[{"role": "user", "content": tree_prompt}],
response_format={"type": "json_object"}
)
document_tree = json.loads(tree_response.choices[0].message.content)
print("Document tree built successfully!")
print(json.dumps(document_tree, indent=2)[:500])
# Step 2: Reasoning-based search over the tree
user_question = "What was the year-over-year change in operating margin?"
search_prompt = f"""You are a retrieval expert. Given a user question and
a document's table of contents tree, identify which sections are most
likely to contain the answer.
Think step by step:
1. What kind of information does the question ask for?
2. Which sections would a human expert check first?
3. Are there sections that might cross-reference each other?
Document tree:
{json.dumps(document_tree, indent=2)}
Question: {user_question}
Return JSON with:
- "reasoning": your step-by-step thought process
- "relevant_pages": list of page numbers to retrieve"""
search_response = client.chat.completions.create(
model="gpt-4.1",
messages=[{"role": "user", "content": search_prompt}],
response_format={"type": "json_object"}
)
search_result = json.loads(search_response.choices[0].message.content)
print("Reasoning:", search_result["reasoning"])
# Step 3: Fetch only relevant pages and generate answer
relevant_text = ""
for page_num in search_result["relevant_pages"]:
if page_num in pages:
relevant_text += f"\n--- Page {page_num} ---\n{pages[page_num]}"
answer_response = client.chat.completions.create(
model="gpt-4.1",
messages=[
{"role": "system", "content": "Answer precisely based on the document context provided."},
{"role": "user", "content": f"Context:{relevant_text}\n\nQuestion: {user_question}"}
]
)
print("\nAnswer:", answer_response.choices[0].message.content)
Cały sekret sprowadza się do jednego zdania: pomiń magazyn wektorów, pomiń embeddingi, pomiń dostosowywanie rozmiaru fragmentów i pozwól modelowi przeanalizować strukturę, zdecydować, gdzie powinna znajdować się odpowiedź, i pobrać tylko te sekcje.
Używanie frameworka PageIndex
Wersja do samodzielnego użycia nadaje się do nauki. W przypadku rzeczywistych projektów PageIndex przejmuje większość pracy: tworzy optymalizowane drzewa, obsługuje bardziej zaawansowane strategie wyszukiwania i dostępny jest jako usługa chmurowa lub opcja self-hosted. Podstawowe użycie wygląda w ten sposób:
from pageindex import PageIndexClient
import time
# Initialize the client
pi_client = PageIndexClient(api_key="your-pageindex-api-key")
# Upload and process your document
result = pi_client.submit_document("./annual_report.pdf")
doc_id = result["doc_id"]
# Wait for processing to complete
while True:
status = pi_client.get_document(doc_id)["status"]
if status == "completed":
print("Document processed!")
break
time.sleep(5)
# Inspect the generated tree structure
tree_result = pi_client.get_tree(doc_id)
if tree_result.get("status") == "completed":
tree = tree_result["result"]
for node in tree:
print(f"[{node['node_id']}] {node['title']} - Page {node['page_index']}")
# Ask questions using the Chat API
response = pi_client.chat_completions(
messages=[{"role": "user", "content": "What was total revenue in FY2024 vs FY2023?"}],
doc_id=doc_id
)
print(response["choices"][0]["message"]["content"])
Wygenerowane drzewo ma taką formę:
{
"title": "Financial Stability",
"node_id": "0006",
"page_index": 21,
"text": "The Federal Reserve maintains financial stability...",
"nodes": [
{
"title": "Monitoring Financial Vulnerabilities",
"node_id": "0007",
"page_index": 22,
"text": "The Federal Reserve's monitoring focuses on..."
},
{
"title": "Domestic and International Cooperation",
"node_id": "0008",
"page_index": 28,
"text": "In 2023, the Federal Reserve collaborated..."
}
]
}
Każdy węzeł ma unikalny identyfikator wskazujący na oryginalny dokument, tytuł, sam tekst oraz węzły potomne dla podsekcji. Model przemierza drzewo, czytając streszczenia i decydując, które gałęzie należy dalej otworzyć.
W jednej zapytaniu można porównać kilka dokumentów:
response = pi_client.chat_completions(
messages=[{"role": "user", "content": "Compare the results across these two reports."}],
doc_id=["pi-abc123def456", "pi-abc123ghi789"]
)
Rozwijający agenty przy użyciu LangChain, CrewAI lub OpenAI Agents SDK mogą połączyć się z PageIndex za pośrednictwem Model Context Protocol (MCP), co umożliwia agentowi korzystanie z niego jako narzędzia do wyszukiwania informacji bez konieczności pisania specjalnego kodu integracyjnego.
Testy porównawcze stanowiące podstawę twierdzeń
FinanceBench to testy porównawcze, które przyciągnęły uwagę do podejścia RAG bez użycia wektorów. Jego pytania pochodzą z rzeczywistych dokumentów składanych do SEC (raporty 10-K i 10-Q) i wymagają dokładnych odpowiedzi: danych z tabel, obliczeń składających się z kilku kroków oraz odniesień między poszczególnymi sekcjami. To nie jest żaden test próbny.
Konwencjonalne rozwiązania RAG oparte na wektorach osiągają na tych testach wyniki w przedziale od 30% do 50%. PageIndex, wykorzystujący silnik rozumowania Mafin 2.5, uzyskał wynik 98,7%, co oznacza zupełnie inny poziom i znaczny przyrost wydajności. Wyróżniają się trzy główne powody tego sukcesu:
- Śledzenie odnośników międzysekcji. Gdy w dokumentacji znajduje się informacja „zobacz Dodatek G”, model rozumowania przemieszcza się po drzewie strukturalnym do tego dodatku i pobiera tamte dane. Magazyn wektorowy nie wie, że powinien podążać za tym wskaźnikiem.
- Przestrzeganie nienaruszonego układu. Tabela finansowa zawiera nagłówki, nagłówki wewnętrzne, przypisy oraz linki między komórkami. Sekcje drzewa utrzymują je razem w ramach wyraźnych granic, podczas gdy dzielenie na fragmenty o stałej wielkości rozdziela je.
- Rozumowanie wieloetapowe. Aby uzyskać informację o zmianie marży operacyjnej z roku na rok, potrzebne są liczby z dwóch sekcji oraz wynik obliczenia. Model rozumowania określa, że potrzebuje obu tych elementów, i pobiera je razem, podczas gdy wyszukiwanie podobieństw prawdopodobnie pobrałoby tylko ten fragment najbliższy sformułowaniu pytania.
Jedna ważna uwaga: na początku 2026 roku zespół PageIndex nie opublikował szczegółowych danych dotyczących szybkości i przepustowości. Każde zapytanie wymaga kilku sekwencyjnych wywołań modelu w celu przeszukiwania i rozumowania, więc jest wolniejsze i droższe na zapytanie w porównaniu z pojedynczą wyszukiwaniem wektorowym. W przypadku zastosowań o dużym obrocie i niskiej opóźnieniu taka kompromisowa opcja może nie być odpowiednia.
Wybór pomiędzy nimi
Vectorless RAG nie jest uniwersalną zamiennicą baz danych wektorowych – to narzędzie specjalistyczne.
Vector RAG nadaje się wtedy, gdy odpowiedzi muszą nadejść w mniej niż sekundę, gdy korpus składa się z wielu krótkich dokumentów, takich jak baza FAQ czy zbiór artykułów, gdy koszt na zapytanie przewyższa doskonałą dokładność, lub gdy chatbot konsumencki może obyć się odpowiedziami wystarczająco dobrymi.
Vectorless RAG nadaje się do obsługi długich, zstrukturyzowanych dokumentów profesjonalnych: rocznych raportów, umów, dokumentów regulacyjnych oraz instrukcji technicznych. Pasuje również do sytuacji, w których najważniejsza jest dokładność, gdy zapytania muszą odnosić się do krzyżowych odniesień, lub gdy konieczny jest wyraźny ślad audytowy pokazujący, skąd pochodzi każda część odpowiedzi.
Dla zastosowań produkcyjnych warto rozważyć rozwiązanie hybrydowe. Lekkie metadane lub filtry słów kluczowych mogą zawęzić zakres dokumentów istotnych, a następnie rozumowanie oparte na drzewach umożliwi znalezienie dokładnych sekcji w nich zawartych. Dzięki temu uzyskuje się szybkość tradycyjnego wyszukiwania już przy pierwszej próbie oraz dokładność rozumowania przy kolejnej.
Kompromis pomiędzy kosztem a jakością jest rzeczywisty. Modele oparte na rozumowaniu kosztują więcej za każdą próbę wywołania niż modele embeddingowe, a przeszukiwanie drzewa oznacza liczne sekwencyjne wywołania i wyższą opóźnioność. Szybkość i cena są zamieniane na dokładność i możliwość wyjaśnienia wyników. W regulowanych dziedzinach takich jak finanse, prawo i opieka zdrowotna, gdzie błędne odpowiedzi mają poważne konsekwencje, taka zamiana zazwyczaj się opłaca.
Kierunek rozwoju
Przejście od systemów wyszukiwania opartych na podobieństwie do tych opartych na rozumowaniu jest jeszcze w początkowej fazie, ale kierunek jest jasny. PageIndex już obsługuje wariant oparty na obrazach, który działa bezpośrednio na obrazach stron PDF, bez konieczności wyodrębniania tekstu ani używania OCR. Do systemu wprowadza się obrazy stron, a model analizuje to, co widzi. To pomaga w przypadku złożonych układów, zeskanowanych stron oraz wbudowanych wykresów, z którymi metody wyodrębniania tekstu radzą sobie słabo.
Trwają również prace nad systemem wyszukiwania opartym na agencjach. Zamiast jednego przeglądu, model nadal bada treść: śledzi odniesienia, porównuje sekcje, zadaje sobie dodatkowe pytania i doskonali swoją odpowiedź w ramach kilku rund rozumowania, co stanowi różnicę pomiędzy szybkim przeglądaniem dokumentu a jego dogłębnym studiowaniem.
Każdy, kto chce eksperymentować, może skorzystać z repozytorium open-source PageIndex na GitHubie, które zawiera uruchamialne notatniki Jupyter dla zarówno standardowych, jak i opartych na rozpoznawaniu obrazu metod przetwarzania danych. Projekt osiągnął 20 000 gwiazdek po swoim uruchomieniu we wrześniu 2025 roku, a jego kanał na Discordzie jest aktywny.
Bazy danych wektorowych pozostaną i dobrze radzą sobie z wieloma obciążeniami. Jednak aplikacje, które wymagają dogłębnego analizowania długich, złożonych dokumentów, przybywają w coraz większej liczbie, a dzielenie tekstu na kawałki o stałej wielkości w nadziei, że wyszukiwanie podobieństw pokaże właściwy fragment, staje się coraz mniej skuteczne. Umowy, dokumenty rejestracyjne i specyfikacje techniczne to właśnie te dokumenty, które najbardziej cenią się w biznesie, i to tam metody wyszukiwania oparte na rozumowaniu przynoszą największe korzyści.
Rozsądny sposób oceny polega na przetestowaniu wersji do samodzielnego użycia na dokumencie, który jest już dobrze zrozumiały, a następnie na wypróbowaniu PageIndex na tym samym pliku, aby zobaczyć, w jaki sposób drzewo strukturalne zachowuje organizację informacji, której niszczy dzielenie na fragmenty. Najlepszy system wyszukiwania to nie ten z najnowocześniejszą technologią, lecz ten, który znajduje właściwą odpowiedź.
Sposób na przetestowanie
- Vector RAG – odpowiedni do zrozumienia podstaw: zainstaluj
chromadbiopenai, uruchom przykład ChromaDB na krótkim dokumencie, następnie spróbuj z dłuższym i obserwuj, w których miejscach odpowiedzi stają się mniej pewne. - Metoda DIY bez wektorów – dobrze nadaje się do zrozumienia koncepcji: uruchom prosty przykład drzewa rozumowania od OpenAI na tym samym dokumencie i porównaj odpowiedzi z wersją wektorową.
- Wersja produkcyjna bez wektorów: pobierz bezpłatny klucz API PageIndex ze strony dokumentacji, zainstaluj pakiet Pythona
pageindexi postępuj zgodnie z przykładem SDK. Zloaduj rzeczywisty dokument i zadawaj pytania, na które odpowiedzi są już znane – to najszybszy sposób na ocenę odpowiedniości.
Wszystkie przykłady wykorzystują Python 3.10 lub nowszy wraz z SDK OpenAI, ChromaDB i PyPDF2, zainstalowanymi za pomocą polecenia pip install openai chromadb PyPDF2 pageindex. Potrzebny jest klucz API OpenAI, a także klucz PageIndex do przykładów z tej platformy.
Podobne artykuły
- Szukanie semantyczne w PostgreSQL za pomocą pgvector i Node.js – bez potrzeby LLM — Budowanie wyszukiwania opartego na znaczeniach w PostgreSQL przy użyciu pgvector, embeddingów MiniLM i Node.js: tokeny, fragmenty, wektory, indeks IVFFlat, operatorzy odległości oraz sposoby odczytywania wyników.
- Zdjęcia ekranu pamięci agenta, umiejętności, degradacja i zakres gałęzi — Cztery ulepszenia warstwy pamięci wbudowanej bazy danych wektorowej dla agentów programistycznych: przenośne zdjęcia ekranu z możliwością łączenia, aktywacja umiejętności, degradacja z kontrolą konfliktów oraz pamięć ograniczona do konkretnej gałęzi.