RAG vs Fine-Tuning.
Com triar l'enfocament adequat per al teu producte d'IA.
Estàs construint un producte d'IA. El teu model necessita conèixer les dades de la teva empresa, els teus clients i el teu domini. Algú de l'equip diu: "hauríem de fer fine-tuning". Una altra persona diu: "millor fes servir RAG". Totes dues opcions sonen raonables. Però ningú sap explicar exactament per què.
Aquesta decisió afecta el teu calendari en setmanes, els teus costos en desenes de milers de dòlars i la teva capacitat d'actualitzar el sistema un cop sigui en producció. Si t'equivoques al principi, ho pagaràs en costos de re-arquitectura sis mesos després.
No hi ha una resposta universal, però sí un marc clar de decisió, i la majoria d'equips s'equivoca perquè optimitza la variable incorrecta. Aquest article et dona aquest marc.
Què fa realment cada enfocament
RAG (Retrieval-Augmented Generation)
El model no es modifica. Li dones informació rellevant en temps de consulta recuperant-la d'una base de coneixement externa: base vectorial, repositori documental o índex de cerca.
Model mental: és com donar al model un document de referència abans de cada resposta. No memoritza, consulta.
Què necessita RAG en la pràctica:
- Un pipeline de recuperació: model d'embeddings, base vectorial i estratègia de chunking
- Una base de coneixement ben estructurada i actualitzada
- Manteniment continu a mesura que el coneixement canvia
Fine-Tuning
Agafes un model preentrenat i continues entrenant-lo amb les teves dades perquè interioritzi patrons, to, estructura o comportament de domini.
Model mental: estàs ensenyant al model, no passant-li apunts. Després de l'entrenament, aquest comportament queda incorporat.
Què requereix el fine-tuning:
- Dades d'entrenament etiquetades, normalment centenars o milers d'exemples d'entrada/sortida
- Pressupost de còmput per als entrenaments
- Reentrenar cada vegada que el coneixement o els requisits canvien de manera significativa
Error habitual: el fine-tuning no afegeix coneixement factual de manera fiable. Ensenya el model a com respondre (estil, format, comportament), no què ha de saber. Aquesta confusió és l'origen de moltes decisions incorrectes.
Les cinc variables reals de decisió
Preguntes superficials com "quin és més precís?" o "quin costa menys?" no tenen una resposta general. Aquestes cinc variables sí.
1) Amb quina freqüència canvia el teu coneixement?
Si la teva base de coneixement canvia diàriament o setmanalment (noves línies de producte, polítiques actualitzades, canvis regulatoris), RAG guanya per molt. Reentrenar un model fine-tuned per cada actualització és lent, car i operativament insostenible en fases inicials.
El coneixement estable (protocols mèdics, precedents legals consolidats, manuals fixos de producte) és on el fine-tuning esdevé realment viable. La cadència d'actualització és prou baixa perquè el cost de reentrenament es pugui amortitzar.
Pregunta clau: "La meva resposta seria diferent d'aquí sis mesos?" Si la resposta és sí, inclina't per RAG.
2) Recuperar coneixement o modelar comportament?
Aquesta és la distinció més important i la que més equips s'estalvien.
- Necessites que el model sàpiga coses (respondre sobre documents, productes, dades): RAG
- Necessites que el model es comporti diferent (to específic, format estricte, taxonomia pròpia): Fine-tuning
Un bot d'atenció al client que ha de sonar com la teva marca i conèixer el teu catàleg pot necessitar tots dos, però per motius diferents. El comportament ve del fine-tuning. El coneixement ve de RAG.
3) Quina és la teva situació de dades?
Per a RAG: necessites una base de coneixement neta, estructurada i recuperable. Si els teus documents són un caos de PDFs i pàgines de Notion, tens primer un problema de dades, no d'IA.
Per a fine-tuning: necessites exemples etiquetats, parelles entrada/sortida que mostrin el comportament desitjat. Mínim aproximadament 200 per a tasques bàsiques, i més de 1.000 per a canvis consistents de comportament.
La realitat: la majoria d'empreses early-stage no tenen prou dades etiquetades de qualitat per fer fine-tuning al primer mes.
4) Restriccions de latència i cost
RAG afegeix latència de recuperació, normalment entre 200 i 800 ms segons infraestructura, embeddings i base vectorial. Per a casos en temps real (veu, xat sub-segon), això importa i s'ha d'enginyar amb cura.
El fine-tuning pot reduir latència en eliminar la recuperació, però els models fine-tuned sovint són més grans i més cars d'operar que un model base amb capa RAG.
En etapes inicials, RAG sobre models base allotjats (GPT-4o, Claude, Gemini) acostuma a ser més barat que mantenir infraestructura dedicada per a inferència de models fine-tuned. Cal fer números abans de comprometre's.
5) Quin nivell d'explicabilitat necessita el teu sistema?
RAG et dona una font recuperable per a cada resposta. Pots mostrar quin document s'ha fet servir, quin chunk s'ha recuperat i quins senyals de confiança hi havia. En indústries regulades (salut, finances, legal), això sovint és un requisit de compliment.
Les respostes d'un model fine-tuned són opaques. El model "sap" alguna cosa, però no pots rastrejar per què ho ha dit. Si el teu producte passarà auditories o revisions de compliance, l'auditabilitat de RAG és un avantatge estructural.
Matriu de decisió: guia ràpida
| Senyal | Inclina't per RAG | Inclina't per Fine-Tune |
|---|---|---|
| El coneixement canvia sovint | ||
| Cal recuperar informació de documents | ||
| Cal format o estil de sortida específic | ||
| Compliance exigeix atribució de fonts | ||
| Tens més de 1.000 exemples etiquetats | ||
| Etapa inicial amb pressupost d'infra limitat | ||
| Cas sensible a latència, sense recuperació possible | ||
| Cal reduir la mida del prompt a escala |
Quan necessites tots dos (i com combinar-los)
RAG i fine-tuning no són excloents. La majoria de productes d'IA madurs fan servir tots dos. La decisió real d'arquitectura és quin problema resol cadascun.
Patró combinat habitual:
- Fine-tuning per a consistència de comportament: to, format de sortida, framing de tasca, guardrails de seguretat
- RAG per a grounding de coneixement: el contingut concret per respondre
Pensa en un sistema de monitoratge de compliment en trucades comercials. Necessita dues capacitats:
- Entendre què és una afirmació compliant o no compliant (classificador fine-tuned entrenat amb exemples etiquetats)
- Recuperar la política específica rellevant per al context de la trucada (RAG)
Cap dels dos enfocaments, per separat, és suficient.
Quan combines enfocaments, l'ordre importa:
- Primer recupera, després genera: el context de RAG entra al prompt abans de generar
- La qualitat del fine-tuning baixa si les dades d'entrenament no s'assemblen als prompts augmentats amb recuperació que veurà en inferència
Entrena amb exemples representatius que incloguin context recuperat.
L'error que més equips cometen (i per què és car)
L'error més habitual és triar fine-tuning perquè sona més "seriós" o "propietari", quan RAG hauria sortit més ràpid i hauria resolt millor el problema real.
El cost real no és només l'entrenament inicial. És:
- Setmanes recollint i etiquetant dades
- El primer cicle de reentrenament quan canvien els requisits
- Pèrdua de flexibilitat quan el comportament queda "incrustat" en els pesos i costa molt canviar-lo
El segon error més habitual és començar amb RAG però saltar-se la part difícil: estratègia de chunking, qualitat d'embeddings i avaluació de recuperació.
Un pipeline RAG mal dissenyat pot rendir pitjor que un model fine-tuned ben dissenyat en tasques de recuperació de coneixement. RAG no és "pujar documents a una base vectorial i ja està".
La pregunta no és quin enfocament és millor. La pregunta és quin problema tens realment.
Per on començar: primer pas pràctic per cada camí
Si t'inclines per RAG
- Audita la teva base de coneixement: està neta, actualitzada i és recuperable?
- Defineix la unitat de recuperació: què és un chunk en el teu domini?
- Construeix un petit set d'avaluació (20-50 parelles pregunta/resposta) abans d'escriure codi
- Tria el teu stack: model d'embeddings, base vectorial i capa d'orquestració
- Mesura la qualitat de recuperació abans de mesurar la qualitat de generació
Si t'inclines per Fine-Tuning
- Defineix exactament quin comportament vols canviar (sigues específic)
- Reuneix almenys 200 exemples etiquetats d'alta qualitat
- Estableix primer una línia base amb prompting; si ja arribes al 80%, potser el fine-tuning no compensa
- Planifica la cadència de reentrenament abans del llançament
RAG és el default correcte per a la majoria de productes d'IA en etapes inicials. És més ràpid de llançar, més barat d'actualitzar i més fàcil de depurar. El fine-tuning guanya sentit quan tens un problema de comportament (no de coneixement) i prou dades de qualitat per resoldre'l bé.
La majoria de sistemes en producció acaben fent servir tots dos, però haurien de començar pel problema real que intenten resoldre.
Els equips que prenen bé aquesta decisió des del principi no només estalvien temps d'enginyeria: construeixen sistemes més mantenibles, més explicables per a stakeholders i més fàcils de millorar quan evolucionen els requisits.
Vols una segona opinió sobre la teva arquitectura?
Si estàs decidint entre aquests enfocaments per al teu producte, encantats de parlar-ne. Sense pitch: una trucada de 30 minuts amb un dels nostres enginyers.
Construïm junts
Unim experiència i innovació per portar el teu projecte al següent nivell.