E069_Caché_semántica_y_de_prompts_en_IA

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, acelerando la IA, cómo las

memorias caché están salvando tiempo y dinero en

la era de los modelos de lenguaje.

Hola, ¿qué tal?

Un tema absolutamente vital hoy en día, la

verdad.

Totalmente.

A ver, para ponernos en situación, imaginemos un

escenario que, bueno, se ha vuelto peligrosamente común,

diría yo, en la industria tecnológica actual.

Uf, me lo veo venir.

Sí, sí.

Fíjate, un equipo de ingeniería lanzó una aplicación,

¿vale?

Respaldada por un modelo de lenguaje generativo masivo.

La herramienta resuelve una necesidad real, a la

gente le encanta, la adopción de usuarios se

dispara, la curva de crecimiento se vuelve vertical

y...

Y de repente llega el susto de fin

de mes.

Exacto.

Llega la primera factura de la infraestructura en

la nube y son, no sé, 50.000 euros.

Así, de golpe.

Madre mía, 50.000 euros que duelen físicamente.

Duelen, duelen mucho.

Y lo más sangrante del asunto, lo que

de verdad duele a nivel de ingeniería, es

que gran parte de ese presupuesto astronómico se

ha esfumado en generar respuestas que el modelo,

en la práctica, ya había procesado y calculado

horas antes para otros usuarios.

Claro, es que es la paradoja definitiva del

desarrollo actual.

O sea, el éxito masivo puede quebrar literalmente

un proyecto por culpa de una arquitectura ineficiente.

Es que morir de éxito nunca ha sido

tan literal, ¿no?

Totalmente.

Porque, a ver, el consumo de las APIs

de inteligencia artificial no funciona como el tráfico

web tradicional.

Aquí, la latencia y el coste financiero escalan

de forma lineal y vamos despiadada con cada

token generado.

Cada palabra es dinero.

Eso es.

Y frente a esta amenaza, pues la ingeniería

de software se ha visto obligada a implementar

unas capas de optimización muy, muy sofisticadas.

Que es justo nuestra misión de hoy.

Vamos a diseccionar a nivel técnico las dos

trincheras principales de esta batalla, ¿verdad?

Exacto.

Por un lado, tenemos la caché semántica para

las respuestas finales, que la vamos a ver

a través de un proyecto de código abierto

buenísimo llamado GPT-Caché.

Mmm, interesantísimo.

Y por otro lado, el almacenamiento en caché

pero del procesamiento de entrada, o sea, los

prompts, basándonos en un análisis técnico muy revelador

de IBM Technology.

Vale, pues vamos a empezar por lo básico,

porque el instinto más fundamental de la informática

para evitar recalcular cosas siempre ha sido la

memoria caché.

¿De toda la vida vamos?

Claro.

Si una base de datos ya ha devuelto

un resultado complejo, pues ese resultado se almacena

temporalmente y listo.

Pero el problema de aplicar esta lógica, así,

tan binaria, a los modelos de lenguaje es

que la caché tradicional opera bajo un régimen

de coincidencia léxica absoluta.

O sea, que tiene que ser exactamente la

misma letra, el mismo espacio, todo.

Eso es.

Yo lo veo como el funcionamiento de un

restaurante con un protocolo, digamos, extremadamente rígido.

A ver esa analogía.

Fíjate, si la primera comanda exige una hamburguesa

con queso, pues la cocina prepara el plato,

¿vale?

Vale.

Pero si el siguiente cliente entra y solicita

una hamburguesa que lleve queso, un sistema tradicional,

una caché clásica, descartaría el trabajo previo por

completo.

Claro, porque la cadena de texto no es

idéntica.

Exactamente.

Obligaría a la cocina a empezar el proceso

de elaboración desde cero, simplemente porque la cadena

de caracteres no coincide matemáticamente, aunque el cliente

quiera lo mismo.

Es que esa variabilidad infinita de la expresión

humana es lo que destroza por completo el

índice de aciertos, lo que llamamos el hit

ratio de las arquitecturas de caché clásicas.

O sea, un clúster de Redis normal y

corriente ahí no nos sirve de mucho.

No, porque evalúa hashes de texto plano.

Te dice, no es igual y ya está.

Y para solucionar esta ineficiencia tan crítica, aquí

es donde entra GPT Caché e introduce una

capa de evaluación algorítmica previa a la búsqueda.

Vale, o sea, ¿se pone en medio?

Exacto.

Intercepta la consulta.

En lugar de comparar letras, el sistema coge

la consulta del usuario y la procesa a

través de un modelo de embedding ligero.

Vale, la convierte en vectores.

Eso es.

Este modelo transforma la frase en un vector

denso.

Digamos, una matriz de números flotantes que representa

las coordenadas semánticas de esa frase en un

espacio multidimensional.

Suena a ciencia ficción, pero básicamente es que

el sistema deja de buscar palabras exactas y

empieza a calcular distancias matemáticas, ¿no?

El significado de fondo.

Totalmente.

Entiende el significado.

Si dos frases apuntan al mismo sitio en

ese espacio multidimensional, es que significan lo mismo.

Ya, claro.

Pero a ver, la conversión a vectores altera

las reglas del juego, sí.

Pero calcular esas distancias matemáticas entre cientos de

miles de registros en tiempo real, a mí

me suscita dudas sobre el rendimiento.

Es una duda superlógica.

Claro, porque si el objetivo primordial es reducir

la latencia, introducir un modelo intermedio que se

ponga a evaluar coordenadas suena a un proceso

que, no sé, podría generar su propio cuello

de botella.

Ya, parece contraproducente, ¿verdad?

Un poco, sí.

¿Cuál es el mecanismo exacto que permite que

esta evaluación no penalice el tiempo de respuesta

final y acabemos peor de lo que empezamos?

Pues la clave reside en la optimización bestial

de las bases de datos vectoriales y en

una métrica matemática que es la similitud de

cosenos.

El sistema no escanea toda la base de

datos de principio a fin, secuencialmente.

Eso sí que sería lento.

Emplea algoritmos de búsqueda aproximada de vecinos más

cercanos.

Digamos que estructuran el espacio vectorial en grafos

navegables.

Cuando la nueva consulta entra ya convertida en

un vector, el sistema calcula el ángulo entre

ese vector y los que ya tiene almacenados.

O sea, si el ángulo es muy cerrado,

es que está muy cerca, ¿no?

Exacto.

Un ángulo cerrado indica una altísima similitud semántica.

Y lo alucinante es que esta operación matemática

en arquitecturas especializadas ocurre en la escala de

los milisegundos.

¡Guau!

¡Milisegundos!

Sí, sí.

Si lo comparas con el proceso autoregresivo de

un modelo de lenguaje masivo, que, oye, tiene

que inferir, generar y proyectar las probabilidades del

siguiente token uno a uno, iterativamente… Claro, la

búsqueda vectorial le da mil vueltas en velocidad.

Órdenes de magnitud más veloz.

De hecho, los datos de implementación de GPT-Caché

reflejan una reducción de los costes operativos de

hasta 10 veces.

10 veces menos coste.

Y mejorando la velocidad de respuesta por un

factor de 100 en algunos casos.

Madre mía.

Pero claro, un salto de rendimiento de esa

magnitud requiere una monitorización exhaustiva.

Desplegar una capa semántica no es darle un

botón y olvidarse.

¿Qué va?

El mantenimiento exige vigilar métricas fundamentales para garantizar

que la caché no se vuelva loca y

esté devolviendo resultados imprecisos.

Claro.

Entiendo que el hit ratio, el porcentaje de

aciertos, marca la pauta de la rentabilidad financiera,

¿no?

Es decir, ¿qué porcentaje del tráfico nos estamos

comiendo sin tocar la API de pago?

Exacto, eso es el dinero que te ahorras

Y luego tienes la latencia, que básicamente te

confirma la mejora en la experiencia del usuario,

que la app va fluida Vale, pero hay

una tercera métrica, el recall, que me parece

la más delicada en un entorno así, tan

probabilístico Es que el recall lo es todo

para la robustez del sistema, fíjate Básicamente evalúa

la proporción de consultas que la Cachea atendió

correctamente Sobre el total de consultas que legítimamente

debería haber interceptado interceptado.

O sea, los aciertos reales.

Eso es.

Mira, si el umbral de similitud matemática lo

configuras de manera demasiado restrictiva, en plan tienen

que ser casi idénticas.

Pues el hit ratio se desploma y volvemos

a gastar recursos tontamente, claro.

Exacto.

Pero si el umbral es excesivamente laxo y

dejas pasar cualquier cosa que se parezca un

poco.

Uf, peligro.

Claro, el sistema pecará de falsos positivos.

Imagínate, entregando una respuesta sobre cómo hacer una

factura a un usuario que en realidad preguntaba

por reembolsos.

Un desastre para la experiencia del usuario.

O sea, calibrar esa sensibilidad es el núcleo

de la ingeniería de la caché semántica, por

lo que veo.

Es el arte detrás de todo esto totalmente.

Y al trasladar esa calibración a una infraestructura

de producción real, supongo que la flexibilidad de

la herramienta se vuelve crítica, porque a menudo

adoptar nuevas capas de optimización conlleva el riesgo

de quedarte atrapado en un ecosistema propietario.

El temido vendor locking, sí.

Eso es.

Si mi equipo ya ha diseñado su arquitectura

usando, no sé, llama.cpp para ejecutar inferencia en

local o depende de modelos muy específicos en

la nube, pues que me impongan un adaptador

único suele ser motivo de descarte inmediato.

Y con razón.

Pero precisamente por ello, la arquitectura de GPTKH

se ha diseñado bajo un paradigma estrictamente modular.

No es un bloque monolítico.

Vale, me gusta eso.

Es un poco como montar un ordenador a

piezas, ¿no?

Un PC custom.

Justo.

Es una analogía perfecta.

El sistema desacopla totalmente la lógica del almacenamiento

de la interfaz del modelo.

Tú eliges las piezas.

O sea, yo elijo mi tarjeta gráfica, que

sería el LLM.

Exacto.

El módulo del adaptador de LLM te permite

rutear las peticiones hacia la API de OpenAI,

hacia implementaciones de launching o entornos locales sin

ninguna fricción.

Qué bueno.

Y ojo que no solo hay texto.

Tienen un adaptador multimodal.

¿Multimodal?

Para imágenes y audio.

Sí, sí.

Operaciones masivamente pesadas como la síntesis de imágenes

en Stable Diffusion o transcripciones de audio larguísimas

con Whisper, todo eso puede beneficiarse de la

misma retención semántica.

Claro, te evitas regenerar exactamente el mismo activo

multimedia si la petición es análoga.

Es un ahorro brutal.

Brutal.

Pero volviendo a la analogía del PC, ese

nivel de modularidad requiere tomar decisiones sobre el

hardware, sobre dónde residen físicamente esos datos.

Veo que la arquitectura separa claramente el lugar

donde se guardan los vectores, el vector store,

del lugar donde reside la respuesta cruda, el

texto final, que sería el Caché storage, o

sea, el disco duro.

Exactamente.

Herramientas como Faiz o Milbus se encargan de

toda esa matemática vectorial rápida, mientras que bases

de datos transaccionales de toda la vida, como

Postgres, custodian los textos de salida.

Pero claro, esta separación plantea el ineludible problema

de la saturación bajo carga masiva, porque la

memoria RAM es la que es, es un

recurso finito y bastante costoso, por cierto.

Ya te digo, la degradación del rendimiento por

saturación de memoria.

Los famosos errores OOM, Out of Memory.

Las pesadillas de los de sistemas.

Es el punto de fallo más habitual en

implementaciones ingenuas, fíjate.

Si la aplicación experimenta un pico de tráfico

por un evento externo, oye, la caché crecerá

a un ritmo exponencial.

Y depender exclusivamente de la memoria local de

un único servidor te garantiza un colapso.

Matemático.

Por eso, gestionar el ciclo de vida de

los datos exige implementar políticas de expulsión agresivas.

O sea, tirar cosas a la basura.

Claro.

El algoritmo LRU, por ejemplo, que descarta los

elementos que llevan más tiempo sin ser consultados,

es súper efectivo en apps de cara al

público, donde el tráfico suele ir por modas

o temas de actualidad.

Ya, lo viejo se borra.

Y supongo que, para evitar la redundancia y

asegurar alta disponibilidad, pues la arquitectura debe escalar

horizontalmente.

Sí o sí.

Desplegar una Caché distribuida apoyándose en sistemas probados

como Memcached o Redis.

O sea, que todo un clúster de servidores

comparta un único cerebro, un estado único.

Si un servidor en Europa calcula y guarda

una respuesta muy compleja, cualquier otro nodo, a

nivel global, en Asia o América, hereda ese

acceso instantáneamente.

Neutralizando la necesidad de duplicar el esfuerzo y

protegiendo la memoria de cada máquina.

Brillante.

Es una infraestructura que resuelve magistralmente la redundancia

en las respuestas finales.

Pero.

Ah, amigo, siempre hay un pero.

Siempre.

Porque todo esto de GPT-Caché es genial si

los usuarios hacen preguntas parecidas.

Pero, ¿qué pasa si cambiamos las reglas?

A ver.

Analicemos el escenario del RAG, el Retrieval Augmented

Generation.

En estos sistemas, inyectamos documentos masivos, a veces

decenas de miles de palabras, en la ventana

de contexto de la IA.

Sí, para fundamentar la respuesta y que no

alucine.

Exacto.

Pues imagínate que un usuario le mete a

la IA un manual técnico de 100 páginas

y le hace una pregunta súper específica sobre

el capítulo 3.

Vale.

Y 10 minutos después, el mismo usuario u

otro, con el mismo manual, le hace una

pregunta completamente diferente sobre el glosario final.

Claro.

La caché semántica de resultados aquí falla estrepitosamente

porque las respuestas que tiene que dar la

IA deben ser distintas.

Sí, sí, irremediablemente.

Porque las salidas esperadas son divergentes.

Entonces la perspectiva cambia por completo.

Ya no buscamos reciclar el plato ya cocinado.

Buscamos otra cosa, que es lo que explica

la documentación de IBM, ¿no?

El prompt caching.

Eso es, el almacenamiento en caché de entradas.

Que yo lo asocio mucho con la mise

en place, en la alta gastronomía.

Me encanta, explícalo.

Pues a ver, si la caché semántica era

una nevela donde guardabas el plato ya terminado

y solo lo calentabas.

El prompt caching es todo el trabajo preparatorio

de la cocina.

El equipo ya ha picado la cebolla, ha

hecho los caldos, tiene las salsas listas… Todo

organizado.

Exacto.

Si entra una comanda de un plato diferente

pero que usa esa base, esos mismos caldos,

te ahorras el 90% del trabajo pesado.

Es que el concepto de la mise en

place captura literalmente la esencia de la fase

de prellenado o el pre-fill en la arquitectura

de los transformers.

A ver, explícanos un poco las tripas de

eso.

Pues para entender el ahorro hay que visualizar

el mecanismo interno del LLM.

Cuando ese manual de 100 páginas entra al

sistema, el modelo no empieza a escribir texto

de inmediato.

No es magia, claro.

Para nada.

Los mecanismos de atención de la red neuronal

tienen que calcular la relación de cada token

con todos y cada uno de los tokens

precedentes.

O sea, entender el contexto de la palabra

tornillo en la página 50 respecto a la

página 2.

Eso es.

Y ese proceso requiere computar unas matrices gigantescas

que se conocen como pares clave-valor, los KV

pairs.

Y supongo que esa computación se adentra en

el territorio de la complejidad cuadrática, ¿no?

Porque si evaluamos 50.000 tokens simultáneamente… Las matemáticas

se disparan.

El número de operaciones de multiplicación de matrices

que la GPU tiene que comerse alcanza cifras

astronómicas.

Madre mía.

Y ojo, que esto se repite en cada

una de las capas ocultas del transformer.

El desgaste de ciclos de procesamiento es absoluto.

Y, claro, como los modelos por defecto no

tienen memoria de estado, si le mandas la

segunda pregunta con el mismo manual adjunto, la

IA desecha todo lo de antes.

Todo a la basura.

Inicia el cómputo masivo de los pares clave-valor

desde la primera letra del manual.

¡Qué ineficiencia!

Entonces el prompt caching interviene ahí.

Exacto.

Interceptando y guardando estas matrices de atención en

la memoria VRAM a altísima velocidad de la

GPU.

Al detectar que un bloque de texto coincide

con uno recién procesado, el sistema carga ese

estado precalculado.

Ah, o sea, recupera el contexto ya en

formato matemático.

Y así solo se esfuerza en calcular los

tokens nuevos, es decir, la preguntita nueva del

usuario.

Eso es.

Pura eficiencia.

El impacto en la latencia tiene que ser

brutal, claro.

pero exija una precisión, digamos, quirúrgica.

El sistema tiene que saber rapidísimo qué parte

recicla y qué parte es nueva.

Sí, y aquí es donde las reglas del

juego se ponen estrictas.

Para discriminar esto, se usa la técnica de

coincidencia de prefijos, el prefix matching.

Que evalúa de izquierda a derecha, entiendo.

Estrictamente secuencial.

Construye como una estructura de árbol.

El motor recorre la instrucción nueva token a

token.

Mientras todo sea idéntico a lo que hay

en caché, recicla los pares KV.

Vale.

Pero la severidad de esto es que, en

el instante en que detecta un solo token

distinto, un carácter, un espacio extra, un salto

de línea cambiado, se rompe la magia.

Se rompe de forma irreversible.

Desde ese punto de divergencia hacia adelante, te

obliga a ejecutar el cómputo completo otra vez.

¡Guau!

O sea que esta rigidez obliga a los

desarrolladores a replantear la ingeniería de los prompts

desde los cimientos.

Totalmente.

Ya no es cómo escribes para que suene

bonito, es que la sintaxis determina la rentabilidad

financiera de tu empresa.

Es que hay una regla de oro aquí,

¿no?

La información debe organizarse en un gradiente estricto,

de lo más estático a lo más dinámico.

Eso es fundamental que la audiencia se lo

grave a fuego.

Sí, sí.

O sea, lo que no cambia, arriba del

todo.

La arquitectura óptima exige que consolides todos los

bloques invariables en la cabecera.

Instrucciones del sistema, en plan, eres un asistente

útil, el contexto kilométrico del manual, los ejemplos

estáticos.

Todo eso primero.

En los primeros estratos.

Y la consulta específica y efímera del usuario,

la pregunta, debe ir estrictamente confinada al final

del documento.

Porque si inviertes el orden, catástrofe.

Si un desarrollador pone la pregunta del usuario

en la primera línea y luego le pega

el manual de 100 páginas.

Pues que el primer token generado por cada

usuario va a ser diferente siempre.

Y el prefix matching falla en el milisegundo

1.

Invalidas la posibilidad de recuperar el bloque gigante

que va detrás.

Exacto.

Un simple error de concatenar strings en el

código y te has cargado la eficiencia de

toda la infraestructura.

Apagar el cálculo estático en cada petición.

¡Qué locura!

Pero, viendo lo elegante que es esta solución,

a mí me surge una duda.

¿Por qué no guardamos en caché el contexto

de absolutamente todo?

A ver, explícate.

Pues si un usuario le dice hola a

un bot.

Tres palabras.

La intuición me dice que guardar esos pares

KB también sería optimizar.

Todo suma, ¿no?

Ya, pero en sistemas distribuidos ninguna abstracción te

sale gratis.

Claro, el sobrecoste de gestionar la propia caché.

Exacto.

Indexar, almacenar en memoria compartida, buscar y transferir

las matrices a la GPU.

Todo eso añade latencia y coste.

O sea, hay un umbral de rentabilidad.

Sí, los proveedores principales suelen establecer la barrera

en unos 1024 tokens de entrada.

Para secuencias más cortas que eso, tardas más

en buscar en la caché que en dejar

que el modelo lo procese en bruto.

Tiene sentido.

Y me imagino que esta mise en place

digital es efímera, no dura para siempre.

Para nada.

Para no saturar el hardware, operan con políticas

de expiración súper agresivas, purgando todo tras 5

o 10 minutos de inactividad.

O sea, optimizan sesiones densas y rápidas, no

un histórico a largo plazo.

Exacto.

Al final, la lógica de la alta cocina

prevalece.

Cuando el servicio acaba, el chef ordena limpiar

la estación, tira los ingredientes preparados y recupera

el control de su encimera.

Es una analogía brillante, sí.

Encapsula perfectamente el ciclo de vida del procesamiento

en redes neuronales.

Y fíjate, contemplar esta evolución hacia la retención

semántica y estructural a mí me empuja hacia

una reflexión mucho más profunda.

A ver, cuéntame.

Pues sobre la naturaleza futura de estos sistemas.

Porque si las arquitecturas siguen perfeccionando esto, guardando

contexto de entrada y semántica de salida, nos

acercamos a un horizonte de hipereficiencia muy bestia.

Y cabe plantearse si los grandes modelos masivos

van a ir reduciendo progresivamente su, digamos, generación

estocástica real.

Se acabarán operando, en la práctica, como gigantescos

repositorios indexados que simplemente actúan como bibliotecarios.

Recuperando pensamientos precalculados del pasado.

A la velocidad de la luz, para el

99% de nuestras interacciones cotidianas.

¡Qué barbaridad!

Resulta fascinante reconsiderar así la generación del lenguaje.

Lo que desde fuera parece, no sé, una

IA, pensando en tiempo real, bajo el capó

se transforma en una labor monumental de recuperación

de estados almacenados.

Exacto.

Una coreografía compleja donde la verdadera magia reside

en evitar pensar la misma idea dos veces.

Es una perspectiva reveladora sobre la eficiencia matemática

de esta revolución.

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.