Fusing RAG, GraphRAG, PageIndex & LLM-Wiki for Enterprise Agent Knowledge Systems

Understanding Four Knowledge Modes

Enterprise Agent systems need a knowledge foundation that lets agents retrieve relevant context efficiently. Large organizations store knowledge in varied formats across departments. The article uses a library analogy to introduce four modes:

Vector RAG — Fragment Retrieval: Each book paragraph becomes an index card; semantic search finds cards close in meaning (e.g., "company expense policy").

GraphRAG — Graph-Enhanced Retrieval: Chapters, people, organizations, events form a relationship network; traverse edges to answer "who influenced whom."

PageIndex — Document Tree Navigation: Build a table of contents with summaries for a thick manual; look up the chapter first, then drill down to the full text.

LLM-Wiki — Knowledge Compilation: Like a librarian writing a continuously revised topical encyclopedia; users read the wiki first, follow cross-links, and only return to source books when needed.

These modes operate at different layers — some focus on retrieval structure, others on knowledge organization — so they are not mutually exclusive.

Broadly, RAG is an architecture that augments LLM output with external knowledge, not limited to vector databases; Graph and PageIndex can enter the RAG pipeline. In this article, "classic RAG" refers specifically to the common implementation centered on text chunking and vector recall.

Classic RAG and GraphRAG: From Fragments to Relationships

Classic RAG: Semantic Index Card Lookup

Classic RAG treats original text chunks as retrieval units. Vector indexes find content by semantic similarity — roughly, coordinates on a "semantic map" where nearby points share meaning (but not guaranteed factual identity). Process:

Indexing: Parse documents, split by chapter or semantics, compute vectors, write to vector store with source metadata.

Retrieval: Convert user query to vector, fetch nearby chunks, pass to model for answer.

In practice, vector search combines with keyword search/filters. Example: "iPhone 18 warranty terms" — vectors capture "warranty terms" semantics, keywords match exact model "iPhone 18"; merge and rerank candidates via multi-route fusion, metadata filtering, or hybrid search databases.

Applicability: Suits large-scale document collections for localized factual QA (customer service, product docs, internal policies). Mature ecosystem, easy baseline, high retrieval speed.

Core Limitation: "Similarity ≠ completeness." A chunk containing the main clause may miss exceptions; a project chunk may omit its system dependencies. Small chunks lose context; large chunks introduce noise. This explains why many early RAG systems launch fast but optimize slowly — simple principle, limited problem coverage.

GraphRAG: Traversing Relationships for Clues

Question: "Supplier A stops delivery — which key customers are affected?" No direct answer exists; must trace "supplier → parts → products → orders → customers" across multiple documents or databases.

Graph structures entities as nodes, relationships as edges. Microsoft's GraphRAG is a representative implementation:

Build Phase: Extract entities/relations from text, aggregate into graph, detect tight-knit communities ("cliques" of closely related nodes), generate community summaries.

Retrieval Phase: Vector-search relevant entities, then augment context via neighbors, relations, and source text; for summarization questions, aggregate community reports into the model.

Engineering challenges: accurate entity/relation extraction, disambiguation, source mapping, graph storage/update/query — especially hard in vertical domains to build a complete graph.

Applicability: Cross-document multi-hop questions and thematic summarization. Can trace "supplier stoppage → affected customers" or answer "what do these materials mainly discuss?"

Compared to pure vector RAG, it supplements context via relationships, but preparation is more complex (usually LLM-assisted), costlier, and can propagate errors. Only adopt when knowledge has clear relational characteristics and tasks genuinely require relationship exploration.

GraphRAG often still needs vectors: e.g., vector-find N entities relevant to the question, then walk graph relations for leads.

PageIndex: Read the TOC, Then the Original Text

Vector retrieval finds relevant content; Graph fills relations. Both work for factual queries like "which auth protocols does SSO support?" in a hundreds-page software manual. But consider:

"Why can some users still not log in after SSO config? Is it related to permission settings or version?"

RAG and GraphRAG may miss context: SSO config, permissions, version limits, FAQs scattered across chapters tens of pages apart. Recalling only semantically similar paragraphs omits preconditions, dependencies, and caveats.

PageIndex addresses cross-chapter verification in long documents.

Core Method: Build a Navigation Tree of the Original Document

PageIndex parses the document, uses TOC, heading styles, or body structure to identify chapter hierarchy, associates nodes with page ranges or text spans, generates node summaries per config, forming a "navigation tree" of the original doc.

Each index node tells the model: what this section covers, its parent/children, and where to read. It does not rely on vectors but organizes indexes by chapter hierarchy and retains original text location pointers.

At query time, the model starts by inspecting this navigation tree:

Select relevant chapters and page ranges based on the question.

Call a read tool to fetch original content for those pages.

If context seems insufficient, request additional chapters.

In the SSO example, the model might read SSO config, then supplement with permission settings, version limits, and relevant FAQ entries. Success depends heavily on navigation tree quality and model judgment.

Technical Implementation: PageIndex SDK

Open-source PageIndex enables quick start. Local call example:

from pageindex import PageIndexClient

client = PageIndexClient(
    index="gpt-6-luna",  # tree-building model
    chat="gpt-6-sol"     # query model
)

doc_id = client.submit_document(
    "report.pdf"
)["doc_id"]

answer = client.chat(
    "What was the 2023 operating margin?",
    doc_id=doc_id,
)

SDK provides index creation, structure reading, retrieval, and QA interfaces; currently handles text PDFs or Markdown (OCR, vision parsing need separate integration).

Applicability and Characteristics

PageIndex suits annual reports, contracts, manuals — long documents with clear chapters requiring cross-chapter verification. For many long docs, a candidate-document discovery step is needed first.

Advantage: grasp full document flow first, then gather evidence, greatly reducing context omissions.

Drawbacks: narrower applicability, often a "sidekick" in large projects. Costs include query latency and extra LLM calls for structure parsing, summary generation, and retrieval-time decisions, which can also be inaccurate.

LLM-Wiki: Organize and Query Knowledge by Topic

Proposed by Andrej Karpathy. Core idea: instead of retrieving from raw documents at query time, first compile knowledge into a persistent, interlinked Wiki kept up to date — like a continuously revised topical encyclopedia that organizes raw docs into concept Pages, preserves key conclusions, and cross-links Pages.

Core Method: LLM Compilation and Continuous Updates

Initial Build: From raw directory (e.g., raw), LLM reads documents, identifies entities, concepts, key facts, plans wiki page structure, merges materials by topic, generates concept/entity/topic summary pages, then creates cross-links, source backlinks, and index pages. One topic can aggregate multiple sources; one source can contribute to multiple pages.

Ongoing Maintenance: When new materials arrive or sources change, LLM identifies affected wiki pages, supplements/revises/deletes, flags unresolved issues, and ideally runs periodic checks for stale content, broken links, and knowledge gaps.

Usage: Agent follows index page and internal links to load needed content:

Read index page first (e.g., index.md) to see available topics and decide entry point.

Enter relevant concept pages via TOC links, read curated knowledge.

Extend reading on demand via cross-links to fill gaps.

Apply to current task — answer, analyze, write docs, or code.

Retrieval does not depend on vector indexes or similarity ranking; you can define custom knowledge loading strategies in AGENTS.md or Skills.

OKF: Standardizing LLM-Wiki Knowledge Format

OKF (Open Knowledge Format) is a Google-published open spec for expressing/exchanging LLM-Wiki knowledge. A wiki page is typically Markdown with YAML metadata. Example structure shown in article images (not reproducible in text). OKF-based LLM-Wikis follow this standardized layout.

Applicability and Characteristics

Suits: Domain terminology, metric definitions, operating procedures, programming contexts — reusable knowledge that supports both direct browsing and Agent task context assembly.

Challenge: Scale and long-term maintenance, due to the independent "middle layer" Wiki. With thousands of pages, source changes require locating affected pages, handling updates/conflicts/errors — significant time and token cost.

Therefore, don't rush to wikify all materials. Prioritize core knowledge that is repeatedly used and relatively stable; massive tickets, meeting notes can be curated later when reuse value emerges. Best approach: collaborate and fuse with other modes.

Fusion Applications of the Four Modes

Each mode has costs: vectors need embeddings, graphs need relation extraction, trees need building, wikis need curation and ongoing maintenance. Real applications combine them — route tasks or chain different modes and tools.

Mode Comparison

Vector RAG: Strengths — massive docs, localized facts. Engineering burden & limits — recall precision; may miss context.

GraphRAG: Strengths — relationship exploration, global themes. Engineering burden & limits — extraction & disambiguation; wrong relations propagate.

PageIndex: Strengths — long-doc cross-chapter evidence. Engineering burden & limits — tree building & reading; multi-step queries slower.

LLM-Wiki: Strengths — reusable knowledge, exploration, creation. Engineering burden & limits — large-scale maintenance heavy; update & read costs.

Fusion 1: Vector Finds Entry, Graph Expands Relations

Keyword + semantic vector search locates relevant entities/chunks; then graph walks sourced relations to expand context, optionally rerank. Alternatively, parallel recall from chunks and graph, then merge/rerank (can include keyword search). Limit relation types and hop depth to avoid flooding context with distant neighbors.

Fusion 2: Vector Locates Document, PageIndex Enhances Reading

RAG pipeline or GraphRAG retrieves candidate documents; then supplement context as needed. Short docs read fully; complex long docs invoke PageIndex to locate relevant chapters and augment. Must align vector chunk metadata, graph node attributes, etc., to confirm document identity and tree index version consistency, avoiding search-read mismatches.

Fusion 3: Wiki Holds Core Knowledge, PageIndex Reads Long Docs, RAG Covers Long Tail

Division of labor: different tasks/subtasks route to different knowledge service pipelines.

Core, stable, frequently cited enterprise knowledge → Wiki/OKF (business rules, policies, metric definitions, reference manuals, SOPs).

Complex long documents → PageIndex for in-doc reading, location, context supplement.

Other massive, unstructured, fast-changing, occasionally queried info → RAG pipeline for fast service, optionally graph-enhanced.

Agent uses LLM router to pick tools; or dynamically decomposes large tasks into subtasks, queries each service, consolidates, synthesizes.

Example: AI Programming Context

Building an AI coding knowledge base for an industry app: existing curated Wiki, vector RAG pipeline, and syntax-tree-based code graph (Graph built without LLM). During a new feature design/development:

Enter via Wiki index, read business terms, rules, flows, system architecture.

Verify a metric definition or API change via vector RAG for quick fact retrieval.

Use code graph to discover module/code associations, analyze change impact scope.

Use PageIndex in a 100+ page interface spec to locate usage patterns, dev notes.

Output: verified design draft with citations, references, even page numbers. Verified, reusable design decisions can be written back to Wiki for knowledge accumulation.

Not every task needs all channels. Define routing/combination rules in AGENTS.md, or codify standard retrieval flows via Skills or frameworks like LangGraph.

Fusion 4: Wiki Feeds Other Modes

Query pipelines need not build from raw docs. Curated LLM-Wiki/OKF is structured, higher-quality Markdown — ideal input for RAG/GraphRAG. Build a vector RAG acceleration layer on top, validate chunking and recall; fall back to raw docs only when necessary.

Interlinked Wiki pages themselves form a document graph; extract entities/relations on this basis for deeper relationship exploration.

Final Caveat: Fusion expands retrievable needs but adds knowledge update/governance complexity: when raw content or permissions change, chunks, graph, wiki pages, and doc trees all need corresponding updates or invalidation — a serious test of engineering capability.

Open-Source Projects to Reduce Engineering Complexity

Microsoft GraphRAG: Entity/relation extraction, community detection, local retrieval & global summarization.

LightRAG: Fuses graph and vector retrieval, supports incremental maintenance.

PageIndex: Document tree navigation, provides indexing, retrieval, QA SDK.

OpenWiki (LangChain): Wiki compilation & maintenance, supports OKF output.

RAGFlow: Powerful document parsing; offers RAG, Wiki, PageIndex modes.

WeKnora: Tencent's knowledge engineering foundation, supports RAG, Graph, Wiki modes.

Follow-up articles will share practices based on these projects.