RAG простыми словами: как ИИ-поиск находит ответ в вашем контенте

Представьте: вы вводите в Perplexity вопрос «сколько стоит тариф X у сервиса Y» — и через пять секунд получаете точный ответ с актуальной ценой и ссылкой на страницу тарифов внизу. А через минуту задаёте ChatGPT почти тот же вопрос о своём собственном продукте — и получаете уверенный, гладко написанный ответ, в котором половина фактов устарела на год, а один тариф модель просто придумала, потому что похожее название где-то мелькало в обучающих данных.

Оба ответа звучат одинаково убедительно. Разница не в самой модели — в том, что происходит до того, как она начинает писать ответ. В первом случае между вопросом и ответом стоит механизм, который называется RAG — Retrieval-Augmented Generation, «генерация, дополненная поиском». Во втором модель отвечает по памяти, без обращения к актуальным данным, и выдаёт то, что статистически похоже на правду — а не то, что является правдой.

Эта разница — не теоретическая деталь для дата-сайентистов. Доля запросов, которые раньше попадали в строку классического поиска, а теперь задаются прямо в ChatGPT или Perplexity, год от года растёт — и в каждом таком запросе решение «что ответить и на что сослаться» принимает тот самый механизм retrieval. Если в 2015 году задача была — попасть в топ-10 синих ссылок, то в 2026-м задача шире: оказаться тем фрагментом текста, который модель решит процитировать дословно.

Возьмём простой пример. Компания в прошлом году переехала в новый офис и поменяла тарифную сетку. Модель, обученная на данных, собранных до переезда, «помнит» старый адрес и старые цены — это зашито в её весах, и никакое уточнение в промпте это не исправит, пока модель не сходит и не посмотрит, что изменилось на самом деле. Вот это «сходить и посмотреть» и есть RAG.

Для обычного пользователя разница между этими двумя сценариями — вопрос удобства. Для владельца сайта, продукта или бренда — вопрос репутации: если ИИ-система не может найти и процитировать актуальную информацию о вас, она либо промолчит, либо, что хуже, выдумает что-то похожее на правду. В этой статье разберём, как устроен RAG шаг за шагом и что это значит для контента, который вы публикуете, — если вы хотите, чтобы ИИ-поиск отвечал о вас точно, а не фантазировал.

RAG расшифровывается как Retrieval-Augmented Generation. Это не отдельная модель и не замена GPT или Gemini, а архитектурный приём: перед тем как модель сформулирует ответ, систему заставляют сначала найти релевантные фрагменты текста в базе знаний и подставить их в контекст запроса. Модель отвечает не «из головы», а по тем кускам текста, которые ей только что показали.

Хорошая аналогия — экзамен. Обычная языковая модель без RAG сдаёт экзамен по памяти: всё, что она знает, выучено на этапе обучения, и если с тех пор что-то изменилось — тариф, адрес, состав команды, — она об этом не узнает, пока её не переобучат. RAG — тот же экзамен, но с открытым учебником: прямо во время ответа модели разрешают заглянуть в конкретные страницы, параграфы и таблицы, и только после этого — написать ответ.

Без RAG модель сдаёт экзамен по памяти. С RAG ей разрешают принести на экзамен учебник — отвечать своими словами всё равно приходится ей самой.

На практике это выглядит как конвейер из пяти шагов, который выполняется за доли секунды:

Шаги 1–2. Запрос пользователя — «сколько стоит доставка» — переводится в вектор, последовательность из сотен чисел, которая описывает смысл фразы, а не конкретные слова. Это называется эмбеддингом; подробно этот механизм разобран в статье «Что такое векторные эмбеддинги». Фразы «сколько стоит доставка» и «какая цена у курьерской доставки» превращаются в похожие векторы, даже если в них нет ни одного общего слова, — система ищет по смыслу, а не по ключевым словам.

Представим это наглядно: каждый вектор — это точка в многомерном пространстве, и чем ближе по смыслу два текста, тем ближе друг к другу их точки. Эмбеддинг «сколько стоит доставка» и эмбеддинг «цена курьерской доставки» окажутся соседями в этом пространстве; эмбеддинг «как оформить возврат» — где-то совсем в другой его части. Поиск по такому пространству — это буквально поиск ближайших соседей, только не в двух-трёх измерениях, а в нескольких сотнях.

Шаг 3. Вектор-запрос сравнивается с векторами, заранее посчитанными для всех фрагментов текста в базе знаний — страниц сайта, документации, базы ответов поддержки. Хранилище, оптимизированное именно под такое сравнение, называется векторной базой данных; оно умеет за миллисекунды найти несколько фрагментов, векторы которых ближе всего к вектору запроса, даже если фрагментов — миллионы.

Шаг 4. Система отбирает top-N самых близких по смыслу фрагментов — обычно от трёх до десяти, в зависимости от настройки, — и подставляет их текст прямо в промпт модели, рядом с исходным вопросом пользователя.

Отдельный нюанс, о котором редко задумываются вне разработки: соседние чанки обычно делают с небольшим перехлёстом — последние одно-два предложения одного фрагмента повторяются в начале следующего. Иначе факт, который оказался ровно на границе двух кусков текста, рискует не попасть целиком ни в один из них и выпасть из поиска.

Шаг 5. И только теперь модель формулирует ответ — но её прямо просят опираться на подставленные фрагменты, а не на то, что она «помнит» с этапа обучения. Хорошо настроенная система при этом указывает, из какого именно фрагмента, а значит и с какой страницы, взят каждый факт.

Ключевое — RAG не меняет саму модель. GPT, Gemini или любая другая большая языковая модель под капотом остаются той же нейросетью, что с RAG, что без него. Разница исключительно в том, что модели показывают до того, как она начинает писать.

На стороне пользователя это незаметно — переключатель «поиск включён/выключен» часто спрятан в настройках или вовсе выбирается автоматически самой системой в зависимости от того, насколько «свежим», по её оценке, должен быть ответ. Отсюда и ощущение непредсказуемости: один и тот же человек в одном и том же интерфейсе может в одном диалоге получить ответ, подкреплённый источником, а в другом — чистую догадку, даже не заметив разницы в формулировке.

Это объясняет, почему один и тот же вопрос про один и тот же бренд может получить два противоположных ответа — в зависимости от того, какая система отвечает и включён ли в ней поиск. Perplexity и ChatGPT с включённым браузингом по умолчанию работают в режиме RAG; без поиска любая языковая модель рискует заполнить пробелы в знаниях чем-то похожим на правду, но правдой не являющимся. Мы подробно разбираем механику этого эффекта в статье «Почему ИИ выдумывает факты» — если коротко, галлюцинация почти всегда случается именно там, где retrieval не сработал или вовсе отсутствовал.

Если вы не строите чат-бота и не внедряете ИИ внутри компании, может показаться, что RAG — тема для разработчиков, а не для владельца сайта. Это не так. Современные ИИ-поисковики — ChatGPT с включённым браузингом, Perplexity, обзорные ответы Google — по сути выполняют тот же RAG-конвейер, который мы только что разобрали, но в масштабе всего открытого интернета. Ваш сайт — это часть той самой «базы знаний», по которой они ищут фрагменты для ответа.

Это меняет единицу, на которую стоит оптимизировать контент. В классическом SEO единицей ранжирования была страница целиком: заголовок, мета-описание, ссылочный профиль. В мире RAG-поиска единица — фрагмент, «чанк»: отдельный абзац или блок, который модель может выдернуть из контекста страницы и процитировать сам по себе, без остального текста вокруг. Если абзац понятен только в связке с предыдущими тремя абзацами, он плохо «извлекается», и шанс, что именно он попадёт в топ результатов поиска по эмбеддингам, падает.

На практике это означает три вещи. Во-первых, заголовки должны звучать как вопросы, которые реально задают, а не как рубрики в духе «Наши преимущества» — эмбеддинг заголовка «Сколько стоит подключение» гораздо ближе к эмбеддингу реального вопроса пользователя, чем эмбеддинг абстрактного слова «Тарифы». Во-вторых, каждый ключевой факт стоит формулировать явно и целиком в одном месте — не «у нас гибкие условия», а «бесплатная отмена подписки в любой момент без штрафов». Фраза с конкретикой — это то, что модель может процитировать как прямой ответ; обтекаемую формулировку процитировать нечем. В-третьих, абзацы стоит писать так, чтобы они имели смысл сами по себе, вне контекста соседних абзацев, — именно так ИИ-поисковик будет «нарезать» их на чанки при индексации.

Разница заметна на конкретном примере. Маркетинговый вариант: «У нас выгодные тарифы и гибкие условия для любого бизнеса». Retrievable вариант: «Тариф от 990 ₽ в месяц, отмена подписки в любой момент без штрафов, бесплатный тестовый период — 14 дней». Первая формулировка не содержит ни одного факта, который можно процитировать как ответ на вопрос «сколько это стоит» или «можно ли отменить без штрафа», — она пройдёт мимо любого retrieval. Вторая отвечает сразу на три потенциальных вопроса дословно, и именно поэтому у неё на порядок больше шансов оказаться тем фрагментом, который ИИ-система выберет для цитирования.

Проверить, что реально отвечают ИИ-системы о вашем бренде — вручную, вопрос за вопросом в каждом интерфейсе, — можно, но утомительно и плохо масштабируется. Такие инструменты, как AI Control, автоматизируют именно это: регулярно прогоняют одни и те же промпты через ChatGPT, Perplexity, Copilot, Gemini и Google AI и показывают, упоминают ли вас эти системы, цитируют ли и с какой регулярностью — то есть насколько ваш контент оказывается «извлекаемым» на практике, а не в теории.

RAG — не один алгоритм, а семейство решений, и от конкретной реализации сильно зависит, насколько точными окажутся ответы. Вот пять факторов, которые решают, попадёт ли нужный фрагмент в топ результатов поиска — и, соответственно, процитирует ли модель именно вас.

Разные системы по-разному решают, что считать «близким» фрагментом. Самый простой вариант — naive RAG: один проход поиска по векторам, топ-N результатов без дополнительной проверки. Более продвинутые системы добавляют гибридный поиск — одновременно по векторам и по ключевым словам, что подстраховывает от промахов чистого семантического поиска, — и re-ranking: отдельный шаг, который заново сортирует уже найденных кандидатов более точной (и более медленной) моделью перед тем, как отдать их в промпт. Чем сложнее эта цепочка, тем точнее результат, но и тем больше факторов на стороне вашего контента начинают иметь значение — в первую очередь те, что перечислены в таблице ниже.

Ни один из этих пунктов не требует разработки — это в чистом виде редакторская работа: структура, формулировки, конкретика.

Самый быстрый способ понять, насколько RAG-дружелюбен ваш контент, — не гадать, а спросить саму модель напрямую и сравнить два режима ответа: по памяти и с поиском. Вот промпт, который можно скопировать и вставить в любую систему с переключаемым веб-поиском — ChatGPT, Perplexity или Gemini.

Ты — ассистент с доступом к поиску в интернете.

Шаг 1. Сначала ответь на вопрос ниже, НЕ используя поиск — только то, что ты уже знаешь. Явно напиши в начале ответа: "Отвечаю по памяти, без проверки в интернете".

Вопрос: [впишите сюда вопрос о вашем продукте, бренде или компании]

Шаг 2. Теперь включи поиск в интернете и ответь на тот же вопрос заново. В начале напиши: "Отвечаю с проверкой в интернете". После каждого факта в скобках укажи источник (адрес страницы), откуда он взят.

Шаг 3. Сравни оба ответа построчно и перечисли отдельным списком: какие факты из ответа 1 не подтвердились источником в ответе 2 или прямо ему противоречат.

Если переключателя веб-поиска нет — например, в обычном чате без доступа к интернету, — есть более грубый, но тоже рабочий вариант: попросите модель прямо указать, насколько она уверена в ответе и на основании чего, а отдельным сообщением спросите, какие источники ей понадобились бы, чтобы ответить точно. Модели без retrieval обычно честно описывают, что отвечают «по общим знаниям», если спросить об этом напрямую, — просто в обычном диалоге их об этом никто не спрашивает.

Если шаг 3 показывает длинный список расхождений — это сигнал не о том, что модель «плохая», а о том, что retrieval не нашёл для неё однозначных, явно цитируемых фактов на вашем сайте. Чаще всего причина в размытых формулировках и в структуре, которая мешает нарезать текст на самостоятельные фрагменты, — то есть именно в том, что мы разобрали в предыдущих разделах.

Собрали из разобранного выше практический список для проверки — пройдитесь по нему перед тем, как публиковать или переписывать ключевые страницы.

• Переформулируйте заголовки разделов как реальные вопросы пользователей, а не абстрактные рубрики
• Каждый ключевой факт — цену, условие, срок, контакт — сформулируйте явно и целиком в одном абзаце
• Пишите абзацы так, чтобы они были понятны сами по себе, без контекста соседних абзацев
• Избегайте обтекаемых формулировок вроде «гибкие условия» — замените конкретикой, которую можно процитировать
• Указывайте дату актуальности на страницах, которые меняются: цены, тарифы, контакты
• Повторите ключевой факт в заголовке, абзаце и FAQ — это увеличивает шанс, что хотя бы один чанк попадёт в выдачу
• Проверьте страницу промптом из этой статьи — сравните ответ по памяти и ответ с поиском
• Для системной проверки по всем ключевым промптам и ИИ-системам используйте AI Control вместо ручных прогонов