Почему ИИ путает товары и клиентов: проверяем мастер-данные до автоматизации

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

Найдите сущности, на которых держится процесс

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

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

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

Различайте совпадение названий и совпадение объектов

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

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

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

Проверьте качество на реальных исключениях

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

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

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

Назначьте владельца и путь исправления

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

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

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

Ограничьте действия ИИ при неоднозначности

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

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

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

Разберите учебный случай с номенклатурой

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

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

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

Покажите руководителю связь качества и результата

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

Разделите быстрые исправления и системные изменения. Где-то достаточно уточнить обязательное поле, где-то нужен единый порядок ведения данных между системами. Выбор MDM-решения имеет смысл обсуждать после понимания масштаба, владельцев и источников. Покупка инструмента сама по себе не создаёт согласованные определения сущностей.

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

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

Где обсудить эту задачу на практике

Navicon и Arenadata Harmony MDM заявляют обсуждение качества мастер-данных, их роли в ИИ-проектах и управленческих условий внедрения. Это тематическая встреча для тех, чьи процессы зависят от согласованной информации о товарах, клиентах и других сущностях. Программу подтвердили по странице организатора.

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

Посмотреть программу и условия: MDM в эпоху ИИ: новая роль мастер-данных и реальность проектов внедрения. В карточке можно перейти к организатору и проверить актуальные дату, формат, стоимость и порядок регистрации.

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