Integrant LLMs al Teu Producte: Guia Tècnica per a Startups
Cada fundador vol afegir "IA" al seu producte. Ho entenc. Els inversors pregunten per això, els competidors ho anuncien, i la demo que vas muntar un diumenge amb l'API d'OpenAI semblava màgica.
El problema és que les demos sempre semblen màgiques. Li demanes al model que resumeixi un text, et retorna alguna cosa coherent, i penses "això ho tenim en producció en dues setmanes". Després arriben les dues setmanes. I les dues següents. I tres mesos després segueixes lluitant amb al·lucinacions, latències de 8 segons, factures d'API que no quadren i outputs que el teu sistema downstream no pot parsejar.
La diferència entre una demo i un producte no és el model. És l'enginyeria.
Aquesta guia és el camí que segueixo quan un equip necessita integrar LLMs al seu producte de veritat — no per a un pitch deck, sinó per a usuaris reals en producció.
Pas 1: Defineix el cas d'ús abans de tocar codi
Abans de triar model, framework o arquitectura, respon una pregunta: quina tasca específica resoldrà el LLM?
"Afegir IA al producte" no és un cas d'ús. Aquests sí que ho són:
- Classificació: categoritzar tickets de suport, detectar intenció de l'usuari, moderar contingut.
- Generació: crear esborranys d'emails, generar descripcions de producte, escriure codi.
- Resum: condensar documents llargs, extreure punts clau de reunions.
- Extracció: treure dades estructurades de text lliure (noms, dates, quantitats de factures).
Cadascun d'aquests casos necessita un enfocament diferent. La classificació pot funcionar amb models petits i ràpids. La generació necessita models més capaços. El resum depèn de la mida de la finestra de context. L'extracció requereix outputs estructurats fiables.
Si no defineixes el cas d'ús amb precisió, sobreenginyeraràs la solució o triaràs el model equivocat. Les dues opcions et costen mesos.
Pas 2: Tria la teva estratègia de model
Tens tres camins. Cadascun té sentit en contextos diferents.
API de tercers (OpenAI, Anthropic, Google). El més ràpid per començar. Crides GPT-4o, Claude 3.5 Sonnet o Gemini, pagues per token, no gestionas infraestructura. Per a la majoria de startups, aquest és el camí correcte al principi. Et permet validar el cas d'ús sense invertir setmanes en infraestructura. El risc: dependència del proveïdor i costos que escalen linealment amb l'ús.
Open source autoallotjat (Llama 3.1, Mistral). Cost més baix a escala, control total sobre les dades, possibilitat de personalització profunda. Té sentit quan gestiones dades sensibles que no pots enviar a APIs externes, quan el volum és tan alt que les APIs et maten, o quan necessites latència ultrabaixa. El preu: necessites infraestructura GPU, equip que sàpiga gestionar-la i més temps de setup.
Fine-tuning. Entrenes un model (normalment open source) amb les teves dades específiques perquè rendeixi millor al teu domini. És el camí quan el prompting no és suficient — quan necessites que el model entengui terminologia específica de la teva indústria, segueixi un format molt concret, o assoleixi un nivell de precisió que el prompting general no aconsegueix. El preu: necessites dades d'entrenament de qualitat, pipeline de fine-tuning i procés d'avaluació.
La meva recomanació per a startups: comença amb APIs, valida el cas d'ús, mesura costos reals, i migra a open source només quan els números ho justifiquin. He vist massa equips perdre mesos muntant infraestructura de Llama abans de saber si el cas d'ús funciona.
Pas 3: Prompt engineering — el que sembla fàcil i no ho és
Un prompt ben dissenyat pot ser la diferència entre un output inútil i un que funciona en producció. No és màgia, és enginyeria.
System prompts clars. Defineix el rol, el context i les restriccions del model. "Ets un assistent de suport tècnic per a una empresa de SaaS de comptabilitat. Respons només preguntes sobre el producte. Si no saps la resposta, dius que no ho saps." Això no és opcional. Sense system prompt, el model improvisa, i en producció no vols improvisació.
Few-shot examples. Inclou 2-3 exemples de l'input i output esperat directament al prompt. Això ancora el model en el format i estil que necessites. Per a tasques d'extracció i classificació, few-shot millora la precisió dràsticament.
Outputs estructurats. Si necessites que el LLM retorni dades que el teu sistema consumirà, fes servir JSON mode o function calling. No parsegis text lliure amb regex — és fràgil i trenca en producció. GPT-4o i Claude 3.5 Sonnet suporten respostes en JSON estructurat. Fes-ho servir.
Guardrails. Valida sempre l'output del model abans de passar-lo al teu sistema. El JSON és vàlid? Els camps obligatoris hi són? Els valors estan dins de rangs esperats? El LLM no és una funció determinista — de vegades retorna escombraries, i el teu sistema ha de gestionar-ho.
Pas 4: RAG — quan el LLM necessita les teves dades
Retrieval-Augmented Generation és el patró que necessites quan el model ha de respondre preguntes sobre informació que no estava en el seu entrenament: la teva documentació, la teva base de coneixement, les dades dels teus clients.
El concepte és simple: abans d'enviar la pregunta al LLM, busques a la teva base de dades els fragments de text més rellevants i els incloeus al context del prompt. El model genera la resposta basant-se en aquesta informació real.
La implementació té peces mòbils:
Vector databases. Necessites emmagatzemar els teus documents com a embeddings (representacions numèriques del seu significat). Opcions: Pinecone (managed, fàcil de començar), Weaviate (open source, flexible), pgvector (si ja fas servir PostgreSQL — pot ser suficient per començar i t'estalvies un servei extra).
Chunking. No fiques un document de 50 pàgines sencer al context. El divideixes en fragments (chunks) de 200-500 tokens amb overlap. L'estratègia de chunking afecta directament la qualitat de les respostes. Chunks massa petits perden context. Massa grans afegeixen soroll.
Embedding models. Converteixes text en vectors. OpenAI ofereix text-embedding-3-small que funciona bé per a la majoria de casos. Si estàs autoallotjant, hi ha models open source com els de Sentence Transformers que fan la feina.
L'error més comú amb RAG: assumir que funciona bé perquè les primeres proves semblen raonables. Necessites avaluar sistemàticament amb preguntes les respostes de les quals coneixes. Si la retrieval no troba els chunks correctes, el model genera respostes convincents però incorrectes — i això és pitjor que no respondre.
Pas 5: Producció — on moren les demos
Aquí és on la majoria d'integracions de LLMs s'estanquen. Tens un prototip que funciona, però posar-lo davant d'usuaris reals requereix resoldre problemes que la demo ignora.
Latència. GPT-4o tarda 2-5 segons a generar una resposta completa. Per a l'usuari, això és una eternitat mirant un spinner. La solució: streaming. Envia tokens al frontend a mesura que el model els genera. La resposta tarda el mateix, però l'usuari percep que comença instantàniament.
Control de costos. Sense límits, un sol usuari curiós pot generar-te una factura de centenars d'euros en un dia. Implementa: rate limiting per usuari, longitud màxima d'input/output, caching de respostes per a queries repetides, i model routing (fes servir models més barats per a tasques simples, reserva els potents per al complex).
Gestió d'errors. El LLM de vegades falla. Timeout, rate limit del proveïdor, resposta malformada, al·lucinació evident. Necessites fallbacks: reintents amb backoff exponencial, model alternatiu si el primari falla, resposta per defecte quan res funciona. Mai mostris un error críptic d'API a l'usuari.
Avaluació. Com saps si l'output és bo? En software tradicional tens tests amb resultats esperats. Amb LLMs, l'output varia. Necessites: conjunts d'avaluació amb parells input/output esperat, mètriques de qualitat (rellevància, factualitat, format), i revisió humana periòdica. Sense avaluació, voles a cegues.
Monitorització. Registra cada request i response. Latència, tokens consumits, cost, scores de qualitat si els tens. Necessites veure tendències: la qualitat està degradant? Els costos estan pujant? Hi ha patrons d'ús que no esperaves?
Els errors que veig repetir-se
Després de veure desenes d'integracions de LLMs, aquests són els errors que es repeteixen:
- Sense fallback quan el LLM falla. El model no respon i la teva app es penja. Sempre tingues un pla B.
- Sense cap de costos. Un bucle infinit o un usuari abusiu et pot costar milers d'euros en una nit.
- Sense validació de l'output. Fiques la resposta del LLM directament a la teva base de dades o la mostres a l'usuari sense verificar. Així és com acabes amb dades corruptes o amb el teu chatbot dient coses que no hauria.
- Tractar l'output del LLM com a dades fiables. Un LLM no és una base de dades. Genera text probable, no fets verificats. Si el teu flux depèn que l'output sigui factualment correcte, necessites verificació.
- Optimitzar el model abans d'optimitzar el prompt. Abans de pensar en fine-tuning o canviar de model, assegura't que el teu prompt està ben dissenyat. El 80% dels problemes de qualitat es resolen amb millor prompting.
No necessites un equip d'IA — necessites enginyers que sàpiguen integrar IA
El malentès més gran que veig a startups és pensar que necessiten contractar "enginyers d'IA" o "ML engineers" per integrar LLMs al seu producte. Per a la majoria dels casos, el que necessites són enginyers senior que entenguin APIs, sistemes distribuïts, gestió d'errors i disseny de producte — i que a més tinguin experiència pràctica desplegant LLMs en producció.
A Conectia, els enginyers que proporcionem a startups europees han treballat amb integracions reals de LLMs — RAG en producció, pipelines de processament amb GPT-4 i Claude, sistemes d'avaluació d'outputs. No enginyers que van fer un curs de prompt engineering, sinó enginyers que han resolt els problemes de latència, costos i fiabilitat que apareixen quan passes de demo a producció.
La IA al teu producte no és un feature que s'afegeix en un sprint. És una decisió d'arquitectura que necessita enginyeria seriosa. I l'enginyeria seriosa la fan enginyers senior que ja han passat per això.
Estàs integrant IA al teu producte i necessites enginyers que ja hagin resolt aquests problemes? Parla amb un CTO — et connectem amb enginyers senior de LATAM que han desplegat LLMs en producció, no només en demos.
