Cómo hice un comparador de reglas de reembolso de boletos de autobús llamando a través de API humana





Estamos automatizando los autobuses aquí; recientemente, con nuestra ayuda, todos los billetes en Rusia se han vuelto electrónicos . El mercado está entrando en TI de alguna manera, y todavía se están haciendo muchas cosas en los libros del granero.



Les cuento un simple episodio de automatización, que ya se completó hace décadas en la aviación y en el ferrocarril, pero que acaba de comenzar con nosotros. Entonces, la situación: hay alrededor de un centenar de sistemas de información diferentes que nos envían datos sobre las rutas de los autobuses. Es una colección de automatizaciones escritas por ellos mismos de diferentes proveedores y productos comerciales de la competencia. Cada sistema tiene su propio formato para registrar cómo se realiza la devolución del billete de autobús. La mayoría de las veces, un registro legible por humanos en ruso, escrito para operadores y cajeros, pero alrededor del 20% de los sistemas no envían datos de devolución en absoluto.



Algunas de las reglas se superponen y puede haber varios niveles de anidamiento: " Todos los boletos no son reembolsables, pero en esta dirección regresamos allí de acuerdo con 259-FZ, de regreso, bajo estas condiciones ".



Necesitamos mostrarle al pasajero los términos del reembolso del boleto (reembolsable, no reembolsable, reembolso del 100% o no, cuando sea posible reembolsar), utilizar estos parámetros para buscar, comparar y, de hecho, automatizar reembolsos.



Bueno, necesitaba entender cómo convertir varios miles de mensajes de texto en ruso en parámetros de tickets, dónde almacenarlos y cómo administrarlos.



¿Cómo se ven las respuestas de las fuentes de datos?



Aquí hay algunos ejemplos:













Lo primero que me viene a la mente es el análisis de PNL. Para enseñar a un motor de red neuronal NLP a analizar todo esto, necesita un conjunto de reglas que formarán un corpus para el entrenamiento. Para obtener un conjunto de reglas, debe analizar todo manualmente y reducirlo a ciertos conjuntos de reglas en un solo formato.



La solución resultó ser tan simple como un registro. Casi todas las reglas de devolución no han cambiado durante años, y solo unas pocas líneas nuevas llegan en un mes. Tenemos un departamento de contenido que recopila datos de varias fuentes, por ejemplo, llama a las estaciones de autobuses, recopila datos de las paradas, etc. Algo de esto está automatizado, otros no. Lo que se está automatizando está cubierto por el script y las pruebas y pasa a prod. Lo que se hace manualmente se puede simplificar por el hecho de que al contenido llegarán datos ya preparados, es decir, llamaremos al operador humano a través de alguna API que contiene un formulario de solicitud típico.



Analizar todo manualmente una vez y mantener los cambios manualmente resultó ser más barato que atornillar y mantener la automatización, y luego monitorear su corrección. Como resultado, usamos redes neuronales complejas, directamente el cerebro de los operadores. Y mostraron un rendimiento muy alto.



Luego, agregamos una regla de hash de acuerdo con MD5 después de limpiar los espacios no funcionales y convertirlos a un caso, para comprender que ha cambiado. Si ha cambiado, la automatización establece una tarea para el departamento de contenido y el departamento de contenido ingresa una nueva regla en nuestro sistema.



Nuevamente, es correcto utilizar la decisión de clase BRMS para almacenar muchas reglas. Pero todo resultó ser más simple para nosotros, todo el conjunto de reglas se redujo a tales matrices:







En esta iteración, decidimos puntuar en los modificadores. En primer lugar, no está claro cuáles son. En segundo lugar, parece que se utilizan en pocos lugares. Al menos hasta ahora, no ha habido una necesidad especial de ellos.



Se convierte en tal texto de formato unificado: por lo







tanto, los almacenamos directamente en nuestro sistema que gestiona los parámetros de los tickets. Es decir, de hecho, simplemente agregamos a la base de datos en cada ticket un enlace a las reglas para su devolución de esta empresa.



Así empezó a verse:







GDS son fuentes, luego hay un "colapso" de vuelos (un mismo vuelo puede venir de diferentes fuentes con algunos cambios, hay más sobre este infierno aquí , por ejemplo).



Así es como funciona el comparador de reglas. De cada vuelo, se obtiene una regla de retorno, de acuerdo con su hash, se busca nuestra regla correspondiente (analizada en la forma que necesitamos), y si todo funcionó, se aplica:







A menudo, GDS no envía reglas de retorno para un determinado vuelo. En este caso, podemos tener nuestras propias reglas de devolución "manuales". Por ejemplo, podemos aplicar los estándares prescritos en la ley federal. Por cierto, lo interesante, en teoría, deberían ser las condiciones mínimas para todos, pero en la práctica a menudo los transportistas las mejoran o empeoran.



Los transportistas pueden tener reglas locales, como di un ejemplo: "para todos los vuelos es así, pero en los vuelos Moscú - San Petersburgo es así". Especialmente para esto, hemos creado el parámetro "prioridad" para las reglas "manuales". Como resultado, dicha regla de devolución “manual” consta de tres partes: parámetros por los cuales entendemos que esta regla es adecuada (ciudad de salida / llegada, transportista, GDS), prioridad y resultado (de hecho, los mismos intervalos con retención porcentajes). Cuando GDS emite un vuelo sin reglas de reembolso, vamos a la base con reglas “manuales”, seleccionamos todas las que sean adecuadas y tomamos la de mayor prioridad. Además, el vuelo está decorado con estas reglas recibidas.

Por supuesto, es posible que no cubramos algo con tales reglas "manuales". Para ello, hicimos un informe, que incluye direcciones que no están cubiertas por las reglas. El personal del departamento de contenido lo desmonta manualmente.



Como esto. Como dije, todo es bastante simple, pero todavía hay muchas situaciones de este tipo en el mercado, porque el mercado de autobuses recién está abriendo ventas electrónicas y hay un enorme zoológico de soluciones autoescritas, o a menudo no hay automatización en todas.



Bueno, ahora hemos creado una base unificada de reglas de reembolso de boletos para cada ruta oficial de autobús en Rusia que conocemos.



All Articles