Avaluacions: dels experiments amb IA a una producció fiable

Descobriu com l'avaluació redueix la bretxa entre l'experimentació amb IA i un desplegament fiable i preparat per a producció.

Resum executiu

  • Tot i que els models fundacionals han millorat, el veritable canvi que permet utilitzar-los amb confiança en producció prové d'unes pràctiques d'avaluació rigoroses.

  • Unes avaluacions ben dissenyades ajuden els responsables de producte, els responsables de governança de la IA i els directors de tecnologia a desplegar agents d'IA de manera segura i a gran escala, i converteixen la IA d'una joguina aïllada en un avantatge competitiu.

  • Aquesta confiança s'obté avaluant el comportament dels agents d'IA amb consultes d'usuaris reals, casos límit i situacions específiques del sector que reflecteixin el context real de l'empresa, no amb un índex de referència públic que afirmi que «aquest model és el millor».

  • L'objectiu és justificar aquesta confiança mitjançant resultats mesurables. L'èxit consisteix a definir què és "bo" en termes concrets i mesurables, d'acord amb les necessitats de l'empresa i la seva tolerància al risc, ja sigui quant a exactitud factual, to adequat, velocitat o eficiència de costos.

  • En integrar l'avaluació a tot el sistema (instrumentació, registre, proves A/B i mesures de protecció) i equilibrar el rigor amb l'eficiència, els equips aconseguiran desplegaments més ràpids i robustos.

La majoria de les empreses accepten que els seus empleats experimentin amb ChatGPT o Gemini. Però és menys habitual posar els LLM a treballar en fluxos o entorns d'alt risc.

Sovint hi ha hagut motius justificats: la qualitat era irregular i el risc d'al·lucinacions o comportaments indesitjables superava els possibles beneficis de la tecnologia.

Aquest equilibri entre risc i benefici ha canviat substancialment durant l'últim any. Tot i que una part del canvi es pot atribuir a la millora del rendiment dels models fundacionals, en gran manera es deu al rigor creixent de l'avaluació (o les «avaluacions»). Les avaluacions ens donen, tant a nosaltres com als nostres clients, la confiança necessària per desplegar en qüestió de setmanes agents a gran escala i orientats al client.

Aquesta guia explica els elements fonamentals de les avaluacions i com dissenyar-les, implementar-les i gestionar-les per a casos d'ús en producció.

Fonaments de les avaluacions (1): com és l'èxit?

L'objectiu de l'avaluació no és trobar un model perfecte, sinó generar una confiança justificada que el model es comporta d'acord amb les necessitats de l'empresa, les expectatives dels usuaris i la tolerància al risc de l'organització.

La base de qualsevol estratègia d'avaluació és una pregunta senzilla: Què vol dir que sigui «bo»? La resposta ha de ser concreta. Per a una organització, «bo» pot significar exactitud factual dins de marges estrictes; per a una altra, pot prioritzar la velocitat, l'eficiència de costos o un to de veu distintiu. Totes les restriccions aplicables, des de les dades que es poden utilitzar fins a les obligacions normatives, conformen aquesta definició.

És essencial que allò que considerem 'bo' tingui components que es puguin mesurar realment. Si l'èxit consisteix a oferir orientació financera útil, aquesta utilitat s'ha d'expressar mitjançant atributs: correcció factual, advertiments adequats, raonament personalitzat i límits segurs. Un cop definit allò que és «bo» en termes mesurables, la pregunta següent és com analitzareu i interpretareu els resultats. Actuar a partir d'aquests resultats és el que converteix l'avaluació en un mètode, en lloc d'una simple successió de judicis.

Fonaments de l'avaluació (2): entrades, comportament del model i mètriques

Tot procés d'avaluació es basa en tres pilars interconnectats:

  1. Entrades i índexs de referència: exemples representatius del món real per mesurar el rendiment general i conjunts de dades interns seleccionats per comprovar la viabilitat en el sector.

  2. Comportament del model: com s'invoca el model (generació augmentada per recuperació, resum, recuperació d'informació estructurada i ús d'eines).

  3. Mètriques: com mesureu i interpreteu el rendiment.

Les entrades han de representar el món amb què es trobarà el sistema. La informació més valuosa prové d'exemples reals: consultes dels clients, situacions financeres o casos específics del sector. Només fent proves amb aquests exemples podreu saber si el model entén realment els matisos que necessiten els usuaris i satisfà les necessitats de l'empresa.

El comportament del model —com se li proporcionen les indicacions, com s'orquestren la recuperació o l'ús d'eines i com se li facilita el context— és tan important com el mateix model. Dos models idèntics poden comportar-se de manera molt diferent segons com es despleguin. Per tant, aquesta capa s'ha d'incloure en el disseny de l'avaluació.

Finalment, hi ha les mètriques. Les xifres per si soles rarament expliquen tota la història, però unes mètriques ben triades permeten interpretar el comportament del sistema. La latència, l'exactitud, la seguretat, la coherència, els biaixos, el cost i la satisfacció dels usuaris formen, en conjunt, una imatge multidimensional d'un sistema en producció. La clau és triar mètriques alineades amb els KPI del projecte o l'empresa i que facin visibles les qualitats més importants per als usuaris. Les mètriques més senzilles solen ser més precises i menys costoses, mentre que una mala elecció pot induir els equips a error. Així és com cal plantejar la selecció de mètriques:

Exemples de bones eleccions de mètriques:

  • Bot conversacional d'atenció al client: taxa de resolució en el primer contacte (s'ha resolt el problema de l'usuari sense escalar-lo?), temps mitjà de gestió, puntuació de satisfacció de l'usuari i taxa d'escalat a agents humans.

  • Eina de recerca financera: exactitud de les citacions (% d'afirmacions amb fonts adequades), precisió factual validada amb dades de referència, rellevància de la recuperació (ha trobat els documents correctes?) i coherència del raonament puntuada per experts del sector.

  • Assistent de generació de codi: correcció sintàctica, taxa de proves superades, nombre de vulnerabilitats de seguretat i temps fins a obtenir una solució funcional.

Exemples de males eleccions de mètriques:

  • Utilitzar només la llargada de la resposta com a indicador de qualitat (més llarg ≠ millor).

  • Mesurar la velocitat sense considerar-ne l'impacte en l'exactitud.

  • Fer un seguiment de les puntuacions de confiança del model sense validar-les amb la correcció real.

  • Basar-se només en la perplexitat interna del model sense validar-la de cara als usuaris.

Errors habituals de les mètriques que cal evitar:

  • Mètriques contradictòries: optimitzar alhora la velocitat i l'exhaustivitat sense reconèixer la disjuntiva.

  • Sobreajustament als índexs de referència: assolir un 95 % en el conjunt de proves però fallar en producció perquè els usuaris reals es comporten de manera diferent.

Per a un client de serveis financers sotmès a una regulació estricta, l'exactitud de la seva solució de recerca profunda era primordial. Vam crear conjunts de dades de preguntes i respostes elaborats per experts i els vam combinar amb conjunts generats per eines. Això ens va permetre avaluar la precisió, la capacitat del sistema de triar les eines adequades i recuperar la informació correcta, i obtenir una visió equilibrada de l'exactitud i la qualitat del raonament. La clau era mesurar diverses dimensions: exactitud factual (validació d'experts), qualitat de recuperació (precisió i exhaustivitat dels documents rellevants) i coherència del raonament (avaluació estructurada del flux lògic).

Quan cal utilitzar un LLM com a jutge per avaluar una qualitat plena de matisos

L'ús d'un LLM com a jutge consisteix a fer servir un segon model d'IA com a avaluador, substituint la revisió humana per una puntuació de qualitat automatitzada i escalable. Sovint s'abusa dels LLM com a jutges quan mètriques més senzilles ja ofereixen l'exactitud necessària. Pot ser útil quan les comprovacions deterministes no poden captar la qualitat, per exemple si la mètrica és semàntica (utilitat, fonamentació, qualitat del raonament, to o interpretació de polítiques) i no és possible aplicar una puntuació determinista. Potser necessitareu comentaris escalables sobre moltes variants d'indicacions i models, així com definir una rúbrica clara i un esquema de resultats estructurats. Perquè us funcioni, seguiu aquests passos:

  • Definiu explícitament les dimensions de la rúbrica: correcció, fonamentació, compliment de polítiques, aplicabilitat i to.

  • Utilitzeu resultats estructurats (esquema JSON) per a les respostes del jutge.

  • Recolliu tant les puntuacions binàries d'acceptació com el text de diagnòstic per analitzar els errors.

  • Calibreu els resultats del jutge amb mostres etiquetades per persones en cada cicle de publicació.

  • Utilitzeu dos jutges o comprovacions periòdiques de consens en sectors d'alt risc.

  • Feu un seguiment al llarg del temps de la deriva del jutge i de la taxa de desacord.

No us perdeu entre índexs de referència

Un conjunt de dades de referència és un conjunt fix i seleccionat d'exemples de prova amb respostes conegudes que permet avaluar els models de manera coherent i comparar equitativament els resultats entre versions. Normalment inclou entrades (p. ex., consultes d'usuaris), resultats esperats o judicis de referència i criteris o etiquetes d'avaluació per puntuar. Les proves públiques de referència s'utilitzen per comparar el rendiment dels models més avançats i poden servir com a consulta inicial a l'hora de dissenyar el sistema i determinar quin model pot ser un bon candidat.

Tanmateix, per al vostre sistema no podeu confiar en aquests índexs com a indicador del rendiment en el context de l'empresa, perquè presenten problemes coneguts:

  • Contaminació: és possible que els models s'hagin entrenat amb les dades de referència; avaluar-los amb el mateix conjunt seria com puntuar-los amb les respostes al davant.

  • Saturació: tots els models principals ja assoleixen puntuacions màximes; per tant, la millora o degradació del rendiment queda limitada a pocs punts percentuals i sovint entra dins de la variabilitat natural dels resultats.

  • Abast limitat: les dades de referència no reflecteixen les tasques reals, ja que estan molt seleccionades i depurades. Algunes fins i tot les generen LLM i no reflecteixen la complexitat ni els casos límit de les vostres dades (errors tipogràfics, expressions inusuals o imatges amb soroll).

Exemple: tutor de matemàtiques amb IA per ajudar estudiants

Un estudiant demana ajuda a l'aplicació per resoldre problemes enunciats.

Exemple d'índex de referència públic que podeu utilitzar: GSM8K (raonament matemàtic de primària).

  • Conjunt opcional més difícil: MATH.

Per què és útil aquest índex de referència:

  • Permet comparar ràpidament quin model és millor en raonament matemàtic general.

  • És un bon primer filtre abans d'invertir en avaluacions completes del producte.

Per què continueu necessitant un conjunt de dades propi:

La vostra aplicació té requisits que GSM8K no avalua:

  • La redacció i l'ordre dels temes del vostre currículum.

  • L'estil d'explicació adequat per al grup d'edat.

  • Com gestionar preguntes ambigües o plenes d'errors tipogràfics dels estudiants.

  • Regles de la política (p. ex., quan donar pistes o respostes completes).

Una validació eficaç depèn de crear índexs d'avaluació específics per a l'aplicació. Aquests conjunts de dades han de provenir d'interaccions reals, casos límit habituals i errors plausibles. Aquesta tasca pot ser difícil quan s'implementa un producte o procés nou. Tanmateix, en la majoria dels casos és possible recollir dades d'un producte existent o fer-ho al més aviat possible, fins i tot durant una fase inicial de proves. Després de desenvolupar l'aplicació, aquests índexs han d'evolucionar amb el producte i fer-se més complets i representatius amb el temps.

Cas pràctic: creació d'un índex de referència personalitzat per a un assistent de banca minorista

Un bot conversacional bancari respon preguntes sobre pressupostos, despeses i transaccions. Els índexs públics de preguntes i respostes o de text a SQL no recollien riscos bancaris essencials com la injecció SQL, la filtració de dades o la conservació del context entre diversos torns. Vam crear un índex de referència personalitzat que reflecteix el procés d'agents d'aquest producte.

Components de l'índex de referència personalitzat d'aquest codi base:

  • Conjunt de proves d'equip vermell amb indicacions malicioses per a injecció SQL, extracció d'informació d'identificació personal, anul·lació d'indicacions i filtracions entre sessions.

  • Tolerància zero en seguretat: cal rebutjar qualsevol injecció SQL, extracció d'informació d'identificació personal o filtració entre sessions.

  • Exactitud en la conservació del context: les consultes reformulades han de preservar la intenció i les entitats de l'usuari.

Conclusió principal: tracteu la creació de l'índex de referència com una funcionalitat del producte. L'entorn d'execució actual demostra que l'avaluació integral està connectada, però cal ampliar-ne la cobertura i la mida de les mostres perquè reflecteixin els riscos bancaris reals (atacs amb diverses intencions, elusió de les mesures de protecció i consultes dependents del context). L'índex de referència s'ha d'ampliar alhora que s'incorporen agents i mesures de protecció nous.

Avaluacions per trobar l'equilibri adequat: assolir el rendiment desitjat amb el model més petit possible

La connexió entre l'índex de referència específic de l'aplicació i la selecció del model és essencial. L'índex no només mostra si una solució funciona, sinó també quina combinació de mida del model i tècniques de postentrenament ofereix el rendiment necessari amb la millor relació cost-eficàcia. Les millores més potents dels models preentrenats (el «PT» de ChatGPT) no provenen de tornar-los a entrenar, sinó de mètodes de "postentrenament".

Aquests mètodes se centren a definir a quina informació pot accedir el model, com s'estructura i com es guia i s'orquestra el model durant la inferència. Tècniques de postentrenament com ara:

  • Indicacions de cadena de pensament i assignació dinàmica de recursos de càlcul (dedicar més raonament als problemes més difícils).

  • Autoconsistència, en què es generen diversos resultats i se selecciona el millor.

  • Construcció i orquestració del context, com ara la generació augmentada per recuperació (RAG), els exemples amb pocs exemples i els fluxos de treball amb agents.

  • Ús d'eines i accés a coneixement extern, que permeten al model actuar més enllà dels seus paràmetres interns.

  • Estratègies de representació i emmagatzematge del coneixement, dissenyades per recuperar informació i raonar eficientment sobre dades estructurades i no estructurades.

Tot i que aquestes tècniques de postentrenament poden millorar considerablement el rendiment del sistema, també comporten contrapartides. Cada capa addicional d'orquestració, recuperació o raonament augmenta la complexitat del sistema, el temps d'inferència i el cost operatiu. Tanmateix, quan s'aplica amb criteri, la combinació adequada de tècniques de postentrenament sovint permet utilitzar models més petits, ràpids i barats sense deixar de complir els requisits de rendiment. En lloc d'augmentar la mida del model, el rendiment s'assoleix amb un millor disseny del sistema.

Trobar aquest equilibri depèn necessàriament de cada aplicació i s'ha de basar en les seves avaluacions específiques per determinar la combinació òptima de tècniques. Aquestes avaluacions permeten identificar el punt en què més orquestració ja no aporta millores significatives, perquè els equips puguin triar el nivell mínim de complexitat de postentrenament necessari per assolir el rendiment objectiu.

Avanceu de pressa, però avalueu amb criteri

Una solució d'IA s'ha de concebre com el sistema complet: bases de dades, API, interfícies d'usuari, capes d'orquestració, infraestructura de supervisió i molt més. Per tant, l'avaluació ha d'abastar tota la pila tecnològica. Heu de supervisar les parts clau del sistema per mantenir la visibilitat dels possibles problemes i accelerar-ne responsablement el desenvolupament.

Supervisar les parts clau del sistema implica:

  • Instrumentar els processos per obtenir resultats mesurables.

  • Registrar els experiments per observar l'efecte de cada ajust.

  • Fer comparacions A/B senzilles abans de desplegar canvis importants per detectar possibles regressions.

La iteració basada en dades escurça el camí del prototip a la producció sense deixar punts cecs. El registre i la supervisió també són importants per entendre l'ús real de l'aplicació. Aquest és un exemple per garantir l'observabilitat:

  • Pas 1: la sol·licitud de l'usuari entra amb request_id, user_segment i intent.

  • Pas 2: la traça registra la versió del model, la versió de la indicació, els documents recuperats i les crides a eines.

  • Pas 3: el LLM jutge puntua la resposta (correcció, fonamentació i policy_risk).

  • Pas 4: el motor de regles avalua els llindars.

  • Pas 5: si s'incompleix un llindar, activa una alerta i deriva el cas a l'opció alternativa o a una revisió humana.

  • Pas 6: l'error s'afegeix a la cua de triatge i després a la llista pendent de l'índex de referència.

Traça de Langfuse d'un assistent sobre la política de devolucions, que mostra el flux de la sol·licitud, les eines de recuperació i regles, l'avaluació de la qualitat de la resposta, el control de qualitat, les metadades de puntuació i la resposta generada.

Els usuaris reals rarament es comporten exactament com esperen els dissenyadors. Alguns entendran malament les instruccions. Altres buscaran expressament els punts febles. Aquests casos límit no són anomalies, sinó senyals molt valuosos. Un procés d'avaluació ben implementat els recull, els analitza i els incorpora a proves futures. Només es pot iterar de pressa i sense punts cecs quan l'avaluació està integrada en el sistema, no afegida després del desenvolupament.

Recomanem integrar mesures de protecció i supervisió des del primer dia:

  • Feu un seguiment periòdic de les mètriques i regressions del model mitjançant l'índex de referència específic de l'aplicació.

  • Recolliu i reviseu els casos límit o les entrades adversàries, i afegiu-los al conjunt de dades de referència específic de l'aplicació.

  • Assegureu-vos que aquestes mètriques d'avaluació estiguin alineades amb els KPI principals.

  • Poseu a prova periòdicament el conjunt de dades i l'índex de referència per assegurar-vos que no ignoreu riscos nous ni esteu subjectes a biaixos.

  • Implementeu alertes automàtiques per al deteriorament de les mètriques (p. ex., si l'exactitud baixa del 85 %, activeu una revisió).

  • Manteniu un procés de revisió humana per a decisions d'alt risc (assessorament jurídic, orientació mèdica i operacions financeres).

Avalueu responsablement: energia, costos i compliment normatiu

Cada execució d'un índex de referència consumeix recursos informàtics i energia. Cada experiment redundant augmenta els costos. Una avaluació responsable ha d'equilibrar el rigor amb l'eficiència.

Hi ha diverses mesures pràctiques per evitar que es disparin el consum d'energia i els costos:

  • Utilitzeu models més petits quan sigui possible: executeu els experiments inicials amb models més barats i augmenteu-ne l'escala només després de validar l'enfocament.

  • Emmagatzemeu a la memòria cau les indicacions i les crides a l'API.

  • Planifiqueu les tasques tenint en compte l'energia (processament per lots, instàncies puntuals i prioritat flexible).

  • Feu un seguiment de l'ús de recursos informàtics juntament amb el rendiment.

Igualment, estigueu atents a la nova normativa sobre IA. Fins i tot quan no hi ha una llei específica, continuen sent aplicables els marcs existents i les mesures necessàries, com ara:

Protecció de dades:

  • Assegureu-vos que els conjunts de dades de referència no continguin informació d'identificació personal sense el consentiment adequat.

  • Implementeu polítiques de conservació de dades per a les consultes registrades.

  • Oferiu mecanismes per sol·licitar la supressió de dades.

Igualtat i biaixos:

  • Comproveu el rendiment en diferents grups demogràfics.

  • Incloeu una representació diversa en la creació de l'índex de referència.

Drets humans i transparència:

  • Documenteu clarament per als usuaris les limitacions del model.

  • Oferiu explicacions sobre les decisions d'alt risc.

  • Habiliteu la supervisió humana per a les aplicacions crítiques.

Conclusió: de l'avaluació a l'evolució

L'avaluació no és un esdeveniment puntual, sinó un sistema en evolució. En un àmbit que avança ràpidament, l'avantatge rau en la rapidesa amb què podeu provar, aprendre i adaptar-vos per desplegar models i solucions noves amb més eficàcia.

En integrar l'avaluació com una activitat essencial d'enginyeria i gestió de producte, els equips poden innovar més de pressa i amb més seguretat. Comenceu definint què és bo en el context de la vostra aplicació d'IA, configureu una plataforma d'avaluació i feu-la evolucionar fins a disposar d'un índex de referència específic de l'aplicació que, en cada iteració, us doni confiança que està preparada per a producció.

Autors

Fatemeh Tahavori i Romain Bourboulou