> TL;DR: The Wix team turned an enterprise knowledge base into a "skill tree," letting an LLM browse folders like a human instead of matching keywords like a search engine. No vector database, no embedding retrieval at query time—pure LLM reasoning for navigation—and it performs better.
---
1. A Concrete Scenario
Imagine you are a support agent. A user asks: "How do I convert my Wix sole proprietorship account to an LLC account?"
This spans three domains: account types, payment configuration, and legal entity management. Traditional RAG embeds the question, finds the "most similar" chunks, and returns Top-K. The problem: those chunks may all contain the keywords "sole proprietorship" and "LLC," but the truly critical piece of information ("account types cannot be changed directly; you must contact support") may be missing because of surface-level vocabulary mismatch.
Worse, the LLM consuming these fragments has no view of the overall structure of the knowledge base. It cannot know which topics it hasn't searched, cannot decide "this direction yielded nothing, try another," and cannot stitch documents from different departments into a complete answer.
This is the paper's "seeing trees, not the forest" problem—RAG makes the LLM a passive consumer of search results rather than an active explorer.
---
2. The Essence of Corpus2Skill: From Searching to Browsing
The paper's core insight is simple: instead of making the LLM search the corpus, let it browse the corpus.
Compile phase (offline, done once)
1. Embed + cluster: vectorize all documents and build a topic tree via hierarchical clustering 2. LLM summaries: at each level, the LLM writes summaries—top level is a skill catalog (SKILL.md), mid-level is a subtopic index (INDEX.md), leaves are the actual documents 3. Materialize as files: the output is not a database index but a set of human-readable Markdown files, organized like folders
Serving phase (online, per query)
The LLM agent, given a user question:
1. Sees the bird's-eye view—names and one-line descriptions of all top-level skills (~200 tokens) preloaded into context
2. Selects a skill—reads the corresponding SKILL.md to understand subtopic structure
3. Drills down—reads INDEX.md to see the document list
4. Fetches on demand—uses a get_document tool to read full documents
5. Backtracks or crosses over—switches branches if the current path is wrong, or collects information across branches for synthesis
The whole process is like finding material on a company wiki: scan the table of contents, click into relevant pages, go back if wrong, and lock onto the target.
---
3. Key Design: Progressive Disclosure
This is the smartest part of the system.
Preloading all navigation files would drown the context in thousands of summaries; preloading nothing makes the LLM blind. Progressive disclosure takes the middle path: show the LLM only the catalog (skill name + one-line description) for the first-level decision, then dynamically load a branch's details once the agent commits to it.
Two key benefits:
- Token efficiency: the LLM reads long documents only when necessary, keeping junk out of context
- Explainability: every decision is based on an explicit summary; the navigation path is transparent and auditable
- Dense Retrieval
- RAPTOR (hierarchical RAG)
- Multi-turn Agentic RAG
- Relatively stable enterprise knowledge bases (no real-time updates needed)
- Complex queries requiring cross-topic synthesis (not simple fact lookups)
- Teams already using Anthropic Skills API or similar infrastructure
- Real-time systems needing millisecond responses (LLM navigation requires multiple API round-trips)
- Frequently changing knowledge bases (every update triggers recompilation)
- Simple lookup queries (traditional vector RAG is faster and cheaper)
---
4. Why It Works: Experimental Results
On the WixQA benchmark (200 real enterprise support queries), Corpus2Skill beat:
Why does it win?
Traditional RAG retrieval is a one-shot deal—query → vector match → Top-K. If the first retrieval misses the key document, the LLM never sees it. Corpus2Skill's navigation is iterative exploration—the agent can detect a wrong branch and actively backtrack, and can see multiple related topics and synthesize across branches.
The paper shows two typical trajectories:
Direct navigation (4 steps): query → pick skill → pick subgroup → read document → answer Cross navigation (7 steps): query → pick skill → explore subgroup A → insufficient → switch to subgroup B → synthesize both → answer
This "trial-and-error + synthesis" capability is something black-box retrieval cannot provide.
---
5. An Honest Look at Limitations
The paper devotes a full section to failure analysis—which is itself commendably scientific.
Of 200 queries, 62 (31%) failed, for three main reasons:
1. Navigation mistakes (38 cases, 61% of failures): the LLM took a wrong turn at top-level skill selection. E.g., a "CMS collection sorting" question was routed to the "Site Editor" skill instead of "CMS." This shows top-level taxonomy granularity is the bottleneck—categories too coarse, boundaries between similar skills too fuzzy.
2. Over-retrieval (19 cases, 31%): the LLM found the right topic but grabbed many adjacent irrelevant documents, diluting context quality. This points to room for improvement in leaf-node grouping precision.
3. Synthesis errors (3 cases, 5%): the LLM misread conditional instructions as universal rules or over-generalized. This is an LLM reasoning issue, not an architecture issue.
The authors also ran an ablation: compressing top-level clusters from 15 to 3 (compact mode) reduced navigation mistakes—fewer options mean lower decision complexity. This reveals an interesting trade-off: a flatter tree is easier to navigate but each node's summary gets longer; a deeper tree has shorter summaries but more decision steps.
---
6. A Skeptical Question: Is This Really "No Retrieval"?
The paper's slogan is "Don't Retrieve, Navigate"—but let's not be fooled by slogans.
Look closely at the compile phase: document embedding and clustering are essentially retrieval preprocessing. Corpus2Skill merely moves "retrieval" from online query time to offline compile time. The upside is no vector database at runtime; the downside is that any knowledge base update requires recompiling the entire skill tree.
A more accurate framing: "shift retrieval cost from query time to compile time, and replace vector-similarity matching with LLM reasoning for final document selection."
This isn't a rejection of retrieval—it's a redistribution of compute across time and space.
---
7. Practical Guidance: Who Should Use This?
Good fit:
Poor fit:
8. Closing Thoughts
Corpus2Skill's most valuable contribution is not a specific technique but a paradigm shift: from "letting the LLM consume search results" to "letting the LLM actively explore knowledge structure."
It reminds us that RAG's problem may not be imprecise retrieval algorithms but a wrong interaction model altogether—the LLM is not a search engine user; it should be an explorer that finds its own way through the knowledge forest.
But don't forget that 31% failure rate. Navigation tree quality, top-level taxonomy precision, and LLM decision stability are real engineering challenges. The slogan is sexy; deployment is hard.
> "Compile first, navigate later" — future knowledge systems may no longer be "database + retriever," but "pre-compiled navigable structure + reasoning agent."
---
📄 Paper: arXiv:2604.14572 🏢 Authors: Yiqun Sun, Pengfei Wei, Lawrence B. Hsieh (Wix) 🔗 Code: https://github.com/dukesun99/Corpus2Skill