Спросите ChatGPT про хук useEffect в React, и он ответит уверенно и по делу. Спросите про регламент онбординга в вашей компании, и он либо промолчит, либо уверенно сочинит правдоподобную небылицу. Причина одна: модель училась на публичных данных. Она знает Python, знает историю Рима, знает документацию React. Вашу внутреннюю вики она не открывала ни разу.

Ограничений тут три. Первое: у модели есть дата отсечки обучения, и всё, что появилось после неё, для модели просто не существует. Второе: приватные данные. Ваши доки в Notion и тикеты в Jira остались за бортом тренировки. Третье: дообучить модель на своих данных стоит дорого и тянется днями, а документация меняется каждую неделю. RAG заходит с другой стороны.

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

Открытая книга на экзамене

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

Схематично весь процесс укладывается в три хода: пользователь задаёт вопрос, система находит подходящие куски из ваших документов, модель получает вопрос вместе с этими кусками и отвечает. Ответ с опорой на конкретный источник называют grounded response.

Пять шагов, из которых собран RAG

За аналогией стоит конвейер из пяти шагов. Пройдём по порядку.

  1. Chunking, нарезка. Документы нарезают на короткие фрагменты по 300-600 токенов. Целиком хранить нельзя: PDF на пятьдесят страниц утопит модель в шуме. Фрагменты режут с небольшим перекрытием, чтобы мысль, начавшаяся в конце одного куска, не потерялась на стыке со следующим.
  2. Embeddings, векторизация. Каждый фрагмент превращают в вектор, массив из полутора тысяч чисел, который кодирует смысл текста. Не слова, а именно смысл. Фразы «как уволить сотрудника» и «процедура расторжения трудового договора» состоят из разных слов, но вектор у них почти одинаковый. Поэтому поиск находит документ по смыслу запроса, а не по совпадению ключевых слов.
  3. Векторная база. Векторы надо где-то хранить и быстро искать среди них похожие. Для этого есть специальные базы: ChromaDB ставится одной строчкой и хороша для первых опытов, Qdrant и Pinecone тянут миллионы документов в проде. Обычный Postgres тут не помощник без отдельного расширения под векторный поиск.
  4. Retrieval, поиск. Пользователь задал вопрос. Система превращает его в вектор той же моделью, что и документы, и ищет в базе ближайшие по смыслу фрагменты. Возвращает top-K, обычно от трёх до десяти самых релевантных. Близость считают через косинусную меру: единица это идентичный смысл, ноль это ничего общего.
  5. Генерация. На руках вопрос и, скажем, пять найденных фрагментов. Их складывают в один промпт с инструкцией вроде «отвечай только по этим документам, а если ответа в них нет, честно скажи, что не знаешь». Модель читает фрагменты и формулирует ответ. Инструкция про «не знаю» здесь критична: без неё модель начнёт галлюцинировать и придумывать то, чего в документах нет.

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

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

Отдельная история про код. Для файлов текущего репозитория RAG почти всегда лишний: встроенный grep находит нужное быстрее и точнее.

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

С чего начать

Самый быстрый вход занимает пять минут и не требует своей базы. Есть готовый MCP-сервер context7: он уже проиндексировал документацию сотен библиотек. Добавляете его в файл .mcp.json:

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp@latest"]
    }
  }
}

Перезапускаете Claude Code и спрашиваете, например, как настроить авторизацию в свежей версии Next.js. Агент ответит не из памяти, а из актуальной документации, подтянутой прямо сейчас.

Когда дойдёте до RAG над собственными документами, конвейер будет тот же: нарезка, embeddings, векторная база, retrieval, генерация. Начните с ChromaDB и десятка своих файлов:

pip install chromadb

Задайте пару вопросов и посмотрите, какие фрагменты вернул поиск. Как только увидите, что агент отвечает цитатами из ваших доков, RAG перестанет быть модным словом и станет просто рабочим инструментом.

Тема: Память и знания