RAG Explicat per a Founders: Com Donar Context Empresarial a un LLM
Has provat ChatGPT per al teu negoci. És impressionant — fins que li preguntes sobre ELS TEUS clients, ELS TEUS productes, ELS TEUS processos interns. Llavors comença a inventar. Noms falsos, dades que no existeixen, polítiques que mai vas tenir. Al·lucina perquè no té les teves dades.
No és un bug. És una limitació fonamental. GPT-4o, Claude 3.5, Llama 3.1 — tots els LLMs tenen coneixement general enorme però zero coneixement de la teva empresa. No saben qui són els teus clients, què diu la teva documentació interna ni quines són les teves polítiques de devolució.
La bona notícia: hi ha una solució que no requereix reentrenar cap model. Es diu RAG. I probablement é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
Pensa en un LLM com un empleat extremadament intel·ligent que sap de tot una mica però que acaba d'arribar a la teva empresa. Sap programar, escriure, analitzar dades — però no té accés a la teva wiki interna, el teu CRM, els teus contractes ni la teva base de coneixement.
Si li preguntes "quina és la nostra política de reemborsament per a clients enterprise?", inventarà una resposta que soni plausible. No perquè sigui deshonest, sinó perquè no té altra opció. Omple els buits amb probabilitats, no amb fets.
Fine-tuning (reentrenar el model amb les teves dades) sona com la solució òbvia, però té problemes seriosos: és car, requereix experiència especialitzada, les dades queden obsoletes ràpid i necessites repetir el procés cada cop que la teva informació canvia.
Aquí és on entra RAG.
Què és RAG i per què importa
RAG (Retrieval-Augmented Generation) és una tècnica que dona al LLM accés als teus documents en el moment de respondre una pregunta. No reentrenes el model. En comptes d'això, li passes la informació rellevant com a context juntament amb la pregunta de l'usuari.
És com donar-li a aquell empleat nou accés a l'arxiu de l'empresa abans que respongui cada pregunta. El model segueix sent el mateix, però ara té dades reals amb les quals treballar.
El concepte és simple. La implementació té matisos, però no és ciència espacial. Qualsevol equip d'enginyeria senior pot construir un sistema RAG funcional en setmanes.
Com funciona RAG: els 3 passos
Pas 1: Indexa les teves dades
Agafa els documents que vols que el LLM pugui consultar: PDFs, wikis, bases de dades, emails, documentació tècnica, tickets de suport. 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 teu 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 necessites entendre les matemàtiques darrere dels embeddings. El que importa és que dos textos amb significat similar tindran embeddings propers. "Política de devolució per a clients premium" i "reemborsament per a comptes enterprise" tindran vectors semblants, 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 comunes:
- Pinecone: managed, fàcil de començar, escala bé.
- Weaviate: open source, molt flexible.
- Qdrant: open source, rendiment excel·lent.
- pgvector: 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 una extensió és molt més simple 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 (mateix procés que amb els documents).
- Es busquen els chunks més similars a la base de dades vectorial — els fragments dels teus documents el significat dels quals és més proper a la pregunta.
- Aquests chunks s'injecten al prompt del LLM com a context: "Basant-te en la informació següent, respon la pregunta de l'usuari: [chunks rellevants]".
- El LLM genera una resposta fent servir LES TEVES dades, no el seu coneixement general.
El resultat: respostes fonamentades en informació real de la teva empresa. No al·lucinacions. No invencions.
Quan té sentit implementar RAG
RAG no és la solució per a tot, però és la solució correcta per a molts casos d'ús comuns a startups:
- Knowledge bases internes: empleats que consulten documentació, processos, polítiques.
- Chatbots de suport al client: respostes basades en la teva documentació real, no en el coneixement general del model.
- Cerca sobre documents: trobar informació rellevant en milers de documents legals, tècnics o financers.
- Consultes de compliance: respondre preguntes regulatòries fent servir la teva documentació de compliment normatiu.
- Sales enablement: donar al teu equip comercial respostes precises sobre productes, preus i comparatives amb competidors.
El patró comú: 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 RAG NO és suficient
Hi ha límits. És important conèixer-los abans de començar:
- Quan necessites que el model aprengui patrons nous. RAG dona context, no aprenentatge. Si necessites que el model classifiqui tickets de suport segons categories específiques de la teva empresa, pot ser que necessitis fine-tuning.
- Quan les dades canvien en temps real. RAG funciona bé amb documents que s'actualitzen periòdicament (diària o setmanalment). 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%. RAG millora enormement la precisió, però no la garanteix al 100%. Per a decisions mèdiques, legals vinculants o financeres d'alt risc, necessites validació humana al loop.
Errors comuns que has d'evitar
He vist aquests errors repetir-se en gairebé tots els equips que implementen RAG per primera vegada:
Chunks massa grans. Si cada chunk és un document sencer de 20 pàgines, estàs injectant molt soroll al prompt. El LLM rep massa informació irrellevant i la resposta perd qualitat. Chunks de 200-500 tokens solen ser un bon punt de partida.
Chunks massa petits. L'extrem oposat: fragments d'una sola frase perden context. Si un chunk diu "el límit és 30 dies" però no diu "per a reemborsaments de clients enterprise", la resposta serà incompleta. Necessites un equilibri entre especificitat i context.
No tenir un pipeline d'avaluació. Implementes RAG, "funciona", i el poses en producció. Però com saps si realment està trobant els documents correctes? Com mesures si les respostes són precises? Necessites mètriques: relevance score, faithfulness, answer correctness. Sense avaluació, voles a cegues.
No filtrar per rellevància. De vegades la base de dades vectorial retorna els chunks "més similars", però cap és realment rellevant. Si l'score de similitud és baix, és millor que el sistema digui "no tinc informació sobre això" en comptes de forçar una resposta amb dades tangencialment relacionades.
Confiar que el LLM dirà "no ho sé". Els LLMs són extremadament dolents dient "no ho sé". Fins i tot amb context RAG, si la resposta no és als documents, molts models intentaran respondre igualment. Necessites guardrails explícits al teu 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. Et donen components pre-construïts per a chunking, embedding, retrieval i generació. Acceleren el desenvolupament inicial, però afegeixen dependències i de vegades abstracció innecessària.
Pipeline custom: construeixes cada component per separat. Més feina inicial, però control total. Per a casos d'ús simples (un chatbot sobre la teva documentació), un pipeline custom amb pgvector i l'API d'OpenAI o Anthropic pot ser més simple que un framework.
La meva recomanació: comença amb un pipeline simple i custom. Si la complexitat creix (múltiples fonts de dades, re-ranking avançat, hybrid search), llavors avalua un framework. No comencis amb la solució més complexa.
Qui hauria de construir el teu sistema RAG
RAG és conceptualment simple però els detalls d'implementació importen molt. Chunking strategy, embedding model selection, retrieval tuning, prompt engineering, avaluació — cada decisió afecta la qualitat del resultat final.
No necessites un equip d'investigadors d'IA. Necessites enginyers senior que hagin construït sistemes RAG en producció i sàpiguen on són els gotchas. Que hagin iterat sobre estratègies de chunking, provat diferents models d'embedding i construït pipelines d'avaluació reals.
A Conectia, els enginyers que vetem per a projectes d'IA han treballat en implementacions reals de RAG — no en demos o tutorials. Saben la diferència 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 estaven al pla original.
Si estàs avaluant RAG per al teu producte, la diferència entre un bon resultat i una mala experiència d'usuari està en l'experiència de l'equip que el construeix. Un enginyer senior amb experiència en RAG pot estalviar-te mesos d'iteració i errors que ja va cometre algú abans.
Vols implementar RAG al teu producte però no tens l'equip amb experiència en producció? Parla amb un CTO — et connectem amb enginyers senior que ja han construït sistemes RAG reals, llestos per integrar-se en 72 hores.
