Retrieval Augmented Generation - архитектура, которая решает главную проблему языковой модели: она ничего не знает про ваши данные и с уверенностью выдумывает факты, если ответа не помнит. За последний год я собрал десяток таких систем - от бота с базой знаний интернет-магазина на WooCommerce до ассистента поддержки на aiogram - и в каждом случае RAG оказался единственным рабочим способом дать модели актуальную информацию без дорогого переобучения с нуля.
Что такое Retrieval Augmented Generation простыми словами
Представьте экзамен с открытой книгой. Студент без RAG отвечает по памяти - и если что-то забыл, додумывает похожее на правду. Студент с RAG перед ответом открывает нужную страницу учебника и цитирует её. Модель работает так же: вместо того чтобы полагаться только на веса, обученные месяцы назад, она получает вместе с вопросом пользователя выдержки из ваших документов - базы знаний, каталога товаров, регламентов поддержки - и формирует ответ на их основе.
Технически RAG склеивает два независимых процесса: поиск (retrieval) по внешнему хранилищу и генерацию (generation) текста языковой моделью. Поиск находит несколько фрагментов текста, максимально похожих на запрос по смыслу, а не по совпадению слов. Генерация превращает эти фрагменты и вопрос пользователя в связный ответ. Ни один из процессов не работает сам по себе: без поиска модель галлюцинирует, без генерации получится просто список цитат без ответа на вопрос.
Из каких блоков состоит RAG-пайплайн
На практике пайплайн строится из шести шагов, и я прохожу их в одном порядке в любом проекте - будь то бот техподдержки на aiogram или интеграция для CRM на n8n.
- Разбивка документов на чанки - PDF, статьи базы знаний или карточки товаров режутся на куски по 300-800 токенов. Слишком крупный чанк размывает релевантность, слишком мелкий обрубает контекст на середине мысли.
- Векторизация - каждый чанк превращается в эмбеддинг, числовой вектор, кодирующий смысл текста. Использую модели вроде text-embedding‑3 от OpenAI или voyage‑3 - разница в качестве поиска между дешёвой и качественной моделью эмбеддингов ощутимее, чем разница между моделями генерации.
- Хранение в векторной базе - эмбеддинги вместе с исходным текстом складываются в индекс, оптимизированный под поиск по косинусному сходству.
- Семантический поиск - запрос пользователя тоже превращается в вектор, и база возвращает 3-10 ближайших по смыслу чанков.
- Reranking (не всегда обязателен) - отдельная модель пересортировывает найденные фрагменты по фактической релевантности запросу, отсекая случайные совпадения.
- Сборка промпта и генерация - найденные фрагменты вставляются в системный промпт вместе с вопросом, и модель, у меня чаще всего Claude через API, формирует ответ, опираясь только на переданный контекст.
Вот как выглядит шаг поиска на Python, если база - Postgres с расширением pgvector.
from openai import OpenAI
client = OpenAI()
def search(query, k=5):
vector = client.embeddings.create(
model="text-embedding-3-small", input=query
).data[0].embedding
return db.query(
"SELECT content FROM knowledge_chunks "
"ORDER BY embedding <=> %s LIMIT %s",
(vector, k),
)
Пять строк вместо абзаца объяснений - именно так поиск и работает под капотом, независимо от того, обёрнут он в LangChain, LlamaIndex или написан руками.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Векторные базы и эмбеддинги - как устроен поиск в RAG-системе
Выбор хранилища эмбеддингов - вопрос не столько технологии, сколько инфраструктуры, которая у клиента уже есть. Если проект крутится на Postgres, беру pgvector и не завожу отдельный сервис. Если нужен быстрый поиск по миллионам записей с фильтрацией по метаданным - Qdrant или Weaviate. Для прототипа хватает Chroma, она поднимается локально за пять минут.
| Хранилище | Где живёт | Когда беру |
|---|---|---|
| pgvector | Расширение для PostgreSQL | Уже есть Postgres, объём до нескольких миллионов чанков |
| Qdrant / Weaviate | Отдельный сервис, self-hosted или облако | Нужна фильтрация по метаданным и высокая скорость поиска |
| Chroma | Встраиваемая, локальный файл | Прототип, MVP, проверка гипотезы |
| Pinecone и подобные | Управляемое зарубежное облако | Только данные без персональной информации о клиентах |
Про Pinecone и подобные зарубежные облачные хранилища отдельно: если в чанках может оказаться переписка с клиентами, их телефоны или адреса, такие данные я храню только на серверах в РФ - того требует локализация персональных данных по 152-ФЗ. Для базы знаний из статей помощи или карточек товаров это ограничение не действует, а вот для истории обращений в поддержку - действует всегда.
RAG или дообучение модели - что выбрать
Дообучение (fine-tuning) меняет веса модели под конкретный стиль или узкую задачу. RAG ничего не меняет в модели - он меняет контекст, который она видит перед ответом. На практике для девяти из десяти запросов клиентов правильный выбор - RAG.
| Критерий | RAG | Fine-tuning |
|---|---|---|
| Обновление данных | Добавил документ - через минуту он в ответах | Нужен новый цикл обучения на новых данных |
| Стоимость запуска | Дешевле: векторная база и промпт | Дороже: подготовка датасета, вычисления, итерации |
| Прозрачность ответа | Можно показать источник - цитату из документа | Модель отвечает «из головы», источник не проверить |
| Когда подходит | Ответы по базе знаний, документации, каталогу | Смена стиля, формата, узкой терминологии |
Дообучение имеет смысл, если нужно изменить саму манеру модели отвечать - например, заставить её всегда возвращать структурированный JSON определённого вида или писать в фирменном тоне без лишних инструкций в промпте. Для задачи «модель должна знать про наши тарифы и договоры» дообучение не подходит в принципе: обучающая выборка устареет при первом же изменении прайса, а RAG просто подхватит новый документ на следующей индексации.
Где я применяю retrieval augmented generation на практике
Три сценария встречаются чаще остальных.
Бот поддержки на aiogram с базой знаний. Клиент присылает регламенты, FAQ, инструкции по возвратам - я режу их на чанки, индексирую в pgvector и подключаю к боту в Telegram. Бот отвечает цитатами из документов, а не общими фразами, и не путает тарифы прошлого года с текущими.
Виджет на сайте (WordPress или Tilda) с ответами по каталогу или документации. Похожая схема, только источник - карточки товаров или статьи помощи, а не внутренние регламенты.
RAG внутри workflow n8n. Например, перед тем как менеджер ответит на обращение, сценарий в n8n делает поиск по базе похожих обращений и подсказывает готовый вариант ответа со ссылкой на прошлый похожий кейс - это экономит минуты на каждом тикете, а на потоке в сотню обращений в день превращается в часы.
Если нужно быстро прогнать документы через чанкинг и векторизацию без готового сервиса, часть таких заготовок для парсинга и подготовки текста я выкладываю в библиотеке готовых скриптов - там есть рабочие куски кода для разбивки PDF и синхронизации с векторной базой.
Типичные ошибки при внедрении RAG
Собрал список по итогам десятка внедрений - все эти грабли наступал сам или чинил в чужом коде.
- Чанки нарезаны механически по количеству символов, без учёта границ абзацев - обрывают предложение на середине, и модель цитирует половину мысли.
- Эмбеддинги считает дешёвая модель ради экономии - поиск находит похожие по форме, а не по смыслу фрагменты, и в ответах начинается путаница.
- Индекс наполнили один раз при запуске и забыли - через три месяца бот отвечает по старому прайсу.
- Reranking пропустили там, где в базе тысячи похожих документов - топ‑5 по косинусному сходству не значит топ‑5 по релевантности.
- Никто не смотрит логи диалогов - если модель начинает путать факты, узнают об этом только из жалобы клиента, а не из мониторинга.
- Экономят на лимите контекста - засовывают в промпт двадцать чанков вместо пяти, модель теряется в лишнем тексте и хуже отвечает даже с правильными данными под рукой.
Чат-бот с базой знаний
AI / RAG
от 50 000 ₽
Подробнее →Частые вопросы
Чем RAG отличается от обычного чат-бота с промптом
Обычный бот с промптом либо держит всю информацию прямо в системном промпте - это работает, пока база знаний укладывается в десяток страниц, - либо отвечает из общих знаний модели без всякой опоры на ваши данные. RAG подбирает релевантные фрагменты под каждый конкретный вопрос из базы любого объёма, поэтому масштабируется на тысячи страниц без раздувания промпта и без потери точности.
Сколько стоит внедрение RAG-системы
У меня чат-бот с базой знаний на RAG стоит от 50 000 ₽ - сюда входит настройка векторной базы, чанкинг документов и подключение к мессенджеру или виджету на сайте. Если нужна дополнительно интеграция с CRM или сложная логика в n8n, оценка идёт от стоимости этой части отдельно, автоматизация в n8n у меня от 25 000 ₽.
Можно ли использовать RAG с Telegram-ботом
Да, это одна из самых частых связок в моей практике: aiogram-бот принимает сообщение, ищет релевантные фрагменты в базе знаний и передаёт их вместе с вопросом в Claude API. Telegram-бот без RAG у меня от 30 000 ₽, с базой знаний на RAG - от 50 000 ₽.
Какие данные можно загружать в базу знаний без юридических рисков
Публичные материалы - статьи помощи, документацию, карточки товаров, регламенты без персональных данных - можно грузить в любое хранилище, включая зарубежные облачные векторные базы. А вот переписку с клиентами, телефоны и адреса из истории обращений храню только на серверах в РФ - того требует локализация персональных данных по 152-ФЗ, и это правило не обсуждается независимо от удобства сервиса.