Всем привет! 👋
Я практикующий юрист и сейчас пробую собрать 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