Настраивая бота и пытаясь улучшить его ответы, я столкнулся с тем, что многие процессы и термины попросту не понимаю.

Поэтому решил изучить тему загрузки данных в систему RAG более детально и создать для себя «памятки», чтобы лучше запомнить\усвоить. Составил две схемы. Первая — «Полный цикл загрузки в RAG» (прикрепил), вторая — «Процесс поиска и генерации ответа» (выложу чуть позже).

К схемам сделал пояснения, так как некоторые блоки нужно раскрыть гораздо глубже, чем просто указано на схеме. Пояснения — ниже 👇

Пояснения к Схеме №1 «Полный цикл загрузки в RAG»

В разных источниках «ингестия» и «индексация» могут означать весь процесс загрузки данных в RAG, а иногда строго разделяются. В прикрепленной схеме они разделены: ингестия — подготовка и очистка текстов, индексация — нарезка, метаданные и перевод текста в векторы.

Этап 1. Ингестия
Начиная с блока 1.3 (Парсинг), всё происходит автоматически и, по сути, «невидно для глаза». Используются библиотеки, которые извлекают текст из файлов (PDF, Word и т.п.): pdfplumber, PyMuPDF, python-docx и др.
На шаге 1.4 текст автоматически (с помощью скриптов и библиотек) очищается от мусора: лишние переносы, колонтитулы, повторяющиеся заголовки, странные символы.

В прикреплённом ниже файле — более подробные пояснения ко всем этапам, если хочется разобраться глубже.

Этап 2. Индексация
2.1 Чанкинг. Текст режется на куски (чанки). Размер задаётся в скрипте и может измеряться в символах, токенах, словах, предложениях, абзацах, разделах или страницах. Дополнительно задаётся перекрытие (overlap) — «нахлёст» между чанками, чтобы не терялся контекст. Чанкинг делает скрипт, но конкретная стратегия зависит от уровня RAG (про уровни RAG можно найти в прикреплённом файле).

2.2 Метаданные. После нарезки каждому чанку присваиваются метаданные. Даже в простом RAG это хотя бы имя файла/документа. Простые метаданные (имя файла, страница) добавляет скрипт, более сложные (summary, ключевые слова) может генерировать LLM. Процессы здесь связаны и часто плавно перетекают один в другой.

2.3 Эмбеддинг. Каждый чанк преобразуется в набор чисел — вектор. Для этого используются специальные эмбеддинговые модели (энкодеры): all-MiniLM, bge, E5 и др.

2.4 Запись. Вектор, текст чанка и его метаданные сохраняются в векторной базе. Запись обычно идёт пакетами (батчами) — можно настроить, сколько чанков отправляется в хранилище за один раз.

Итог.
Данные подготовлены, нарезаны, превращены в векторы и сохранены в хранилище. Дальше RAG готов к этапу поиска и генерации ответов.

Более подробные пояснения к схеме.

Закончил вторую памятку на тему «какой путь проходит заданный вопрос в системе RAG?».
К тексту прилагаю схему, которая помогает визуализировать этот процесс. Тема достаточно объёмная, больше информации о каждом процессе/механизме — в прикреплённой памятке ниже.

Кратко про «путь» заданного вопроса:

🔹 Оптимизация запроса (необязательный этап). В «базовой комплектации» RAG этого блока нет — его нужно отдельно реализовывать через скрипт/код. Фактически это переформулировка запроса для более точного поиска.
​
🔹 Эмбеддинг запроса. Текст вопроса преобразуется в числовой вектор (эмбеддинг).
​
🔹 Ретривал (Retrieval) - процесс поиска. Ретривер (механизм поиска) получает вектор/набор чисел и обращается к векторной базе.

🔹 Переранжирование (необязательный этап). После первичного поиска можно добавить реранкера — отдельный механизм, который повторно оценивает найденные фрагменты уже на уровне текста и оставляет самые подходящие.
Сборка. Дальше система собирает финальный «пакет документов» для LLM.

🔹Генерация ответа. "Склеенный блок" вставляется в промпт, и LLM формирует ответ.

Что я для себя понял: «на деле» почти каждый этап (процесс/механизм) отображенный на схеме можно настраивать вручную через скрипты/код. Причём это касается не только промпта, но и того, как именно идёт поиск (логика, фильтры по метаданным), как отбираются фрагменты (реранкер) и как собирается контекст (обрезка/сжатие, порядок, источники). За счёт этого чат‑бот можно реально «дотачивать» под задачу юриста: чтобы он отвечал по конкретной базе судебных актов и был предсказуемее в ссылках и формулировках.

Продолжаем пилить чат-бота.

После того как я разобрался с теорией (схемы из прошлых постов), пришло время переходить к практике и нагружать бота объемом данных.

Небольшой апдейт: ранее я писал, что буду делать бота по поставке. Но для тестов архитектуры решил «переобуться» на сферу интеллектуальной собственности. Она показалась мне более показательной для проверки точности поиска.

На данный момент загрузил в RAG приличное количество судебной практики + 4 часть ГК РФ.
На скриншоте видно точное количество загруженных чанков и родительских элементов.

Решил не сваливать всё в одну кучу. Для более «правильной» архитектуры разнес данные по разным коллекциям (папкам) в векторном хранилище: судебная практика отдельно, нормы ГК РФ — отдельно. Это должно улучшить качество поиска.

Загрузка 858 судебных дел заняла у меня почти 3 часа. Почему так долго?
Тут сыграли роль три фактора:
➡️ Объем текста. 850+ решений — это уже не тестовая выборка.
➡️ Иерархический RAG. Я использую продвинутую нарезку (Parent Document Retriever). Системе нужно не просто порезать текст на мелкие кусочки, но и создать большие (родительские) блоки, связать их между собой метаданными и только потом сохранить. Это кратно сложнее обычной нарезки.
➡️ Железо. Делаю всё на ноутбуке с 8 Гб оперативной памяти. Памяти мало, поэтому пришлось написать скрипт для последовательной обработки: берется 1 файл -> режется -> присваиваются метаданные -> эмбеддинг -> сохранение в базу.
После этого файл принудительно выгружается из оперативки, и только затем берется следующий. И так 858 раз.

Для сравнения: 4-ю часть ГК РФ (она меньше по объему и структурированнее) я загрузил всего за 5–7 минут.

✅ Главный вывод этого этапа:
Проектируйте и тестируйте своего бота на малых объемах, прежде чем загружать в него «всё, что есть» !

Некоторые настройки (например, размер чанка или его перекрытие/overlap) нельзя поменять «на лету» в уже загруженной базе. Если вы загрузили 1000 дел, а потом поняли, что бот плохо ищет, потому что куски текста слишком маленькие — вам придется сносить базу и заливать всё заново. А это, как мы видим, часы времени.

Коллеги, собрал RAG-бота в сфере IP и авторского права.

Нужен ваш "краш-тест" и фидбек.

Что он делает:
Считает "вилку" компенсации за нарушение прав на РИД и подсказывает методику расчета.

На чем работает:
В базе сейчас 850+ актов СИП (свежая практика 2024–2026 гг.) + актуальная 4 часть ГК РФ.

Зачем это нужно:
Чтобы быстро оценить перспективу: стоит ли идти в суд, какую сумму реально взыскать и на какую практику ссылаться. Если вы со стороны ответчика — помогает понять, адекватны ли требования истца или их можно снизить.

Буду благодарен, если погоняете его по своим кейсам. Это пока бета-версия, так что конструктивная критика приветствуется!

🤖 Потестировать бота: @GetINNinfo_bot