SEO-команда тонет в чатах, старых брифах, разрозненных кейсах. Редполитика в Notion. Термины в старом чате. Чек-листы у каждого свои.
Нужно написать статью — и человек тратит час на поиск того, что уже написано раньше. Или не находит и пишет заново, чуть другими словами. Голос плывёт. Термины расходятся. CTA каждый раз разные.
RAG — архитектурное решение этой проблемы. Вместо гигантского промпта — база знаний, из которой модель достаёт нужное в момент запроса. Масштабируется и обновляется, в отличие от промпта.
Как это работает: простой пайплайн
Не нужно строить сложную инфраструктуру, чтобы понять принцип. Упрощённая схема:
| Этап | Что происходит и зачем |
|---|---|
| 1. Источник | Документы: редполитика, кейсы, термины, чек-листы, Q&A из чатов |
| 2. Chunking (разбиение) | Документы делятся на атомарные фрагменты: 1 концепция = 1 чанк (200–500 токенов). Если чанк слишком большой — retrieval тянет лишний шум и снижает точность |
| 3. Метаданные | Каждый чанк помечается тегами: тип, тема, дата. Позволяет фильтровать при поиске |
| 4. Индексирование | Чанки преобразуются в векторные эмбеддинги и хранятся в вектор-БД |
| 5. Retrieval (поиск) | При запросе система ищет релевантные чанки по смысловому сходству |
| 6. Generation | Модель получает запрос + релевантный контекст → генерирует ответ |
Работа до RAG и после: конкретный пример
Задача: написать статью для блога в стиле автора, с правильной терминологией, с нужными CTA.
| Без RAG | С RAG |
|---|---|
| Каждый раз пишем промпт заново: «ты SEO-эксперт, вот тон, вот стиль...» | База содержит редполитику и примеры. Контекст достаётся автоматически |
| После 3-й статьи голос начинает «плыть» | Голос стабилен — контекст не зависит от длины сессии |
| CTA формулируется вручную или копируется из прошлых статей | Из базы извлекается актуальный список услуг с правильными формулировками |
| Внутренние ссылки расставляются вручную — нужно помнить все существующие статьи | База содержит карту статей и кластеров → ссылки предлагаются автоматически по теме |
| Перепроверка терминологии вручную | Словарь из базы обеспечивает консистентность терминов |
| Время на подготовку контекста: 20–40 минут | Время на подготовку контекста: 2–5 минут |
Тот же принцип работает для аудитов: база накапливает типовые паттерны ошибок по нишам, чек-листы, примеры из кейсов. Вместо «вспоминать» — «получить нужное».
Реальный пример: документы и промпты
Вот как это выглядит на практике — три уровня: сам документ в базе, промпт, который его использует, и что получает модель на выходе.
Шаг 1 — Документ в базе (чанк редполитики)
Метаданные чанка: type:policy · topic:voice · lang:ru · updated:2026-04
- Голос: прямой, без вводных слов. Не «следует отметить» — а «вот что важно».
- Стиль: конкретные числа > абстракции. «Трафик вырос на 340%» вместо «трафик вырос значительно».
- Запрещены: клише («в современном мире»), пассивный залог как основной приём, перечни без контекста.
- CTA: только через Telegram (@staurus_seo). Формулировка: «Написать в Telegram».
Шаг 2 — Промпт с RAG-контекстом
CONTEXT (retrieved from base)[editorial-voice.md]
Голос: прямой, конкретные числа, без клише.
CTA: @staurus_seo в Telegram.
[terms-glossary.md]
Crawl budget — лимит URL, которые Googlebot
обходит за сессию. Не «краулинговый бюджет» —
только «crawl budget» или «бюджет обхода».
[content-map.md]
/blog/javascript-seo-kak-rendering-... — JS SEO
/blog/enterprise-seo-chto-otlichaet-... — Enterprise
[ЗАДАЧА]
Напиши вводный абзац для статьи о crawl budget.
Стиль — из редполитики. Предложи 1-2 внутренние
ссылки из карты. Длина: 80-100 слов.
Шаг 3 — Что получает модель и почему это работает
«Crawl budget — количество URL, которые Googlebot обходит за сессию. На сайте с 2 млн страниц бот не успевает обойти всё. Что именно попадает в очередь — определяет не контент, а структура: приоритеты, дублирование, параметры. Разбираю, где теряется бюджет и как это починить. Подробнее про enterprise-аудит →»
- Правильный термин: «crawl budget», не «краулинговый бюджет»
- Конкретная цифра («2 млн страниц»), а не абстракция
- Внутренняя ссылка из актуальной карты статей
- Нет CTA в этом блоке — редполитика не требует
Что класть в RAG первым: по скорости отдачи
Не нужно строить идеальную базу с нуля. Начинать нужно с того, что снимает боль прямо сейчас.
| Приоритет | Что добавлять и почему даёт быстрый эффект |
|---|---|
| 1 Редполитика + примеры голоса | Сразу стабилизирует тон всего производимого контента |
| 2 Словарь терминов | Убирает разброс: один термин = одно слово во всех материалах |
| 3 Список услуг/продуктов с CTA | Правильные формулировки оферов без ручного копирования |
| 4 Карта внутренних ссылок | Автоматические предложения по перелинковке при написании статей |
| 5 Кейсы с цифрами | Готовые примеры для статей, предложений, аудитов |
| 6 FAQ из реальных вопросов | Структура для SEO-контента, отражающая реальный спрос |
| 7 Чек-листы и фреймворки | Повторяемые рабочие процессы без «вспоминания» |
Риск плохого RAG: уверенный ответ не по тем документам
Если retrieval настроен плохо — модель будет звучать уверенно, но отвечать на основе нерелевантных документов. Это хуже, чем отсутствие RAG, потому что ошибки становятся менее заметными.
Признаки плохого retrieval:
- Ответы звучат правдоподобно, но содержат детали из чужих кейсов или устаревших данных.
- Тон голоса правильный, но факты не соответствуют вашей практике.
- Внутренние ссылки предлагаются, но к нерелевантным страницам.
Что не надо класть в базу знаний
Плохо структурированная или загрязнённая база хуже пустой — она создаёт противоречия и шум в ответах модели.
- Сырые черновики с непроверенными данными — создают противоречия с финальными версиями.
- Устаревшие документы без пометки — старые алгоритмы, устаревшие правила.
- Противоречивые регламенты — если два документа говорят разное, модель будет «галлюцинировать».
- Дубли одного и того же контента — размывают поиск, возвращается нерелевантный результат.
- Слишком большие монолитные документы — хуже находятся при поиске, содержат нерелевантный контекст и снижают точность ответов.
Инструменты по уровням
Старт — один человек, до 100 документов
Obsidian или Notion — структурированные папки, теги, связи между документами. Не нужна специальная инфраструктура.
Claude / ChatGPT с загрузкой файлов. Качество структуры и метаданных важнее выбора фреймворка.
Команда — 100–10K документов
LlamaIndex или LangChain — управление документами, chunking, retrieval. Подходит при повторяемых задачах и интеграции с CMS.
Chroma (локально), Qdrant или Pinecone — хранение эмбеддингов. Выбор зависит от объёма и требований к латентности.
Как собрать базу от нуля: пошаговая инструкция
Не нужна вектор-БД и инженер для старта. Вот последовательность, которая работает без инфраструктуры.
Соберите исходники
Что брать: редполитику с примерами голоса, 2–3 эталонные статьи, словарь терминов (даже 30–50 пунктов — уже ценно), список услуг/продуктов с формулировками CTA, кейсы с цифрами, FAQ из реальных вопросов клиентов.
Где искать: старые чаты с повторяющимися ответами, Notion / Google Docs, собственные статьи и брифы, записи созвонов с клиентами.
Нарежьте документы на чанки
Правило: 1 концепция = 1 чанк (200–500 токенов, ~150–350 слов). Не кладите редполитику и кейс в один файл — они разного типа и будут мешать друг другу при поиске.
- Редполитику разбейте по разделам: голос / структура / запреты / CTA — 4 чанка.
- Каждый кейс — отдельный чанк: ниша + проблема + что сделали + цифры.
- Термины: один термин = одна запись (название + определение + пример использования).
Добавьте метаданные к каждому чанку
Минимальный набор для начала:
Метаданные чанка (в начале файла или отдельным полем)type: policy # policy / case / term / faq / checklist
topic: voice # voice / structure / technical / content / audit
lang: ru
updated: 2026-04
scope: all # all / niche / client-type
Без метаданных retrieval возвращает нерелевантное — модель будет использовать чужие кейсы или устаревшие правила.
Начните с загрузки файлов — без вектор-БД
Загрузите 5–10 ключевых документов напрямую в Claude или ChatGPT (Projects / Custom GPT с файлами). Проверьте retrieval вручную: задайте вопрос и посмотрите, что достаётся.
- «Какой CTA использовать в статье о техническом аудите?» → должна вернуться редполитика.
- «Как правильно писать: crawl budget или краулинговый бюджет?» → должен вернуться словарь.
- «Какие кейсы есть по e-commerce?» → должны вернуться только кейсы с тегом e-commerce.
Если ответы нерелевантны — проблема в разбиении или метаданных, не в модели.
Напишите три базовых промпта
Три задачи, которые закроют 80% работы с контентом:
Промпт 1 — Голос автораИспользуй редполитику из базы знаний. Напиши [тип контента: абзац / секцию / FAQ] о [тема]. Стиль — из editorial-voice.md. Конкретные цифры, без клише. CTA по правилам из базы, если нужен. Промпт 2 — Проверка терминологииПроверь текст ниже на соответствие словарю из базы. Замени нестандартные формулировки на принятые. Текст: [вставить текст] Промпт 3 — Внутренние ссылкиПо карте статей из базы: предложи 2-3 релевантные внутренние ссылки для материала о [тема]. Объясни, почему каждая ссылка уместна.
Проверьте retrieval отдельно от генерации
Это самый важный шаг, который пропускают. Сначала убедитесь, что по запросу достаются правильные документы — только потом запускайте полный пайплайн генерации.
- Запросите базу: «Покажи, какие документы ты используешь для ответа на этот вопрос».
- Если ответ нерелевантен — меняйте чанкинг или метаданные, не промпт генерации.
- Рабочий критерий: для любого запроса база должна возвращать нужный тип документа (policy → редполитика, не кейс).
После того как retrieval работает стабильно — подключайте LlamaIndex или Qdrant для масштабирования.
SEO-задачи, где RAG работает прямо сейчас
- Написание статей — стабильный голос, правильные термины, внутренние ссылки из актуального списка.
- Брифы для авторов — быстрое извлечение структуры, интентов, релевантных кейсов.
- Глоссарий и согласованность — единое название для каждого термина во всех материалах.
- FAQ-блоки — генерация на основе реальных вопросов из базы.
- Паттерны диагностики — повторяемые схемы анализа по нише или типу сайта, сохранённые из прошлых аудитов.
- Предложения клиентам — извлечение релевантных кейсов и формулировок под конкретную задачу.
Хотите внедрить RAG в SEO-процессы команды?
Разберём конкретный пайплайн под ваши задачи: что и как хранить, как настроить retrieval, с чего начать без сложной инфраструктуры.
Написать в Telegram