Qui busca, troba

Hola,

em passen les setmanes que no me n'adono, però no m'oblido que et vaig prometre informar-te mensualment dels progressos que fem en el nou assistent virtual.

Avui vull explicar-te que hem avançat molt en un component que és essencial per l'èxit d'aquest tipus de tecnologies: un motor de cerca de text.

Què és i per què volem un motor de cerca?

Un model de llenguatge és la tecnologia de IA que hi ha darrere de l'assistent virtual, i ha estat entrenat amb moltíssima informació.

Malgrat això, no ho sap tot, i encara menys de tot el que cal saber per respondre preguntes sobre Tryton o com interactuar-hi.

Això sí, sol ser capaç de demanar informació quan la necessita.

Per tal que ho pugui fer, li facilitem unes eines (tools) i li expliquem quan les pot utilitzar.

Una de les que hem creat s'anomena help i la pot fer servir per buscar entre els tutorials de Tryton que hem creat... Com aquell qui busca a Google, però entre la nostra pròpia documentació.

Aquest tipus de cerques de text són essencials perquè l'assistent sàpiga què fer o què respondre quan els usuaris li fan una petició.

Si un usuari diu: "Hola! Com puc crear una factura?" ell farà ús d'aquesta cerca, probablement buscant "crear una factura", la nostra eina li retornà els tutorials que parlen d'aquests temes i ell podrà respondre a l'usuari a partir del que "llegeix" en aquests tutorials.

És fàcil entendre que és essencial que aquesta eina de cerca retorni els tutorials adequats i si no ho fa, per molt intel·ligent que sigui la IA, mai podrà donar la resposta adequada.

ERP i text

No sé si t'has fixat mai que en un ERP hi ha relativament poc text en comparació amb la informació que gestiona una persona en la vida en general i també l'entorn de treball.

No sol haver-hi textos llargs: noms d'empreses, de persones, noms de productes...

Alguna descripció... però poc més.

Però des de NaN-tic estem convençuts que això canviarà i la cerca sobre els tutorials és només el primer dels usos que donarem al motor de cerca de text que hem creat.

Motors de cerca i bases de dades vectorials

L'auge actual dels models de llenguatge ha fet aparèixer un nou concepte que són les bases de dades vectorials.

M'haig d'allargar una mica però agafa't que això és súperinteressant!

Un motor de cerca, fa essencialment tres coses:

• busca el text que ha donat l'usuari sobre un conjunt de documents
• retorna els documents que contenen el que busca l'usuari en forma de rànquing (l'ordre és essencial)
• mostra el fragment de text que conté les paraules clau i normalment les ressalta en negreta

Per fer això bé, es fan servir moltíssims trucs. Te'n comento només 3:

• stemming, que és el procés d'obtenir les arrels de les paraules i treballar només sobre aquestes. Així si l'usuari busca "comptabilització" el sistema trobarà també el document on hi ha escrit "comptabilitzar".
• weighting, que és la manera en com donem més pes al títol del document, que no pas a un paràgraf: si un document porta la paraula "comptabilitzar" al títol apareixerà abans en el rànquing que una que la té al mig d'un paràgraf.
• Tenir en compte la freqüència d'aparició de la paraula. Les paraules que menys apareixen en el conjunt dels documents són les més rellevants a l'hora d'establir l'ordre. En aquest sentit, l'algorisme BM25 creat els anys 70 és encara avui el rei de la cerca.

Però els motors de cerca tenen un problema greu: no entenen res de res.

Suposem que només tenim tres documents: un que parla de futbol, un de tennis i un de bàsquet. Cap d'ells menciona a cap jugador. Llavors, si anem al motor de cerca i busquem "Leo Messi", no ens retornarà cap resultat.

En canvi, si a tu et demano que em diguis quin dels tres documents em donaries tens clar que em donaries el que parla de futbol.

Aquí és on entren les bases de dades vectorials, els embeddings i on la màgia de la Intel·ligència Artificial fa explotar el cap.

Resulta que existeixen molts models d'embeddings, que són bàsicament una caixa negra on li passes un text i et retorna una llista de números: unes coordenades (o vector).

Pots imaginar-ho com un punt en un espai de dues dimensions X i Y. L'únic que has de tenir en compte és que els embeddings tenen moltíssimes dimensions: normalment diversos centenars o uns pocs milers.

I què dimonis representen aquestes coordenades?

Doncs resulta que tenen una propietat: si calcules la distància entre les coordenades de "Leo Messi" i "futbol" és més petita que la distància entre "Leo Messi" i "tennis". Si calcules la distància entre "Leo Messi" i "NaN-tic" és més gran que entre "Leo Messi" i "Barcelona".

És una meravella: resulta que aquesta caixa negra, que ha estat creada a partir d'un sistema d'aprenentatge automàtic ha sigut capaç d'entendre el món. Almenys una mica.

S'han desenvolupat aplicacions molt interessants amb aquests embeddings. Per exemple, s'han fet sistemes de traducció raonablement bons entre idiomes sense utilitzar cap base de dades de traducció entre ells. Simplement creant el model d'embeddings d'un idioma i de l'altre per separat (a partir de milions de documents de cadascun): les coordenades que ocupen les paraules que tenen el mateix significat en els dos idiomes és molt semblant fins al punt que es poden utilitzar per fer traduccions de documents!

Però tornant al que ens ocupa, la gràcia d'aquests embeddings, és que ens permeten calcular distàncies entre dos textos qualssevol i podem saber si tenen un significat proper o no i sobretot, sobretot, és molt ràpid buscar-ho en una base de dades gran perquè només hem de calcular distàncies entre números.

Al mateix temps, aquestes bases de vectors no les podem utilitzar per reemplaçar els buscadors tradicionals. Tenen els seus reptes. Per exemple, què hem de fer, calcular les coordenades (l'embedding) per tot el document? Per cada paràgraf? Per cada frase? Per cada paraula? Com ponderem la combinació de tot plegat?

Així doncs, un sistema de cerca modern ha de combinar els dos sistemes: un motor de cerca tradicional i una base de dades de vectors.

Com NO ho fem doncs?

Dotar-nos d'un bon buscador per Tryton és fàcil i complicat alhora.

És fàcil perquè ja existeixen força solucions al mercat però és complicat perquè cal triar la més adequada.

Per prendre una bona decisió no n'hi ha prou en saber què fan les diferents alternatives que hi ha disponibles sinó que cal entendre:

• Com funcionen? essencialment el que t'he explicat en l'apartat anterior.
• Quina trajectòria té el producte a nivell de fiabilitat, volum de gent utilitzant-lo realment?
• Què implicarà desplegar-ho i posar-ho a disposició de tots els nostres clients?
• Quines conseqüències pot tenir el manteniment a llarg termini?
• Quin és el valor real que aporta al nostre cas concret cadascuna d'elles?
• Fins a quin punt és preferible construir la nostra propia solució?

Així ens hem plantejat diferents solucions que hem descartat:

• Elasticsearch (i solucions semblants com Solr): tot i que seria l'opció més fàcil d'agafar per molts dels aspectes anteriors (té suport per cerca de text i vectorial, té una llarga trajectòria i és àmpliament utilitzada), també suposa complicacions a nivell d'infraestructura (caldria fer una instal·lació per cada base de dades Tryton, complicant a més, els entorns de proves que ara podem fer amb moltíssima facilitat), també generaria nous punts d'error potencial (degut a que pot no estar en funcionament quan el necessitem) i a nivell de sincronització de dades (la informació quedaria fora de la base de dades Tryton).

• Whoosh: aquesta és una solució 100% python que utilitzem amb èxit en pàgines web de clients. Tot i que funciona correctament per la cerca de text no incorpora la part vectorial. Podríem integrar-la nosaltres però els principals motius per descartar-la han estat que fa gairebé 8 anys que no rep manteniment (tot i que funciona perfectament) i que les dades també queden fora de Tryton. Tot i que té alguns avantatges respecte Elasticsearch en aquest sentit, clarament no és un escenari ideal.

• Bases de dades vectorials: les hem descartat essencialment per motius semblants a Elasticsearch i per problemes addicionals com la joventut de les eines i que solen estar pensades per volums enormes de dades. Sovint són creades per startups que busquen poder atreure grans empreses, que és on troben el negoci. No s'alineen les nostres necessitats amb el seu model de negoci.

• ParadeDB: ha estat una solució que hem provat d'utilitzar però l'hem acabat descartant. Té l'avantatge d'estar integrada a PostgreSQL (el motor de base de dades que ja utilitzem amb Tryton) i també té l'avantatge d'implementar BM25, a priori el millor algorisme de cerca de text. Però té dos grans desavantatges: és molt nou (immadur) i és lent. I és que l'algorisme BM25 té algunes particularitats tècniques que potser no el fan ideal pel nostre escenari.

Com ho hem fet doncs?

Hem optat per crear un petit mòdul Tryton que combina dues tecnologies força madures i que utilitzen el mateix PostgreSQL per emmagatzemar la informació.

Per la cerca de text utilitzem les possibilitats de Full Text Search que ja incorpora Postgres. Tot i que no és l'estat de l'art en cerca de text, creiem que és suficient i els avantatges superen els desavantatges.

Per la cerca vectorial utilitzem l'extensió de Postgres pg_vector que ens ha funcionat perfectament bé, aviat farà 4 anys que va néixer, va rebent actualitzacions de millores i correccions amb freqüència, i sembla que ha tingut bona acollida entre els usuaris.

El mòdul que hem creat són menys de 400 línies de codi i ens permet tenir quelcom que entenem en profunditat, pràcticament no hem de fer res a nivell d'infraestructura pels entorns de producció ni de proves, també és 100% compatible amb les instal·lacions que tenim de còpia de seguretat i replicació en temps real.

A més, eliminem molts problemes d'inconsistència d'informació que podríem tenir amb altres solucions i sobretot és extremadament senzill: indexar una nova taula de l'ERP poden ser menys de 10 línies de codi.

A partir d'ara

Des d'aquesta setmana els assistents de tots els clients que ja treballen amb la versió 7.2 (la majoria) estaran utilitzant aquest sistema per trobar l'ajuda i altres funcions i ja es pot notar en la millora en la interacció amb el sistema.

També estem començant a utilitzar el buscador per noves funcionalitats, però això ja serà material per un altre correu...

Salut i bona setmana!