Omar Tissir (PonteClick): “Hai que evitar que o noso algoritmo viaxe a Frankfurt para responder en Santiago"

Omar Tissir é consultor tecnolóxico e CEO de PonteClick. Especialista en IA e WPO, escribe sobre rendibilidade dixital desde Galicia.

Omar Tissir, consultor tecnolóxico galego e CEO de PonteClick, achéganos un artigo sobre as cousas que podemos facer para comezar a tirar verdadeiro partido da intelixencia artificial.

Imos ser honestos para empezar.
Levamos meses de hype. Abres LinkedIn e parece que se non integraches unha IA xenerativa na túa empresa antes do almorzo, estás obsoleto. Todo son promesas de automatización máxica, vídeos que se crean sós e chatbots que recitan a Shakespeare.
Gastaches o orzamento do ano en contratar a API de OpenAI ou en montar un servidor cunha GPU que custa o mesmo que un coche pequeno. Deseñaches un prompt perfecto. Dáslle a "enviar".
Sentas. Agardas. O circuliño de carga xira.
E xira.
E, tres segundos despois, a IA respóndeche.
Ti pensas: "Bo, é maxia, ten que pensar". Eu dígoche: “A túa infraestrutura é unha ruína e estás a tirar o diñeiro”.
Son Omar, especialista en IA e WPO, e hoxe veño soltarvos unha verdade incómoda que ninguén quere oír entre tanto ruído mediático: a Intelixencia artificial non é maxia. É ferro, electricidade e física. E en Galicia, estamos tentando correr por estradas de terra.
A infraestrutura é a nova "fontanería". E a túa, probablemente, perde auga.

A explicación humana: por que o teu IA parece parva (sen que estoupe a túa cabeza)

Sei que aos directivos e desenvolvedores gústanvos as siglas. LLM, RAG, API... Queda moi ben nas reunións. Pero necesito que prestedes atención á única sigla que realmente decide se o seu proxecto triunfa ou vaise directamente ao foxo: TTFB (Time To First Byte).
Esquece das redes neurais un segundo. Imos imaxinarnos que a túa aplicación de IA é un restaurante de luxo en Santiago.

1. A latencia: o camareiro que vive en Alemaña

Tecnicamente, a latencia é o tempo que tarda un paquete de datos en ir de A a B. Na vida real: imaxina que entras ao restaurante, sentas e pides un vaso de auga. Algo simple.
O problema é que a cociña non está en Santiago. A cociña está en Frankfurt (onde adoitan estar os servidores de eu-central-1 de AWS). Cada vez que pides "auga", o camareiro ten que saír do local, coller un avión a Alemaña, encher o vaso, volver en avión e servilo.
Por moi rápido que sexa o camareiro (a fibra óptica), a física é a física. Esa viaxe ten un custo en tempo. Se o teu IA tarda 800 milisegundos só en chegar ao servidor para empezar a "pensar", xa perdiches. No mundo da interacción en tempo real, 800 ms é unha eternidade. É a diferenza entre unha conversa fluída e falar por walkie-talkie con atraso.

2. O código sucio: o cociñeiro con manoplas

Aquí entra a segunda métrica asasina. O tempo de cómputo. Na vida real: o camareiro xa volveu de Alemaña co teu pedido. Agora o cociñeiro ten que preparar o prato. Pero resulta que o teu cociñeiro (o teu código) está a tentar cortar cebola cunhas manoplas de forno postas e un coitelo de manteiga.
Iso é o que pasa cando usas librerías de Python pesadísimas para tarefas sinxelas, ou cando a túa base de datos fai consultas redundantes. Estás a queimar CPU ao parvo. E na nube, queimar CPU é queimar billetes de 50 euros.

O dato financeiro: a factura da luz e a paciencia

"Vale, Omar, pero a IA é lenta de seu, o usuario enténdeo".
Non. Non o entende. E voucho demostrar coa carteira.
Se estás a montar un sistema de atención ao cliente con voz (Voicebot) ou un asistente de compras, cada milisegundo de atraso (latencia) tradúcese en "fricción cognitiva". Se eu lle pregunto ao teu bot "tedes stock?" e tarda 2 segundos en contestar, o meu cerebro asume que é estúpido ou que se colgou.
O resultado é o mesmo que no artigo que escribín sobre webs lentas: abandono. Estás a pagar pola API de IA (carísima), estás a pagar polo servidor (carísimo) e o cliente vaise porque a experiencia é pastosa. É como mercar un Ferrari e poñerlle rodas de madeira.

Caso de estudo: o algoritmo perfecto no servidor equivocado

O equipo de PonteClick

Para que vexas que isto non é teoría de salón, vou contar un caso real que diagnosticamos na miña Axencia PonteClick. Manterei o anonimato, pero digamos que é unha startup galega prometedora.
A situación: crearan un modelo de recomendación brutal. Sabía exactamente que produto querías antes de que ti o soubeses.
O problema: a web tardaba 4 segundos en mostrar esa recomendación. O CEO culpaba ao modelo de IA: "É que é moi complexo, necesita tempo".
O diagnóstico técnico (o que non se ve): meter nas tripas do sistema e... sorpresa. O modelo de IA tardaba só 200ms en inferir a resposta. Era unha bala. Onde estaban os outros 3.8 segundos?
1. A base de datos estaba a pedais: para alimentar á IA cos datos do usuario, o sistema facía unha consulta SQL nefasta a un servidor saturado (metáfora: o cociñeiro buscando os ingredientes nun rocho ás escuras).
2. A viaxe a Frankfurt: o servidor da web estaba en Madrid, a base de datos en París e a API de IA en Virginia (EE.UU.). Os datos estaban a dar a volta ao mundo en cada clic.
A solución (fontanería, non maxia): non tocamos nin unha liña do algoritmo de IA. O que fixemos foi WPO (Web Performance Optimization) puro e duro:
-Limpamos as consultas á base de datos (índices, caché).
-Movemos o que puidemos o Edge.
O resultado? O tempo baixou a 0.8 segundos. As vendas subiron. A "intelixencia" do sistema non cambiou, pero de súpeto parecía máis intelixente porque era rápida.

O reto para Galicia: menos APIs e máis "ferro" local

Aquí é onde me poño a gorra de analista rexional.
Galicia ten unha rede de fibra envexable. Temos os tubos. Pero fáltanos o Edge. Seguimos dependendo demasiado de que os nosos datos viaxen aos grandes hubs europeos.
A solución non é só contratar máis largo de banda. A solución é o Edge Computing. Isto significa achegar o procesamento ao usuario. Que o teu algoritmo non se execute en Alemaña, senón nun nodo no Porriño ou o máis preto posible do punto de intercambio.
Se queremos que Galicia sexa unha potencia en IA, temos que deixar de pensar só no software e empezar a preocuparnos pola física. Necesitamos centros de datos de proximidade e arquitecturas que entendan que a luz, aínda que rápida, non é instantánea.

Guía práctica: o que podes facer hoxe mesmo

Non quero que te vaias de aquí só con queixas. Se es un responsable técnico ou un directivo TIC, aquí tes deberes:
1. Mide o teu TTFB real. Non me vale que me digas "vai rápido na miña fibra de 1GB". Usa ferramentas reais. Se o teu servidor tarda máis de 200ms en responder antes de procesar a IA, tes un problema de fontanería.
2. Audita o teu código Legacy. Antes de meter IA, limpa a casa. Se o teu backend é un espagueti de código ineficiente, a IA só vai a amplificar o desastre.
Código limpo = Menos consumo = Menos latencia.
3. Caché, Caché, Caché: A resposta máis rápida é a que non se ten que calcular. Se a túa IA responde o mesmo á mesma pregunta, gárdao en Redis. Non gastes cómputo dúas veces.

A velocidade é credibilidade

Vou pechar cunha reflexión que repito moito.
Podemos falar de redes neurais, de transformadores e de futuro todo o día. Pero ao final, a experiencia de usuario redúcese a unha cousa: inmediatez.
Unha IA lenta non se percibe como "pensativa", percíbese como rota. Unha infraestrutura optimizada di: "Sei o que fago". Unha infraestrutura lenta berra: "Isto é un prototipo e non sei como escalalo".
Revisa as túas tubaxes. Deixa de mirar tanto o algoritmo e empeza a mirar onde o estás a executar. Porque sen unha boa fontanería, a túa IA é só un xoguete moi caro.