{"id":2633,"date":"2026-08-20T12:37:10","date_gmt":"2026-08-20T10:37:10","guid":{"rendered":"https:\/\/mairateam.com\/?post_type=glossary&p=2633"},"modified":"2026-08-20T15:55:16","modified_gmt":"2026-08-20T13:55:16","slug":"rag","status":"publish","type":"glossary","link":"https:\/\/mairateam.com\/en\/glossary\/rag\/","title":{"rendered":"RAG"},"content":{"rendered":"

RAG<\/strong> stands for Retrieval-Augmented Generation. The model retrieves relevant sources before answering and assembles the answer from them, instead of drawing only on what it learned during training. This mechanism is precisely why a brand's visibility in AI answers can be influenced by content you publish today.<\/p>\n

In short<\/h2>\n\n\n\n\n\n\n\n
What it is<\/strong><\/td>\nGenerating an answer from retrieved sources rather than from the model's memory<\/td>\n<\/tr>\n
Why marketers care<\/strong><\/td>\nWithout RAG you could only influence what was in the training data. With RAG, current content and its availability decide<\/td>\n<\/tr>\n
Who uses it<\/strong><\/td>\nEffectively every assistant with web access: ChatGPT, Perplexity, Gemini, Claude, Copilot<\/td>\n<\/tr>\n
What RAG rewards<\/strong><\/td>\nClear statements that make sense out of context, and original data<\/td>\n<\/tr>\n
Where it breaks<\/strong><\/td>\nOn technical availability. What a crawler cannot fetch never enters an answer<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

How RAG works<\/h2>\n

It runs in three steps. The query is first turned into something searchable, often by splitting it into several sub-questions. Passages answering them are then pulled from an index. Finally the model assembles an answer from those passages and attaches source links.<\/p>\n

Retrieval works on passages, not pages<\/h3>\n

This is the most important consequence for content. The unit is not a URL, it is a paragraph or a section. A long article with no part that answers standalone has little chance, however well it matches the topic. A short passage carrying a clear definition gets picked up easily.<\/p>\n

Two different crawlers, two different kinds of damage<\/h3>\n

Model providers run separate crawlers. One collects content into the index, the other fetches a page only when it comes up inside a specific answer. Each can be blocked on its own and the consequences differ: without the indexing crawler the site never enters the candidate set at all, without the second one the model cannot verify the current wording of the page.<\/p>\n

The model prefers what it can verify<\/h3>\n

A claim backed by a number, a date or a source enters answers more often than a general statement. Marketing copy with no data gives the model nothing to hold on to.<\/p>\n

From our own practice: crawlers blocked by the firewall<\/h2>\n

In technical audits we test language model and search crawlers directly, each with a request carrying its user agent. Some routinely receive HTTP 403 even though robots.txt explicitly allows them. They are blocked by the firewall at hosting level or by the CDN, a layer most companies never check.<\/p>\n

The split between two bots of the same provider is instructive: the crawler that fetches a page during a live answer passes without trouble, while the indexing crawler gets a 403. In practice that means the model can open the page once it knows about it, but will never discover it on its own.<\/p>\n

Hence the check that belongs in routine maintenance: go through the crawler list and verify the response code directly. Reading robots.txt is not enough, because robots.txt can contradict a block sitting at firewall level.<\/p>\n

Common mistakes<\/h2>\n