El teu equip va muntar un prototip de RAG en dues setmanes. A la demo funcionava. En producció, els usuaris es queixen de respostes irrellevants, el consum de tokens es dispara i ningú confia en les respostes. No és un problema d'LLMs. És un problema d'arquitectura de retrieval.
Retrieval-Augmented Generation prometia resoldre les al·lucinacions dels LLMs connectant-los amb dades reals. I ho fa, quan l'arquitectura és correcta. Però la majoria d'implementacions enterprise cauen en els mateixos tres errors que transformen RAG d'una inversió en un pou sense fons del pressupost.
Segons dades recents, el 80% de projectes RAG enterprise experimenten fallades crítiques en producció. El 42% de projectes d'IA van fracassar el 2025, representant 13.800 milions de dòlars en despesa enterprise en risc. I l'arrel no és tecnològica: és la bretxa entre un prototip que impressiona i un sistema que funciona a escala.
Error #1: Recuperació sense curació de dades
El primer error és el més bàsic i el més costós: connectar un LLM a una base de coneixement sense curar les dades que l'alimenten. Garbage in, garbage out, però ara amb un cost de tokens per cada consulta escombraria.
A la pràctica, això es manifesta en queixes com: "Li vaig preguntar per la política de vacances actualitzada i em va donar l'esborrany del Q1", o "Diu que no tenim política de devolucions quan la vam actualitzar fa dos mesos". L'LLM respon amb el que troba. Si troba documents desactualitzats, duplicats o contradictoris, la resposta reflecteix aquest caos.
La dada crítica: El 80% de les fallades de RAG s'originen en decisions de chunking, no en el retrieval ni en la generació. El chunking naïf amb mida fixa arriba a un faithfulness score de 0,47-0,51. El chunking semàntic optimitzat arriba a 0,79-0,82. Aquesta diferència és la que separa un sistema útil d'un que genera desconfiança.
Com evitar-lo
- Curació activa: No indexis tot. Filtra documents obsolets, elimina duplicats, normalitza formats abans d'ingerir.
- Chunking semàntic: Divideix documents per unitats de significat (seccions, paràgrafs temàtics), no per nombre de caràcters.
- Metadata enriquida: Cada chunk ha de portar data, font, versió i categoria. Sense metadata, el retriever no pot prioritzar el document correcte.
Error #2: Ignorar re-ranking i validació de rellevància
El segon error és confiar cegament en el retriever. Un vector search retorna els chunks "més propers" semànticament, però proximitat semàntica no és el mateix que rellevància per a la pregunta de l'usuari.
Sense re-ranking, l'LLM rep context que està vagament relacionat però no directament útil. El resultat: respostes genèriques, context inflat que consumeix tokens innecessaris i una confiança de l'usuari que cau ràpidament.
Arquitectura híbrida: la solució que funciona
L'arquitectura que veiem funcionar en producció combina tres capes:
- Retrieval híbrid (dense + sparse): Cerca vectorial (embeddings) per capturar significat semàntic + BM25 per a coincidència exacta de termes. Reciprocal Rank Fusion (RRF) combina tots dos rànquings en un.
- Re-ranking semàntic: Un model transformer (ColBERT, Cohere Rerank, o similar) reordena els resultats per rellevància real a la query. Filtra el soroll abans que arribi a l'LLM.
- Validació de rellevància: Un score mínim de rellevància per a cada chunk. Si cap resultat supera el llindar, el sistema respon "no tinc informació suficient" en lloc d'al·lucinar.
Query de l'usuari
│
├─→ Dense retrieval (embeddings) ──→ Top 20 candidats
│
├─→ Sparse retrieval (BM25) ──────→ Top 20 candidats
│
└─→ Reciprocal Rank Fusion ───────→ Top 20 fusionats
│
Re-ranker (ColBERT)
│
Top 5 rellevants
│
Score > llindar?
│ │
Sí No
│ │
LLM genera "No tinc informació
resposta suficient per respondre" Error #3: RAG simple quan el cas requereix agenticitat
El tercer error és aplicar RAG naïf a problemes que requereixen raonament multi-pas. Preguntes com "Quina és la diferència entre la nostra política de viatges de 2024 i la de 2025?" necessiten recuperar dos documents, comparar-los i sintetitzar les diferències. Un RAG simple recupera chunks i els passa a l'LLM sense capacitat de raonament intermedi.
Però l'error oposat també existeix: equips que salten directament a Agentic RAG quan un pipeline simple seria suficient. Cada pas agèntic consumeix tokens addicionals. Cada crida a eines afegeix latència i cost.
El cost compost: En un sistema amb fallades en cascada on cada capa té un 95% de precisió, la fiabilitat total cau al 81%. Cada capa agèntica que afegeixes multiplica els punts de fallada i el consum de tokens. El 2024, el 90% de projectes de RAG agèntic van fracassar en producció precisament per aquest efecte compost.
Quan escalar de RAG simple a agèntic
| Tipus de consulta | Arquitectura | Per què |
|---|---|---|
| Pregunta factual directa | RAG simple | Un retrieval + una generació. Sense overhead agèntic. |
| Comparació entre documents | RAG agèntic | Necessita múltiples retrievals i raonament intermedi. |
| Resum d'un document | RAG simple | El document es recupera i es resumeix en un pas. |
| Anàlisi creuada multi-font | RAG agèntic | Requereix planificar quines fonts consultar i en quin ordre. |
| FAQ sobre polítiques internes | RAG simple | Respostes directes amb baix cost per query. |
| Recerca amb reasoning multi-hop | RAG agèntic | La resposta depèn d'encadenar troballes intermèdies. |
Eines de benchmark: mesurar abans de posar en producció
Un dels patrons més costosos que veiem és equips que despleguen RAG a producció sense un framework d'avaluació. Descobreixen les fallades quan els usuaris es queixen, no quan podrien haver-les previngut.
RAGAS (Retrieval-Augmented Generation Assessment Suite) s'ha convertit en l'estàndard de facto per a l'avaluació de RAG, amb més de 400.000 descàrregues mensuals i 20 milions d'avaluacions executades. El que és rellevant per a equips que volen evitar llençar pressupost: RAGAS avalua qualitat sense necessitat de labels manuals.
Les 4 mètriques que has de mesurar abans de producció
- Faithfulness: La resposta es basa fidelment en el context recuperat o afegeix informació inventada? És la mètrica anti-al·lucinacions.
- Context Precision: Els chunks recuperats són rellevants per a la pregunta? Un score baix indica que estàs enviant soroll a l'LLM i pagant tokens per context inútil.
- Context Recall: Es recupera tota la informació necessària per respondre? Un score baix indica que el retriever no troba el que hauria.
- Answer Relevance: La resposta generada realment contesta la pregunta de l'usuari? Mesura el gap entre intenció i output.
Regla pràctica: Si el teu faithfulness score està per sota de 0,75, no posis el sistema en producció. Cada punt per sota és una al·lucinació que els teus usuaris trobaran, i cada al·lucinació erosiona la confiança més ràpid del que costa arreglar-la.
ROI: quan RAG justifica la inversió
RAG no és sempre la resposta correcta. De vegades un fine-tuning és més eficient. De vegades una cerca tradicional amb bona UX és suficient. La pregunta no és "podem implementar RAG?" sinó "ens dona RAG retorn sobre la inversió en aquest cas?"
RAG: ROI positiu vs overhead
ROI positiu
- Base de coneixement que canvia freqüentment (no viable amb fine-tuning)
- Volum alt de consultes repetitives sobre documentació interna
- Necessitat de traçabilitat (saber de quin document ve cada resposta)
- Múltiples fonts de dades que s'han de consultar de forma unificada
Probablement overhead
- Base de coneixement estàtica i petita (el fine-tuning és més eficient)
- Poques consultes al dia (el cost d'infraestructura no s'amortitza)
- Dades no estructurades sense possibilitat de curar (garbage in permanent)
- L'equip no té capacitat per mantenir el pipeline en producció
Conclusió: RAG funciona quan l'arquitectura és honesta
RAG no és màgia. És una arquitectura amb components que poden fallar independentment i el cost dels quals s'acumula a cada capa. Els equips que obtenen valor real de RAG són els que tracten cada component amb el mateix rigor que qualsevol sistema de producció:
- Curen dades abans d'indexar, no després que es queixin els usuaris.
- Implementen re-ranking en lloc de confiar cegament en el retriever.
- Trien la complexitat justa per a cada tipus de consulta, sense sobreenginyeria agèntica quan un RAG simple és suficient.
- Mesuren abans de desplegar amb RAGAS o un altre framework d'avaluació.
El 71% d'organitzacions fa servir GenAI de forma regular, però només el 17% atribueix més del 5% del seu EBIT a la GenAI. La bretxa entre fer servir IA i obtenir-ne retorn es tanca amb arquitectura correcta, no amb més tokens.
Un RAG ben dissenyat redueix costos i millora respostes. Un RAG mal dissenyat només multiplica la factura de tokens.
Jordi García és Tech Lead a onext. Treballa a portar la IA a producció governada en equips de desenvolupament i de producte —amb Spec-Driven Development, enginyeria de context i verificació humana a cada pas— i signa els insights tècnics d'onext sobre mètode, qualitat i cost de la IA aplicada.
LinkedIn →