Про JSON понимаю замечание. Мы используем его не ради скобок, а чтобы результат сразу был машиночитаемым для отчета и чтобы жестко зафиксировать поля: номер пункта, confidence и короткое объяснение. Чтобы качество не проседало, схема у нас простая и короткая, а в контекст мы даем только заранее отобранные кандидаты, иначе шум будет и без JSON. Плюс есть проверка формата и повторный запрос, если ответ развалился. При необходимости это можно делать через structured output, когда модель возвращает структуру по схеме еще надежнее. На практике важнее не сам JSON, а сколько нерелевантного текста попало в контекст, поэтому критичны предварительный отбор и нормализация текста
По Track Changes и нумерации: да, многие библиотеки это ломают. У нас поэтому сначала предобработка docx (убираем <w:del> , разворачиваем <w:ins> ), потом восстанавливаем номера пунктов через numbering.xml. Про AUTONUMLGL/LISTNUM — спасибо, хороший кейс
Формат результата сейчас простой: это не “исправленный договор”, а замечания/подсветка риск-пунктов в отчёте — номер пункта, к какому риску относится, confidence и короткое объяснение
Про “минуты”: я имел в виду ускорение первичного прохода по типовым рискам (мы видим 5×–10×), но это не тезис “договор можно не читать вообще”
Это практический инженерный кейс про внедрение LLM в юрпроцесс: архитектура, парсинг docx, нормализация нумерации, промпт и SGR, протокол экспериментов и измеримые эффекты.
Это не инструкция повторить один в один, потому что правила и таблица рисков у всех разные, но подход и инженерные решения можно переносить и адаптировать
Про JSON понимаю замечание. Мы используем его не ради скобок, а чтобы результат сразу был машиночитаемым для отчета и чтобы жестко зафиксировать поля: номер пункта, confidence и короткое объяснение. Чтобы качество не проседало, схема у нас простая и короткая, а в контекст мы даем только заранее отобранные кандидаты, иначе шум будет и без JSON. Плюс есть проверка формата и повторный запрос, если ответ развалился. При необходимости это можно делать через structured output, когда модель возвращает структуру по схеме еще надежнее. На практике важнее не сам JSON, а сколько нерелевантного текста попало в контекст, поэтому критичны предварительный отбор и нормализация текста
По Track Changes и нумерации: да, многие библиотеки это ломают. У нас поэтому сначала предобработка docx (убираем <w:del> , разворачиваем <w:ins> ), потом восстанавливаем номера пунктов через numbering.xml. Про AUTONUMLGL/LISTNUM — спасибо, хороший кейс
Формат результата сейчас простой: это не “исправленный договор”, а замечания/подсветка риск-пунктов в отчёте — номер пункта, к какому риску относится, confidence и короткое объяснение
Про “минуты”: я имел в виду ускорение первичного прохода по типовым рискам (мы видим 5×–10×), но это не тезис “договор можно не читать вообще”
Это практический инженерный кейс про внедрение LLM в юрпроцесс: архитектура, парсинг docx, нормализация нумерации, промпт и SGR, протокол экспериментов и измеримые эффекты.
Это не инструкция повторить один в один, потому что правила и таблица рисков у всех разные, но подход и инженерные решения можно переносить и адаптировать