Buenas, esto es BIMPRAXIS, el podcast donde el
BIM se encuentra con la inteligencia artificial.
Exploramos la ciencia, la tecnología y el futuro
desde el enfoque de la arquitectura, ingeniería y
construcción.
¡Empezamos!
Muy buenas, bienvenidas, bienvenidos a un nuevo episodio
de BIMPRAXIS.
Hoy os traemos una inmersión profunda en cómo
reducir drásticamente los costes y tiempos de espera
de los grandes modelos de lenguaje, gracias a
GPT-Caché.
Y la verdad es un tema fascinante porque
ataca directamente a la viabilidad económica de la
inteligencia artificial.
Bueno, y para arrancar este análisis, vamos a
plantear una situación.
Imaginemos por un momento que contratamos al consultor
más brillante del planeta para un negocio.
Uno que tiene respuestas para todo, claro.
Exacto.
Respuestas súper precisas, articuladas para cualquier problema imaginable.
Pero hay un pequeño gran inconveniente en el
contrato.
Y es que este genio cobra una tarifa
exorbitante por cada sílaba exacta que sale de
su boca.
Uf, menudo peligro para la cuenta del banco
de la empresa.
Totalmente.
Y además, como tiene que pensar meticulosamente cada
respuesta, pues se toma su tiempo para formular
las frases en tiempo real y mientras los
clientes esperando en la línea.
Claro.
Y el problema de verdad llega cuando tienes
a miles de personas entrando por la puerta
y preguntándoles exactamente la misma duda rutinaria.
O sea, cosas como, no sé, el horario
de apertura de la tienda, por ejemplo.
Eso es.
Si la empresa le paga a este consultor
por generar esa misma respuesta, desde cero, una
y otra vez, la bancarrota está asegurada.
Pues de eso va nuestra misión de hoy.
Queremos entender la arquitectura que se está implementando
para resolver esta crisis de escalabilidad.
Y es que esa analogía del consultor ilustra
con una precisión tremenda el problema económico fundamental
de la infraestructura actual.
Depender de las APIs de estos modelos masivos
impone un modelo de negocio que, sinceramente, rompe
con la lógica del software tradicional.
Porque antes, si una web recibía más visitas,
pues añadías servidores y listo, ¿no?
Claro.
Añadías servidores, optimizabas bases de datos y el
coste marginal por usuario bajaba radicalmente.
Pero con la IA generativa, la curva de
costes no se aplana tan fácilmente.
Crece de forma constante y lineal.
O sea, a más uso, la factura sube
proporcionalmente.
Exactamente.
Y la inmensa mayoría de estos proveedores cobran
en base a una combinación de peticiones y
del recuento de tokens.
Para que no lo tenga fresco, un token
viene a ser como una unidad de computación,
más o menos un fragmento de palabra o
una palabra corta.
Sí, eso es.
Y ese peaje económico por cada palabra generada
es solo uno de los dos muros contra
los que chocan los desarrolladores hoy en día.
El segundo muro, entiendo, es el que afecta
directamente a la paciencia de la audiencia, la
latencia, esa lentitud desesperante cuando el sistema se
satura.
Totalmente.
Y el origen de esa lentitud reside en
la propia naturaleza de los algoritmos, porque estos
grandes modelos son sistemas autoregresivos.
Es decir, que no tienen la respuesta completa
guardada en un disco duro lista para mandártela.
Qué bar que va.
La máquina calcula matemáticamente, basándose en el contexto
previo, cuál es la siguiente palabra más probable.
Claro, va palabra por palabra.
Eso es.
La decide, la añade al texto y vuelve
a hacer todo el cálculo masivo para predecir
la que viene después.
Madre mía, es que viéndolo así es un
proceso iterativo que exige una potencia bruta espectacular.
Y por eso cuando una aplicación se hace
viral y miles de personas exigen esa computación
a la vez, no solo sube la factura,
sino que la infraestructura corre un riesgo real
de colapsar.
Y ahí es cuando los proveedores imponen los
famosos rate limits, ¿verdad?
Exacto.
Te ponen un límite estricto de peticiones por
minuto.
Si te pasas, pues quien esté usando tu
app se come una pantalla de error.
Bueno, pues todo este drama técnico nos lleva
directos al núcleo de la investigación de hoy,
la propuesta de valor de GPT-Caché, que es
un proyecto de código abierto diseñado precisamente para
situarse en medio.
Como una capa intermedia entre la aplicación que
desarrollas y el modelo de lenguaje externo.
Eso es.
Y su objetivo es construir una caché semántica.
Y fíjate, los números que arroja la documentación
técnica son una locura.
Prometen reducir el coste de la API hasta
10 veces.
Y acelerar la velocidad de respuesta hasta 100
veces.
Es una barbaridad.
Es un cambio de paradigma total.
Pero, ¿cómo logran exactamente esas cifras de rendimiento?
Pues el principio básico es evitar el trabajo
redundante.
Al interceptar las peticiones y entregar respuestas que
ya tienen almacenadas localmente, el sistema corta de
raíz el consumo de tokens.
Claro, porque no tienes que enviar la petición
al servidor ajeno y esperar a que la
IA piense.
Exacto.
Y al no hacer ese cálculo autoregresivo, la
latencia, o sea el tiempo de espera, se
desploma.
Y además, te libras casi por completo de
los problemas de los límites de tasa que
comentábamos antes.
A ver, el concepto de guardar respuestas pasadas
para ahorrar recursos tiene una lógica aplastante.
Es el mecanismo de la memoria Caché de
toda la vida, vamos.
De toda la vida, sí.
La informática lleva décadas usándolo con muchísimo éxito.
Pero claro, aplicarlo a la inteligencia artificial tiene
que ser otra historia.
Porque el lenguaje humano es de todo menos
un bloque de código predecible.
Es un caos organizativo enorme.
Está lleno de sinónimos, de expresiones coloquiales, de
intenciones implícitas.
Y por ese caos supongo que las caches
tradicionales no sirven aquí, ¿no?
Fracasan estrepitosamente, sí.
Una Caché web convencional funciona buscando una coincidencia
exacta.
Busca si la petición nueva es idéntica, letra
por letra, a algo que ya tiene guardado.
Como cuando guarda el logotipo de una web
para que cargue rápido la segunda vez.
Eso es.
En una web estática, eso vale.
Pero al interactuar con lenguaje natural, la variabilidad
es casi infinita.
O sea, pongamos un ejemplo.
Si alguien quiere saber cómo configurar el control
parental en el móvil, puede escribir cómo activar
control para niños en el móvil.
Claro.
Y a los dos minutos, otra persona con
el mismo problema teclea pasos para bloquear contenido
adulto en smartphone.
O tutorial configuración parental teléfono.
Y al final, las tres frases persiguen exactamente
el mismo objetivo práctico.
Sí, pero para un sistema de caché clásico
basado en coincidencias exactas.
Esas tres entradas son consultas completamente dispares.
Ostras, ¿no se da cuenta de que la
intención de fondo es la misma?
Que va.
Procesaría cada frase como algo totalmente nuevo.
Dejaría pasar la petición a la API y
la empresa pagaría tres veces por generar tres
variaciones de la misma guía.
Entonces, ¿la tasa de acierto sería tan baja
que no compensaría tener la caché?
Exactamente.
Y es frente a esta limitación técnica donde
entra la gran innovación de GPT-Caché, que es
dar el salto del análisis sintáctico al análisis
semántico.
Entiendo.
En lugar de buscar letras idénticas, agrupa consultas
que comparten el significado de fondo.
Eso es.
Vale, pero espera, espera.
Aquí tengo que hacer de abogada del diablo
por un momento.
Adelante, dime.
Si la base de datos local que almacena
esta caché no es una red neuronal masiva
y no está pensando o comprendiendo el lenguaje
en tiempo real, ¿cómo demonios sabe matemáticamente que
dos frases totalmente distintas significan lo mismo?
Es la gran pregunta, desde luego.
O sea, ¿cómo sabe que felino doméstico y
gato operan en la misma categoría si no
está analizando la sintaxis de las letras?
Pues la magia de todo esto reside en
su diseño modular.
El procesamiento se hace por pasos.
Y el primer eslabón crucial es el generador
de embeddings.
Los famosos embeddings.
Sí, que en lenguaje llano de ingeniería, un
embedding no es más que un vector numérico.
Este módulo coge la frase escrita por el
usuario y la traduce a una lista de
números reales.
O sea, convierte las palabras en coordenadas matemáticas,
por así decirlo.
Exacto.
Y usa modelos muy ligeros que ya han
sido entrenados leyendo millones de textos.
Así han aprendido que gato y felino suelen
aparecer rodeados del mismo vocabulario y les asignan
una representación matemática muy similar.
Vale, a ver si lo visualizo.
Es como tener un bibliotecario un poco especial,
que tiene una capacidad de organización distinta.
No ordena los libros por orden alfabético, sino
en un mapa enorme de coordenadas conceptuales.
Me gusta esa analogía.
Es muy visual.
Entonces, si alguien le pide algo sobre vehículos
de combustión, el bibliotecario no va a la
letra V.
Piensa en el concepto y lo archiva en
la latitud 40, longitud 12 del mapa.
¿Y si al día siguiente llega otra persona
y pide información sobre coches de gasolina?
Pues el bibliotecario hace su cálculo y resulta
que las coordenadas vuelven a ser latitud 40,
longitud 12, frases distintas, pero acaban habitando el
mismo punto exacto del mapa matemático.
Lo has clavado.
Esa es exactamente la lógica de la agrupación
espacial.
Aunque, por ponernos un poco tiquismiquis con la
parte técnica, este mapa no tiene solo dos
dimensiones.
Claro, no es solo latitud y longitud.
¡Qué va!
Los espacios vectoriales en el procesamiento de lenguaje
operan con cientos o miles de dimensiones simultáneas.
Cada dimensión puede ser el tono, la formalidad,
o sea, mil matices.
Y para gobernar un mapa tan salvaje, he
visto en las fuentes que GPT-Caché usa su
segundo componente, el almacén de vectores o VectorStore.
Sí, y se integran con bases de datos
especializadas de alto rendimiento, como Milbus o Fais.
Están hechas exclusivamente para guardar millones de estos
puntos y calcular distancias entre ellos en fracciones
de milisegundo.
Vale, tenemos el generador, que traduce las palabras
a puntos, y el almacén ultra rápido que
guarda la ubicación.
Y a eso hay que sumarle el almacenamiento
de caché estándar, claro.
Que entiendo que es una base de datos
normal, tipo Postgres o SQLite, que guarda el
texto real de la respuesta.
El párrafo jugoso que queremos devolver, vamos.
Eso es.
Pero me sigue faltando una pieza en el
rompecabezas.
Si el almacén detecta que la coordenada de
la pregunta nueva está cerca de una antigua,
tiene que haber un árbitro.
Alguien que decida si esa cercanía es suficiente
para reciclar la respuesta o si están muy
separados.
Ah, el juez definitivo de la transacción.
Ese módulo es el evaluador de similitud.
¿Y cómo toma la decisión ese juez?
Pues aplica algoritmos de distancia espacial.
Uno muy típico es calcular la similitud del
coseno.
En vez de medir los centímetros imaginarios entre
dos puntos, mide el ángulo que se forma
trazando líneas desde el centro del mapa a
las dos coordenadas.
Ah, entiendo.
Si el ángulo es muy cerrado, casi cero,
es que apuntan en la misma dirección semántica.
Exacto.
Y si el ángulo es muy amplio, pues
representan conceptos desconectados.
Quien programa esto configura un umbral estricto y
si se supera, el evaluador frena la petición
a la API externa y saca la respuesta
de la base de datos local.
Fíjate que todo este entramado técnico ya me
parece una pasada para el texto escrito.
Pero es que la utilidad se multiplica por
mil cuando pensamos en otros formatos, en la
multimodalidad.
Claro, porque hoy en día la IA también
genera audios y sobre todo imágenes.
Exacto.
Y la documentación del proyecto muestra que esta
lógica vectorial ya se está adaptando para interactuar
con modelos de imágenes.
Y ahí el ahorro económico y energético es
un salto cualitativo brutal.
Generar una ilustración original en alta resolución exige
muchísimo más esfuerzo a las tarjetas gráficas que
redactar un par de párrafos.
Claro.
Si alguien pide un bosque encantado al atardecer
bajo la lluvia y a las dos horas
otra persona pide árboles mágicos lloviendo durante la
puesta de sol… El evaluador de similitud verá
que los vectores son casi idénticos.
Y te silbe la imagen que ya tenía
generada de forma instantánea.
Evitas que los algoritmos pesados de imagen se
reactiven y gasten recursos.
Y además de para los usuarios, a nivel
de ingeniería esto transforma la forma de trabajar.
Las guías insisten mucho en su uso para
entornos de prueba, los famosos sandboxes.
Claro.
Al desarrollar una app conectada a la nube,
tienes que lanzar miles de peticiones automáticas para
ver si tu código aguanta el estrés.
Y pagar las tarifas de los proveedores masivos
solo para diagnosticar errores de desarrollo, pues te
arruina.
Totalmente.
Con la caché simulando las respuestas, pruebas todo
a máxima velocidad sin gastar dinero real.
Pero volviendo al producto final, hay un mecanismo
de control que me parece súper interesante.
La temperatura.
Ah, sí.
La temperatura es la palanca que te permite
ajustar directamente la rigidez de la caché.
Normalmente va del 0.0 al 2.0.
¿Y si lo configuras a cero, qué pasa
exactamente?
Pues que priorizas la eficiencia absoluta.
Si la pregunta entrante supera el umbral matemático
de similitud, te devuelve la respuesta local sí
o sí.
Lo cual tiene todo el sentido si buscas
predictibilidad total.
Por ejemplo, en un sistema de recursos humanos
que explica cuántos días de vacaciones tienes en
la empresa.
Claro.
Si 100 empleados te preguntan por las vacaciones,
tu objetivo es dar la misma información normativa,
rápida y barata.
No quieres variaciones creativas.
¿Pero qué pasa si hablamos de una herramienta
para redacción creativa o un asistente para buscar
nombres originales para productos nuevos?
Ahí reciclar respuestas te destruye el producto.
O sea, si pido cinco ideas disruptivas para
una marca de café y me da el
mismo listado que generó para mi competencia la
semana pasada, pues vaya asistente.
¿Pierde toda su utilidad?
En esos casos elevas la temperatura al máximo,
cerca del 2.0.
Así el sistema ignora la caché local y
obliga a la API a generar algo completamente
original.
Asumiendo el coste y el tiempo, obviamente.
Equilibras la repetición eficiente y la creatividad bajo
demanda.
Exacto.
Pero bueno, toda arquitectura basada en ángulos y
probabilidades tiene que tener sus riesgos, ¿no?
Las cachés tradicionales, si no encuentran la letra
exacta, fallan y punto.
Pero un sistema semántico se puede equivocar al
juzgar.
Y tanto.
Por eso la supervisión de estas cachés exige
un análisis muy riguroso.
Los desarrolladores luchan principalmente contra dos cosas, los
falsos negativos y los falsos positivos.
Empecemos por los falsos negativos.
Eso es una penalización económica pura y dura,
¿verdad?
Exacto.
Ocurre cuando el algoritmo no se da cuenta
de que dos frases distintas significan lo mismo.
Así que manda la petición a la red
externa, aunque tenía la respuesta guardada, y pagas
de nuevo por generarla.
Sí.
Quien interactúa con la pantalla recibe una respuesta
válida, pero la cuenta bancaria de la empresa
sufre por esa ineficiencia.
¿Y el falso positivo?
Ese es el que te genera un fallo
de integridad.
Pasa cuando el sistema agrupa por error dos
preguntas que usan palabras parecidas, pero la intención
es totalmente distinta.
¡Ostras!
Y al hacer eso, rescata de la memoria
una respuesta errónea o fuera de contexto.
Y entregar información fuera de lugar daña irreparablemente
la confianza en el sistema.
Por eso entiendo que la industria evalúa esto
con tres indicadores clave, que la documentación detalla
muy bien.
Sí, el primer gran indicador es la tasa
de acierto, o hit ratio.
Que viene a ser una métrica directa de
cuánto estás ahorrando, ¿no?
Eso es.
Expresa estadísticamente el porcentaje de peticiones que has
resuelto solo con la base de datos local,
sin tocar la API.
Es el termómetro principal de ahorro de costes.
Vale.
Y el segundo indicador he visto que es
la latencia.
Que se mide en milisegundos.
Es el tiempo total de todo el proceso
interno.
Convertir texto a vector, buscar coordenadas, medir el
ángulo y sacar el texto.
Claro.
Si todo ese papeleo interno genera un cuello
de botella y la latencia supera el tiempo
que tardaría el modelo externo… Pues apaga y
vámonos, porque el propósito de la caché queda
anulado.
O sea que la tasa de acierto es
el dinero que nos ahorramos y la latencia
es lo rápido que conseguimos que desaparezca el
ícono de cargando en la pantalla.
Me gusta ese resumen.
¿Y cuál sería el tercer indicador?
El tercer pilar es la exhaustividad, lo que
en inglés llaman recall.
Es para evaluar la precisión general.
¿Y cómo funciona exactamente?
Evalúa cuántas veces el sistema sirvió la respuesta
correcta desde su base de datos frente a
la cantidad total de veces que, matemáticamente, debería
haberlo hecho.
Ah, o sea, le garantiza que el umbral
de similitud está bien calibrado para no dejar
escapar esos falsos negativos que decíamos antes.
Exacto.
Lograr atrapar y reciclar la inmensa mayoría de
las preguntas sin gastar a lo tonto.
Fíjate que analizando el volumen de ingeniería que
hay detrás de todo esto, me doy cuenta
de algo muy profundo sobre la evolución de
la IA.
A ver, cuéntame.
Pues que mediáticamente todo el mundo habla de
construir redes neuronales cada vez más inmensas para
generar textos hipercomplejos en tiempo real.
Pero con herramientas como GPT-Caché apuntamos a una
estrategia totalmente opuesta.
En no usarlas, vaya.
Exacto.
La máxima prioridad arquitectónica para que estos negocios
sobrevivan es, paradójicamente, no tener que utilizar esa
espectacular capacidad de generación en tiempo real.
Es un desafío de diseño fascinante.
Dedicamos capitales ingentes a entrenar el razonamiento de
la máquina para inmediatamente destinar esfuerzos brutales a
desarrollar engranajes que impidan que razone.
Totalmente.
Y a medida que estas caches semánticas a
nivel global se sigan expandiendo y absorbiendo miles
de millones de interacciones… Es lógico prever que
el porcentaje de respuestas creadas verdaderamente desde cero
en ese instante se reducirá al mínimo.
El poder computacional puro se quedará solo para
instrucciones muy excepcionales o preguntas súper originales.
Sí, sí, combinaciones inéditas.
Y esto sugiere un horizonte donde nuestra experiencia
diaria con la IA cambiará.
Igual ya no estamos charlando con un mecanismo
que genera activamente ideas nuevas de la nada.
Sino que el sistema se convierte en una
vasta arquitectura de memoria artificial ultra optimizada.
Exacto.
La mayoría de las veces estaremos conversando con
un archivo monumental que simplemente recicla, ordena y
nos devuelve los fragmentos congelados de respuestas pasadas.
Dejamos esta reflexión sobre el futuro del almacenamiento
del conocimiento para que la audiencia le dé
unas cuantas vueltas.
Da que pensar, desde luego.
Antes de despedirnos hasta el próximo programa os
informamos de que las voces que oyes han
sido generadas por la IA de Notebook LM
y que dirigiendo el podcast se encuentra Julio
Pablo Vázquez un humano que te envía saludos
En caso de error probablemente sean errores humanos
¡Nos escuchamos!
Y hasta aquí el episodio de hoy Muchas
gracias por tu atención Esto es BIMPRAXIS Nos
escuchamos en el próximo episodio ¡Suscríbete al canal!