Всем привет! 👋
Я практикующий юрист и сейчас пробую собрать 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
Коллеги, собрал RAG-бота в сфере IP и авторского права.
Нужен ваш "краш-тест" и фидбек.
Что он делает:
Считает "вилку" компенсации за нарушение прав на РИД и подсказывает методику расчета.
На чем работает:
В базе сейчас 850+ актов СИП (свежая практика 2024–2026 гг.) + актуальная 4 часть ГК РФ.
Зачем это нужно:
Чтобы быстро оценить перспективу: стоит ли идти в суд, какую сумму реально взыскать и на какую практику ссылаться. Если вы со стороны ответчика — помогает понять, адекватны ли требования истца или их можно снизить.
Буду благодарен, если погоняете его по своим кейсам. Это пока бета-версия, так что конструктивная критика приветствуется!
🤖 Потестировать бота: @GetINNinfo_bot
Нужен ваш "краш-тест" и фидбек.
Что он делает:
Считает "вилку" компенсации за нарушение прав на РИД и подсказывает методику расчета.
На чем работает:
В базе сейчас 850+ актов СИП (свежая практика 2024–2026 гг.) + актуальная 4 часть ГК РФ.
Зачем это нужно:
Чтобы быстро оценить перспективу: стоит ли идти в суд, какую сумму реально взыскать и на какую практику ссылаться. Если вы со стороны ответчика — помогает понять, адекватны ли требования истца или их можно снизить.
Буду благодарен, если погоняете его по своим кейсам. Это пока бета-версия, так что конструктивная критика приветствуется!
🤖 Потестировать бота: @GetINNinfo_bot
🔥7👍4🤝1
Борщ, пентест и план апгрейда: итоги первых тестов чат-бота, который может за минуту оценить компенсацию за нарушение интеллектуальных прав
Спасибо всем, кто принял участие в краш-тесте бота по интеллектуальной собственности.
Отдельная благодарность Павлу Мищенко за его репост — это дало хороший приток пользователей и помогло выявить больше скрытых багов.
Из забавного: в процессе пентестов одному из пользователей удалось обойти системный промпт и заставить бота выдать пошаговый рецепт борща. Посмеялись, баг отметил.
Но главное — есть крутые результаты на реальной практике. Один из пользователей загрузил тексты трех прошедших судебных споров и бот выдал ровно ту вилку компенсации, которую им в итоге взыскал суд. Ради подобных кейсов бот и разрабатывался.
Что планирую исправить и добавить по итогам тестов:
Впечатление от всего этого: поймал себя на мысли, что сам процесс разработки затягивает. А когда получаешь живой фидбек и видишь, как твой инструмент способен решать (не без багов) реальные задачи — это максимальный кайф. Осторожно, вайбкодинг вызывает зависимость!😄
Ссылка на бота: https://t.me/GetINNinfo_bot
Спасибо всем, кто принял участие в краш-тесте бота по интеллектуальной собственности.
Отдельная благодарность Павлу Мищенко за его репост — это дало хороший приток пользователей и помогло выявить больше скрытых багов.
Из забавного: в процессе пентестов одному из пользователей удалось обойти системный промпт и заставить бота выдать пошаговый рецепт борща. Посмеялись, баг отметил.
Но главное — есть крутые результаты на реальной практике. Один из пользователей загрузил тексты трех прошедших судебных споров и бот выдал ровно ту вилку компенсации, которую им в итоге взыскал суд. Ради подобных кейсов бот и разрабатывался.
Что планирую исправить и добавить по итогам тестов:
➡️ Защита от промпт-инъекций. Частично уже прикрыл лазейки от любителей кулинарии и других нестандартных запросов.➡️ Ориентация во времени. Добавлю передачу текущей даты, чтобы бот корректно работал со сроками.➡️ Чистка базы и настройка чанков. Уберу лишний информационный «шум» из документов, на которых работает модель, а также изменю размеры чанков и их перекрытие. Это касается только ГК РФ: с поиском судебной практики проблем не возникало, так как для нее применялся другой скрипт обработки.➡️ Понимание контекста. Настрою память на продолжение диалога. Чтобы сбросить контекст и задать новый вопрос, нужно будет нажать кнопку «Завершить» или просто исчерпать лимит в 3 уточняющих сообщения.➡️ Для 4 части ГК РФ "установить" гибридную логику поиска (будет искать как по смыслу, так и по совпадению слов). Это необходимо для исключения семантической путаницы между похожими нормами ГК РФ и предотвращения галлюцинаций на несуществующих статьях.➡️ Ограничение запросов. Временно устанавливаю лимит в 10 обращений в сутки от пользователя. Лимиты нужны исключительно для контроля нагрузки. По мере тестов и анализа его работы буду их увеличивать или оставлю такими же.➡️ Перенос на сервер. В «мыслях» разместить бота на сервере, чтобы он работал стабильно и был доступен 24/7.
Впечатление от всего этого: поймал себя на мысли, что сам процесс разработки затягивает. А когда получаешь живой фидбек и видишь, как твой инструмент способен решать (не без багов) реальные задачи — это максимальный кайф. Осторожно, вайбкодинг вызывает зависимость!😄
Ссылка на бота: https://t.me/GetINNinfo_bot
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥4
Недавно наткнулся на карту российских LegalTech-проектов. Это ресурс, где собирают отечественные решения — позволяет мониторить, что вообще сейчас есть на рынке.
Решил подать заявку со своим ботом (AI-ассистент для оценки компенсации за использование РИД). Заполнил небольшую форму, прошел модерацию, и теперь проект официально появился на карте.
За поддержку и развитие этого ресурса отдельное спасибо Holger Zscheyge.
Перенес его на удаленный сервер. Тестировать архитектуру на домашнем ноутбуке было круто, но держать его постоянно включенным 24/7 — та еще боль. Теперь бот работает автономно.
В ближайшем посте расскажу про этот опыт: как выбирал сервер для проекта, на какие параметры смотрел в первую очередь и сколько времени занял переезд.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤2👍2
Как я оставил бота без «мозгов» и эпично стер базу
В предыдущем посте я писал, что перенёс бота на удалённый сервер. Звучало гладко. На деле всё оказалось не совсем так.
Что произошло
Код нормально подгрузился с GitHub, бот запустился и начал отвечать пользователям. Проблема была в одном - я забыл загрузить векторную базу.
Бот работал «по старой памяти» (точнее, уверенно галлюцинировал), не имея доступа ни к одному из 858 загруженных судебных дел. При этом ответы выглядели крайне правдоподобно😄
Поняв это, я начал искать способ закинуть базу на сервер. Посоветовался с Trae AI. Он уверенно выдал план: делаем репозиторий приватным и льем всё через Git LFS (для больших файлов).
Итог: GitHub выдал ошибку — лимит по размеру на бесплатном тарифе превышен, база не влезла. Каково же было мое разочарование, когда я заглянул в локальную папку с базой и обнаружил, что Git подменил реальные файлы на короткие текстовые пустышки (LFS-указатели).
Как я разбирался
Подключил Claude Code. Он помог восстановить цепочку событий, но итог был один: файлы восстановлению не подлежат.
Так как пришлось заново индексировать 858 дел и ГК РФ, я решил перепроверить архитектуру поиска. Тут клод выдал второе разочарование дня: родительские чанки в моей системе не работали вовсе. Код был написан, файлы лежали в папке, но в пайплайне они не использовались. Иерархической системой, о которой я писал ранее, там и не пахло.
Что в итоге переделал
➡️ Подключил разбиение на родительские и дочерние чанки. Теперь поиск идет по коротким фрагментам, а модель получает полный контекст дела с логикой суда.
➡️ Добавил reranker (кросс-энкодер) — модель-судью, которая переоценивает релевантность после первичного поиска.
➡️ Увеличил перекрытие между чанками, чтобы смысл не терялся на стыках.
➡️ Заменил запись логов в json-файл на SQLite для сбора статистики.
➡️ Настроил rsync для синхронизации тяжелых данных между ноутом и сервером.
➡️ Доработал промпт под новую редакцию ГК РФ (ФЗ-214 от 04.01.2026).
Уроки, которые стоили мне половины дня:
➡️ GitHub — не файлообменник. Векторная база, ключи, веса моделей и бэкапы должны быть в gitignore. Для переноса данных есть rsync, FileZilla или scp.
➡️ Git LFS на бесплатном тарифе — мина замедленного действия. Обрыв загрузки может превратить ваши файлы в тыкву.
➡️ Не доверяй каждому совету ИИ (даже если очень хочется быстро решить проблему).
➡️ Возможно, стоило использовать API-эмбеддинги вместо локальной модели — с ними индексация проходит куда быстрее. Но мы не ищем легких путей.
🤖 Бот снова в строю. Протестировать тут: @GetINNinfo_bot
В предыдущем посте я писал, что перенёс бота на удалённый сервер. Звучало гладко. На деле всё оказалось не совсем так.
Что произошло
Код нормально подгрузился с GitHub, бот запустился и начал отвечать пользователям. Проблема была в одном - я забыл загрузить векторную базу.
Бот работал «по старой памяти» (точнее, уверенно галлюцинировал), не имея доступа ни к одному из 858 загруженных судебных дел. При этом ответы выглядели крайне правдоподобно😄
Поняв это, я начал искать способ закинуть базу на сервер. Посоветовался с Trae AI. Он уверенно выдал план: делаем репозиторий приватным и льем всё через Git LFS (для больших файлов).
Итог: GitHub выдал ошибку — лимит по размеру на бесплатном тарифе превышен, база не влезла. Каково же было мое разочарование, когда я заглянул в локальную папку с базой и обнаружил, что Git подменил реальные файлы на короткие текстовые пустышки (LFS-указатели).
Как я разбирался
Подключил Claude Code. Он помог восстановить цепочку событий, но итог был один: файлы восстановлению не подлежат.
Так как пришлось заново индексировать 858 дел и ГК РФ, я решил перепроверить архитектуру поиска. Тут клод выдал второе разочарование дня: родительские чанки в моей системе не работали вовсе. Код был написан, файлы лежали в папке, но в пайплайне они не использовались. Иерархической системой, о которой я писал ранее, там и не пахло.
Что в итоге переделал
Уроки, которые стоили мне половины дня:
🤖 Бот снова в строю. Протестировать тут: @GetINNinfo_bot
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👍2👏1😱1
Какая LLM лучше для юридического RAG-бота?
Провёл серию тестов — прогнал 10 разных моделей через бот с RAG-системой на одних и тех же вопросах.
Когда запускал бота, я не особо думал о выборе модели — просто взял Gemini 3.0 Flash Preview по советам из чата. Модель быстрая, дешёвая, меня в целом устраивает. Но со временем возник вопрос — а так ли она хороша конкретно в моём проекте? И насколько велика разница между бюджетными моделями и «люксом» вроде Claude Sonnet 4.6, GPT-5.4, Gemini 3.1 Pro?
Условия теста
Все 10 моделей тестировались на одном RAG-пайплайне: одна база (858 дел СИП + 4 часть ГК), один промпт, один реранкер, одни настройки. Менялась только LLM. Каждой модели задавался одинаковый вопрос + 2 уточнения. Два разных теста — по авторскому праву и по товарному знаку.
Каждую модель оценивал по 8 метрикам в формате «выполнил / частично / не выполнил»:
🔵 RAG-дисциплина — наличие галлюцинаций (не выдумывала ли модель номера дел и статьи?)
🔵 Точность вилки — обоснованность размера вилки (привязана ли к делам, рекомендован ли выгодный способ расчёта?)
🔵 Глубина квалификации — увидела ли скрытые нюансы (переработку, множественность, снижения по датам)
🔵 Практическая полезность — пошаговый план, рекомендации «доступным языком», конкретные инструменты доказывания
🔵 Арифметика — математически верный расчёт
🔵 Уточняющие вопросы — наличие обязательных триггеров (ст. 1295, реальность платежей, дата нарушения)
🔵 Формат промпта — структура ответа по инструкции, отсутствие markdown (#, **, ---)
🔵 Поддержка диалога — сохранение контекста при уточнениях
Результаты в прикреплённой таблице.
Хочется отметить следующие модели:
Claude Sonnet 4.6 — 1 место. Единственная модель, которая увидела три основания при переработке фото: воспроизведение (ст. 1301), неприкосновенность (ст. 1266) и удаление информации об авторе (ст. 1300). Вилка: 100–250 тыс. с привязкой к делам. Ни одной галлюцинации, идеальный формат.
Gemini 3.1 Pro — 2 место. Полный комплект по всем метрикам. Увидела два основания + отдельную компенсацию по ст. 1300. Заметила, что переход на твёрдую сумму выгоден истцу. На 20% дешевле Claude.
GPT-5.4 — 3 место. Единственная модель, спросившая про ст. 1295 (служебное произведение). Самая детальная стратегия. Минус — превышен объём ответа (промпт ограничивает размер).
Gemini 3.0 Flash — 4 место. Вилка адекватная, формат идеальный, ни одной галлюцинации. Но не объяснила почему лицензия невыгодна и не выделила переработку как отдельное нарушение.
Qwen3 Max — 8 место. Тактически грамотный совет (два варианта расчёта в иске), вилка адекватная. Но обнаружены галлюцинации: ссылка на ст. 1320 как на обязательный претензионный порядок (статья существует, но к претензиям не относится) и ссылка на дело А32-69603/2024 с суммой 930 000 руб., которого нет в базе. Для RAG-бота это критично.
DeepSeek R1 — 9 место. В тесте 2 выдала «максимум 20 916 000 руб.» — фантастический расчёт. Сослалась на дело А41-134957/2024, которого нет в базе. Систематически ломает формат. При цене 132₽/528₽ — дороже бюджетных, а результат хуже.
o3 Mini High — 10 место. Написала, что обрезка фотографий «не влияет на методику расчёта» — грубая ошибка. Вилка 20–40 тыс. — самая низкая. Перепутала сумму дела А40-44109/2025 (написала 29 754 вместо 54 931 руб.).
Модели на 5–7 местах — без галлюцинаций и с хорошим следованием промпту, но слабее по содержанию: вилки занижены, переработку не квалифицируют как отдельное нарушение, планы действий общие.
Стоимость моделей указана в таблице (цены с polza.ai, за 1M токенов).
Выводы
Для подобного проекта (бесплатный, MVP) Gemini 3.0 Flash является хорошей моделью — адекватная вилка, идеальное следование промпту, ни одной галлюцинации при минимальной цене.
Если нет ограничений по финансам — Claude Sonnet 4.6 и Gemini 3.1 Pro вне конкуренции. Gemini 3.1 Pro на 20% дешевле Claude при очень близком результате.
Кому интересно — подробные ответы каждой модели, метрики с пояснениями и полный разбор в прикреплённом файле ниже.
Провёл серию тестов — прогнал 10 разных моделей через бот с RAG-системой на одних и тех же вопросах.
Когда запускал бота, я не особо думал о выборе модели — просто взял Gemini 3.0 Flash Preview по советам из чата. Модель быстрая, дешёвая, меня в целом устраивает. Но со временем возник вопрос — а так ли она хороша конкретно в моём проекте? И насколько велика разница между бюджетными моделями и «люксом» вроде Claude Sonnet 4.6, GPT-5.4, Gemini 3.1 Pro?
Условия теста
Все 10 моделей тестировались на одном RAG-пайплайне: одна база (858 дел СИП + 4 часть ГК), один промпт, один реранкер, одни настройки. Менялась только LLM. Каждой модели задавался одинаковый вопрос + 2 уточнения. Два разных теста — по авторскому праву и по товарному знаку.
Каждую модель оценивал по 8 метрикам в формате «выполнил / частично / не выполнил»:
Результаты в прикреплённой таблице.
Хочется отметить следующие модели:
Claude Sonnet 4.6 — 1 место. Единственная модель, которая увидела три основания при переработке фото: воспроизведение (ст. 1301), неприкосновенность (ст. 1266) и удаление информации об авторе (ст. 1300). Вилка: 100–250 тыс. с привязкой к делам. Ни одной галлюцинации, идеальный формат.
Gemini 3.1 Pro — 2 место. Полный комплект по всем метрикам. Увидела два основания + отдельную компенсацию по ст. 1300. Заметила, что переход на твёрдую сумму выгоден истцу. На 20% дешевле Claude.
GPT-5.4 — 3 место. Единственная модель, спросившая про ст. 1295 (служебное произведение). Самая детальная стратегия. Минус — превышен объём ответа (промпт ограничивает размер).
Gemini 3.0 Flash — 4 место. Вилка адекватная, формат идеальный, ни одной галлюцинации. Но не объяснила почему лицензия невыгодна и не выделила переработку как отдельное нарушение.
Qwen3 Max — 8 место. Тактически грамотный совет (два варианта расчёта в иске), вилка адекватная. Но обнаружены галлюцинации: ссылка на ст. 1320 как на обязательный претензионный порядок (статья существует, но к претензиям не относится) и ссылка на дело А32-69603/2024 с суммой 930 000 руб., которого нет в базе. Для RAG-бота это критично.
DeepSeek R1 — 9 место. В тесте 2 выдала «максимум 20 916 000 руб.» — фантастический расчёт. Сослалась на дело А41-134957/2024, которого нет в базе. Систематически ломает формат. При цене 132₽/528₽ — дороже бюджетных, а результат хуже.
o3 Mini High — 10 место. Написала, что обрезка фотографий «не влияет на методику расчёта» — грубая ошибка. Вилка 20–40 тыс. — самая низкая. Перепутала сумму дела А40-44109/2025 (написала 29 754 вместо 54 931 руб.).
Модели на 5–7 местах — без галлюцинаций и с хорошим следованием промпту, но слабее по содержанию: вилки занижены, переработку не квалифицируют как отдельное нарушение, планы действий общие.
Стоимость моделей указана в таблице (цены с polza.ai, за 1M токенов).
Выводы
Для подобного проекта (бесплатный, MVP) Gemini 3.0 Flash является хорошей моделью — адекватная вилка, идеальное следование промпту, ни одной галлюцинации при минимальной цене.
Если нет ограничений по финансам — Claude Sonnet 4.6 и Gemini 3.1 Pro вне конкуренции. Gemini 3.1 Pro на 20% дешевле Claude при очень близком результате.
Кому интересно — подробные ответы каждой модели, метрики с пояснениями и полный разбор в прикреплённом файле ниже.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10👍2❤1
От бота к агенту
Честно, до недавнего времени я был уверен, что «ИИ-агент» — просто бот, которого переименовали, коммерческий ход, не более. Однако разница существенная — агент способен оценивать промежуточный результат и на основе этой оценки менять свой дальнейший ход.
Добавил своему юридическому боту (в сфере IP) способность принимать решения на промежуточных этапах. Для этого внёс три изменения в архитектуру:
✔️ Анализ вопроса перед поиском (Intake-агент)
Перед поиском отдельная LLM переводит бытовой язык пользователя в юридические термины, извлекает факты из сообщения и решает — начать поиск или задать дополнительный вопрос.
✔️ Порог релевантности (score threshold)
Бот научился отсеивать мусорные фрагменты (чанки) до того, как они будут переданы из векторного хранилища в нейросеть. Раньше передавал всё подряд — теперь фильтрует и меняет поведение, если качественного контекста мало.
✔️ Цикл поиска (retrieval loop)
Если первый поиск в базе дал мало результатов, бот сам формирует второй запрос, но с другими ключевыми словами и ищет ещё раз.
Тест изменений (на скриншотах)— один вопрос, два пайплайна:
➡️ Старый — линейный rag (скрин 1): одно основание → 45–90 тыс. руб.
➡️ Новый — agentic rag (скрин 2): агент определил переработку, применил два основания (ст. 1301 п.1 + п.2) → 66–180 тыс. руб.
Стал ли ответ точнее? Однозначно. Но я бы не спешил приписывать этот успех «магии» Agentic RAG. Часть улучшений — это результат донастройки фильтров и промптов.
Тем не менее, в архитектуре появилась та самая «агентная сущность» — система перестала следовать одному алгоритму и начала принимать решения на промежуточных этапах. Однако здесь важно понимать, агентность — это не всегда плюс. Чем больше в системе «самостоятельных» узлов, тем выше вероятность того, что агент примет неверное решение на промежуточном шаге и уверенно уведёт ответ в сторону. Автономность требует кратно большего внимания к настройке. Есть кейсы, где Agentic RAG будет чрезмерен или даже вреден, а классического линейного пайплайна хватит с головой, поэтому нужно выбирать инструмент под конкретные цели и задачи.
Кстати, кто хочет копнуть глубже — у Екатерины есть классный материал по agentic-RAG, рекомендую.
Честно, до недавнего времени я был уверен, что «ИИ-агент» — просто бот, которого переименовали, коммерческий ход, не более. Однако разница существенная — агент способен оценивать промежуточный результат и на основе этой оценки менять свой дальнейший ход.
Добавил своему юридическому боту (в сфере IP) способность принимать решения на промежуточных этапах. Для этого внёс три изменения в архитектуру:
Перед поиском отдельная LLM переводит бытовой язык пользователя в юридические термины, извлекает факты из сообщения и решает — начать поиск или задать дополнительный вопрос.
Пользователь пишет «украли фотки на озоне», но ведь база не понимает некоторых слов, а некоторые воспринимает совершенно не так как нам нужно, например "озон", для неё это скорее газ, чем маркетплейс. Добавил вызов LLM перед поиском, которая переформулирует запрос на юридический язык («нарушение исключительных авторских прав на фотографическое произведение, маркетплейс Ozon, компенсация ст. 1301 ГК РФ»), извлекает структурированные факты (тип объекта, роль пользователя, наличие переработки) и принимает решение: — данных достаточно, отправляем в работу — данных недостаточно, задаем дополнительный вопрос пользователю
Бот научился отсеивать мусорные фрагменты (чанки) до того, как они будут переданы из векторного хранилища в нейросеть. Раньше передавал всё подряд — теперь фильтрует и меняет поведение, если качественного контекста мало.
В боте уже был реранкер — модель, которая оценивает, насколько каждый найденный фрагмент подходит к вопросу. Из 30 найденных фрагментов он отбирал 10 лучших и передавал в нейросеть. Если же по теме поиска нашлось всего 5 близких фрагментов, то остальные 5 мест он заполнял потому что «надо» и тем «чем пришлось». В итоге LLM могла получить «хвост» из не релевантных фрагментов и начинала галлюцинировать на их основе. Добавил числовой порог, то есть если скор (оценка) фрагмента ниже определённого значения, то он отсеивается, сколько бы свободных мест ни оставалось.
Если первый поиск в базе дал мало результатов, бот сам формирует второй запрос, но с другими ключевыми словами и ищет ещё раз.
Раньше бот один раз обращался к базе — что нашёл, с тем и работал. Теперь после первого поиска происходит отдельный вызов LLM и она оценивает: хватает ли найденного? Если нет — формирует второй запрос с другими ключевыми словами, ищет ещё раз, а результаты от двух поисков объединяются. Если даже после повторного поиска релевантных фрагментов мало, то бот честно скажет, что практики в базе недостаточно, и предоставит то, что нашёл.
Тест изменений (на скриншотах)— один вопрос, два пайплайна:
Стал ли ответ точнее? Однозначно. Но я бы не спешил приписывать этот успех «магии» Agentic RAG. Часть улучшений — это результат донастройки фильтров и промптов.
Тем не менее, в архитектуре появилась та самая «агентная сущность» — система перестала следовать одному алгоритму и начала принимать решения на промежуточных этапах. Однако здесь важно понимать, агентность — это не всегда плюс. Чем больше в системе «самостоятельных» узлов, тем выше вероятность того, что агент примет неверное решение на промежуточном шаге и уверенно уведёт ответ в сторону. Автономность требует кратно большего внимания к настройке. Есть кейсы, где Agentic RAG будет чрезмерен или даже вреден, а классического линейного пайплайна хватит с головой, поэтому нужно выбирать инструмент под конкретные цели и задачи.
Кстати, кто хочет копнуть глубже — у Екатерины есть классный материал по agentic-RAG, рекомендую.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6👍3❤1