Quan un RAG ja no cal, i quan encara hi és imprescindible

Fa un any, si volies que un model respongués sobre els teus propis documents, la resposta gairebé sempre era la mateixa: RAG. Indexes els documents, en recuperes els trossos rellevants per a cada pregunta i els poses davant del model perquè hi respongui. No hi havia alternativa real, perquè cap finestra de context aguantava més d’uns quants centenars de milers de tokens, i molt menys a un preu que es pogués pagar en producció.

Això ha canviat més ràpid del que la majoria de projectes s’han adonat. Aquest article continua el primer, on parlàvem del límit de fons de qualsevol sistema de recuperació: només pot trobar el que algú ja va escriure. Aquí la pregunta és més tècnica i, sovint, més cara si te l’equivoques: un cop tens el text, com el poses davant del model? Tot de cop, o a trossos?

Les xifres que ho han canviat

Llama 4 Scout, el model obert de Meta, arriba als 10 milions de tokens de finestra de context. És una xifra que costa d’imaginar: la Bíblia sencera en té uns 800.000. Deu Bíblies i mitja, en una sola trucada.

No cal arribar tan lluny per notar el canvi. Gemini 2.5 Flash, un model pensat per ser barat i ràpid (no el de gamma alta de Google), ofereix un milió de tokens de context per uns 30 cèntims per milió de tokens d’entrada. Fa dos anys, un milió de tokens de context era una demo de laboratori. Ara és un nivell econòmic.

No tots els models barats hi arriben, i val la pena dir-ho perquè no es generalitzi de més: GPT-5 mini, per exemple, es queda en 400.000 tokens. El milió no és encara un estàndard universal, però ja no és una excepció.

Amb aquestes mides, molts corpus sencers d’una petita empresa (tota la documentació, tots els tiquets d’un any, tot un codi base mitjà) hi caben directament. La pregunta «per què fer-hi un RAG, si li ho puc posar tot al davant» ha deixat de ser ingènua.

Per què una finestra gran no és gratis

Aquí és on molts projectes s’equivoquen per l’altra banda: assumir que, com que cap ara, no costa res.

Costa temps. Un model no llegeix un context llarg instantàniament: l’ha de processar sencer abans de començar a respondre (el que s’anomena prefill). Com més tokens hi poses, més triga a arrencar la resposta, i el cost de còmput no puja de manera lineal amb la mida del context, sinó més de pressa. Enviar deu vegades més context no costa deu vegades més: sol costar més.

Costa diners a cada crida. Si envies un milió de tokens a cada pregunta perquè el context inclou tota la documentació, pagues per aquest milió de tokens cada vegada, encara que la pregunta només necessités tres paràgrafs. En un sistema amb poc trànsit, no es nota. En un sistema que respon centenars de preguntes al dia, la factura ho fa evident de seguida.

I, potser el més important, no garanteix precisió. S’ha demostrat, i s’ha repetit en diversos models (GPT-3.5, GPT-4, Claude, i altres), que quan la resposta a una pregunta queda enterrada al mig d’un context molt llarg, en lloc del principi o del final, la precisió cau. En algunes proves, la caiguda supera el 30 %. Els models recorden millor el que han llegit fa poc i el que han llegit primer; el mig es dilueix. Una finestra de deu milions de tokens no és deu milions de tokens de memòria perfecta: és deu milions de tokens amb un forat al centre.

On el RAG segueix guanyant, encara amb finestres enormes

Fins i tot amb deu milions de tokens disponibles, hi ha situacions on la recuperació continua sent l’opció correcta, no la de repesca:

• Corpus més grans que la finestra. Un magatzem documental gran d’una empresa, o un codi base sencer amb anys d’història, pot superar fins i tot deu milions de tokens. Cap finestra actual ho cobreix tot.
• Dades que canvien. Si la informació s’actualitza cada dia (estocs, preus, tiquets oberts), tornar a enviar tot el context a cada pregunta és car i, sovint, ni cal: només fa falta recuperar el que ha canviat.
• Permisos diferents per usuari. Si dos usuaris no haurien de veure les mateixes dades, no pots ficar-ho tot en un sol context compartit. La recuperació, feta bé, filtra per qui pregunta abans de respondre; un context gegant i estàtic no ho fa sol.
• Cost a volum alt. Reenviar un context enorme a cada crida, quan reps centenars o milers de preguntes al dia, surt més car que recuperar un fragment petit i rellevant per a cadascuna.

La pregunta correcta no és «RAG o context»

La manera útil de plantejar-ho no és triar un bàndol per sempre, sinó decidir cas per cas, amb quatre preguntes: el corpus cap a la finestra? és estable? el veu un sol usuari a la vegada? i el volum de preguntes és baix? Si la resposta a totes és sí, posa-ho tot al context i estalvia’t la infraestructura de recuperació. Si la resposta a alguna és no, necessites recuperar, per gran que sigui el model que facis servir després.

I val la pena recordar el que dèiem al primer article: tant si tries context gegant com recuperació, totes dues opcions treballen només sobre el que ja està escrit. Cap de les dues resol el problema del coneixement tàcit. Només decideixen com li arribes al model el que sí que tens per escrit.

Si la resposta és que et cal recuperació, la pregunta següent és pràctica: on guardes els vectors i com els cerques. És el que tractem al tercer article, on comparem Qdrant, pgvector i Milvus amb noms i xifres, no amb generalitats.