Com integrar LLMs al teu producte: una guia tècnica per a startups
Tots els fundadors volen afegir "IA" al seu producte. Ho entenc. Els inversors ho pregunten, la competència ho anuncia, i la demo que vas muntar un diumenge amb l'API d'OpenAI semblava màgia.
El problema és que les demos sempre semblen màgia. Demanes al model que et resumeixi un text, et torna una cosa coherent i penses "això ho tenim en producció en dues setmanes". Passen les dues setmanes. I dues més. I al cap de tres mesos encara lluites 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 guió que segueixo quan un equip ha d'integrar LLMs al seu producte de debò — 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, imports de factura).
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ó, o bé sobredimensionaràs la solució o bé triaràs el model equivocat. Totes dues coses 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). La via més ràpida per començar. Crides GPT-4o, Claude 3.5 Sonnet o Gemini, pagues per token i no gestiones cap 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 dessagnen, o quan necessites latència ultrabaixa. El preu: necessites infraestructura GPU, un equip que la sàpiga gestionar i més temps de posada en marxa.
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, un pipeline de fine-tuning i un 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 ni tan sols 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 l'output esperats directament al prompt. Això ancora el model al format i a l'estil que necessites. Per a tasques d'extracció i classificació, el few-shot millora dràsticament la precisió.
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 es trenca en producció. GPT-4o i Claude 3.5 Sonnet admeten respostes en JSON estructurat. Fes-les 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 era a les seves dades d'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 inclous al context del prompt. El model genera la resposta a partir d'aquesta informació real.
La implementació, però, té més peces del que sembla:
Vector databases. Necessites emmagatzemar els teus documents com a embeddings (representacions numèriques del seu significat). Opcions: Pinecone (servei gestionat, fàcil per 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. Un document de 50 pàgines no el fiques al context d'una tirada. El divideixes en fragments (chunks) de 200-500 tokens amb solapament. L'estratègia de chunking afecta directament la qualitat de les respostes. Els chunks massa petits perden context. Els 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 t'ho allotges tu mateix, models open source com els de Sentence Transformers fan la feina.
L'error més comú amb RAG: donar per fet que funciona bé perquè les primeres proves semblen raonables. Has d'avaluar sistemàticament amb preguntes de les quals ja saps la resposta. Si el retrieval no troba els chunks correctes, el model genera respostes que sonen convincents però són 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 triga 2-5 segons a generar una resposta completa. Per a l'usuari, això és una eternitat mirant un spinner. La solució: streaming. Envia els tokens al frontend a mesura que el model els genera. La resposta triga el mateix, però l'usuari percep que comença a l'instant.
Control de costos. Sense límits, un sol usuari curiós et pot fer 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 consultes repetides, i model routing (fes servir models més barats per a les tasques simples i reserva els potents per a la feina complexa).
Gestió d'errors. El LLM de tant en tant falla. Timeout, rate limit del proveïdor, resposta malformada, al·lucinació evident. Necessites fallbacks: reintents amb backoff exponencial, un model alternatiu si el primari falla, una resposta per defecte quan res no funciona. No mostris mai a l'usuari un error críptic de l'API.
Avaluació. Com saps si l'output és bo? En el software tradicional tens tests amb resultats esperats. Amb els LLMs, l'output varia. Necessites: conjunts d'avaluació amb parells d'input/output esperats, mètriques de qualitat (rellevància, factualitat, format) i revisió humana periòdica. Sense avaluació, vas a cegues.
Monitorització. Registra cada request i cada response. Latència, tokens consumits, cost, scores de qualitat si els tens. Necessites veure-hi tendències: la qualitat es degrada? Els costos s'enfilen? Hi ha patrons d'ús que no t'esperaves?
Els errors que veig una vegada i una altra
Després de veure desenes d'integracions de LLMs, aquests són els errors que no paren de repetir-se:
- Cap fallback quan el LLM falla. El model no respon i la teva app es queda penjada. Tingues sempre un pla B.
- Cap límit de despesa. Un bucle infinit o un usuari abusiu et poden costar milers d'euros d'un dia per l'altre.
- Cap validació de l'output. Fiques la resposta del LLM directament a la base de dades o la mostres a l'usuari sense comprovar-la. Així és com acabes amb dades corruptes o amb un chatbot que diu coses que no hauria de dir.
- 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 en canviar de model, assegura't que el prompt està ben dissenyat. Per la meva experiència, la majoria de problemes de qualitat es resolen amb un prompt més ben treballat.
No necessites un equip d'IA — necessites enginyers que sàpiguen integrar IA
El malentès més gran que veig a les startups és pensar que han de contractar "enginyers d'IA" o "ML engineers" per integrar LLMs al seu producte. En la majoria de casos, el que necessites són enginyers sèniors que entenguin d'APIs, de sistemes distribuïts, de gestió d'errors i de disseny de producte — i que a més tinguin experiència pràctica desplegant LLMs en producció.
A Conectia, els enginyers que posem a disposició de les startups europees han treballat en integracions reals de LLMs — RAG en producció, pipelines de processament amb GPT-4 i Claude, sistemes d'avaluació d'outputs. No enginyers que han fet un curs de prompt engineering, sinó enginyers que han resolt els problemes de latència, de costos i de fiabilitat que apareixen quan passes de la demo a la producció.
La IA al teu producte no és una funcionalitat que s'afegeixi en un sprint. És una decisió d'arquitectura que demana enginyeria seriosa. I l'enginyeria seriosa la fan enginyers sèniors que ja hi han passat.
Estàs integrant IA al teu producte i necessites enginyers que ja hagin resolt aquests problemes? Parla amb un CTO — et connectem amb enginyers sèniors de LATAM que han desplegat LLMs en producció, no només en demos.
