RAG: как сделать AI-ассистента по своим документам

RAG (retrieval-augmented generation) — это способ научить AI-ассистента отвечать по вашим документам без дообучения модели: система находит в базе знаний фрагменты, относящиеся к вопросу, и передаёт их модели вместе с вопросом. Качество такого ассистента определяется не моделью, а тем, как документы нарезаны, проиндексированы и найдены.

Разберём, из чего состоит RAG-система, как её собрать и проверить, прежде чем показывать клиентам.

Как работает RAG?

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

Пошагово это выглядит так:

1. Подготовка: документы разбиваются на фрагменты, для каждого считается эмбеддинг — числовой вектор, описывающий смысл текста.
2. Индексация: фрагменты и векторы сохраняются в базу с поддержкой векторного поиска.
3. Поиск: вопрос пользователя тоже превращается в вектор, и база находит ближайшие по смыслу фрагменты.
4. Генерация: найденные фрагменты вместе с вопросом передаются модели с инструкцией отвечать только по ним.
5. Ответ: пользователь получает ответ со ссылками на документы-источники.

Главное преимущество перед дообучением — знания обновляются без переобучения модели: добавили документ, пересчитали его векторы, и ассистент уже знает новое.

Из каких компонентов состоит RAG-система?

RAG-система состоит из конвейера загрузки документов, модели эмбеддингов, векторного хранилища, поиска с переранжированием и слоя генерации с проверкой ответа. Каждый компонент можно заменить, не переписывая остальные.

Компонент	Что делает	Типичные варианты
Загрузка документов	Извлекает текст из PDF, страниц, баз знаний	Парсеры документов, выгрузки из CRM и вики
Нарезка на фрагменты	Делит текст на куски по смыслу	По заголовкам и абзацам, с перекрытием
Модель эмбеддингов	Превращает текст в векторы	Облачные API или открытые модели
Векторное хранилище	Хранит векторы и ищет ближайшие	pgvector в PostgreSQL, отдельные векторные базы
Переранжирование	Уточняет порядок найденных фрагментов	Модели-реранкеры, гибридный поиск
Генерация	Формирует ответ по найденным фрагментам	LLM через шлюз с лимитами

Если в проекте уже есть PostgreSQL, начинать удобно с расширения pgvector: не нужна новая инфраструктура, а векторы лежат рядом с остальными данными.

Фото: Unsplash

Как собрать простой RAG на Python?

Простейший рабочий RAG на Python занимает несколько десятков строк: таблица с фрагментами и векторами, функция поиска и вызов модели. Ниже — скелет поиска и генерации поверх PostgreSQL с pgvector; embed и llm — ваши обёртки над выбранными провайдерами.

import psycopg

SEARCH_SQL = """
    SELECT content, source_url
    FROM chunks
    ORDER BY embedding <=> %(query)s::vector
    LIMIT 5
"""

def answer(question: str, conn: psycopg.Connection) -> dict:
    query_vector = embed(question)
    rows = conn.execute(SEARCH_SQL, {"query": str(query_vector)}).fetchall()

    context = "\n\n".join(f"[{i + 1}] {content}" for i, (content, _) in enumerate(rows))
    prompt = (
        "Ответь на вопрос только по фрагментам ниже. "
        "Если ответа в них нет — так и скажи. Указывай номера фрагментов.\n\n"
        f"{context}\n\nВопрос: {question}"
    )
    return {"answer": llm(prompt), "sources": [url for _, url in rows]}

Оператор <=> в pgvector считает косинусное расстояние. Для больших объёмов к таблице добавляют индекс HNSW, чтобы поиск не перебирал все строки.

Как нарезать документы

От нарезки зависит больше, чем от выбора модели. Слишком крупные фрагменты размывают смысл, слишком мелкие теряют контекст. Хорошее начало — делить по заголовкам и абзацам, добавлять к каждому фрагменту заголовок раздела и название документа и делать небольшое перекрытие между соседними кусками.

Почему RAG отвечает неправильно?

RAG отвечает неправильно чаще всего потому, что поиск не нашёл нужный фрагмент, а не потому, что модель плохо сформулировала ответ. Поэтому качество начинают проверять с поиска.

Типичные причины ошибок:

• нужная информация есть в документах, но в виде таблицы или скана, из которого не извлёкся текст;
• фрагменты нарезаны так, что ответ разорван между двумя кусками;
• пользователь спрашивает другими словами, чем написано в документе, — помогает гибридный поиск: векторный плюс полнотекстовый;
• в базе лежат устаревшие версии документов, и они противоречат новым;
• модель не получила запрета отвечать «из головы», когда источников нет.

Чтобы измерять качество, соберите набор из 50–100 реальных вопросов с правильными ответами и источниками. Проверяйте на нём две вещи отдельно: нашёл ли поиск нужный фрагмент и правильно ли модель по нему ответила.

Что учесть перед запуском RAG для клиентов?

Перед запуском для клиентов нужно решить вопросы доступа к данным, стоимости и того, что ассистент делает, когда не знает ответа. Внутренний ассистент для сотрудников прощает больше, чем ассистент на сайте.

Чек-лист перед запуском:

1. Права доступа: пользователь не должен получать фрагменты документов, к которым у него нет доступа, — фильтр по правам делается на этапе поиска.
2. Источники в ответе: каждое утверждение можно проверить по ссылке.
3. Честный отказ: если в базе нет ответа, ассистент говорит об этом и предлагает связаться с человеком.
4. Обновление базы: изменённые документы переиндексируются автоматически.
5. Защита от prompt injection: текст документов не может менять инструкции модели.
6. Журнал и оценки пользователей — основа для улучшений.

Общую архитектуру AI-функций — шлюз, лимиты, валидацию — мы разбирали в статье как встроить LLM в продукт.

Коротко

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