RAG без вектараў: як PageIndex чытае дакументы без імбеддынгаў

Калі запытаць каго-небудзь, што адбылося ў 7-й главе, ён не будзе чытаць увесь кнігу. Ён адкрое змест, перайдзе да 7-й главы і прачытае ту частку. Гэта шырока і точна.

Большасць сістэм пошуку дакументаў на адной AI працюе зовсім не так. Яны дзеляць тэкст на довільныя фрагменты, ператвараюць кожны фрагмент у цыфры і падбіраюць адпаведнае рашэнне на адваротнасць да тых цыфр, якія знаходзяцца як можна бліжэй. Інодзе гэта прыемна. Інодзе адпаведнае рашэнне знаходзіцца між межамі фрагментаў, і сістэма гэтага не бачыць. Новейшы падход, які называецца vectorless RAG, абмовляецца ад вікорыстоўвання цыфр і прымушвае мадэль чытаць структуру дакумента так, як чытае яе чалавек. Як сообшчаецца, ён досяг 98,7% на складным фінансавым тэсце, дзе традыцыйныя методы ледве досягалі 50%. Тое, што будзе пасля, паставіць нас на шлях да гэтага рэзультата, выйшоўшы з аснов.

Што робіць RAG

RAG — гэта абяцэнка retrieval-augmented generation. У практыцы гэта значыць наданне модэлю доступу да вашых сабе дакументаў, так што яе адказы будуць выходзіць з вашых дадзеных, а не толькі з матэрыялу, на якім яна навучалася.

Гэта мае значэнне, таму што модэлі на кшталт GPT чы Claude маюць паверхневы розмежаванне знанняў. Яны ніколі не бачылі внутршніх атласаў, прававых даговораў чы медычных дакументаў какой-небудзь конкрэтной організацыі. RAG заполняе гэты прыём, выкарыстоўваючы рэлевантныя фрагменты і размешчаючы іх пры модэлі непразьдзе перад тым, як яна дае адказ. Обяцанне простае: запытайцеся, і вы отрымайце адказ, апараны на вашым матэрыяле. Рэальнасць жа стае сложнейшай.

Версія з прымітной сілой

Найболей очвістны падход — гэта прыклеўце цэлага дакумента да запытання ў прапанове і дазволэнне модэлю самай усё разабраць. Ніякіх баз дадзеных, ніякіх складных механізмаў.

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)

Гэта прыемна для пяцісторанковага PDF. Аднак 200-сторанковы годовы апаведак прышвыдка сталкаецца з такімі працоўнымі мерыбамі.

• Мерыбы кантэксту. Мадэлі можаць прыймаць толькі певную колькасць тэксту за раз, а 200-сторанковы дакумент можа налічваць аж 300 000 токенаў, што перавышае магчымасці нават самых большых модэляў.
• Падышэнне якосці. Нават калі ўсё паспявае, адпаведзі становяцца нечысткімі. Калі прасіце мадэль знайсці адну шпілю сярод цэлага купы сена, яна тырчыць увагу.
• Косць. Прадаўцы выклікаюць плату за кожны токен, таму адправка 300 000 токенаў за кожны запіт, нават які адпаведзімаеся за дапамогою адной сторанкі, быстра збірае вялікія сумы.

RAG быў створаны самэ для таго, каб абйсці гэтыя працоўныя мерыбы.

Як працуе вектарны RAG

Ідэя простая. Обрабатваеце дакумент адной раз, зберагаеце яго розумныя прэдставленні ў базе дадзенаў, а пад час запіта выкарыстоўваеце толькі актуальныя часткі. Працэс складаецца з пяці этапаў:

1. Разбіўка. Документ роздаёцца на меншыя часткі, напрыклад, кожныя 500 слоў або по аднам параграфу.
2. Вбудовванне. Спецыялізаваныя мадэлі ператвараюць кожную частку на спіс цэфр, вектар, які фіксуе яе значэнне. Падобныя ідэі палягаюць на падобных цэфрах.
3. Зберагчыцель. Вектары зберагаюцца ў спецыяльна створаных базах дадзеных, такіх як ChromaDB, Pinecone або Weaviate. Milvus, Qdrant і пашырэнне PGVector для PostgreSQL — іншыя популярныя варыянты.
4. Пошук. Запіт таксама вбудовваецца, і база дадзеных вяртае тыя часткі, чыяя вектары знаходзяцца як можна бліжэй. Гэта і ёсць пошук за схожасцю.
5. Генераванне. Атрыманыя часткі і запіт падаюць разам у мадэль, тады яна можа працаваць на адгукліваным кантэксце.

Полная працюючая версія, якая выкарыстоўвае ChromaDB і OpenAI, выглядае так:

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)

Сёння большасць компаній выкарыстоўвае ўльотнае да гэтага рашэння. Яно добра справляецца з простымі запытаннямі пра простыя дакументы, але сталквецца з труднасцямі, калі дакументы стаюць складнейшымі.

Тры прычыны яго нявыкарыстоўвання

Фрагменты, якія раздваіваюць ідэю

Уявіце абзац у апошніку, у яком пісаецца, што чысты дохід у трэцьму квартале склікаў 4,2 мільярда долераў, што на 12% больш, чым у пакананнем годзе, галоўная прычына — гэта хмарныя сервісы, якія прынеслі 2,8 мільярда долераў стаўкавага доходу (падробнасці ў Дадатку C). Калі 500-словы паверхні падыходзіць да канца саме ў серэдзіне гэтага рэчэння, адны фрагмент залішае цыфру, але втрачае поясненне, а другі — поясненне, але втрачае цыфру. Жадны з іх не расказвае всю історыю.

Гэтую проблему лёгка перадаць знову:

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)

Калі запытацца, што стало прычыной адзынкі выручкі ад аперацыйных дзеянняў у трэцьму квартале, пошук можа прадаст частку пра хмарныя службы без цыфр, або частку з цыфрамі, але без прычыны. У будзь-якім случае адказ ўсё равно непашыроны.

Раздзелэнне на параграфы не рашае проблэму. Дзеяныя параграфы складаюцца з двух рэчэй, а іншыя заполняюць палову стораніцы, і тры суседзяючыя параграфы можу рассказаць адну історыю, якая мае сэнс толькі якраз разам чытаная.

Справакі, якія нікуды не вядуць

Контракты і фінансавыя дакументы апіраюцца на пазначкі на кшталт «Гэта рэгулюецца раздзелам 4.2.1» або «Дэталізаваныя табліцы знаходзяцца ў Дадатку G». Запыт пра ўтварэнне на стораніцы 12, якае аднаёсца да дадзэнняў на стораніцы 87, верагодна прыведзе на стораніцу 12, таму што ключавыя словы збігаюцца, але нічога ў вектарным пошуку не следуе за пазначкай на стораніцу 87, дзе знаходзяцца ціфры.

Короткая сімуляцыя паказвае проблэму:

# 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"

Гэта часта прыкмета кантрактов, дакументаў, якія падаюцься для рэгуляторнай перапрацавкі, і акадэмічных працаў. Адпаведзь часта знаходзіцца ў двух месцах адночасна, і сістэма, якая не можа іх з’яеднаць, завжды будзе вяртаць непашыраныя даны.

Слоўнік, які не падходзіць

Падобнасць вектараў сільна залежыць ад таго, насколькі формулаванні карыстальніка падобнае да формулавання ў дакуменце. Калі у звятыні пісаецца пра EBITDA пасля корэктыў па стандартам non-GAAP, а карыстальніка цікавіць кэшовыя доходы, вектары можаць не падходзіць настацькі, ўнаследке чаго не будзе атрымана правільная частка тэксту. Людзі не знаюць точнай тэрміналогіі дакумента, і ім не трэба яе знаваць.

У тэхнічных галузях сітуацыя ўсё горшая. Врач, які шукае протаколы лечэння інфаркту серця, можа працягнуць пасля частак, напісаных як методы керавання інфарктам міокарда. Значэнне ідэнтычнае, але вектары можаць знаходзіцца на такай вялікай адстані, што правільныя часткі ніколі не з’яўляюцца.

Гэта не рэдкія экстрачныя сітуацыі. У дзейнаўскіх, дзялёных на структуры дакументах такія рэчы выклікаюцца рэгулярна.

Прыходзіць vectorless RAG

У верасні 2025 года команда з VectifyAI выпусціла фрэймворк пад назвай PageIndex, які выбірае іншы падход. Ён не дзеляе дакументы на часткі і не падбірае номеры. У яго ствароўваецца структураваная карта дакумента, якая дазволяе AI-модэлю аналізаваць яго змест.

Інспірацыяяй стала рэальная праця экспертаў. Калі аналітык отрымае 200-сторонній атлас і яму трэба толькі адна цыфра, ён не чытае кожную сторону. Ён пераглядае змест, выбірае раздзіл, які, як верагаецца, мае адпаведны адказ, і чытае яго адзёвна. Калі там напісана «дывіцца да Дадатку G», ён пераходзіць да Дадатку G.

PageIndex прымець за тым, каб модэль велася аднакова. Ключовая ідэя заключаецца ў тым, што найболей сэродній тэкст не завжды ёсць найболей рэлевантным. База дадзеных на аднойчынных вектарах вяртае тое, што найбольш сэроднія запытку, пры тым як адказ інодзе знаходзіцца ў раздзеле, які зовсім не сэродні яму. Патрэбна ўзгадка пра тое, дзе павінен быць адказ, а не падбор патэранаў.

Сістэма працуе ў два крокі.

Першы крок: індэкс у вачыні

У зменшыцю чакранавання і вбудоўвання дакумента, ён перадаецца модэлі для логічных выводам, якая структуруе яго ў вачынь. Уявіце сабе амбіцыязны стажыста, які чытае весь звярненне і стварае багатаслойны паведамленнік, у яком кожны пункт мае заглавле, кароткі апіс, дыяпазон сторанак і спынкі на ўсія падпункты. Фінансавае звярненне можа выглядаць так:

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)

Няма вектараў і няма эмбедынгаў, толькі логічная структура, якая адпавядае спосабу арганізацыі дакумента. Модэль выкарыстоўвае свое разумаванне, каб выявіць прыродныя межы, такія як перыяды між роздзеламі, змены тэмы і новыя часткі, замест таго, каб розрываць тэкст на фіксаваныя кантэйнты слоў.

Другі крок: пошук на аднойчыне з разумаваннем

Пад час запыткі модэль бачыць толькі дрэво, а не весь дакумент. Яна скануе заглавы і апісанні, прыкладзеі своія власныя знанні з данай галіны і выберае вузлы, якія, як правільна, могу мячыць адпаведны адказ.

Разглянемы пытанне пра змяну маржы дзеяння з годы на году. Логіка модэлі выглядае прыблізна так: маржы ўжо ўважаюцца фінансавым показнікам, таму важліва выкладка прыбылі і збыткаў, але для паўстанавлення парадку з годы на году можа знадобіцца і ранейшыя даны, можа, у дадатку. Модэлі даёмся ID-ы обох раздзелаў, сістэма запрашае толькі асловны тэкст для гэтых двух раздзелаў, і заканчоўны адказ пішаецца на адважваным на гэты тэкст адлікі.

Для практычнага прадказання гэтага падходу не трэба нічога кроме звычных вызоў у 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)

Такім чынам, весь секрэт можна выразіць ў адной фразе: не вікорыстоўваць базу вектараў, не вікорыстоўваць эмбеддынгі, не налагоджваць размер частак, а дазволіць модэлю аналізаваць структуру, выбіраць месца для адпаведзення і запрашаць толькі тыя часткі.

Выкарыстоўванне фрэймворку PageIndex

Версія, яку можна стварыць самостоятэльна, падходзіць для навучэння. Для рэальных праектаў PageIndex выконвае важку працу: ён стварае оптымізаваныя дрэвы, падтрымлівае болей прыглушаныя стратэгіі пошуку і доступны як клядовая служба, так і як варыянт для самастойнага хоставання. Базовая адналежнасць выглядае так:

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"])

Створаныя дрэва маюць такі фармат:

{
  "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..."
    }
  ]
}

Кожны рэглін мае унікальны ID, які вядзе да первіснага дакумента, заглавле, сам тэкст і дзецявыя рэгліны для падраздэлаў. Модэль праходзіць па дрэве, чытаючы апускі, і выбірае, якія галузі адкрываць далей.

У адной запытцы можна парабіраць калькі дакументаў:

response = pi_client.chat_completions(
    messages=[{"role": "user", "content": "Compare the results across these two reports."}],
    doc_id=["pi-abc123def456", "pi-abc123ghi789"]
)

Распрацоўшчыкі, які ствараюць агентаў з LangChain, CrewAI або OpenAI Agents SDK, можаць падключыць PageIndex праз Model Context Protocol (MCP), які дазволяе агенту выкарыстоўваць яго як інструмент для пошуку дакументаў без неабычнага коду інтэграцыі.

Крэтынг, які стоіць за стварэнням

FinanceBench — гэта крэтынг, які прынёс увагу да тэхнікі RAG без вектараў. Яго запытанні беруцца з рэальных дакументаў SEC (справаздачнасцня 10-K і 10-Q) і выкарыстоўваюць точныя адпаведзі: цыфры, взятыя з табліц, вырахунакі з калькольнікаў і перакіранні інформацыі з аднаго раздзела ў іншы. У ўсём гэтым няма нічага фантастычнага.

Традыцыйныя методы RAG на вектарах паўтараюць на гэтым крэтынгу рэзультаты ад 30% да 50%. PageIndex, які выкарыстоўвае двігун рассуджэння Mafin 2.5, паўтарыў 98,7%, што ўзначайна перакладаецца на абласць, зусім не схожую на тую, дзе працююць іншыя методы, і являецца значным прыростам. Выдліваюцься тры галоўныя прычыны:

• Следаванне межвыкліканых апавязоў. Калі ў дакуменце напісана «дывіцеся Дадатак G», модэль аналізу праходзіць па структуры да Дадатака G і запоўнюее інформацыю з яго. Хранілішча вектараў не маюць уявлення пра тое, што яны павінны следаваць за вказывальнікам.
• Зберэнне цэліснасі структуры. Фінансавая табліца мае заголовкі, вкладныя заголовкі, прымечанні і звязкі між клеткамі. Раздзелы структуры зберагаюць іх разам у чыста адзначаных межах, тады як разбіўка на фіксаваныя часткі роздзеляе іх.
• Аналіз з калькуляцыямі на калькі. Ёсьць патрэба выявіць змяну маржы дзеяння з годы на год — для гэтага трэбуюцься цыфры з двух раздзелаў плюс вырахунак. Модэль аналізу вырашае, што яму патрэбны якія-то з іх, і запоўнюее іх разам, тады як пошук за сэмантычнаю супаданнем, верагодна, запоўніць бы толькі тую частку, якая найбліжэй падходзіць да формулювання запіту.

Адзін адзынакавы пункт: па начало 2026 года команда PageIndex не публікавала дакладных паказанняў пра швальнасць і праўоўернасць работы. Кожны запіт выклікае калькі модэляў паспяроўна, што робіць працэс медленней і дорожэ за адзін просты пошук у вектарнай базе. Для задач з вялікым обсягам дадзеных і мінімальным часам адпаведзення такі компроміс можа не падходзіць.

Выбір межы ямі

Vectorless RAG не ўсепрацэсавы заменік для вектарных баз дадзеных. Гэта спецыялізаваны інструмент.

Vector RAG падходзіць тады, калі адпаведзенні павінны прыйсці за менш чым секунду, калі корпус складаецца з многа короткіх дакументаў, напрыклад, базы FAQ або збору статэйка, калі вартасць за запіт перавышае праблему абсалютнай тачнасці, або калі чат-боту для спожыцеля падойду адпаведзенні прыемныя за якасцю.

Vectorless RAG падае для дзейнаўгалых, структураваных прафесійных дакументаў: годовых адчыненняў, кантрактов, дакументаў, якія неабходна подаць за правіламі, і тэхнічных інструкцыяў. Ён таксама падходзіць для сітуацыяў, калі прыорытэтам являецца точнасць, калі запыткі павінны адпавядаць крос-саюванню інфармацыі, або калі неабходна чыстая лінія аўдыту, якая паказвае, звядзе куды кожная частка адпаведзі ўзялася.

Для практычнага выкарыстоўвання варта рассмотрзець гібрыдны падход. Лёгкія метаданы або фільтры за ключовымі словамі могу выбраць тыя дакументы, якія ёсць рэлевантнымі, а пасля логіка, адаснованая на дрэвах, знаходзі точныя раздзелы ў іх. гэта дае швальнасць традыцыйнага пошуку ў першы раз і тачнасць логічных вывадаў у другі.

Існуе рэальныя компрэсіі між цэнай і якасцю. Мадэлі, якія выкарыстоўваюць логічныя расчынанні, коштаюць дорожэ за адну запытку, чым мадэлі з умяшчанням даных, а праходжэнне па дрэве значыць калькі запытак па спадчынству і вышэйшую затрымку. Швальнасць і цена заменяюцца точнасцю і здатнасцю до пояснення. У рэгулююцыях сферах, такіх як фінансы, права і охорона здароў’я, дзе неправільныя адпаведзі змаўляюць наследкі, такі компрэсіі зазвычай ўзнаграджуюцца.

Куды гэта прыводзіць

Пераход з методаў пошуку, апаратных на сэмантычную садоўнасць, ўсё ўсходзіць, але напрамак ясны. PageIndex вялікі час падтрымлівае варыянт, які выкарыстоўвае візуальныя даны, працуючы безпосерэдна з адпрацоўкай зображэнняў сторанак PDF, без выкарыстоўвання методаў выкарыстоўвання тэксту чы OCR. Уводзяцца зображэнняя сторанак, і мадэль расчыняе тое, што бачыць. Гэта дапамагае з складнымі макетамі, сканаванымі сторанкамі і умяшчанымі дыяграмамі, з якімі методы выкарыстоўвання тэксту справляюцца па-свойму.

Таксама адклікаюцца праца над агентным адзьвярцэннем. У зьвязку з тым, што мадэль не працуе толькі ў аднам цыкле, яна продовжае дакледжваць: яна следуе за пахадамі, парабяляе часткі, ставіць сабе дадзейныя запытанні і удосконаляе свой адказ праз калькі раундоў разумоўкі, што і ёсць розлікам межы кароткага прыгляду да дакумента і яго адлічэння.

Кожны, хто хочаць эксперыментаваць, можа выкарыстоўваць рэпазітарый PageIndex з адкрытым кодам на GitHub, які мае рабочыя Jupyter-зошыты як для стандартных, так і для базаваных на візуальных тэхналогіях практык. Пры стартаванні праекта у сэптэбрэ 2025 года ў яго было 20 000 зірак, а ў яго Discord актыўнае сацыялістычнае сяродовішча.

Базы дадзэнтэйў-вектараў застануцца, і яны эфкарыстоўваюцца для адпрацоўкі вялікай колькасці заданняў. Аднак прыкладнасці, якія выкарыстоўваюць глыбокую аналізацыю дужа дзялёных і складных дакументаў, становяцца все болей популярнымі, і падход, калі тэкст розбіваецца на фіксаваныя часткі з надзеяй, што пошук сэмабільнасці знайдзе правільную частку, стае все менш эфкарыстным. Контракты, дакументы для рэгістраціі і тэхнічныя спецыфікацыі — гэта саме тые дакументы, якія падпрыемства ценяць найбольш, і самэ тут апрацоўка на адной падставе логічных выводам дае найбольшыя рэзультаты.

Розумны спосаб разбіраць гэта — запрацаваць версію, яку можна адразу запрацаваць самому, на дакуменце, які ужо добра разумецца, а потым запрацаваць PageIndex на тым жа файле і паглядзець, як дрэва структуры захоўваюць ту організацыю, яку руйнуе частковае разбіванне. Найлепшая сістэма пошуку — гэта не тая, якая выкарыстоўвае найсучаснейшыя тэхналогіі, а тая, якая знаходзіць правільную адпаведзь.

Шлях для прыкладнага выкарыстоўвання

• Vector RAG – прыдатны для аснов: запытайце chromadb і openai, запрацавайце прыклад ChromaDB на короткам дакуменце, пасля спробуйце з дэльнейшым дакументам і стараннае адзірнайце, дзе адказы становяцца ненадзеянымі.
• DIY без вектараў – прыдатны для разумення концэпцыі: запрацавайце просты прыклад OpenAI з дрэва і логікай на тым жа дакуменце і парабяльнайце адказы з вектарным варыянтом.
• Продакшн без вектараў: запытайце безкоштовны ключ API PageIndex з сайту дакументацыі, запытайце пакет Python pageindex і следуйце прыкладу SDK. Аплодуйце рэальны дакумент і задавайце запытанні, на якія адказы вялік шанс вядомы, гэта яшчэ быстрый спосаб адгукнуцца, чы рэшэння падходзіць.

Усе прыклады выкарыстоўваюць Python 3.10 або новейшую версію з SDK OpenAI, ChromaDB і PyPDF2, якія запытваюцца праз pip install openai chromadb PyPDF2 pageindex. Патрэбны ключ API OpenAI, а таксама ключ PageIndex для прыкладаў PageIndex.

Супаўязаныя матэрыялы

• Semantic Search in PostgreSQL With pgvector and Node.js, No LLM Needed — Стварэнне пошуку на аднойчынных значэннях у PostgreSQL за дапамою pgvector, MiniLM embeddings і Node.js: токены, часткі, вектары, індэкс IVFFlat, аператары адстані і спосабы чытання рэйтынгаў.
• Agent Memory Snapshots, Skills, Decay and Branch Scoping — Чатыры дадатковыя функцыі для шара памяці вектарнага БД для агентаў-програмістаў: перэносныя кадры памяці з возможнасцю з’еднання, актывацыя навыкаў, змена значэнняў памяці з перакіранням на выявленні канфліктов і памяць, адзінакаваная па галузях.

Узбагачэнне метаданых у RAG: фільтры, цітаты, свежасць і кантроль даступу — Чаму сістэма RAG вяртае правілы няправільнага рэгіону і як метаданы апавядковання, організацыі, часу і безпекі дапамагаюць у паводзе пад час ўваходжэння дадзеных.

30 пытанняў для спытанняў па RAG і базах дадзеных вектараў з канкрэтнымі адпаведзямі — Трыдцаць пытанняў для спытанняў па RAG і пошуку вектараў з короткімі адпаведзямі: гібрыдны паводз, HNSW проты IVF, чанкаванне, пераранжаванне, паметры ацэнкі і безпека для калькуляцыі.

Расчунакі замест адказвання ў дрэве дакументаў у замест пошуку вектараў — PageIndex стварае іерархічны індэкс, які дазволяе LLM навігаваць у ям, адмовіваючыся ад чанкавання і эмбедынга. Як гэта працуе, рэзультаты на FinanceBench і калі яго вжываць.

GraphRAG проты Vector RAG: Чаму пошук вектараў не функцыонуе у вялікіх масштабах — Vector RAG сталкніваецца з проблемамі чанкавання, расчунакаў між дакументамі і масштабавання. Пазнакайце, як GraphRAG стварае спільнатыя структуры і апускі, каб яе вырашыць, і калі выбіраць кожны з варыянтаў.