La promesa de la generació augmentada per recuperació (RAG, per les seves sigles en anglès) ha captivat moltes organitzacions que busquen dotar els models de llenguatge d'un context empresarial precís. No obstant això, després dels prototips reeixits i les demostracions brillants, la realitat productiva sol ser molt diferent. Quan un sistema RAG falla, rara vegada ho fa de forma sorollosa. Més aviat, produeix respostes polides però incorrectes, cosa que erosiona la confiança dels usuaris i pot generar decisions equivocades. El problema no està en el model de llenguatge, sinó en l'arquitectura de recuperació. Tractar la recuperació com un sistema productiu, amb controls de qualitat, observabilitat i propietat, és l'única forma que RAG compleixi la seva promesa en entorns empresarials.
Molts equips implementen RAG seguint un flux bàsic: ingerir documents, trossejar-los, generar vectors, indexar-los i després recuperar fragments similars per incloure'ls en el prompt. Aquest patró funciona en entorns controlats, però a la pràctica s' enfronta a documents desactualitzats, versions duplicades, permisos mal gestionats i solapaments semàntics. Un fragment pot ser semànticament similar però fàcticament irrellevant. L'índex pot contenir polítiques obsoletes al costat de les vigents. El model, en rebre context contradictori, el barreja i genera una resposta coherent però falsa. Això és el que fa que un RAG feble sigui perillós: no sempre falla de forma evident.
Per evitar aquest escenari, cal canviar l'enfocament. En lloc de pensar en RAG com una característica més d'un assistent conversacional, l'hem de concebre com un sistema de recuperació amb portes de qualitat. Aquestes portes inclouen la verificació de la frescor de la font, l' autoritat del document, els permisos de l' usuari, la coherència amb metadades i la suficiència de l' evidència. Per exemple, un runbook d'operacions de VMware Cloud Foundation no hauria d'aparèixer en una consulta sobre procediments d'Azure si les metadades indiquen que pertany a una altra plataforma. Sense metadades, el recuperador no té forma de distingir entre documents que comparteixen vocabulari però pertanyen a contextos diferents.
La incorporació de metadades no és opcional; és un requisit arquitectònic. Cada document ha d' incloure informació com el propietari, la unitat de negoci, el sistema o plataforma associada, la versió, la data de vigència, el nivell de confidencialitat i l' estat de revisió. D' aquesta manera, el sistema pot filtrar, prioritzar i ordenar els fragments segons criteris de negoci, no només segons similitud vectorial. A més, una política de control de RAG, expressable en formats com YAML, permet que els equips d' arquitectura, seguretat i operacions revisin i aprovin explícitament les regles de recuperació. Per exemple, es pot definir que només s'utilitzin fonts aprovades, que es bloquegin els documents esborranys i que es requereixi un mínim de dues evidències abans de generar una resposta.
L' avaluació és un altre pilar que sovint es descuida. Mesurar únicament la qualitat de la resposta final oculta el veritable origen de les fallades. Cal avaluar per separat la qualitat de la recuperació (es van recuperar els fragments correctes?), l'assemblatge del context (el prompt contenia informació suficient i sense soroll?) i la generació de la resposta (el model va utilitzar correctament l'evidència?). Si la resposta és incorrecta, l'equip ha de saber si el recuperador va proporcionar mal context o si el model va ignorar l'evidència. Cada cas té una solució diferent. Mètriques com la taxa d'encert, la precisió i el rang recíproc mitjà ajuden, però les proves amb preguntes reals d'operacions són insubstituïbles.
En aquest punt, l'experiència d'una empresa com Q2BSTUDIO, especialitzada en intel·ligència artificial per a empreses, resulta rellevant. Hem vist com la falta d'una estratègia de recuperació ben governada porta projectes d'IA a estancar-se. La intel·ligència artificial no és només el model; és l'ecosistema que l'envolta: les fonts de dades, els pipelins d'ingestió, els controls d'accés i l'observabilitat. Per això, en dissenyar solucions de RAG, recomanem començar amb un abast reduït, un domini conegut i un registre de fonts. No s' ha d' indexar tot el contingut de l' empresa sense abans filtrar el que realment aporta valor. Incloure contingut dolent és tan perjudicial com excloure contingut bo.
La propietat del sistema s' ha de distribuir entre diversos equips. Els propietaris de contingut decideixen quins documents són els mateixos i quan s'han de retirar. L' equip de seguretat defineix les llistes de control d' accés i els requisits d' auditoria. L'equip de plataforma opera l'índex, el pipeline i el runtime. L' equip d' IA defineix l' estratègia de recuperació, l' avaluació i el comportament del prompt. I l'equip d'operacions gestiona els incidents quan els usuaris reporten respostes incorrectes. Sense aquesta divisió de responsabilitats, RAG es converteix en una característica d'IA que ningú posseeix realment, cosa que permet que el contingut obsolet i les fallades silencioses s'acumulin.
Des d'una perspectiva tècnica, la implementació ha de contemplar un comportament de tancament segur (fail-closed). El sistema ha de ser capaç de respondre 'No tinc prou evidència aprovada per respondre de forma segura' quan la qualitat de la recuperació no assoleix el llindar. Això no és una debilitat, és un control. A més, és fonamental registrar cada decisió de recuperació: quins fragments es van recuperar, per quina puntuació, quines metadades tenien i com van influir en la resposta. Aquesta traçabilitat permet reconstruir incidents i millorar el sistema de forma contínua.
La integració amb serveis cloud com AWS i Azure és habitual en aquests entorns, ja que moltes organitzacions emmagatzemen els seus documents en plataformes cloud. Gestionar correctament els permisos i la sincronització entre l' índex vectorial i els repositoris originals és un desafiament que requereix experiència. De la mateixa manera, la ciberseguretat juga un paper crucial: un sistema RAG que filtri informació sensible per una mala configuració d'ACL pot tenir conseqüències greus. En Q2BSTUDIO oferim serveis de ciberseguretat que ajuden a identificar i mitigar aquests riscos abans que arribin a producció.
La intel·ligència de negoci i les eines com Power BI també es beneficien de RAG quan es combinen amb fonts de dades internes. Un assistent que respongui preguntes sobre KPIs a partir de documents normatius pot ser molt potent, sempre que la recuperació estigui ben governada. Les aplicacions a mesura que integren RAG requereixen un disseny acurat de la capa de recuperació, més enllà de la simple inclusió d' un índex vectorial. Per això, en Q2BSTUDIO abordem cada projecte de programari a mida amb un enfocament en la qualitat de les dades i la traçabilitat de les decisions.
Els agents d'IA, que estan guanyant protagonisme, també depenen de la recuperació per executar accions en nom de l'usuari. Si un agent rep context incorrecte, pot executar comandaments equivocats en sistemes productius. D'aquí que la recuperació no sigui només un problema de preguntes i respostes, sinó un component crític per a l'automatització segura. Els serveis cloud AWS i Azure ofereixen eines per construir pipelins escalables, però la governança ha de ser dissenyada per humans amb coneixement del domini.
En conclusió, RAG no és inútil; el RAG feble és inútil. La diferència està en la disciplina operativa. La recuperació necessita autoritat de font, metadades, control d' accés, estratègia de rànquing, avaluació, observabilitat i propietat. Sense aquests controls, el model de llenguatge esdevé la façana polida d'un pipeline d'evidència caòtic. Tracti la recuperació com un sistema productiu, monitora'l, pruébelo, governi, així com propietaris i defineixi un comportament de recolzament quan l'evidència sigui feble. Aquesta és l'única manera que RAG sigui útil més enllà de la demostració.
