Integrar un LLM al teu producte (el que ja funciona): què fa un equip sènior els primers 30 dies

El projecte difícil amb un LLM no és el que comença de zero. Començar de zero et dona un repositori buit, cap usuari a qui trencar res i cap factura amb què comparar-te. El projecte difícil és el producte que ja funciona —clients que paguen, un model de dades que algú va triar fa tres anys, una guàrdia, un marge— i on ara algú hi ha de posar un model de llenguatge sense espatllar res de tot això.

He dirigit aquest projecte unes quantes vegades, a totes dues bandes de la taula, i n'he vist l'altra versió: el hackató de dues setmanes que produeix una caixa de xat, la demo que impressiona el consell i la funcionalitat que quatre mesos després algú apaga sense soroll perquè ningú no sap dir si encerta ni què costa. La diferència entre un resultat i l'altre es decideix els primers trenta dies. No la decideix el model, ni el framework. La decideix l'ordre en què un equip sènior fa les coses.

Aquest és aquell ordre, setmana a setmana. Parteix d'un producte amb trànsit real i d'un equip que, mentrestant, ha de continuar entregant tota la resta.

Setmana u: tria un sol flux, mesura'l i construeix el set d'evals amb trànsit real

El primer error és posar «IA» com a abast. L'abast és un flux de treball amb un resultat mesurable: la resposta de suport que a un agent li costa onze minuts, la factura que classifica una persona, la cerca que en un terç de les consultes no torna res d'útil. Un flux que ja porta un número associat, perquè l'única feina de l'LLM és moure aquell número.

Després, abans d'escriure ni un prompt, el set d'evals. Res d'exemples inventats: entre cinquanta i dos-cents casos reals trets dels logs de producció, amb la resposta que va donar una persona competent, anonimitzats allà on les dades ho exigeixin. Aquest artefacte és el que aguanta tot el projecte: amb ell sabràs a la setmana quatre si la cosa funciona, i amb ell sabràs al mes sis si l'actualització silenciosa del proveïdor del model l'ha trencada. Els equips que se salten aquest pas no se salten l'avaluació: la deixen als seus usuaris.

La setmana u acaba també amb un mapa d'integració: en quin punt del codi viurà la crida, quines dades veurà, quines no ha de veure mai i quin servei existent és l'amo del resultat. En un sistema amb tres anys al damunt, aquell mapa sol destapar la primera feina de debò: una dada de context que viu a dos llocs i no coincideix.

Setmana dos: una llesca fina darrere d'un flag, amb recuperació abans que generació

La segona setmana produeix el camí d'extrem a extrem més petit possible, al codi real, darrere d'un feature flag que ningú de fora de l'equip no pot veure. Entrada des del sistema real, una crida al model, sortida escrita on el producte l'espera. Que sigui lleig tant se val. El que compta és que passi per la teva CI, la teva autenticació i els teus logs, perquè és allà on viuen els problemes d'integració, i surten més barats a la setmana dos que a la set.

A la majoria de fluxos de producte el model necessita les teves dades més que enginy, i per això la recuperació va abans que la generació. La llesca fina inclou, doncs, el camí de recuperació —què es busca, on i amb quins permisos—, encara que a la setmana dos sigui una consulta senzilla i a la cinc es converteixi en un índex vectorial. Els permisos no són opcionals: un model a qui es pot preguntar pels registres d'un altre client és una fuita de dades amb una interfície amable.

En tancar la setmana, el set d'evals corre contra la llesca. La puntuació serà dolenta. Per això hi ha el número.

Setmana tres: els evals passen a ser la porta, i el cost té sostre abans de tenir gràfica

La setmana tres és la que separa un equip sènior d'un hackató, perquè la setmana tres és avorrida. L'execució d'evals entra a la CI: cada canvi en un prompt, en una consulta de recuperació o en la versió del model passa el set i torna la puntuació, i baixar del llindar bloqueja el merge. És la pràctica que manté viva una funcionalitat amb LLM més enllà de la primera actualització de model. Un prompt sense eval és una opinió; un prompt amb eval és un test.

La mateixa setmana, el cost. Abans que existeixi una gràfica de despesa existeix un sostre: un pressupost de tokens per petició, un límit diari per tenant i un tallacircuits que torna al comportament antic quan s'hi arriba. Entre un model frontera i un de petit el preu canvia en dos ordres de magnitud, i per a la majoria de fluxos de producte la resposta correcta és el model més barat que passi l'eval, una decisió que només pots prendre si l'eval existeix. Ja he escrit sobre què els passa als equips que tracten els tokens com a mètrica i no com a cost; la versió curta és que la factura arriba abans que el valor si el sostre no hi és primer.

La setmana tres tanca també els modes de fallada, enumerats i provats: el model no respon a temps, torna alguna cosa que el parser no entén, la recuperació no porta res, la petició és una injecció de prompt colada per un camp de client. Cadascun té un comportament definit —tornar enrere, reintentar un cop, rebutjar, registrar— i cadascun és al set d'evals com un cas més.

Setmana quatre: el cinc per cent del trànsit, amb observabilitat i una decisió per escrit

El desplegament és petit a propòsit. El cinc per cent del trànsit, o un segment de clients, o només usuaris interns —el que permeti el perfil de risc—, vigilant tres coses: la puntuació d'evals sobre mostres en viu, el cost per petició contra el sostre i la mètrica humana de la setmana u. Una resposta de suport que costava onze minuts ara n'hauria de costar menys; si no, la funcionalitat no s'amplia, per bé que quedés a la demo.

L'observabilitat d'una funcionalitat amb LLM no és la d'un servei. Has de guardar junts, per petició, el prompt, el context recuperat, la versió del model i la sortida, amb una retenció que respecti la teva política de dades, perquè l'única manera de depurar «la resposta era incorrecta» és veure exactament què va veure el model. Els equips que només registren la sortida es passen el mes dos endevinant.

El mes acaba amb una decisió escrita, una pàgina: què s'ha construït, què diu l'eval, què costa cada mil peticions, què ha fet la mètrica humana i un de tres veredictes: ampliar, iterar o parar. Un veredicte de parar després de trenta dies i un sol flux és un èxit, no un fracàs; és la manera més barata que hi ha de descobrir que aquell flux no era el bo. El fracàs és la funcionalitat que arriba a tots els usuaris perquè ningú no va escriure la pàgina.

L'objecció: trenta dies és lent, i un proveïdor ho va fer en dues setmanes

L'argument en contra més fort és que tot això és més lent que la demo, i la demo és el que vol el consell. És cert, i ho reconec: si l'objectiu és una demo, fes la demo, en una setmana, en un sandbox, i no la connectis mai a producció. Les demos són barates i útils, i jo també en faig.

El pla de trenta dies no és per a la demo. És per a la funcionalitat que encara correrà d'aquí a un any, facturant tokens sobre trànsit real, després de dues actualitzacions de model i que un enginyer hagi marxat. Aquella funcionalitat necessita un set d'evals, un sostre de cost, una recuperació amb permisos i observabilitat per petició, i cap d'aquestes coses no es pot afegir després al preu que costa a les setmanes u a tres. La versió de dues setmanes no és més ràpida: trasllada els trenta dies a després del llançament, i llavors els paguen els usuaris.

Què li demana això a l'equip

Res del que hi ha aquí dalt no requereix un equip de recerca en IA. Requereix enginyers sènior que coneguin les costures del teu codi, i que almenys un d'ells ja hagi portat una funcionalitat amb LLM a producció i en tingui les cicatrius: la injecció pel camp d'adreça, la recuperació que va filtrar dades entre tenants, l'actualització que va canviar el format de la resposta un dimarts. Aquesta combinació escasseja més que cap de les dues meitats per separat, i per això l'encàrrec que més repetim és un o dos enginyers sènior integrats a l'equip del client durant aquells trenta dies, i no un projecte d'IA a part entregat des de fora.

Si tens un producte que funciona i un flux amb un número al damunt, la primera conversa dura trenta minuts, i comença pel set d'evals.