Agentic RAG: quan els teus documents interns es converteixen en el teu millor asset

La teva empresa ha generat milers de documents els últims anys. Contractes, manuals de producte, historials de suport, informes d'investigació, actes de reunions, tickets, polítiques internes. Tota aquesta informació és, en teoria, el coneixement acumulat de l'organització. A la pràctica, és un arxiu mort: ningú el troba quan el necessita, ningú l'actualitza, ningú confia del tot en el que retorna.

Durant els últims dos anys la resposta gairebé automàtica a aquest problema ha estat la mateixa: "Muntem un chatbot amb RAG". I durant aquests dos anys, la majoria d'aquests chatbots han acabat al mateix lloc: un projecte intern que al principi genera entusiasme, després genera dubtes i finalment s'abandona silenciosament perquè "no acaba de funcionar".

El problema poques vegades és la tecnologia base. El problema és que RAG tradicional — buscar fragments similars i passar-los a un LLM — no està dissenyat per raonar sobre el coneixement d'una empresa real. Empreses on la resposta correcta a una pregunta d'un client pot estar repartida entre un PDF de 2022, un ticket de Zendesk, una política interna i un changelog de producte. Cap d'ells, per separat, és la resposta. Tots, combinats i validats, sí.

Aquí és on entra Agentic RAG: el RAG que raona en lloc de només buscar. Aquest article explica què el diferencia del RAG tradicional, en quins casos d'ús empresarials està generant resultats reals, com es construeix pas a pas, quines mètriques importen de veritat i quin ROI cal esperar davant d'un chatbot simple.

RAG tradicional vs Agentic RAG: la diferència que ho canvia tot

RAG tradicional és un pipeline lineal. Rep una pregunta, la converteix en un vector, busca els fragments més similars a l'índex, els concatena i els passa a l'LLM juntament amb la pregunta. L'LLM genera una resposta. Fi del procés.

Aquest flux funciona raonablement bé per a FAQs, cerques puntuals en documentació ben estructurada i lookups d'informació on la resposta és en un sol document. Falla sistemàticament quan la pregunta requereix combinar diverses fonts, validar consistència, aplicar regles de negoci o reconèixer que la informació recuperada no és suficient.

Agentic RAG trenca la linealitat introduint agents amb capacitat de decisió dins del pipeline. En lloc d'un flux únic, hi ha un sistema que planifica, recupera, valida i refina. Si la primera cerca no retorna informació suficient, l'agent reformula la query i torna a buscar. Si els fragments recuperats es contradiuen, l'agent detecta el conflicte abans de generar la resposta. Si la pregunta requereix dades estructurades a més de text, l'agent decideix cridar un API o consultar una base de dades.

La diferència clau no està en els components, sinó en el reasoning autònom. Un sistema Agentic RAG pot decidir, dins del mateix cicle, si necessita buscar més, en quines fonts, amb quina estratègia i quan aturar-se. Es pot autoavaluar abans de respondre. Pot demanar context addicional a l'usuari si la pregunta és ambigua. Pot generar una resposta amb un nivell de confiança explícit.

Això no és cosmètica. És el que converteix un chatbot que "de vegades encerta" en un assistent del qual un advocat, un enginyer de suport o un investigador es pot fiar.

On Agentic RAG està generant resultats reals

No tots els casos d'ús justifiquen la complexitat addicional d'Agentic RAG. Però hi ha tres dominis empresarials en què la diferència davant d'un chatbot simple és mesurable i, en molts casos, crítica.

1. Knowledge management intern

L'escenari clàssic: una empresa amb 15 anys de documentació acumulada a Confluence, SharePoint, Notion, unitats compartides i wikis soltes. Els empleats nous triguen mesos a orientar-se. Els veterans depenen del coneixement tàcit de tres persones que fa temps que hi són des del principi. Quan algú necessita una resposta, recorre a Slack abans que al repositori, perquè buscar mai funciona.

RAG tradicional millora marginalment aquesta situació. Agentic RAG la transforma. En lloc de retornar un fragment amb baixa confiança, el sistema:

• Identifica quin repositori conté la font autoritzada per a aquest tipus de pregunta
• Reconeix si la política recuperada està desactualitzada i creua amb el changelog intern
• Detecta quan dos documents es contradiuen i prioritza el més recent o el de major jerarquia
• Cita les fonts amb enllaç directe, perquè l'usuari pugui validar
• Ofereix seguiment proactiu si detecta que hi ha informació relacionada que l'usuari hauria de conèixer

El que abans era "no trobo res a la wiki" es converteix en una conversa en què el sistema raona sobre el coneixement corporatiu com ho faria un empleat sènior que coneix on és cada cosa.

2. Customer support complex

El suport tècnic de productes amb moltes versions, configuracions i dependències és un camp de mines per al RAG simple. Una pregunta aparentment directa — "per què la meva integració amb el CRM X no s'està sincronitzant?" — pot requerir combinar el ticket actual del client, l'historial d'interaccions prèvies, la documentació tècnica del connector, les notes de l'última release i un log d'errors conegut.

Agentic RAG pot orquestrar tot això:

• Un agent d'investigació consulta la documentació tècnica i els tickets històrics amb problemes similars
• Un agent de verificació comprova si la versió del client està afectada per un bug conegut
• Un agent de síntesi combina les troballes i genera una resposta estructurada amb passos de diagnòstic
• Un agent d'escalat decideix si la resposta es pot resoldre en primer nivell o s'ha de derivar

Els equips de suport que treballen així no substitueixen l'agent humà. Redueixen dràsticament el temps de primera resposta, eleven la taxa de resolució en primer contacte i descarreguen el personal especialitzat de les consultes repetitives.

3. Investigació i desenvolupament (R&D)

En R&D, la promesa d'Agentic RAG és directa: convertir la literatura interna — informes previs, datasets propis, resultats d'experiments, patents, notes tècniques — en un assistent que ajudi l'equip a no repetir el que ja es va fer i a connectar troballes disperses.

Un investigador no pregunta "què diu el document X?". Pregunta "hem provat abans alguna cosa semblant a això?", "quines conclusions se'n van extreure?", "hi ha algun experiment amb resultats contradictoris?". Aquest tipus de consultes requereix un sistema que sintetitzi informació distribuïda, reconegui relacions conceptuals i, sobretot, sàpiga quan la literatura disponible no és suficient i cal assumir que s'està obrint terreny nou.

Arquitectura step-by-step: com es construeix un sistema Agentic RAG

Un pipeline Agentic RAG ben dissenyat té tres capes: indexació, retrieval i validació. Cada capa incorpora agents amb responsabilitats específiques. Saltar-se una d'elles és la causa més habitual que un projecte fracassi en producció.

Fase 1: Indexació conscient del context

La indexació en RAG tradicional sol ser una operació cega: trossejar el document en chunks de mida fixa i passar-los per un encoder per generar embeddings. En Agentic RAG la indexació és una fase activa que prepara el terreny perquè el retrieval posterior sigui possible.

1. Ingesta multi-font: Es connecten els repositoris reals (Confluence, SharePoint, Jira, bases de dades, drives). Cada document arriba amb metadades: autor, data, jerarquia, tipus, audiència, nivell d'accés.
2. Chunking semàntic: En lloc de trossejar per mida, es respecten les unitats naturals del document (seccions, apartats, blocs de codi). Un estudi clínic de 2025 va demostrar que el chunking adaptatiu arriba al 87% de precisió vs 13% amb mida fixa.
3. Enriquiment amb context: Cada chunk s'anota amb un resum semàntic que indica quina pregunta respon aquest fragment dins del document. Això és el que Anthropic anomena contextual retrieval, i redueix la taxa de fallades de recuperació fins a un 49%.
4. Graf de coneixement lleuger: S'extreuen entitats i relacions entre documents. No cal muntar GraphRAG complet, però sí tenir identificades les connexions clau: quin producte afecta quina política, quina release introdueix quina feature, quin client està vinculat a quin contracte.

Aquesta fase sol ser la més subestimada. Equips que salten directament al retrieval sense invertir en indexació acaben amb sistemes que retornen resultats aparentment rellevants però que no es poden justificar ni traçar.

Fase 2: Retrieval multi-estratègia

El retrieval en Agentic RAG no és una crida a l'índex vectorial. És una cascada orquestrada per un agent que decideix quina estratègia aplicar en funció de la query.

Fase 3: Validation agents

Aquí és on Agentic RAG se separa definitivament del RAG tradicional. Abans de generar la resposta final, un o diversos agents de validació operen sobre l'evidència recuperada.

• Agent de consistència: Detecta contradiccions entre els fragments recuperats. Si dos documents diuen coses diferents, marca el conflicte i aplica regles de priorització (data, jerarquia, nivell d'autoritat).
• Agent de suficiència: Avalua si l'evidència és realment suficient per respondre. Si no ho és, retorna el control al retrieval per a una nova passada.
• Agent de fonamentació: Verifica que cada afirmació de la resposta generada estigui sostinguda per una font concreta. Sense citació, no hi ha resposta.
• Agent de polítiques: Aplica regles de negoci i compliance. Filtra informació que l'usuari no ha de veure segons els seus permisos, emmascara dades sensibles i assegura que el sistema no retorni respostes fora del perímetre autoritzat.

Clau de disseny: els agents de validació han d'operar sobre l'evidència recuperada, no sobre la resposta generada. Validar després que l'LLM hagi sintetitzat ja és massa tard: el model pot haver introduït al·lucinacions que són difícils de detectar post-hoc. La validació prèvia a la generació és el que converteix Agentic RAG en un sistema fiable.

Les mètriques que importen de veritat

La pregunta més freqüent quan un equip passa de prototip a producció és "com sabem si funciona?". En Agentic RAG hi ha tres famílies de mètriques que no es poden ignorar. Qualsevol sistema que no les mesuri està, per definició, funcionant per sort.

Accuracy: respondre bé, no només respondre

Accuracy en RAG no és un número únic. Es descompon en quatre mètriques diferents que mesuren coses diferents:

• Context Precision: dels fragments recuperats, quin percentatge són realment rellevants per a la pregunta.
• Context Recall: de tota la informació rellevant existent al corpus, quin percentatge s'ha recuperat.
• Faithfulness: quin percentatge de les afirmacions de la resposta estan sostingudes pels fragments recuperats. Llindar de producció: >0.8 segons RAGAS.
• Answer Relevancy: com de directa i útil és la resposta respecte a la pregunta real de l'usuari.

Un sistema amb alta Context Precision però baixa Context Recall retorna respostes netes però incompletes. Un amb alta Faithfulness però baixa Answer Relevancy retorna respostes correctes que no contesten el que s'ha preguntat. Mesurar només una d'aquestes mètriques és un autoengany habitual en equips que encara no han passat a producció.

Latency: el cost real del raonament

Agentic RAG és, per disseny, més lent que el RAG tradicional. Cada cicle addicional de retrieval i validació afegeix latència. La pregunta important no és "quant triga?" sinó "quina és la latència acceptable per a aquest cas d'ús i com es distribueix entre els components?".

Per a aplicacions conversacionals, el llindar sol estar en 3-5 segons per resposta. Per a casos d'ús en background (anàlisi documental massiva, investigació), la latència acceptable puja a desenes de segons. El caching semàntic pot reduir costos i latència fins a un 65x en queries recurrents.

User satisfaction: la mètrica que molts equips no mesuren

Accuracy i latència són mètriques tècniques. User satisfaction és la mètrica que decideix si el sistema s'adoptarà o s'abandonarà. I és la que amb més freqüència queda fora del dashboard.

Les dues senyals més útils són:

• Taxa de feedback explícit: thumbs up/down després de cada resposta. Per sota del 70% de positiu sostingut, hi ha un problema.
• Taxa de reformulació: quantes vegades l'usuari torna a preguntar el mateix amb altres paraules. Una taxa alta indica que el sistema respon, però no encerta.

En combinació amb l'absència d'abandonament ("l'usuari deixa de fer servir el sistema sense avisar") i l'ús recurrent pels mateixos empleats, són les mètriques que de veritat diuen si l'Agentic RAG s'ha convertit en part del flux de treball o si és només una demo interna que ningú vol dir que no funciona.

ROI: Agentic RAG vs chatbots simples

La pregunta inevitable: val la pena la complexitat addicional? La resposta depèn completament del cas d'ús, però hi ha un patró clar: com més crítica és la resposta, major és el delta de ROI entre Agentic RAG i un chatbot simple.

Un chatbot simple es pot muntar en dues setmanes amb LangChain, un vector store i un LLM. Un Agentic RAG ben dissenyat requereix entre 6 i 12 setmanes, depenent del nombre de fonts i la complexitat dels validation agents. El cost inicial és aproximadament 3-4x superior. I, per a la majoria de casos d'ús, val la pena.

El patró que veiem en els equips que han fet aquesta transició és consistent: els chatbots simples entren en una espiral de desconfiança. El primer error genera dubtes. El segon genera escepticisme. El tercer fa que els empleats tornin a preguntar a Slack. Agentic RAG, perquè cita fonts, detecta contradiccions i reconeix els seus límits, trenca aquesta espiral des del principi.

Dada incòmoda: el 40-60% d'implementacions RAG enterprise no arriba a producció segons Gartner. De les que arriben, una part significativa cau en desús els primers 6 mesos. La causa dominant no és tècnica: és pèrdua de confiança de l'usuari. Agentic RAG ataca directament aquest problema.

Què hauria de fer un arquitecte avui

Si estàs avaluant si Agentic RAG té sentit per a la teva empresa, aquestes són les accions concretes ordenades per impacte.

1. Audita el teu corpus real. No el corpus teòric. Quants repositoris, quin volum, quin nivell d'actualització, quin nivell de duplicació. Sense això, qualsevol estimació d'esforç és fictícia.
2. Identifica el cas d'ús amb major dolor real. Comença per un domini on hi hagi un problema mesurable avui (temps d'onboarding, saturació de l'equip de suport, repetició de projectes en R&D). Agentic RAG sense cas d'ús clar és un experiment que no sobreviu al primer comitè de pressupost.
3. Inverteix en indexació abans que en retrieval. Chunking semàntic, enriquiment contextual, metadades ben estructurades. És la fase menys vistosa i la que més diferencia la producció de la demo.
4. Defineix els validation agents des del dia 1. Consistència, suficiència, fonamentació i polítiques. Saltar-se validació és saltar-se la diferència entre Agentic RAG i RAG.
5. Mesura user satisfaction des del primer deploy. Feedback explícit, taxa de reformulació, ús recurrent. Sense aquestes mètriques, no tindràs com detectar l'abandonament silenciós.
6. Planifica governança i control d'accés. Control d'accés pre-recuperació, no post-generació. Per a empreses a Europa, l'EU AI Act fa això no opcional a partir d'agost de 2026.

Connexió amb Spec-Driven Development. Un pipeline Agentic RAG sense especificació és un pipeline sense control. A onext apliquem SDD als pipelines RAG: constitució del sistema (regles immutables de chunking, validació, citació), templates de spec per tipus de query, i avaluació integrada en CI/CD. Els equips que ho fan redueixen la retreballada un 75% perquè l'arquitectura està dissenyada des del principi per controlar la complexitat, no per patir-la.

Conclusió: l'avantatge no està en buscar, està en raonar

Durant dos anys, el debat en IA empresarial ha girat al voltant de quin model fer servir, quin vector store escollir o quin framework era l'última moda. I mentrestant, els documents interns de les empreses continuaven sent exactament igual d'inaccessibles que abans.

Agentic RAG canvia l'enfocament. L'avantatge no està en tenir el millor índex vectorial ni l'LLM més gran. Està en construir un sistema que raoni sobre el coneixement corporatiu amb el mateix rigor amb què un empleat sènior raonaria: sabent on buscar, quan dubtar, quan combinar fonts i quan reconèixer que fa falta informació addicional.

La diferència entre un chatbot que respon i un assistent que entén no és una qüestió de més paràmetres. És una qüestió d'arquitectura. I el 2026, aquesta arquitectura — indexació conscient, retrieval multi-estratègia i validation agents — és el que separa els projectes que generen valor dels que acaben com una demo oblidada.

Els teus documents interns no són un arxiu.
Són el teu millor asset. Si saps com fer que raonin.