Retrieval-Augmented Generation, or RAG, has become widely known as a way to connect generative AI with internal corporate documents.<\/p>\n\n\n\n
The commonly presented explanation of RAG is surprisingly simple:<\/p>\n\n\n\n
LangChain\u2019s introductory materials similarly present documents, text splitters, embeddings, vector stores, and retrievers as the basic components of semantic search. Major surveys of RAG research classify this structure\u2014splitting documents into chunks, storing their embeddings in a vector database, and retrieving the most similar chunks\u2014as Naive RAG<\/strong>.<\/p>\n\n\n\n The problem is not that this method is taught as an introductory model.<\/p>\n\n\n\n The problem is that an introductory model has come to be treated as though it were the completed form of RAG.<\/p>\n\n\n\n A user\u2019s question and the answer-bearing text in a document usually have different linguistic forms.<\/p>\n\n\n\n Suppose a contract contains the following provision:<\/p>\n\n\n\n Unless written notice is provided at least 30 days before the expiration date, the agreement will renew automatically.<\/p>\n<\/blockquote>\n\n\n\n A user may ask:<\/p>\n\n\n\n How far in advance do I need to notify you if I want to stop the automatic renewal?<\/p>\n<\/blockquote>\n\n\n\n These two sentences concern the same subject, but their vocabulary, syntax, and communicative functions differ. One is a declarative rule. The other expresses a user\u2019s intent in question form.<\/p>\n\n\n\n Naive RAG directly compares these different kinds of sentences in an embedding space and assumes that their meanings will be sufficiently close.<\/p>\n\n\n\n Modern embedding models can handle this to a certain extent. However, as the number of documents grows and more chunks contain similar language, the correct chunk may fall outside the top few retrieved results. Surveys of RAG have repeatedly identified problems such as irrelevant retrieval, failure to retrieve necessary evidence, and answers that are not properly grounded in the retrieved material.<\/p>\n\n\n\n In response, practitioners repeatedly adjust:<\/p>\n\n\n\n These techniques can improve performance, but they do not change the underlying structure. They continue to refine a system that directly compares a question with fragments of answer text.<\/p>\n\n\n\n A more natural approach is to generate, in advance:<\/p>\n\n\n\n What kinds of questions can this passage answer?<\/p>\n<\/blockquote>\n\n\n\n From the contract provision above, a system could generate question patterns such as:<\/p>\n\n\n\n A user\u2019s actual question is likely to resemble these generated question patterns more closely than it resembles the original legal provision.<\/p>\n\n\n\n The retrieval structure can therefore be redesigned.<\/p>\n\n\n\n The generated question patterns should not become the final source of truth.<\/p>\n\n\n\n They are routing devices that lead the system to the correct original evidence. The final answer should still be generated from the source document.<\/p>\n\n\n\n This distinction matters. Even if some detail is omitted when a Wiki page or question pattern is generated, the final system can return to the original passage before answering.<\/p>\n\n\n\n The idea of generating synthetic questions from documents and using them for retrieval has already appeared in research.<\/p>\n\n\n\n Studies on enterprise RAG have proposed decomposing document chunks into atomic statements, generating synthetic questions from those statements, and matching user questions against the generated questions. In reported experiments, retrieval based on synthetic questions achieved better recall than directly retrieving the original document chunks.<\/p>\n\n\n\n Other work has likewise proposed generating questions that a document chunk could answer and indexing those questions rather than relying only on the chunk\u2019s original wording.<\/p>\n\n\n\n The important conclusion is not that vector search is fundamentally wrong.<\/p>\n\n\n\n The real issue is:<\/p>\n\n\n\n What should be vectorized, and what should be compared?<\/p>\n<\/blockquote>\n\n\n\n It may be more rational to construct an \u201canswerable question space\u201d from a source document and route the user\u2019s question through that space than to treat raw document chunks as the only retrieval units.<\/p>\n\n\n\n This situation closely resembles the history of the Self-Organizing Map, or SOM.<\/p>\n\n\n\n In many textbooks, SOM is presented as an online learning algorithm. Data records are shown one at a time, a winning node is selected, and the winner and its neighbors are gradually updated.<\/p>\n\n\n\n This explanation is intuitive and useful for understanding the basic principle of SOM. However, online SOM is affected by:<\/p>\n\n\n\n Batch SOM, by contrast, processes the complete dataset in batch form. It does not require a conventional learning-rate schedule and can produce stable, reproducible models when its conditions are fixed.<\/p>\n\n\n\n Teuvo Kohonen himself later recommended the batch-learning version for practical use, describing it as faster and safer than sequential learning.<\/p>\n\n\n\n Viscovery SOMine also used high-performance batch SOM as its core technology for many years, together with two-dimensional hexagonal maps, variable weighting, missing-value handling, and clustering.<\/p>\n\n\n\n Nevertheless, when many people hear \u201cSOM,\u201d they still think primarily of the sequential algorithm described in introductory textbooks.<\/p>\n\n\n\n This reveals a recurring problem in the diffusion of technology:<\/p>\n\n\n\n The first version that is explained clearly becomes fixed in the public imagination as the standard form of the technology.<\/p>\n<\/blockquote>\n\n\n\n Even when more practical methods are later developed, it may take years for them to reach textbooks, training courses, sample code, and ordinary users.<\/p>\n\n\n\n Naive RAG did not become widespread because it was necessarily the most advanced approach.<\/p>\n\n\n\n It became widespread because it was easy to explain and easy to demonstrate.<\/p>\n\n\n\n The following story is immediately understandable:<\/p>\n\n\n\n Split a PDF, put the chunks into a vector database, retrieve the most similar passages, and send them to an LLM.<\/p>\n<\/blockquote>\n\n\n\n This structure also maps neatly onto commercial products:<\/p>\n\n\n\n It is convenient for developers because they can build a demo quickly. It is convenient for vendors because the components are easy to sell. It is convenient for corporate buyers because they can explain internally that they are adopting a widely recognized RAG architecture.<\/p>\n\n\n\n The same was true of sequential SOM. The narrative of presenting an input, selecting a winner, and updating neighboring nodes was intuitive and closely resembled the familiar story of neural-network learning.<\/p>\n\n\n\n But ease of explanation and practical superiority are not the same thing.<\/p>\n\n\n\n When Naive RAG fails to answer a question, developers begin adjusting:<\/p>\n\n\n\n Because these adjustments can become highly complex, RAG begins to look like an advanced technical discipline.<\/p>\n\n\n\n But there is another interpretation:<\/p>\n\n\n\n Much of the tuning may be required because the system began with an overly primitive retrieval design.<\/p>\n<\/blockquote>\n\n\n\n The system is trying to compensate for the mismatch between question language and document language through downstream parameter adjustments.<\/p>\n\n\n\n This resembles repeatedly changing the learning rate, initialization, and presentation order of an online SOM and then concluding that SOM is inherently unstable.<\/p>\n\n\n\n Batch SOM simplifies the problem by changing the learning procedure itself.<\/p>\n\n\n\n Similarly, redesigning what RAG retrieves may eliminate much of the tuning that otherwise appears unavoidable.<\/p>\n\n\n\n When people hear that an LLM automatically creates Wiki pages from documents, they may imagine that the source text is merely being summarized into another knowledge base.<\/p>\n\n\n\n That is not the most important function.<\/p>\n\n\n\n Each Wiki page can contain:<\/p>\n\n\n\n The Wiki page then functions as a semantic router between the user\u2019s question and the original evidence.<\/p>\n\n\n\n If a separate LLM Wiki is created for each source document, several additional problems become easier to manage:<\/p>\n\n\n\n There is no need to place every corporate document into one enormous vector database and ask the LLM to decide afterward whether the retrieved information should be disclosed.<\/p>\n\n\n\n The system should first determine which Wiki sets the authenticated user is permitted to access. Routing and retrieval should then occur only within that authorized knowledge space.<\/p>\n\n\n\n The point is not that embedding-based search should be abandoned.<\/p>\n\n\n\n Embeddings can still be used to compare a user\u2019s question with generated question patterns.<\/p>\n\n\n\n The difference lies in what is being compared:<\/p>\n\n\n\n Do we directly compare the question with raw document chunks? Vector search is a tool. It is not a complete knowledge architecture.<\/p>\n\n\n\n Yet the introduction of a vector database is often treated as equivalent to the construction of a knowledge base.<\/p>\n\n\n\n This confusion lies at the center of much of the current enthusiasm around RAG.<\/p>\n\n\n\n It would be too simple to say that developers continue using primitive RAG because they do not understand the technology.<\/p>\n\n\n\n The deeper problem is structural:<\/p>\n\n\n\n Once this cycle is established, the standard architecture becomes difficult to challenge, even when more rational alternatives are available.<\/p>\n\n\n\n The slow diffusion of batch SOM and the continued dominance of raw-chunk vector retrieval can be understood as examples of the same phenomenon.<\/p>\n\n\n\n Companies do not truly need systems that find chunks resembling a user\u2019s query.<\/p>\n\n\n\n They need systems capable of managing questions such as:<\/p>\n\n\n\n The central challenge of RAG is therefore not the speed or sophistication of a vector database.<\/p>\n\n\n\n It is the design problem of transforming documents written for humans into structures through which AI can reliably answer questions.<\/p>\n\n\n\n When a new technology appears, the first simplified explanation often survives for a long time.<\/p>\n\n\n\n In SOM, sequential learning came to be treated as though it were SOM itself.<\/p>\n\n\n\n In RAG, chunking documents and retrieving them by vector similarity has come to be treated as though it were RAG itself.<\/p>\n\n\n\n But a basic principle is a starting point, not a final form.<\/p>\n\n\n\n Just as SOM evolved in practical applications toward batch learning, variable weighting, missing-data handling, clustering, and stable two-dimensional visualization, RAG must move beyond raw-document retrieval toward:<\/p>\n\n\n\n A method does not become the most rational design merely because everyone uses it.<\/p>\n\n\n\n Real technological progress does not begin with finer adjustment of existing parameters.<\/p>\n\n\n\n It begins by questioning assumptions that have become so familiar that no one thinks to question them anymore.<\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" The \u201cFirst Textbook\u201d Trap Seen Before in the History of SOM Retrieval-Augmented Generation, or RAG, has become widely known as a way to connect generative AI with internal corporate documents. The commonly presented explanation of RAG is surprisingly simple: LangChain\u2019s…<\/p>\n","protected":false},"author":1,"featured_media":2194,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[21,9,96,59],"tags":[],"class_list":["post-2193","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-main","category-rag","category-review","category-trende"],"_links":{"self":[{"href":"https:\/\/www.aicritique.org\/us\/wp-json\/wp\/v2\/posts\/2193","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.aicritique.org\/us\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.aicritique.org\/us\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.aicritique.org\/us\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.aicritique.org\/us\/wp-json\/wp\/v2\/comments?post=2193"}],"version-history":[{"count":2,"href":"https:\/\/www.aicritique.org\/us\/wp-json\/wp\/v2\/posts\/2193\/revisions"}],"predecessor-version":[{"id":2197,"href":"https:\/\/www.aicritique.org\/us\/wp-json\/wp\/v2\/posts\/2193\/revisions\/2197"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.aicritique.org\/us\/wp-json\/wp\/v2\/media\/2194"}],"wp:attachment":[{"href":"https:\/\/www.aicritique.org\/us\/wp-json\/wp\/v2\/media?parent=2193"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.aicritique.org\/us\/wp-json\/wp\/v2\/categories?post=2193"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.aicritique.org\/us\/wp-json\/wp\/v2\/tags?post=2193"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The Unnaturalness of Directly Comparing Questions with Answer Text<\/h2>\n\n\n\n
\n
\n
\n
Indexing \u201cAnswerable Questions\u201d Instead of Documents<\/h2>\n\n\n\n
\n
\n
Conventional RAG<\/h3>\n\n\n\n
User question\n \u2193\nDirect comparison with document chunks\n \u2193\nOriginal source text<\/code><\/pre>\n\n\n\nQuestion-pattern routing<\/h3>\n\n\n\n
User question\n \u2193\nComparison with generated question patterns\n \u2193\nIdentification of the relevant Wiki page\n \u2193\nRetrieval of the original source text\n \u2193\nGrounded answer generation<\/code><\/pre>\n\n\n\nQuestion-Based Retrieval Is Not an Exotic Idea<\/h2>\n\n\n\n
\n
The Same Thing Happened with SOM<\/h2>\n\n\n\n
\n
\n
Primitive Methods Are Often Easier to Popularize<\/h2>\n\n\n\n
\n
\n
Endless Tuning Can Make an Elementary Design Look Advanced<\/h2>\n\n\n\n
\n
\n
An LLM Wiki Is a Routing Layer, Not Merely a Knowledge Repository<\/h2>\n\n\n\n
\n
\n
This Is Not an Argument Against Vector Search<\/h2>\n\n\n\n
\n
Or do we first generate the questions that the document can answer and search within that question space?<\/p>\n<\/blockquote>\n\n\n\nThe Problem Is Not Simply a Lack of Intelligence<\/h2>\n\n\n\n
\n
What Enterprises Need Is Knowledge Design, Not Merely Better Retrieval<\/h2>\n\n\n\n
\n
Questioning the Basic Form Presented in Textbooks<\/h2>\n\n\n\n
\n