Почему индивидуальный подход к модели Ntropy является единственным решением для обеспечения высокой производительности

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

Хорошо, — скажете вы, — тогда мы просто создадим классификатор транзакций собственными силами. Привлекательность владения конвейером от начала до конца с возможностью настройки и настройки по своему усмотрению заманчива. К сожалению, отечественные модели неадекватны и хрупки. Категоризация транзакций по своей сути представляет собой проблему длинного хвоста. Если бы я представил вам 1 миллион транзакций, вы могли бы обнаружить, что 500 000 из них принадлежат одним и тем же 300 компаниям, а остальные 500 000 принадлежат 100 000 разных компаний. Это означает, что у вас есть два варианта:

  1. Создайте что-то быстрое и простое, что попадет в топ-300 компаний. У вас будет впечатляющая модель, которая быстро понимает половину ваших данных о транзакциях, но для понимания 75% ваших данных могут потребоваться годы.
  2. Определите шаблоны транзакций и запишите правила для предсказания длинного хвоста. То, что может показаться надежной внутренней моделью, может резко развалиться по мере изменения распределения данных. И реальность такова, что мы живем во взаимосвязанной экономике, которая собирает финансовые данные из разрозненных источников. Полезные сведения можно получить при просмотре транзакций в разное время, в разных регионах, на счетах, в агрегаторах и отраслях.

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

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

Этот пост не о настройке.

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

Речь идет о понимании истории, которую рассказывают транзакции.

Речь идет о понимании того, что значит классифицировать транзакцию.

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

Три источника проблем

На высоком уровне действительно есть три вещи, которые ухудшают производительность классификатора транзакций.

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

Проблемы, связанные со схемой

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

  • Ваши категории более специфичны, чем наши. Мы не можем сопоставить только рестораны, скажем, с мексиканскими или итальянскими ресторанами.
  • Ваши категории более общие, чем наши. Наш ярлык «консультации по программному обеспечению» не подходит ни к одному «консалтингу», ни к «программному обеспечению».
  • Ваши категории плохо определены. Например, «специальные операции».
  • Наша интерпретация и ваша интерпретация категории могут отличаться (включают ли государственные пособия отчисления в фонд социального обеспечения или только вытягивание средств из него?)

Сопоставление меток (сопоставление каждой категории в нашей иерархии с одной в вашей) также может дать сбой, если они зависят не только от метки. Важным примером является категория «кредиты». Если у пользователя в качестве категорий есть и «выплаты по кредиту», и «выплаты по кредиту», то невозможно сопоставить наш ярлык с их. Для этого им потребуется добавить дополнительную логику для проверки типа записи транзакции и назначить выплату для входящих и оплату для исходящих транзакций.

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

Проблемы на уровне транзакции

Что такое финансовые операции?

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

Описание: ACH PULL ORIG CO NAME:Wood LTD ORIG ID:400005498 EED:210510 INDN:Door LLC SEC:CCD PMT DET:MATER

Сумма: 5000 долларов США.

Тип записи:исходящая

который можно обобщить как

«ООО «Дор» отправило компании Wood LTD 5000 долларов за строительные материалы».

В широком смысле цель категоризации транзакций состоит в том, чтобы преобразовать приведенный выше фрагмент в приведенное ниже предложение. При этом происходит три отдельных шага. На первом этапе нам нужно извлечь всю необходимую информацию, включая отправителя и получателя денег, сумму, тип ввода, имена людей, даты, местоположения и любые описания на естественном языке. На втором этапе мы должны использовать какую-то внешнюю базу данных, чтобы выяснить, кто и что представляют собой найденные нами именованные сущности (например, нам нужно подтвердить в Google, что Door LLC действительно продает двери). Затем, на третьем и последнем шаге, нам нужно собрать всю эту информацию, чтобы собрать воедино то, что имеет наибольший логический смысл, и присвоить категорию (в данном случае оплата строительных материалов).

Почему сложно классифицировать транзакции?

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

  1. Имена могут быть запутаны, искажены или усечены до такой степени, что мы не сможем восстановить исходное имя продавца. Пример — British Airways против British Air против British.
  2. В мире более 200 миллионов компаний, и для всех недостаточно уникальных названий. Аббревиатуры — отличный пример. Например, рассмотрим дебетовую транзакцию для «ACH PYMT TO NRA 4905588409». Возможно, вы поспешите решить, что NRA означает Национальную стрелковую ассоциацию, но для ресторана, вероятно, более вероятно, что NRA — это Национальная ассоциация ресторанов. Без дополнительной информации мы не можем делать никаких предположений о транзакции, какими бы очевидными они ни казались.
  3. Многие организации предоставляют более одного товара или услуги. Мы предположили, что Wood LTD продает древесину. Но что, если они также продавали продукты деревообработки? Внезапно мы не знаем, была ли покупка на материалы или на производственное оборудование!

К счастью, мы можем решить или обойти большинство этих проблем. (а) искажения имен имеют шаблоны, которые могут усвоить наши модели (обычно это удаления, которые сохраняют произносимый звук, например амазон -> амзн). (б) учитывая отрасль владельца счета, сумму, местоположение и тип записи, некоторые результаты гораздо более вероятны. Мы также можем фильтровать на основе популярности организации. (c) учитывая сумму и историю транзакций, мы можем подтолкнуть прогнозы к материалам, а не к оборудованию. Тем не менее, еще не совсем очевидно, что выбрать.

Все эти решения зависят от одного абсолютно важного компонента, который будет отличаться для каждого отдельного пользователя: контекст. Даже в решении (а) мы исходим из того, что наши транзакции выполняются на английском языке, что может привести к впечатляющим ошибкам, если не соответствует действительности. Предположим, у нас есть транзакция «PIX PMT». Если бы мы знали, что транзакция была на португальском языке, мы могли бы разумно сделать вывод, что PIX — это бразильская платежная система, но если бы транзакция была на английском языке, более вероятно, что pix — это сокращение от слова «картинки». В решении (b) Spectrum — крупная кабельная компания в США, а в Индии — крупная компания по производству одежды. А в (с) мы делаем (весьма вероятное) предположение, что дверная компания отправляет деньги деревообрабатывающей компании на закупку материалов для производства дверей. Но это все еще предположение, и все модели категоризации должны решить, что считать обоснованным предположением. Всегда есть вероятность, что эта транзакция может быть связана с чем-то другим, например, с древесиной для улучшения помещений.

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

Постановка проблемы и проблемная постановка

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

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

Мы разберемся с этим в каждом конкретном случае.

Метаданные (транзакции обычно содержат неполную информацию):

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

Описание => Тип записи => Сумма => Тип владельца счета (бизнес, потребитель,…) => Код валюты ISO и страна => Владелец счета => Дата.

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

Владелец счета — это наиболее естественный способ пометить конкретный набор транзакций как отличный от другого. Также предполагается, что наиболее точные решения следует настраивать либо на уровне пользователя, либо на уровне владельца аккаунта. Вместо предоставления повторяющихся, но полезных метаданных, таких как отрасль владельцев учетных записей, может быть более эффективным и действенным создание пользовательских классификаторов для каждого пользователя/владельца учетной записи.

Один из (транзакции не всегда точно вписываются в одну категорию)

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

В нашей первой итерации API категоризации Ntropy эта проблема была нашей главной заботой. Наше решение состояло в том, чтобы обеспечить классификацию с несколькими метками. Благодаря компонуемости это значительно увеличило выразительность нашей модели. Вместо, скажем, фиксированных классов C, теперь существовало 2^C возможных классов, по одному для каждой комбинации выходных меток (для сравнения, 100 классов будут означать 1⁰³⁰ возможных выходных данных). На практике мы сократили количество меток до 4 на транзакцию. тем не менее, количество классов было больше похоже на C⁴, который по-прежнему составляет колоссальный 1 миллион. Чтобы увидеть это в действии, рассмотрите возможность подписки на Netflix. Он будет состоять из трех ярлыков: телевидение, подписка, развлечения.

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

Во второй итерации API категоризации Ntropy у нас не было другого выбора, кроме как принять классификатор с одной меткой. Конечно, ни один такой классификатор не может достичь 100% точности, но это не значит, что мы не можем приблизиться к нему. Однако есть два способа взломать 100% точность, и они дают нам представление о различных компромиссах.

  1. Все того же класса. Эквивалентно высказыванию «Все транзакции являются транзакциями». 100% точность, но ноль специфичности и ноль информации.
  2. Каждая транзакция — это отдельный класс. Эквивалентно простой проверке уникальных записей. Бесконечная специфичность, но и ноль информации.

Может показаться удивительным, что такие противоположные пределы могут дать 100% точность, но это многое говорит нам о том, чего мы надеемся достичь. В хорошем наборе категорий должно быть ровно столько категорий, чтобы они могли уместиться в памяти человека (7 ± 2, кажется, естественный предел), а также содержать смысл. Возможно, Операционные расходы слишком общие, а счета за электроэнергию слишком специфичны, но Расходы на оборудование могут быть в самый раз. При достаточном размышлении и усилиях можно построить достаточно последовательный, широкий и удобный набор категорий. Однако однажды сделав это, вы в конце концов вспомните, почему метод одного класса был второй итерацией Ntropy API.

В одноклассовой системе категоризации совпадения классов неизбежны. Рассмотрим две категории: заработная плата и налоги. Они кажутся довольно разными, пока вы не столкнетесь с такой транзакцией, как «GUSTO PAYRLL TAX 693557 5bmsdkgmmo MONEYMAN LLC». (пасхальное яйцо, возьмите хорошие наушники и поищите эту компанию ;)). Это налог на заработную плату. Это считается зарплатой или налогом? Должна ли заработная плата включать общие расходы на работника (которые также включают их налоги) или просто компенсацию после уплаты налогов?

К счастью, в этом случае, как и в большинстве других, эта проблема решаема.

Чтобы решить проблему перекрытия категорий, все, что нам нужно сделать, это сказать нашим моделям, как сделать выбор! Вот где лучше всего работает персонализация. Машинное обучение невероятно хорошо находит закономерности в данных, и пока имеется достаточно таких примеров классификации налога на заработную плату, наши алгоритмы могут улавливать закономерности. Вопрос «достаточно» может быть трудным (и позже мы рассмотрим его более количественно), но интуитивно полезно подумать о том, сколько образцов транзакций потребуется человеку, чтобы понять, что происходит.

Категории, понятные человеку (все расходятся во мнениях относительно того, как интерпретировать ярлык)

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

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

Мы можем быстро увидеть, что настройка — единственное решение, которое распутывает вещи. Однако на этом этот раздел не заканчивается. Это потому, что даже с настройкой модели все еще сложно классифицировать. Это потому, что это требует изучения неизвестного или неопределенного шаблона.

Для иллюстрации предположим, что я даю вам 300 тарелок с едой, по 100 блюд японской, итальянской и марокканской кухни. Если бы я попросил вас построить классификатор, который может попробовать 50 блюд из каждой кухни, а затем предсказать следующие 50, я полагаю, вы смогли бы построить довольно хорошую модель. Категории четко определены, и должны быть шаблоны, которые отличают одну кухню от другой. Теперь давайте усложним. Вместо этого, скажем, я хочу, чтобы вы дополнительно классифицировали, считается ли блюдо «особым блюдом». Рассмотрим три возможных стратегии маркировки блюд как особенных, каждая из которых будет объяснять разные явления:

Блюдо считается особенным, если я подбрасываю монету 5 раз, и она 4 раза выпадает орлом.

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

Дораяки, тажин из баранины и касио и пепе считаются особенными.

  • Второй пример — это то, что мы называем неопределенным. Неясно, есть ли закономерность, или это просто заучивание. И, если есть закономерность, неясно, являются ли образцы, которые мы видели, полностью репрезентативными для всех будущих образцов (ошибка обобщения). При построении набора категорий мы не можем обучить модель примерам, подобным А, а затем ожидать, что она будет успешно предсказывать примеры, подобные В, за исключением случаев, когда: (1) А и В подобны. (2) Мы говорим модели, что A и B подобны. Вот два примера неопределенных категорий транзакций: 1. специальные транзакции. Если специальные транзакции касаются авиабилетов, тайской еды и автокредитов, а мы показываем только примеры авиатарифов, то у него нет надежды предсказать автокредиты. 2. Сотрудники компании. Это в основном запоминание, но возможно, что набор соответствующих сотрудников (приблизительно) конечен, и может существовать шаблон того, как транзакции выглядят для внутренних сотрудников по сравнению с внешними подрядчиками. В этом случае нам просто нужно научить модель достаточному количеству примеров, чтобы понять, на чем сосредоточиться.

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

  • Третий пример тесно связан с проблемой метаданных, обсуждавшейся ранее. Здесь есть четкая закономерность, и это хорошо. Единственная проблема заключается в том, что данные, содержащие шаблон, никогда не передаются нашей модели! Вы можете себе представить, что «специальные транзакции» соответствуют любой транзакции, помеченной Бобом из бухгалтерии. Мы не знаем Боба. Наша модель тоже. Единственное решение здесь — добавить в модель дополнительные входные данные (например, имя аннотатора).

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

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

Если все это звучит круто, вы также можете написать нам по адресу [email protected], и мы будем рады помочь вам начать работу с пользовательскими моделями Ntropy. Спасибо за прочтение 👋!