RAG (Retrieval-Augmented Generation)

Embeddings i similitud del cosinus

En un RAG, cada fragment de document es converteix en un embedding, i la pregunta de l'usuari també. La similitud del cosinus mesura l'angle entre dos vectors: com més a prop d'1, més s'assemblen els significats. Així es troben els fragments més rellevants per a una pregunta, encara que no comparteixin paraules.

El valor absolut de la similitud enganya: depèn del model, de l'idioma i de com s'han redactat els textos. El que és útil és comparar la distància entre els resultats bons i els dolents per a preguntes reals. Per això els llindars de similitud s'han de calibrar amb dades, no fixar a ull.

Bases de dades vectorials

Una base de dades vectorial emmagatzema embeddings i permet trobar ràpidament els més propers a un vector donat, fins i tot entre milions de registres, gràcies a índexs aproximats (ANN). Alguns exemples són pgvector (una extensió de PostgreSQL), Qdrant, Pinecone, Weaviate o Chroma.

No sempre en cal una de dedicada. Amb uns quants milers de fragments, calcular la similitud contra tots (una cerca exhaustiva) és prou ràpid i estalvia infraestructura. La base vectorial comença a compensar quan el volum creix o quan necessites filtres i latències baixes a escala.

Chunking

El chunking és trossejar els documents en fragments (chunks) abans de generar-ne els embeddings. Un document sencer barreja massa temes en un sol vector, i un fragment massa petit perd el context. La mida típica va d'uns centenars a un parell de milers de caràcters, amb un cert solapament entre fragments consecutius perquè cap idea quedi tallada per la meitat.

La millor estratègia depèn del contingut: per paràgrafs o seccions en la documentació, i per registre en les dades estructurades (un tiquet, una comanda). Quan indexes registres, convé convertir-los en fitxes llegibles («Comanda 1042 de la Maria, enviada el 3 de març, pendent de devolució») en lloc de bolcar-ne les columnes: l'embedding captura significat, no estructura.

Cerca híbrida

La cerca híbrida combina la cerca semàntica (per embeddings) amb la cerca tradicional per paraules clau (com BM25). Cadascuna cobreix els punts febles de l'altra: la semàntica entén sinònims i paràfrasis, però falla amb codis, referències i noms propis exactes; la lèxica funciona just al revés.

En una aplicació d'atenció al client, «no m'ha arribat el paquet» es resol bé pel significat, però «comanda 1042» o un codi d'error concret necessiten una coincidència exacta. Els resultats de les dues cerques es fusionen, per exemple amb Reciprocal Rank Fusion, que combina les posicions de cada llista.

Reranking

El reranking és un segon pas que reordena els candidats recuperats amb un model més precís (sovint un cross-encoder), que avalua cada parella pregunta-fragment en conjunt en lloc de comparar vectors precalculats.

El patró típic és recuperar molts candidats de manera barata (per exemple, 50) i fer que el reranker triï els millors (per exemple, 5), que són els que entren al context. Millora la precisió, però afegeix latència i cost, i només té sentit quan has comprovat que el problema és l'ordre dels resultats i no que la informació no hi és.

Knowledge graphs

Un knowledge graph representa la informació com a entitats (clients, productes, comandes) i relacions entre elles («el client X ha comprat el producte Y», «el producte Y té la incidència Z»). En el context del RAG (GraphRAG), permet respondre preguntes que requereixen seguir relacions, no només trobar fragments semblants.

És útil quan la pregunta és relacional («quins clients que van comprar aquest producte han obert tiquets aquest mes?»), on la cerca per similitud no arriba. El preu és alt, perquè construir i mantenir el graf és complex. En la majoria de casos, és més assenyat començar amb un RAG vectorial i resoldre les preguntes estructurades amb consultes SQL.