ИИ для сравнения таблиц помогает сверить две версии реестра по ключу строки и получить список добавленных, исчезнувших и изменённых записей. Если сравнить файлы только по номеру строки, сортировка создаст ложные расхождения. Решение подходит, когда у каждой записи есть устойчивый идентификатор или его можно составить из нескольких полей.
Ключ прежде сравнения
Для сверки нужны две версии, ключ записи и список проверяемых полей; итогом служит журнал изменений с обоими исходными значениями.
Задача отличается от разговора с одной таблицей: здесь важна история каждой записи между двумя состояниями. В статье про работу ИИ с Excel и таблицами разобраны вопросы к отдельному набору данных. Сверка версий начинается раньше запроса к модели: сохраните оригиналы файлов, укажите дату выгрузки и назначьте владельца результата. Копии с названиями «итог» и «итог новый» мало помогают, если источник и момент выгрузки остаются загадкой.
Хороший ключ выбирают по бизнес-смыслу. Для заказов это идентификатор заказа; для справочника товаров часто подходит артикул вместе с вариантом упаковки. Фамилия покупателя, порядковый номер строки и цвет ячейки для такой роли слабые: значения меняются или повторяются. Если единого идентификатора нет, составьте ключ из полей, которые вместе дают уникальность, и проверьте число дублей в каждой версии. При совпадении ключей внутри одного файла автоматическая трактовка расхождения становится спорной.
- Зафиксируйте две исходные версии и перечень колонок для проверки.
- Отделите ключевые поля от описаний, сумм и дат.
- Сохраните пустые значения как отдельное состояние, без подмены нулём.
Проверяйте также стабильность ключа во времени: иногда карточка получает новый номер после переноса между системами. Для таких записей нужен отдельный журнал соответствий, иначе перенос выглядит как удаление и новое создание.
Подготовка данных
Перед сопоставлением приведите заголовки и значения к согласованному формату. Даты из Excel бывают настоящими датами, текстом или серийными числами; суммы содержат пробелы и разные десятичные разделители. ИИ полезен для предложения правил нормализации, но сами правила фиксируются явно и применяются одинаково к обеим версиям. Различие «Москва» и «г. Москва» иногда косметическое, а различие в валюте суммы уже существенное.
- Снимите перечень столбцов обеих версий и сопоставьте их по смыслу. Переименование колонки запишите отдельно.
- Очистите пробелы по краям, приведите даты и числа к одному виду, сохранив исходные ячейки.
- Проверьте уникальность составного ключа в обоих файлах и выгрузите коллизии в отдельный лист.
- Сравните множества ключей, затем значения выбранных полей для общих ключей.
Промпт для ChatGPT, GigaChat или YandexGPT формулируйте как спецификацию результата: «Получишь два набора с полем ключа; верни статус записи, старое и новое значение каждого изменённого поля, указатель на исходную строку; сомнительные совпадения выдели отдельно». При больших таблицах детерминированное соединение строк удобнее выполнять в Excel, Google Таблицах или скриптом, а модели отдавать объяснение спорных расхождений. Очистка и нормализация одной таблицы решает другую задачу: она готовит набор, но сама по себе оставляет историю изменений за рамками.
Журнал расхождений
Отчёт о сверке должен позволять повторить каждое утверждение без доверия к формулировке модели. В одной записи укажите ключ, статус, имя поля, исходное значение, новое значение и строки обоих файлов. Если строка добавлена, старое значение отсутствует; если исчезла, отсутствует новое. Отдельно пометьте изменение, которое следует из принятого правила нормализации, чтобы проверяющий видел разницу между содержанием и форматом.
| Статус | Пример | Действие |
|---|---|---|
| Добавлена | Ключ есть только в новой версии | Сверить источник создания |
| Исчезла | Ключ есть только в старой версии | Проверить удаление или фильтр выгрузки |
| Изменена | Один ключ, разные значения | Согласовать поле и владельца |
| Спорная | Дубли или неоднозначный ключ | Передать человеку |
Для условного реестра заказов изменение суммы при прежнем номере заказа требует просмотра первичного документа. Изменение пробелов в адресе может быть техническим шумом, если правила очистки утверждены заранее. Модель способна описать оба события одинаковым словом «изменено», поэтому категория решения рождается из правил отдела, без догадки по тексту. Важно хранить исходное значение рядом с нормализованным: иначе ошибку подготовки данных трудно обнаружить.
Когда список расхождений станет рабочим документом, полезна автоматизация сверки бизнес-процессов с журналом решений и ответственными. Начните с ручного принятия спорных строк: именно они показывают, какое правило нужно уточнить для следующего цикла.
Какие версии таблиц вашей команде приходится сверять регулярно?
Проверка результата
Сначала посчитайте контрольные величины: число уникальных ключей в каждой версии, пересечение, новые и исчезнувшие ключи. Эти четыре числа образуют простую арифметическую проверку покрытия. Затем возьмите несколько строк из каждой категории и найдите их в исходных файлах. Для изменений числовых полей сравните сумму разниц с ожидаемым движением показателя; совпадение сумм полезно, хотя само по себе ещё оставляет риск ошибки отдельной строки.
Человек утверждает изменения с последствиями: стоимость, срок, статус оплаты, ответственный, реквизиты. Он также решает, какое значение считается правдой, если источники противоречат друг другу. ИИ формирует объяснение и группирует повторы, но статус «согласовано» ставит владелец данных. Удобно добавить колонки «решение», «кто проверил», «дата» и ссылку на первичный документ. Тогда журнал остаётся пригодным для разговора через месяц, когда детали выгрузки уже забыты.
Возьмите две соседние версии одного реестра и сначала разберите дубли ключа. Пока дубли остаются в исходниках, красивый отчёт о различиях лишь маскирует неоднозначное сопоставление.
Проверяйте крайние случаи отдельно: пустая ячейка против нуля, дата против текста, исчезнувшая колонка, повторный ключ и строка после сортировки. Успех пилота измеряйте долей изменений, для которых есть обе исходные строки и понятное решение проверяющего. Такой критерий ближе к реальной работе, чем количество найденных цветных ячеек.
Рабочий цикл
После первой сверки закрепите правила в коротком паспорте процесса. Запишите, откуда берутся версии, кто запускает сравнение, какие поля образуют ключ, что нормализуется и какие изменения требуют согласования. Если команда ведёт таблицу в 1С или CRM, выгрузка должна сохранять идентификаторы источника. Подстановка новых номеров при каждом экспорте лишает сверку опоры. Для Google Таблиц полезно хранить отдельные снимки с датой, вместо перезаписи одного листа.
Автоматизация может каждую неделю собирать файлы, выполнять точное сопоставление и выдавать человеку очередь спорных строк. В n8n сценарий удобно строить вокруг события появления новой выгрузки, но решение о принятии изменений оставьте за владельцем реестра. Следите за качеством входа: рост дублей, пропавшие ключи и неожиданные новые колонки означают проблему источника, вместо запроса на более длинный промпт.
Если задача состоит в создании строк из письма или переписки, полезнее подход к таблице из текста. Для сверки двух готовых версий главный результат иной: воспроизводимая цепочка от исходной ячейки к решению. Хорошая система позволяет открыть оба файла и понять причину каждой отметки без повторного диалога с моделью.
- Храните оригиналы и версию правил рядом с журналом.
- Назначьте владельца согласования каждой категории изменений.
- Возвращайте выявленные ошибки экспорта команде источника.
Повторяйте сверку на одинаковом наборе проверочных записей после каждого изменения правила. Если отчёт внезапно показывает меньше расхождений, проверьте, исчезли ли реальные ошибки или новый фильтр спрятал их. Полезно хранить несколько заранее известных различий как контрольные примеры и сверять их с каждым новым запуском.