Модель умная, но не знает твоих данных. Контекстное окно большое, но не бесконечное. Где-то между этими двумя ограничениями лежит RAG — самая практически важная техника в современном AI-инжиниринге.
RAG (Retrieval-Augmented Generation) — это паттерн, при котором перед запросом к модели сначала находишь релевантные документы во внешней базе, и кладёшь их в контекст вместе с вопросом. Не вместо обучения модели — а вместо попытки впихнуть всю базу знаний в контекст. Это и есть ответ на вопрос «как агент работает с данными, которых не знает».
Возьми реальную задачу: «сделай чат-бот для нашей корпоративной базы знаний». 4000 страниц документации, 200 PDF, внутренние Notion-страницы. Пользователь спрашивает: «как настроить SSO для нового подразделения?».
Ты упираешься в две стены сразу:
GPT-5 / Claude / Gemini обучены на публичном интернете до своего cutoff'а. Они не знают:
Когда модель пытается ответить на такой вопрос — она либо отказывается («не знаю»), либо галлюцинирует (выдумывает правдоподобный ответ). И второй вариант катастрофичнее: пользователь получит уверенный неправильный ответ и поверит ему.
Очевидное решение: «впихну всю документацию в system prompt». На бумаге звучит хорошо. На практике — три проблемы:
Контекст — не место для всей твоей базы. Контекст — это рабочая область, в которой должно быть только то, что нужно прямо сейчас, под этот запрос.
Возвращаемся ко Дню 10: «контекст ≠ история, контекст = проектирование». RAG — это и есть проектирование контекста под конкретный запрос. Не «положить всё». А «найти нужное → положить только это».
RAG — это двухшаговый процесс. Перед запросом к LLM добавляется отдельная стадия поиска по твоей базе. Потом найденные куски вкладываются в контекст вместе с вопросом, и модель отвечает опираясь на них.
Расшифровка названия:
То есть RAG — это не отдельная модель, не специальная LLM. Это паттерн использования обычной LLM с поиском перед ней.
Не через обучение, а через подгрузку нужного куска в контекст под каждый запрос. Динамически.
В контекст уходят 3-5 KB релевантного текста, не вся база. Стоимость запроса — копейки.
Модель видит ровно то, что нужно. Lost in the middle не страшен. Меньше галлюцинаций.
Изменилась инструкция → обновил в базе → агент сразу отвечает по новой. Не надо ждать новую модель.
RAG появился ещё в 2020-м (статья Lewis et al.), но взлетел именно в эпоху LLM, когда стало очевидно: ни одна модель не может «знать всё своё». А вот найти нужное и подать — это инженерная задача, в которой RAG — основной инструмент.
RAG — не единственный способ дать модели «свои данные». Сравним с альтернативами:
Класть всю базу прямо в system prompt каждого запроса.
Когда работает: база маленькая (до 50-100K токенов). Например — один документ-инструкция для бота, который отвечает по этому документу.
Когда ломается: база больше окна (типичный случай). Дорого (платишь за всё каждый раз). Качество падает на длинном контексте.
Когда выбрать: у тебя 5-50 страниц текста, которые редко меняются — может оказаться проще, чем RAG. В остальных случаях — нет.
Берёшь базовую модель и дообучаешь её на своих данных. После — модель «знает» твоё в весах.
Когда работает: для стиля — научить модель писать «как ты». Для навыков — научить решать специфический класс задач. Для формата — стабильно отвечать в определённой структуре.
Когда ломается: для фактов. Fine-tuning плохо запоминает конкретные факты, а если запомнит — то на момент обучения. Обновил документ — модель не знает. Нужно переобучать.
Когда выбрать: нужен особый стиль/формат. Нужны факты — нет, бери RAG.
Дать агенту инструмент search_company_docs(query) через MCP-сервер (см. Кластер 04). Модель сама решает, когда вызвать поиск.
Когда работает: для агентов, где модель иногда нуждается в данных, иногда — нет. Поиск становится одним из инструментов в наборе.
Когда ломается: когда поиск нужен почти всегда. Модель может «забыть» использовать инструмент и ответить из общих знаний (= галлюцинация).
Когда выбрать: в агентах с разнообразными типами запросов, где поиск — одна из нескольких возможностей. Под капотом этого «инструмента» обычно тот же RAG-pipeline.
На каждом запросе, безусловно, выполняется поиск в базе, и найденные куски кладутся в контекст. Модель отвечает, опираясь на них.
Когда работает: когда база критична для каждого ответа. Q&A-боты по документации, юристы, медицинские помощники, support-боты.
Когда ломается: поиск возвращает не то / не находит / возвращает много мусора. Это и есть весь Кластер 05 — учиться делать поиск хорошо.
Когда выбрать: у тебя база знаний больше 50K токенов И запросы пользователей касаются её содержимого. Это 80% реальных корпоративных AI-кейсов.
Что происходит, когда вместо RAG используют что-то другое в неподходящем месте:
Команда тратит месяц на сбор датасета, fine-tuning, оценку. После — модель отвечает правдоподобно на 70% запросов, но точно только на 30%. Факты «расплываются» при обучении.
Корень: fine-tuning не индексирует факты, он сглаживает их. RAG бы достал точную строку из документации.
Технически влезает. Но запросы становятся дорогими ($5-20 за каждый), медленными (10-30 сек), и качество хуже, чем у того же бота с RAG. Модель «утопает» в шуме.
Это типичная ловушка 2024-25, когда стали выходить модели с огромными окнами. «Раз помещается — значит можно». Помещается ≠ работает хорошо.
Пользователь спрашивает «как настроить вход через корпоративный аккаунт», а в документации это называется «конфигурация SSO с провайдером идентификации». Фуллтекст не находит совпадений, RAG бы нашёл по смыслу.
Поэтому в Дне 22 — про эмбеддинги. Это и есть «поиск по смыслу, а не по буквам».
Прежде чем строить RAG — ответь честно: а нужен ли он именно тебе?
RAG оправдан, когда:
RAG не нужен, когда:
Соблазн — сразу проектировать сложный RAG-pipeline с эмбеддингами, чанкингом, реранкером. На практике стартуй проще:
Многие команды теряют недели на сложный RAG, когда им нужен был этап 0 или 1. Эскалируй сложность по мере появления проблем, а не сразу.
«Подключим RAG и галлюцинации исчезнут». Не исчезнут. RAG уменьшает их, но: (а) если поиск нашёл не то, модель будет галлюцинировать на «не том»; (б) даже с правильным контекстом модель иногда вставляет несуществующие детали.
RAG — это значительное улучшение точности, но не гарантия. Для критических областей (медицина, право) — RAG + анти-галлюцинационные приёмы из Дня 25 + ручная проверка.
RAG достаёт из базы то, что в базе есть. Если в базе устаревшие документы, дубликаты, противоречия — поиск принесёт всё это в контекст, и модель ответит хаотично.
Принцип: garbage in → garbage out. Прежде чем строить RAG — почисти базу. Удали устаревшее, объедини дубликаты, разреши противоречия. 80% качества RAG зависит от качества базы, не от хитрости pipeline.
«Что такое X?» — RAG находит, отвечает. Тестируешь 10 таких запросов, всё работает. Запускаешь в прод — на 30% реальных запросов всё ломается.
Реальные запросы пользователей сложнее: с опечатками, с непрямой формулировкой, с двумя темами сразу, с эмоциональной окраской. Тестируй на запросах, которые реально задают пользователи, а не на тех, под которые ты подгоняешь.
RAG — это один компонент, не вся архитектура. В реальном продукте RAG живёт внутри агента — как способ обогащения контекста перед запросом. Всё, что мы строили в Кластерах 02-04 (агенты, память, инструменты) — продолжает работать. RAG — дополнение, не замена.
В Кластере 07 будем собирать реальные продукты, где RAG — один из компонентов, а не центральная сущность.
Открой ChatGPT или Claude и спроси про какую-то очень свежую новость («что случилось вчера»). Современные модели часто покажут поиск (web_search) и потом цитируют найденное — это и есть RAG, только база не твоя, а интернет. Открой Notion AI / Slack AI / Asana с AI-помощником: они тоже используют RAG по содержимому твоего workspace. Замечай: где видишь «источник: ссылка» — там RAG.
Возьми идею AI-агента, который ты хотел бы построить. Пройди по чеклисту из развилки 1: есть ли у тебя база больше 50K токенов? Обновляется? Критична точность? Нужны цитаты? Если 3 из 4 «да» — RAG нужен. Если 1-2 — стартуй с альтернатив (полный контекст или инструмент). Это сильно экономит время на старте.
Если у тебя есть документация (компании, продукта, своих заметок) — открой её и пройдись по трём вопросам: (а) сколько устаревших документов? (б) сколько дубликатов? (в) есть ли противоречия между разными документами? Это упражнение в духе Дня 14 (инварианты). До того, как строить RAG, лучше знать, что в базе. Часто это самый большой источник проблем будущего pipeline.