На прошлой неделе коллега попросил помочь с одной задачей. Его команда запилила чат-бота на GPT-4 — вроде всё работает, пользователи довольны. Но буквально на третий день кто-то спросил бота про скидки, которые компания давно отменила, а бот уверенно выдал ответ как будто скидки всё ещё действуют. Потом кто-то спросил про старый регламент — и снова выдал устаревшую информацию.
Знакомая ситуация? У меня у самого так было. С GPT всё просто: модель знает данные на момент обучения и не умеет обновляться сама. Решение — построить RAG-систему. Слышали это слово, но не знаете, с чего начать? Разберёмся.
Что такое RAG и почему это вообще работает
RAG — это Retrieval-Augmented Generation, то есть генерация с поиском. Суть: LLM не просто берёт ответ из своего веса, а сначала ищёт релевантный контекст в базе знаний, потом подаёт его модели, и уже на основе этого контекста отвечает.
Звучит очевидно, но эффект огромный. Модель получает якорь — факты из вашего документа — и может на них опираться. Плюс вы контролируете, откуда она берёт информацию. Хотите, чтобы отвечала про внутренний регламент — пожалуйста. Про базу знаний support-команды — тоже можно.
Модель остаётся генеративной, но ответы привязаны к вашим данным. Это снимает главную головную боль: устаревшую информацию и галлюцинации.
Из чего состоит RAG: три слоя
Я разбиваю любую RAG-систему на три слоя — так проще думать.
Первый — индексация. Берём документы и превращаем их в векторы, которые компьютер потом умеет сравнивать. Это называется embedding. Каждый текстовый фрагмент получает набор чисел — свою координату в многомерном пространстве. Близкие по смыслу тексты оказываются рядом.
Второй — поиск. Когда пользователь задаёт вопрос, система переводит его в вектор и ищет самые похожие фрагменты из базы. За это отвечает vector database — специализированное хранилище вроде Pinecone, Qdrant, Weaviate или FAISS.
Третий — генерация. Найденные фрагменты подставляются в промпт вместе с вопросом. LLM видит контекст и отвечает на его основе.
Вот и вся схема. Дальше начинаются детали, которые решают, будет система работать нормально или отлично.
Векторные базы данных: какую выбрать
Я перепробовал несколько и вот моё наблюдение.
Если у вас до 100 тысяч документов и прототип — ставьте FAISS. Это библиотека от Meta, работает локально, ничего не стоит, интегрируется с LangChain и LlamaIndex за полчаса. Для продакшена с высокой нагрузкой — смотрите в сторону Qdrant или Pinecone. Qdrant хорош тем, что есть self-hosted-версия, не надо платить за облако. Pinecone проще, но платите за инфраструктуру.
Главное, на что смотрю при выборе: скорость поиска, скейлинг под нагрузкой и фильтрация по метаданным. Фильтрация — это когда вы хотите искать не просто по тексту, а ещё учитывать дату, категорию, источник. Без этого неудобно.
Chunking: как резать документы
Вот где я наступал на грабли. Первая версия нашего RAG просто брала целые страницы документов и сувала в эмбеддинг. Результат — поиск возвращал огромные куски текста, LLM тонул в шуме и отвечал мимо.
Разбиение на чанки — это искусство. Общее правило: чанк должен быть достаточно маленьким, чтобы быть релевантным запросу, и достаточно большим, чтобы сохранять смысл.
Я обычно работаю с чанками в 500–1000 токенов с перекрытием в 20–30%. Перекрытие важно: если смысл разрезается на границе чанка, поиск его не найдёт. А с перекрытием мы подстраховываемся.
Ещё один приём: hierarchical chunking. Смысл в том, что сначала бьёшь документ на мелкие чанки, потом группами индексируешь более крупные. При поиске сначала ищешь мелкие, потом расширяешь контекст за счёт родительских чанков. Это даёт и точность, и полноту.
Embedding: модель важнее, чем кажется
Сначала я взял text-embedding-ada-002 от OpenAI и был доволен. Потом попробовал text-embedding-3-small — дешевле и почти не хуже. А потом узнал про Cohere и BGE от Baidu — и понял, что модель embedding сильно влияет на качество поиска.
Для русскоязычных документов я в итоге остановился на двух вариантах: либо мультиязычная модель вроде BGE-M3 от Baidu, либо E5 — обе хорошо понимают русский без дополнительных танцев. OpenAI-модели тоже неплохи, но английский у них приоритетнее, и на русском они иногда теряют нюансы.
Совет: не экономьте на embedding на этапе оценки. Попробуйте 2–3 модели, загрузите 50–100 вопросов, замерьте, насколько релевантные фрагменты возвращает каждая. Это один из самых высоких ROI экспериментов в RAG-системе.
Reranking: когда поиск недостаточно точный
Векторный поиск хорош, но он ищет по семантическому сходству, а не по релевантности запросу. Модель может найти фрагмент, где слова похожи, но по смыслу он не отвечает на вопрос.
Для этого есть reranking — двухэтапный поиск. Первый этап: быстрый векторный поиск возвращает топ-50 кандидатов. Второй этап: более тяжёлая модель вроде Cross-Encoder (это модель типа «запрос — документ», она оценивает пару целиком) заново ранжирует эти 50 документов по реальной релевантности вопросу.
Я добавил reranking в нашу систему и качество ответов выросло заметно. Особенно там, где вопрос содержит специфические термины из нашей предметной области. Библиотека sentence-transformers от HuggingFace покрывает базовые модели reranking из коробки.
Промпт: последняя миля
Даже идеальный поиск можно испортить промптом. Я несколько раз с этим сталкивался.
Базовый промпт для RAG выглядит примерно так: «На основе следующего контекста ответь на вопрос. Если информации в контексте недостаточно, так и скажи.» Вроде просто, но есть нюансы.
Во-первых, LLM может игнорировать контекст и отвечать из своей памяти. Решение — явная инструкция: «Отвечай ТОЛЬКО на основе предоставленного контекста». Иногда помогает добавить «Не придумывай информацию».
Во-вторых, контекст бывает шумным. Если поиск вернул 5 фрагментов, а релевантный только один — модель может запутаться. Здесь помогает threshold: отсекать фрагменты с низким скором релевантности, оставлять только самые качественные.
В-третьих, длинный контекст стоит денег и замедляет ответ. Я обычно ограничиваю контекст тремя-четырьмя фрагментами максимум и проверяю, что каждый из них реально полезен для ответа.
Что я понял за год возни с RAG
Главное: RAG — это не «взяли векторную базу и забыли». Это система, которая требует постоянной работы над качеством.
Я видел, как команды месяцами строят инфраструктуру, а потом удивляются, почему качество ответов так себе. А проблема была в том, что документы были плохо структурированы, чанки резались по непонятному принципу, а метрик качества не было вообще.
Поэтому пара советов, которые стоит усвоить до того, как начнёте.
Стройте метрики сразу. Измеряйте recall — нашёл ли поиск нужный фрагмент, precision — нашёл ли именно нужное, а не шум, и end-to-end quality — правильный ли ответ даёт LLM. Без метрик вы будете тыкать вслепую.
Держите документы в чистоте. RAG хорош ровно настолько, насколько хороши источники. Мусорные документы, неактуальные версии, дубли — всё это тянет качество вниз.
Обновляйте базу. Я видел системы, где последний документ в базе датирован прошлым годом. Пользователи спрашивают про новые процессы, а база молчит. Добавьте автоматизацию индексации — хотя бы раз в день.
Коротко
RAG — это не магия. Это конкретный пайплайн: документы → эмбеддинги → векторная база → поиск → контекст → LLM → ответ. Каждый этап влияет на результат.
Попробуйте начать с простого: FAISS + LlamaIndex + text-embedding-ada-002. Соберите 20–30 типичных вопросов, замерьте качество. Потом улучшайте чанки, embedding-модель, добавьте reranking. Не пытайтесь сразу построить идеальную систему — это нормально.
Главное — измеряйте. Без метрик вы не знаете, стало лучше или хуже.
