Skip to content

Hierarchical retrieval and table ingest: two capabilities built and discarded, three quality gaps #14967

Open
2 of 9 issues completed

Description

@mrveiss

Problem

A review of AutoBot's document-ingest and hierarchical-retrieval paths found that
two capabilities we already pay for are being discarded before they reach retrieval,
plus three narrower quality gaps in how hierarchical summaries and tabular content are
built and embedded.

The two discard findings are the priority: in both cases the expensive producer is wired
and runs on every document, and no consumer reads the result. This is the "full surface,
no sink" class.

Confirmed findings (evidence in each child)

# Finding Class
1 RAPTOR tree summaries are created with an empty source_chunk_ids, so a node cannot cite the chunks beneath it correctness
2 context.raptor_tree is built per document and has no consumer — no loader, no retrieval path, not even a result counter unwired work
3 PDF tables are extracted on every PDF and dropped by every ingest path unwired work
4 Table rows lose their header binding when rendered for embedding retrieval quality
5 RAPTOR clustering discards document order retrieval quality
6 Refinement is linear, so multi-part questions cannot be covered retrieval quality

Children

# Issue Finding
1 #14968 RAPTOR nodes built with empty source_chunk_ids — uncitable by construction
2 #14969 RAPTOR tree built per document and discarded — no sink
3 #14970 PDF tables extracted on every PDF, dropped by every ingest path
4 #14971 Table rows lose header binding when rendered
5 #14972 RAPTOR clustering discards document order
6 #14973 Refinement is linear, not branching

Sequencing

These are two independent tracks plus one standalone — they do not form a single chain,
and the two entry points can be worked in parallel.

graph LR
  A["#14968<br/>RAPTOR provenance"] --> B["#14969<br/>RAPTOR sink"]
  B --> C["#14972<br/>order-aware clustering"]
  D["#14970<br/>PDF tables reach ingest"] --> E["#14971<br/>table header binding"]
  F["#14973<br/>branching refinement"]
Loading
Track Order Why this order
Hierarchical retrieval #14968 → #14969 → #14972 Provenance lands before the sink, because wiring a tree whose nodes cannot cite their sources would have to be redone. Clustering last: optimising a clusterer whose output is currently discarded is wasted motion.
Table ingest #14970 → #14971 Tables must reach an ingest path before how they are rendered can matter.
Standalone #14973 No dependency either way. Lowest priority — the two unwired-work findings are worth more.

Entry points: #14968 and #14970. Both are unblocked today.

Highest value first: #14969 and #14970 are the two findings where we already pay the
production cost and read nothing back. #14968 is sequenced ahead of #14969 only because it
is a precondition, not because it is independently valuable.

What this review found we already do well — do not "fix" these

Deliberately NOT proposed — do not re-raise

  • Vision-model layout classification (classifying page regions into header /
    footer / caption / reference / equation / table with a trained model). Rejected:
    it reintroduces exactly the silent-failure class our document layer was built to
    eliminate — a mis-detected region returns plausible text, so a bad parse reads as
    a bad answer rather than an error — and it adds model weights plus an inference
    budget to the ingest hot path. A positional heuristic for repeated first/last
    lines across pages is the cheap 80% and can be raised separately if header/footer
    dilution is ever measured as a real problem.
  • Unconditional scanned-page rotation retry (try four orientations, pick by OCR
    confidence). Rejected as a default: it is a 4x multiplier on precisely the resource
    media/document/ocr.py most carefully bounds. Acceptable only if scoped to pages
    that already produced no text and drawn from the existing page and document
    budgets — not worth filing until scanned-rotation failures are actually observed.
  • Replacing our graph ranking with a static global PageRank feature. Our
    personalised, per-query-seeded implementation is strictly stronger.
  • Adopting an external ingest/retrieval stack wholesale. The operational floor
    (a relational store, a cache, an object store, and a separate search engine, plus
    a host-kernel prerequisite, before any model loads) is a large regression against
    what we reach today on our existing stores, to acquire capabilities we mostly
    already have.

Acceptance criteria

Activity

  1. added this to the Backlog milestone on Sep 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: kb-retrievalWave 5 · cluster J — Knowledge-base retrieval qualityknowledge-baseragresearchumbrellaEpic/umbrella tracking issue grouping member issues

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions