SEO-команда тонет в чатах, старых брифах, разрозненных кейсах. Редполитика в Notion. Термины в старом чате. Чек-листы у каждого свои.

Нужно написать статью — и человек тратит час на поиск того, что уже написано раньше. Или не находит и пишет заново, чуть другими словами. Голос плывёт. Термины расходятся. CTA каждый раз разные.

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

Что такое RAG простыми словами и чем он отличается от обычного промпта

RAG расшифровывается как Retrieval-Augmented Generation — генерация с расширением через поиск. Смысл прост: вместо того чтобы полагаться только на знания, встроенные в модель при обучении, система в момент запроса достаёт релевантные документы из внешней базы и передаёт их модели как контекст.

Модель не «помнит» — она читает. Каждый раз. Из актуальной базы.

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

RAG динамичен: база содержит тысячи документов, но модель получает только те фрагменты, которые релевантны конкретному запросу. Обновили документ в базе — все последующие ответы автоматически используют новую версию.

Параметр Только промпт RAG
Масштабируемость Ограничена контекстным окном (~200K токенов максимум) Неограниченная — база может содержать миллионы документов
Свежесть данных Требует ручного редактирования промпта при каждом обновлении Обновляется отдельно от пайплайна генерации
Точность фактов Модель может галлюцинировать при отсутствии контекста Ответы заземлены на реальные документы базы
Лимит контекста Весь контекст в одном окне — конкурирует за токены Передаётся только релевантное (3–10 чанков на запрос)
Прозрачность Непонятно, почему модель ответила именно так Можно видеть, из каких документов взят ответ

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

RAG — не инструмент и не конкретная библиотека. Это архитектурный паттерн. Его можно реализовать через загрузку файлов в Claude Projects, через LlamaIndex, через самописный Python-скрипт. Принцип один: сначала поиск по базе, потом генерация с найденным контекстом.

Как работает RAG в упрощённой форме: пользователь задаёт вопрос → система ищет похожие фрагменты в базе → передаёт их модели вместе с вопросом → модель генерирует ответ на основе найденного контекста.

Как это работает: простой пайплайн

Не нужно строить сложную инфраструктуру, чтобы понять принцип. Упрощённая схема:

Этап Что происходит и зачем
1. Источник Документы: редполитика, кейсы, термины, чек-листы, Q&A из чатов
2. Chunking (разбиение) Документы делятся на атомарные фрагменты: 1 концепция = 1 чанк (200–500 токенов). Если чанк слишком большой — поиск по базе тянет лишний шум и снижает точность
3. Метаданные Каждый чанк помечается тегами: тип, тема, дата. Позволяет фильтровать при поиске
4. Индексирование Чанки преобразуются в векторные эмбеддинги и хранятся в вектор-БД
5. Retrieval (поиск) При запросе система ищет релевантные чанки по смысловому сходству
6. Generation Модель получает запрос + релевантный контекст → генерирует ответ
Для начала не нужна вектор-БД. Достаточно структурированной папки с документами и модели с поддержкой загрузки файлов.

RAG vs fine-tuning и Custom GPT с файлами: когда что выбирать

Три подхода к тому, чтобы модель работала с вашими данными. Их часто путают — и в итоге выбирают не то.

Fine-tuning — дообучение модели на ваших данных. Модель «запоминает» стиль, формат, специфические паттерны. Работает, когда нужно изменить поведение модели: иначе форматировать ответы, писать в специфическом стиле, понимать нишевую терминологию без объяснений.

RAG — передача актуального контекста в момент запроса. Работает, когда нужна фактическая точность: конкретные кейсы, актуальные цены, свежие данные. Fine-tuning не обновляется — обученная модель знает только то, что было в датасете на момент обучения.

Custom GPT с файлами (или Claude Projects) — самый низкий порог входа. Загружаете документы, GPT их «видит» и использует. Фактически это RAG без инфраструктуры, реализованный внутри платформы. Ограничения: нет контроля над разбиением на чанки, нет метаданных, непрозрачный поиск по базе.

Параметр RAG Fine-tuning Custom GPT / Projects
Стоимость Средняя (инфраструктура + API) Высокая (датасет + обучение) Низкая (только подписка)
Скорость обновления Быстро — добавил документ, сразу работает Медленно — нужно переобучать Быстро — перезалил файлы
Фактическая точность Высокая при хорошем поиске по базе Средняя — модель «помнит», не «читает» Средняя — поиск по базе непрозрачен
Сложность настройки Средняя (нужен технический навык) Высокая (датасет, обучение, деплой) Минимальная (загрузить файлы)
Лучше всего для Фактические данные, частые обновления Стиль, формат, специфический вывод Быстрый старт, небольшая команда

Практическая рекомендация для SEO-команды: начинать с RAG. Это оптимальный баланс между усилиями и результатом. Fine-tuning оправдывает себя, когда у вас уже есть рабочий RAG-пайплайн и чёткое понимание, что именно нужно изменить в поведении модели. Custom GPT с файлами — отличный старт для проверки гипотезы перед инвестицией в инфраструктуру.

RAG и fine-tuning — не взаимоисключающие подходы. Можно использовать fine-tuned модель с RAG-пайплайном: модель настроена на ваш стиль и формат, RAG обеспечивает фактическую точность через актуальную базу.
Важная оговорка: RAG не универсален для всех сценариев. Если задача — не отвечать на вопрос по базе, а качественно пересказывать один большой документ целиком, RAG может быть не лучшим первым выбором. В таких кейсах проблема не в поиске по базе, а в том, что вам нужен полноценный контроль над обработкой всего источника, а не выборочных чанков. Поэтому для Q&A по внутренним данным и часто обновляемой базе RAG обычно оптимален, а для некоторых задач полного пересказа, строгого форматирования или устойчивого поведения модели может потребоваться другой подход.

Работа до RAG и после: конкретный пример

Задача: написать статью для блога в стиле автора, с правильной терминологией, с нужными CTA.

Без RAG С RAG
Каждый раз пишем промпт заново: «ты SEO-эксперт, вот тон, вот стиль...» База содержит редполитику и примеры. Контекст достаётся автоматически
После 3-й статьи голос начинает «плыть» Голос стабилен — контекст не зависит от длины сессии
CTA формулируется вручную или копируется из прошлых статей Из базы извлекается актуальный список услуг с правильными формулировками
Внутренние ссылки расставляются вручную — нужно помнить все существующие статьи База содержит карту статей и кластеров → ссылки предлагаются автоматически по теме
Перепроверка терминологии вручную Словарь из базы обеспечивает консистентность терминов
Время на подготовку контекста: 20–40 минут Время на подготовку контекста: 2–5 минут

Тот же принцип работает для аудитов: база накапливает типовые паттерны ошибок по нишам, чек-листы, примеры из кейсов. Вместо «вспоминать» — «получить нужное».

Реальный пример: документы и промпты

Вот как это выглядит на практике — три уровня: сам документ в базе, промпт, который его использует, и что получает модель на выходе.

Шаг 1 — Документ в базе (чанк редполитики)

Файл: editorial-voice.md

Метаданные чанка: 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 даст случайную терминологию, без ссылок и «в современном мире». С RAG — стабильный результат с каждой итерации.

Что класть в RAG первым: по скорости отдачи

Не нужно строить идеальную базу с нуля. Начинать нужно с того, что снимает боль прямо сейчас.

Приоритет Что добавлять и почему даёт быстрый эффект
1 Редполитика + примеры голоса Сразу стабилизирует тон всего производимого контента
2 Словарь терминов Убирает разброс: один термин = одно слово во всех материалах
3 Список услуг/продуктов с CTA Правильные формулировки оферов без ручного копирования
4 Карта внутренних ссылок Автоматические предложения по перелинковке при написании статей
5 Кейсы с цифрами Готовые примеры для статей, предложений, аудитов
6 FAQ из реальных вопросов Структура для SEO-контента, отражающая реальный спрос
7 Чек-листы и фреймворки Повторяемые рабочие процессы без «вспоминания»

Риск плохого RAG: уверенный ответ не по тем документам

Внимание: без нормального поиска по базе вы не ускоряете работу — вы автоматизируете хаос. Только быстрее и увереннее.

Если поиск по базе настроен плохо — модель будет звучать уверенно, но отвечать на основе нерелевантных документов. Это хуже, чем отсутствие RAG, потому что ошибки становятся менее заметными.

Признаки плохого поиска по базе:

Решение: тестировать поиск по базе отдельно от генерации ответа. Перед внедрением проверяйте — по данному запросу достаются нужные чанки? Если нет — проблема в разбиении или метаданных, а не в модели.

Что реально влияет на качество поиска по базе

Базовый векторный поиск работает — но только до определённого масштаба. Когда база вырастает за 500 документов, а запросы становятся сложнее, стандартный поиск по сходству начинает давать сбои. Вот что реально улучшает поиск по базе на практике.

Гибридный поиск: смысловой поиск + поиск по точным словам. Классический смысловой векторный поиск (dense retrieval) хорошо находит по смыслу, но плохо справляется с точными совпадениями: именами, аббревиатурами, специфическими терминами. Поиск по точным словам (sparse retrieval) на основе BM25 — наоборот: отлично работает по буквальным совпадениям, но хуже по смыслу.

Гибридный поиск объединяет оба подхода: поиск по смыслу и поиск по точным словам. Запрос «настройка canonical для пагинации» найдёт и документы, где слово «canonical» встречается буквально, и те, где говорится о дублях и структуре URL. Результаты объединяются через Reciprocal Rank Fusion (RRF), то есть через простое объединение рангов, — это понятный и эффективный метод.

Reranking: повторная проверка найденных результатов. После первичного поиска (20 лучших кандидатов) reranker — отдельная модель повторной проверки релевантности — переоценивает результаты по паре «запрос + документ». Это дороже простого поиска по косинусному сходству, но значительно точнее. Я использую Cohere Rerank или bge-reranker-v2 для небольших проектов. Разница заметна сразу: без reranker в 3 самых релевантных фрагмента часто попадают структурно похожие, но семантически далёкие чанки.

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

Фильтры по метаданным: сначала сужаем, потом ищем. Если запрос явно относится к определённой категории документов — фильтруйте перед поиском. Запрос про e-commerce кейсы не должен искать по всей базе включая редполитику и технические чек-листы. Фильтр type:case AND niche:ecommerce сократит пространство поиска и повысит точность.

Техника Что улучшает Когда применять
Гибридный поиск Покрытие: находит и по смыслу, и по точным словам Когда есть специфические термины или аббревиатуры
Reranking Точность в первых K результатах: правильные документы выше в списке База > 200 документов, запросы разнообразные
Фильтры по метаданным Скорость и релевантность: меньше шума в результатах Когда документы имеют чёткие типы и категории
Query decomposition Покрытие сложных запросов через подзапросы Многоаспектные вопросы («как и когда и зачем»)
Агентный поиск Итеративный поиск для многошаговых задач Сложные аналитические задачи, не однозначные запросы

Разбиение запроса на подзапросы решает проблему сложных запросов. «Какие технические проблемы типичны для медицинских сайтов и что делать с дублями?» — это два разных вопроса. Система разбивает его на подзапросы, выполняет поиск по каждому, объединяет результаты. Реализуется через LlamaIndex SubQuestionQueryEngine или простой скрипт с несколькими последовательными поисками.

Агентный поиск идёт дальше: модель сама решает, какие запросы выполнить и сколько итераций нужно. Для сложных аналитических задач это даёт качественный скачок. Но для большинства SEO-задач (контент, брифы, FAQ) достаточно гибридного поиска и reranking.

Порядок внедрения по приоритету: 1) нормальное разбиение на чанки и метаданные, 2) гибридный поиск, 3) reranking. Агентный поиск — только когда базовые вещи уже работают стабильно.

Как оценивать RAG: точность, релевантность, полнота, hit-rate и MRR

Без метрик RAG — это «кажется работает». С метриками — «работает на 78% hit-rate, нужно улучшить поиск по базе на запросах типа X». Это разница между инженерным подходом и надеждой на лучшее.

Метрики делятся на два уровня: оценка поиска по базе (нашли ли нужное?) и оценка генерации ответа (правильно ли ответили на основе найденного?).

Метрики поиска по базе:

Метрика Что измеряет Когда использовать
Hit-rate (Recall@K) Доля запросов, где нужный документ попал в первые K результатов Базовая проверка: находим ли вообще нужное
MRR (Mean Reciprocal Rank) Средняя обратная позиция первого релевантного результата Важен ли порядок — первый результат самый важный
Precision@K Доля релевантных документов среди первых K результатов Когда нужно минимизировать нерелевантный контекст
NDCG Качество ранжирования с учётом позиции и степени релевантности Детальная оценка качества сортировки результатов

Метрики генерации ответа: здесь оцениваем сам ответ модели.

Как запустить оценку на практике. Начните с выборочной ручной проверки: выберите 20–30 тестовых запросов с заранее известными правильными ответами. Проверьте вручную, что поиск по базе достаёт нужные документы и что генерация ответа корректна. Запишите результаты в таблицу. Это занимает день и сразу показывает главные проблемы.

После первичной ручной оценки можно автоматизировать через специализированные фреймворки: RAGAS (open-source), TruLens, DeepEval. Они автоматически вычисляют groundedness и релевантность через LLM-as-judge — модель оценивает качество ответов другой модели.

Ещё одна ошибка — оценивать RAG только по качеству ответа и игнорировать стоимость пайплайна. В рабочей версии системы важны не только groundedness и hit-rate, но и latency, цена одного запроса, длина передаваемого контекста и наблюдаемость системы. Если поиск по базе формально точный, но на каждый ответ тратится слишком много токенов, времени и промежуточных запросов, такой пайплайн быстро становится дорогим и неудобным для команды. Поэтому нормальная оценка RAG — это всегда качество + скорость + стоимость + прозрачность того, какие документы реально были использованы.

Хороший рабочий ориентир для SEO-базы: hit-rate@5 выше 80% (нужный документ попадает в пятёрку результатов в 8 из 10 запросов). Если ниже — проблема в разбиении на чанки или модели эмбеддингов, не в промптах генерации.

Что не надо класть в базу знаний

Плохо структурированная или загрязнённая база хуже пустой — она создаёт противоречия и шум в ответах модели.

RAG умножает то, что уже есть. База должна строиться на реальной экспертизе, а не на скопированных материалах. Если в базе нет сильных кейсов — RAG не добавит их.

Инструменты по уровням

Старт — один человек, до 100 документов

Организация базы

Obsidian или Notion — структурированные папки, теги, связи между документами. Не нужна специальная инфраструктура.

Простой RAG без инфраструктуры

Claude / ChatGPT с загрузкой файлов. Качество структуры и метаданных важнее выбора фреймворка.

Команда — 100–10K документов

RAG-пайплайн

LlamaIndex или LangChain — управление документами, разбиение на чанки, поиск по базе. Подходит при повторяемых задачах и интеграции с CMS.

Вектор-БД

Chroma (локально), Qdrant или Pinecone — хранение эмбеддингов. Выбор зависит от объёма и требований к латентности.

Как собрать базу от нуля: пошаговая инструкция

Не нужна вектор-БД и инженер для старта. Вот последовательность, которая работает без инфраструктуры.

01

Соберите исходники

Что брать: редполитику с примерами голоса, 2–3 эталонные статьи, словарь терминов (даже 30–50 пунктов — уже ценно), список услуг/продуктов с формулировками CTA, кейсы с цифрами, FAQ из реальных вопросов клиентов.

Где искать: старые чаты с повторяющимися ответами, Notion / Google Docs, собственные статьи и брифы, записи созвонов с клиентами.

02

Нарежьте документы на чанки

Правило: 1 концепция = 1 чанк (200–500 токенов, ~150–350 слов). Не кладите редполитику и кейс в один файл — они разного типа и будут мешать друг другу при поиске.

  • Редполитику разбейте по разделам: голос / структура / запреты / CTA — 4 чанка.
  • Каждый кейс — отдельный чанк: ниша + проблема + что сделали + цифры.
  • Термины: один термин = одна запись (название + определение + пример использования).
03

Добавьте метаданные к каждому чанку

Минимальный набор для начала:

Метаданные чанка (в начале файла или отдельным полем)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

Без метаданных поиск по базе возвращает нерелевантное — модель будет использовать чужие кейсы или устаревшие правила.

04

Начните с загрузки файлов — без вектор-БД

Загрузите 5–10 ключевых документов напрямую в Claude или ChatGPT (Projects / Custom GPT с файлами). Проверьте поиск по базе вручную: задайте вопрос и посмотрите, что достаётся.

  • «Какой CTA использовать в статье о техническом аудите?» → должна вернуться редполитика.
  • «Как правильно писать: crawl budget или краулинговый бюджет?» → должен вернуться словарь.
  • «Какие кейсы есть по e-commerce?» → должны вернуться только кейсы с тегом e-commerce.

Если ответы нерелевантны — проблема в разбиении или метаданных, не в модели.

05

Напишите три базовых промпта

Три задачи, которые закроют 80% работы с контентом:

Промпт 1 — Голос автораИспользуй редполитику из базы знаний.
Напиши [тип контента: абзац / секцию / FAQ] о [тема].
Стиль — из editorial-voice.md. Конкретные цифры, без клише.
CTA по правилам из базы, если нужен.

Промпт 2 — Проверка терминологииПроверь текст ниже на соответствие словарю из базы.
Замени нестандартные формулировки на принятые.
Текст: [вставить текст]

Промпт 3 — Внутренние ссылкиПо карте статей из базы: предложи 2-3 релевантные
внутренние ссылки для материала о [тема].
Объясни, почему каждая ссылка уместна.
06

Проверьте поиск по базе отдельно от генерации

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

  • Запросите базу: «Покажи, какие документы ты используешь для ответа на этот вопрос».
  • Если ответ нерелевантен — меняйте чанкинг или метаданные, не промпт генерации.
  • Рабочий критерий: для любого запроса база должна возвращать нужный тип документа (policy → редполитика, не кейс).

После того как поиск по базе работает стабильно — подключайте LlamaIndex или Qdrant для масштабирования.

Минимальный рабочий RAG для SEO: 1 файл редполитики + 1 файл словаря + 1 карта статей + три промпта выше. Это можно собрать за один рабочий день и сразу использовать.

SEO-задачи, где RAG работает прямо сейчас

RAG для SEO — это про организацию того, что уже есть. Начните с редполитики и словаря. Добавьте карту внутренних ссылок и кейсы. Это уже рабочий RAG для производства контента.
Как это работает у меня. Базу собирал последовательно: сначала редполитика и словарь терминов (~40 записей). Потом карта статей и услуг с правильными формулировками CTA. Потом кейсы — каждый в отдельном чанке с тегами ниши, типа проблемы и конкретными цифрами. Сейчас база содержит около 120 документов. Задача «написать введение в статью о техаудите в стиле автора с правильными терминами» занимает 2 минуты вместо 25. Важнее — результат стабильный: не нужно каждый раз переписывать голос заново. Модель берёт нужный контекст из базы, а не пытается угадать стиль из подсказок в промпте.

RAG, GEO и AI Overviews: почему база знаний влияет на AI-цитируемость

Внутренний RAG и внешняя AI-видимость — связанные вещи. Не очевидно, но работает именно так.

AI Overviews в Google, ChatGPT с поиском, Perplexity — все они извлекают информацию из открытых источников по той же логике, что и ваш RAG. Им нужны структурированные, авторитетные, хорошо цитируемые материалы. Контент, созданный с помощью грамотного RAG, обычно лучше удовлетворяет этим критериям: конкретные факты, чёткие определения, последовательный голос без противоречий.

GEO (Generative Engine Optimization) — подход к оптимизации контента под AI-генераторы ответов. Суть: структурированные данные, явные цитаты, определения терминов, конкретные числа. Всё это — именно то, что хорошая RAG-база уже содержит как стандарт.

Практическая связь работает так: ваша RAG-база накапливает точные формулировки, конкретные данные, структурированные ответы на реальные вопросы. Контент, созданный на этой базе, органично содержит то, что AI-системы ищут для цитирования — факты с источниками, определения, конкретику.

Кроме того, сама база знаний может стать источником структурированного контента для AI: публичные FAQ, глоссарии терминов, структурированные описания услуг и процессов. Это напрямую повышает вероятность цитирования в AI Overviews и ответах ChatGPT.

Три вещи из базы знаний, которые напрямую улучшают AI-цитируемость: глоссарий терминов с чёткими определениями, FAQ с конкретными ответами (без воды), структурированные кейсы с цифрами. Это одновременно хороший RAG и хороший GEO.

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

Когда RAG не нужен

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

Объём знаний помещается в один промпт. Если вся нужная информация — 2-3 страницы текста, которые редко меняются, просто положите её в системный промпт. Вектор-БД и разбиение на чанки для 20 документов — это лишняя сложность, которая не окупается.

Задача разовая, без повторений. RAG окупается на масштабе. Если вы один раз пишете один документ — проще сделать это вручную, чем строить пайплайн.

Источники противоречивые или неструктурированные. RAG не исправляет плохую базу — он её усиливает. Если документы противоречат друг другу, устарели или написаны в хаотичном стиле, сначала нужно привести базу в порядок. Иначе получите уверенные ответы на основе некачественных данных.

Нет ответственного за поддержку базы. База знаний требует регулярного обновления: кейсы устаревают, цены меняются, методы эволюционируют. Если нет человека, который будет добавлять новые документы и архивировать устаревшие, база через 2-3 месяца станет источником дезинформации.

Информация статична и никогда не обновляется. Если у вас есть 50 неизменных определений терминов — можно просто встроить их в промпт. Нет смысла в инфраструктуре ради инфраструктуры.

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

Проблемы рабочей RAG-системы: права доступа, версии документов, свежесть данных

MVP RAG собирается за день. Рабочая версия системы, которая работает надёжно через полгода, — это другая задача. Вот проблемы, которые возникают у всех, кто выходит за рамки прототипа.

Версии документов. Какая версия кейса — каноническая? Вы исправили цифры в прошлом квартале. Старая версия тоже лежит в базе? Если да — поиск по базе будет периодически доставать устаревшие данные, и модель будет уверенно цитировать неверные факты.

Решение: явная версионность. Каждый документ имеет статус: status: active / archived / draft. Поиск по базе фильтрует только status: active. При обновлении — старая версия получает status: archived, новая добавляется с status: active. Никогда не удалять документы — архивировать.

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

Решение: метка updated на каждом документе + политика ревизии. Документы типа «цены» проверяются ежемесячно, кейсы — раз в квартал, редполитика — раз в полгода. Просроченные документы автоматически помечаются для ревью.

Права доступа. Не все документы должны быть доступны всем запросам. Конкурентный анализ, внутренние цены для переговоров, данные конкретных клиентов, персональные данные — это разные уровни доступа. В простом RAG всё смешано в одной базе.

Решение: разделение индексов (отдельные базы для публичного и приватного контента) или строгие фильтры по метаданным на уровне запроса. Если работаете с персональными данными — это уже не просто хорошая практика, а требование GDPR/закона о персональных данных.

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

Решение простое: один владелец базы знаний. Его задача — ревью новых документов перед добавлением, периодическая чистка, обновление при изменениях в продукте или методологии. Без этого любой RAG деградирует.

Безопасность. RAG не делает систему автоматически безопасной только потому, что модель отвечает «по документам». Наоборот: если в базу попадает токсичный, ошибочный или чувствительный контент, модель может уверенно воспроизводить его в ответах. Поэтому для рабочей базы нужны не только роли доступа и свежесть документов, но и базовая проверка на опасные сценарии: утечку лишних данных, нежелательные инструкции внутри документов и ответы на пограничные запросы.

Рабочий RAG, который не развалится через несколько месяцев, — это не только технология, но и процесс. Chunking и вектор-БД — меньшая часть работы. Больший вклад: политики обновления, контроль версий, распределение ответственности. Это SEO-менеджмент, применённый к базе знаний.

FAQ: эмбеддинги, векторная база, гибридный поиск, reranker, агентный поиск

Эмбеддинги — числовые векторы, в которые модель кодирует текст. Смысл: семантически похожие фрагменты получают близкие векторы в многомерном пространстве. Именно это позволяет находить релевантные документы по смыслу запроса, а не по точному совпадению слов. Запрос «как повысить трафик» найдёт документ со словами «органический рост» и «поисковые системы», потому что они семантически близки.

Это специализированное хранилище для эмбеддингов с оптимизированными индексами для поиска ближайших соседей. Популярные варианты: Chroma (для локального запуска), Qdrant (рабочий контур, на своём сервере), Pinecone (облако), Weaviate. Обычная реляционная база данных для этого не подходит — там нет алгоритмов быстрого векторного поиска, а хранение 1536-мерных векторов крайне неэффективно.

Поиск по ключевым словам (BM25, TF-IDF) ищет точные совпадения слов и их вариаций. Поиск по смыслу работает через эмбеддинги и находит близкие по значению формулировки. Запрос «настройка обхода сайта» найдёт документ с «crawl budget» и «Googlebot», даже без точных слов из запроса. Каждый подход имеет слепые пятна: поиск по ключевым словам теряет синонимы и парафразы, поиск по смыслу теряет аббревиатуры и точные имена. Гибридный поиск объединяет оба — это стандарт для рабочей системы.

Разбиение на чанки — это деление документа на фрагменты перед индексированием. Оптимальный диапазон для большинства задач: 200–500 токенов (~150–350 слов). Слишком маленький чанк (50 токенов) теряет контекст — поиск по базе находит правильный фрагмент, но модели не хватает информации для ответа. Слишком большой (2000 токенов) тащит нерелевантный контент и засоряет контекст. Для технических инструкций лучше разбивать по смысловым блокам (один шаг = один чанк), а не по количеству токенов.

Reranker — модель второго прохода, то есть модель повторной проверки релевантности, которая переоценивает найденные кандидаты по паре «запрос + документ». Первичный поиск находит 20 лучших кандидатов через быстрый поиск ближайших векторов. Reranker анализирует каждую пару и выбирает 3 самых релевантных фрагмента. Это значительно точнее, чем только векторное сходство, потому что такая модель учитывает взаимный контекст запроса и документа. Популярные варианты: Cohere Rerank, bge-reranker-v2-m3, BAAI/bge-reranker-large.

Гибридный поиск — комбинация смыслового векторного поиска и поиска по точным словам. Результаты объединяются через Reciprocal Rank Fusion (RRF), то есть через объединение рангов, или через взвешенное слияние. Работает лучше каждого из подходов в отдельности: смысловой векторный поиск находит концептуально похожее, поиск по точным словам — точные названия, аббревиатуры, имена собственные. Это стандартный подход для рабочей RAG-системы с разнородным контентом.

Агентный поиск — подход, при котором модель сама решает, что искать и сколько итераций поиска выполнить. Вместо одного запроса к базе агент анализирует задачу, разбивает её на подзапросы, выполняет несколько поисков и синтезирует финальный ответ. Нужен для сложных аналитических задач: «Как мы решали проблему дублей в e-commerce для крупных каталогов?» — это не один поиск, а минимум три. Для простых задач (написать абзац, проверить термин) агентный поиск избыточен.

Проверенные варианты: text-embedding-3-large от OpenAI (мультиязычный, высокое качество, платный), multilingual-e5-large от Microsoft (открытая, специально для нескольких языков), bge-m3 от BAAI (открытая, отличное качество на русском). Для старта подойдёт text-embedding-3-small — дешевле примерно в 5 раз, при этом достаточно точен для большинства задач. Проверяйте на своих данных: метрика hit-rate@5 покажет реальную разницу между моделями.

Да. Загрузка документов в Claude Projects или ChatGPT Custom GPT — это RAG без кода. Достаточно структурированных файлов с правильными метаданными. Для небольшой команды (до 50 документов) это полностью рабочее решение. Если нужна большая база или интеграция с внешними сервисами — понадобится минимальный технический навык: LlamaIndex с готовыми примерами или платформы без программирования вроде Flowise, Dify. Полноценная рабочая система уже требует инженера.

Зависит от типа документа. Редполитика — при изменении позиционирования или голоса (раз в полгода или по событию). Кейсы — после каждого завершённого проекта. Словарь терминов — при появлении новых понятий в работе. Цены и услуги — сразу при изменении, без задержки. Технические чек-листы — после значимых изменений алгоритмов или инструментов. Главный принцип: устаревший документ опаснее, чем отсутствующий — модель отвечает уверенно на основе неактуальных данных.

Не всегда. Если у вас 5–10 стабильных документов, редкие обновления и одна-две повторяемые задачи, может хватить Projects / Custom GPT с файлами или просто хорошо собранного промпта. RAG появляется не там, где «хочется модную технологию», а там, где контекст начинает расползаться: документов много, данные обновляются, термины плавают, кейсы дублируются, а команда тратит время на постоянный ручной поиск. То есть RAG — это не про магию, а про момент, когда ручное управление знаниями становится дороже, чем сборка нормального слоя поиска по базе.

Хотите внедрить RAG в SEO-процессы команды?

Разберём конкретный пайплайн под ваши задачи: что и как хранить, как настроить поиск по базе, с чего начать без сложной инфраструктуры.

Написать в Telegram
Кириченко Станислав
Кириченко Станислав
20+ лет в SEO, сложные технические аудиты, second opinion, AI-автоматизация · Подробнее обо мне