RAG, fine-tuning o prompts: què convé per posar un LLM en producció

Hi ha tres maneres d'adaptar un model de llenguatge a la feina d'una empresa: escriure-li instruccions millors, donar-li els documents de la casa en el moment de la consulta o reentrenar-lo amb dades pròpies. Gairebé tots els projectes que revisem comencen per l'opció més cara. L'ordre en què es proven pesa més que la tècnica triada, i aquest ordre és sempre el mateix.

Les instruccions resolen més casos del que sembla

El prompt és el conjunt d'instruccions, exemples i format de sortida que rep el model amb cada petició. Costa hores, es canvia sense desplegar res i es prova en una tarda. Per això és el primer pas, encara que als equips tècnics els sembli poc ambiciós.

A la pràctica, un prompt ben construït fixa el rol, descriu la tasca amb un exemple real, defineix els camps que s'esperen i obliga a retornar un JSON estricte. Amb això queden cobertes tasques de classificació, extracció de camps d'un tipus de document i redacció de respostes a partir d'una plantilla. El que no pot fer és aportar informació que el model no té: el catàleg de l'empresa, la política de devolucions vigent, l'historial d'un client.

El límit apareix quan el prompt creix fins a convertir-se en un manual. Si cada cas estrany hi afegeix un paràgraf, esdevé impossible de mantenir i canvia de comportament amb cada versió del model. Aquest és el senyal per passar a la recuperació de documents.

RAG dona al model les dades de l'empresa sense reentrenar-lo

RAG (generació augmentada per recuperació) consisteix a buscar, per a cada pregunta, els fragments de documentació interna que la responen i passar-los al model com a context. Els documents es queden on ja eren (SharePoint, l'ERP, una base de dades, una bústia plena de PDF); s'indexen i es consulten en el moment. El model redacta a partir del que ha recuperat i pot citar d'on surt cada dada.

El que canvia respecte del prompt és la frescor i la traçabilitat. Si el preu d'un producte s'actualitza avui a Business Central, la resposta de demà ho reflecteix. Si una resposta és incorrecta, es veu quin fragment l'ha provocada. Cap de les dues coses no existeix amb un model reentrenat.

El problema és que RAG hereta la qualitat de les fonts. Una wiki amb tres versions del mateix procediment produeix respostes amb tres versions, totes escrites amb la mateixa seguretat. Per això la major part de la feina d'un projecte RAG és a la capa de dades: decidir quines fonts hi entren, qui les manté i com es trossegen i s'indexen. El model (Claude, GPT, Gemini o un de pesos oberts dins del núvol propi a Azure o AWS) és la peça que menys hores consumeix.

El fine-tuning canvia el comportament, no el coneixement

Reentrenar un model amb exemples propis ajusta com respon: el to, el format, la manera de classificar. Compensa quan hi ha milers d'exemples etiquetats d'una tasca estable i les dues tècniques anteriors s'han quedat curtes a l'avaluació. Un cas típic és una classificació amb desenes de categories pròpies del sector on els prompts llargs no arriben mai a la precisió exigida.

A canvi, el coneixement queda congelat en la data de l'entrenament i cada actualització obliga a repetir el procés, amb el seu cost de GPU i de preparació de dades. Un model reentrenat tampoc no cita fonts. Dit d'una altra manera, no és l'eina perquè el model "conegui l'empresa"; per a això hi ha RAG.

Convé tractar-lo com l'última opció. A la majoria d'empreses mitjanes el conjunt de dades etiquetades no existeix, i construir-lo costa més que la resta del projecte.

El que decideix el resultat és l'avaluació

Abans de tocar res cal un conjunt de prova: entre cinquanta i cent peticions reals amb la resposta que l'equip considera correcta. Amb aquest conjunt es mesura el punt de partida i cada canvi (un prompt nou, una altra estratègia d'indexació, un model diferent) es compara amb un número en lloc d'una impressió. Sense això, la discussió sobre tècniques és una discussió d'opinions.

Les mètriques útils són poques: encert per tipus de petició, proporció de respostes en què el model reconeix que no té dades, latència i cost per petició. Un sistema que respon bé la majoria de casos i s'inventa la resta és pitjor que un que encerta una mica menys i deriva els dubtes a una persona.

En producció, el sistema necessita a més el que necessita qualsevol programari: registre de cada petició i resposta, gestió d'errors i de límits de l'API, un model de reserva i una via perquè una persona revisi els casos de baixa confiança. És aquí on se'n va la major part del pressupost, i aquí es decideix si el projecte sobreviu al segon mes.

Per on començar aquesta setmana

• Triar una sola tasca amb volum i resultat verificable: classificar correus entrants, extreure camps d'un tipus de document o redactar la primera resposta a una consulta.
• Reunir cinquanta casos reals amb la resposta correcta i anotar l'encert actual del procés manual.
• Provar primer amb un prompt sobre l'API d'un proveïdor i mesurar contra aquest conjunt.
• Afegir recuperació només sobre documents que algú mantingui, i deixar per escrit qui.
• Plantejar el fine-tuning únicament si els números de l'avaluació ho justifiquen.

Si el cas encaixa, a LakeTab el revisem en una primera trucada de 60 minuts.