[Транспорт] Как я делал матчер правил возврата автобусных билетов
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Мы тут автоматизируем автобусы, недавно вот с нашей помощью все билеты в России стали электронными. Рынок только-только хоть как-то приходит в ИТ, и там всё ещё очень много всего делается в амбарных книгах.
Расскажу про один простой эпизод автоматизации, который уже десятки лет назад пройден в авиации и на железной дороге, но только-только начался у нас. Итак, ситуация: есть примерно сотня разных информационных систем, которые присылают нам данные про автобусные рейсы. Это набор самописных автоматизаций разных перевозчиков и конкурирующих коммерческих продуктов. Каждая система имеет свой формат записи о том, как делается возврат билета на автобус. Чаще всего — человекочитаемая запись на русском языке, написанная для операторов и кассиров, но около 20% систем вообще не присылают данные о возврате в принципе.
Часть правил пересекаются, причём может быть несколько уровней вложенности: «Все билеты невозвратные, но на этом направлении туда возвращаем по 259-ФЗ, обратно — вот по этим условиям».
Нам нужно показывать пассажиру условия возврата билета (возвратный, невозвратный, 100% возврат или нет, когда можно возвращать), использовать эти параметры для поиска, сравнения и, собственно, автоматизации возвратов.
Ну а мне нужно было понять, как несколько тысяч текстов на русском языке превратить в параметры билета, где хранить и как этим всем управлять.
Как выглядят ответы источников данных?
Вот примеры:
Первое, что приходит в голову — это NLP-разбор. Чтобы научить нейросетевой движок NLP разбирать всё это, нужен набор правил, который сформирует корпус для обучения. Чтобы получить набор правил, нужно распарсить всё вручную и свести к неким наборам правил в едином формате.
Решение оказалось простым, как бревно. Правила возврата почти у всех не меняются годами, и в месяц приходит всего несколько новых строк. У нас есть отдел контента, который занимается тем, что собирает данные из разных источников — например, обзванивает автовокзалы, собирает данные об остановках и так далее. Что-то из этого автоматизируется, что-то нет. То, что автоматизируется — покрывается скриптом и тестами и идёт в прод. То, что делается вручную, может быть упрощено тем, что в контент будут приходить уже подготовленные данные, то есть мы будем вызывать человека-оператора через некое API, содержащее типовую форму запроса.
Распарсить всё вручную один раз и поддерживать изменения вручную оказалось дешевле, чем прикручивать и поддерживать автоматизацию, а потом следить за её правильностью. В итоге мы использовали сложные нейросети — непосредственно мозг операторов. И они показали очень высокую производительность.
Потом мы добавили хеширование правила по MD5 после очистки от нефункциональных пробелов и приведения к одному регистру — чтобы понимать, что оно поменялось. Если оно поменялось — автоматизация ставит задачу отделу контента, а отдел контента заносит новое правило в нашу систему.
Опять же, правильно использовать для хранения множества правил решения класса BRMS. Но у нас всё оказалось проще, всё множество правил свелось к вот таким матрицам:
В этой итерации решили на модификаторы забить. Во-первых, непонятно какие они бывают. Во-вторых — похоже, что они мало где используются. По крайней мере, до сих пор особой необходимости в них не возникало.
Превращается это вот в такой текст единого формата:
Поэтому мы их храним прямо в своей системе, управляющей параметрами билетов. То есть, по сути, просто добавляем в базу данных в каждый билет ссылку на правила его возврата от данной компании.
Вот так это стало выглядеть:
GDS — это источники, дальше идёт «схлопывание» рейсов (один и тот же рейс может прийти из разных источников с некоторыми изменениями, больше про этот ад есть вот здесь, например).
Вот так работает уровень матчера правил. Из каждого рейса достаётся правило возврата, по его хешу ищется соответствующее наше правило (разобранное в нужный нам вид), и если всё получилось, оно применяется:
Часто GDS не присылает для какого-то рейса правила возврата. В таком случае мы можем завести свои, «ручные», правила возврата. Например, можем применить стандартные, прописанные в федеральном законе. Кстати, что интересно, по идее, это должны быть минимальные условия для всех, но на практике они часто либо улучшаются, либо ухудшаются перевозчиками.
У перевозчиков могут быть локальные правила, как я приводил пример — «для всех рейсов так, но на рейсах Москва — Петербург — вот так». Специально для этого мы для «ручных» правил сделали параметр «приоритет». В итоге такое «ручное» правило возврата состоит из трёх частей: параметры, по которым мы понимаем, что это правило подходит (город отправления/прибытия, перевозчик, GDS), приоритет и результат (собственно, те самые интервалы с процентами удержания). Когда GDS отдаёт рейс без правил возврата, мы идём в базу с «ручными» правилами, выбираем все подходящие и берём то, у которого наибольший приоритет. Дальше рейс декорируется этими полученными правилами.
Конечно, мы можем что-то не покрыть такими «ручными» правилами. Для этого мы сделали отчёт, в который попадают направления, не покрытые правилами. Его в ручном режиме разбирают сотрудники отдела контента.
Вот так. Как я говорил, всё довольно просто, но таких ситуаций на рынке ещё море, потому что автобусный рынок только-только открывает электронные продажи, и там огромный зоопарк самописных решений, либо же вообще часто никакой автоматизации нет.
Ну а мы теперь создали единую базу правил возврата билетов для каждого известного нам официального автобусного рейса в России.
===========
Источник:
habr.com
===========
Похожие новости:
- [Космонавтика, Транспорт] Роскосмос заявил о завершении заводских испытаний модуля «Наука»
- [Энергия и элементы питания, 3D-принтеры, Транспорт] В НИУ «МЭИ» представили 3D-принтер для печати деталей самолетов и кораблей
- [Научно-популярное, Энергия и элементы питания, Транспорт, Электроника для начинающих, Инженерные системы] Как сделать самодельный электрический багги с мощным мотором
- [Софт, Транспорт] ПО авиаперевозчика неправильно считало вес пассажиров, так как принимало женщин за детей
- [Транспорт] Как мы помогали внедрить по стране электронные билеты на автобусы
- [Энергия и элементы питания, Транспорт] Hummer представила электрический внедорожник EV SUV
- [Космонавтика, Транспорт] Sierra Nevada создаст пилотируемый космический самолет Dream Chaser
- [Биографии гиков, Транспорт, IT-компании] Руководителем проекта Google по разработке беспилотных автомобилей стал выходец из России
- [Бизнес-модели, Производство и разработка электроники, Транспорт] Ford сокращает производство автомобилей на шести заводах в США из-за нехватки чипов
- [Бизнес-модели, Автомобильные гаджеты, Транспорт, Будущее здесь] Ё-мобиль vs Tesla, Прохоров против Маска
Теги для поиска: #_transport (Транспорт), #_avtobus (автобус), #_passazhirskie_perevozki (пассажирские перевозки), #_avtoperevozki (автоперевозки), #_pravila_vozvrata (правила возврата), #_blog_kompanii_tutu.ru (
Блог компании Туту.ру
), #_transport (
Транспорт
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:51
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Мы тут автоматизируем автобусы, недавно вот с нашей помощью все билеты в России стали электронными. Рынок только-только хоть как-то приходит в ИТ, и там всё ещё очень много всего делается в амбарных книгах. Расскажу про один простой эпизод автоматизации, который уже десятки лет назад пройден в авиации и на железной дороге, но только-только начался у нас. Итак, ситуация: есть примерно сотня разных информационных систем, которые присылают нам данные про автобусные рейсы. Это набор самописных автоматизаций разных перевозчиков и конкурирующих коммерческих продуктов. Каждая система имеет свой формат записи о том, как делается возврат билета на автобус. Чаще всего — человекочитаемая запись на русском языке, написанная для операторов и кассиров, но около 20% систем вообще не присылают данные о возврате в принципе. Часть правил пересекаются, причём может быть несколько уровней вложенности: «Все билеты невозвратные, но на этом направлении туда возвращаем по 259-ФЗ, обратно — вот по этим условиям». Нам нужно показывать пассажиру условия возврата билета (возвратный, невозвратный, 100% возврат или нет, когда можно возвращать), использовать эти параметры для поиска, сравнения и, собственно, автоматизации возвратов. Ну а мне нужно было понять, как несколько тысяч текстов на русском языке превратить в параметры билета, где хранить и как этим всем управлять. Как выглядят ответы источников данных? Вот примеры:    Первое, что приходит в голову — это NLP-разбор. Чтобы научить нейросетевой движок NLP разбирать всё это, нужен набор правил, который сформирует корпус для обучения. Чтобы получить набор правил, нужно распарсить всё вручную и свести к неким наборам правил в едином формате. Решение оказалось простым, как бревно. Правила возврата почти у всех не меняются годами, и в месяц приходит всего несколько новых строк. У нас есть отдел контента, который занимается тем, что собирает данные из разных источников — например, обзванивает автовокзалы, собирает данные об остановках и так далее. Что-то из этого автоматизируется, что-то нет. То, что автоматизируется — покрывается скриптом и тестами и идёт в прод. То, что делается вручную, может быть упрощено тем, что в контент будут приходить уже подготовленные данные, то есть мы будем вызывать человека-оператора через некое API, содержащее типовую форму запроса. Распарсить всё вручную один раз и поддерживать изменения вручную оказалось дешевле, чем прикручивать и поддерживать автоматизацию, а потом следить за её правильностью. В итоге мы использовали сложные нейросети — непосредственно мозг операторов. И они показали очень высокую производительность. Потом мы добавили хеширование правила по MD5 после очистки от нефункциональных пробелов и приведения к одному регистру — чтобы понимать, что оно поменялось. Если оно поменялось — автоматизация ставит задачу отделу контента, а отдел контента заносит новое правило в нашу систему. Опять же, правильно использовать для хранения множества правил решения класса BRMS. Но у нас всё оказалось проще, всё множество правил свелось к вот таким матрицам:  В этой итерации решили на модификаторы забить. Во-первых, непонятно какие они бывают. Во-вторых — похоже, что они мало где используются. По крайней мере, до сих пор особой необходимости в них не возникало. Превращается это вот в такой текст единого формата:  Поэтому мы их храним прямо в своей системе, управляющей параметрами билетов. То есть, по сути, просто добавляем в базу данных в каждый билет ссылку на правила его возврата от данной компании. Вот так это стало выглядеть:  GDS — это источники, дальше идёт «схлопывание» рейсов (один и тот же рейс может прийти из разных источников с некоторыми изменениями, больше про этот ад есть вот здесь, например). Вот так работает уровень матчера правил. Из каждого рейса достаётся правило возврата, по его хешу ищется соответствующее наше правило (разобранное в нужный нам вид), и если всё получилось, оно применяется:  Часто GDS не присылает для какого-то рейса правила возврата. В таком случае мы можем завести свои, «ручные», правила возврата. Например, можем применить стандартные, прописанные в федеральном законе. Кстати, что интересно, по идее, это должны быть минимальные условия для всех, но на практике они часто либо улучшаются, либо ухудшаются перевозчиками. У перевозчиков могут быть локальные правила, как я приводил пример — «для всех рейсов так, но на рейсах Москва — Петербург — вот так». Специально для этого мы для «ручных» правил сделали параметр «приоритет». В итоге такое «ручное» правило возврата состоит из трёх частей: параметры, по которым мы понимаем, что это правило подходит (город отправления/прибытия, перевозчик, GDS), приоритет и результат (собственно, те самые интервалы с процентами удержания). Когда GDS отдаёт рейс без правил возврата, мы идём в базу с «ручными» правилами, выбираем все подходящие и берём то, у которого наибольший приоритет. Дальше рейс декорируется этими полученными правилами. Конечно, мы можем что-то не покрыть такими «ручными» правилами. Для этого мы сделали отчёт, в который попадают направления, не покрытые правилами. Его в ручном режиме разбирают сотрудники отдела контента. Вот так. Как я говорил, всё довольно просто, но таких ситуаций на рынке ещё море, потому что автобусный рынок только-только открывает электронные продажи, и там огромный зоопарк самописных решений, либо же вообще часто никакой автоматизации нет. Ну а мы теперь создали единую базу правил возврата билетов для каждого известного нам официального автобусного рейса в России. =========== Источник: habr.com =========== Похожие новости:
Блог компании Туту.ру ), #_transport ( Транспорт ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:51
Часовой пояс: UTC + 5