Всем привет! 👋
Я практикующий юрист и сейчас пробую собрать Telegram-бота, который помогает работать с судебной практикой без «галлюцинаций» нейросетей.
В работе часто возникает проблема: если задать нейросети вопрос, предполагающий ссылку на судебную практику, она с большой вероятностью придумает номер дела или источник. В итоге каждую такую ссылку приходится проверять вручную. Так и появилась идея сделать отдельного бота.
💡 Идея простая: бот отвечает на вопросы только на основе реальных судебных актов, которые заранее загружены в базу. Поскольку практики очень много, я сознательно сузил направление — споры по поставке и купле-продаже.
По сути, я хочу получить рабочий инструмент юриста: открыть в течение дня, задать вопрос и получить ответ по той судебной практике, которая есть в базе, а не по абстрактным примерам из интернета или вовсе выдуманным делам.
📉 Что есть на данный момент: бот уже запускается и работает — он «читает» файлы и отвечает на вопросы.
Но результат пока требует доработки. Иногда он не улавливает тонкие нюансы судебных актов или даёт слишком общие ответы.
🎯 Текущая цель — повысить точность и постепенно наполнять базу «знаковыми» решениями (пока их всего 7 — этого, конечно, мало).
В этом канале буду делиться процессом: что получается, что не работает, с какими проблемами сталкиваюсь и как всё это можно применять в реальной юридической работе.
Если вам тоже интересно разобраться, как AI может помогать юристу на практике, — добро пожаловать )
Я практикующий юрист и сейчас пробую собрать Telegram-бота, который помогает работать с судебной практикой без «галлюцинаций» нейросетей.
В работе часто возникает проблема: если задать нейросети вопрос, предполагающий ссылку на судебную практику, она с большой вероятностью придумает номер дела или источник. В итоге каждую такую ссылку приходится проверять вручную. Так и появилась идея сделать отдельного бота.
💡 Идея простая: бот отвечает на вопросы только на основе реальных судебных актов, которые заранее загружены в базу. Поскольку практики очень много, я сознательно сузил направление — споры по поставке и купле-продаже.
По сути, я хочу получить рабочий инструмент юриста: открыть в течение дня, задать вопрос и получить ответ по той судебной практике, которая есть в базе, а не по абстрактным примерам из интернета или вовсе выдуманным делам.
📉 Что есть на данный момент: бот уже запускается и работает — он «читает» файлы и отвечает на вопросы.
Но результат пока требует доработки. Иногда он не улавливает тонкие нюансы судебных актов или даёт слишком общие ответы.
🎯 Текущая цель — повысить точность и постепенно наполнять базу «знаковыми» решениями (пока их всего 7 — этого, конечно, мало).
В этом канале буду делиться процессом: что получается, что не работает, с какими проблемами сталкиваюсь и как всё это можно применять в реальной юридической работе.
Если вам тоже интересно разобраться, как AI может помогать юристу на практике, — добро пожаловать )
👍2❤1🔥1
Как это выглядит на практике:
1️⃣ Вопрос — обычная рабочая ситуация по договору (неустойка, приемка, долг).
2️⃣ Бот ищет ответ только в загруженной судебной практике, без фантазий и «примерных» ссылок.
3️⃣ На выходе — вердикт и разбор с указанием позиций судов и номеров дел.
Пока это прототип, ответы ещё не идеальны — но уже видно, в каком направлении всё движется.
1️⃣ Вопрос — обычная рабочая ситуация по договору (неустойка, приемка, долг).
2️⃣ Бот ищет ответ только в загруженной судебной практике, без фантазий и «примерных» ссылок.
3️⃣ На выходе — вердикт и разбор с указанием позиций судов и номеров дел.
Пока это прототип, ответы ещё не идеальны — но уже видно, в каком направлении всё движется.
🔥3👍1🤝1
Настраивая бота и пытаясь улучшить его ответы, я столкнулся с тем, что многие процессы и термины попросту не понимаю.
Поэтому решил изучить тему загрузки данных в систему RAG более детально и создать для себя «памятки», чтобы лучше запомнить\усвоить. Составил две схемы. Первая — «Полный цикл загрузки в RAG» (прикрепил), вторая — «Процесс поиска и генерации ответа» (выложу чуть позже).
К схемам сделал пояснения, так как некоторые блоки нужно раскрыть гораздо глубже, чем просто указано на схеме. Пояснения — ниже 👇
Поэтому решил изучить тему загрузки данных в систему RAG более детально и создать для себя «памятки», чтобы лучше запомнить\усвоить. Составил две схемы. Первая — «Полный цикл загрузки в RAG» (прикрепил), вторая — «Процесс поиска и генерации ответа» (выложу чуть позже).
К схемам сделал пояснения, так как некоторые блоки нужно раскрыть гораздо глубже, чем просто указано на схеме. Пояснения — ниже 👇
👍3🔥1
Пояснения к Схеме №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, а иногда строго разделяются. В прикрепленной схеме они разделены: ингестия — подготовка и очистка текстов, индексация — нарезка, метаданные и перевод текста в векторы.
Этап 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 готов к этапу поиска и генерации ответов.
👍3
Закончил вторую памятку на тему «какой путь проходит заданный вопрос в системе RAG?».
К тексту прилагаю схему, которая помогает визуализировать этот процесс. Тема достаточно объёмная, больше информации о каждом процессе/механизме — в прикреплённой памятке ниже.
Кратко про «путь» заданного вопроса:
🔹 Оптимизация запроса (необязательный этап). В «базовой комплектации» RAG этого блока нет — его нужно отдельно реализовывать через скрипт/код. Фактически это переформулировка запроса для более точного поиска.
🔹 Эмбеддинг запроса. Текст вопроса преобразуется в числовой вектор (эмбеддинг).
🔹 Ретривал (Retrieval) - процесс поиска. Ретривер (механизм поиска) получает вектор/набор чисел и обращается к векторной базе.
🔹 Переранжирование (необязательный этап). После первичного поиска можно добавить реранкера — отдельный механизм, который повторно оценивает найденные фрагменты уже на уровне текста и оставляет самые подходящие.
Сборка. Дальше система собирает финальный «пакет документов» для LLM.
🔹Генерация ответа. "Склеенный блок" вставляется в промпт, и LLM формирует ответ.
Что я для себя понял: «на деле» почти каждый этап (процесс/механизм) отображенный на схеме можно настраивать вручную через скрипты/код. Причём это касается не только промпта, но и того, как именно идёт поиск (логика, фильтры по метаданным), как отбираются фрагменты (реранкер) и как собирается контекст (обрезка/сжатие, порядок, источники). За счёт этого чат‑бот можно реально «дотачивать» под задачу юриста: чтобы он отвечал по конкретной базе судебных актов и был предсказуемее в ссылках и формулировках.
К тексту прилагаю схему, которая помогает визуализировать этот процесс. Тема достаточно объёмная, больше информации о каждом процессе/механизме — в прикреплённой памятке ниже.
Кратко про «путь» заданного вопроса:
🔹 Оптимизация запроса (необязательный этап). В «базовой комплектации» RAG этого блока нет — его нужно отдельно реализовывать через скрипт/код. Фактически это переформулировка запроса для более точного поиска.
🔹 Эмбеддинг запроса. Текст вопроса преобразуется в числовой вектор (эмбеддинг).
🔹 Ретривал (Retrieval) - процесс поиска. Ретривер (механизм поиска) получает вектор/набор чисел и обращается к векторной базе.
🔹 Переранжирование (необязательный этап). После первичного поиска можно добавить реранкера — отдельный механизм, который повторно оценивает найденные фрагменты уже на уровне текста и оставляет самые подходящие.
Сборка. Дальше система собирает финальный «пакет документов» для LLM.
🔹Генерация ответа. "Склеенный блок" вставляется в промпт, и LLM формирует ответ.
Что я для себя понял: «на деле» почти каждый этап (процесс/механизм) отображенный на схеме можно настраивать вручную через скрипты/код. Причём это касается не только промпта, но и того, как именно идёт поиск (логика, фильтры по метаданным), как отбираются фрагменты (реранкер) и как собирается контекст (обрезка/сжатие, порядок, источники). За счёт этого чат‑бот можно реально «дотачивать» под задачу юриста: чтобы он отвечал по конкретной базе судебных актов и был предсказуемее в ссылках и формулировках.
🔥5👍1
Продолжаем пилить чат-бота.
После того как я разобрался с теорией (схемы из прошлых постов), пришло время переходить к практике и нагружать бота объемом данных.
Небольшой апдейт: ранее я писал, что буду делать бота по поставке. Но для тестов архитектуры решил «переобуться» на сферу интеллектуальной собственности. Она показалась мне более показательной для проверки точности поиска.
На данный момент загрузил в RAG приличное количество судебной практики + 4 часть ГК РФ.
На скриншоте видно точное количество загруженных чанков и родительских элементов.
Решил не сваливать всё в одну кучу. Для более «правильной» архитектуры разнес данные по разным коллекциям (папкам) в векторном хранилище: судебная практика отдельно, нормы ГК РФ — отдельно. Это должно улучшить качество поиска.
Загрузка 858 судебных дел заняла у меня почти 3 часа. Почему так долго?
Тут сыграли роль три фактора:
➡️ Объем текста. 850+ решений — это уже не тестовая выборка.
➡️ Иерархический RAG. Я использую продвинутую нарезку (Parent Document Retriever). Системе нужно не просто порезать текст на мелкие кусочки, но и создать большие (родительские) блоки, связать их между собой метаданными и только потом сохранить. Это кратно сложнее обычной нарезки.
➡️ Железо. Делаю всё на ноутбуке с 8 Гб оперативной памяти. Памяти мало, поэтому пришлось написать скрипт для последовательной обработки: берется 1 файл -> режется -> присваиваются метаданные -> эмбеддинг -> сохранение в базу.
После этого файл принудительно выгружается из оперативки, и только затем берется следующий. И так 858 раз.
Для сравнения: 4-ю часть ГК РФ (она меньше по объему и структурированнее) я загрузил всего за 5–7 минут.
✅ Главный вывод этого этапа:
Проектируйте и тестируйте своего бота на малых объемах, прежде чем загружать в него «всё, что есть» !
Некоторые настройки (например, размер чанка или его перекрытие/overlap) нельзя поменять «на лету» в уже загруженной базе. Если вы загрузили 1000 дел, а потом поняли, что бот плохо ищет, потому что куски текста слишком маленькие — вам придется сносить базу и заливать всё заново. А это, как мы видим, часы времени.
После того как я разобрался с теорией (схемы из прошлых постов), пришло время переходить к практике и нагружать бота объемом данных.
На данный момент загрузил в RAG приличное количество судебной практики + 4 часть ГК РФ.
На скриншоте видно точное количество загруженных чанков и родительских элементов.
Решил не сваливать всё в одну кучу. Для более «правильной» архитектуры разнес данные по разным коллекциям (папкам) в векторном хранилище: судебная практика отдельно, нормы ГК РФ — отдельно. Это должно улучшить качество поиска.
Загрузка 858 судебных дел заняла у меня почти 3 часа. Почему так долго?
Тут сыграли роль три фактора:
➡️ Объем текста. 850+ решений — это уже не тестовая выборка.
➡️ Иерархический RAG. Я использую продвинутую нарезку (Parent Document Retriever). Системе нужно не просто порезать текст на мелкие кусочки, но и создать большие (родительские) блоки, связать их между собой метаданными и только потом сохранить. Это кратно сложнее обычной нарезки.
➡️ Железо. Делаю всё на ноутбуке с 8 Гб оперативной памяти. Памяти мало, поэтому пришлось написать скрипт для последовательной обработки: берется 1 файл -> режется -> присваиваются метаданные -> эмбеддинг -> сохранение в базу.
После этого файл принудительно выгружается из оперативки, и только затем берется следующий. И так 858 раз.
Для сравнения: 4-ю часть ГК РФ (она меньше по объему и структурированнее) я загрузил всего за 5–7 минут.
✅ Главный вывод этого этапа:
Проектируйте и тестируйте своего бота на малых объемах, прежде чем загружать в него «всё, что есть» !
Некоторые настройки (например, размер чанка или его перекрытие/overlap) нельзя поменять «на лету» в уже загруженной базе. Если вы загрузили 1000 дел, а потом поняли, что бот плохо ищет, потому что куски текста слишком маленькие — вам придется сносить базу и заливать всё заново. А это, как мы видим, часы времени.
🔥3👍2