RAG explicat per a founders: com donar el context del teu negoci a un LLM
Has provat ChatGPT per al teu negoci. És impressionant — fins que li preguntes pels teus clients, els teus productes, els teus processos interns. Llavors es comença a inventar coses. Noms falsos, dades inexistents, polítiques que no has tingut mai. Al·lucina perquè no té les teves dades.
No és un bug. És una limitació de fons. GPT-4o, Claude 3.5, Llama 3.1 — tots els LLM tenen un coneixement general enorme i zero coneixement de la teva empresa. No saben qui són els teus clients, què diu la teva documentació interna ni com són les teves polítiques de devolució.
La bona notícia: hi ha una solució que no demana reentrenar cap model. Es diu RAG. He vist equips que el munten bé i equips que el munten malament, i crec que és la tècnica d'IA més rellevant per a la teva startup ara mateix.
El problema: un LLM generalista no coneix el teu negoci
Imagina't un LLM com un empleat brillantíssim que sap una mica de tot però que acaba d'entrar a la teva empresa. Sap programar, escriure i analitzar dades — però no té accés a la wiki interna, al CRM, als contractes ni a la base de coneixement.
Si li preguntes «quina és la nostra política de reemborsament per a clients enterprise?», s'inventarà una resposta que sona plausible. No perquè sigui deshonest, sinó perquè no té cap més opció. Omple els buits amb probabilitats, no amb fets.
El fine-tuning (reentrenar el model amb les teves dades) sembla la solució òbvia, però té inconvenients seriosos: és car, demana coneixements molt especialitzats, les dades queden obsoletes de seguida i has de repetir el procés cada vegada que la informació canvia.
Aquí entra en joc el RAG.
Què és el RAG i per què importa
El RAG (Retrieval-Augmented Generation) és una tècnica que dona a l'LLM accés als teus documents en el moment de respondre una pregunta. No reentrenes el model: li passes la informació rellevant com a context, juntament amb la consulta de l'usuari.
És com donar a aquell empleat nou accés a l'arxiu de l'empresa abans que respongui cada pregunta. El model continua sent el mateix, però ara té dades reals amb què treballar.
El concepte és senzill. La implementació té matisos, però tampoc no és física quàntica. Qualsevol equip d'enginyeria sènior pot construir un sistema RAG funcional en qüestió de setmanes.
Com funciona el RAG: els 3 passos
Pas 1: indexa les teves dades
Agafa els documents que vols que l'LLM pugui consultar: PDF, wikis, bases de dades, correus, documentació tècnica, tiquets de suport. Tot el que sigui rellevant.
Cada document es divideix en chunks (fragments). Un chunk pot ser un paràgraf, una secció, una pàgina — depèn del cas d'ús. Després, cada chunk es converteix en un embedding: una representació numèrica (un vector) que captura el significat semàntic del text.
No cal que entenguis les matemàtiques que hi ha darrere dels embeddings. El que importa és que dos textos amb un significat semblant tindran embeddings semblants. «Política de devolució per a clients premium» i «reemborsaments per a comptes enterprise» tindran vectors propers, encara que facin servir paraules diferents.
Pas 2: emmagatzema els embeddings
Aquests vectors es guarden en una base de dades vectorial. Les opcions més habituals:
- Pinecone: servei gestionat, fàcil d'arrencar, escala bé.
- Weaviate: open source, molt flexible.
- Qdrant: open source, rendiment excel·lent.
- pgvector: una extensió de PostgreSQL. Si ja fas servir Postgres, pots començar sense afegir infraestructura nova.
Per a la majoria de startups, pgvector és l'opció més pragmàtica. Ja tens PostgreSQL. Afegir-hi una extensió és molt més senzill que gestionar una base de dades nova.
Pas 3: consulta en temps real
Quan un usuari fa una pregunta:
- La pregunta es converteix en un embedding (el mateix procés que amb els documents).
- Es recuperen de la base de dades vectorial els chunks més semblants — els fragments dels teus documents amb el significat més proper a la pregunta.
- Aquests chunks s'injecten al prompt de l'LLM com a context: «Basant-te en la informació següent, respon la pregunta de l'usuari: [chunks rellevants]».
- L'LLM genera una resposta a partir de les teves dades, no del seu coneixement general.
El resultat: respostes fonamentades en informació real de la teva empresa, i no suposicions que sonen plausibles. Les al·lucinacions cauen en picat — no fins a zero, com veurem, però prou per canviar el que és possible.
Quan té sentit implementar RAG
El RAG no és cap vareta màgica, però és la solució correcta per a molts casos d'ús habituals en una startup:
- Bases de coneixement internes: empleats que consulten documentació, processos i polítiques.
- Chatbots de suport al client: respostes basades en la teva documentació real, no en el coneixement general del model.
- Cerca documental: trobar informació rellevant entre milers de documents legals, tècnics o financers.
- Consultes de compliance: respondre preguntes regulatòries a partir de la teva documentació de compliment normatiu.
- Sales enablement: donar a l'equip comercial respostes precises sobre productes, preus i comparatives amb la competència.
El fil conductor: tens un corpus de documents que els teus usuaris (interns o externs) necessiten consultar, i vols una interfície conversacional que doni respostes precises.
Quan el RAG NO és suficient
Hi ha límits, i prefereixo que els descobreixis sobre el paper i no en producció:
- Quan necessites que el model aprengui patrons nous. El RAG aporta context, no aprenentatge. Si necessites que el model classifiqui tiquets de suport segons les categories específiques de la teva empresa, potser et caldrà fine-tuning.
- Quan les dades canvien en temps real. El RAG funciona bé amb documents que s'actualitzen periòdicament (cada dia o cada setmana). Si necessites dades al segon — cotitzacions de borsa, inventari en temps real — necessites un pipeline de streaming, no només RAG.
- Quan la precisió ha de ser del 100%. El RAG millora moltíssim la precisió, però no la garanteix al 100%. Per a decisions mèdiques, dictàmens legalment vinculants o decisions financeres d'alt risc, necessites supervisió humana.
Els errors que comet gairebé tothom al seu primer RAG
He vist com aquests errors es repetien en gairebé tots els equips que implementen RAG per primer cop:
Chunks massa grans. Si cada chunk és un document sencer de 20 pàgines, estàs injectant un munt de soroll al prompt. L'LLM rep massa informació irrellevant i la qualitat de la resposta se'n ressent. Uns chunks de 200-500 tokens solen ser un bon punt de partida.
Chunks massa petits. L'extrem oposat: els fragments d'una sola frase perden el context. Si un chunk diu «el límit és de 30 dies» però no diu «per a reemborsaments de clients enterprise», la resposta quedarà incompleta. Cal un equilibri entre especificitat i context.
Cap pipeline d'avaluació. Implementes el RAG, «funciona», i el poses en producció. Però com saps que realment troba els documents correctes? Com mesures si les respostes són precises? Necessites mètriques: relevance score, faithfulness, answer correctness. Sense avaluació, vas a cegues.
No filtrar per rellevància. De vegades la base de dades vectorial retorna els chunks «més semblants», però cap no és realment rellevant. Si la puntuació de similitud és baixa, val més que el sistema digui «no en tinc informació» que no pas forçar una resposta amb dades que només hi tenen una relació tangencial.
Confiar que l'LLM dirà «no ho sé». Els LLM són notòriament dolents a l'hora de dir «no ho sé». Fins i tot amb el context del RAG, si la resposta no és als documents, molts models intentaran respondre igualment. Necessites guardrails explícits al sistema per gestionar aquests casos.
Build vs. buy: la decisió pràctica
Tens dos camins:
Frameworks existents: LangChain i LlamaIndex són els més populars. T'ofereixen components ja fets per al chunking, els embeddings, el retrieval i la generació. Acceleren el desenvolupament inicial, però afegeixen dependències i, de vegades, una abstracció innecessària.
Pipeline a mida: construeixes cada component per separat. Més feina inicial, però control total. Per a casos d'ús senzills (un chatbot sobre la teva documentació), un pipeline a mida amb pgvector i l'API d'OpenAI o d'Anthropic pot ser més senzill que un framework.
La meva recomanació: comença amb un pipeline senzill i a mida. Si la complexitat creix (múltiples fonts de dades, re-ranking avançat, cerca híbrida), llavors sí, avalua un framework. No comencis per la solució més complexa.
Qui hauria de construir el teu sistema RAG
El RAG és conceptualment senzill, però els detalls d'implementació pesen molt. L'estratègia de chunking, la tria del model d'embeddings, l'ajust del retrieval, el prompt engineering, l'avaluació — cada decisió afecta la qualitat del resultat final.
No necessites un equip d'investigadors d'IA. Necessites enginyers sèniors que hagin construït sistemes RAG en producció i sàpiguen on són els paranys. Que hagin iterat estratègies de chunking, provat models d'embedding diferents i muntat pipelines d'avaluació de debò.
A Conectia, els enginyers que seleccionem per a projectes d'IA han treballat en implementacions reals de RAG — no en demos ni tutorials. Saben distingir entre un prototip que funciona en un notebook i un sistema que funciona en producció amb dades reals, a escala, i amb usuaris que fan preguntes que no eren al pla original.
Si estàs avaluant el RAG per al teu producte, la diferència entre un gran resultat i una mala experiència d'usuari rau en l'experiència de l'equip que el construeix. Un enginyer sènior amb experiència en RAG et pot estalviar mesos d'iteració i d'errors que algú altre ja ha comès.
Vols implementar RAG al teu producte però no tens un equip amb experiència en producció? Parla amb un CTO — et connectem amb enginyers sèniors que ja han construït sistemes RAG reals, i et responem en menys de 72 hores.
