3,583 papers
arXiv:2608.21401 72 7 авг. 2026 г. FREE

Generative Gap Filling: LLM угадывает вырезанный пункт договора точнее юристов

КЛЮЧЕВАЯ СУТЬ
Юристы десятилетиями считали: нет пункта в тексте – нет и подсказки, суд просто дописывает свои взгляды. Оказалось наоборот: LLM восстанавливает вырезанный из подписанного договора пункт в 9 случаях из 10, юристы – только в 6, обычные люди – в 5. Метод генеративного заполнения пробелов позволяет проверить логичность и согласованность договора ещё до подписания. Модель никогда не видела вырезанный пункт – она достроила его по стилю, тону и распределению рисков во всём остальном документе.
Адаптировать под запрос

TL;DR

Если убрать из подписанного договора реально согласованный пункт и попросить угадать что там было — обычные люди угадывают в половине случаев, юристы и студенты-юристы чуть лучше (около 6 из 10). LLM, получив только оставшийся текст договора, угадывает 9 раз из 10. Модели не видели вырезанный пункт — они восстановили его по тому, как написан весь остальной документ.

Юристы и учёные десятилетиями считали: если в контракте нет прямого текста на спорный вопрос, значит, оставшийся текст почти ничего не говорит о том, что стороны хотели — и суд, «заполняя пробел», на самом деле вписывает свои предпочтения. Оказалось наоборот: текст договора несёт гораздо больше скрытой информации, чем принято думать. Авторы сравнивают это с радиосигналом — даже неполный, он несёт достаточно, чтобы восстановить пропущенную часть, если знать, как слушать.

Метод простой: взять реальный документ, замаскировать один согласованный пункт, дать модели оставшийся текст плюс сценарий, который активировал бы этот пункт, и попросить предсказать содержание. Точность держится на двух источниках сразу: примерно две трети — это общие ожидания о том, как обычно строятся такие сделки, треть — конкретные формулировки именно этого документа.

🔬

Схема метода

ШАГ 1: Взять реальный документ → убрать (замаскировать) один согласованный пункт
ШАГ 2 (промпт): Дать модели оставшийся текст + сценарий, активирующий пропущенный пункт → попросить предсказать содержание
ШАГ 3 (опционально): Сравнить предсказание с реальным текстом → сигнал о согласованности документа

Шаг 2 выполняется в одном промпте.


🚀

Пример применения

Задача: Вы — предприниматель, заключаете договор с подрядчиком на разработку сайта или маркетинговое продвижение. Хотите проверить: логично ли составлен договор, не «повисает» ли где-то смысл, согласуются ли формулировки друг с другом.

Промпт:

Вот договор на [разработку сайта / оказание услуг] между заказчиком и подрядчиком.
Я специально не показываю тебе пункт про ответственность за задержку сдачи работ.

Сценарий: подрядчик сдал работу на 3 недели позже срока.

На основе стиля, тона и того, как в остальном документе распределены риски 
между сторонами (кто на кого больше давит формулировками, кто платит штрафы 
за другие нарушения), предположи:
1. Какая неустойка или штраф, скорее всего, прописаны за такую задержку
2. На что ты опираешься — на общую практику похожих договоров или на конкретные фразы именно этого текста

[вставить текст договора без пункта об ответственности за задержку]

Результат: модель даст предположение о размере неустойки и логике штрафа, отдельно объяснив, что взято из «типичной практики», а что — из конкретных формулировок договора. Дальше вы сверяете это с реальным пунктом договора: если предсказание сильно расходится с тем, что там написано на самом деле, — это сигнал перечитать документ внимательнее, возможно пункт составлен непоследовательно с остальным текстом.


🧠

Почему это работает

Раньше казалось, что без прямого текста на спорный вопрос модель (или человек) остаётся без опоры — гадает на глазок. На деле у LLM в «памяти» лежат тысячи похожих договоров: она хорошо знает, как обычно распределяются риски в сделках такого типа.

При этом модель одновременно считывает конкретные сигналы именно вашего текста — тон формулировок, кто и где идёт на уступки, насколько жёстко прописаны другие условия. Она совмещает «общий паттерн рынка» с «частным сигналом этого документа» — и это комбинация даёт точное предсказание там, где условие типично, и заметно слабее — где стороны договорились о чём-то нестандартном.

Рычаги управления: - Добавьте конкретный сценарий-триггер («что случилось») — модель точнее предсказывает, когда понимает, зачем нужен этот пункт - Попросите модель разделить источники предсказания (рынок vs текст) — так вы поймёте, насколько предсказание надёжно именно для вашего случая - Дайте несколько похожих документов для сравнения — усилит компонент «типичная практика»


📋

Шаблон промпта

Вот {тип документа} — договор, письмо, план — без пункта про {что пропущено}.

Сценарий, который бы этот пункт регулировал: {описание ситуации}.

На основе стиля, тона и того, как в остальном тексте распределены 
{риски / обязанности / полномочия} между сторонами, предположи:
1. Что, скорее всего, написано в пропущенном пункте
2. Отдельно укажи: что подсказывает типичная практика похожих документов, 
а что — конкретные формулировки именно этого текста

{вставить текст документа без нужного пункта}

🚀 Быстрый старт — вставь в чат:

Вот шаблон для проверки договора через "восстановление пропущенного пункта". 
Адаптируй под мою задачу: [твоя задача]. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит какой пункт закрыть и какой сценарий подставить — потому что без сценария-триггера модель не понимает, зачем этот пункт вообще нужен, и предсказание будет размытым.


⚠️

Ограничения

⚠️ Нестандартные условия — слабое место: когда стороны договорились о чём-то нетипичном для рынка, точность падает до 60%. Модель тянет предсказание к «среднему по больнице», а не к реальному уникальному решению сторон.

⚠️ Часть точности — не из вашего текста: до двух третей успеха держится на общем знании о типичных сделках. Если ваш документ осмысленно и обоснованно отклоняется от нормы — именно там предсказание может ошибиться, хотя это самое важное место.

⚠️ Это не юридическая экспертиза: метод даёт статистическое предположение «что обычно пишут», а не правовую оценку «что должно быть написано».


🔍

Как исследовали

Исследователи взяли реальные подписанные контракты — договор с художником, соглашение о гонораре с адвокатом, договор про поставку бутылок — и вырезали из каждого один по-настоящему согласованный пункт. Дали читателям три группы: обычных людей, юристов/студентов-юристов, и несколько LLM — все получили только оставшийся текст плюс сценарий, который бы этот пункт регулировал.

Люди угадали правильно примерно в половине случаев, юристы — в 59%, модели — в 88%. Чтобы проверить, что модель реально читает текст, а не просто угадывает «типичный ответ», авторы «перевернули» контракты — поменяли направление сделки, оставив рынок и закон неизменными — и предсказания модели сдвинулись вслед за изменённым текстом. Это ключевой момент: значит, модель действительно опирается на конкретные формулировки, а не только на общие шаблоны. Проверку повторили на 100+ других контрактах разных типов — результат устойчив.


🔗

Ресурсы

Yonathan A. Arbel, David A. Hoffman, Generative Gap Filling (University of Alabama, University of Pennsylvania Carey Law School). Связанная работа тех же авторов: Generative Interpretation, 99 N.Y.U. L. Rev. 451 (2024).


📋 Дайджест исследования

Ключевая суть

Юристы десятилетиями считали: нет пункта в тексте – нет и подсказки, суд просто дописывает свои взгляды. Оказалось наоборот: LLM восстанавливает вырезанный из подписанного договора пункт в 9 случаях из 10, юристы – только в 6, обычные люди – в 5. Метод генеративного заполнения пробелов позволяет проверить логичность и согласованность договора ещё до подписания. Модель никогда не видела вырезанный пункт – она достроила его по стилю, тону и распределению рисков во всём остальном документе.

Принцип работы

Модель совмещает два источника сразу: общий паттерн рынка (как обычно пишут такие сделки) и частный сигнал документа (тон, кто на кого давит формулировками, кто платит штрафы за другие нарушения). Две трети точности идут из знания рынка, треть – из конкретных слов именно этого текста. Без сценария-триггера («что случилось») модель не понимает, зачем этот пункт вообще нужен, – и предсказание расплывается.

Почему работает

Казалось: без прямого текста на спорный вопрос ни у судьи, ни у модели нет зацепки. На деле у LLM в памяти тысячи похожих договоров – она знает, как обычно распределяют риски в сделках такого типа. Текст договора несёт куда больше скрытой информации, чем считалось – он как неполный радиосигнал: даже вырезав кусок, остаётся достаточно, чтобы восстановить пропущенное. На нестандартных условиях точность падает до 60% – модель тянет предсказание к среднему по рынку, а не к уникальному решению сторон.

Когда применять

Проверка договоров до подписания → конкретно для типовых коммерческих сделок (подряд, поставка, оказание услуг), особенно когда нужно понять – логично ли составлен документ и не противоречат ли формулировки друг другу. НЕ подходит как замена юридической экспертизе и для договоров с осознанно нестандартными условиями – там модель почти наверняка ошибётся именно в самом важном месте.

Мини-рецепт

1. Замаскируй пункт: возьми реальный договор, убери один согласованный пункт (например, про ответственность за задержку)
2. Добавь сценарий-триггер: опиши ситуацию, которая бы этот пункт регулировал – без сценария модель гадает в туман
3. Попроси разделить источники: пусть модель отдельно скажет, что взято из типичной практики, а что – из конкретных формулировок этого текста
4. Сверь с реальностью: сравни предсказание с оригинальным пунктом – большое расхождение – сигнал перечитать документ внимательнее

Примеры

[ПЛОХО] : Проверь этот договор на ошибки
[ХОРОШО] : Вот договор на разработку сайта. Я скрыл пункт про неустойку за задержку сдачи. Сценарий: подрядчик сдал работу на 3 недели позже срока. На основе тона и того, как в остальном тексте распределены риски между сторонами, предположи размер неустойки. Отдельно укажи: что подсказывает типичная практика похожих договоров, а что – конкретные формулировки именно этого текста. [вставить текст договора без нужного пункта]
Источник: Generative Gap Filling
ArXiv ID: 2608.21401 | Сгенерировано: 2026-08-25 05:27
📖 Простыми словами

Generative Gap Filling

arXiv: 2608.21401

LLM понимают юридические документы не по отдельным словам, а по скрытой архитектуре баланса сил. Механика исследования проста: если вырезать из подписанного документа важный пункт, модель всё равно восстановит его через генеративное заполнение пробелов. Нейронка видит, как распределены риски по всему тексту, и моментально вычисляет недостающий кусок пазла, даже если саму формулировку начисто стёрли.

Это как если бы из детектива вырвали финальную главу, но внимательный сыщик всё равно назвал убийцу по косвенным уликам на каждой странице. Формально развязки нет, но контекст и внутренняя логика кричат об ответе так громко, что ошибиться трудно. Человек в такой ситуации тычет пальцем в небо, а языковая модель опирается на железные паттерны тысяч подобных историй.

Цифры в исследовании разносят людей всухую. Обычный человек угадывает удалённое условие сделки лишь в половине случаев, опытные юристы и студенты права вытягивают жалкие 6 из 10, а LLM попадает в яблочко 9 раз из 10. Модель восстанавливает реальные намерения сторон просто потому, что в её памяти лежат массивы аналогичных контрактов и она знает стандартное распределение рисков лучше любого эксперта.

Тестировали на строгих контрактах, но принцип универсален. Заказываешь разработку софта, маркетинг или арендуешь склад — скорми черновик нейросети на проверку структурной связности. Модель моментально вскроет повисший смысл, найдет неявные дыры и покажет, какие стандартные пункты подрядчик "случайно" забыл внести в договор.

Короче: LLM читает между строк лучше тех, кто эти строки составляет. AI понимает глубинную логику документов точнее людей, которые зевают над каждым абзацем. Прогоняй любой важный контракт через сетку перед подписью: она за секунду найдет перекос рисков и спасёт от судебных разборок.

Работа с исследованием

Адаптируйте исследование под ваши задачи или создайте готовый промпт на основе техник из исследования.

0 / 2000
~0.5-2 N-токенов ~10-30с
~0.3-1 N-токенов ~5-15с