Почему 90% RAG-систем выдают бред?
Потому что база знаний - помойка. Серьёзно. Вы наверняка видели демки: чат-бот с документацией компании, который уверенно цитирует несуществующие страницы. Или помощник HR, рекомендующий сотрудникам устаревшие регламенты 2018 года. Виновата не модель - виноваты данные, которые вы в неё скормили.
RAG (Retrieval-Augmented Generation) работает ровно настолько, насколько хорош ваш retrieval. А retrieval - это про качество, структуру и свежесть базы знаний. Скормите LLM гору неструктурированных PDF с водяными знаками и сканами - получите галлюцинации. Это аксиома.
💡 Ключевая мысль: База знаний - это не просто набор файлов. Это инженерная конструкция. Каждый документ должен быть преобразован в вектор, снабжён метаданными и разбит на осмысленные фрагменты. Иначе модель будет искать иголку в стогу сена.
6 шагов, которые превратят вашу базу знаний в золото
Ниже - пошаговый план, который я проверял на десятке enterprise-проектов от банков до логистических гигантов. Не все шаги обязательны, но без них ваша RAG-система рискует стать дорогой игрушкой, а не рабочим инструментом.
1 Определите границы: что точно должно быть в базе?
Первое, что делают новички - сгребают все корпоративные документы в одну кучу: Confluence, Jira, Slack, внутренние wiki, PDF-отчёты, email-рассылки. И получают шум. Вам нужно чётко ответить на вопрос: какие вопросы будет задавать пользователь?
Сделайте карту вопросов (question taxonomy). Например, для поддержки продукта это будут: установка, ошибки, настройки, интеграции. Не включайте в базу маркетинговые брошюры и презентации - они только запутают модель. Помните принцип: лучше меньше, но качественнее.
Кстати, если ваш проект на Java/Kotlin, архитектуру интеграции AI мы уже разбирали в статье Интеграция AI в Java/Kotlin проекты - та же логика применима и к базе знаний.
2 Извлечение и очистка: мусор на входе - мусор на выходе
Вы не поверите, сколько компаний кормят RAG необработанными PDF с колонтитулами, номерами страниц и водяными знаками. Результат: модель цитирует "Стр. 14, Конфиденциально" вместо сути.
Вот минимальный пайплайн очистки:
- Извлечение текста - используйте PyMuPDF (fitz) или Unstructured.io. Избегайте OCR там, где есть текстовый слой.
- Удаление шума - стоп-слова, номера страниц, нижние колонтитулы, повторяющиеся заголовки.
- Нормализация - пробелы, Unicode, приведение к единой кодировке (UTF-8).
- Дедупликация - одинаковые документы в разных версиях (это частая проблема в Confluence).
⚠️ Типичная ошибка: оставлять в тексте таблицы и списки как есть. LLM не понимает сложные таблицы без контекста. Преобразуйте их в Markdown или описательный текст.
Пример кода для очистки PDF на Python (последняя версия PyMuPDF на май 2026):
import fitz # PyMuPDF
def clean_pdf_text(filepath):
doc = fitz.open(filepath)
text = ""
for page in doc:
blocks = page.get_text("blocks")
for block in blocks:
# пропускаем колонтитулы и номера страниц (пример эвристики)
if block[1] < 50 or block[3] > 720:
continue
text += block[4] + "\n"
doc.close()
# нормализация пробелов
import re
text = re.sub(r'\s+', ' ', text)
return text.strip()3 Чанкинг: режем, но со смыслом
Золотое правило: размер чанка зависит от задачи. Для вопросов по конкретным процедурам - 200-300 токенов. Для общих концепций - 500-1000. Главное - не резать посередине предложения.
Лучшие стратегии на 2026 год:
- RecursiveCharacterTextSplitter (LangChain) - разбивает по разделителям (абзацы, предложения).
- Semantic chunking - использует эмбеддинги для определения границ темы (библиотека
semantic-text-splitter). - Agentic chunking - модель сама определяет, где логично завершить фрагмент (экспериментально, но даёт лучший retrieval).
4 Эмбеддинги и индексация: выбираем модель под данные
Эмбеддинг-модель превращает текст в вектор. Не все модели одинаково хороши для вашего домена. Например, text-embedding-3-large от OpenAI отлично работает на английском, но для русскоязычной документации лучше взять intfloat/multilingual-e5-large или BAAI/bge-m3.
Индекс: ваша цель - быстрый поиск по сотням тысяч векторов. Стандарт индустрии - FAISS (Facebook AI Similarity Search) или Qdrant (если нужен managed сервис). Для особо упёртых - pgvector на PostgreSQL.
⚠️ Ошибка: использовать один эмбеддинг для всех типов данных. Код и естественный язык - разные пространства. Подумайте о мультимодальной базе или отдельных индексах.
from langchain_huggingface import HuggingFaceEmbeddings
from langchain_community.vectorstores import FAISS
embeddings = HuggingFaceEmbeddings(model_name="intfloat/multilingual-e5-large")
docs = [...] # список документов-чанков
db = FAISS.from_documents(docs, embeddings)
db.save_local("knowledge_base_index")5 Поиск: одного векторного недостаточно
Чистый семантический поиск может пропустить точное совпадение (например, номер договора). Решение - hybrid search: комбинация векторного и keyword (BM25) поиска.
Ещё круче - re-ranking. После того как получили топ-20 чанков, прогоните их через re-ranker (например, Cohere rerank или BAAI/bge-reranker-v2). Он переупорядочивает результаты, и верхние 3-5 чанков попадают в контекст LLM. Это повышает точность ответа на 10-20%.
Пример с Qdrant (latest API 2026):
from qdrant_client import QdrantClient
from qdrant_client.http.models import Filter, FieldCondition, MatchValue
client = QdrantClient(url="http://localhost:6333")
# гибридный поиск через Qdrant с fusion
results = client.search(
collection_name="docs",
query_vector=vector,
query_filter=Filter(
must=[FieldCondition(key="department", match=MatchValue(value="IT"))]
),
with_payload=True,
limit=20,
)6 Мониторинг и обновление: база не терпит статики
Самая недооценённая часть. База знаний на дату релиза хороша, но через месяц документы устаревают, появляются новые версии. Нужен пайплайн инкрементального обновления.
- CI/CD для данных - при мерже в репозиторий документации запускайте переиндексацию изменённых файлов.
- Feedback loop - пользователь ставит дизлайк ответу? Логируйте запрос и чанки, которые были в контексте. Это даёт сигнал, что база не находит нужное.
- Versioning - храните старые версии векторов? Не всегда, но если данные критичны (юридические документы) - да, через векторные снимки.
Ошибки, которые я видел в каждом втором проекте
1. Забывают про permission. База знаний содержит конфиденциальные данные, а RAG отдаёт их всем подряд. Решение - фильтрация на уровне метаданных (роли пользователей).
2. Слишком большой контекст. LLM имеет лимит токенов. Вы не можете скормить ей 50 чанков. Настройте re-ranking так, чтобы в контекст попадало не более 3-5 штук.
3. Игнорирование мультиязычности. Если документация на русском, а вопросы задают на английском - эмбеддинги должны быть мультиязычными. Иначе - ноль.
4. Отсутствие тестового полигона. Вы не знаете, насколько точна ваша RAG, пока не создадите золотой датасет пар "вопрос-правильный ответ". Используйте синтетические данные для LLM, чтобы сгенерировать такие пары - мы писали об этом в статье Синтетические данные для LLM: как не сжечь модель.
Что дальше? Постройте свою первую RAG сегодня
Начните с малого: возьмите 10 документов, пройдите все 6 шагов. Измерьте accuracy на тестовых вопросах. Удивитесь, насколько улучшится качество после re-ranking и семантического чанкинга. Не пытайтесь объять необъятное - лучше постепенно наращивайте базу, чем сразу свалить всё в кучу.
Если хотите освоить создание контента с помощью нейросетей, обратите внимание на курс AI-креатор: создаём контент с помощью нейросетей от Skillbox. Там есть модуль про RAG и базы знаний для AI-ассистентов - практически пригодится.
И помните: лучшая база знаний - та, которую вы поддерживаете. Без регулярного обновления даже самый крутой RAG превращается в генератор убедительной лжи.
