О компании Новости Продукты и сервисы Наши клиенты Контакты

О лаборатории Технологии Направления работ Публикации Бэкграунд

25.07.2016

Внедрили поддержку кодов ОКАТО, ОКТМО и ФИАС

Изначально мы ориентировали сервис ahunter.ru исключительно на приведение почтовых адресов к структурированному стандартному виду, которое сопровождается восстановлением пропущенных полей и исправлением ошибок. Все эти действия, как правило, необходимы для решения внутренних задач компаний по систематизации сведений об их клиентах и контрагентах. Корректные и нормализованные контактные данные клиентов нужны на всех этапах работы CRM, начиная от создания нового клиента и заканчивая организацией кросс-продаж.

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

Одной из таких смежных задач является интеграция клиентской базы с государственными информационными системами, такими как ГИС ЖКХ. Например, такое может потребоваться, если банк принимает коммунальные платежи. В этом случае информация о платежах должна передаваться в ГИС ЖКХ в соответствии с федеральный законом от 21.07.2014 N 209-ФЗ. Для осуществления такой интеграции адреса клиентов должны быть привязаны к кодам, которые используются в этих системах. На данный момент для различных нужд учета в разных информационных системах могут использоваться различные способы кодификации, такие как ОКАТО, ОКТМО, КЛАДР и ФИАС. В частности, последняя используется в ГИС ЖКХ, поскольку позволяет присваивать коды адресным объектам с точностью до дома.

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

• ОКАТО - код объекта административно-территориального деления, которому принадлежит обработанный адрес.
• ОКТМО – код территории муниципального образования, которой принадлежит адрес.
• ИФНС – коды инспекций федеральной налоговой службы, обслуживающих физических и юридических лиц соответственно, по обработанному адресу.
• КЛАДР – код адреса по классификатору адресов России до улицы включительно.
• ФИАС – код адреса в рамках федеральной информационной адресной системы до номера дома включительно.

С новыми возможностями API для форматов JSON и XML можно ознакомиться по следующим ссылкам здесь и здесь соответственно.

15.06.2016

Обогатили телефонную базу и базу GPS-координат

Сервис ahunter.ru и его корпоративный аналог ahunterES используют различные эталонные базы для нужд обработки и стандартизации контактных данных. При обработке почтовых адресов данные продукты используют базу GPS-координат, чтобы пользователи имели возможность получать координаты для обрабатываемых адресов. Координаты бывают полезны в случае, если, например, требуется оценить расстояние между адресом нахождения клиента и офисами, в которых организация обслуживает клиентов. Это в свою очередь позволяет отыскать для каждого клиента ближайший к нему офис. Точность, с которой выполняются такого рода оценки, зависит от полноты базы данных, содержащей координаты.

При попытке определить координаты адреса с точностью до конкретного дома наш сервис ищет этот дом в координатной базе. Если дом найти не удается в силу неполноты этой базы, то предпринимается попытка найти координаты для улицы, указанной в адресе. В случае неудачи берется следующее адресное поле. Эти действия могут повторяться вплоть до поля адреса, содержащего регион РФ. С каждым таким переходом от более конкретного поля к его родителю соответствие возвращаемых координат исходному адресу уменьшается. Хотя эти координаты можно использовать в бизнес-задачах, погрешность решения этих задач возрастает. Например, если в качестве координат места нахождения клиента возвращается широта и долгота середины улицы, а не конкретного дома, то расчеты расстояний между клиентом и офисами компании становятся менее точными.

Для повышения точности решения таких задач мы предприняли попытку обогатить нашу координатную базу за счет извлечения координат адресных объектов из открытых источников. Кроме того, мы провели оптимизацию и улучшение самих алгоритмов, используемых при извлечении и консолидации этих сведений. В сравнении с предыдущей версией координатной базы новая версия содержит на 70% больше сведений о домах на территории России, а также на 50% больше сведений об улицах городов и населенных пунктов.

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

30.05.2016

Разработали решение по унификации сведений о должниках

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

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

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

Данное решение устанавливается в инфраструктуре коллекторского агентства и интегрируется с его внутренней базой данных, где ведется накопление контактных данных должников. Для стандартизации контактных данных решение использует возможности сервиса ahunter.ru посредством его API. Помимо стандартизации решение выявляет дубли в разрезе каждого должника. Чтобы признать почтовые адреса дублями они необязательно должны быть полностью идентичными, достаточно наличия частичного сходства. После дедупликации DebtorCleanse выполняет оценку вероятности нахождения должника по каждому из его адресов. Данная оценка позволяет коллекторскому агентству повысить эффективность коммуникации с конкретным должником, поскольку из всего массива его контактных данных выбирается наиболее предпочтительный адрес, по которому человека можно найти с наибольшей вероятностью.

11.03.2016

Разработали средство для перевода проектов

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

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

• Возможность перевода продукта, который изначально не был предназначен для интернационального использования. Многие существующие технологии перевода программных продуктов рассчитаны на то, что в исходные тексты заранее должны внедряться соответствующие конструкции, обрабатываемые системой перевода при формировании языковой версии продукта. Например, так устроен gettext. Наши продукты изначально не ориентировались на использование такого рода технологий. Кроме того, мы посчитали, что внедрение такой технологии в наши существующие продукты приведет к необоснованному засорению программного кода. Также принцип, реализуемый в gettext, не позволяет выполнять перевод нетекстовых файлов. Поэтому использование данных i18n решений мы посчитали нецелесообразным.
• Отсутствие привязки к конкретному языку программирования, на котором написаны исходные тексты. В наших продуктах исходные тексты представлены на C++, Perl, JavaScript, CSS а также на языках разметки HTML и XML. Поэтому нам нужны были инструментальные средства, позволяющие охватить весь этот спектр без излишней подготовки и преобразования исходников.
• Автоматическое обнаружение в исходных текстах фрагментов, которые требуется перевести. Большинство исходных текстов, в том числе документация на HTML, содержат синтаксические конструкции, тэги и разметку, которые не должны переводиться, вместе с тем они не должны отвлекать переводчика и отнимать у него время на поиск целевых фрагментов, которые, в отличие от разметки, перевести требуется.
• Возможность перевода нетекстовых файлов, например файлов с изображениями. Зачастую картинки содержат текстовые надписи, которые также требуется перевести. В продукте ahunterES используется около сотни изображений, каждый из которых требовалось просмотреть и при необходимости подготовить соответствующий перевод. Поэтому технология перевода проекта должна была обеспечивать удобные средства для контроля переводов изображений.
• Эргономика и свой словарь терминов. Наши продукты содержат довольно много специфической терминологии, поэтому нам требовалось ведение собственного словаря терминов и их переводов на другой язык. Также требовался автоматический поиск терминов в переводимых текстах и их замена на соответствующие переводы. Кроме того, общим требованием к инструментальным средствам перевода была минимизация числа действий, которые требуется предпринять пользователю, чтобы выполнять перевод, а также защита уже подготовленного перевода от случайной порчи или изменений.
• Поиск переводов и интеграция с онлайн переводчиками. В общей сложности в рамках ahunterES требовалось перевести тексты, суммарно содержащие полмиллиона символов. При этом многие фразы и термины в разных текстах нашего продукта повторяются довольно часто. Поэтому необходимые нам средства перевода должны были позволять оперативно отыскивать уже переведенные фразы и их переводы по ключевым словам. Нам нужно было выполнять поиск фрагментов как на языке оригинала, так и на языке переводов. Кроме поиска нам хотелось, чтобы инструментальные средства умели работать с онлайн переводчиками посредством API, чтобы пользователь, не покидая своей рабочей среды, мог задействовать онлайн-средства автоматического перевода.
• Пожалуй, самым важным нашим требованием к технологии перевода была поддержка жизненного цикла продукта. Нам нужно было не просто перевести все имеющиеся у нас тексты, но и обеспечить поддержку их жизненного цикла. Дело в том, что наши продукты постоянно изменяются, в них появляются новые возможности, а также исправляются ошибки и недочеты. На жизненном пути продукта неизбежно происходят изменения в текстах, требующих перевода. В особенности это касается документации к ahunter.ru, которая со временем пополняется и уточняется. Нам было важно, чтобы переведенная версия нашего продукта всегда находилась в актуальном состоянии и соответствовала текущей версии языка-оригинала. А для этого средства перевода должны отслеживать изменения в оригиналах и оповещать переводчика о текстовых фрагментах, которые требуется актуализировать.

Поскольку наша компания имеет большой задел и опыт в области обработки текстов, мы решили самостоятельно разработать соответствующее решение для перевода наших продуктов на другие языки и удовлетворяющее всем нашим требованиям. Такое решение было нами разработано и апробировано на продуктах ahunter.ru и ahunterES.

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

20.01.2016

Добавили транслитерацию и перевод адресов в ahunter.ru

Мы продолжаем расширять функциональность сервиса ahunter.ru. Для использования сервиса за пределами России мы добавили возможности по прямой и обратной транслитерации обрабатываемых сервисом почтовых адресов.

Прямая транслитерация заключается в преобразовании символов, составляющих ответы сервиса, в символы латиницы. Для прямой транслитерации мы реализовали ГОСТ 7.79-2000. Прямая транслитерация является достаточно очевидной процедурой, поскольку подразумевает прямую замену каждой буквы русского алфавита на соответствующий символ или последовательность символов латиницы. Возможности прямой транслитерации включаются автоматически при работе с англоязычной версией сервиса.

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

Дополнительную специфику в проблему обратной транслитерации добавляет работа с почтовыми адресами. Мы проанализировали выборку почтовых адресов наших зарубежных партнеров и обнаружили, что при попытке ввода почтовых адресов латиницей пользователи часто пытаются выполнить не транслитерацию, а перевод на английский язык. Например, адрес, «город Москва, улица Тверская, д.1, 5» может быть записана как «city of Moscow, Tverskaja street, house 1, room 5». Для выполнения стандартизации таких почтовых адресов обычных правил транслитерации уже не достаточно и необходимо использовать методы перевода почтовых адресов с английского языка на русский.

Мы реализовали данный функционал и успешно внедрили его на ahunter.ru. В настоящий момент транслитерация с элементами перевода доступна при стандартизации почтовых адресов, а также в функциях сервиса, отвечающих за формирование подсказок почтовых адресов в процессе их ввода пользователями. Новые возможности доступны и для пользователей нашего продукта ahunterES.