Administración de bases de conocimiento auxiliadas por IA

En un artículo previo mostraba el uso práctico de un bot conversacional para apoyo operativo en una intranet, ahora vamos a desmitificar un poco sobre la trastienda de estos bot (Azure Cognoscitive Services), llamada la base de conocimiento. En efecto, cualquier bot se nutre de bases de conocimiento como fuente de datos primaria, más allá de las interpretaciones de léxico auxiliadas por inteligencia artificial (IA). De hecho hay dos etapas de intervención de la IA, vamos a detallar este proceso.

El tópico que estoy describiendo específicamente de este producto son los de reconocimiento del lenguaje, obviamente en castellano aunque la mecánica aplica a cualquier otro idioma disponible en la plataforma. El bloque principal y núcleo de la funcionalidad es la base de conocimiento, donde la primera acción a realizar es alimentarlo con nuestros documentos mediante archivos, o preferentemente enlaces URL (esta segunda opción es mejor porque enlazará directamente los enlaces de imágenes al contenido ofrecido, dado que se pierden desde los archivos documentales tipo PDF o Word). Aquí es donde interviene la IA por primera vez, dado que interpretará la documentación clasificándola por ítems de conocimiento, y creará un esquema taxonómico de preguntas y respuestas en forma completamente automática. El hecho de usar IA nos asegura que los resultados no solo serán satisfactorios sino que además mejoraran continuamente dado que el servicio está centralizado y no es particular de nuestra solución. El “Language Studio” permite hacer esta acción, además de presentar luego la serie de preguntas y repuestas que generó el servicio:

Ejemplo de conjuntos de preguntas-respuestas para un bot conversacional

Además de los documentos personalizados, permite agregar un conjunto de ítems de conversación casual (propiamente chat) que le dará una personalidad al bot más allá de materia que tratan los documentos. Por supuesto qué hay variantes de personalidad que le otorgarán un carácter más casual o formal según el elegido, y que más allá de ser un aditamento de prueba es conveniente adoptar por razones más psicológicas. El que un bot pueda tener un sencillo diálogo casual ayudará a la adopción por parte de los usuarios, que más allá de obtener las frías respuestas generaran una empatía natural para promover el uso de este tipo de elemento auxiliar de la organización. Estos diálogos también son evitables y se podrán adaptar mejor a las necesidades de la organización de estimarse conveniente.

Es que la base de conocimiento recién creada es completamente editable, la imagen muestra al administrador de los conjuntos pregunta-respuesta, que más allá de tratarlo como par tiene la opción de sumarle el conjunto de preguntas equivalentes que mejoraran la precisión de la respuestas del bot, y hasta ofrece la posibilidad de desambiguar la pregunta con una elección múltiple de respuestas (un ejemplo de ello se ve en la imagen). Aquí entra en juego la segunda fase de la IA al no necesitar taxativamente cada tipo de pregunta textual posible, sino los esquemas genéricos que mejor la representen, dado que el sistema de scoring o puntuación con el que trabaja puntuará el tipo de respuesta como la más factible según la distancia relativa entre los sintagmas de preguntas ingresados y disponibles de cada respuesta. Ahí reside la gran potencia del producto, y lo que la diferencia enormemente de versiones previas, el análisis de lenguaje que permite realizar esta puntuación con mucha más cercanía al significado que a la forma.

Otro elemento que ayuda notablemente es la definición de sinónimos, referida a la asociación de varios términos que representan el mismo objeto de la vida real. Obviamente no estamos hablando de los sinónimos lingüísticos, que la IA los maneja notablemente bien, sino a aquellos que son particulares dentro de la organización y que nos interesa se interpreten de un mismo modo, más allá que por fuera del ámbito de trabajo no tengan ese sentido específico. Eso permite integrar términos de la jerga laboral y ayudar al servicio a orientarlo al elemento gramático existente que deseamos asociarlo. Por ejemplo, si dentro del ámbito laboral un datawarehouse se puede conocer por su abreviatura como DW o acompañado de su versión como DW3, se pueden establecer como sinónimos ayudando al bot a interpretar el objeto concreto al que se hacer referencia.

Todos estos puntos nos llevan a justificar un punto clave que mencioné en el artículo previo, y es la necesidad de tener roles de documentadores específicos. Como toda solución nueva en su tipo, siempre se genera una nueva necesidad que se puede cubrir a veces con recursos existentes, aunque otras veces y como en este caso implica general un nuevo tipo de rol. Concretamente un área de administración documental será necesaria tanto como se quiera potenciar el uso de las bases de conocimiento. El reunir la información documental, darle la forma necesaria para mejor interpretación de la IA, administrar la taxonomía y actualización del material, y por último configurar los sinónimos y preguntas equivalentes son tareas ciertamente no menores que necesitan de personal a mi criterio especializado, pudiendo ser bibliotecarios por dar un ejemplo. Esto se potencia aún más dado que la IA detecta las nuevas preguntas de los mismos usuarios y ofrece la posibilidad de incorporarlas por los administradores asociándola a la o las respuestas que mejor acomoden, cerrando un ciclo de vida de mejora continua con la gestión documental sobre la base de conocimiento. Como siempre, la Inteligencia de Negocios es una materia de continuo crecimiento y cada vez más multidisciplinaria.

Por supuesto que todo esto dependerá de qué tan lejos se desee llegar en este tipo de proyectos, y el balance de costo-beneficio, que en muchos casos resultará positivo porque todo esto redunda finalmente en fomentar el autoaprendizaje, evitando posiblemente muchas horas redundantes de capacitaciones extra al contar con material de consulta permanente y dirigido a dudas concretas.

Uso de Chat-Bots privados como guías en la Intranet

Desde hace unos meses cobró un impulso inusitado el uso de chat bots públicos, y sus intenciones ambiciosas de intentar ser un reemplazo de los motores de búsqueda y enciclopedias en línea. Sin embargo los bots conversacionales son un recurso que tienen varios años de trayectoria y que podemos experimentar en web públicas, como por ejemplo para sacar turnos en línea de atención médica. Pero además creando los propios especializados y bien empleados podemos encontrarle útiles usos internos en las organizaciones. La pregunta que vamos a responder en este artículo es: ¿qué tan inaccesible es lograr hoy esto?

Para comenzar les muestro un video muy corto, menos de 2 minutos, de una prueba piloto que llevé adelante. Estamos en una página de la Intranet corporativa donde generamos un inventario de tablas del data warehouse, para auxiliar en la búsqueda de información dentro de los modelos dimensionales. Un artículo anterior habla más en detalle de esto. A pesar de que la página es funcional a la localización de la información pertinente a las tablas de hechos y dimensiones, el hecho de que la acceden personal no familiarizado específicamente con este tipo de modelos hace que falte algo de información de contexto, y ahí es donde el bot es de gran ayuda:

Prueba piloto de chat-bots privados

Trabajando en la modalidad de que el Data warehouse sea internamente accesible a áreas que generan su propia reportabilidad, no siempre se cuenta con personal especializado en modelos de datos, y aunque se hagan las capacitaciones, los conceptos tienden a olvidarse con el paso del tiempo. Aunque siempre se puede volver sobre la documentación de la capacitación interna, la rutina diaria hace que muchas veces se necesiten repasos de los temas, y que sean fácilmente recuperados sin necesidad de hacer búsquedas exhaustivas o usando buscadores de texto que no siempre interpretan el punto solicitado. Aquí es donde un chat bot maneja el contexto desde donde se hace la consulta, y accede a una base de conocimiento especializada en los temas sobre los que trata la página actual. En efecto, los chat insertados pueden alimentarse de diferentes bases de conocimiento según la página en navegación actual. La rapidez de encontrar información de esta manera asegura de por sí un aumento de productividad, y lo que es mejor aún, despejando el camino para que los colaboradores internos logren hacer sus tareas sin frustrarse en el intento por falta de asistencia directa. Estos son puntos muy importantes a la hora de evaluar una inversión de tiempos y recursos en poblar estas bases de conocimiento.

Ahora viene la parte más interesante, con la Inteligencia Artificial (AI) de los Servicios Cognoscitivos, combinados con el Language Studio, ambos de Azure, permiten mantener las bases de conocimiento necesarias, ciclo de vida incluido; y publicarlas desde un Servicio de Bot que las presente. Todo ello basado en microservicios con poco esfuerzo de infraestructura, lo que permite poner mejor el foco en la administración del conocimiento. El proceso de alimentación es muy simple, se cargan los archivos y páginas web como fuentes de información, y la AI se encarga de interpretar y crear todo el conjunto de preguntas y respuestas, usando uno de los servicios dedicado especialmente a este fin. El proceso total no tiene mayores complicaciones y está muy bien documentado.

Si bien para la versión del video se usaron las versiones gratuitas de todos los servicios asociados, los costos reales de los servicios de pago no son elevados, y las versiones más económica son por demás generosas para un uso interno. El punto a evaluar entonces es lo que implica auxiliarse de estos recursos.

Lo primero a considerar es que debemos disponer de una base de conocimiento de la organización, es decir una serie de documentos que expliquen la naturaleza de los procesos sobre los que deseamos que el bot ayude. El grado de madurez de la organización juega un rol importantísimo en esta instancia, dado que no disponer de documentación interna puede echar por tierra el proyecto desde un comienzo. En el caso que se cuente o se decida confeccionar documentación interna, el punto siguiente es tener personal dedicado a ordenar, y clasificar la información útil. Probablemente deban transcribirse en algunos casos los documentos si es que la AI no llega a interpretarlos correctamente, o si quedaron mal rotuladas las preguntas base corregirlas en el entorno de pruebas del Language Studio, para lo cual evidentemente necesitamos cubrir esas posiciones con documentadores. Como el ciclo de vida realimenta la base de conocimiento con las nuevas preguntas generadas por lo colaboradores, el proyecto no termina con el lanzamiento sino que además se mantiene con cierta frecuencia para mejorar las actividades de relación entre preguntas y respuestas que la misma AI aporta. Puede que todo este tratamiento evolutivo no necesite una ocupación total, pero la misma crecerá en función de la cantidad de bases de conocimiento generadas y la cantidad de información que maneje cada una.

Como comenté al inicio del artículo, el tema de chat bots está muy de moda, y esto genera un incentivo más para que los usuarios hagan uso de los mismos. Basado en mi experiencia anterior con el buscador de metadata SQL, este tipo de iniciativa puede tener en forma análoga un alto impacto positivo, dar confianza a los colaboradores, y finalmente una mejora productiva importante. Además tengamos en cuenta que las nuevas generaciones están muy acostumbradas a tratar con redes sociales, y aprovechar este canal similar como vehículo de transmisión de conocimiento garantiza que las aprovecharan naturalmente, y más confiados que con solo disponer de una interminable biblioteca de documentos electrónicos acumulados.

Como estoy en una etapa experimental de esta funcionalidad, son bienvenidas las opiniones de quienes hayan implementado soluciones de intranet similares.

Suscripción a eventos por Azure Event Grid

Un tema recurrente al diseñar los ETL, pieza fundamental de todo data warehouse, es la programación de lectura de orígenes de datos. Al trabajarlos especialmente desde sistemas transaccionales la frecuencia de lanzamiento no siempre es claramente pautada, generando una incertidumbre que atenta contra la rutina de horas específicas preestablecidas. El camino más fácil, y del que se abusa innecesariamente, es la ejecución iterativa dentro de periodos muy cortos de tiempo, algo que anteriormente comenté que es la salida más nefasta, la que causa más dolores de cabeza y sobrecostos evitables. Evaluemos este tema y una alternativa saludable para tomar de modelo dentro de una arquitectura de micro servicios en la nube.

Antes que nada, voy a fundamentar las principales desventajas de los procesos iterativos, además del evidente del costo extra de tener procesos haciendo comprobaciones o directamente leyendo una y otra vez las mismas fuentes al no poder detectar la llegada de información nueva. Consideremos que el enfoque más moderno de un data warehouse se basa en modelos multidimensionales, cuyas relaciones entre dimensiones y hechos obligan a leer los datos con un cierto orden. Sin hay incertidumbre sobre cuándo aparecen las novedades en los diferentes orígenes la orquestación basada en procesos iterativos se hace directamente inviable. Si a esto agregamos que se da cierto margen entre iteraciones, con un enfoque económico de una o dos veces a la hora, la orquestación de ejecuciones multiplicará la latencia entre las mismas por la cantidad de orígenes diferentes, llegando a tener horas de retraso por suma de tiempos muertos, y probablemente ello atente contra la oportuna disponibilidad de la información final. Finalmente el control de secuencialidad entre los procesos se hace tan engorroso que debilita la solución tanto por errores de detección como por solapamientos indeseados inevitables en este tipo de soluciones.

Ahora veamos una mejor alternativa, quienes programan aplicaciones modernas están familiarizados con el concepto de “eventos” que en un primer momento podría considerarse opuesta a la secuencialidad mencionada, sin embargo no son excluyentes. La idea es lograr la secuencialidad orquestada por eventos, e independizando todo lo posible los acoplamientos para minimizarlos. Cuando trabajamos en la nube de Azure, la herramienta más apropiada para integrar información es el Data Factory, sucesor natural de los servicios de integración de SQL aunque admita un motor de compatibilidad para permitir usarlos en los casos cuya funcionalidad aún no está cubierta por este nuevo producto. Aunque una de las ventajas que le hace ganar puntos es la facilidad de suscribir ejecuciones gatilladas por eventos (trigger).

Una posibilidad que aprovecho con frecuencia es la de detectar cambios en los blob de Azure Storage, principalmente la carga de un archivo que de manera inmediata ejecuta el proceso de integración por la canalización (pipeline). Si logramos que el sistema proveedor de los datos, o persona si es carga manual, deje el archivo a integrar en el storage tenemos resuelto el primer gran paso. Al final de cada bloque de integración se puede verificar en una tabla de SQL, o table storage alternativamente, los pasos que debe seguir ejecutando a continuación si un conjunto de archivos termina de completarse. Con esto se puede tener una orquestación que controle perfectamente el paralelismo.

Un segundo escenario se presenta cuando no tenemos la amable posibilidad de que nos alcancen los archivos en storage y debamos buscarlos. Esto es muy común en el ámbito financiero donde los bancos trabajan antiguos sistemas de mainframe que no acompañan los sistemas más modernos, y a duras penas disponibilizan carpetas FTP. Como en el caso de la integración desde una casilla de correo de un artículo anterior, las aplicaciones lógicas de Azure nos pueden auxiliar con la detección. Un paso detecta la llegada de un archivo nuevo a la carpeta ftp controlada y lanza un evento a la grilla personalizada a la que está suscrita la canalización del DataFactory.

Detección de eventos a través del Azure Event Grid

El método que utiliza es exponer webhooks que enlazan los eventos entre ambos sistemas. La canalización recibe el mensaje a través del callback, donde se le indica los datos de identificación del archivo detectado y su ruta dentro del FTP, para que pueda integrarlo inequívocamente. El éxito de las operaciones se puede monitorear dentro del módulo de administración del Event Grid como se muestra en la imagen anterior, aunque como en muchos otros servicios que utilizo jamás extravió o tuvo excepciones el gatillazo de un evento. En la parte inferior se muestran los distintos webhook que aprovechan los sistemas, algunos desde aplicaciones C# en servidores on-premise, siendo el último el dedicado a la detección de llegadas de archivos por FTP. El mismo evento puede estar asociado a diferentes tipos de archivos, y cada uno de ellos lanzará la respectiva canalización de DataFactory que los integra. Un ejemplo de estas secuencias la vemos en la siguiente imagen, desde el monitor de procesos del DataFactory:

Monitor de ejecución de canalizaciones en DataFactory

Como se puede apreciar en la secuencia, para la gran mayoría el orden diario de las ejecuciones no siempre es el mismo, dado que las integraciones de archivos desde el FTP dependen de la llegada desordenada de archivos a integrar. Para que se lancen las canalizaciones independientes en forma certera, hay un paso previo que es la copia del archivo desde el FTP a una carpeta auxiliar en blob storage, para lograr un mejor rendimiento copiando el archivo íntegramente para posteriormente integrarlo con su canalización dedicada.

Resumiendo, con un esquema de este tipo podemos aprovechar los recursos de microservicios en Azure de la mejor manera posible y para lo que cada uno esta especializado: Logics Apps para detectar colocación de archivos en FTP, Event Grid para transmitir por evento la identificación del archivo, y DataFactory para copiar e integrar los archivos desde Blob Storage a SQL a otros destinos (por ejemplo Azure SQL y/o Table Storage).

Como de costumbre, como puede haber más de un tipo de solución combinando microservicios, pueden dejar sus comentarios describiendo otras arquitecturas que les hayan dado resultado para solucionar casos similares.

Posibilidad de instalar una instancia de Reporting Services (SSRS) en la nube

Para no generar falsas expectativas con el título, debo anticipar que el producto en sí de SQL Reporting Services no admite su instalación cloud, sin embargo hay dos métodos alternativos que pueden prolongar la vida del producto soportado en la nube por varios años más. De hecho, a pesar de todos los rumores y recomendaciones en off de pasar a PowerBI como reemplazo, se siguen versionando junto al motor de base de datos (actualmente la 2022) y no hay planes a la vista de discontinuidad total del producto.

La primera explicación es quedar toda duda de su incompatibilidad con las tecnologías de nube: Reporting Services tiene casi 20 años de antigüedad y se desarrolló en una época en que el XML era un estándar muy aceptado, de hecho se usan rutinas programadas como extensión del lenguaje llamada XMLA, hoy en día considerado de hecho como algo obsoleto para nuevos desarrollos y con cero compatibilidad con los servicios cloud. Además de esto, su sistema de servidor trabaja como servicio local del sistema operativo de windows, interactuando de esa manera entre su portal web y la base de datos dedicada; de esta manera no hay plataforma dentro del ecosistema de micro servicios Azure que permita una arquitectura de ese estilo.

Descartada esta posibilidad, el único remedio que queda es crear una máquina virtual como servidor donde instalarlo, y publicar su portal desde dicho entorno. La máxima flexibilidad que nos da esta situación en la nube es poder asociar un directorio de autenticación Azure AD, y explorar las limitaciones que pueda tener este conjunto. En mi caso, enfrenté el tema con la situación poco feliz de no contar con autenticación Active Directory para los usuarios, sino que el log a los sistemas se hacen con autenticación por servicios de Google. Por favor no me critiquen por eso, no fue una decisión propia la de usar este esquema híbrido y tampoco lo recomiendo especialmente.

Ahora bien, con estos limitantes tenemos por un lado una máquina virtual servidor con autenticación básica por SQL a nivel de datos y cuenta de servicio de sistema operativo local para Reportes, mientras por el otro hay todo un ejercito de usuarios tratando a de acceder con sus cuentas Google. Pero a no desesperar que todavía existe una posibilidad y es la que vengo usando con éxito desde hace dos años: desarrollar un sitio web (intranet) como interfaz (o proxy si le cabe esta definición).

En efecto, se trata de un sitio de servicio o Aplicación Web de Azure, desarrollado para autenticar por Google, con autorización por roles y una series de páginas que muestran embebidos los reportes del SSRS. La tecnología de la intranet es ASPX con .NET 4.8/C#, dado que nos provee de un control nativo de SSRS para poder mostrar estos reportes (tanto en forma de frame como de página completa) ocultando la dirección original del servidor de reportes mejorando la seguridad. El servidor de reportes queda así protegido y pueden cerrarse todos los puertos que no provengan de la red virtual de Azure, siendo accedido solo desde a través de su ip interna en red virtual. En el caso que no pueda conectarse a través de la red interna, igualmente el firewall puede cerrar todos los puertos a orígenes que no sean del servicio de intranet. Esta aplicación web puede probarse sin inconvenientes en su versión de desarrollo que es gratuita, y si no es muy exigente el uso del sitio puede mantenerse definitivamente en ese nivel de servicio lo que abarata el costo del workaround.

Esta arquitectura tiene una serie de configuraciones qué hay que cuidar con sumo detalle para que funcione armoniosamente, pero nada que investigando un poco en la web no se pueda resolver. Tengamos en cuenta que tratamos de forzar un producto a entornos y plataformas en la nube nuevas que ni siquiera se soñaban en su época de desarrollo. Una alternativa a los sitios ASPX que también se están dejando de lado (se incentiva el uso de core 6/7 para servicios de Aplicaciones Web que tienen un mejor manejo de los nuevos modelos de programación basados en Inyección de Dependencias integrados a entornos cloud), es crear sitios web basados en Blazor. Estimo por lo que investigué que la versión que mejor acomoda es la de servidor (Blazor Server), sin embargo no hay controles nativos que permitan integrar Reporting Services en forma más o menos transparente, y usar los iframe francamente son un agujero de seguridad importante. Existen productos de terceros de pago que equivalen al componente de SSRS, pero mientras podamos usar ASPX no debería interesarnos, y hasta quizás haya otras y mejores alternativas para cuando debamos migrar obligatoriamente este esquema de solución a futuro. Ir migrando todo lo permisible a PowerBI es siempre una buena idea, para minimizar el esfuerzo de adaptar aquellos reportes que hoy nos impliquen sacrificar funcionalidades de cara al usuario por no tener equivalentes en PowerBI.

Para tener una idea de como opera el conjunto, podemos echar un vistazo al monitoreo de Application Insights:

Solución de Reporting Services combinado con un portal de autenticación Google.

En la figura, la instancia central representa al sitio web de la Intranet, una Web Application en su modo básico de configuración, que se conecta a un servicio de SQL Azure (en rojo) y usa internamente el servicio de sistema de claves (Key Vault) y Azure Active Directory (ambos en azul) para su funcionamiento. La autenticación por Google, al ser un servicio externo, no queda monitoreada por este esquema. Finalmente en amarillo se muestran dos conexiones al mismo servidor donde se encuentra instalado Reporting Services, una para el portal (protocolo http) y la otra a su servicio web gracias al cual el componente embebido recupera la información a desplegar de los reportes. Este último servicio web accede además al servidor de SQL señalado en rojo, pero que no puede monitorear el servicio de Insights por obvias razones.

Como pueden apreciar la solución se comporta perfectamente y la menor incidencia de errores que apenas se ve como el mínimo punto rojo en la instancia del sitio web, es debida a timeout por tiempos muertos en explorador de las páginas o al exportar grandes archivos a excel o PDF generalmente, lo cual es permisible y no generan reportes de incidencias específicamente por parte de los usuarios. Espero que el ejemplo les ayude a resolver situaciones similares, y con tan buenos resultados como los que obtuve apoyado en este esquema.