Estamos automatizando ônibus aqui, recentemente, com a nossa ajuda, todos os bilhetes na Rússia tornaram-se eletrônicos . O mercado está apenas entrando de alguma forma na TI, e ainda há muitas coisas sendo feitas nos livros do celeiro.
Vou contar a vocês um simples episódio de automação, que já foi concluído há décadas na aviação e na ferrovia, mas que apenas começou conosco. Então, a situação: há cerca de uma centena de sistemas de informação diferentes que nos enviam dados sobre rotas de ônibus. É uma coleção de automações de autoria própria de diferentes operadoras e produtos comerciais concorrentes. Cada sistema possui um formato próprio para registrar como é feita a devolução da passagem de ônibus. Na maioria das vezes - um registro legível em russo, escrito para operadores e caixas, mas cerca de 20% dos sistemas não enviam dados de retorno.
Algumas das regras se sobrepõem, e pode haver vários níveis de aninhamento: “ Todos os bilhetes não são reembolsáveis, mas neste sentido regressamos de acordo com a 259-FZ, voltar - nestas condições . ”
Precisamos mostrar ao passageiro as condições de reembolso do bilhete (reembolsável, não reembolsável, reembolso de 100% ou não, quando for possível o reembolso), utilizar esses parâmetros para pesquisar, comparar e, de fato, automatizar os reembolsos.
Bem, eu precisava entender como transformar vários milhares de textos em russo em parâmetros de tíquetes, onde armazená-los e como gerenciar tudo.
Como são as respostas das fontes de dados?
Aqui estão alguns exemplos:
A primeira coisa que vem à mente é a análise de PNL. Para ensinar um motor de rede neural PNL a analisar tudo isso, você precisa de um conjunto de regras que formarão um corpus para treinamento. Para obter um conjunto de regras, você precisa analisar tudo manualmente e reduzi-lo a certos conjuntos de regras em um único formato.
A solução acabou sendo tão simples quanto um registro. Quase todas as regras de devolução não mudam há anos, e apenas algumas novas linhas surgem em um mês. Temos um departamento de conteúdo que coleta dados de várias fontes - por exemplo, liga para estações de ônibus, coleta dados de paradas e assim por diante. Algumas delas são automatizadas, outras não. O que está sendo automatizado é coberto pelo script e pelos testes e vai para a produção. O que é feito manualmente pode ser simplificado pelo fato de que os dados já preparados virão para o conteúdo, ou seja, chamaremos o operador humano por meio de alguma API contendo um formulário de solicitação típico.
Analisar tudo manualmente uma vez e manter as alterações manualmente acabou sendo mais barato do que aparafusar e manter a automação e, em seguida, monitorar sua correção. Como resultado, usamos redes neurais complexas - diretamente o cérebro dos operadores. E eles mostraram um desempenho muito alto.
Em seguida, adicionamos uma regra de hashing de acordo com MD5 após limpar os espaços não funcionais e converter para um caso - para entender que ele mudou. Se mudou, a automação define uma tarefa para o departamento de conteúdo, e o departamento de conteúdo insere uma nova regra em nosso sistema.
Novamente, é correto usar a decisão da classe BRMS para armazenar muitas regras. Mas tudo acabou sendo mais simples para nós, todo o conjunto de regras foi reduzido a tais matrizes:
Nesta iteração, decidimos pontuar nos modificadores. Em primeiro lugar, não está claro o que são. Em segundo lugar, eles parecem ser usados em poucos lugares. Pelo menos até agora, não houve nenhuma necessidade especial para eles.
Torna-se um texto de formato unificado:
Portanto, nós os armazenamos diretamente em nosso sistema que gerencia os parâmetros dos tickets. Ou seja, simplesmente adicionamos à base de dados em cada ticket um link com as regras para a sua devolução desta empresa.
É assim que começou a parecer:
GDS são fontes, aí ocorre um “colapso” de voos (o mesmo voo pode vir de fontes diferentes com algumas alterações, tem mais sobre esse inferno aqui , por exemplo).
É assim que o combinador de regras funciona. De cada vôo, uma regra de retorno é obtida, de acordo com seu hash, nossa regra correspondente é pesquisada (analisada na forma que precisamos), e se tudo deu certo, ela é aplicada:
Freqüentemente o GDS não envia regras de retorno para um determinado voar. Nesse caso, podemos ter nossas próprias regras de devolução "manuais". Por exemplo, podemos aplicar os padrões prescritos na lei federal. Aliás, o que é interessante, em tese, deveriam ser as condições mínimas para todos, mas na prática muitas vezes são melhoradas ou pioradas pelas operadoras.
As transportadoras podem ter regras locais, como dei um exemplo - “para todos os voos é assim, mas nos voos Moscou - São Petersburgo é assim”. Especialmente para isso, definimos o parâmetro "prioridade" para as regras "manuais". Como resultado, tal regra de retorno “manual” consiste em três partes: parâmetros pelos quais entendemos que esta regra é adequada (cidade de partida / chegada, transportadora, GDS), prioridade e resultado (na verdade, os próprios intervalos com retenção percentagens). Quando a GDS emite um vôo sem regras de reembolso, vamos para a base com regras “manuais”, selecionamos todas as que são adequadas e pegamos aquele com a maior prioridade. Além disso, o vôo é decorado com essas regras recebidas.
Claro, não podemos cobrir algo com essas regras "manuais". Para isso, fizemos um relatório, que inclui orientações que não estão contempladas nas regras. Ele é desmontado manualmente pela equipe do departamento de conteúdo.
Como isso. Como eu disse, tudo é muito simples, mas ainda existem muitas situações semelhantes no mercado, porque o mercado de ônibus está apenas abrindo vendas eletrônicas e há um enorme zoológico de soluções auto-escritas, ou muitas vezes não há automação no tudo.
Bem, agora criamos uma base unificada de regras de reembolso de passagens para cada rota oficial de ônibus na Rússia que conhecemos.