Как сравнить две версии документа с помощью ИИ без выдумок

Чтобы сравнить две версии документа с помощью ИИ и минимизировать риск выдуманных различий, сначала сформируйте механический diff, затем передавайте модели не полные документы, а отдельные элементы этого diff с устойчивыми идентификаторами и исходными цитатами. ИИ должен классифицировать уже зафиксированные изменения, а не искать их заново. Завершайте работу реестром, в котором каждый элемент diff имеет статус «учтено», «шум» или «требуется ручная проверка».

Что потребуется

• две неизменяемые копии документа: старая и новая версия;
• инструмент сравнения, фиксирующий вставки, удаления и замены;
• проверенное извлечение текста и структуры из исходных файлов;
• реестр элементов diff с уникальными идентификаторами;
• модель, которой передаются только подготовленные элементы diff;
• ручная проверка цитат и выводов по исходным документам.

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

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

Шаг 1. Зафиксируйте версии и правила сравнения

Сохраните исходные файлы отдельно и однозначно обозначьте их, например: «Регламент_2026-05-10_старая_версия» и «Регламент_2026-07-01_новая_версия». Зафиксируйте контрольные признаки файлов: имя, размер, дату получения и при необходимости хеш-сумму. Не редактируйте эти копии во время сравнения.

До получения diff определите, какие виды изменений должны попадать в отчет:

• смысловые: обязанности, права, запреты, условия и исключения;
• числовые: суммы, проценты, даты, сроки и единицы измерения;
• структурные: добавление, удаление и перемещение разделов;
• редакционные: орфография, пунктуация и стилистика;
• форматные: нумерация, выделение, списки, таблицы и расположение реквизитов.

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

Шаг 2. Проверьте извлечение текста и структуры

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

• комментарии и ответы на комментарии;
• режим исправлений, удаленный и добавленный текст;
• сноски и концевые сноски;
• колонтитулы, номера страниц и водяные знаки;
• подписи к рисункам и текст внутри схем;
• объединенные ячейки и многоуровневые заголовки таблиц;
• нумерация списков и перекрестные ссылки;
• порядок чтения колонок и текстовых блоков в PDF;
• символы, распознанные из сканированного документа с ошибками.

Перед сравнением сопоставьте извлеченный текст с исходным файлом выборочно и по критичным областям. Проверьте начало и конец документа, несколько таблиц, сноски, колонтитулы, пункты с числами и отрицаниями. Если используется OCR, отдельно проверьте похожие символы: «0» и «О», «1» и «I», десятичные разделители, знаки минуса и частицы «не».

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

Шаг 3. Получите механический diff

Используйте встроенное сравнение текстового редактора, систему контроля версий или специализированный diff-инструмент. На этом этапе не требуется объяснять смысл: задача инструмента — зафиксировать точные вставки, удаления, замены и предполагаемые перемещения.

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

Формат элемента diff

Каждому изменению присвойте уникальный идентификатор. Сохраняйте не только измененный текст, но и место, тип операции и контекст:

ID: DIFF-0042
Старая версия: Регламент_2026-05-10
Новая версия: Регламент_2026-07-01
Раздел старой версии: 4.2
Раздел новой версии: 4.2
Тип механической операции: замена
Старый фрагмент: в течение 10 рабочих дней
Новый фрагмент: в течение 5 рабочих дней
Контекст до: Исполнитель направляет отчет
Контекст после: после окончания отчетного периода
Источник: страница 7, абзац 3
Примечание инструмента: нет

Для чистого добавления поле старого фрагмента должно содержать значение «отсутствует в старой версии». Для чистого удаления используйте значение «отсутствует в новой версии». Это не цитата, а явное обозначение отсутствующей стороны:

ID: DIFF-0043
Тип механической операции: добавление
Старый фрагмент: отсутствует в старой версии
Новый фрагмент: Заказчик вправе запросить промежуточный отчет.
Раздел новой версии: 4.3
Контекст до: 4.2. Срок предоставления отчета
Контекст после: 5. Ответственность сторон

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

Как отмечать перемещения

Перемещение нельзя автоматически считать удалением и добавлением. Создавайте предполагаемую связь между двумя элементами только при полном или проверяемом совпадении текста:

ID: DIFF-0051
Тип механической операции: предполагаемое перемещение
Старое расположение: раздел 3.4
Новое расположение: раздел 6.2
Старый фрагмент: [полный текст пункта]
Новый фрагмент: [полный текст пункта]
Совпадение: полное
Требуется проверка нумерации и ссылок: да

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

Шаг 4. Удалите данные, которые нельзя передавать модели

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

[КЛИЕНТ_1]
[СОТРУДНИК_3]
[СУММА_A]
[АДРЕС_ОБЪЕКТА]
[НОМЕР_ДОГОВОРА]

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

Шаг 5. Передайте модели элементы diff, а не полные документы

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

Ты классифицируешь элементы механического diff двух версий документа.

Правила:
1. Рассматривай только переданные элементы diff.
2. Не ищи дополнительные изменения и не используй внешние знания.
3. Не исправляй и не дополняй исходные цитаты.
4. Сохраняй идентификатор каждого элемента.
5. Для добавления допускается значение:
   «отсутствует в старой версии».
6. Для удаления допускается значение:
   «отсутствует в новой версии».
7. Если старый и новый фрагменты нельзя надежно сопоставить,
   установи статус «требуется ручная проверка».
8. Не отбрасывай форматное изменение, если из данных нельзя доказать,
   что оно не влияет на структуру или юридическое значение.
9. Практическое последствие указывай только тогда, когда оно прямо
   следует из цитат. Иначе пиши:
   «нельзя определить без дополнительного контекста».

Верни таблицу с колонками:
- ID diff;
- раздел или пункт;
- механическая операция;
- классификация;
- старый фрагмент;
- новый фрагмент;
- практическое последствие;
- статус проверки;
- причина ручной проверки.

Допустимые классификации:
- добавление;
- удаление;
- замена;
- изменение числа;
- изменение срока;
- изменение обязанности;
- изменение права;
- изменение запрета;
- изменение исключения;
- редакционная правка;
- форматное изменение;
- перемещение без изменения текста;
- неоднозначное сопоставление.

ЭЛЕМЕНТЫ DIFF:
[вставьте подготовленные элементы]

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

Шаг 6. Проверьте каждую строку по идентификатору

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

1. ID существует в исходном реестре diff;
2. старый и новый фрагменты воспроизведены без изменений;
3. для добавления или удаления корректно указана отсутствующая сторона;
4. раздел и контекст позволяют найти фрагмент в исходном документе;
5. классификация соответствует механической операции;
6. описанное последствие действительно следует из цитат;
7. один элемент diff не потерялся внутри объединенной строки.

Модель может объединить несколько соседних изменений в одну запись. Это допустимо для аналитического отчета, но в проверочном реестре необходимо сохранить все исходные ID. Например, объединенная строка должна ссылаться на «DIFF-0042, DIFF-0043», а не скрывать второй элемент.

Шаг 7. Отдельно проверьте изменения высокого риска

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

Проверь переданные элементы diff на изменения высокого риска.

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

Не ищи новые изменения вне списка.
Не меняй цитаты.
Для каждого вывода укажи ID diff.
Если значение нельзя интерпретировать без соседнего раздела,
установи статус «требуется ручная проверка».

Особенно внимательно проверяйте изменение числа вместе с единицей измерения. Замена «10 дней» на «10 рабочих дней» отличается от простой редакционной правки. Аналогично отдельной проверки требуют валюты, часовые пояса, десятичные разделители и частицы отрицания.

Шаг 8. Ведите итоговый реестр покрытия

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

Используйте только три итоговых статуса:

• учтено — элемент отражен в отчете и проверен по исходнику;
• шум — элемент проверен и обоснованно исключен;
• требуется ручная проверка — сопоставление или значение неоднозначно.

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

Пример проверяемой классификации

Элемент механического diff:

ID: DIFF-0067
Тип механической операции: замена
Раздел: 5.1
Старый фрагмент: в течение 10 рабочих дней
Новый фрагмент: в течение 5 рабочих дней
Контекст: Исполнитель направляет отчет после окончания периода.

Корректная классификация: «изменение срока; срок сокращен с 10 до 5 рабочих дней». Обе величины и единица времени присутствуют в исходных фрагментах.

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

Типичные ошибки

• Передача модели двух полных документов вместо diff. Модель повторно ищет изменения и может пропустить часть правок.
• Отсутствие ID. Невозможно доказать, что каждый элемент механического сравнения учтен.
• Требование двух цитат при чистом добавлении. Оно провоцирует модель придумывать отсутствующий старый фрагмент.
• Автоматическое удаление форматных изменений. Может потеряться структурно или юридически значимая правка.
• Непроверенное извлечение из PDF или DOCX. Сравнение выполняется по неполному представлению документа.
• Сопоставление по количеству строк. Число строк отчета не подтверждает покрытие diff.
• Доверие уровню уверенности. Самооценка модели не заменяет проверку по исходным файлам.
• Отсутствие статуса «требуется ручная проверка». Неоднозначные элементы вынужденно получают ложную классификацию.

Итоговый чек-лист

• Старая и новая версии однозначно обозначены и сохранены без изменений.
• Проверено извлечение основного текста, таблиц, сносок, комментариев и исправлений.
• Получен механический diff с уникальными идентификаторами.
• Для каждого элемента сохранены операция, цитаты, раздел и контекст.
• Добавления и удаления имеют явную отметку об отсутствии одной стороны.
• Перемещения выделены отдельно от удалений и вставок.
• Нормализация пробелов отделена от оценки смысловой значимости.
• Модели передаются элементы diff, а не полные документы.
• Каждый вывод содержит ID исходного изменения.
• Числа, сроки, отрицания, обязанности и исключения проверены отдельно.
• Каждый ID внесен в реестр со статусом и ссылкой на исходник.
• Все неоднозначные элементы направлены на ручную проверку.

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