The newer architectures each address a different blind spot. GraphRAG<\/strong> adds an explicit graph layer so that the system can reason over entities, relations, communities, and whole-corpus themes, not just top-k chunks. LLM Wiki<\/strong> treats knowledge not as something to rediscover on every query, but as something an LLM continuously rewrites into a readable Markdown knowledge base. Corpus2Skill<\/strong> goes one step further toward agent operations: instead of retrieving top-ranked chunks at runtime, it compiles a corpus offline into a hierarchical skill directory that an agent can navigate through The practical conclusion is that there is no single \u201cpost-RAG\u201d architecture. The next phase is combinatorial by purpose<\/strong>. Use RAG for fast, grounded answers; GraphRAG when relationships and whole-corpus sensemaking matter; LLM Wiki when the organization needs an editable, compounding knowledge artifact; Corpus2Skill when agents must reliably traverse enterprise knowledge as an operational hierarchy; and GNG+MST when the goal is concept discovery, qualitative analysis, or research exploration rather than narrow question answering. The strategic design question is no longer \u201cWhich one replaces RAG?\u201d but \u201cWhich representation of knowledge best fits the work we need to do?\u201d (Azure RAG overview<\/a>; Microsoft GraphRAG blog<\/a>; ThinkNavi manual<\/a>)<\/p>\n\n\n\n Standard RAG remains the enterprise default because it is conceptually simple and operationally useful. In its common form, documents are chunked, chunk embeddings are computed, an index is built, a query triggers vector or hybrid retrieval, the candidate set is reranked, the top evidence is injected into the prompt, and the model generates an answer grounded in those retrieved fragments. Lewis et al.\u2019s original RAG paper established the idea of combining a parametric model with non-parametric external memory, while Azure and Amazon Bedrock documentation make explicit the modern production pipeline: chunking, embedding, retrieval, reranking, and response generation. (Lewis et al., 2020<\/a>;\u00a0Azure RAG overview<\/a>;\u00a0Azure information retrieval guide<\/a>;\u00a0Bedrock reranking<\/a>)<\/p>\n\n\n\n This pipeline is good at finding local answers<\/strong>. If the question is \u201cWhat does the return policy say?\u201d or \u201cWhich API parameter controls retries?\u201d RAG often works well because the answer can be grounded in one or a few fragments. In that sense, RAG is like a strong search engine that can also write. It improves freshness and grounding relative to relying only on model parameters, and it can reduce hallucination when relevant evidence is actually retrieved. (Lewis et al., 2020<\/a>; Self-RAG<\/a>; Azure RAG overview<\/a>)<\/p>\n\n\n\n But the limits have become increasingly visible. First, retrieval can simply miss the right evidence. BM25 is robust for lexical matches and remains a strong baseline, but it depends on term overlap and ranking heuristics; dense retrieval depends on embedding geometry and nearest-neighbor search; both can fail when the question is underspecified or when the necessary evidence is distributed across multiple documents. Second, chunking fragments context. A document may make sense as a whole even when no single chunk cleanly answers the question. Third, long context windows do not magically solve the issue, because models can still underuse relevant information placed in the middle of long prompts. Research such as IRCoT and Lost in the Middle shows why single-shot retrieve-and-read pipelines often struggle on multi-step reasoning and long-context use. (Stanford IR book on BM25<\/a>; DPR<\/a>; IRCoT<\/a>; Lost in the Middle<\/a>)<\/p>\n\n\n\n That is why the field is moving from pure retrieval toward knowledge forms<\/strong> better suited to different tasks. If RAG is a search box, GraphRAG is a map of connections, LLM Wiki is an edited handbook, Corpus2Skill is an agent-operable directory tree, and GNG+MST is a terrain map of meaning. The shift is not away from retrieval entirely, but away from assuming retrieval should be the only organizing principle. (Microsoft GraphRAG paper<\/a>; Karpathy gist<\/a>; Corpus2Skill paper<\/a>; Mindware concept-investigation PDF<\/a>)<\/p>\n\n\n\n Corpus2Skill, introduced in the preprint \u201cDon\u2019t Retrieve, Navigate: Distilling Enterprise Knowledge into Navigable Agent Skills for QA and RAG\u201d<\/strong> (arXiv: 2604.14572, April 2026) and implemented in the public repository dukesun99\/Corpus2Skill<\/strong>, proposes a very specific inversion of the usual RAG assumption: do more work offline<\/strong>, so the runtime agent needs less retrieval and more guided navigation. The paper\u2019s key claim is that enterprise knowledge can be distilled into a navigable skill hierarchy<\/strong> instead of a search index. The repository README describes the same idea in practical terms: take an arbitrary document corpus, compile it into a hierarchically arranged skill tree, and let the serving-time agent traverse that tree instead of querying a retrieval stack on every question. The repository is explicitly labeled an early release \/ work in progress<\/strong>, so it should be treated as promising but experimental. (Corpus2Skill paper<\/a>; Corpus2Skill GitHub README<\/a>)<\/p>\n\n\n\n Mechanistically, Corpus2Skill has an offline compile phase<\/strong> and a runtime serve phase<\/strong>. In the compile phase, the system reads the corpus, computes embeddings, clusters the corpus hierarchically, and uses an LLM to generate concise labels and summaries for each level. The public implementation specifies default models in the README, including At runtime, the agent does not begin by asking a vector database for the top-k nearest chunks. Instead, it begins with a high-level overview of the available skills and descends the tree. It reads a top-level This makes Corpus2Skill fundamentally different from both BM25 and standard vector-database RAG. BM25 ranks documents by lexical relevance using frequency-based scoring; dense retrieval ranks by embedding similarity; standard RAG usually turns those rankings into a top-k context pack for the model. Corpus2Skill still uses embeddings during compilation, but its runtime interface is not a ranked list of chunks<\/strong>. It is a navigation problem over a tree of summaries and directories. That matters because it gives the agent explicit \u201cbranching choices.\u201d If a chosen path looks wrong, the agent can back up and try another branch, rather than being silently constrained by a possibly poor top-k retrieval result. (Stanford IR book on BM25<\/a>; DPR<\/a>; Corpus2Skill paper<\/a>)<\/p>\n\n\n\n The paper evaluates Corpus2Skill on WixQA<\/strong>, a benchmark for enterprise support-style QA based on the Wix Help Center snapshot dated 2024-12-02. The Corpus2Skill paper reports, on the 200-query ExpertWritten split, a Token F1 of 0.460<\/strong>, compared with 0.342 for BM25<\/strong>, 0.363 for Dense<\/strong>, 0.389 for RAPTOR<\/strong>, and 0.388 for Agentic RAG<\/strong>. It also reports Factuality 0.729<\/strong> and Context Recall 0.652<\/strong>, again above the reported baselines in that setting. The associated WixQA benchmark paper and dataset card describe the benchmark composition, including expert-written, simulated, and synthetic queries over the Wix knowledge base. These are strong results, but they should still be read as benchmark-specific evidence rather than universal proof. (Corpus2Skill paper<\/a>; WixQA paper<\/a>)<\/p>\n\n\n\n The trade-offs are equally important. Corpus2Skill\u2019s runtime can be expensive because the skill files themselves consume input tokens. The paper reports roughly $0.172 per query<\/strong> in its main setting, and the public README says Anthropic prompt caching reduced that to $0.089 per query<\/strong> on the WixQA benchmark in repository testing. The paper also names several limitations: dependence on Anthropic\u2019s Skills-style serving pattern, top-level routing errors caused by hard single-path clustering, and lack of mature support for incremental updates without recompilation. Those are not minor footnotes. They mean Corpus2Skill is best understood as a serious architectural idea at an early stage, not yet a drop-in replacement for every production RAG system. (Corpus2Skill paper<\/a>; Corpus2Skill GitHub README<\/a>)<\/p>\n\n\n\n Standard RAG<\/strong> is the retrieval-centered baseline. Its advantages are operational familiarity, modular indexing, relatively easy updates, and good performance on questions whose answers already exist in locally retrievable evidence. Its weaknesses are equally well known: search misses, chunk fragmentation, weak global structure, and the tendency to confuse \u201cmore retrieved text\u201d with \u201cbetter understanding.\u201d (Lewis et al., 2020<\/a>; Azure RAG overview<\/a>)<\/p>\n\n\n\n GraphRAG<\/strong>, especially in Microsoft\u2019s implementation, adds another layer of knowledge representation: extract entities, relations, and claims; detect communities; generate community reports; and support both local and global search modes. Global search is aimed at whole-corpus sensemaking, while local search starts from semantically relevant entities and expands into related neighborhoods. One practical detail from the official docs matters: GraphRAG does not necessarily require a dedicated graph database<\/strong>. Microsoft\u2019s OSS implementation stores outputs in Parquet tables plus a vector store. Its real cost lies elsewhere: extraction quality, prompt tuning, report generation, hierarchy design, re-indexing, and operational maintenance. The docs openly state that out-of-the-box settings are not always optimal and that some features, such as claim extraction, require tuning to be useful. (Microsoft GraphRAG paper<\/a>; Microsoft GraphRAG docs overview<\/a>; Microsoft GraphRAG docs<\/a>)<\/p>\n\n\n\n LLM Wiki<\/strong>, from Andrej Karpathy\u2019s gist published on April 4, 2026, is not a product and not a benchmarked framework. It is a pattern. The key move is to convert raw sources into a persistent Markdown wiki<\/strong> that the LLM can read from, edit, and lint over time. Karpathy separates the system into raw sources, the wiki itself, and a schema or conventions layer. He also proposes three recurrent operations: ingest new sources, answer questions from wiki pages, and lint the wiki for contradictions, stale claims, and missing links. For personal or small-to-medium corpora, he argues that simple page indexes can work surprisingly well without a full embedding retrieval stack, roughly around the scale of about a hundred sources and hundreds of pages. That makes LLM Wiki especially relevant where the goal is knowledge compression, editing, and accumulation<\/strong>, not just one-shot retrieval. (Karpathy gist<\/a>)<\/p>\n\n\n\n Mindware\u2019s GNG+MST concept-structure approach<\/strong> comes from official ThinkNavi and ConceptMiner materials rather than a single canonical research paper. The public manuals and product pages describe a pipeline that uses embeddings and related data, organizes them with Growing Neural Gas and a Minimum Spanning Tree, and uses LLMs to help label dimensions, clusters, and semantic interpretations. The ThinkNavi manual contains the succinct formulation, \u201cRAG finds answers. ThinkNavi finds structure.\u201d<\/strong> That phrase is analytically useful. It captures the fact that this architecture is not primarily about point-answer retrieval. It is about surfacing conceptual neighborhoods, bridges, latent themes, exploration axes, and the relation between an embedding space and human-interpretable conceptual structure. Public official materials emphasize applications in strategic thinking, market or technology exploration, qualitative data analysis, and research support. What is not publicly confirmed<\/strong> in the official materials reviewed is a standardized external benchmark comparable to enterprise QA benchmarks such as WixQA. (ThinkNavi manual, chapter 1<\/a>; ThinkNavi glossary\/manual<\/a>; ConceptMiner developer page<\/a>; Mindware concept-investigation PDF<\/a>)<\/p>\n\n\n\n The simplest way to remember the difference is by metaphor. RAG is a search engine<\/strong>. GraphRAG is a map of relations<\/strong>. LLM Wiki is a living handbook<\/strong>. Corpus2Skill is an agent-operable directory tree<\/strong>. GNG+MST is a terrain map of concepts<\/strong>. These are not interchangeable metaphors; they correspond to different knowledge representations and different operational burdens.<\/p>\n\n\n\nSKILL.md<\/code> and INDEX.md<\/code> files. Mindware Research Institute\u2019s GNG+MST concept-structure approach<\/strong> points in a different but complementary direction: not \u201cfind the answer,\u201d but \u201cfind the structure,\u201d by visualizing clusters, concept distances, bridges, and latent exploration axes. (Microsoft GraphRAG paper<\/a>; Microsoft GraphRAG docs<\/a>; Karpathy, \u201cLLM Wiki\u201d gist<\/a>; Corpus2Skill paper<\/a>; Corpus2Skill GitHub<\/a>; ThinkNavi manual<\/a>; Mindware concept-investigation PDF<\/a>)<\/p>\n\n\n\nTitle Proposals<\/h2>\n\n\n\n
\n
Why Knowledge Architecture Is Shifting<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.aicritique.org\/us\/wp-content\/uploads\/2026\/05\/image-5.png\")
<\/figure>\n\n\n\nCorpus2Skill in Detail<\/h2>\n\n\n\n
Qwen\/Qwen3-Embedding-0.6B<\/code> for embeddings and claude-sonnet-4-6<\/code> for summarization at the time of the public README reviewed here. The output is a file-system-style hierarchy containing SKILL.md<\/code>, INDEX.md<\/code>, and document references. The paper explains that hard assignment is used so that each document lives on one path in the tree, making the hierarchy materializable as a directory structure. (Corpus2Skill GitHub README<\/a>; Corpus2Skill paper<\/a>)<\/p>\n\n\n\nSKILL.md<\/code>, chooses a branch, opens lower-level INDEX.md<\/code> files, and only then fetches source documents through a document lookup when needed. In other words, the agent is following a knowledge directory<\/strong>, not issuing repeated blind searches. That is the practical meaning of \u201cnavigate, don\u2019t retrieve.\u201d The knowledge base is pre-shaped into an explorable hierarchy, like moving through a company\u2019s internal operations manual rather than typing keywords into a search bar. (Corpus2Skill paper<\/a>)<\/p>\n\n\n\nComparative Map of RAG, GraphRAG, LLM Wiki, and GNG+MST<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.aicritique.org\/us\/wp-content\/uploads\/2026\/05\/image-6.png\")
<\/figure>\n\n\n\n