За год работы с LLM я упирался в одну и ту же стену — модель выдумывает детали. Буквально. Спрашиваю: "Как настроить миграцию в нашем проекте?" — а она выдаёт правдоподобную чушь с уверенностью академика. Или просит документацию по продукту, которого у неё нет в контексте — и она просто фантазирует.
RAG — Retrieval-Augmented Generation — решает именно эту проблему. Вместо того чтобы надеяться, что языковая модель где-то там внутри "знает" ответ, мы подсовываем ей релевантные документы в момент генерации. Звучит просто. На практике — три месяца возни, прежде чем заработало нормально. Делюсь тем, что понял.
Зачем вообще заморачиваться с RAG
Проблема в том, что LLM обучены на данных до определённой даты. Они не знают вашу внутреннюю документацию, базу кейсов поддержки, кодовую базу, таблицы с метриками. Fine-tuning — переобучение модели на своих данных — работает, но это дорого, долго и к тому же часть "родных" навыков модели при этом теряется.
RAG предлагает другой путь: не менять модель, а менять то, что она видит при ответе. В каждый запрос подмешиваются релевантные фрагменты из вашей базы знаний. Модель отвечает на основе этих фрагментов — и вероятность галлюцинаций падает драматически.
Мне RAG понадобился, когда мы с командой делали внутреннего чат-бота для саппорта. Сотрудники задают вопросы по продукту, техдокументации, процессам. Без RAG бот врал в трёх случаях из десяти. С RAG — в одном из пятидесяти, и то в тех случаях, где фрагменты были неполные.
Из чего RAG состоит — минимум, который реально работает
Архитектура RAG состоит из четырёх узлов. Разберу по порядку.
Источник данных. Это может быть папка с PDF, база Notion, API какой-нибудь системы, CSV с таблицами. На старте я загрузил в Vector DB экспорт из нашего Notion — около двухсот страниц. Звучит много, но по объёму это копейки.
Разбиение на чанки. Текст нельзя засовывать в эмбеддинг-модель целиком — он либо не влезет в контекст, либо потеряет релевантность. Нужно разбить на фрагменты — чанки. Обычно это 500–1500 токенов. И вот здесь я убил неделю, подбирая размер.
Слишком мелкие чанки — теряется контекст, модель не видит связей. Слишком крупные — размывается релевантность, в ответ подтягиваются не те фрагменты. Я остановился на 800 токенах с перекрытием в 100 токенов. Перекрытие важно: если мысль разрезана между чанками, без перекрытия она развалится.
Эмбеддинги и векторная база. Каждый чанк прогоняется через эмбеддинг-модель и превращается в вектор — массив чисел, который описывает смысл текста. Эти вектора складываются в векторную базу. Когда пользователь задаёт вопрос, он тоже переводится в вектор, и в базе ищутся ближайшие по смыслу чанки.
Я использовал сначала OpenAI Embeddings — дёшево и сердито, работает из коробки. Потом переехал на sentence-transformers для части задач, потому что хотел запускать эмбеддинги локально и не зависеть от API.
Генерация. Найденные чанки подставляются в промпт вместе с вопросом пользователя. Модель отвечает на основе этих фрагментов. Если фрагмент не содержит ответа — она честно говорит, что не знает. Это уже большой шаг.
Три грабли, на которые я наступил
Первая — плохое разбиение. Сначала я резал документы тупо по символам: каждые 1000 символов. Результат — абзацы пополам, таблицы разорваны, в чанках остаётся мусор вроде заголовков без текста. Перешёл на разбиение по семантике: смотрю на структуру документа, режу по смысловым блокам. Это добавило головной боли при настройке, но качество ответов выросло процентов на тридцать.
Вторая — неправильный поиск по метаданным. У нас в базе были документы разных версий. Бот упорно подтягивал старую версию процедуры, хотя новая лежала рядом. Оказалось, что я не добавил метаданные — дата, продукт, тип документа. Теперь фильтрую поиск по метаданным перед тем, как искать по векторам.
Третья — промпт. Я недооценил роль промпта. Без инструкции "отвечай только на основе предоставленных фрагментов" модель продолжала фантазировать, опираясь на свои знания. Добавил строчку — и бот начал честно говорить "я не нашёл информации по этому вопросу" вместо того чтобы выдумывать ответ.
Инструменты, которые реально использую
Для быстрого прототипа — LlamaIndex. Он берёт на себя всю механику: загрузка документов, разбиение, индексация, поиск. Можно запустить рабочий RAG за вечер.
Для продакшена — ChromaDB или Qdrant как векторная база. Они быстрые, поддерживают фильтрацию по метаданным и нормально масштабируются. Qdrant я выбрал для себя, потому что у него хороший API и есть облачный хостинг, когда не хочется возиться с сервером.
Эмбеддинги — OpenAI text-embedding-3-small для большинства задач. Для русского языка хорошо работает модель sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2 — она компактная, быстрая, запускается на ноутбуке.
Что в итоге
RAG не волшебная таблетка. Это инфраструктура, которая требует настройки, мониторинга и итераций. Первые версии будут отдавать нерелевантные фрагменты, модель будет путаться в ответах, поиск будет лажать на длинных запросах.
Но когда оно заработает — это другой уровень. Мы получили бота, который отвечает на вопросы по продукту так, что сотрудники перестали спрашивать в чате друг друга. Это десятки часов сэкономленного времени в неделю.
Главное, что я понял: RAG — это не "включил и забыл". Это живая система. Документы обновляются, запросы пользователей показывают дыры в базе, качество поиска нужно мерить и улучшать. Но если вам нужно, чтобы LLM отвечал по вашим данным, а не по своему внутреннему словарю — без RAG никак.
