Ant Group RAG Interview: Vector, GraphRAG, LLM-Wiki, PageIndex & Ontology Fusion

What the Interview Question Tests

The interviewer's question "How is RAG designed now?" examines four layers: (1) boundary awareness — RAG is a paradigm, not a synonym for vector stores; retrieval includes graph, document-tree navigation, wiki page reading, all part of the broad RAG retrieval chain. (2) Failure analysis — each paradigm has explicit strength domains, failure domains, and hidden costs. (3) Engineering trade-offs — candidates must articulate which solution fails for which problem, the failure mechanism, and the fallback. (4) System governance — how paradigms coexist and are orchestrated.

Orthogonal Knowledge Framework

The author introduces a two-axis framework: a time axis (generational evolution) and a space axis (knowledge organization form and architectural layer).

Time Axis: Generational Evolution

First Generation (2023) : Core leap — Semantic: from keyword matching to vector retrieval. Members: Vector RAG.

Second Generation (2024) : Core leap — Structured: from fragment retrieval to structural organization. Members: GraphRAG (entity-relationship), PageIndex (document native structure).

Third Generation (Late 2024–2025+) : Core leap — Assetization & Contract: from retrieval to governance. Members: LLM-Wiki (pre-compiled knowledge assets), Ontology (semantic contract).

Space Axis: Knowledge Organization Forms

Semantic Chunk (shattered & reassembled) — Architectural Position: Retrieval Execution Layer — Members: Vector RAG.

Document Native Structure (chapter tree) — Architectural Position: Retrieval Execution Layer — Members: PageIndex.

Entity-Relationship Network (triples) — Architectural Position: Retrieval Execution Layer — Members: GraphRAG.

Pre-compiled Concept Page (OKF) — Architectural Position: Knowledge Asset Layer — Members: LLM-Wiki.

Semantic Contract Schema (TBox) — Architectural Position: Knowledge Contract Layer — Members: Ontology.

Combined coordinates yield:

Vector RAG: Gen1 × Semantic Chunk — retrieval execution bedrock, long-tail fact fallback.

PageIndex: Gen2 × Document Structure — retrieval execution structured branch, single-document deep-reading aide.

GraphRAG: Gen2 × Relationship Network — retrieval execution structured branch, multi-hop conduction mainstay.

LLM-Wiki: Gen3 × Pre-compiled Asset — knowledge asset layer "standard answer library".

Ontology: Gen3 × Semantic Contract — full-chain schema contract, single source of truth for governance.

Three core inferences: (1) Generations supplement, not replace; production architectures coexist with router scheduling. (2) Same generation different layers, different generations can share layer — GraphRAG and PageIndex both Gen2 but handle entity relations vs document chapters. (3) Dependencies point downward only — Ontology constrains all lower components; lower components feed raw materials upward; dependency arrows never reverse.

Five Paradigms Overview

Vector RAG : Core Unit — Chunk semantic blocks, parent-child chunks. Typical Business Scenario — FAQ, tickets, massive long-tail document queries. Explicit Engineering Cost — Embedding compute, vector DB tuning. Implicit Failure Risk — Semantic similarity ≠ factual relevance; cross-chunk dependency rupture.

GraphRAG : Core Unit — Entity nodes, relationship edges, community summaries. Typical Business Scenario — Supply-chain risk, fault root-cause analysis. Explicit Engineering Cost — LLM extraction, graph storage, disambiguation. Implicit Failure Risk — Extraction noise propagates along edges; hop-count explosion.

PageIndex : Core Unit — Chapter-tree nodes, heading anchors. Typical Business Scenario — Contracts, annual reports, compliance manual deep reading. Explicit Engineering Cost — Document parsing, anchor management. Implicit Failure Risk — Scanned PDFs fail directly; cross-document retrieval missing.

LLM-Wiki : Core Unit — OKF concept pages, aliases, versions. Typical Business Scenario — Metric dictionaries, SOPs, interface specs. Explicit Engineering Cost — Continuous compilation, conflict merge, lint inspection. Implicit Failure Risk — Knowledge staleness; multi-editor conflicts.

Ontology : Core Unit — Classes, object relations, data properties. Typical Business Scenario — Domain-wide terminology unification, extraction whitelist. Explicit Engineering Cost — Ontology iteration review, expert involvement. Implicit Failure Risk — Premature full-scale modeling; business detachment.

Analogy: Vector RAG = index-card retrieval; GraphRAG = relationship network drawing; PageIndex = table-of-contents extraction for close reading; LLM-Wiki = encyclopedia compilation; Ontology = cataloging rules.

Vector RAG (Gen1 × Semantic Chunks): Semantic Retrieval but Naturally Loses Global Dependencies

Production pipeline: document preprocessing, chunking strategy, semantic embedding, indexing, query preprocessing, multi-route hybrid retrieval, result fusion & reranking.

Production-grade hybrid retrieval code (ACL permission filtering front-loaded):

def hybrid_retrieve(raw_query, user_acl, top_k=20, rerank_threshold=0.6):
    queries = ontology_query_expand(raw_query)
    vec_hits, bm25_hits = [], []
    filt = {"acl": {"$in": list(user_acl)}, "valid_before": {"$gt": now()}}
    for q in queries:
        qv = embedding_model.encode(q)
        vec_hits += vector_db.search(qv, k=top_k, filter=filt)
        bm25_hits += bm25_index.search(q, k=top_k, filter=filt)
    fused = reciprocal_rank_fusion(vec_hits, bm25_hits)
    unique = deduplicate_by_chunk_id(fused)
    reranked = reranker_model.rank(raw_query, unique)
    return [x for x in reranked if x.score >= rerank_threshold][:5]

Three high-frequency pitfalls:

Chunking is essentially a dependency-boundary problem. Too small → cross-chunk preconditions split; too large → noise increases. Mainstream solution: parent-child chunking — child chunks for recall, parent chunks carry full context.

Similarity ≠ Relevance. Embedding captures surface semantic distribution; must rely on ontology synonym dictionaries, reranker models, post-hoc fact verification as safety nets.

Permission isolation is the demo-vs-enterprise divide. ACL filtering must sit inside the retrieval operator, not post-recall, otherwise privilege-escalation risks exist.

Vector RAG is the baseline bedrock: highest throughput, simplest maintenance, suits long-tail queries. Fails rapidly when needing to stitch scattered fragment dependencies.

GraphRAG (Gen2 × Relationship Network): From Finding Fragments to Relationship Conduction

Microsoft GraphRAG separates offline index construction and online retrieval pipelines.

Offline Construction Pipeline

Document chunking → LLM entity-relation extraction → Ontology whitelist validation to filter illegal entities → Entity disambiguation → Graph construction → Leiden community clustering → Community summary generation.

Online Retrieval Two Paths

Local Search: Vector retrieval fetches seed entities, limited-hop neighbor expansion, links back to original chunks. Hard hop limit 1–2 hops.

Global Search: Directly recalls community summaries for macro induction; summaries only guide clues, cannot serve as factual evidence.

def graph_local_search(question, allowed_rels, max_hop=2, max_nodes=40):
    seeds = vector_search_entities(question, top_k=8)
    subgraph = bfs_graph_expand(
        seeds, max_hop=max_hop,
        allowed_rel=allowed_rels, max_nodes=max_nodes
    )
    chunks = fetch_origin_chunks(subgraph)
    return {"subgraph": subgraph, "source_chunks": chunks}

Four Production Pain Points

Uncontrolled extraction freedom causing noise contagion; entity disambiguation nightmare; incremental update cost extreme; global summary black-box hallucination.

GraphRAG is a relationship-enhancement plugin for vector retrieval, not a replacement. Forcing GraphRAG without clear entities or need for relationship conduction is over-engineering.

PageIndex (Gen2 × Document Structure): Respect Native Document TOC, Solve Single-Document Cross-Chapter Evidence Gathering

PageIndex philosophy: respect author's original writing order and chapter dependency logic. Contracts and spec documents' arrangement order itself embodies business logic.

Offline Tree-Building Pipeline

Document structure parsing → Build chapter tree → Node summary generation (only for deciding which chapter to read, not as factual material) → Index persistence.

Online Query Chain

Load navigation tree → LLM browses summaries to infer needed chapters → Fetch original text → Self-check supplement → Output answer with page-number anchors.

from pageindex import PageIndexClient
client = PageIndexClient(
    index_model="tree-builder-model",
    chat_model="navigator-model",
    max_read_pages=12,
    read_timeout=30
)
doc_id = client.submit_document(
    "contract-v2.4.pdf", version="v2.4",
    meta={"doc_type": "legal_contract", "acl": ["finance", "legal"]}
)["doc_id"]
answer = client.chat(
    "合同里的履约违约责任，和付款节点之间有哪些约束？",
    doc_id=doc_id
)

Hard Constraints

Strongly bound to single document — no cross-document navigation; depends on document structure quality — scanned PDFs fail directly; multi-round tool-call latency high; document version change requires index tree rebuild.

PageIndex positioned as close-reading aide, invoked after upstream router selects candidate long documents.

LLM-Wiki (Gen3 × Pre-compiled Assets): From Query-Time Retrieval to Pre-compiled Knowledge Assets

Vector RAG, GraphRAG, PageIndex all dynamically retrieve raw evidence at query time; LLM-Wiki compiles raw evidence into standardized knowledge pages at ingestion, query phase reads compiled artifacts directly.

Three-Layer Architecture

Raw Layer: Original fact sources, permanently retained; every Wiki conclusion must carry provenance links.

Wiki Layer: OKF-format standardized concept pages — YAML front-matter metadata + Markdown body + bidirectional cross-links.

Schema Layer: Ontology constrains Wiki page types, fields, alias norms.

Core Operations

Ingest compile/update, Query read, Lint inspection. Lint scans broken links, expired versions, source invalidation, contradictory conflicts — key to preventing Wiki rot.

Enterprise OKF Page Example

---
id: order-failure-rate-v2
title: 订单失败率
type: metric
aliases: [OFR,履约失败率]
ontology_ref: metric.order_failure_rate
sources:
  - path: raw/oms-spec-v3.2.md
    page_range: [18,22]
    updated: 2026-09-01
valid_period:
  start: 2026-09-01
  end: null
conflict_note: "和v1版本口径不同，v1统计含用户主动取消订单，当前版本剔除"
reviewer: business-op
review_status: passed
---
# 订单失败率
定义：统计周期内，支付成功订单中，最终履约失败订单的占比。
计算公式：履约失败订单数 ÷ 支付成功订单数
口径约束：
<strong>(1) 统计数据源：OMS order_state 字段；</strong>
<strong>(2) 排除场景：用户主动发起取消、支付超时关闭订单；</strong>
关联概念：[[支付成功订单口径]]、[[履约失败状态枚举]]、[[订单对账时效]]

Wiki Lint Simplified Code

def wiki_lint(pages):
    issues = []
    for p in pages:
        if source_changed(p["sources"]):
            issues.append({"page": p["id"], "type": "stale_source"})
        if broken_links(p["body"]):
            issues.append({"page": p["id"], "type": "broken_link"})
        if not ontology_aligned(p["title"], p["ontology_ref"]):
            issues.append({"page": p["id"], "type": "term_mismatch"})
    return issues

Two Fatal Challenges

Compilation explosion risk (only high-frequency stable knowledge enters Wiki).

Version conflicts & causal traceability (define authoritative source priority, auto-flag conflicts for human arbitration).

LLM-Wiki positioned as standard answer library; query chain reads Wiki first, falls back to lower retrieval pipelines on miss.

Ontology (Gen3 × Semantic Contract): TBox Skeleton, Global Semantic Contract

Ontology = TBox schema layer + ABox assertion layer.

TBox (Terminological Box): Defines what concepts exist, inter-concept relationships, allowed properties, axioms & constraints. Corresponds to Ontology: Classes, Object Properties, Data Properties, Axioms, Constraints. Stores rules & structure, not concrete data.

ABox (Assertional Box): Asserts specific individuals' class membership and inter-individual relationships. Corresponds to GraphRAG's LLM-extracted entity nodes, relationship edges, attribute values — e.g., "Supplier A supplies Part B", "Order O contains Product P" are ABox assertions.

Instances must obey class and property definitions. Ontology is the schema contract shared by GraphRAG, RAG, Wiki, PageIndex; it does not perform retrieval or store answers.

Ontology Five Building Blocks

Class concepts, Object Properties, Data Properties, Axioms, Constraints.

Supply-Chain Ontology YAML Example

id: supply_chain_ontology_v1.2
domain: 供应链履约域
classes:
  Supplier:
    attrs: [supplier_id, tier, region, audit_status]
    enum:
      tier: ["A","B","C"]
      audit_status: ["passed","pending","reject"]
  Part:
    attrs: [part_no, spec, unit]
  Product:
    attrs: [sku, category]
  Order:
    attrs: [order_id, amount, status]
    enum:
      status: ["created","paid","fulfilled","failed","cancelled"]
object_properties:
  supplies:
    domain: Supplier
    range: Part
    card: N:M
  consists_of:
    domain: Product
    range: Part
    card: 1:N
  contains:
    domain: Order
    range: Product
    card: N:M
axioms:
  - "supplier_audit_status == reject ⇒ 不允许建立supplies关系"
  - "is_indirect_supply 是 supplies 的传递闭包"

Extraction Validation Pseudocode

def validate_extraction(entity, relation, ontology):
    if entity.type not in ontology.classes:
        return False
    if relation.name not in ontology.allowed_relations:
        return False
    if not ontology.check_domain_range(relation):
        return False
    return True

Four-Layer Constraint Capabilities

Constrains GraphRAG extraction denoising — filters illegal entities & relations.

Unifies terminology across full chain — eliminates same-word-different-meaning.

Rule reasoning completes implicit relations — transitive closure auto-computes indirect impact chains.

Governance single source of truth — business caliber change in one place, full-chain awareness.

Landing Pitfall Avoidance

Start with Minimum Viable Ontology (MVO) — dozens of classes suffice for early stage. LLM assists candidate concept mining, experts review & finalize.

Fusion Orchestration: Scenario-Driven, No "Best" Only "More Suitable"

Five paradigms not nailed to single scenario; instead matched by business scenario to paradigm combos.

Scenario 1: High-Frequency Stable Knowledge Query

Typical questions: "How is order failure rate calculated?" "How to handle refund interface timeout?"

Paradigm combo: Wiki first → on miss fall back to Vector RAG → output aligned with Ontology verification.

Key constraint: Wiki pages must carry provenance links; final answer back-links to original text. Ontology enforces terminology unity.

Scenario 2: Long-Document Cross-Chapter Evidence Gathering

Typical questions: "What constraints exist between performance breach liability and payment milestones in the contract?" "What is the R&D expense capitalization policy in this annual report?"

Paradigm combo: Upstream Vector/Graph locks candidate documents → PageIndex single-document close reading → Ontology verifies output terminology.

Key constraint: Strongly validate document version ID to prevent retrieving v2 but reading v1 TOC. PageIndex summaries only for navigation; facts must read original text.

Scenario 3: Multi-Entity Relationship Conduction & Risk Analysis

Typical questions: "Which products affected if Supplier A fails?" "Through which services does this error code propagate?"

Paradigm combo: Vector recall seed entities → GraphRAG limited-hop expansion → Ontology whitelist filters illegal edges → back-link original chunks for verification.

Key constraint: Hard hop limit 1–2 hops; beyond 3 hops context explodes. Community summaries only guide clues; final conclusion must back-link original chunks.

Scenario 4: Massive Heterogeneous Document Long-Tail Queries

Typical questions: "How to reset password?" "What does this error mean?"

Paradigm combo: Vector RAG hybrid retrieval (BM25 + vector + metadata filtering) → Rerank → Ontology synonym expansion fallback.

Key constraint: ACL permission filtering front-loaded, not post-recall. Parent-child chunking solves dependency-boundary problem.

Scenario 5: Knowledge Change & Full-Chain Governance

Trigger: Source document change event.

Execution chain: Ontology identifies affected concepts/entities → Broadcast invalidation signals → Vector chunks marked stale, graph entities marked for re-extraction, PageIndex trees marked expired, Wiki pages marked for review → Local incremental rebuild → Ontology axiom verification → Verification failure blocks release.

Key constraint: Incremental rebuild not full refresh. Ontology is governance single source of truth; business caliber change only modifies Ontology, broadcasts outward.

Scenario–Paradigm Mapping

High-frequency stable knowledge query : Primary — Wiki; Auxiliary — Vector RAG fallback; Unneeded — GraphRAG, PageIndex.

Long-document cross-chapter evidence : Primary — PageIndex; Auxiliary — Vector/Graph for document screening; Unneeded — none.

Multi-entity relationship conduction : Primary — GraphRAG; Auxiliary — Vector seed recall, Ontology whitelist; Unneeded — PageIndex, Wiki.

Massive long-tail queries : Primary — Vector RAG; Auxiliary — Ontology synonym expansion; Unneeded — GraphRAG, PageIndex, Wiki.

Knowledge change governance : Primary — Ontology; Auxiliary — Full-chain cascading invalidation; Unneeded — none.

An agent session dynamically switches scenarios. Example: Requirements design — first query Wiki for architecture specs (Scenario 1), then read interface whitepaper via PageIndex (Scenario 2), assess impact scope via GraphRAG (Scenario 3), finally persist new caliber back to Wiki (Scenario 5).

Summary by Architect Nien

Enterprise-grade RAG is essentially a heterogeneous knowledge retrieval bus. Vector, Graph, Document Tree, Wiki, Ontology each play their role, dynamically scheduled by business scenario; Ontology provides global semantic constraints; governance pipeline ensures full-chain consistency.