Сравнение документов нейросетью: что она находит

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

Что модель находит, а diff нет

Четыре типа различий, где преимущество очевидно.

Изменённое условие при переписанной формулировке. Пункт сформулирован заново другими словами, а смысл сдвинулся. Diff покажет, что абзац переписан целиком, — и не скажет, что именно поменялось.

Перенесённое обязательство. Пункт переехал из одного раздела в другой и слегка изменился. Для diff это удаление и добавление, для модели — одно изменение.

Добавленное исключение. В список появилось «за исключением случаев, когда…». Одна вставка, меняющая работу всего пункта.

Убранная гарантия. Самое опасное: отсутствие текста человек не замечает, потому что глазу не за что зацепиться.

Коротко, по типам различий:

Последний пункт и есть главная причина использовать модель: людям плохо даётся замечать отсутствующее, а вопрос «чего в новой версии больше нет» модели задаётся явно.

Обязательные проверки

Без них схему нельзя пускать дальше эксперимента.

Ссылка на пункт для каждого различия. Номер и цитата из обеих версий. Без ссылки строка не считается найденной.

Обратный проход. Отдельным запросом спросить: «что есть в первой версии и отсутствует во второй». Пропуски ловятся именно так, а не общим вопросом «найди различия».

Программная сверка цитат. Цитата встречается в тексте дословно? Номер пункта существует? Десяток строк кода, ловит целый класс ошибок.

Двойной прогон с обратным порядком. Сравните A с B и B с A. Если списки не зеркальны, документ идёт на ручное чтение.

Четвёртый приём стоит недорого и ловит нестабильность извлечения на длинном тексте — почему это важно в юридических документах.

Как работать с длинными документами

Практическая часть, где решается и качество, и бюджет.

Два договора по тридцать страниц в одном запросе — это дорого и хуже по качеству: на длинном контексте точность падает. Работает другой порядок:

Сначала выровнять структуру. Разбить обе версии по разделам своим кодом и сопоставить разделы между собой.

Потом сравнивать попарно. Раздел с разделом, а не документ с документом.

Потом свести программно. Собрать результаты кодом, а не просить модель пересказать пересказ.

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

Где это применимо

Пять сценариев с обратимой ошибкой.

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

Свой шаблон против присланного. Что добавлено, что убрано, где отклонение от типового.

Обновление регламента. Что поменялось для сотрудников с прошлой редакции.

Две редакции технического задания. Что дописали заказчик и подрядчик.

Своя и чужая версия перевода. Расхождения в терминологии и смысле.

Общее: модель готовит сводку, решение принимает человек. Как только сводка превращается в вывод «можно подписывать», граница нарушена.

Чего делать не стоит

Три вещи.

Автоматически принимать изменения. Даже помеченные как косметические.

Просить оценку вместо перечисления. «Стало ли хуже» — вопрос, на который модель ответит уверенно и необоснованно.

Доверять полноте без обратного прохода. Список различий выглядит убедительно независимо от того, полон он или нет — почему пропуск неотличим от отсутствия.

Сколько это стоит

Порядок величин.

Два раздела по паре страниц — это тысячи входных токенов, сводка на выходе короткая. Полное сравнение договора на тридцать страниц по разделам — десятки тысяч токенов, то есть рубли при ставках за миллион.

Дороже становится в одном случае: если гонять оба документа целиком при каждом уточняющем вопросе. Разбор по разделам и повторное использование извлечённого решают это — как перевести объём в рубли.

В каталоге на 9 сентября 2026 года 49 позиций в пятнадцати семействах, платные текстовые от 1 ₽ за миллион. Для сравнения по разделам достаточно недорогой позиции, но на юридическом тексте разница между моделями заметнее — проверяйте на своих документах: методика.

Что уходит наружу

Документы — коммерческая информация, часто с персональными данными сторон.

Обезличивайте, где задача позволяет. Для поиска изменений в условиях имена сторон обычно не нужны.

Отправляйте разделы, а не документы. Это и приватность, и деньги.

Определите перечень. Не «любые документы», а конкретные типы.

Прочитайте, что хранит провайдер. У нас это llms.txt; общий разбор — что уходит провайдеру.

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

Как внедрять

Пять шагов.

1. Возьмите двадцать пар документов с известным результатом — те, где вы уже знаете, что изменилось.
2. Опишите, что считается существенным. Сроки, суммы, ответственность, порядок расторжения — ваш список.
3. Прогоните и сравните с тем, что нашёл человек.
4. Считайте пропуски отдельно от ошибок. Ложное различие видно и стоит минуты; пропущенное не видно и стоит дорого.
5. Оставьте решение человеку. Всегда.

Четвёртый пункт ключевой: обычная точность здесь бесполезна, потому что усредняет две ошибки с несопоставимой ценой.

Как оформить результат

Форма выдачи определяет, будут ли сводкой пользоваться. Четыре требования.

Таблица, а не текст. Пункт, было, стало, тип изменения. Читается за минуту вместо связного пересказа на две страницы.

Тип изменения отдельным полем. Добавлено, убрано, изменено, перенесено. Это позволяет отсортировать и посмотреть сначала на убранное — самую опасную категорию.

Существенность отдельным полем. По вашему списку критериев, а не по мнению модели: она помечает, попадает ли изменение в названные вами категории, а решение о важности принимаете вы.

Ссылки в обе стороны. Пункт в старой версии и пункт в новой. Без этого проверка каждой строки превращается в поиск.

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

Чего мы не утверждаем

Мы не юристы, и это не юридическая консультация.

Не заменяем инструменты сравнения версий. Для кода и структурированных документов обычный diff точнее; модель полезна там, где важен смысл, а не символы.

Не сравниваем модели по качеству. Своих замеров мы не делали.

Не обещаем полноты. Проверки снижают долю пропусков, но не обнуляют её.

Что нужно, чтобы попробовать

Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов и без зарубежной карты. Оплата российской картой в рублях, один ключ на весь каталог.

Платные текстовые модели доступны сразу на приветственном бонусе: взять одну пару своих документов, где вы точно знаете разницу, и посмотреть, найдёт ли её модель, — проверка на десять минут без пополнения.

И про масштаб: чем длиннее документы, тем важнее выравнивание разделов до сравнения. Большая часть пропусков возникает не потому, что модель не заметила изменение, а потому, что ей дали сравнивать не те куски.

Что держать в голове

Diff показывает, где текст отличается; модель — что это значит. Ради этого её и берут, и ради этого же приходится проверять полноту.

Обязательный приём — обратный проход: отдельно спросить, чего в новой версии больше нет. Убранная гарантия не бросается в глаза ни человеку, ни списку различий, составленному одним запросом.

Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Сравнить свою пару документов: keydealer.ru/login.