ИИ-сравнение документов должно показывать точную правку, а не только пересказ различий

Если сотруднику нужно увидеть заменённые слова в редакциях Word, начните со встроенного сравнения. Настольный Word для Windows показывает изменения в отдельном документе; можно выбрать сравнение текста, оформления и комментариев. Новый модуль имеет смысл после проверки того, чего не хватает в этом рабочем процессе.

ИИ для юристов выбирают по задаче проверки договора или поиска решений фирмы.

Онлайн-сервисы тоже уже решают эту задачу. Compare by Embedika описывает поиск добавлений, изменений и удалений. GostDoc показывает две страницы рядом и подсвечивает слова. Алиал Групп заявляет смысловой анализ и отчёт по категориям. Мы прочитали их описания, но не проверяли качество сравнения на файлах клиента.

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

Вернёмся к архивным заявкам. Разницу нельзя принять по фразе «изменился экспорт». Сотрудник должен открыть старую и новую редакции в нужном месте и увидеть добавленное слово. Объяснение последствия помогает решить, надо ли менять код и сценарий проверки.

Адрес зависит от формата: раздел и абзац в Word, страница и область в PDF, строка и колонка в таблице. Повторяющейся цитаты недостаточно: она может встретиться в разных требованиях. Сохраняйте обе исходные редакции вместе с результатом, а у цитаты её адрес и окружающий раздел. Замена файла под тем же именем не должна менять основание отчёта.

Так выглядит задача для ИИ-агента: предъявить проверяемую разницу. Если модель не может обосновать последствие исходным текстом, пусть оставляет вопрос проверяющему. Догадка о намерениях заказчика не должна становиться новым требованием.

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

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

Перемещение тоже требует контекста. Если тот же абзац переехал внутри раздела, требование может остаться прежним. Если он оказался под заголовком «Только для администратора», область действия могла измениться. Решение «текст одинаковый, правок нет» здесь неверно.

Сравнение начинается до вызова модели. В Word есть абзацы и таблицы; в PDF текст может идти в другом порядке или быть картинкой. Если при чтении скана исчезло «не», последующий смысловой разбор уже получает неверную формулировку.

Для текстового PDF проверьте порядок строк и связь заголовка с абзацем. Для скана отдельно проверьте распознавание. В таблице важно сохранить название колонки: одно и то же значение в «Минимуме» и «Максимуме» задаёт разные условия. Простая склейка строк теряет эту связь.

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

До разработки соберите контрольные пары с известными правками. Автор документа отмечает ожидаемые изменения, проверяющий сверяет их с результатом. Включите и пары без смысловой правки, иначе модуль, который объявляет важным любое отличие, легко покажется полезным.

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

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

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

В работе над сайтом агент мог написать убедительный текст с несуществующим фактом. Другие агенты приносили разные числа из одного источника. Эти ошибки поймали при проверке. Из них следует ограниченный урок: уверенность объяснения не заменяет сверку с исходником.

Для сравнения редакций переносим именно это правило. Сначала проверяются вход, точные цитаты и адреса, затем объяснение последствия. Отдельный проверяющий не становится безошибочным: он тоже должен сверяться с исходником и контрольной парой.

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

Вычислимую часть приёмки можно отделить: цитата содержится в этой редакции, адрес ведёт к ней, обработанные блоки учтены. Оценку бизнес-последствия нельзя свести к совпадению строк. Её проверяет человек, который отвечает за требования.

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

В заказе есть две разные машины. Инженер ведёт машину агентов, которая пишет и проверяет код. Готовый модуль сравнивает файлы сотрудников; внутри него может вызываться модель. Агент, разрабатывающий продукт, и модель внутри продукта выполняют разные работы.

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

Не требуйте ИИ на каждом этапе. Чтение структуры, сопоставление блоков и проверку адресов можно выполнять программно; модель нужна там, где полезно объяснить изменение требования. Выбор проверяется на контрольных парах. Наличие LLM само по себе не улучшает ни распознавание, ни полноту результата.

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

На дату проверки 8 октября 2026 подписка на агентную разработку «Один проект» стоит 250 000 ₽/мес. Инженер ведёт машину агентов, правки идут в репозиторий клиента, одна задача находится в работе. Подписку можно поставить на паузу или отменить в любой месяц. Это цена разработки по подписке, не готового сервиса сравнения и не обещание завершить любой модуль за месяц.

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

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

1. Сначала проверьте готовый инструмент на своих разрешённых образцах.
2. Принимайте разницу с обеими цитатами и адресами; объяснение проверяйте по ним.
3. Непрочитанный фрагмент должен останавливать окончательный вывод.
4. Проверяйте пропуски, ложные отличия и неверные привязки раздельно.
5. Добавляйте обнаруженную ошибку в контрольные пары следующей версии.