Preguntas Frecuentes

Un cliente cunha tenda de mobles escribiunos case molesto porque o chatbot que lle acabábamos de instalar “tardaba unha eternidade” en contestar. Collemos o móbil e cronometramos: 4,2 segundos desde que o usuario premía enter até que aparecía a primeira palabra. A nós, que levamos meses mirando logs destas cousas, non nos pareceu moito. Para alguén afeito ao chat de WhatsApp, onde a resposta aparece case ao instante, si o é.

Por que tarda en responder un chatbot de IA ten unha resposta bastante concreta: depende do tamaño do modelo que uses, de canto contexto lle mandas en cada petición e de se ten que consultar algunha ferramenta externa (unha base de datos, un catálogo, outra API) antes de poder contestar. Un modelo grande, con moito historial de conversa a cuestas e unha chamada a un sistema de inventario polo medio, pode tardar máis de tres segundos aínda que todo estea funcionando exactamente como debería.

O tamaño do modelo pesa máis do que parece. Cando probamos o mesmo fluxo con GPT-4 e con un modelo máis pequeno pensado para tarefas sinxelas, a diferenza foi de 4 segundos a 900 milisegundos para preguntas tipo “¿tedes esta mesa en carballo?”. O modelo grande seguía sendo necesario para as consultas raras, as que mesturan varias condicións ou requiren razoar un pouco. Para o resto, era pagar de máis por unha precisión que ninguén necesitaba nese punto.

O que ao cliente lle importaba, de todos os xeitos, non era o número exacto, senón a sensación. E aí hai un truco que cambia a percepción sen tocar a latencia real: amosar a resposta palabra a palabra en canto comeza a chegar (o que na xerga se chama streaming), en vez de esperar a ter o texto completo para pintalo de golpe. Psicoloxicamente, ver que algo “xa está pasando” tolérase moito mellor que unha pantalla en branco cun punto a xirar.

Hai outras cousas que si reducen o tempo real, non só a percepción. Recortar o system prompt ao imprescindible axuda, porque cada token de máis procésase antes de xerar nada. Gardar en caché resultados de chamadas externas que non cambian cada minuto —prezos, stock aproximado, políticas de envío— tamén quita de en medio a parte máis lenta, que case nunca é o modelo en si, senón a rede ir e vir a outro sistema; é a mesma lóxica que explicamos ao falar de por que ás veces non se ven os cambios dunha web, só que aplicada a datos en vez de a páxinas. E usar un modelo rápido como primeiro filtro, que só escale ao modelo grande cando detecta que a pregunta o necesita, é basicamente o que fixemos coa tenda de mobles: mesma caixa de entrada, dúas velocidades segundo faga falta.

O cliente dos mobles segue con esa configuración mixta meses despois. O que non resolvemos de todo, e dicímolo sen disimulo, é onde trazar a liña entre “isto é simple, vai polo camiño rápido” e “isto precisa o modelo grande”: cada vez que se afina esa regra aparece unha pregunta nova que non encaixa ben en ningún dos dous caixóns.

→ Ligazón directa a esta pregunta

Hai un par de meses un cliente chamounos case enfadado: o chatbot que lle montaramos para atención ao cliente puxérase a recomendar produtos da competencia. Non era un fallo do modelo. Era o system prompt, mal escrito, que non lle dicía ao bot que facer cando non sabía a resposta.

O system prompt dun chatbot de IA é o bloque de instrucións que se manda ao modelo antes de cada conversa, invisible para quen escribe, e que fixa o seu rol, o seu ton e os seus límites; cambiar unhas poucas frases aí pode facer que o mesmo modelo pase de soar como un robot xenérico a comportarse como o asistente dunha marca concreta.

Na práctica é un ficheiro de texto, a veces de dous parágrafos, a veces de catro páxinas. Aí metemos cousas como “es o asistente desta tenda, só falas dos produtos deste catálogo” ou “se non sabes o prezo do envío, dio, non inventes un número”. Aí está o 80% do traballo real cando montamos un axente ou chatbot para un cliente: non en elixir o modelo, en afinar ese texto a base de probar conversas raras que un usuario normal nunca escribiría nunha demo.

O que ninguén conta ao empezar é que o mesmo prompt funciona distinto segundo o modelo. Tivemos un que ía perfecto en GPT-4 e volvíase evasivo en Claude coas instrucións idénticas, letra por letra. Houbo que reescribir media instrución só por ese cambio de provedor.

E hai un límite que a veces se nos esquece avisar ao cliente: o system prompt non é seguridade. Un usuario con paciencia pode lograr que o bot ignore as súas instrucións. Para evitalo fai falta algo máis que un texto bonito ao principio: filtros á parte do prompt, validacións no backend, límites que non dependan de que o modelo “se acorde” de comportarse ben.

→ Ligazón directa a esta pregunta

Hai uns meses montei o buscador interno para unha tenda online de material de pesca, un cliente que xa levabamos co resto da web. Probou a buscar “caña spinning” e non saía nada, aínda que o produto se chamaba “caña de pescar para spinning” e estaba en stock, con fotos e todo. O buscador de toda a vida compara palabras: se a consulta non coincide máis ou menos letra a letra co título ou a descrición, non hai resultado. Cambiei o motor a un baseado en embeddings e o problema desapareceu nunha tarde, non nunha semana de ir metendo sinónimos á man un a un.

Un embedding é unha lista de números (un vector, normalmente de varios centos ou miles de posicións) que representa o significado dun texto, non as súas letras. “Caña spinning” e “caña de pescar para spinning” xeran vectores moi próximos entre si aínda que compartan poucas palabras exactas, e esa proximidade numérica é o que permite buscar por significado en vez de por coincidencia literal.

Para xeralos usei o modelo text-embedding-3-small de OpenAI: mándaslle un texto e devolveche un vector de 1536 números, por uns 0,02 dólares por millón de tokens, así que procesar o catálogo enteiro (uns 4.000 produtos) custou céntimos. Gardei eses vectores en Postgres coa extensión pgvector, cinco liñas de SQL para o índice, e xa podía comparar o vector de cada busca cos dos produtos e quedar cos máis próximos. Nada de infraestrutura nova nin de meter un servizo externo só para isto.

O que non esperaba é o mal que se explica isto a un cliente. Díxenlle “o sistema busca por significado” e mirou para min coma se lle estivese vendendo fume. O que funcionou foi ensinarlle capturas de antes e despois: mesmo termo, cero resultados co buscador vello, tres produtos relevantes co novo. Iso entendeuno en dez segundos; a explicación teórica non a entendería en dez minutos.

Os embeddings son tamén a peza que permite que un chatbot conteste cos documentos dunha empresa sen que o modelo se teña adestrado con eles: converte cada fragmento dun manual ou un PDF no seu vector, e cando alguén pregunta algo, busca os fragmentos co vector máis parecido á pregunta e pásallos ao modelo como contexto, dentro do que lle cabe na ventá de contexto. É a base técnica do que moita xente chama RAG, aínda que o nome técnico case nunca sae na conversa cun cliente.

O que si discuto con calma é que modelo de embeddings usar, porque non dá igual: hai modelos máis baratos e rápidos, e outros máis caros que captan matices máis finos, como sinónimos raros ou xerga dun sector moi concreto. Para o catálogo de pesca sobraba co modelo pequeno; para un buscador legal con terminoloxía moi específica probablemente non. Aínda non teño unha regra fixa para decidir isto de antemán. De momento probo os dous cunha mostra real de buscas do cliente antes de comprometerme cun.

→ Ligazón directa a esta pregunta

Hai un par de meses pedinlle a un modelo “normal” que revisase a lóxica dun sistema de descontos con regras que se pisaban entre si (cupón, oferta de tempada e prezo xa rebaixado, os tres á vez) e devolveume unha resposta segura, ben redactada e equivocada. Cambiei ao modo de razoamento do mesmo provedor, a mesma pregunta exacta, e tardou quince segundos en vez de dous. Esta vez si colleu o caso raro no que dúas condicións se anulaban entre elas.

Un modelo de razoamento é unha IA que, antes de escribir a resposta que ves, xera internamente unha cadea de pasos intermedios onde proba camiños e descarta os que non cadran, en vez de contestar á primeira como fai un chatbot normal. Iso custa máis tempo e máis tokens, pero mellora bastante o acerto en tarefas con varios pasos lóxicos encadeados: código con dependencias cruzadas, contratos con cláusulas que se contradín, ese tipo de cousa.

O problema é xustamente ese: pensar de máis non é de balde. Na maioría de provedores pagas tamén polos tokens do razoamento interno, os que nunca ves na pantalla, así que a mesma pregunta pode saír bastante máis cara que cun modelo normal. Para unha consulta de atención ao cliente do tipo “¿facedes envíos a Portugal?” é tirar o diñeiro: o modelo estándar responde igual de ben e nunha fracción do tempo. E aí é onde entender como se contan os tokens axuda de verdade a decidir que modelo pos en cada función, non só na de razoamento.

Nós usámolo dun xeito bastante cirúrxico.

Para xerar texto de mercadotecnia, resumir un correo ou clasificar un ticket entra un modelo estándar de gama media, sen dubidalo. Para revisar un cambio de arquitectura antes de tocar nada, depurar un bug que leva dous días resistíndose ou repasar un contrato antes de que o vexa un cliente, cambiamos ao modo razoamento sen pensalo dúas veces. A diferenza nótase sobre todo cando o problema ten unha trampa agochada: o modelo normal písaa con seguridade, o de razoamento ás veces vena vir e dío explicitamente antes de responder, algo tipo “espera, isto ten un caso límite raro”.

O que aínda non teño resolto do todo é cando delegar esa elección, modelo rápido ou modelo que pensa, no propio sistema en vez de decidila eu a man cada vez. Algúns provedores xa ofrecen un router automático que elixe por ti segundo a pregunta, pero as poucas veces que o probamos en produción acertaba menos do que nos gustaría. Así que, de momento, seguimos poñendo o interruptor nós.

→ Ligazón directa a esta pregunta

Hai unhas semanas un cliente escribiunos ás once da noite bastante nervioso: acababa de recibir un aviso do seu provedor de IA de que o consumo se disparara na última hora, algo así como douscentos dólares en corenta minutos. Ninguén na súa empresa tocara nada. Cando miramos o repositorio do proxecto en GitHub —público, porque o subira el mesmo sen preguntarnos, para “ensinarllo a un socio”— alí estaba, nun commit de hai tres semanas, a clave de API pegada directamente no código, sen variables de contorno nin nada. Alguén, ou algún bot rastrexador, atopárase con ela e estábaa usando para xerar quen sabe que ao seu costo.

Unha API key de IA é, basicamente, un contrasinal que identifica a túa conta perante o provedor do modelo (OpenAI, Anthropic, Google ou o que sexa) cada vez que a túa aplicación lle pide algo. Se esa clave cae en mans doutra persoa, esa persoa pode usar o modelo coma se fose ti, e a factura chégache a ti: non hai xeito de que o provedor saiba que quen a usou non eras ti, salvo que reacciones a tempo revocándoa.

O que fixemos con este cliente foi o de sempre nestes casos: revogar a clave desde o panel do provedor en canto vimos o aviso, xerar unha nova, e desta vez metela en variables de contorno do servidor, nunca no código que se sobe a un repositorio. Iso levou dez minutos. O que custou máis foi convencelo de que o seu socio non necesitaba ver o código fonte para entender o que construiramos —abondaba cunha demo gravada— e de que un repositorio “privado pero coa clave dentro” tampouco é tan privado como parece, porque calquera colaborador futuro, ou un fork mal xestionado, a herda igual.

A factura, por certo, asumiuna o provedor tras unha reclamación por uso fraudulento. Non sempre pasa. Depende da política de cada provedor e do rápido que reportes o problema, así que non convén contar con esa sorte.

Desde entón aplicamos unha regra en todos os proxectos que antes dabamos por sabida sen comprobala de todo: ningunha clave vai no código, todas van nun ficheiro de contorno que o propio Git ignora, e as de produción gárdanse á parte, no xestor de segredos do hosting, nunca nun documento compartido por correo ou nunha conversa de WhatsApp do proxecto (vímolo máis dunha vez). É a mesma lección que sacamos ao auditar a seguridade do noso propio servidor: a maioría dos sustos non veñen dun ataque sofisticado, veñen dunha clave que alguén deixou á vista sen decatarse.

O que aínda non teño resolto é como explicarlle isto a un cliente sen que soe a regaño, sobre todo cando o erro o cometeu alguén con boa intención que só quería presumir do seu proxecto.

→ Ligazón directa a esta pregunta

Hai tres semanas escribiunos unha clienta que vende lámpadas e decoración online. Quería automatizar un anaco do proceso de devolucións: cando un comprador manda unha foto dicindo “chegou rota”, que alguén do sistema puidese mirar esa imaxe e decidir se aprobar a devolución sen que unha persoa do equipo tivese que abrir cada correo a man.

Iso é xustamente o que fai a IA multimodal: entender texto e imaxe (ás veces tamén audio ou vídeo) na mesma conversa, sen necesitar un sistema á parte para cada tipo de contido. Mándaslle unha foto xunto cunha pregunta e respóndeche sobre o que ve, coma se llo describises a unha persoa por teléfono.

Ata hai un par de anos, montar algo así implicaba pegar pezas soltas: un modelo de visión por un lado que clasificaba a imaxe, un OCR se había texto na foto, e logo un modelo de linguaxe á parte que redactaba a resposta co que os outros dous lle pasaban. Tres sistemas, tres puntos onde algo se pode romper. Cun modelo multimodal coma Claude ou GPT-4o iso redúcese a unha soa chamada: a imaxe entra na mesma xanela de contexto que o texto, e o modelo razoa sobre as dúas cousas á vez.

O prototipo para a clienta montámolo nunha tarde, literal. Pasámoslle a foto e un prompt coas condicións da súa política de devolucións, e o modelo devolve se hai dano visible, de que tipo, e unha nota breve para o equipo. Funciona ben con roturas evidentes (un cristal partido vese decontado) e peor con matices: un pequeno arañazo nun acabado mate, por exemplo, unhas veces detéctao e outras non. Aí seguimos con revisión humana antes de aprobar nada automaticamente. A IA reduce o traballo de mirar cada foto unha por unha. Non substitúe o criterio final.

O que case ninguén pregunta ao principio, e debería, é que pasa con esas fotos unha vez saen do teu servidor. Van á API dun provedor externo igual que pasaría con calquera modelo de linguaxe, así que se a clienta sobe algo con datos persoais visibles (un enderezo nunha etiqueta, unha cara ao fondo) hai que tratalo co mesmo coidado ca calquera outro dato que lle deas a unha IA. No noso caso avisamos á clienta de que as fotos de devolución pasan por ese proceso, e deixámolo por escrito na política, non como nota a pé de páxina.

Aínda non probamos a meter audio no mesmo fluxo, aínda que a mesma clienta xa preguntou se se pode facer algo parecido coas notas de voz que ás veces manda a xente explicando o que pasou. Tecnicamente si se pode. Se paga a pena montalo para o volume de devolucións que ten, esa é outra pregunta da que aínda non teño resposta clara.

→ Ligazón directa a esta pregunta

Un cliente escribiume hai unhas semanas case indignado: pedíralle a ChatGPT que lle resumise o mesmo documento dúas veces, coa pregunta copiada e pegada, letra por letra, e deralle dous resumos distintos. Pensaba que a ferramenta estaba rota. Non o está. Funciona así por deseño, e a min tamén me custou asumilo a primeira vez que montamos unha integración cun modelo para un cliente e os resultados non saían repetibles nas probas.

Un programa normal é determinista: mesma entrada, mesma saída, sempre. Unha folla de cálculo non ten días bos nin malos. Un modelo de linguaxe non funciona así por dentro. Cando xera texto, en cada paso calcula unha lista de palabras candidatas cunha probabilidade asignada a cada unha, e escolle unha de entre as máis probables, non sempre a máis probable, senón unha mostreada ao chou dentro dese abano. Iso contrólase cun parámetro que case todas as API expoñen, chamado “temperature”: canto máis alto, máis variedade (e máis risco de irse polas ramas); canto máis baixo, ou directamente a cero nalgúns modelos, respostas moito máis parecidas entre si, aínda que case nunca ao cen por cen idénticas. En unha frase: unha IA dá respostas distintas á mesma pregunta porque non escolle sempre a palabra máis probable, senón que mostrea entre varias candidatas segundo ese parámetro de aleatoriedade, así que certa variación non é un fallo, é parte do deseño.

Por que deseñalo así, se xera esta sensación de pouca fiabilidade? Porque o mesmo mecanismo que fai que dous resumos saian distintos é o que permite que o modelo non soe sempre igual, que remate unha frase de forma natural en vez de repetir a combinación de palabras estatisticamente máis plana unha e outra vez. Sen esa aleatoriedade un chatbot soaría a máquina de verdade, non a algo que imita unha conversa con soltura.

O problema aparece cando alguén, nós incluídos a primeira vez, usa un modelo para unha tarefa que si precisa ser determinista. Montamos para un cliente unha automatización que lía facturas en PDF e extraía importe, data e provedor cun LLM. Nas probas funcionaba ben. En produción, de cando en vez o mesmo tipo de factura, co mesmo formato exacto, daba un campo mal lido que a vez anterior saíra perfecto. Non era un bug do noso código: era o modelo sendo modelo. Baixamos a temperatura ao mínimo e engadimos unha validación posterior con regras fixas, que o importe teña formato numérico, que a data exista de verdade, e o problema mellorou moito. Non desapareceu de todo. Con estas ferramentas, “case sempre ben” é distinto de “sempre ben”, e hai que deseñar sabendo cal das dúas precisas de verdade para cada peza do proceso.

Para un uso normal, preguntar algo, pedir ideas, que che axude a redactar un correo, esta variabilidade non importa nada, ata axuda. O problema é cando alguén monta un proceso automático de negocio dando por feito que un LLM se comporta como unha fórmula de Excel. Non o fai. Canto antes o teñas claro ao deseñar a automatización, menos sustos con datos raros vas levar seis meses despois de poñela a funcionar soa.

→ Ligazón directa a esta pregunta

O outono pasado un cliente inmobiliario pediunos un asistente que contestase preguntas sobre os seus contratos de arras subindo o PDF directamente ao chat. Soaba trivial. Probamos primeiro cun contrato curto, de oito páxinas, e funcionou perfecto: preguntas sobre prazos, sobre a cláusula de penalización, sobre quen se queda coa sinal se cae a operación. Todo ben: o contrato enteiro cabía de sobra na fiestra de contexto do modelo.

O problema chegou cun dos seus contratos longos de verdade, deses que arrastran anexos técnicos e un historial de modificacións: corenta e tantas páxinas, moitas máis das que cabían nesa fiestra. O modelo empezou a responder con seguridade absoluta sobre cláusulas que non existían. Non é que se equivocase un pouco, é que se inventaba números de artigo enteiros. A fiestra de contexto é xustamente iso: o límite de canto texto pode “ter presente” un modelo á vez, e cando se supera, case nunca avisa cun erro claro, así que a IA “parece esquecer” o principio da conversa ou o documento e empeza a improvisar.

É un concepto que case ningún cliente coñece ata que lle estala na cara: ese límite mídese en tokens, non en páxinas nin en palabras (un token son máis ou menos tres ou catro caracteres). Un modelo cunha fiestra de 128.000 tokens pode manexar, a ollo, unhas 300 páxinas de texto normal. Soa xeneroso. Pero un PDF escaneado, con táboas mal convertidas ou con imaxes incrustadas, pode converterse no dobre ou no triplo de tokens do que parece a simple vista, e aí é onde a marxe desaparece sen avisar.

O que pasa na práctica, exactamente, é isto: segundo a ferramenta, corta o documento por onde pode, ou resume partes sen dicircho, ou simplemente enche ocos co que lle parece máis probable dado o patrón do texto. Iso é o que lle pasou ao noso cliente: o modelo non tiña o final do contrato na súa fiestra activa e, no canto de dicir “non o sei”, improvisou.

A solución que aplicamos non foi buscar un modelo cunha fiestra máis grande (hainos, ata dun millón de tokens, pero custan máis e van máis lentos). Traballamos con RAG: no canto de meter o contrato enteiro dun golpe, o sistema busca primeiro os fragmentos relevantes para a pregunta concreta e só eses entran na fiestra de contexto. Menos elegante ca “sobe o PDF e pregunta o que queiras”, pero moito máis fiable, e de paso máis barato, porque pagas polos tokens que realmente usa cada consulta.

Se alguén che vende un asistente de IA “sen límites” para documentos longos, pregúntalle que pasa exactamente cando o documento non cabe enteiro. Se a resposta é vaga, probablemente non o probaron cun caso real de corenta páxinas.

→ Ligazón directa a esta pregunta

Hai uns meses un cliente do sector legal pedíunos algo moi concreto: quería un asistente que axudase ao seu equipo a buscar en miles de páxinas de expedientes, pero negábase en redondo a que eses documentos saísen do seu servidor. Nin a OpenAI, nin a Anthropic, nin a ninguén. Aí é onde entra a diferenza entre usar unha IA “na nube” e usar unha de código aberto que corres ti mesmo.

Cando falas con ChatGPT ou con Claude, as túas preguntas viaxan a un servidor de OpenAI ou Anthropic, procésanse alí e devólvenche a resposta. Cómodo, rápido, e non tes que preocuparte de infraestrutura ningunha. O problema é que, para certos negocios, mandar información sensible a un terceiro non é unha opción, xa sexa por contrato, por normativa do sector ou simplemente porque o cliente non se fía. Nunha frase: usar unha IA na nube significa mandar os teus datos a un servidor de terceiros (OpenAI, Anthropic, Google) a cambio de comodidade; corréla nos teus propios servidores significa que eses datos nunca saen da túa rede, a cambio de montar e pagar ti a infraestrutura.

Aí aparecen os modelos de código aberto (ou “open weight”, que é o termo máis preciso): Llama de Meta, Mistral, Qwen. Modelos que podes descargar e executar no teu propio hardware, sen que nin unha palabra do que preguntes saia da túa rede. Con ferramentas coma Ollama ou vLLM, montalo non é tan complicado como soa — un par de días de traballo, non semanas.

O que si custa é o hardware. Para o proxecto do bufete acabamos alugando unha máquina con GPU nun provedor cloud (mercar tarxetas gráficas propias é algo que desaconsellamos case sempre) e aínda así o gasto mensual multiplicaba por catro o que tería custado usar a API de Anthropic para o mesmo volume de consultas. E a calidade das respostas, sendo honestos, era peor: Llama fai un traballo digno, pero non está ao nivel de Claude ou GPT-4 en tarefas de razoamento sobre texto longo.

Así que a pregunta real non é “código aberto si ou non”. É “que me pesa máis, a confidencialidade ou a calidade”. Para a maioría dos nosos clientes a resposta é clara: usar a API dun provedor serio, cun bo contrato de tratamento de datos, sae máis barato, móntase antes e dá mellores resultados. O bufete foi un dos poucos casos sen volta atrás: os seus propios avogados tiñan obrigas de confidencialidade que non admitían intermediarios, por bo que fose o contrato.

Hai un punto intermedio do que se fala menos: algúns provedores (Azure OpenAI, Amazon Bedrock) ofrecen os mesmos modelos pechados pero con garantías contractuais de que os teus datos non se usan para adestrar nin se comparten con ninguén máis. Para bastantes clientes con dúbidas de privacidade iso resolve o problema sen montar servidores propios nin sacrificar calidade. Aínda non llo explicamos a ninguén sen que se lle relaxe un pouco a cara.

O que non teño tan claro é que pasa dentro de dous anos, cando os modelos abertos se acheguen máis en calidade aos pechados. Pode que a pregunta de “self-hosted si ou non” deixe de ser unha cuestión de sacrificar calidade e pase a ser puramente de custo operativo. Ou pode que os modelos grandes vaian sempre un paso por diante. Xa o veremos.

→ Ligazón directa a esta pregunta

Un cliente de loxística escribiunos hai un par de meses bastante nervioso: lera que un provedor grande de IA lle subira o prezo a certos clientes empresariais sen avisar, e quería saber se lle podía pasar o mesmo co asistente que lle montamos para clasificar incidencias de reparto. Díxenlle a verdade, que si. Non falaramos dese risco ao asinar o proxecto. Nin el, nin nós.

Meter un modelo de IA nun negocio é meter unha dependencia nova, e das gordas. Non é como depender dun hosting, que podes cambiar nunha tarde copiando ficheiros dun sitio a outro. Cando un asistente leva meses funcionando cun modelo concreto, o texto das instrucións que lle das (o “prompt”) está afinado para as manías dese modelo en particular: como interpreta as datas, canto se explaia se non lle pos límite, que exemplos precisa para non saírse do guión. Cambiar de provedor non é cambiar unha clave de API. É volver probar media lóxica do asistente desde cero. En resumo: se o teu negocio depende dun provedor de IA concreto e ese provedor sobe o prezo, cambia de modelo ou deixa de dar soporte, migrar non é só cambiar unha clave de API, é volver axustar o prompt e probar de novo boa parte da lóxica do asistente.

Pasounos de verdade cun cliente de seguros. O modelo que usabamos deixou de estar dispoñible na súa versión antiga (deprecated, que din agora) e tivemos que migrar o asistente á versión nova en tres semanas, cunha data límite fixada polo provedor, non por nós. A lóxica xeral seguía funcionando, pero o ton cambiou: o modelo novo era máis seco, respondía máis curto, e tivemos que retocar o prompt enteiro para que volvese soar parecido a como soaba antes. Tres días de traballo que ninguén orzamentara.

Desde entón intento explicar isto en cada proxecto novo que depende de IA de forma seria, non como funcionalidade decorativa de escaparate. Dúas cousas axudan bastante. Unha, non meter a lóxica de negocio dentro do prompt se se pode evitar: as regras duras (que prezo aplicar, que prazo hai que cumprir) van en código normal de toda a vida, e o modelo encárgase só da parte de linguaxe. Así, se mañá cambia o modelo, o que se rompe é o ton, non o cálculo. Dúas, escribir o código de xeito que cambiar de provedor sexa substituír unha función, non reescribir a aplicación enteira. Nada do outro mundo, pero poucos clientes o piden, porque ninguén lles contou que fai falta pedilo.

O que non teño tan claro é canto disto merece a pena montalo desde o primeiro día nun proxecto pequeno. Esa capa de abstracción custa horas que o cliente nota na factura, e para un asistente sinxelo dunha pequena empresa quizais sexa pagar un seguro que nunca vai facer falta usar. Para o cliente de seguros mereceu a pena, visto con perspectiva. Para o das incidencias de reparto, a verdade, aínda non o sei.

→ Ligazón directa a esta pregunta