Nous automatisons les bus ici; récemment, avec notre aide, tous les billets en Russie sont devenus électroniques . Le marché n'entre que d'une manière ou d'une autre dans l'informatique, et il y a encore beaucoup de choses à faire dans les livres de grenier.
Je vais vous parler d'un simple épisode d'automatisation, qui s'est déjà achevé il y a des décennies dans l'aviation et sur le chemin de fer, mais qui ne fait que commencer avec nous. Donc, la situation: il existe une centaine de systèmes d'information différents qui nous envoient des données sur les itinéraires de bus. Il s'agit d'un ensemble d'automatisations auto-écrites de différents transporteurs et produits commerciaux concurrents. Chaque système a son propre format d'enregistrement de la manière dont le retour du ticket de bus est effectué. Le plus souvent - un enregistrement lisible par l'homme en russe, écrit pour les opérateurs et les caissiers, mais environ 20% des systèmes n'envoient pas du tout de données de retour.
Certaines règles se chevauchent et il peut y avoir plusieurs niveaux d'imbrication: " Tous les billets ne sont pas remboursables, mais dans ce sens, nous y retournons selon 259-FZ, retour - dans ces conditions . "
Nous devons montrer au passager les conditions de remboursement du billet (remboursable, non remboursable, remboursement à 100% ou non, lorsqu'il est possible de rembourser), utiliser ces paramètres pour rechercher, comparer et, en fait, automatiser les remboursements.
Eh bien, j'avais besoin de comprendre comment transformer plusieurs milliers de textes en russe en paramètres de ticket, où les stocker et comment tout gérer.
À quoi ressemblent les réponses des sources de données?
Voici quelques exemples:
La première chose qui me vient à l'esprit est l'analyse de la PNL. Pour apprendre à un moteur de réseau neuronal PNL à analyser tout cela, vous avez besoin d'un ensemble de règles qui formeront un corpus d'entraînement. Pour obtenir un ensemble de règles, vous devez tout analyser manuellement et le réduire à certains ensembles de règles dans un format unique.
La solution s'est avérée être aussi simple qu'un journal. Presque toutes les règles de retour n'ont pas changé depuis des années et seules quelques nouvelles lignes arrivent en un mois. Nous avons un service de contenu qui recueille des données à partir de diverses sources - par exemple, appelle les gares routières, collecte des données sur les arrêts, etc. Une partie est automatisée, d'autres non. Ce qui est automatisé est couvert par le script et les tests et va à la production. Ce qui est fait manuellement peut être simplifié par le fait que des données déjà préparées arriveront au contenu, c'est-à-dire que nous appellerons l'opérateur humain via une API contenant un formulaire de demande typique.
Analyser tout manuellement une fois et maintenir les modifications manuellement s'est avéré moins coûteux que de visser et de maintenir l'automatisation, puis de surveiller son exactitude. En conséquence, nous avons utilisé des réseaux de neurones complexes - directement le cerveau des opérateurs. Et ils ont montré des performances très élevées.
Ensuite, nous avons ajouté une règle de hachage selon MD5 après avoir effacé les espaces non fonctionnels et converti en un seul cas - pour comprendre qu'il a changé. S'il a changé, l'automatisation définit une tâche pour le service de contenu et le service de contenu entre une nouvelle règle dans notre système.
Encore une fois, il est correct d'utiliser la décision de classe BRMS pour stocker de nombreuses règles. Mais tout s'est avéré plus simple pour nous, l'ensemble des règles a été réduit à de telles matrices:
Dans cette itération, nous avons décidé de marquer sur les modificateurs. Premièrement, ce qu'ils sont n'est pas clair. Deuxièmement, ils semblent être utilisés dans peu d'endroits. Au moins jusqu'à présent, ils n'en ont pas été particulièrement nécessaires.
Il se transforme en un tel texte d'un format unifié:
Par conséquent, nous les stockons directement dans notre système qui gère les paramètres des tickets. C'est-à-dire, en fait, nous ajoutons simplement à la base de données dans chaque ticket un lien vers les règles pour son retour de cette société.
C'est ainsi que ça a commencé à ressembler: les
GDS sont des sources, puis il y a un "effondrement" des vols (le même vol peut provenir de différentes sources avec quelques changements, il y a plus sur cet enfer ici , par exemple).
C'est ainsi que fonctionne le correcteur de règles. A partir de chaque vol, une règle de retour est obtenue, en fonction de son hachage, notre règle correspondante est recherchée (analysée dans le formulaire dont nous avons besoin), et si tout a fonctionné, elle est appliquée:
Souvent, GDS n'envoie pas de règles de retour pour un certain vol. Dans ce cas, nous pouvons avoir nos propres règles de retour "manuelles". Par exemple, nous pouvons appliquer les standards prescrits dans la loi fédérale. Soit dit en passant, ce qui est intéressant, en théorie, ce devraient être les conditions minimales pour tout le monde, mais dans la pratique, elles sont souvent soit améliorées, soit aggravées par les porteurs.
Les transporteurs peuvent avoir des règles locales, comme je l’ai donné un exemple - «pour tous les vols, c’est comme ça, mais sur les vols Moscou - Saint-Pétersbourg, c’est comme ça». Surtout pour cela, nous avons fait le paramètre "priorité" pour les règles "manuelles". En conséquence, une telle règle de retour «manuelle» se compose de trois parties: les paramètres par lesquels on comprend que cette règle est adaptée (ville de départ / d'arrivée, transporteur, GDS), la priorité et le résultat (en fait, les intervalles mêmes avec rétention pourcentages). Lorsque GDS émet un vol sans règles de remboursement, nous allons à la base avec des règles «manuelles», sélectionnons tout ce qui convient et prenons celui qui a la priorité la plus élevée. De plus, le vol est décoré de ces règles reçues.
Bien sûr, nous ne pouvons pas couvrir quelque chose avec de telles règles «manuelles». Pour cela, nous avons fait un rapport, qui comprend des directions qui ne sont pas couvertes par les règles. Il est démonté manuellement par le personnel du service de contenu.
Comme ça. Comme je l'ai dit, tout est assez simple, mais il y a encore beaucoup de situations de ce genre sur le marché, car le marché des bus ne fait qu'ouvrir des ventes électroniques, et il y a un énorme zoo de solutions auto-écrites, ou il n'y a souvent pas d'automatisation à tout.
Eh bien, nous avons maintenant créé une base unifiée de règles de remboursement de billets pour chaque ligne de bus officielle en Russie que nous connaissons.