-
Notifications
You must be signed in to change notification settings - Fork 1
Extraction Retrieval Co Design
type: synthesis up: "Markov-Retrieval-Tutorial" tags: [architecture, extraction, retrieval, design-principle] related: ["Heterogeneous-Graph", "Vanilla-RAG-Failure-Mode", "Bridge-Entity"] supports: "Markov-Retrieval-Tutorial"
The third of the tutorial's three claims: retrieval and extraction are not independent stages. The structure your retrieval can exploit is the structure your extraction chose to preserve.
The chain works because the graph exists. The graph exists because an extractor produced chunks, identified the concepts they mention, and populated co-occurrence statistics. If the extractor had produced flat text, there would be no graph. Therefore the choice of what to extract determines the answerable scope of the downstream system. A team that chooses the extraction schema in isolation forces retrieval to recover structure post-hoc through similarity heuristics, query expansion, and concept-boost re-rankers.
| What the extractor preserves | Retrieval ceiling |
|---|---|
| Chunk text and embedding similarity only | Vanilla RAG; fails on tail vocabulary |
| Chunks, documents, and concepts | Graph retrieval via random walk on a heterogeneous graph |
| Chunks, documents, concepts, and explicit concept relationships | Multi-hop reasoning over typed paths |
These are not aesthetic preferences. They are choices about which queries can later be answered well.
The DLA query partially succeeded in the tutorial: HoosierMetals was recovered, but the canonical defense cluster (ITAMCO and others) was not. The chain is not wrong here. The corpus has only one bridge entity, and one bridge cannot populate the connecting graph region with enough signal.
Two extraction-time fixes would have closed the gap without changing the chain at all:
- Canonicalize "DLA" to "Defense Logistics Agency" so they become the same concept node, not two weakly-similar ones.
- Tag procurement concepts as related to defense-prime concepts at extraction time, so the bridge edge exists in the graph rather than having to be discovered through co-occurrence.
The work is the same; the question is where in the pipeline it gets done.
The practical guidance the writeup offers:
- Talk to the people who will use the data before you finalize the schema.
- Ask what queries they expect to run.
- Ask what vocabulary those queries will be in.
- Ask what kinds of structural relationships will need to traverse.
- Design the extraction schema to anticipate retrieval rather than designing it in isolation and forcing retrieval to compensate.
Concept-boost re-rankers, query expansion, and similarity heuristics all live downstream of an extraction-time decision that could have closed the gap directly.
The tutorial is not just a retrieval demo. It is an argument about pipeline design. The chain is presented honestly, including its limits, because the limits are precisely where the extractor choices show through. See Tutorial Queries for the full set of findings, and the writeup's section 6 (in Tutorial PDF Summary) for the original framing.