Document Parsing as the Retrieval Bottleneck

Sources#

• Beyond RAG: Building Agentic Document Workflows with LlamaIndex

Summary#

Pierre-Loic Doulcet (LlamaIndex, AI Engineer Singapore 2026, 116 slides, practitioner-opinion) traces three years of RAG practice to a single chain of bottlenecks:

The bottleneck is retrieval, not generation. Inside retrieval, the bottleneck is parsing. Inside parsing, it's losing the document's structure. Most of the tuning effort goes into the model. Most of the wins are upstream of it.

The talk's structure is the argument: name the 2024 failure taxonomy, show which entries became routine engineering by 2026, and observe that the residue is concentrated at the first step of the pipeline — turning a PDF into text an agent can read. Its closing line is the compact version: "the bottleneck moved upstream. Out of the model, out of the retriever, into the document."

Evidence and COI, stated once and applying to everything below. This is a vendor talk. LlamaIndex sells the parser (LlamaParse), the managed pipeline (LlamaCloud), and publishes the benchmark (ParseBench) on which its own parser leads. Every quantitative claim on this page is either (a) a third-party number the deck cites, (b) a LlamaIndex number, marked as such, or (c) an unsourced practitioner assertion, marked as such. The deck opens by disclaiming itself — "almost everything here will be wrong by 2027; the half-life of 'best practice' in this stack is under a year" — which is the right weight to give the specifics. The taxonomy and the cascade direction are the durable part; the technique rankings are a 2026 snapshot.

The 12 pain points, and why the cascade matters more than the list#

The 2024 baseline the deck takes as given is Wenqi Glantz's 12 RAG Pain Points and Proposed Solutions (Towards Data Science, 2024) — 7 drawn from the Barnett et al. paper, 5 from production. Glantz's figure (viewed; it is a pipeline diagram, not a list) places each failure at the stage that produces it: an index process (documents → chunker → chunks → database) carrying missing content and data-ingestion scalability, and a query process (query → rewriter → retriever → reranker → consolidator → reader → response) carrying missed top-ranked, not in context, not extracted, wrong format, incomplete, incorrect specificity. Four sit outside the pipeline as cross-cutting concerns: structured-data QA, complex PDFs, fallback models, LLM security.

The deck's contribution is to re-cluster them by who corrupts whom (figure viewed):

Cluster	Pain points	Relation
Parsing	complex PDFs	↓ corrupts ↓
Retrieval	missing content · missed top-k · consolidation · specificity · incomplete	↓ corrupts ↓
Synthesis	not extracted · wrong format	—
Adjacent, non-cascading	structure (tabular QA) · scale (ingestion) · ops (fallback · security)	independent

The load-bearing claim: parsing is 1 pain point of 12, but its errors propagate into 7 of the others — and they arrive downstream wearing a retrieval or synthesis costume. A table flattened to one line produces "right page, wrong row, wrong column, wrong year", which presents as a synthesis failure (the model misread the chunk) and is actually an ingest failure (the chunk no longer encodes which number belongs to which column). This misattribution is the reason the deck says the 2024 fixes — better prompts, more few-shot, tuned top-k, tweaked chunk size — were aimed at the wrong layer: "all of these treat the synthesizer as the thing to fix."

What became routine engineering (2024 → 2026)#

The deck's ROI ladder, ordered as it presents it, with the instruction to adopt top-down and stop when done ("most teams need 1–3, not all five").

1. Cross-encoder reranking — "no other knob has this ratio." A second pass that re-scores candidates with a model that reads query and document together, rather than comparing pre-computed embeddings. Stage 1 retrieves wide for recall (bi-encoder, top 50, ~5ms over 10M docs); stage 2 reorders for precision (cross-encoder, 50 pairs, ~100ms) and keeps 5–10. The two model classes are not substitutes — the bi-encoder structurally cannot see the pair, which is where negation, scope and qualifiers get lost. Claimed lift +4 to +14 nDCG@10 at a few hundred ms. The cited grounding is mixed-tier: the BEIR/sentence-transformers result (largest cross-encoder beats the best bi-encoder by ~+4 nDCG@10 on average, up to +12 on a single dataset — gooaq-dev 59.12 → 71.35) is third-party; the paired figure (Voyage rerank-2.5 at +7.9% nDCG@10 over Cohere rerank-v3.5 across 93 datasets, +12.7% on MAIR) is a vendor blog claim from the winning vendor. Kills pain points 2, 3, and partially 6.

2. Query rewriting — demoted. HyDE (draft a hypothetical answer, embed that, search — closes the user-speak/document-speak dialect gap) and multi-query + Reciprocal Rank Fusion (N phrasings, retrieve each, fuse by rank — closes the angle gap) were the 2024 pre-agent tricks. The deck's verdict: both are subsumed by agentic loops, because an agent that grades and rewrites does this dynamically and recovers when the first attempt misses. Kept as historical literacy — "you'll see HyDE and QueryFusionRetriever in 2024-era code."

3. Agentic / corrective loops — "second highest ROI." CRAG (Yan et al., 2024) is the canonical shape: retrieve → grade each chunk before generation → branch (high confidence → synthesize; ambiguous → refine chunks and retry; low → reformulate or fall back to web search). The mechanism the deck emphasizes is that the grader decouples retrieval quality from generation: vanilla RAG always generates, so bad chunks become confident hallucinations; the grader is "a circuit breaker on the pipeline." Deliberately cheap — a small model scoring (query, chunk) pairs, same input shape as a reranker, emitting one confidence number rather than a judgment. Kills pain points 1, 4, 7. Costs +1–3 LLM calls and 2–4× P50 latency, and the deck is unusually explicit about when not to pay it: skip when the head of the query distribution is still broken, when the latency budget is under 2s, when you have no eval (the loop will hide regressions), and when "the 'loop' is really just a retry that masks a bug."

The squeeze on hand-rolled loops, from both sides. Adaptive-RAG (Jeong et al., NAACL 2024) routes by complexity with a small classifier — no retrieval / single-hop / multi-hop — on the observation that most queries don't need a loop at all. Search-R1 / R1-Searcher (2025) train the model to call search() mid-reasoning, so the loop ends up inside the weights. Speculative RAG (Wang et al., Google, 2024) parallelizes instead: small drafters generate N answers from disjoint chunk subsets, a larger verifier picks one. The deck's summary — "hand-rolled CRAG is getting routed away from below and absorbed into the model from above; the workflow shape sticks around, what runs inside each step keeps changing" — is the retrieval-layer statement of Harness Shrinkage as Models Improve.

4. Multimodal caption-and-index. Vector search embeds text; the load-bearing content of a 2026 enterprise document is often the picture. Two-stage fix: at ingest a VLM captions each figure and the caption is indexed alongside surrounding text; at synthesis the original image is fetched and handed to the model. Explicitly not image embeddings — "CLIP lives in a separate space: two pipelines, no shared reranker; captions stay in the text space." Two operational notes: caption quality is the bottleneck (name axes and units, not "a bar chart showing data"), and never paraphrase what the VLM can read at answer time.

5. Structured data — query, don't embed. A table embedded as text loses its shape: rows become sentences, columns become noise, aggregates become impossible. "Top 5 vendors by 2025 spend in APAC" finds the table about vendors and cannot filter, group, or rank it. The fix is a router: index the schema plus sample rows so the model knows the shape, send table-shaped questions to a query language (JQ for JSON, SQL for relational, Cypher for graphs) and prose-shaped questions to vector retrieval, merge in synthesis. The line worth keeping is the honest one: "the router is the work. Most teams skip it. It's what makes it work." The default heuristic offered is crude on purpose — number / list / filter → query; summary → retrieve.

(Annexed as conditional rather than default: Graph RAG when traversal literally is the answer and the entity/relation schema is stable — "adopt because eval says single-hop misses, not because it's interesting", budget 2–3× vanilla latency, and the hidden cost is that bad entities produce bad edges produce wrong traversals. Multi-grain indexing — index sentence, section and page level, route or rerank across them, "3× storage, vectors are cheap, pay it". Incremental upserts plus content-hash dedup quietly retire the ingestion-scalability pain point; "most teams still run batches out of habit.")

Three frame shifts#

Retrieval, not generation. 2024: "the model hallucinated" → try a bigger model. 2026: "retrieval handed it the wrong chunks" → fix parsing, chunking, reranking. The supporting figure — naive RAG failing at retrieval ~40% of the time — is asserted without a citation and should be treated as a practitioner's order-of-magnitude, not a measurement. The prescriptive version is the sharpest slide in the deck, a budget comparison rather than an argument: where to spend the week — 2d parsing + chunking, 2d retrieval + reranking, 1d synthesis prompts, 0d the model — against what most teams actually do — 0d parsing, 1d retrieval, 2d synthesis prompts, 2d switching models.

Long context did not kill RAG — the 2024 prediction that didn't land. The prediction was that 1M-token windows would make retrieval a workaround for small context. "Windows shipped. Retrieval grew. Stuffing the corpus lost, decisively." Three reasons, and only the first is about tokens: cost (1M tokens per query at frontier rates; caching helps, the arithmetic still fails for any nontrivial corpus); governance (stuffing means stuffing documents the requester should not see — "'model promised to ignore' is not a boundary"); and auditability — "'Why did the AI say this?' Retrieval gives a citation log. Long context gives a vibe." The reframe is the useful part: retrieval turned out to be the audit trail more than a capacity workaround, which means it survives even if context becomes free.

Eval is its own stack. 2024: a notebook, ten hand-written questions, eyeball, ship. 2026: production queries → sampled eval set → triad scoring (faithfulness · relevancy · recall) → regression gate on every deploy, with tracing and replay (RAGAS, DeepEval, Langfuse, Phoenix). Two rules carried: don't use the same model to generate and grade — "it agrees with itself" (see LLM-as-a-Judge), and don't only eval the questions your system already answers well — keep an explicit long-tail suite. The closing formulation: "if you can't measure whether a change helped, what you have is a demo rather than a system."

The six ways a parser destroys a document#

The deck's central section, walked one failure per slide against a single hostile source (a bank annual report). Each is paired with the pain point it detonates downstream:

Failure	What survives	Downstream
1. Multi-column flattened	two unrelated sentences spliced word-by-word ("Net interest income The Group continued to deliver strong rose 8% as deposit growth across…")	embeddings carry junk neighbourhoods; retrieval surfaces text that does not exist in the document
2. Tables → pipe-soup	headers detach from rows, numbers lose units, a row label welds to the next row's numbers	PP 4 — "right page, wrong row"; the agent confidently pulls a value from the wrong line
3. Footnotes inlined	the qualifier reads as the next sentence; the number becomes context-free	the agent quotes a figure as headline growth with no idea a one-time gain is excluded
4. Charts dropped	the caption, maybe; often only legend strings ("FY21 FY22 FY23 FY24 FY25")	PP 10 — any question whose answer is in the chart fails silently
5. Headers/footers pollute	every chunk inherits the same document title and page furniture	every embedding pulled toward one centroid; cosine similarity collapses; PP 2 at the top-k boundary, and the reranker spends its budget separating near-duplicates
6. Reading order broken across pages	chunk A ends mid-clause, chunk B starts mid-clause, each embedded alone; a table's rows separated from its header	PP 3 and PP 4, both lit up by one page break

The instruction attached: "pick any production PDF you haven't personally inspected. At least one is happening." The 2024 baseline being indicted is PyMuPDF / pdfplumber — "free, fast, surprisingly OK on simple documents; on an annual report, a contract, a regulatory filing, bad," because the output is one string in roughly reading order, which on a multi-column page is the wrong order.

These slides are self-demonstrating in this vault's copy of the source, which is the sharpest available proof of the claim. The deck screenshots the corrupted output; our own parse then OCR'd those screenshots, so the raw file contains failure modes 1, 2 and 5 as literal unreadable garble. Nothing in it may be cited as data — see the parse caveat in Beyond RAG: Building Agentic Document Workflows with LlamaIndex — but the demonstration survives the round trip intact.

The fix stack: spatial text → Markdown → structure-aligned chunks#

Spatial text is the missing primitive. "A PDF isn't really a string of text. It's a set of spatially positioned tokens on a 2D canvas — each with x, y, width, height, font, style." Keep the coordinates through parsing and every downstream layer can still reason about layout: group by y → rows, group by x → columns, group by region → sections. What that buys, stated as capabilities rather than quality: recoverable table structure, region filters that drop headers/footers without regex hacks, citations that resolve to a bounding box you can highlight, and a VLM handoff — when text isn't enough, fall back to the page screenshot at the same coordinates. LiteParse (Apache 2.0, local, no LLM, no cloud) is the reference implementation.

Markdown is what you hand downstream. "Spatial text preserves geometry; Markdown preserves structure" — heading hierarchy, table grids with headers attached, lists, footnotes bound to their anchors, figures with captions. One artifact, three uses: flatten for legacy embedders, parse as a tree for layout-aware chunking, render for humans. And the underrated reason: every frontier model is already trained on Markdown — the syntax is the signal, so no prompt engineering is needed to explain "this is a table."

Chunking along structure, not length. The 2024 answer (512 tokens, 50-token overlap, recursive splitter) is described as "always wrong — just a defensible default; it pretends the document is a string." The 2026 answer: a section is a chunk, a table is a chunk, a figure-plus-caption is a chunk, a footnote stays attached to its anchor. The dependency is the point — structural chunking is only available if the parser kept the structure, which is why chunking migrated out of the retrieval section of this talk and into the parsing section. This also dissolves pain point 6 (incorrect specificity), whose root cause is that a corpus is chunked once at a single grain while question grain ranges from "one number" to "the whole report."

Metadata is half the chunking story. Document title, section path, page, source URL, ingest timestamp, permissions, parser version, confidence — earning three things a chunk otherwise cannot do: filter at retrieval by predicate rather than by vector, cite at synthesis with a path the user can click, and replay any historical answer by knowing which parser produced it.

Extract vs parse. Schema-first extraction (define a Pydantic model, get validated typed JSON with per-field page + bbox citations) when you know what you want, the fields are the same across documents, and downstream is a row or a form field. Parse + retrieval when you don't know what you want and the question shapes have a long tail. "Most real systems use both."

Parsing is a stage, not a step. You will reparse, re-extract with new schemas, and need to rerun retroactively when the parser improves — so store the raw document, store every intermediate, make parsing idempotent. The annex generalizes it to version everything (parser, prompts, index, schemas): "'we changed the parser on Tuesday and accuracy dropped 8 points on Wednesday' is only debuggable if Tuesday's parser is still reachable."

ParseBench, and a figure that undercuts its own caption#

LlamaIndex's parsing benchmark (2026, arXiv 2604.08538, ~2,000 human-verified enterprise pages, released as a Hugging Face dataset for open-weight models and a Kaggle competition for frontier ones, same harness so the numbers are comparable). Its design choice is the transferable part: scored on semantic correctness rather than text overlap, across five dimensions each chosen for what a downstream agent depends on — tables (structural record matching, rows × columns recovered), charts (exact data-point verification: axes, values, series), text completeness (no drops, no hallucinations), text styling (headings/lists/emphasis as semantic structure), and bbox grounding (every extracted element points back to a page region). The deck's own warning about it is the correct one to carry: "check before you ship — the numbers will be lower than the vendor quotes."

The cost-vs-accuracy figure was worth viewing, because the slide prose misreads it. The text claims "frontier VLMs (GPT-5 Mini, Haiku 4.5) sit in the low-40s — premium price, generalist accuracy," positioning LlamaParse Agentic (84.9%, ~1.2¢/page) and Cost-Effective (71.9%, ~0.4¢) as the Pareto frontier. The figure (Fig. 5, ~14 methods) shows those two points as claimed — and also shows Gemini (high) near 76% at ~2.4¢ and Gemini Pro near 69% at ~8.4¢, with GPT-5.4 near 62%. The "low-40s" characterization is true only of the cheapest frontier tiers (GPT-mini variants, Haiku 4.5 non-thinking). The honest reading of the vendor's own chart is that a general frontier VLM at its high setting lands within ~9 points of the specialist parser at roughly 2× the per-page cost — a much narrower gap than the prose implies, and one that Harness Shrinkage as Models Improve predicts will keep narrowing. The deck's structural point survives the correction and is the one to keep: most of the accuracy-cost curve is flat, and parsing errors compound through every stage that follows, so upstream is where marginal budget belongs.

Where the agent layer lands: workflows over chains#

The deck's answer to "what do you wire around a document the agent can actually read" is LlamaIndex Workflows — an event-driven graph in which typed events are the architecture. Treated on Crystallizing Agent Work into Workflows, which holds the workflow-shape material (typed events, declarative fan-out/fan-in, HITL as a durable event rather than an exception, observability falling out of the event stream) alongside Malik's account of when agent work should become a workflow at all. The deep-research form factor — decompose into sub-questions, fan out parallel retrievals, fan in to compose a cited answer, described here as "a tree of agentic retrieval, not a loop" — is on Deep Research Agents.

This vault is an instance of the argument#

Uncomfortably direct, and worth recording because it converts the deck from advice into a description of practice already running here:

• Failure mode 2 is this vault's documented parse defect. _system/compiler-prompt.md's table-collapse and table-shift rules describe exactly the pipe-soup failure — a spanning label merging a group of rows into one cell, or a row label sliding into a numeric column — and the audit trail records that the wiki's only known wrong number came from a shift. The deck's downstream diagnosis ("right page, wrong row; the agent confidently pulls a value from the wrong line") is the same failure named from the consumer's side.
• The standing habit matches the deck's own advice. "Quote figures from prose and figure captions; treat table rows as needing reconciliation first" is the operational form of the structure is what gets lost, arrived at independently from seven of eight suspect sources turning out clean.
• The image two-pass rule is caption-and-index run at compile time, with a human-grade captioner. This page is a worked example: the pain-point cascade, the CRAG branch, the parallel fan-out shape and the ParseBench cost curve all live only in slide images, and the ParseBench prose/figure discrepancy above was recoverable only by viewing the figure.
• The canary the vault lacks and the deck's benchmark has. canary-recall samples prose tokens after the fact; ParseBench's bbox-grounding dimension and LlamaExtract's per-field page+bbox citations both bind an extracted value to a page region at extraction time — the difference between checking whether something survived and being able to point at where it came from. Same gap Layerwise Omission Attribution identifies at L0.

Connections#

• Layerwise Omission Attribution — the same failure, formalized one abstraction up. "OCR table-structure loss" is the first mechanism listed under Rajan's L0 (source/ingestion) layer, and this page is the practitioner's expansion of that single cell into six named failure modes with their downstream consequences. The two supply what the other lacks: Rajan supplies the method — canary taps at every pipeline boundary make an L0 loss exactly countable with no judge — while this supplies the mechanisms and, crucially, the observation Rajan's layered accounting predicts but does not state, that an L0 loss is systematically misattributed downstream: a collapsed table presents as an L5 mid-context miss or an L7 decoding error. Doulcet's "parsing is 1 of 12 but propagates into 7" is the cascade version of the same warning, and the reason the fixed layer order exists at all
• LLM-as-Compiler Knowledge Base — the strongest opposing view in the corpus, and the disagreement is narrower than it looks. Karpathy's architecture replaces retrieval with compilation; this deck argues retrieval survives even a free 1M-token window because it is the audit trail ("retrieval gives a citation log, long context gives a vibe"). Both, however, locate the same irreducible risk at the same place: the compile-time-loss limit — "an early summary removes a detail from the source, and each later answer has that error" — is this page's structure loss, one layer later. The compiled wiki pays the parsing tax once and permanently; a retrieval pipeline pays it per query but can be reparsed when the parser improves, which is precisely what "parsing is a stage, not a step" buys and a compiled artifact forfeits
• Deep Research Agents — the form factor this pipeline feeds, and the one most exposed to its failures. DRACO graded factual accuracy as the weak axis at the output; this names the upstream cause the grading cannot see, since an omitted or misattributed figure in a cited report may have died in the parser rather than the planner. The convergent design point: the deck's deep-research workflow threads citations through every step for the same reason DRACO scores them, and the deck's insistence that a chunk cite back to page and bbox is what makes the citation checkable rather than decorative
• Crystallizing Agent Work into Workflows — where the deck's Part V lands. Malik supplies the lifecycle (when agent exploration should become a fixed workflow); Doulcet supplies the shape (typed events as the contract, durable context, human review as an event). They agree on the boundary condition from opposite directions — "when NOT to use a workflow: if the task is a single Q&A over a single document, a function will do" is Malik's Type 3 admission criterion stated as a warning
• Agentic Prompt Injection — pain point 12 as a retrieval-pipeline problem: "retrieved content is untrusted input; treat every retrieved chunk like a form field a user typed." The deck's contribution is where in the pipeline the defenses belong — strip or flag directive-shaped text at ingest, not at synthesis; put authz metadata on the chunk and filter at retrieval rather than sharing an index across tenants; constrain the tool surface so no agent that retrieves can also exfiltrate; and maintain a red-team corpus of documents with embedded payloads that runs against every release like an eval set
• Context Lifecycle Management — the same information-preservation question at the other end of the pipeline. Structure loss at parse time and condensation loss at compaction time are both silent, both invisible in the trace, and both are attacked by keeping a recoverable representation rather than a smaller one — spatial text with bboxes on the ingest side, sidecar storage with stable object ids on the runtime side
• LLM-as-a-Judge — the eval frame-shift's operative rule, "don't use the same model to generate and grade; it agrees with itself," asserted here as practitioner advice and carried there with the audit evidence behind it
• Harness Shrinkage as Models Improve — the retrieval-side statement of the same trend, and the deck states it explicitly: as models improved, logic migrated into the agent loop and the retrieval layer got simpler (hand-written HyDE and multi-query rewrites subsumed by an agent that grades and retries; CRAG absorbed into the weights by Search-R1). The residual is the counter-datum: the layer that did not shrink is the one outside the model's reach — a parser is deterministic software operating on bytes the model never sees
• Verification as the New Bottleneck — why bbox grounding is the interesting ParseBench dimension: an answer citing page and region is checkable by a human in seconds, while an answer citing a chunk id is checkable only by trusting the pipeline that produced it
• LlamaIndex — the vendor behind the deck, its parser/extraction/workflow stack, and the benchmark it publishes
• FastContext — the same decoupling one domain over: retrieval/exploration separated from solving, with the explorer paying the search cost in a disposable window
• Authority and Audit Survive Abundance — the audit-trail question answered: cost is the only leg of this page's long-context defense that token price dissolves; per-chunk governance and citation-log audit are boundary-and-record machinery that cannot move inside the window they police

Open Questions#

• Does the "parsing errors propagate into 7 of 12 pain points" cascade hold up under measurement rather than assertion? Layerwise Omission Attribution supplies the instrument — canary taps make an L0 loss exactly countable, and the (conflict − literal) needle contrast isolates downstream behavioral loss — so the falsifiable version is: on a fixed corpus, parse with a structure-preserving and a flat-text parser, hold every later stage constant, and attribute the delta in end-to-end failures by layer. Nothing in the corpus does this.
• How far has the specialist-parser advantage over general frontier VLMs actually narrowed? ParseBench Fig. 5 (a vendor-run benchmark) puts LlamaParse Agentic at 84.9% against Gemini at its high setting near 76%, at roughly half the cost per page. If Harness Shrinkage as Models Improve governs here as elsewhere, the specialist layer is a temporary tax on current VLM weakness; if bbox grounding and per-page cost predictability are structural, it is not. Falsifiable at the next frontier VLM release by re-running the same harness.

Resolved Questions#

• Is the audit-trail argument for retrieval strong enough to survive genuinely cheap long context? The deck's three reasons are cost, governance and auditability, and only cost is a function of token price. If a 1M-token window becomes ~free, does per-chunk permission filtering and citation-log auditability still force a retrieval layer — or do they become an attribution problem solvable inside the window? Answered: Authority and Audit Survive Abundance — yes, wherever the requirements it serves exist, because only the cost leg is token-priced. Governance survives by circularity: per-chunk permission filtering is per-call authorization at the retrieval boundary, and enforcement cannot live inside the window it polices ("'model promised to ignore' is not a boundary" is the in-band collapse the security corpus measured) — the window is the wrong trust domain at any price. Auditability survives because in-window attribution is model testimony where an audit needs a log produced outside the model — and a log without selection reads "everything," which attributes nothing: retrieval is the act that makes a citation log non-trivial. The scope conditions run the other way too: governance forces a retrieval layer only where principals > 1, audit only where accountability is required, and the leg this page's "~free" premise prices too generously is capability (Context Window Smart Zone's effective-ceiling/refusal evidence) — the one leg made of current model limitation rather than structure. The requirement also binds the compiled-wiki rival: compilation and retrieval are both selection-with-a-record, and corpus-stuffing is the only architecture the audit leg eliminates outright.

Sources#

• Beyond RAG: Building Agentic Document Workflows with LlamaIndex — Pierre-Loic Doulcet (@hexapode, LlamaIndex), Beyond RAG: Building Agentic Document Workflows with LlamaIndex, AI Engineer Singapore 2026, 116 slides / ~90 min, published 2026-05-18 and released 2026-05-25 via a Jerry Liu (@jerryjliu0) X thread merged into the same raw file (practitioner-opinion; direct vendor COI — LlamaIndex sells LlamaParse/LlamaCloud and publishes ParseBench, on which its own parser leads). Parse warning, unusually consequential here: the deck screenshots deliberately-corrupted parser output as demo material, and our docling pass then OCR'd those screenshots, so Tables 3–5 (the DBS annual-report extracts) and the surrounding mangled prose are unreadable by design — cite them only as examples of corruption, never for a number. The table-collapse warn is a false positive (the agenda row's literal text 2024 → 2026); canary-recall 5/5. Image two-pass applied and load-bearing: Glantz's 12-pain-point pipeline diagram, the parsing→retrieval→synthesis cascade figure, the bi-encoder/cross-encoder cascade, the CRAG grade-and-branch tree, the caption-and-index flow, the structured-data router, the send_event/collect_events fan-out shape, the contract-review event graph, the durable-HITL pause, and ParseBench Fig. 5 exist only as images; the ParseBench prose/figure discrepancy recorded above was recoverable only by viewing the figure. Logo-wall OCR noise (CCMCX, Opepsi, MIcheliN, tabst) is misreads, not entities; the repeated 9f98de06… image is a slide-template background