Paraules clau: aranya, robot de cerca, cerca i recuperació d'informació, bot, cercador, intel·ligència artificial, IA, search bot, search robot, robot, crawler, web crawler, information retrieval, information search and retrieval, artificial intelligence, AI
En aquest article, dividit en 4 parts, expliquem com implementar un Information Retriever. És a dir, un sistema software capaç d'aconseguir informació d'interès de forma automàtica/desassistida/intel·ligent a partir d'informació que s'està actualitzant constantment a internet.
A la primera part hem descrit l'escenari.
A la segona part hem exposat la seva arquitectura.
A aquesta tercera part descriurem amb més detall cadascun dels components i en donarem pautes per implementar-los.
Crawlers/bots/aranyes
Són les aranyes del diagrama. S'executen periòdicament i descarreguen totes les pàgines incumbents que no tinguin ja descarregades. Incumbents: susceptibles de contenir informació d'interès.
Pautes d'implementació
-
- Acatar robots.txt (veure glossari).
- No crawlejar sempre a la mateixa hora tots per no saturar, sino fer-ho cada cert nombre primer de minuts, per exemple (respectant robots.txt).
- Fer que siguin fàcilment invocables per poder fer que s'executin sols còmodament (relacionat amb punt anterior).
- Evitar en la mesura que sigui possible descarregar el mateix dos cops. A tal efecte, comprovar primer si ja estava descarregat abans de descarregar. Per exemple, mirant si un article publicat ja estava guardat a BD amb el mateix codi de publicació.
- Ser robust a falles. Si el lloc web d'on volem descarregar canvia i/o deixa de poder-se descarregar, fer que sigui de fàcil detecció per tal que el programador pugui actualitzar el codi o canviar la programació.
- Generar logs concissos, però no massa, que serveixin per poder saber quin problema hi ha hagut en cas necessari (en relació al punt anterior).
- Paralelitzar en la mesura que sigui possible (sempre sense saturar la font). Poden haver diverses instàncies del mateix crawler descarregant múltiples coses en moments diferents.
- Pensar-los de tal manera que sigui fàcilment diferenciable al codi font la part d'arribar a les URL finals (recòrrer les "branques") de la part que es descarrega finalment la informació d'aquestes urls (els "fruits", les "fulles").
- Si fem diversos crawlers per diferents tipus de pàgines, no repetir codi per coses comuns, sino aprofitar les mateixes llibreries entre ells.
Magatzems/repositoris
Són a on es desa el contingut "cru" descarregat pels crawlers pel seu posterior tractament.
Pautes d'implementació
-
- Han de ser escalables. És a dir, a mida que és necessari acumular més informació, és un espai que ha de poder-se ampliar fàcilment.
- No cal guardar tota la història, però sí és interessant guardar tota la història recent. És a dir, tota aquella que pugui encara contenir informació que pugui afectar i els parsers no hagin sabut extreure. Així, es poden millorar els parsers i comprovar que amb la nova versió si l'haurien extret.
- En relació al punt anterior: és necessari un mecanisme automàtic d'arxiu i/o oblit, per tal d'arxivar (comprimir i posar apart) o esborrar tot el contingut descarregat que ja no pugui afectar.
Parsers
Quan apareix contingut nou al magatzem el processen i extreuen la informació d'interès, desant-la a BD de forma estructurada i relacionada (o donant-se-la a un broker per tal que la guardi a BD).
Pautes d'implementació
-
- Un parser no pot fallar. És com un compilador o un navegador.
- Igual que el que fan els compiladors, és convenient treballar amb màquines d'estats en comptes d'aniar if's.
- Per tal que un parser trobi les coses, cal explicar com les troba una persona. Un cop explicat, programar allò (veure IA al glossari).
- En primer lloc cal recollir exemples variats i fer "factor comú" d'ells. És a dir: què és el que fa que a tots ells, malgrat ser variats, sempre sàpigues trobar per exemple l'import? Si hi ha massa variabilitat i quan ho expliquem entrem a fer casos, és millor fer diversos parsers que sobrecarregar massa un. Caldrà programar doncs un discriminador que derivi al parser adequat. Per programar-lo, igual que als parsers, és explicar com una persona ho discrimina i després programar allò.
- El codi ha de ser molt fàcil de llegir i de modificar. Així doncs, ha de tenir altíssima qualitat. Així serà possible reaprofitar a d'altres parsers ja no el codi a cegues, sino estratègies, i fer-ne variacions.
- Cal triar un llenguatge que treballi bé amb strings, com pot ser PHP o Python.
- Igual que als crawlers, no repetir codi entre parsers, sino que comparteixin llibreries comuns per coses comuns.
BD
La Base de Dades guarda la informació obtinguda pels parsers de forma estructurada. Per exemple (pensant en els 3 exemples del context), a cada DNI o NIF li vincula tants avisos com hagi detectat, indexats per data, per tipus, etc. D'aquesta manera és la BD allò que es consultarà per treure'n partit d'aquesta informació i no directament el contingut del magatzem. És quasi segur que aquesta BD ja existeix. Així doncs, potser no hem de crear-li ni tan sols ampliar-la, sino simplement entendre-la i fer-la servir.
Pautes d'implementació
-
- La BD ha de ser consistent i vetllar per tal que no hi hagi la mateixa informació diversos cops. Així els parsers es despreocupen de pensar si això "ja se sabia" o no, i simplement informen.
- Ha de ser escalable, permetent crèixer indefinidament sense anar cada cop més lenta.
- Igual que els magatzems/repositoris, ha de tenir mecanisme d'oblit, i així no guardar informació innecessària més temps del que calgui.
Brokers
A enginyeria del software anomenem brokers a aquells components que fan d'intermediaris (representants, brokers) amb altres components. Estan atents a canvis a uns que puguin afectar a d'altres. Per exemple (cas autoescola): cada minut el broker pot consultar la BD cadascú dels DNI dels alumnes a veure si la seva nota ha sortit ja publicada. Per la seva banda, els parsers no cerquen a cegues al contingut descarregat pel crawler, sino que busquen només DNI's d'afectats. En aquest mateix exemple, els parsers serien configurats automàticament pel broker cada cop que hi hagués un nou alumne a l'autoescola, per tal que tinguin en compte aquest DNI a les seves cerques. Si troba un resultat, el broker s'ocuparà d'invocar al CRM de l'autoescola per tal que canvii l'estat d'aquest alumne a aprovat/suspès. Consegüentment, el CRM quan detecta el canvi d'estat enviarà un mail a l'alumne amb còpia al professor de l'autoescola. Si el CRM no té aquesta funcionalitat, el broker li demanarà a un "enviador d'emails" que caldrà implementar.
Pautes d'implementació
-
- No programar coses que ja estiguin fetes. Primer documentar-se sobre què ofereix cada aplicatiu, i només implementar la part que manca.
- Ortogonalitat en el format de les dades intercanviades i al protocol: per exemple tots els brokers tornen objectes JSON i es fan servir mitjançant API REST.
- Situar cada broker a on convingui més segons l'arquitectura. Per exemple, si cal llegir i escriure d'una base de dades que es a un Windows, és possible que sigui més còmode desplegar el broker a aquell windows en comptes d'obrir ports al windows (cosa que exposaria la BD del windows innecessàriament).
Serveis
Són components software disponibles i preparats per tal que els facin servir d'altres softwares, gràcies a una API (veure glossari). Són per exemple un enviador d'emails, un enviador de SMS, un enviador de whatsapp, un bot de telegram... Poden formar part de les funcionalitats d'un ERP o CRM, i en aquest cas li ho demanarem a ells (veure exemple descrit en definir els brokers).
Pautes d'implementació
-
- Cada serveri ha de ser desplegat de la manera més independent i ubiqua que sigui possible.
- Tots han de reportar al mateix subsistema de logs.
A la quarta part d'aquest article donarem algunes conclusions i consells finals.
Glossari
Aclarim aquí alguns termes que anirem fent servir. Més enllà de donar la seva definició genèrica (que el lector podrà trobar a la wikipedia) ens hem esforçat per dir a què ens referim amb ells en aquest context.
Algorisme/Algoritme: procediment, estratègia.
API (Application Programming Interface): invocacions que ofereix una aplicació per tal que d'altres aplicacions puguin fer servir algunes de les seves funcionalitats.
BD (Base de Dades): una base de dades és un component d'un sistema de software a on es guarda informació de forma estructurada.
Bot: és un robot sense cos. És a dir, només el software.
Crawler / Aranya: bot (programa) que entra a pàgines d'internet i descarrega el seu contingut (allò que fa google amb totes les pàgines)
CRM (Customer Relationship Manager): aplicatiu que s'encarrega de mantenir els clients d'una empresa i la seva relació amb ells.
ERP (Enterprise Resource Planner): aplicatiu que s'ocupa de gestionar els processos de producció d'una empresa.
GUI (Graphical User Interface): controls que pot fer servir un usuari per utilitzar funcionalitats d'una aplicació.
IA (Intel·ligència Artificial): paradigma de programació consistent en pensar un algorisme de la mateixa manera que ho faria una persona si fos una persona qui hagués de fer la feina.
IR (Information Retriever): software que s'encarrega de trobar informació incumbent automàticament.
Magatzem de contingut descarregat: contingut descarregat pels crawlers pel seu posterior tractament.
Parser: programa que extreu informació d'un text.
Programa: és un algoritme escrit en un llenguatge que un ordinador entengui i així el pugui executar.
Robot: provè del polac "esclau" i és quelcom artifical construit per fer el que li diguis emulant el que faria un ésser humà.
robots.txt: els webs tenen un fitxer a la seva arrel que es diu robots.txt que són indicacions perquè si algu fa un crawler, les respecti. Consisteixen bàsicament en no entrar massa sovint i no entrar a segons quines rutes.
Sistema software / Sistema d'informació / Aplicatiu / Aplicació: conjunt de programes i dades que produeixen nova informació a partir d'informació existent.