RAG по своим конспектам: локальный поиск, чанки и ответы с источниками

RAG по своим конспектам строится из пяти частей: очистка файлов, разбиение на смысловые чанки, embeddings, поиск похожих фрагментов и ответ модели только на найденном контексте. Для доверия сохраняйте имя файла и заголовок каждого чанка, а при недостатке данных просите модель честно отказать.

RAG не обучает модель заново и не гарантирует истину. Он подбирает фрагменты перед генерацией ответа. Если поиск вернул не тот конспект, сильная модель всё равно получит плохую основу. Поэтому сначала проверяют retrieval отдельно: для набора вопросов смотрят, попал ли правильный фрагмент в top-k. Только затем оценивают формулировку ответа и ссылки.

RAG по своим конспектам: начните с качественных чанков

Не режьте текст строго каждые 500 символов посреди предложения. Для заметок удобно сначала делить по заголовкам и абзацам, затем собирать блоки до лимита. Пример ниже использует только стандартный Python и сохраняет целые абзацы. В production дополнительно учитывают токены, таблицы, код и перекрытие там, где мысль продолжается между блоками.

def split_notes(text: str, max_chars: int = 700) -> list[str]:
    paragraphs = [part.strip() for part in text.split("\n\n") if part.strip()]
    chunks: list[str] = []
    current: list[str] = []

    for paragraph in paragraphs:
        candidate = "\n\n".join([*current, paragraph])
        if current and len(candidate) > max_chars:
            chunks.append("\n\n".join(current))
            current = [paragraph]
        else:
            current.append(paragraph)

    if current:
        chunks.append("\n\n".join(current))

    return chunks

После chunking передайте список текстов в embedding-модель. Ollama рекомендует embeddinggemma, qwen3-embedding и all-minilm. Векторы документа и вопроса должны создаваться одной моделью. Храните рядом source, heading, дату и порядковый номер. При смене embedding-модели переиндексируйте всю коллекцию, потому что пространства векторов несовместимы.

Что проверять в RAG отдельно

Большой top-k не всегда лучше. Лишние фрагменты размывают контекст и могут противоречить друг другу. Начните с 3-5 результатов и показывайте их пользователю. Если точный термин не находится семантически, добавьте гибридный поиск по ключевым словам. Для сложных вопросов полезен reranker, который повторно сортирует кандидатов.

Практика: RAG на десяти конспектах с проверкой попадания в top-3

Возьмите десять своих заметок и соберите на них минимальный поиск с ответом. Нужны три части: функция split_notes для чанков, embeddings одной моделью и выдача трёх фрагментов вместе с source и heading. Успехом считается такое: на контрольный вопрос нужный конспект попадает в top-3, а ответ модели ссылается именно на него.

Сломайте условие намеренно: посчитайте вектор вопроса другой embedding-моделью, оставив старые векторы документов. Код не упадёт, ответ будет звучать уверенно, но выдача станет случайной, потому что пространства векторов несовместимы. Отдельно задайте вопрос по теме, которой в ваших десяти заметках нет: модель должна честно отказать, а не сочинить абзац. Верните исходную модель и переиндексируйте коллекцию целиком.

Дальше добавьте гибридный поиск по ключевым словам: точные термины, номера и редкие названия семантика часто теряет. Потом попробуйте reranker, который пересортирует кандидатов перед отправкой в модель, и сравните долю попаданий до и после. Держите top-k в диапазоне 3-5: лишние фрагменты размывают контекст и начинают противоречить друг другу. Перекрытие между чанками включайте точечно, только там, где мысль переходит в следующий абзац.

Частые ошибки и почему они появляются

Частая ошибка состоит в оценке только красивого ответа. Модель может угадать из общих знаний, хотя ваш конспект не найден. Вторая ошибка: индексировать PDF без проверки извлечённого текста. Третья: менять embedding-модель и оставлять старые векторы. Такой индекс выглядит рабочим, но близость теряет смысл.

Самопроверка