Jev: el model que decideix en lloc d'escriure. Anàlisi a fons i deu casos d'ús

El 15 de setembre, TypeSafe AI va publicar Jev. En tres dies, la demanda n'havia fet caure l'API una estona, LangChain n'havia tret una integració i TechCrunch titulava que un nou tipus de model entusiasmava els desenvolupadors. Al darrere hi ha Diogo Almeida, que ve d'OpenAI i figura —segons la mateixa TypeSafe— entre els coinventors de l'RLHF, la tècnica que va convertir els models de llenguatge en ChatGPT.

Jev no és un model de llenguatge com els altres: no escriu ni una paraula. Rep un estat —un tiquet, un expedient, la traça d'un agent— i una bateria de preguntes tancades, i retorna decisions tipades amb una probabilitat per a cada opció. Segons TypeSafe, en 70-500 mil·lisegons i cobrant només l'entrada.

Abans de continuar, el que preguntaria qualsevol CTO: Jev va sortir fa quatre dies i nosaltres encara no el tenim en producció. Aquesta peça surt de llegir sencera la seva documentació tècnica, els seus cookbooks, el que n'han explicat els primers que l'han provat i, sobretot, la pàgina on TypeSafe enumera les fallades conegudes de la versió 1.13. És la pàgina més útil del llançament i la que menys s'està citant.

La nostra lectura cap en una frase: la major part del que les empreses demanen avui a un LLM dins d'una automatització no és escriure, és decidir, i per a aquesta part Jev canvia els números. Però el que canvia de debò no és el que diuen els titulars —la velocitat i el preu—, sinó que cada resposta arriba amb una probabilitat calibrada sobre la qual es pot recolzar un llindar. Això és el que converteix una classificació en una decisió que es pot automatitzar.

Què és exactament Jev, i què no és

La interfície és tota la idea. En lloc d'un prompt i un text de tornada, s'envia un estat —text, un objecte JSON o una llista— i unes preguntes de tres tipus, que TypeSafe anomena primitives:

Totes les preguntes d'una crida veuen el mateix estat i s'avaluen en paral·lel i per separat: la resposta d'una no contamina l'altra. Afegir preguntes gairebé no canvia el temps de resposta, i agrupar-les surt molt més barat que fer-les d'una en una. En un dels seus cookbooks, tretze preguntes en una sola crida van ser unes deu vegades més ràpides i més d'onze vegades més barates que tretze crides soltes, amb les mateixes respostes. D'aquí surt el patró que més repeteix la seva documentació: pregunteu tot el que el codi pugui necessitar, encara que només serveixi per a alguns casos, i que el codi decideixi quines respostes fa servir.

L'entrenament és l'altra meitat. Els LLM de xat s'afinen per produir el text que prefereix un avaluador humà (RLHF) o per encertar problemes que es poden verificar de manera automàtica (RLVR). TypeSafe entrena Jev amb el que anomena Reinforcement Learning for Calibrated Decisions (RLCD), l'objectiu del qual és que les probabilitats siguin honestes: si el model diu 0,8 sobre un conjunt de casos, al voltant del 80% haurien de ser correctes. La mateixa documentació hi afegeix el matís important: el calibratge es mesura sobre grups de prediccions i no garanteix que una resposta concreta sigui correcta.

I el que no és. No escriu respostes, no genera codi, no explica el seu raonament i no és un agent: no decideix el pas següent de res, contesta preguntes tancades que li fa el codi. El nom de la categoria, System One, ve del sistema 1 de Kahneman: judicis ràpids i intuïtius, dels que una persona experta fa en un segon si té al davant el context adequat. Tot el que requereixi raonar en diversos passos continua sent terreny d'un LLM.

El que canvia de debò és la probabilitat, no la velocitat

Els titulars es van quedar amb les xifres de 40 a 200 vegades més ràpid i centenars de vegades més barat. Importen, però no són el més important.

A la peça sobre la ruta d'excepció explicàvem per què la confiança que declara un LLM és un mal disparador per decidir quins casos van a una persona: l'informe tècnic de GPT-4 va mostrar que el post-entrenament empitjorava el calibratge del model. RLCD apunta exactament a aquest problema. La taula comparativa de l'anunci de TypeSafe ho resumeix millor que nosaltres: si un model pot fer una tasca el 95% de les vegades però no diu quan és al 5%, no la pot automatitzar.

Els primers testimonis van en la mateixa direcció. Nikhil Mudholkar, CTO de Bryo AI, va comparar Jev amb Gemini classificant correus de negoci: Gemini va encertar una mica més, però costava entre deu i vint vegades més. El que li va interessar, segons va explicar a TechCrunch, va ser la confiança: és l'únic que retorna una probabilitat real. Armin Ronacher, CTO d'Earendil, ho va formular a l'inrevés: Jev «delega una mica el problema de l'al·lucinació a l'usuari». Si la resposta arriba amb un 50%, és tirar una moneda a l'aire i la descartes; si arriba amb un 95%, pots actuar.

Aquesta frase és la clau pràctica: el llindar passa a ser una decisió vostra, explícita, que es pot mesurar i ajustar. I l'altra meitat de l'argument de la ruta d'excepció continua dempeus, perquè cap model no la resol: la probabilitat mesura el dubte del model, no el que us hi jugueu en el cas. La documentació de TypeSafe ho aplica en els seus propis exemples, amb llindars diferents per consultar un saldo i per aprovar una transferència. Qui decideix quanta seguretat exigeix cada acció és el codi.

Així es veu un triatge amb encaminament per confiança a l'SDK de Python. Les instruccions van en català a propòsit, perquè és el primer que cal mesurar:

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient(model="jev-1.13.0")  # versió fixada: els llindars es calibren contra aquesta

r = client.system_one(
    state={"ticket": ticket, "client": {"pla": pla, "antiguitat": antiguitat}},
    questions={
        "area": Choice(
            instructions="Quin equip ha de resoldre `ticket`?",
            criteria={
                "facturacio": "Cobraments, factures i devolucions",
                "tecnic": "Errors, integracions i caigudes",
                "compte": "Accessos, usuaris i permisos",
                "altre": "Res del que hi ha més amunt",
            },
        ),
        "demana_reemborsament": Noul(
            instructions="El client demana que se li retornin diners?",
        ),
        "risc_baixa": Score(
            instructions="Quin risc de baixa expressa `ticket`?",
            criteria=[
                "Cap",
                "Queixa puntual",
                "Esmenta que vol marxar o es compara amb un altre proveïdor",
            ],
        ),
    },
)

area = r.answers["area"]
if area.confidence < 0.6:
    a_safata_humana(ticket)              # la ruta d'excepció, no un error
elif r.answers["demana_reemborsament"].noul > 0.9:
    obrir_flux_reemborsament(ticket)     # import i política es comproven en codi
else:
    encaminar(area.choice, prioritat=r.answers["risc_baixa"].score)

Tres detalls de l'exemple són decisions de disseny, no d'estil. L'opció altre, perquè el model no hagi de forçar una resposta. La versió fixada, perquè l'àlies jev-latest es mou quan TypeSafe publica una versió nova i els llindars es calibren contra un model concret. I el llindar de 0,6, que és un punt de partida i no una recomanació: el vostre surt de mesurar.

La lletra petita, llegida sencera

TypeSafe mereix un reconeixement poc habitual: el seu anunci inclou un apartat de matisos darrere de cada xifra, i la documentació té una pàgina de fallades conegudes. Llegits sencers, deixen un mapa força clar d'on no convé fer-lo servir, o no sense precaucions.

Dues coses més que convé saber, encara que no canviïn el disseny. TypeSafe no n'explica l'arquitectura, i observadors externs citats per TechCrunch sospiten que està construït sobre un LLM de pesos oberts. I diu que entrena exclusivament amb dades sintètiques que produeix el seu propi equip.

Res de tot això no és un retret. Que un laboratori publiqui el dia del llançament la llista de les seves pròpies fallades és més honest que gairebé tot el que es veu en aquest mercat. Però cal llegir-la abans de dissenyar, no després del primer incident.

Deu casos d'ús on aporta moltíssim valor

No hem triat els casos perquè siguin vistosos, sinó per quatre criteris: que la tasca sigui decidir i no escriure; que hi hagi volum o pressa, que és on el cost i la latència d'un LLM fan mal; que la probabilitat serveixi per a alguna cosa concreta; i que existeixi, o es pugui dissenyar, una ruta per als casos dubtosos. Van ordenats del més immediat al més ambiciós.

1 · Triatge de suport i de safates d'entrada

El problema. Cada correu o tiquet passa avui per un LLM que retorna un JSON amb l'àrea, la urgència i el to, o per una persona que el llegeix i el reenvia. El primer és car i lent a escala; el segon, encara més.

Com es munta. Un Choice per a l'àrea, amb una opció «altre»; uns Nouls per a reemborsament, urgència o petició de parlar amb una persona; un Score per a frustració o risc de baixa. Tot en una crida, i el codi encamina. És l'exemple de més amunt.

Per què aquí. És la tasca que més s'assembla al que Jev fa millor, i el volum converteix la diferència de cost i de latència en diners. El cas de Bryo AI és exactament aquest.

El parany. La lectura literal. «Demana un reemborsament» no és el mateix que «està descontent i pregunta quines opcions té», i Jev contesta el que hi ha escrit. Els casos frontera van als criteris, amb exemples del que hi entra i del que no.

2 · Rutes d'excepció amb llindar: sinistres, factures, reclamacions

El problema. El procés automatitzat resol la majoria dels casos i ha de decidir quins van a una persona. Amb un LLM, aquesta decisió es recolza en una confiança que no està calibrada.

Com es munta. Preguntes atòmiques sobre l'expedient —s'hi aplica la cobertura?, falta documentació?, hi ha alguna cosa que mereixi revisió?—, combinades en codi en tres sortides: pagar, denegar o persona. Un dels cookbooks de TypeSafe construeix precisament un triatge de reclamacions amb aquestes tres sortides.

Per què aquí. És el cas en què la probabilitat calibrada val més que la velocitat. Un altre cookbook, de moderació, ho quantifica: si s'exigeix com a mínim 0,6 a l'opció més probable, el que no hi arriba passa a revisió humana, i la coincidència entre execucions repetides puja del 90,8% al 99,2% amb el 74,2% de les respostes automatitzades. És la corba de cobertura davant d'error de la ruta d'excepció, amb els números a la vista. Amb una reserva: l'experiment repeteix quinze vegades un únic missatge dubtós, de manera que ensenya el mecanisme, no el rendiment que tindreu.

El parany. Els imports, les franquícies i els terminis. Jev no compara quantitats ni dates de manera fiable: la cobertura la jutja Jev i l'aritmètica es fa en codi. I el llindar es decideix per conseqüència, no per comoditat.

3 · Guardrails abans que l'agent actuï

El problema. Un agent amb eines pot rebre males instruccions, per error o perquè algú les hi ha colat. Revisar cada crida amb un altre LLM és car i lent, i gairebé ningú no ho fa.

Com es munta. Abans d'executar una crida a una eina, un grapat de Nouls: és destructiva?, fa alguna cosa que l'usuari no ha demanat?, envia dades a fora? LangChain ja ho empaqueta com a middleware experimental que bloqueja la crida abans que s'executi.

r = client.system_one(
    state={"peticio": peticio_usuari, "crida": {"eina": "bash", "ordre": ordre}},
    questions={
        "destructiva": Noul(instructions="`crida.ordre` esborra o sobreescriu dades de manera irreversible?"),
        "fora_de_encarrec": Noul(instructions="`crida.ordre` fa alguna cosa que `peticio` no ha demanat?"),
        "treu_dades": Noul(instructions="`crida.ordre` envia dades o credencials a una destinació externa?"),
    },
)

risc = max(r.answers[k].noul for k in ("destructiva", "fora_de_encarrec", "treu_dades"))
if risc > 0.3:
    demanar_confirmacio(ordre)   # i la llista de permisos continua manant sobre el que s'executa

Per què aquí. Perquè el cost i la latència permeten revisar totes les crides, no una mostra. Pranit Sharma, enginyer de Vercel, va explicar a TechCrunch que van substituir per Jev l'LLM que revisava la seguretat de les ordres i van obtenir resultats entre cinc i divuit vegades més ràpids, i amb més encert.

El parany. El més seriós de la llista: la mateixa documentació de Jev adverteix que un text escrit per manipular-lo en pot moure la resposta. Un guardrail probabilístic apuja el cost de l'atac, però no autoritza res. El que l'agent pot executar ho continua decidint una llista de permisos determinista, com defensàvem a la peça sobre injecció de prompts. Per això el llindar de l'exemple és baix: aquí surt més barat demanar una confirmació de més que executar-ne una de menys.

4 · Encaminament de models

El problema. Enviar totes les peticions al model més potent és car; enviar-les totes al barat empitjora les difícils. I un encaminador fet amb un LLM afegeix la latència i el cost que es volien estalviar.

Com es munta. Un Choice sobre la petició —model ràpid o potent, amb criteris del que va a cadascun— i un Score de dificultat o de risc; el codi tria el model. LangChain també ofereix un middleware experimental d'encaminament sobre Jev, i Ronacher l'assenyalava com un dels usos més útils.

Per què aquí. És la palanca de cost més directa en qualsevol sistema amb volum, i ataca de front el que explicàvem sobre per què la factura creix entre el pilot i l'escala.

El parany. L'error de l'encaminador és silenciós: una tasca difícil enviada al model barat no dona error, dona una resposta pitjor. Cal mostrejar el que l'encaminador va enviar al model barat i revisar-ho, com qualsevol altra ruta automàtica.

5 · Quin context i quina skill carrega l'agent

El problema. Els agents carreguen massa: totes les skills del catàleg, tots els fragments que va retornar la cerca. Més context no és més intel·ligència; és més cost i més distracció.

Com es munta. Una crida que puntua cada skill o cada fragment davant de la petició, i un Noul que pregunta si en cal algun. En un dels cookbooks, amb un catàleg de 182 skills i 488 peticions a Claude Haiku 4.5, suggerir com a molt una skill amb Jev va fer baixar les càrregues equivocades del 16,8% al 7,3% i les innecessàries del 9,8% al 4,0%. Un altre filtra els fragments recuperats abans que arribin al model que respon, i descarta els que amaguen instruccions.

Per què aquí. Perquè és enginyeria de context automatitzada: decidir què entra a la finestra és una decisió, i ara és barata.

El parany. Descartar el fragment que contenia la resposta no genera cap avís. El filtre necessita el seu propi conjunt d'avaluació.

6 · Reordenar els resultats d'un RAG

El problema. La cerca per embeddings o per paraules clau troba el document correcte, però poques vegades el posa el primer.

Com es munta. Una pregunta per cada parell consulta-candidat sobre una llista curta, i es reordena per la puntuació.

Per què aquí. Millora el que veu el model que respon sense tocar-lo. Al cookbook de TypeSafe sobre consultes jurídiques, amb llistes curtes de trenta passatges en què el correcte sempre hi era, el passatge correcte va quedar el primer en el 18% de les consultes davant del 5% de la cerca sola, i entre els deu primers en el 62% davant del 38%.

El parany. Són quaranta consultes: serveixen per veure l'ordre de magnitud, no per prometre aquest resultat. I el cost creix amb la mida de la llista: aquelles quaranta consultes van ser 1.200 crides.

7 · Verificar el que escriu un altre LLM

El problema. Els LLM fallen de maneres conegudes: citen malament, s'inventen referències, criden una eina amb l'argument equivocat. Revisar cada sortida amb un altre LLM duplica el cost; revisar-la amb persones no escala.

Com es munta. Preguntes atòmiques sobre la sortida i la seva font: el passatge citat avala l'afirmació?, la cita existeix al document?, l'argument de la crida coincideix amb el que va demanar l'usuari? La documentació descompon la verificació d'una traça d'eines en nou preguntes de sí o no, una per cada cosa que pot fallar.

Per què aquí. Perquè converteix la verificació en una cosa que es fa sobre el cent per cent de les sortides, i les respostes queden registrades com a dades: just el que necessita el mostreig de l'error silenciós que descrivíem a la ruta d'excepció.

El parany. Comprovar que una cita és al document és un judici; comprovar que un número quadra és aritmètica. El segon, un altre cop, en codi.

8 · Extracció: l'LLM proposa, Jev tria, el codi calcula

El problema. Extreure camps de factures, contractes o formularis amb un LLM funciona fins que s'inventa un valor que no era al document.

Com es munta. Jev no extreu escrivint, perquè no escriu: tria. Una expressió regular o un LLM proposen els candidats —imports, dates, NIF, correus— i Jev tria quin correspon al camp demanat, amb una opció «no hi consta». Les dates es demanen per parts, com a opcions tancades, i el codi les munta. Un dels cookbooks porta un detall molt nostre: preguntar amb un Noul si el document escriu «1.315,50 €» o «1,315.50», perquè el codi que normalitza l'import ho necessita saber.

Per què aquí. Perquè el valor extret és literal: existeix al document. En comptes a pagar, aquesta és la diferència entre un apunt erroni i una excepció visible. A més, TypeSafe publica una cascada en què un model petit extreu, Jev verifica camp per camp i només es paga el model gran quan la verificació dubta.

El parany. Creure que la part difícil la fa Jev. La fa el disseny: quins candidats es proposen i què fa el codi amb cada resposta.

9 · Conciliar entitats al CRM i a l'ERP

El problema. El mateix client apareix tres vegades amb noms diferents; el mateix proveïdor, amb dues adreces. Qualsevol agent que llegeixi aquests sistemes n'hereta el desordre.

Com es munta. Per a cada parell candidat, un Score amb tres nivells que són les tres coses que es poden fer —fusionar, deixar separats o passar-ho a una persona— i uns Nouls que diuen a aquesta persona en quin camp discrepen. És el disseny del cookbook de TypeSafe sobre catàlegs, amb 450 parells candidats.

Per què aquí. Perquè és la quarta pregunta de la frontera de l'ERP —i si la dada del sistema està malament?— resolta abans de connectar l'agent. Netejar el mestre és la preparació de dades més rendible que hi ha.

El parany. Els identificadors —CIF, IBAN, codis interns— es comparen en codi, mai amb el model. Jev jutja si «Distribuciones Pérez» i «Dist. Pérez e Hijos, SL» són la mateixa empresa, no si dos números coincideixen.

10 · Revisió semàntica a la CI i triatge de pull requests

El problema. Les convencions d'un equip —com s'anomenen les coses, què no es fa en segons quina capa, què exigeix un canvi en una API pública— no caben en un linter clàssic, i revisar-les a mà és el primer que se salta quan creix el volum de codi generat.

Com es munta. Un Noul per regla sobre cada fragment del diff, dins del pipeline de CI; el que supera el llindar es marca per revisar. TypeSafe ho inclou entre els seus casos d'ús com a linting semàntic.

Per què aquí. Perquè en els equips que desenvolupen amb IA el coll d'ampolla ja no és escriure codi, sinó revisar-lo, com explicàvem a la peça sobre la revisió de codi generat. Un filtre barat que dirigeix l'atenció humana cap al que importa val més que un altre assistent que escrigui.

El parany. El codi de baix nivell i les representacions numèriques són entre el que pitjor porta Jev, segons la seva pròpia documentació. Per a regles sobre intenció i estructura, bé; per trobar una fallada de lògica, no.

Tres usos prometedors que deixem fora de la llista, de moment

Decisions en temps real dins d'una interfície. És la demostració més vistosa del llançament —Jev jugant a Doom amb deu consultes per segon, per uns set dòlars l'hora— i l'exemple de la banca per veu de la seva documentació. Pocs processos d'una empresa mitjana necessiten decidir en 100 mil·lisegons en lloc de tres segons; els que sí, com el frau en el moment del pagament, mereixen una anàlisi pròpia.

Convertir històrics en variables per a models clàssics. Passar anys de tiquets, notes comercials o ressenyes per centenars de preguntes i fer servir les probabilitats com a variables d'un model de predicció és dels usos amb més recorregut, i TypeSafe publica un bucle complet per fer-ho. Però exigeix una veritat de referència amb què mesurar i un equip de dades que ho mantingui: no és per on es comença.

Agents que fan servir el navegador o l'ordinador. Hi ha qui ja l'està fent servir per decidir cada clic per fraccions de cèntim. És massa aviat per recomanar-ho en un procés de negoci.

Com saber si serveix per al vostre cas abans de comprometre res

TypeSafe demana que cada client es construeixi les seves avaluacions, i té raó. Aquesta és la prova que faríem nosaltres abans de posar Jev en un procés:

1. Trieu una decisió, no un procés. Una sola crida a un LLM de les de la segona pila: la que més es repeteix o la que més costa.
2. Reuniu entre 200 i 300 casos reals amb la resposta correcta, en el vostre idioma i amb la vostra brutícia. És el golden set de sempre, i probablement ja en teniu la meitat a l'històric.
3. Descomponeu la pregunta en preguntes atòmiques, amb criteris que diguin què entra i què no en cada opció. Proveu les instruccions en català i en anglès.
4. Feu córrer Jev i el vostre LLM actual sobre el mateix conjunt, i mesureu encert, latència i cost per decisió.
5. Mireu el calibratge, no només l'encert. Agrupeu les respostes per trams de confiança i comproveu quin percentatge encerta a cada tram. Si al tram de 0,9 n'encerten nou de cada deu, hi podeu construir un llindar a sobre; si no, la confiança no serveix com a disparador i Jev perd el seu principal avantatge.
6. Proveu el que sabeu que li costa: missatges escrits per enganyar-lo, casos amb imports i dates, estats amb molt de soroll.
7. Decidiu abans de desplegar la versió fixada, el llindar per tipus d'acció i què fa el sistema quan Jev no respon. I passeu l'acord de tractament de dades a qui porti la protecció de dades.

El criteri de decisió és senzill d'enunciar: Jev compensa si, al llindar que el vostre procés necessita, resol més casos que el sistema actual amb el mateix error silenciós, o els mateixos casos amb menys cost i latència. Si el calibratge no aguanta en les vostres dades, la velocitat i el preu no ho compensen: haureu canviat un classificador car per un de barat que no sap quan dubta.

El producte pot canviar; el patró es queda

Pot ser que d'aquí a un any Jev tingui competidors —Ronacher ho donava per fet— o que TypeSafe no compleixi el que promet. El que no desapareixerà és el patró que posa sobre la taula, i convé adoptar-lo amb independència del proveïdor.

El patró és aquest. El codi és l'amo del flux. Els LLM es queden amb el que només ells fan bé: redactar, raonar en diversos passos, resoldre el que és obert. I els centenars de decisions petites que hi ha entremig —a qui va això, és segur això, quin d'aquests és el bo, falta alguna cosa— es converteixen en preguntes tancades que retornen una probabilitat, es combinen en codi i s'encaminen amb llindars que algú ha decidit i mesurat. És arquitectura de sistema 1 i sistema 2, i és el que separa un agent que és programari d'un agent que és una demo.

Per això la documentació de TypeSafe insisteix que Jev serveix per construir programari amb IA, no agents: cada volta del bucle d'un agent és una oportunitat més de sortir-se del camí, i cada decisió que es treu del bucle i es converteix en una pregunta tipada és una oportunitat menys.

La pregunta útil, doncs, no és si Jev és millor que GPT o que Claude. És quantes de les vostres crides a un LLM eren, en realitat, una decisió amb forma de text.

Preguntes freqüents

Què és Jev de TypeSafe?

És el primer model del que TypeSafe AI anomena System One: un model que no genera text, sinó que respon preguntes tancades sobre un estat —un tiquet, un expedient, la traça d'un agent— i retorna decisions tipades amb una probabilitat per a cada opció. Hi ha tres tipus de pregunta: Choice per triar entre opcions, Score per situar alguna cosa en una escala i Noul per a preguntes de sí o no. Es va llançar el 15 de setembre de 2026 en accés anticipat i està pensat perquè el consumeixi el codi, no una persona.

En què es diferencia de demanar a un LLM una resposta en JSON?

En tres coses. La sortida està restringida per construcció a les opcions que definiu, de manera que no cal validar ni parsejar res. Totes les preguntes s'avaluen en paral·lel en una sola crida, al voltant de 100 mil·lisegons, en lloc de generar text token a token. I cada resposta porta una probabilitat entrenada per estar calibrada, que és el que permet construir llindars. Un LLM amb sortida estructurada pot retornar el mateix format, però la confiança que declara no sol estar calibrada.

És veritat que Jev no al·lucina?

És veritat en un sentit estret: no pot retornar un valor que no sigui entre les opcions que li heu donat. No ho és en el sentit que importa: pot triar l'opció equivocada, i amb una probabilitat alta. La mateixa documentació recorda que el calibratge es mesura sobre grups de prediccions i no garanteix que una resposta concreta sigui correcta. Cal mesurar l'encert i el calibratge amb casos reals, com amb qualsevol model.

Funciona en català i en castellà?

Accepta qualsevol idioma, però TypeSafe indica que l'anglès és el seu idioma principal d'entrenament i que els altres funcionen amb menys precisió. Per a una empresa d'aquí això vol dir mesurar abans de refiar-se'n: muntar un conjunt de casos reals en català o castellà, comparar-ne l'encert i el calibratge i provar les instruccions escrites en el vostre idioma i en anglès. I vigilar especialment la confiança a l'hora d'encaminar.

Es pot fer servir amb dades personals de clients europeus?

Es pot, amb feina prèvia. El servei és avui als Estats Units i les transferències des de la UE s'emparen en les clàusules contractuals tipus del seu acord de tractament de dades. TypeSafe diu que no entrena amb dades de clients, però la retenció zero només s'ofereix al pla enterprise. Abans d'enviar dades personals convé una avaluació d'impacte i de la transferència, i minimitzar el que va a l'estat: moltes decisions no necessiten noms ni identificadors.

Substitueix GPT o Claude en els nostres fluxos?

No, els complementa. Jev no redacta, no raona en diversos passos i no genera codi. El que sí que pot substituir són les crides a un LLM que en realitat són decisions: classificar, encaminar, puntuar, verificar o triar entre candidats. El patró que proposem és que el codi governi el flux, que els LLM es quedin amb el que requereix escriure o raonar i que les decisions petites es facin amb preguntes tancades i llindars mesurats.