Чтобы сопоставить и сверить две таблицы с помощью ИИ, определите смысл строки и владельца каждого поля, очистите и проверьте ключи, сначала выполните точные соединения, а модель используйте только для кандидатов среди остатка. Отнесите каждую строку к совпадениям, записям только в A, только в B или конфликтам, а затем подтвердите результат количествами, контрольными суммами, доказательствами и утверждением человека.

Ключевые выводы:

До сравнения значений решите, какой источник авторитетен для каждого поля.

Отклоняйте дублирующиеся ключи и соединения «многие ко многим», пока они не размножили записи.

Точные совпадения — доказательство; оценки нечёткого сопоставления — кандидаты, которые ещё нужно проверить.

Сверяйте всю совокупность, включая несовпавшие и нерешённые записи.

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

Что определить, чтобы сопоставить и сверить две таблицы с помощью ИИ?

Начните с цели. Вы сверяете счета с платежами, сравниваете два списка контактов, ищете расхождения в запасах, проверяете миграцию или связываете записи с разными идентификаторами? Цель определяет гранулярность строки, допустимые отклонения, авторитетные поля и последствия ложного совпадения.

Для каждого файла запишите:

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

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

Запишите контракт сверки

Условие	Пример
Строка A	один выставленный счёт
Строка B	одна строка оплаты
Точный ключ	ID счёта и юрлицо
Связь	один к одному
Сумма	точно в валюте операции
Дата	три календарных дня, нужна проверка
Только A	счёт не найден в файле расчётов
Только B	строка расчёта не найдена в файле счетов
Владелец конфликта	финансовые операции

Такой контракт не позволит ИИ незаметно переопределить «совпадение» ради максимального процента совпавших записей.

Как подготовить и проверить ключи?

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

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

Перед соединением проверьте ключи:

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

Соединение «многие ко многим» может дать декартово произведение. Две строки в A и три в B превращаются в шесть строк результата, искажая количества и суммы, даже если каждая исходная строка выглядела корректной.

Ведите таблицу нормализованных ключей

Источник	ID строки	Исходный ключ	Нормализованный	Правило	Статус
A	A-1042	`inv-0017`	`INV-0017`	обрезка пробелов и верхний регистр утверждённого ID	действителен
B	B-881	`INV-0017`	`INV-0017`	без изменения	действителен
B	B-882	пусто	пусто	не выводить	исключение

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

Как выполнить точное сопоставление?

Загрузите обе таблицы в воспроизводимый запрос, модель формул, базу данных или скрипт. Power Query может объединять два запроса по одному или нескольким общим столбцам и поддерживает типы соединений, показывающие совпавшие и несовпавшие строки.［1］ Если цель — полная сверка, используйте полное внешнее соединение (full outer) или эквивалентный набор соединений.

Создайте четыре основные совокупности результатов:

Статус	Определение	Доказательство
matched	утверждённые ключи соответствуют, сравниваемые поля согласуются	ID обеих исходных строк и ключ совпадения
left_only	для записи A нет утверждённого совпадения в B	ID строки A и проверенный точный ключ
right_only	для записи B нет утверждённого совпадения в A	ID строки B и проверенный точный ключ
conflict	утверждённые ключи соответствуют, но контролируемые поля различаются	оба значения, допуск и владелец

Не используйте только внутреннее соединение (inner join). Оно показывает успешные совпадения, но скрывает несовпавшие записи. Точно так же не помечайте запись как совпавшую только потому, что совпало одно поле, если контракт требует составного ключа.

Сравнивайте поля по явным допускам

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

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

Сверяйте количества и суммы после точного соединения

Для стороны A докажите, что matched + left_only + conflict охватывает каждую исходную строку в пределах охвата с учётом правил связей. Выполните соответствующую проверку для стороны B. Пересчитайте суммы по статусам и сравните их с контрольными показателями зафиксированного источника.

Если связи «один ко многим» допустимы, сверяйте и на уровне строк, и на уровне бизнес-объектов. Например, несколько строк оплаты могут погашать один счёт; число строк различается, но сгруппированные суммы и совокупность счетов всё равно должны сходиться.

Когда применять ИИ или нечёткое сопоставление?

Используйте нечёткое сопоставление только после того, как точное сопоставление исчерпало утверждённые ключи, и только для оставшейся совокупности. Microsoft описывает нечёткое сопоставление (fuzzy matching) в Power Query как способ сравнивать текстовые значения по сходству и предоставляет настройки порога и преобразований.［2］ Поэтому оно полезно для отбора кандидатов, а не как автоматическое доказательство тождества.

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

Попросите ИИ предложить пары-кандидаты с обоснованием:

Для каждой несовпавшей записи A ранжируй не более трёх кандидатов из B, удовлетворяющих правилам блокировки. Покажи сравниваемые поля, точные различия, признаки сходства, противоречащие и недостающие доказательства. Не помечай пару как совпавшую. Пиши no candidate, если доказательств недостаточно.

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

Используйте таблицу для проверки человеком

ID A	ID B	Ключ	Метод	Оценка	Различия	Статус	Доказательство	Проверяющий
A-1042	B-881	INV-0017	точный	н/п	нет	принят	составной ключ	OP
A-1049	B-907	имя и почтовый блок	нечёткий кандидат	0.88	суффикс и сокращение улицы	проверка	нет общего внешнего ID	ожидает
A-1051	нет	ID счёта	точный поиск	н/п	отсутствует в B	left_only	запрос к источнику	OP

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

Процесс сверки (reconciliation) в OpenRefine также отличает кандидатов от подтверждённых совпадений и поддерживает проверку или сверку значений по внешнему сервису.［3］ Общий вывод: состояние кандидата должно оставаться отдельным от подтверждённого тождества.

Как разрешать конфликты, не скрывая их?

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

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

Используйте статусы вроде:

accepted_exact;
accepted_reviewed;
rejected_candidate;
left_only;
right_only;
conflict_open;
conflict_resolved;
out_of_scope.

Избегайте общего флага matched, который не отличает точное доказательство от субъективной проверки.

Профиль NIST по генеративному ИИ выделяет риски конфабуляций, целостности информации, приватности и человеческого надзора.［4］ Для сверки эти риски означают запросы, привязанные к источнику, минимальную передачу данных, очередь исключений и решение человека до того, как нечёткий кандидат изменит запись или запустит внешнее действие.

Что должен содержать итоговый отчёт сверки?

Подготовьте отчёт, который другой человек сможет воспроизвести:

цель, охват, версии источников и владельцы;
гранулярность строк, авторитетность, ключи, нормализация и допуски;
количества в источниках и контрольные суммы;
количества точных совпадений, записей только в A, только в B и конфликтов;
совокупность нечётких кандидатов и решения проверяющих;
нерешённые исключения и их владельцы;
контрольные показатели до и после;
версия запроса или скрипта и время запуска;
утверждения и исправления в исходных системах.

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

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

Какие ошибки следует избегать?

Соединение до проверки дублей и кардинальности

Неожиданные дубли создают размножение «многие ко многим». Профилируйте обе стороны и останавливайтесь на связях, которые контракт не разрешает.

Максимизация процента совпадений

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

Автоматическое принятие оценки нечёткого сопоставления

Оценка ранжирует кандидатов, но не подтверждает личность.

Скрытие остатка через inner join

Несовпавшие совокупности — часть ответа. Используйте контроли по всей совокупности и отдельные результаты «только A» и «только B».

Правка отчёта без исправления авторитетного источника

Локальные правки исчезнут при следующем запуске. Устраните проблему в системе-владельце или запишите, почему она остаётся исключением.

Итоги

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

Часто задаваемые вопросы (FAQ)

Какой ключ лучше для сопоставления двух таблиц?

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

Как найти строки только в одном файле?

Используйте полное внешнее соединение (full outer join) или парные антисоединения (anti-join) по утверждённому ключу. Храните таблицы «только A» и «только B» отдельно и сверяйте обе с числом строк источников.

Может ли ИИ сопоставить разные написания имени?

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

Какой порог нечёткого сопоставления выбрать?

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

Как избежать дублей после merge?

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

Что делать с несовпавшими строками?

Храните их в явных очередях «только A» и «только B» с ID источника, проверенными ключами, владельцами и решениями. Никогда не удаляйте их только ради сходимости итогов.

Как сверять небольшую разницу сумм?

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

Что доказывает полноту сверки?

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

Источники:

Microsoft Support - Merge queries (Power Query) — https://support.microsoft.com/en-US/Excel/merge-queries-power-query
Microsoft Support - Create a fuzzy match (Power Query) — https://support.microsoft.com/en-us/excel/create-a-fuzzy-match-power-query
OpenRefine - Reconciling — https://openrefine.org/docs/manual/reconciling/
NIST - Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 29 августа 2026 г.

Рекомендуемые статьи:

Как сопоставить и сверить две таблицы с помощью ИИ