RAG. Flux de treball

Flux de treball d'un sistema RAG

Introducció

Un sistema RAG (Retrieval-Augmented Generation, Generació per recuperació augmentada) és una arquitectura que combina dues capacitats: la recuperació d'informació i la generació de text mitjançant un model de llenguatge (LLM).

L'objectiu principal d'un RAG és permetre que un model de llenguatge respongui preguntes utilitzant informació procedent d'una col·lecció de documents específica. D'aquesta manera, el model no depèn únicament del coneixement amb què va ser entrenat, sinó que pot consultar informació externa i actualitzada abans de generar una resposta.

A efectes pràctics, un sistema RAG es pot dividir en dues fases principals:

1. **Ingesta i indexació dels documents**, que es realitza abans de fer les consultes.
2. **Consulta i generació de la resposta**, que es realitza cada vegada que un usuari formula una pregunta.

El flux general és:

• • Documents → Split → Embeddings → Base de dades vectorial → Retrieval → Context → LLM → Resposta**

Arquitectura general

Un sistema RAG està format per diversos components que treballen conjuntament.

De manera simplificada:

Documents originals -> Extracció del text -> Split / Chunking -> Embeddings -> Base de dades vectorial/semàntica (Qdrant) -> Pregunta de l'usuari -> Embedding de la pregunta -> Cerca semàntica a Qdrant -> Fragments rellevants -> LLM -> Resposta

És important destacar que Qdrant i el LLM tenen funcions diferents. **Qdrant s'encarrega de trobar informació rellevant**, mentre que **el LLM s'encarrega d'interpretar aquesta informació i generar la resposta**.

Ingesta dels documents

La primera etapa del RAG és la **ingesta**.

La ingesta consisteix a incorporar els documents que volem utilitzar com a font de coneixement del sistema.

Aquests documents poden tenir diferents formats:

• PDF
• Word
• HTML
• TXT
• pàgines web
• documents corporatius
• manuals
• informes
• bases de coneixement
• etc.

Per exemple, en un sistema corporatiu podríem disposar de centenars de manuals, contractes i documents tècnics.

Abans de poder utilitzar aquesta informació en un RAG, cal convertir els documents en informació que el sistema pugui processar.

En el cas dels PDF, una eina com **PyMuPDF** pot ser utilitzada per extreure el text i altres metadades, com ara el número de pàgina.

Per tant:

• • Document PDF → text estructurat**

Durant aquesta fase també és interessant conservar informació associada al document (les *metadades* que haurem de conservar), com ara:

• nom del document
• identificador del document
• número de pàgina
• idioma
• tipus de document
• data
• autor
• secció o capítol

Split o Chunking

Un document complet normalment és massa gran per ser tractat com una única unitat.

Per aquest motiu, el text s'ha de dividir en fragments més petits. Aquesta operació s'anomena **split**, **chunking** o segmentació.

Per exemple, un document de 100 pàgines es podria dividir en centenars o milers de fragments.

Un possible esquema seria:

Document:

→ Chunk 1
→ Chunk 2
→ Chunk 3
→ Chunk 4
→ ...
→ Chunk N

Cada chunk conté una part del contingut original.

Per què cal dividir els documents?

Hi ha diversos motius.

En primer lloc, els models d'embeddings funcionen millor quan reben unitats de text relativament acotades.

En segon lloc, quan l'usuari realitza una pregunta, normalment només necessita una petita part d'un document.

Per exemple, si tenim un manual de 300 pàgines i l'usuari pregunta:

> "Quina és la temperatura màxima de funcionament?"

No té sentit recuperar les 300 pàgines. L'objectiu és localitzar únicament els fragments relacionats amb aquesta qüestió.

Mida dels chunks

La mida dels chunks és un dels paràmetres importants del RAG.

Si els fragments són massa petits, poden perdre context.

Si són massa grans, la cerca pot ser menys precisa i es pot acabar proporcionant massa informació al LLM.

Per això és habitual utilitzar chunks d'una mida determinada i, en alguns casos, una certa **superposició (overlap)** entre fragments consecutius.

Per exemple: <pr>

• • Chunk 1:** informació de les pàgines 1-2
  • Chunk 2:** informació de les pàgines 2-3
  • Chunk 3:** informació de les pàgines 3-4

Aquesta superposició ajuda a evitar que una informació important quedi dividida exactament entre dos fragments.

Embeddings

Una vegada tenim els chunks, cal convertir-los en una representació que permeti comparar-ne el significat.

Per fer-ho s'utilitzen els **models d'embeddings**.

Un embedding és una representació numèrica d'un text en forma de vector.

Conceptualment: **Text → Model d'embeddings → Vector**

Per exemple, una frase com:

> "El contracte entra en vigor el 15 de març."

es transforma en un vector numèric amb moltes dimensions.

No és necessari que aquests números tinguin un significat individual comprensible per a nosaltres. El que interessa és que textos amb significats similars generin vectors que estiguin **propers dins de l'espai vectorial**.

Per exemple:

> "Quan entra en vigor el contracte?"

i

> "El contracte serà efectiu a partir del 15 de març."

tenen formulacions diferents, però semànticament estan relacionats.

Un bon model d'embeddings farà que les seves representacions vectorials siguin properes.

Embeddings multilingües

Un RAG també pot treballar amb documents en diferents idiomes.

Per exemple, podem tenir:

• documents en català
• documents en castellà
• documents en anglès
• documents en francès

En aquest cas és convenient utilitzar un **model d'embeddings multilingüe**.

NOTA: En el TFM de Josep Pla, bàsicament tots els documents seran en català. Per tant, a mi m'interessa un model d'embeddings que vagi bé per al català. Si tinc documents en castellà (que també n'hi haurà, per exemple transcripció d'entrevistes), el millor serà fer la traducció al català.

Aquests models permeten representar textos de diferents idiomes dins d'un espai semàntic compartit.

Això permet, per exemple, que una pregunta en català pugui recuperar informació continguda en un document en anglès, sempre que el model d'embeddings tingui una bona capacitat multilingüe.

Per tant, la recuperació no depèn necessàriament que la pregunta i el document estiguin escrits en el mateix idioma.

Base de dades semàntica: Qdrant

NOTA: Alternatives a Qdrant com a base de dades vectorial per fer cerca semàntica: pgvector, Weaviate, Milvus, Chroma, LanceDB, Vespa, Elasticsearch / OpenSearch, FAISS

Una vegada tenim els embeddings dels diferents chunks, cal emmagatzemar-los.

Aquí entra en joc Qdrant, que és una base de dades vectorial o base de dades semàntica'.

Qdrant permet emmagatzemar vectors i buscar-ne els que són més similars a un vector determinat.

Cada element emmagatzemat a Qdrant pot contenir:

• un identificador
• el vector de l'embedding
• el text original del chunk
• metadades associades

Per exemple:

**ID:** 1257
**Vector:** embedding del chunk
**Text:** "El contracte entra en vigor..."
**Document:** contracte.pdf
**Pàgina:** 12
**Idioma:** català

D'aquesta manera, el vector permet fer la cerca semàntica i les metadades permeten saber d'on prové la informació.

Què significa fer una cerca semàntica?

Una cerca tradicional pot buscar coincidències exactes de paraules.

Per exemple, si busquem:

> "temperatura màxima"

podem obtenir documents que continguin exactament aquestes paraules.

Una cerca semàntica funciona de manera diferent.

La pregunta es transforma en un embedding i es compara amb els embeddings dels documents.

Això permet trobar fragments que tenen un significat relacionat encara que no utilitzin exactament les mateixes paraules.

Per exemple:

• • Pregunta:**

> "Quina és la temperatura màxima de funcionament?"

Pot recuperar un fragment que diu:

> "L'equip pot operar fins a un màxim de 80 °C."

Encara que les paraules utilitzades no coincideixin exactament, els dos textos tenen una relació semàntica.

Procés de consulta

Una vegada els documents han estat ingerits i indexats, el sistema està preparat per respondre preguntes.

Quan l'usuari formula una pregunta, comença la segona fase del RAG.

Per exemple:

> "Quan entra en vigor el contracte?"

La pregunta passa pel mateix model d'embeddings utilitzat durant la indexació.

Per tant:

• • Pregunta → Embedding → Vector de consulta**

Aquest vector es proporciona a Qdrant.

Qdrant compara el vector de la pregunta amb els vectors que té emmagatzemats i retorna els fragments més similars.

Per exemple:

**Resultat 1:** fragment del contracte, pàgina 12
**Resultat 2:** fragment del contracte, pàgina 13
**Resultat 3:** fragment del contracte, pàgina 4
**Resultat 4:** fragment d'un altre document

Normalment es selecciona un nombre limitat de fragments, conegut com a **Top-K**.

Retrieval

Aquesta fase s'anomena **retrieval**, és a dir, recuperació de la informació.

És una de les parts fonamentals del RAG.

El sistema no proporciona tots els documents al LLM, sinó només els fragments que considera més rellevants per a la pregunta.

El flux és:

• • Pregunta** -> **Embedding de la pregunta** -> **Cerca semàntica a Qdrant** -> **Top-K fragments més rellevants** -> **Context per al LLM**

Aquesta estratègia redueix la quantitat d'informació que cal proporcionar al model i permet centrar-lo en les dades relacionades amb la pregunta.

Connexió amb el LLM

Una vegada recuperats els fragments rellevants, aquests es proporcionen al **Large Language Model (LLM)**.

El LLM pot estar allotjat al núvol o funcionar localment.

En un sistema local, es poden utilitzar eines com **Ollama** per executar diferents models de llenguatge a la pròpia màquina.

És important diferenciar dues funcions:

• Model d'embeddings: s'utilitza per representar textos com a vectors i facilitar la recuperació.
• LLM: s'utilitza per interpretar la pregunta i la informació recuperada i generar una resposta.

No és necessari que siguin el mateix model.

Context Augmentation

La característica principal del RAG és que la pregunta de l'usuari no s'envia simplement al LLM.

Abans, el sistema recupera informació de la base de dades vectorial.

El LLM rep una entrada conceptualment similar a:

• • Instruccions + context recuperat + pregunta de l'usuari**

Per exemple:

• • Context recuperat:**

> El contracte entrarà en vigor el dia 15 de març de 2026...

• • Pregunta:**

> Quan entra en vigor el contracte?

El LLM utilitza el context proporcionat per elaborar la resposta.

Aquesta és precisament la part **Augmented** de Retrieval-Augmented Generation: la generació de text es veu augmentada mitjançant informació recuperada externament.

Generació de la resposta

Finalment, el LLM analitza:

1. la pregunta de l'usuari,
2. les instruccions del sistema,
3. els fragments recuperats.

A partir d'aquesta informació genera la resposta final.

Per exemple:

> El contracte entra en vigor el 15 de març de 2026.

En un sistema ben dissenyat també es pot indicar la procedència de la informació:

> El contracte entra en vigor el 15 de març de 2026 (contracte.pdf, pàgina 12).

Això és especialment útil en entorns empresarials, jurídics o tècnics perquè permet comprovar l'origen de la resposta.

Diferència entre RAG i entrenar un LLM

És important no confondre un sistema RAG amb el **fine-tuning** o l'entrenament d'un model.

En un RAG, els documents no s'incorporen directament als paràmetres del LLM.

Els documents es mantenen en una font externa, com Qdrant.

Quan l'usuari fa una pregunta, el sistema recupera la informació necessària i la proporciona al LLM com a context. Per tant:

• • RAG**: Documents → Qdrant → Recuperació → Context → LLM

En canvi, en un procés d'entrenament o fine-tuning, la informació s'utilitza per modificar els paràmetres del model.

Això fa que RAG sigui especialment interessant quan els documents:

• canvien freqüentment,
• són privats,
• són molt nombrosos,
• han de poder actualitzar-se sense tornar a entrenar el model.

Metadades i traçabilitat

A més del vector, és recomanable guardar metadades associades a cada chunk. Per exemple:

• document d'origen
• pàgina
• secció
• idioma
• data
• categoria
• identificador del document

Aquestes dades permeten fer filtres durant la recuperació.

Per exemple:

> "Busca només documents de l'any 2025."

> "Busca només informació en català."

També permeten proporcionar referències a l'usuari i fer que la resposta sigui més fàcil de verificar.

Components principals d'un RAG

En resum, un sistema RAG pràctic està format per les següents peces:

Font documental

És el conjunt de documents que contenen el coneixement que volem consultar.

Exemples:

• PDF
• Word
• manuals
• bases documentals
• pàgines web

Processador de documents

S'encarrega d'extreure el contingut dels documents.

En el cas dels PDF, una eina com PyMuPDF pot realitzar aquesta funció.

Splitter / Chunker

Divideix els documents en fragments manejables i semànticament útils.

Model d'embeddings

Converteix els fragments de text en vectors numèrics.

Base de dades vectorial

Emmagatzema els vectors i permet buscar els fragments semànticament més propers.

En aquest cas, **Qdrant** exerceix aquesta funció.

Retriever

És la part del sistema que, a partir de la pregunta de l'usuari, consulta la base de dades vectorial i selecciona els fragments més rellevants.

LLM

Rep la pregunta juntament amb el context recuperat i genera la resposta.

Interfície d'usuari

És la capa que permet a l'usuari interactuar amb el sistema.

Pot ser:

• una aplicació web,
• un chatbot,
• una aplicació d'escriptori,
• una API,
• etc.

Flux complet

El funcionament es pot resumir en dos grans processos.

Procés d'ingesta

Aquest procés normalment es realitza quan s'incorporen nous documents.

1. Obtenció del document -> 2. Extracció del text -> 3. Neteja i preprocessament -> 4. Split en chunks -> 5. Generació dels embeddings -> 6. Emmagatzematge dels vectors a Qdrant -> Emmagatzematge de les metadades

Una vegada finalitzat aquest procés, els documents estan disponibles per a la consulta.

Procés de consulta

Aquest procés es realitza cada vegada que l'usuari formula una pregunta.

1. L'usuari formula una pregunta -> 2. La pregunta es converteix en un embedding -> 3. Qdrant busca vectors similars -> 4. Es recuperen els chunks més rellevants -> 5. Els chunks formen el context -> 6. La pregunta i el context s'envien al LLM -> 7. El LLM genera la resposta -> 8. Es mostra la resposta a l'usuari

Arquitectura final

Una arquitectura RAG local podria tenir aquesta estructura:

• • Documents** -> **PyMuPDF / altres parsers** -> **Split / Chunking** -> **Model d'embeddings multilingüe** -> **Qdrant** -> **Retriever** -> **Context recuperat** -> **Ollama / servidor LLM local** -> **LLM (Llama, Qwen, Mistral, etc.)** -> **Resposta**

En aquesta arquitectura, Qdrant funciona com el **repositori semàntic del coneixement documental**, mentre que el LLM actua com el **motor de comprensió i generació del llenguatge** (coneix el model del món).

Conclusions

El principal avantatge d'un sistema RAG és que permet separar el **coneixement documental** de les capacitats lingüístiques del model.

Els documents es processen i es divideixen en fragments. Cada fragment es transforma en un embedding i s'emmagatzema en una base de dades vectorial com Qdrant.

Quan l'usuari realitza una pregunta, aquesta també es transforma en un embedding. Qdrant permet trobar els fragments documentalment i semànticament més relacionats amb la pregunta.

Aquests fragments es proporcionen al LLM com a context. El model utilitza aquest context per generar una resposta coherent i relacionada amb els documents originals.

Per tant, el RAG no consisteix simplement a connectar una base de dades amb un LLM. És un **pipeline format per diverses etapes**, en què cada component té una responsabilitat concreta:

• • ingesta → split → embeddings → indexació → retrieval → context → LLM → resposta**

Aquesta separació permet construir sistemes que treballin amb grans quantitats de documentació, que es puguin actualitzar sense tornar a entrenar el model i que, amb una arquitectura adequada, puguin funcionar completament en local.

---

creat per Joan Quintana Compte, octubre 2026