The standard advice for enterprise search has settled into “just chunk it and embed it,” and it is wrecking the accuracy of our AI integrations. If you have ever built a documentation bot for a client and then watched it hallucinate a decimal point on a financial report, you know the feeling. The model is rarely the culprit. What your architecture is missing is Proxy-Pointer RAG.
Standard vector RAG is messy by design. It shreds documents into contextless fragments and hopes cosine similarity can put the meaning back together. It cannot. In structured documents such as technical manuals or legal contracts, structure is meaning, and throwing away the headings throws away the logic.
The anatomy of Proxy-Pointer RAG
I have been following the work on Proxy-Pointer RAG because it gets you surgical precision without the overhead of “Vectorless” systems. Rather than expensive LLM-navigated trees, it leans on five ordinary engineering techniques to keep the model grounded.
- Skeleton trees. Pure Python (or PHP if you are brave) parses the headings into a JSON hierarchy. No LLM calls, just the document’s own structure.
- Breadcrumb injection. Every chunk gets the full path prepended before embedding, for example AMD > Financials > Cash Flows.
- Structure-guided chunking. Text splits land on section boundaries and never cut across them.
- Noise filtering. A lightweight model such as Gemini Flash strips tables of contents and glossaries out of the index.
- Pointer-based context. The retrieved chunk works as a pointer, so the synthesizer gets the entire section instead of a 512-token fragment.
The original research on Proxy-Pointer RAG walks through how the components fit together. The short version is that metadata beats brute-force embedding.
The 100% accuracy threshold
In a recent stress test on 10-K financial filings from companies like Boeing and PepsiCo, this architecture hit a 100% accuracy rate across 66 complex queries. That includes multi-hop numerical reasoning, the kind that usually makes an LLM trip over its own feet. With the retriever selecting five nodes (K=5), every numerical value matched the ground truth, because the model had the full structural context.
That matters for modern AI agent architecture. When the retrieval layer is a black box, your agent is guessing. Move to a “glass-box” engine where every answer carries a structural trace, and the user has a reason to trust it.
Implementing structure in WordPress
WordPress already ships a skeleton tree that most developers forget about: the Gutenberg block structure. If you are building AI search over a large WP knowledge base, do not chunk the post_content string. Parse the wp_block metadata instead and keep the section boundaries intact.
<?php
/**
* Conceptual breadcrumb generator for WP Block structure
*/
function bbioon_get_block_skeleton( $post_id ) {
$post = get_post( $post_id );
$blocks = parse_blocks( $post->post_content );
$skeleton = [];
foreach ( $blocks as $block ) {
if ( 'core/heading' === $block['blockName'] ) {
// This is your structure anchor
$skeleton[] = strip_tags( render_block( $block ) );
}
}
return $skeleton;
}
Using the hierarchy your CMS already stores, you get a workable form of Proxy-Pointer RAG with no third-party dependencies. It also keeps the vector index lean and the synthesis bill low.
If AI plugin development is still fighting you, put the effort into context. A good retriever will do more for you than ten better models.
If Proxy-Pointer RAG work is eating your dev hours, I can take it over. I have been wrestling with WordPress and AI integrations since the early days, and I know where the bottlenecks hide.
Respect the document hierarchy
Documents are not flat bags of words, and production-grade accuracy means respecting the hierarchy they already have. Moving to Proxy-Pointer RAG does not take a big budget or a GPU cluster, just some careful engineering at the indexing stage. If the document has headings, use them.
