RAG для корпоративной базы знаний

Раньше поиск по корпоративной вики работал так: набираешь название объекта → одна опечатка → ничего не найдено → идёшь спрашивать коллег. Сейчас можно задать вопрос обычным языком и получить ответ с нужными ссылками. Технология называется RAG — Retrieval-Augmented Generation.

Проблема корпоративных баз знаний

Типовая ситуация в компании с 10+ годами истории. Накопленная документация:

• 40 000+ страниц в Wiki;
• Разные команды создавали по своим стандартам;
• Технические описания процессов и архитектур;
• HR-документы, регламенты, инструкции;
• Описания внутренних метрик и терминов.

Проблема штатного поиска:

• Требуется точное совпадение названия;
• Не работает семантический поиск;
• Не учитывает синонимы;
• Не понимает контекст вопроса.

Результат: сотрудники тратят время на поиск информации вместо работы.

Что такое RAG

RAG (Retrieval-Augmented Generation) — архитектура, где языковая модель отвечает на вопросы, используя найденную в базе знаний информацию.

Принцип работы RAG:

Вопрос пользователя
        ↓
Преобразование в эмбеддинг (вектор)
        ↓
Поиск похожих фрагментов в базе знаний
        ↓
Найденные фрагменты + вопрос → языковая модель
        ↓
Ответ на основе контекста

Ключевое отличие от обычного чат-бота: модель отвечает на основе ваших данных, а не только знаний из обучения.

Главная ошибка внедрения RAG

Типичный сценарий: «Возьмём открытую модель, дообучим на наших данных — и готово». Проблема: fine-tuning требует ресурсов и не решает задачу.

Почему fine-tuning не подходит

Fine-tuning изменяет веса модели — это сложно и дорого. RAG подаёт данные в контекст — это быстро и гибко. Для корпоративной базы знаний RAG — оптимальный выбор: данные обновляются постоянно, не нужна инфраструктура для обучения, запуск за недели.

Архитектура RAG-системы

Компоненты типового решения.

Основные компоненты

Процесс обработки запроса:

Пользователь: "Как оформить больничный?" ↓ Эмбеддинг запроса (вектор 768 чисел) ↓ Поиск 3-5 ближайших фрагментов в векторной БД ↓ Формирование промпта: "Контекст: [найденные фрагменты] Вопрос: Как оформить больничный? Ответь на основе контекста." ↓ Языковая модель генерирует ответ ↓ Ответ + ссылки на документы. Вся цепочка занимает 2-3 секунды.

Подготовка данных

Критичный этап — от качества данных зависит качество ответов.

Очистка документов из Wiki

Проблемы HTML-документов: служебная разметка (меню, ссылки), заголовки без контекста, таблицы с визуальной логикой, схемы в виде изображений.

Процесс очистки:

Исходная HTML-страница ↓ Парсинг текста ↓ Удаление служебной разметки ↓ Проверка осмысленности фрагментов ↓ Разбиение на чанки (chunks). Важно: автоматическая очистка не идеальна — нужны правила для авторов документов.

Разбиение на чанки (chunks)

Chunk — фрагмент текста для хранения в векторной БД.

Оптимум: 800-1200 символов с перекрытием 15-20%.

Эмбеддинги — основа поиска

Эмбеддинг — векторное представление текста в многомерном пространстве.

Как работают эмбеддинги:

• "Как оформить отпуск?" → [0.23, -0.15, 0.87, ..., 0.42] (768 чисел)
• "Оформление отпуска" → [0.21, -0.14, 0.89, ..., 0.40] (близкий вектор)
• "Цена сервера" → [-0.45, 0.72, -0.33, ..., 0.11] (далёкий вектор)

Близость векторов = семантическая похожесть.

Модели эмбеддингов

Векторный поиск

Поиск по близости векторов быстрее и точнее полнотекстового.

Методы векторного поиска

• Cosine similarity: косинусное расстояние (базовый поиск);
• MMR (Maximum Marginal Relevance): баланс релевантности и разнообразия, избегает дублей;
• Hybrid search: векторный + текстовый для максимальной точности.

MMR решает проблему повторяющихся результатов: первый результат — самый релевантный, второй — релевантный и непохожий на первый, и т.д.

Промптирование

Формирование правильного запроса к языковой модели критично для качества ответов.

Элементы промпта

Пример промпта:
Ты — помощник по внутренней документации компании.

Контекст:
[Фрагмент 1: процедура оформления больничного...]
[Фрагмент 2: сроки подачи документов...]

Инструкция: Отвечай только на основе предоставленного контекста. Если информации нет — скажи "Не нашёл информации по этому вопросу".

Вопрос: Как оформить больничный?

Ограничение галлюцинаций

Проблема: модель может "придумать" ответ, даже если информации нет в контексте. Решение: явная инструкция "не отвечай, если не уверен". Лучше отказать, чем дать неверный ответ.

Классификация запросов по доменам

Когда база знаний охватывает разные темы, поиск по всем документам неэффективен.

Схема с классификацией:

Вопрос → Классификатор определяет тему (HR/IT/Продукт) → Поиск в нужном разделе → Ответ. Преимущества: выше точность, быстрее поиск, релевантнее результаты.

Когда RAG оправдан

Практические результаты

Метрики реального внедрения RAG

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

Обязательные компоненты: Векторная БД (OpenSearch, Elasticsearch, Weaviate), модель эмбеддингов, языковая модель с API, система промптирования. Правильный подход: начать с одного раздела документации (HR, IT), отладить процесс, масштабировать на другие разделы.

Частые вопросы

В чём отличие RAG от обычного чат-бота на языковой модели?

Обычный чат-бот отвечает только на основе знаний из обучения. RAG ищет информацию в вашей базе знаний и подаёт её в контекст модели. Это позволяет отвечать на вопросы по внутренним документам компании, которых модель не знает.

Почему RAG лучше fine-tuning для корпоративной базы знаний?

Fine-tuning изменяет веса модели — это требует GPU-кластера и недель работы. RAG подаёт данные в контекст при каждом запросе — это быстро и гибко. Плюс RAG автоматически работает с обновлёнными данными, а fine-tuning нужно повторять при каждом изменении базы знаний.