Как сравнить две версии документа нейросетью

Контрагент прислал договор «с небольшими правками». Файл выглядит почти как ваш: те же разделы, та же нумерация, тот же объём. Где-то внутри поменялись три формулировки, и одна из них переносит риск просрочки с исполнителя на вас. Найти её, читая двадцать страниц подряд второй раз, можно — но это час работы и высокая вероятность зевнуть ровно тот абзац, ради которого всё и затевалось.

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

Посимвольный diff и смысловое сравнение — разные инструменты

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

Проблема в другом. Diff отвечает на вопрос «где текст стал другим», а вам нужен ответ на вопрос «что теперь по-другому». Это не одно и то же. Правка «в течение 10 (десяти) рабочих дней» на «в течение 10 (десяти) календарных дней» — это два изменённых слова, крошечная подсветка среди сотни таких же. По смыслу это сокращение срока почти вдвое. Рядом с ней diff подсветит абзац, где юрист переставил запятые и заменил «Исполнитель обязуется» на «Исполнитель обязан» — визуально изменение крупнее, а значения у него ноль.

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

Смысловое сравнение решает ровно эту задачу: не показать различия, а рассортировать их по важности и объяснить последствия. Модель читает обе редакции как связный текст, понимает, что «рабочие дни» и «календарные дни» — не просто разные слова, узнаёт перенесённый пункт на новом месте и способна сказать, в чью пользу играет правка. Это не замена diff, а другой инструмент поверх него. Идеальный порядок работы — сначала смысловая сводка, чтобы понять картину, затем сверка критичных мест глазами по исходным файлам.

Что подготовить до сравнения

Модель работает с текстом, поэтому обе версии должны быть текстом. Скопируйте содержимое каждого файла целиком, не выборочно — если отдать модели только «спорные разделы», она не увидит, что условие из раздела 4 переехало в раздел 9, и честно сообщит, что его удалили.

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

Персональные данные и реквизиты, которые не нужны для сравнения, лучше убрать заранее — ФИО, номера счетов, паспортные данные. Для анализа условий они не требуются, а гигиена работы с любыми внешними сервисами от этого только выигрывает.

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

Базовый промт: сводка по разделам

Начинать стоит с общей карты — не с поиска подвохов, а с ответа на вопрос «что вообще происходит в этом документе».

Ниже две версии одного документа. Версия А — исходная, версия Б — с правками второй стороны.
Сравни их по смыслу, а не по символам. Опечатки, перестановку слов и стилистику игнорируй.
Выдай результат таблицей по разделам документа: номер и название раздела, что изменилось,
цитата из версии А, цитата из версии Б, последствие изменения одной фразой.
Разделы, где смысловых изменений нет, перечисли отдельной строкой списком.
Если пункт переехал в другой раздел без изменения смысла, отметь это как перенос, а не как удаление.

Версия А:
"""
[вставьте текст]
"""

Версия Б:
"""
[вставьте текст]
"""

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

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

Третья — отдельная категория «перенос». Без неё вы получите пару «удалено там / добавлено тут» и потратите время на разбирательство с несуществующей пропажей.

Как ловить тихие правки

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

Сравни версии А и Б только по параметрам, у которых есть значение: сроки, суммы,
проценты, штрафы и пени, порядок и сроки оплаты, гарантийные обязательства,
условия расторжения, ответственность сторон.
Выдай таблицу: параметр, значение в версии А, значение в версии Б, в чью пользу изменение.
Отдельно выпиши случаи, когда параметр был в версии А и исчез в версии Б,
и когда параметр появился в версии Б, а в версии А его не было.
Если значение не изменилось, строку не выводи.

Такой промт заставляет модель работать не по структуре документа, а по типу данных, и это ловит другое. Классический улов узкого прохода: замена рабочих дней на календарные, сдвиг точки отсчёта срока («с момента подписания» на «с момента получения уведомления»), исчезнувший потолок ответственности, добавленное автоматическое продление, смена «вправе» на «обязан» и обратно.

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

Проверь только одно: что из версии А отсутствует в версии Б.
Перечисли все выпавшие пункты и условия с цитатой из версии А и указанием раздела.
Для каждого напиши, было ли оно заменено похожей формулировкой в другом месте версии Б
или пропало полностью. Ничего, кроме пропаж, не разбирай.

Где этот способ подводит

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

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

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

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

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

Чем сравнивать

Задача сравнения упирается в объём: две редакции договора — это двойной объём текста в одном запросе, и модель должна удержать оба целиком. В каталоге Most AI под это подходят сильные текстовые модели — Claude Opus 4.8 и Sonnet 4.6, GPT-5.5, Gemini 3.1 Pro Preview. Начать разумно с бесплатного безлимитного чата ChatGPT: на документе средней длины он даёт нормальную сводку, и только если текст велик или цена ошибки высока, есть смысл переходить на флагманскую модель. Оплата в рублях, без VPN и без месячной подписки, актуальные цены — на странице прайсинга.

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

Частые вопросы