Palabras clave: araña, robot de búsqueda, búsqueda i recuperación de información, bot, buscador, inteligencia artificial, IA, search bot, search robot, robot, crawler, web crawler, information retrieval, information search and retrieval, artificial intelligence, AI
En este artículo, dividido en 4 partes, explicamos cómo implementar un Information Retriever. Es decir, un sistema software capaz de conseguir información de interés de forma automática/desasistida/inteligente a partir de información que se está actualizando constantemente en internet.
En la primera parte hemos planteado el escenario.
En la segunda parte hemos descrito su arquitectura.
En esta tercera parte describiremos con más detalle cada uno de los componentes y daremos pautas para implementarlos.
Crawlers/bots/arañas
Son las arañas del diagrama. Se ejecutan periódicamente y descargan todas las páginas incumbientes que no tengan ya descargadas. Incumbientes: susceptibles de contener información de interés.
Pautas de implementación
-
- Acatar robots.txt (ver glosario)
- No crawlear siempre a la misma hora todos para no saturar, sino hacerlo cada cierto número primo de minutos, por ejemplo (respetando robots.txt).
- Hacer que sean fácilmente invocables para poder hacer que se ejecuten solos cómodamente (relacionado con punto anterior).
- Evitar en la medida de lo posible descargar lo mismo dos veces. Para ello, comprobar primero si ya estaba descargado antes de descargar. Por ejemplo, viendo si un artículo publicado ya estaba guardado en la BD con el mismo código de publicación.
- Ser robusto a fallos. Si el sitio web de donde queremos descargar cambia y/o deja de poderse descargar, hacer que sea de fácil detección para que el programador pueda actualizar el código o cambiar la programación.
- Generar logs escuetos, pero no demasiado, que sirvan para poder saber qué problema ha habido en caso necesario (en relación al punto anterior).
- Paralelizar en la medida de lo posible (siempre sin saturar a la fuente). Pueden haber varias instancias del mismo crawler descargando varias cosas en momentos diferentes.
- Pensarlos de tal manera que sea fácilmente diferenciable en el código fuente la parte de llegar a las url finales (recorrer las "ramas") de la parte que se descarga finalmente la información de esas urls (los "frutos", las "hojas".
- Si hacemos varios crawlers para diferentes tipos de páginas, no repetir código para cosas comunes, sino aprovechar las mismas librerías entre ellos.
Almacenes/repositorios
Son donde se guarda el contenido "crudo" descargado por los crawlers para su posterior tratamiento.
Pautas de implementación
-
- Deben ser escalables. Es decir, a medida que es necesario acumular más información, es un espacio que debe poderse ampliar fácilmente.
- No hace falta guardar toda la historia, pero sí es interesante guardar toda la historia reciente. Es decir, toda aquella que pueda aún contener información que pueda afectar y los parsers no hayan sabido extraer. Así, se pueden mejorar los parsers y comprobar que con la nueva versión sí la habrían extraido.
- En relación con el punto anterior: es necesario un mecanismo automático de archivo y/o olvido, para archivar (comprimir y poner aparte) o borrar todo el contenido descargado que ya no pueda afectar.
Parsers
Cuando aparece contenido nuevo en el almacén lo procesan y extraen la información de interés, guardándola en la BD de forma estructurada y relacionada (o dándosela a un broker para que la guarde en la BD)
Pautas de implementación
-
- Un parser no puede fallar. Es como un compilador o un navegador.
- Igual que lo que hacen los compiladores, es conveniente trabajar con máquinas de estados en vez de anidar if's.
- Para que un parser encuentre las cosas, hay que explicar cómo las encuentra una persona. Una vez explicado, programar eso (ver IA en el glosario).
- Lo primero es recoger ejemplos variados, y hacer "factor común" de ellos. Es decir: qué es lo que hace que en todos ellos, a pesar de ser variados, siempre sepas encontrar por ejemplo el importe? Si hay demasiada variabilidad, y al explicarlo entramos a hacer casos, es mejor hacer varios parsers que sobrecargar demasiado uno. Habrá que programar entonces un discriminador que derive al parser adecuado. Para programarlo, lo mismo que en los parsers, es explicar cómo una persona lo discrimina y luego programar eso.
- El código debe ser muy fácil de leer y de modificar. Así pues, debe tener altísima calidad. Así será posible reaprovechar en otros parsers ya no el código a ciegas, sino la estrategia, y hacer variaciones.
- Hay que elegir un lenguaje que trabaje bien con strings, por ejemplo PHP o Python.
- Al igual que en los crawlers, no repetir código entre parsers, sino que compartan librerías comunes para cosas comunes.
BD
La Base de Datos guarda la información obtenida por los parsers de forma estructurada. Por ejemplo (pensando en los 3 ejemplos del contexto), a cada DNI o NIF le vincula tantos avisos como vaya detectando, indexados por fecha, por tipo, etc. De esta manera la BD es lo que se consultará para sacar partido de esa información, y no el contenido del almacén. Es casi seguro que esa BD ya existe. Así pues quizá no tenemos que crearla ni siquiera ampliarla, sino simplemente entenderla y usarla.
Pautas de implementación
-
- La BD debe ser consistente y velar para que no haya la misma información varias veces. Así los parsers se despreocupan de pensar si eso "ya se sabía" o no, y simplemente informan.
- Debe ser escalable, permitiendo crecer indefinidamente sin ir cada vez más lenta.
- Al igual que los almacenes/repositorios, debe tener mecanismo de olvido, para no guardar información innecesaria más tiempo del necesario.
Brokers
En ingeniería del software llamamos brokers a aquellos componentes que hacen de intermediarios (representantes, brokers) con otros componentes. Están atentos a cambios en unos que puedan afectar a otros. Por ejemplo (caso autoescuela): cada minuto el broker puede consultar en la BD cada uno de los DNI de los alumnos a ver si su nota ha salido publicada ya. Por su parte, los parsers no buscan a ciegas en el contenido descargado por el crawler, sino que buscan solo DNIs de afectados. Los parsers son configurados automáticamente por el broker cada vez que hay un nuevo alumno en la autoescuela, para que tengan en cuenta ese DNI en sus búsquedas. Si encuentra un resultado, el broker se ocupará de invocar al CRM de la autoescuela para que cambie el estado de ese alumno a aprobado/suspendido. A su vez, el CRM al detectar el cambio de estado enviará un mail al alumno con copia al profesor de la autoescuela. Si el CRM no tiene esa funcionalidad, el broker se lo pedirá a un "enviador de emails" que habrá que implementar también.
Pautas de implementación
-
- No programar cosas que ya estén hechas. Primero documentarse de qué ofrece cada aplicativo, y sólo implementar la parte que falta.
- Ortogonalidad en el formato de los datos intercambiados y en el protocolo: por ejemplo todos los brokers devuelven objetos JSON y se usan mediante API REST.
- Situar cada broker donde convenga más según la arquitectura. Por ejemplo, si hay que leer y escribir de una base de datos que está en un windows, es posible que sea más cómodo desplegar el broker en ese windows en vez de abrir puertos en el windows (cosa que expondría a la BD del windows innecesariamente).
Servicios
Son componentes software disponibles y preparados para ser usados por parte de otros softwares, gracias a una API (ver glosario). Son por ejemplo un enviador de emails, un enviador de SMS, un enviador de whatsapp, un bot de telegram... Pueden formar parte de las funcionalidades de un ERP o CRM, y en ese caso se lo pediremos a ellos (ver ejemplo descrito al definir los brokers).
Pautas de implementación
-
- Cada servicio debe ser desplegado de la manera más independiente y ubicua que sea posible.
- Todos deben reportar al mismo subsistema de logs.
En la cuarta parte de este artículo daremos algunas conclusiones y consejos finales.
Glosario
Aclaramos aquí algunos términos que iremos usando. Más que dar su definición genérica (que el lector podrá encontrar en la wikipedia) nos hemos esforzado por decir a qué nos referimos con ellos en este contexto.
Algoritmo: procedimiento, estrategia.
Almacén de contenido descargado: contenido descargado por los crawlers para su posterior tratamiento.
API (Application Programming Interface): invocaciones que ofrece una aplicación para que otras aplicaciones puedan usar algunas de sus funcionalidades.
BD (Base de Datos): una base de datos es un componente de un sistema de software donde se guarda información de forma estructurada.
Bot: un bot es un robot sin cuerpo. Es decir, sólo el software.
Crawler / Araña: bot (programa) que entra en páginas de internet y descarga su contenido (lo que hace google con todas las páginas).
CRM (Customer Relationship Manager): aplicativo que se ocupa de mantener los clientes de una empresa y su relación con ellos.
ERP (Enterprise Resource Planner): aplicativo que se ocupa de gestionar los procesos de producción de una empresa
GUI (Graphical User Interface): controles que puede usar un usuario para usar funcionalidades de una aplicación.
IA (Inteligencia Artificial): paradigma de programación consistente en pensar un algoritmo de la misma manera que lo haría una persona si fuera una persona la que tuviera que hacer el trabajo.
IR (Information Retriever): software que se ocupa de encontrar información incumbiente automáticamente.
Parser: programa que extrae información de un texto.
Programa: es un algoritmo escrito en un lenguaje que un ordenador entiende y así lo puede ejecutar.
Robot: viene del polaco "esclavo" y es algo artificial construido para hacer lo que le digas emulando a lo que haría un humano.
robots.txt: las webs tienen un fichero en su raíz llamado robots.txt que son indicaciones para que si alguien hace un crawler, las respete. Consisten básicamente en no entrar demasiado seguido y no entrar en según qué rutas.