TL;DR
CGM — метод сопоставления похожих записей между разными базами данных (например, найти какой товар из каталога поставщика соответствует товару в вашем каталоге). Работает в два шага: сначала отбрасывает кандидатов, которые не проходят жёсткую проверку по формальным признакам (код, единица измерения, диапазон значений), и только среди уцелевших LLM выбирает нужный по смыслу.
LLM при сопоставлении данных легко путается: она цепляется за текстовое сходство и игнорирует то, что "1000 см³" и "1.0 л" — это одно и то же, а даты и диапазоны не совпадают. В тестовом примере из статьи правильный вариант был текстово самым непохожим кандидатом (сходство 0.34 против 0.75 у неправильного) — модель без проверки чисел выбрала бы неверный товар. Без фильтра точность сопоставления (F1) была 0.08 — почти случайный результат.
Добавление одного простого шага — жёсткого отсева по формальным правилам перед тем, как LLM начнёт думать о смысле — подняло точность до 0.66. Если жёсткий фильтр отсеял всех кандидатов подряд (слишком строгие правила), правила ослабляются по одному, начиная с наименее важного, пока не останется хотя бы один вариант.
Схема метода
ШАГ 1: Задать жёсткие правила (код, единица измерения, диапазон)
→ список допустимых кандидатов (может быть пуст)
ШАГ 2: Если список пуст — ослабить правила по одному,
начиная с наименее важного
→ непустой список кандидатов
ШАГ 3: LLM выбирает лучший вариант ТОЛЬКО из этого списка
(смысловое сопоставление, без права выйти за границы списка)
→ финальный ответ + объяснение, какое правило сработало/ослаблено
Все три шага можно выполнить в одном промпте: сначала попросить модель явно перечислить, кто прошёл фильтр, потом — выбрать лучший вариант из прошедших.
Пример применения
Задача: Магазин автозапчастей сводит свой прайс-лист с прайсом нового поставщика. У поставщика объём двигателя указан в литрах, у вас — в см³, коды деталей записаны по-разному, названия моделей местами сокращены.
Промпт:
Ты сопоставляешь товар из нашего каталога с кандидатами из каталога поставщика.
НАШ ТОВАР:
Fiat Panda 141, объём двигателя 1000 см³, годы выпуска 1991–1996,
внутренний код FP141-C
КАНДИДАТЫ У ПОСТАВЩИКА:
1. Fiat Panda 145, объём 1.1 л, дата выпуска 15.03.1994, код FP145-D
2. Fiat Panda 141, объём 1.0 л, дата выпуска 20.08.1993, код FP141-C
3. Fiat Panda 141, объём 1.3 л, дата выпуска 10.01.1995, код FP141-C
ШАГ 1 — ЖЁСТКИЙ ФИЛЬТР:
Проверь каждого кандидата по правилам:
- код детали должен совпадать буквально
- объём двигателя (переведи литры в см³, умножив на 1000) должен совпадать
с точностью до 50 см³
- дата выпуска должна попадать в диапазон 1991–1996
Выведи таблицу: кандидат | прошёл фильтр (да/нет) | причина отсева.
Если после фильтра список пуст — ослабь ОДНО, наименее важное правило
(в порядке: дата → объём → код) и повтори.
ШАГ 2 — ВЫБОР:
Из тех, кто прошёл фильтр, выбери один наиболее подходящий вариант.
Объясни выбор.
Результат: Модель сначала покажет таблицу с разбором каждого кандидата — почему первый и третий отсеяны (не совпал объём или код), и только второй прошёл проверку. Затем даст финальный выбор — кандидат №2 — с коротким объяснением. Если бы фильтра не было, модель могла ошибочно выбрать кандидата с более похожим названием или датой, но неверным кодом.
Почему это работает
LLM хорошо улавливает смысловое сходство текста, но плохо держит в голове точные числа и единицы измерения одновременно с семантикой — она склонна доверять "похожести" названия больше, чем формальному несовпадению кода или единицы измерения.
Зато LLM отлично справляется с выбором лучшего варианта, когда вариантов немного и критерии ясны. Метод разделяет работу: скучную, механическую проверку чисел и кодов делает явный фильтр до того, как модель начинает рассуждать о смысле. LLM видит уже "очищенный" список и не может случайно выбрать структурно неверный вариант — потому что неверные варианты туда просто не попадают.
Рычаги управления: - Какие правила считать жёсткими, а какие — мягкими. Жёсткое правило (единица измерения, код) отсекает кандидата навсегда. Мягкое (похожесть названия модели) — просто добавляет вес при финальном выборе. Если сомневаетесь — начните с малого числа жёстких правил и расширяйте. - Порядок ослабления правил. Если фильтр слишком строгий и ничего не проходит — решите заранее, какое правило ослаблять первым (обычно наименее значимое — дата, а не код). - Приоритетная подсказка эксперта. Добавьте фразу вроде "сначала сверяй код, потом объём, в последнюю очередь дату" — это ускоряет и стабилизирует финальный выбор без изменения логики фильтра.
Шаблон промпта
Ты сопоставляешь запись из источника A с кандидатами из источника B.
ЗАПИСЬ ИЗ ИСТОЧНИКА A:
{данные_записи}
КАНДИДАТЫ ИЗ ИСТОЧНИКА B:
{список_кандидатов}
ШАГ 1 — ЖЁСТКИЙ ФИЛЬТР:
Проверь каждого кандидата по правилам (в порядке важности):
1. {жёсткое_правило_1, например: код должен совпадать буквально}
2. {жёсткое_правило_2, например: значение X должно совпадать с точностью Y}
3. {жёсткое_правило_3, например: дата должна попадать в диапазон Z}
Выведи таблицу: кандидат | прошёл (да/нет) | причина отсева.
Если список пуст — ослабь ОДНО правило, начиная с наименее важного
({порядок_ослабления}), и повтори проверку.
ШАГ 2 — ВЫБОР:
Из прошедших фильтр выбери наиболее подходящий вариант по смыслу.
Учти дополнительно: {мягкая_подсказка, например: приоритет — совпадение модели}.
Объясни выбор.
Что подставлять: {данные_записи} и {список_кандидатов} — ваши реальные данные; {жёсткое_правило_N} — формальные критерии, которые точно решают правильность (числа, коды, единицы, диапазоны); {порядок_ослабления} — какое правило отпускать первым при пустом списке; {мягкая_подсказка} — совет для финального выбора, не критичный для допуска.
🚀 Быстрый старт — вставь в чат:
Вот шаблон метода сопоставления записей с жёстким фильтром.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие у вас есть точные числовые/кодовые признаки для сравнения и что делать, если ни один кандидат не проходит фильтр — потому что без этого жёсткий фильтр не заработает. Она возьмёт паттерн из шаблона и подставит ваши правила.
Ограничения
⚠️ Нужны чёткие формальные критерии. Если разница между верным и похожим-но-неверным вариантом решается только смыслом текста (без чисел, кодов, дат) — жёсткий фильтр ничего не даёт. В тесте на данных, где критерии не были решающими, жёсткий фильтр даже снизил точность.
⚠️ Правила нужно знать заранее. Метод не помогает, если вы сами не знаете, по каким признакам отличить верный вариант от похожего неверного. LLM может подсказать возможные правила по примерам, но их всё равно нужно проверить руками.
⚠️ В чате фильтр "текстовый", не программный. В оригинальном исследовании фильтр — это код, который проверяет условие безошибочно. В обычном чате модель проверяет условие текстом — она может ошибиться в самой проверке (например, в переводе единиц). Для важных задач стоит выборочно проверять результат вручную.
Ресурсы
Constraint-Guided Enterprise Data Mapping with Large Language Models — Sebastian Monka, Pramod Anantharam, Thien Vo Minh, Lavdim Halilaj (Bosch Center for Artificial Intelligence). Proceedings of Machine Learning Research vol 284, 2026 Conference on Neurosymbolic Learning and Reasoning (NeSy).