1
00:00:10,000 --> 00:00:15,800
Buenas, esto es BIMPRAXIS, el podcast donde el

2
00:00:15,800 --> 00:00:17,920
BIM se encuentra con la inteligencia artificial.

3
00:00:20,519 --> 00:00:23,620
Exploramos la ciencia, la tecnología y el futuro

4
00:00:23,620 --> 00:00:26,559
desde el enfoque de la arquitectura, ingeniería y

5
00:00:26,559 --> 00:00:27,179
construcción.

6
00:00:28,859 --> 00:00:29,519
¡Empezamos!

7
00:00:37,320 --> 00:00:40,439
Muy buenas, bienvenidas, bienvenidos a un nuevo episodio

8
00:00:40,439 --> 00:00:42,179
de BIMPRAXIS.

9
00:00:42,179 --> 00:00:45,179
Hoy os traemos, acelerando la IA, cómo las

10
00:00:45,179 --> 00:00:48,359
memorias caché están salvando tiempo y dinero en

11
00:00:48,359 --> 00:00:49,820
la era de los modelos de lenguaje.

12
00:00:50,439 --> 00:00:50,979
Hola, ¿qué tal?

13
00:00:50,979 --> 00:00:53,560
Un tema absolutamente vital hoy en día, la

14
00:00:53,560 --> 00:00:54,240
verdad.

15
00:00:54,219 --> 00:00:55,240
Totalmente.

16
00:00:55,240 --> 00:00:57,759
A ver, para ponernos en situación, imaginemos un

17
00:00:57,759 --> 00:01:01,119
escenario que, bueno, se ha vuelto peligrosamente común,

18
00:01:01,119 --> 00:01:03,460
diría yo, en la industria tecnológica actual.

19
00:01:03,460 --> 00:01:04,900
Uf, me lo veo venir.

20
00:01:04,939 --> 00:01:05,620
Sí, sí.

21
00:01:05,620 --> 00:01:08,420
Fíjate, un equipo de ingeniería lanzó una aplicación,

22
00:01:08,420 --> 00:01:09,239
¿vale?

23
00:01:09,239 --> 00:01:12,859
Respaldada por un modelo de lenguaje generativo masivo.

24
00:01:12,859 --> 00:01:15,340
La herramienta resuelve una necesidad real, a la

25
00:01:15,340 --> 00:01:17,659
gente le encanta, la adopción de usuarios se

26
00:01:17,659 --> 00:01:20,299
dispara, la curva de crecimiento se vuelve vertical

27
00:01:20,299 --> 00:01:20,859
y...

28
00:01:20,859 --> 00:01:23,099
Y de repente llega el susto de fin

29
00:01:23,099 --> 00:01:23,760
de mes.

30
00:01:23,760 --> 00:01:24,859
Exacto.

31
00:01:24,859 --> 00:01:26,959
Llega la primera factura de la infraestructura en

32
00:01:26,959 --> 00:01:30,019
la nube y son, no sé, 50.000 euros.

33
00:01:29,959 --> 00:01:30,920
Así, de golpe.

34
00:01:30,980 --> 00:01:33,859
Madre mía, 50.000 euros que duelen físicamente.

35
00:01:33,780 --> 00:01:35,599
Duelen, duelen mucho.

36
00:01:35,640 --> 00:01:37,780
Y lo más sangrante del asunto, lo que

37
00:01:37,780 --> 00:01:40,459
de verdad duele a nivel de ingeniería, es

38
00:01:40,459 --> 00:01:42,920
que gran parte de ese presupuesto astronómico se

39
00:01:42,920 --> 00:01:45,959
ha esfumado en generar respuestas que el modelo,

40
00:01:45,959 --> 00:01:49,000
en la práctica, ya había procesado y calculado

41
00:01:49,000 --> 00:01:50,700
horas antes para otros usuarios.

42
00:01:51,299 --> 00:01:53,200
Claro, es que es la paradoja definitiva del

43
00:01:53,200 --> 00:01:54,540
desarrollo actual.

44
00:01:54,700 --> 00:01:57,540
O sea, el éxito masivo puede quebrar literalmente

45
00:01:57,540 --> 00:02:00,280
un proyecto por culpa de una arquitectura ineficiente.

46
00:02:00,260 --> 00:02:01,959
Es que morir de éxito nunca ha sido

47
00:02:01,959 --> 00:02:02,939
tan literal, ¿no?

48
00:02:03,079 --> 00:02:04,019
Totalmente.

49
00:02:04,019 --> 00:02:06,180
Porque, a ver, el consumo de las APIs

50
00:02:06,180 --> 00:02:08,759
de inteligencia artificial no funciona como el tráfico

51
00:02:08,759 --> 00:02:09,419
web tradicional.

52
00:02:10,719 --> 00:02:13,360
Aquí, la latencia y el coste financiero escalan

53
00:02:13,360 --> 00:02:16,360
de forma lineal y vamos despiadada con cada

54
00:02:16,360 --> 00:02:17,699
token generado.

55
00:02:17,319 --> 00:02:19,000
Cada palabra es dinero.

56
00:02:18,939 --> 00:02:19,819
Eso es.

57
00:02:19,819 --> 00:02:21,580
Y frente a esta amenaza, pues la ingeniería

58
00:02:21,580 --> 00:02:23,520
de software se ha visto obligada a implementar

59
00:02:23,520 --> 00:02:27,240
unas capas de optimización muy, muy sofisticadas.

60
00:02:27,180 --> 00:02:29,960
Que es justo nuestra misión de hoy.

61
00:02:29,960 --> 00:02:33,199
Vamos a diseccionar a nivel técnico las dos

62
00:02:33,199 --> 00:02:36,139
trincheras principales de esta batalla, ¿verdad?

63
00:02:36,080 --> 00:02:37,199
Exacto.

64
00:02:37,199 --> 00:02:39,400
Por un lado, tenemos la caché semántica para

65
00:02:39,400 --> 00:02:41,879
las respuestas finales, que la vamos a ver

66
00:02:41,879 --> 00:02:43,599
a través de un proyecto de código abierto

67
00:02:43,599 --> 00:02:45,500
buenísimo llamado GPT-Caché.

68
00:02:45,819 --> 00:02:47,759
Mmm, interesantísimo.

69
00:02:48,099 --> 00:02:50,479
Y por otro lado, el almacenamiento en caché

70
00:02:50,479 --> 00:02:53,139
pero del procesamiento de entrada, o sea, los

71
00:02:53,139 --> 00:02:56,259
prompts, basándonos en un análisis técnico muy revelador

72
00:02:56,259 --> 00:02:57,620
de IBM Technology.

73
00:02:58,240 --> 00:03:00,620
Vale, pues vamos a empezar por lo básico,

74
00:03:00,620 --> 00:03:03,379
porque el instinto más fundamental de la informática

75
00:03:03,379 --> 00:03:06,560
para evitar recalcular cosas siempre ha sido la

76
00:03:06,560 --> 00:03:07,680
memoria caché.

77
00:03:07,680 --> 00:03:08,580
¿De toda la vida vamos?

78
00:03:08,780 --> 00:03:09,639
Claro.

79
00:03:09,639 --> 00:03:11,240
Si una base de datos ya ha devuelto

80
00:03:11,240 --> 00:03:14,020
un resultado complejo, pues ese resultado se almacena

81
00:03:14,020 --> 00:03:15,560
temporalmente y listo.

82
00:03:16,099 --> 00:03:18,599
Pero el problema de aplicar esta lógica, así,

83
00:03:18,599 --> 00:03:20,840
tan binaria, a los modelos de lenguaje es

84
00:03:20,840 --> 00:03:23,460
que la caché tradicional opera bajo un régimen

85
00:03:23,460 --> 00:03:26,080
de coincidencia léxica absoluta.

86
00:03:25,800 --> 00:03:28,120
O sea, que tiene que ser exactamente la

87
00:03:28,120 --> 00:03:30,939
misma letra, el mismo espacio, todo.

88
00:03:30,780 --> 00:03:31,879
Eso es.

89
00:03:31,879 --> 00:03:33,699
Yo lo veo como el funcionamiento de un

90
00:03:33,699 --> 00:03:38,000
restaurante con un protocolo, digamos, extremadamente rígido.

91
00:03:37,599 --> 00:03:38,719
A ver esa analogía.

92
00:03:38,780 --> 00:03:41,520
Fíjate, si la primera comanda exige una hamburguesa

93
00:03:41,520 --> 00:03:44,340
con queso, pues la cocina prepara el plato,

94
00:03:44,340 --> 00:03:44,460
¿vale?

95
00:03:44,620 --> 00:03:45,159
Vale.

96
00:03:45,159 --> 00:03:47,439
Pero si el siguiente cliente entra y solicita

97
00:03:47,439 --> 00:03:51,259
una hamburguesa que lleve queso, un sistema tradicional,

98
00:03:51,259 --> 00:03:54,360
una caché clásica, descartaría el trabajo previo por

99
00:03:54,360 --> 00:03:55,219
completo.

100
00:03:55,020 --> 00:03:56,900
Claro, porque la cadena de texto no es

101
00:03:56,900 --> 00:03:57,900
idéntica.

102
00:03:57,520 --> 00:03:58,840
Exactamente.

103
00:03:58,840 --> 00:04:00,939
Obligaría a la cocina a empezar el proceso

104
00:04:00,939 --> 00:04:04,159
de elaboración desde cero, simplemente porque la cadena

105
00:04:04,159 --> 00:04:07,479
de caracteres no coincide matemáticamente, aunque el cliente

106
00:04:07,479 --> 00:04:08,460
quiera lo mismo.

107
00:04:08,460 --> 00:04:11,680
Es que esa variabilidad infinita de la expresión

108
00:04:11,680 --> 00:04:13,800
humana es lo que destroza por completo el

109
00:04:13,800 --> 00:04:16,459
índice de aciertos, lo que llamamos el hit

110
00:04:16,459 --> 00:04:19,259
ratio de las arquitecturas de caché clásicas.

111
00:04:19,259 --> 00:04:20,920
O sea, un clúster de Redis normal y

112
00:04:20,920 --> 00:04:22,819
corriente ahí no nos sirve de mucho.

113
00:04:22,819 --> 00:04:26,060
No, porque evalúa hashes de texto plano.

114
00:04:26,060 --> 00:04:28,120
Te dice, no es igual y ya está.

115
00:04:28,120 --> 00:04:31,500
Y para solucionar esta ineficiencia tan crítica, aquí

116
00:04:31,500 --> 00:04:34,079
es donde entra GPT Caché e introduce una

117
00:04:34,079 --> 00:04:37,100
capa de evaluación algorítmica previa a la búsqueda.

118
00:04:37,100 --> 00:04:38,259
Vale, o sea, ¿se pone en medio?

119
00:04:38,259 --> 00:04:39,199
Exacto.

120
00:04:39,199 --> 00:04:40,779
Intercepta la consulta.

121
00:04:40,899 --> 00:04:42,819
En lugar de comparar letras, el sistema coge

122
00:04:42,819 --> 00:04:44,699
la consulta del usuario y la procesa a

123
00:04:44,699 --> 00:04:46,759
través de un modelo de embedding ligero.

124
00:04:46,759 --> 00:04:49,620
Vale, la convierte en vectores.

125
00:04:49,620 --> 00:04:50,680
Eso es.

126
00:04:50,680 --> 00:04:52,800
Este modelo transforma la frase en un vector

127
00:04:52,800 --> 00:04:53,819
denso.

128
00:04:53,819 --> 00:04:56,420
Digamos, una matriz de números flotantes que representa

129
00:04:56,420 --> 00:04:58,779
las coordenadas semánticas de esa frase en un

130
00:04:58,779 --> 00:05:00,540
espacio multidimensional.

131
00:05:00,540 --> 00:05:02,879
Suena a ciencia ficción, pero básicamente es que

132
00:05:02,879 --> 00:05:05,579
el sistema deja de buscar palabras exactas y

133
00:05:05,579 --> 00:05:07,939
empieza a calcular distancias matemáticas, ¿no?

134
00:05:08,279 --> 00:05:09,759
El significado de fondo.

135
00:05:09,740 --> 00:05:10,600
Totalmente.

136
00:05:10,600 --> 00:05:12,199
Entiende el significado.

137
00:05:12,240 --> 00:05:14,339
Si dos frases apuntan al mismo sitio en

138
00:05:14,339 --> 00:05:17,740
ese espacio multidimensional, es que significan lo mismo.

139
00:05:17,600 --> 00:05:18,839
Ya, claro.

140
00:05:18,839 --> 00:05:21,180
Pero a ver, la conversión a vectores altera

141
00:05:21,180 --> 00:05:22,819
las reglas del juego, sí.

142
00:05:22,860 --> 00:05:26,060
Pero calcular esas distancias matemáticas entre cientos de

143
00:05:26,060 --> 00:05:29,420
miles de registros en tiempo real, a mí

144
00:05:29,420 --> 00:05:31,699
me suscita dudas sobre el rendimiento.

145
00:05:31,500 --> 00:05:32,699
Es una duda superlógica.

146
00:05:33,040 --> 00:05:35,920
Claro, porque si el objetivo primordial es reducir

147
00:05:35,920 --> 00:05:38,920
la latencia, introducir un modelo intermedio que se

148
00:05:38,880 --> 00:05:41,360
ponga a evaluar coordenadas suena a un proceso

149
00:05:41,360 --> 00:05:43,720
que, no sé, podría generar su propio cuello

150
00:05:43,720 --> 00:05:44,700
de botella.

151
00:05:44,640 --> 00:05:46,840
Ya, parece contraproducente, ¿verdad?

152
00:05:46,880 --> 00:05:47,980
Un poco, sí.

153
00:05:48,100 --> 00:05:50,280
¿Cuál es el mecanismo exacto que permite que

154
00:05:50,280 --> 00:05:52,620
esta evaluación no penalice el tiempo de respuesta

155
00:05:52,620 --> 00:05:54,780
final y acabemos peor de lo que empezamos?

156
00:05:54,420 --> 00:05:57,680
Pues la clave reside en la optimización bestial

157
00:05:57,680 --> 00:05:59,860
de las bases de datos vectoriales y en

158
00:05:59,860 --> 00:06:02,200
una métrica matemática que es la similitud de

159
00:06:02,200 --> 00:06:03,040
cosenos.

160
00:06:02,720 --> 00:06:05,020
El sistema no escanea toda la base de

161
00:06:05,020 --> 00:06:07,940
datos de principio a fin, secuencialmente.

162
00:06:07,940 --> 00:06:09,660
Eso sí que sería lento.

163
00:06:09,660 --> 00:06:12,240
Emplea algoritmos de búsqueda aproximada de vecinos más

164
00:06:12,240 --> 00:06:14,040
cercanos.

165
00:06:14,040 --> 00:06:16,420
Digamos que estructuran el espacio vectorial en grafos

166
00:06:16,420 --> 00:06:17,480
navegables.

167
00:06:17,480 --> 00:06:19,600
Cuando la nueva consulta entra ya convertida en

168
00:06:19,600 --> 00:06:21,820
un vector, el sistema calcula el ángulo entre

169
00:06:21,820 --> 00:06:23,700
ese vector y los que ya tiene almacenados.

170
00:06:23,920 --> 00:06:25,740
O sea, si el ángulo es muy cerrado,

171
00:06:25,740 --> 00:06:27,020
es que está muy cerca, ¿no?

172
00:06:27,040 --> 00:06:28,080
Exacto.

173
00:06:28,080 --> 00:06:31,780
Un ángulo cerrado indica una altísima similitud semántica.

174
00:06:31,780 --> 00:06:33,640
Y lo alucinante es que esta operación matemática

175
00:06:33,640 --> 00:06:36,740
en arquitecturas especializadas ocurre en la escala de

176
00:06:36,740 --> 00:06:37,520
los milisegundos.

177
00:06:37,860 --> 00:06:38,300
¡Guau!

178
00:06:38,300 --> 00:06:39,120
¡Milisegundos!

179
00:06:39,380 --> 00:06:40,140
Sí, sí.

180
00:06:40,140 --> 00:06:42,340
Si lo comparas con el proceso autoregresivo de

181
00:06:42,340 --> 00:06:44,660
un modelo de lenguaje masivo, que, oye, tiene

182
00:06:44,660 --> 00:06:47,440
que inferir, generar y proyectar las probabilidades del

183
00:06:47,440 --> 00:06:50,680
siguiente token uno a uno, iterativamente… Claro, la

184
00:06:50,680 --> 00:06:53,420
búsqueda vectorial le da mil vueltas en velocidad.

185
00:06:53,160 --> 00:06:55,340
Órdenes de magnitud más veloz.

186
00:06:55,340 --> 00:06:58,420
De hecho, los datos de implementación de GPT-Caché

187
00:06:58,420 --> 00:07:01,820
reflejan una reducción de los costes operativos de

188
00:07:01,820 --> 00:07:03,180
hasta 10 veces.

189
00:07:03,340 --> 00:07:05,140
10 veces menos coste.

190
00:07:05,200 --> 00:07:06,980
Y mejorando la velocidad de respuesta por un

191
00:07:06,980 --> 00:07:08,940
factor de 100 en algunos casos.

192
00:07:08,940 --> 00:07:09,740
Madre mía.

193
00:07:09,740 --> 00:07:12,800
Pero claro, un salto de rendimiento de esa

194
00:07:12,800 --> 00:07:15,860
magnitud requiere una monitorización exhaustiva.

195
00:07:16,040 --> 00:07:18,160
Desplegar una capa semántica no es darle un

196
00:07:18,160 --> 00:07:19,540
botón y olvidarse.

197
00:07:19,680 --> 00:07:20,180
¿Qué va?

198
00:07:20,180 --> 00:07:24,100
El mantenimiento exige vigilar métricas fundamentales para garantizar

199
00:07:24,100 --> 00:07:26,280
que la caché no se vuelva loca y

200
00:07:26,280 --> 00:07:28,360
esté devolviendo resultados imprecisos.

201
00:07:28,480 --> 00:07:29,340
Claro.

202
00:07:29,340 --> 00:07:32,480
Entiendo que el hit ratio, el porcentaje de

203
00:07:32,480 --> 00:07:35,480
aciertos, marca la pauta de la rentabilidad financiera,

204
00:07:35,480 --> 00:07:35,640
¿no?

205
00:07:35,640 --> 00:07:38,900
Es decir, ¿qué porcentaje del tráfico nos estamos

206
00:07:38,900 --> 00:07:40,780
comiendo sin tocar la API de pago?

207
00:07:40,580 --> 00:07:43,580
Exacto, eso es el dinero que te ahorras

208
00:07:43,580 --> 00:07:46,360
Y luego tienes la latencia, que básicamente te

209
00:07:46,360 --> 00:07:48,720
confirma la mejora en la experiencia del usuario,

210
00:07:48,720 --> 00:07:51,200
que la app va fluida Vale, pero hay

211
00:07:51,200 --> 00:07:54,320
una tercera métrica, el recall, que me parece

212
00:07:54,320 --> 00:07:56,760
la más delicada en un entorno así, tan

213
00:07:56,760 --> 00:07:59,240
probabilístico Es que el recall lo es todo

214
00:07:59,240 --> 00:08:02,800
para la robustez del sistema, fíjate Básicamente evalúa

215
00:08:02,800 --> 00:08:05,360
la proporción de consultas que la Cachea atendió

216
00:08:05,360 --> 00:08:09,100
correctamente Sobre el total de consultas que legítimamente

217
00:08:09,100 --> 00:08:10,860
debería haber interceptado interceptado.

218
00:08:10,860 --> 00:08:12,800
O sea, los aciertos reales.

219
00:08:12,800 --> 00:08:13,980
Eso es.

220
00:08:13,980 --> 00:08:16,540
Mira, si el umbral de similitud matemática lo

221
00:08:16,500 --> 00:08:19,560
configuras de manera demasiado restrictiva, en plan tienen

222
00:08:19,560 --> 00:08:20,920
que ser casi idénticas.

223
00:08:20,920 --> 00:08:23,660
Pues el hit ratio se desploma y volvemos

224
00:08:23,660 --> 00:08:25,840
a gastar recursos tontamente, claro.

225
00:08:25,840 --> 00:08:26,400
Exacto.

226
00:08:26,400 --> 00:08:29,340
Pero si el umbral es excesivamente laxo y

227
00:08:29,340 --> 00:08:31,420
dejas pasar cualquier cosa que se parezca un

228
00:08:31,420 --> 00:08:31,960
poco.

229
00:08:31,960 --> 00:08:33,020
Uf, peligro.

230
00:08:33,020 --> 00:08:36,300
Claro, el sistema pecará de falsos positivos.

231
00:08:36,300 --> 00:08:39,080
Imagínate, entregando una respuesta sobre cómo hacer una

232
00:08:39,120 --> 00:08:41,340
factura a un usuario que en realidad preguntaba

233
00:08:41,340 --> 00:08:42,240
por reembolsos.

234
00:08:42,240 --> 00:08:44,800
Un desastre para la experiencia del usuario.

235
00:08:44,800 --> 00:08:48,180
O sea, calibrar esa sensibilidad es el núcleo

236
00:08:48,180 --> 00:08:50,360
de la ingeniería de la caché semántica, por

237
00:08:50,360 --> 00:08:51,400
lo que veo.

238
00:08:51,400 --> 00:08:53,920
Es el arte detrás de todo esto totalmente.

239
00:08:53,920 --> 00:08:56,740
Y al trasladar esa calibración a una infraestructura

240
00:08:56,740 --> 00:08:59,760
de producción real, supongo que la flexibilidad de

241
00:08:59,760 --> 00:09:02,720
la herramienta se vuelve crítica, porque a menudo

242
00:09:02,720 --> 00:09:05,860
adoptar nuevas capas de optimización conlleva el riesgo

243
00:09:05,860 --> 00:09:09,020
de quedarte atrapado en un ecosistema propietario.

244
00:09:09,020 --> 00:09:11,100
El temido vendor locking, sí.

245
00:09:11,100 --> 00:09:11,960
Eso es.

246
00:09:11,960 --> 00:09:14,120
Si mi equipo ya ha diseñado su arquitectura

247
00:09:14,120 --> 00:09:17,880
usando, no sé, llama.cpp para ejecutar inferencia en

248
00:09:17,880 --> 00:09:20,720
local o depende de modelos muy específicos en

249
00:09:20,720 --> 00:09:23,000
la nube, pues que me impongan un adaptador

250
00:09:23,000 --> 00:09:25,880
único suele ser motivo de descarte inmediato.

251
00:09:25,880 --> 00:09:27,080
Y con razón.

252
00:09:27,080 --> 00:09:29,920
Pero precisamente por ello, la arquitectura de GPTKH

253
00:09:29,920 --> 00:09:32,900
se ha diseñado bajo un paradigma estrictamente modular.

254
00:09:32,900 --> 00:09:34,400
No es un bloque monolítico.

255
00:09:34,400 --> 00:09:35,680
Vale, me gusta eso.

256
00:09:35,680 --> 00:09:37,500
Es un poco como montar un ordenador a

257
00:09:37,500 --> 00:09:38,200
piezas, ¿no?

258
00:09:38,100 --> 00:09:39,280
Un PC custom.

259
00:09:39,340 --> 00:09:40,020
Justo.

260
00:09:40,040 --> 00:09:41,700
Es una analogía perfecta.

261
00:09:41,740 --> 00:09:44,900
El sistema desacopla totalmente la lógica del almacenamiento

262
00:09:44,580 --> 00:09:46,380
de la interfaz del modelo.

263
00:09:46,740 --> 00:09:47,980
Tú eliges las piezas.

264
00:09:47,780 --> 00:09:49,820
O sea, yo elijo mi tarjeta gráfica, que

265
00:09:49,820 --> 00:09:51,500
sería el LLM.

266
00:09:51,200 --> 00:09:52,160
Exacto.

267
00:09:51,860 --> 00:09:54,120
El módulo del adaptador de LLM te permite

268
00:09:54,120 --> 00:09:56,960
rutear las peticiones hacia la API de OpenAI,

269
00:09:56,900 --> 00:09:59,660
hacia implementaciones de launching o entornos locales sin

270
00:09:59,180 --> 00:10:00,920
ninguna fricción.

271
00:10:00,560 --> 00:10:01,420
Qué bueno.

272
00:10:00,440 --> 00:10:02,740
Y ojo que no solo hay texto.

273
00:10:02,880 --> 00:10:05,000
Tienen un adaptador multimodal.

274
00:10:04,540 --> 00:10:06,000
¿Multimodal?

275
00:10:05,520 --> 00:10:07,180
Para imágenes y audio.

276
00:10:07,200 --> 00:10:07,980
Sí, sí.

277
00:10:07,980 --> 00:10:11,100
Operaciones masivamente pesadas como la síntesis de imágenes

278
00:10:11,100 --> 00:10:14,560
en Stable Diffusion o transcripciones de audio larguísimas

279
00:10:14,560 --> 00:10:17,180
con Whisper, todo eso puede beneficiarse de la

280
00:10:17,180 --> 00:10:19,000
misma retención semántica.

281
00:10:18,600 --> 00:10:21,280
Claro, te evitas regenerar exactamente el mismo activo

282
00:10:21,280 --> 00:10:23,220
multimedia si la petición es análoga.

283
00:10:23,220 --> 00:10:24,800
Es un ahorro brutal.

284
00:10:24,760 --> 00:10:25,720
Brutal.

285
00:10:25,280 --> 00:10:28,500
Pero volviendo a la analogía del PC, ese

286
00:10:28,500 --> 00:10:31,920
nivel de modularidad requiere tomar decisiones sobre el

287
00:10:31,920 --> 00:10:36,400
hardware, sobre dónde residen físicamente esos datos.

288
00:10:36,400 --> 00:10:39,260
Veo que la arquitectura separa claramente el lugar

289
00:10:39,260 --> 00:10:42,520
donde se guardan los vectores, el vector store,

290
00:10:42,520 --> 00:10:46,140
del lugar donde reside la respuesta cruda, el

291
00:10:46,140 --> 00:10:48,800
texto final, que sería el Caché storage, o

292
00:10:48,800 --> 00:10:49,420
sea, el disco duro.

293
00:10:49,460 --> 00:10:50,400
Exactamente.

294
00:10:50,400 --> 00:10:53,520
Herramientas como Faiz o Milbus se encargan de

295
00:10:53,520 --> 00:10:57,040
toda esa matemática vectorial rápida, mientras que bases

296
00:10:57,040 --> 00:10:59,180
de datos transaccionales de toda la vida, como

297
00:10:59,180 --> 00:11:01,760
Postgres, custodian los textos de salida.

298
00:11:01,760 --> 00:11:05,140
Pero claro, esta separación plantea el ineludible problema

299
00:11:05,140 --> 00:11:07,800
de la saturación bajo carga masiva, porque la

300
00:11:07,800 --> 00:11:09,720
memoria RAM es la que es, es un

301
00:11:09,720 --> 00:11:12,660
recurso finito y bastante costoso, por cierto.

302
00:11:12,520 --> 00:11:15,180
Ya te digo, la degradación del rendimiento por

303
00:11:15,180 --> 00:11:16,601
saturación de memoria.

304
00:11:16,681 --> 00:11:19,861
Los famosos errores OOM, Out of Memory.

305
00:11:19,741 --> 00:11:21,941
Las pesadillas de los de sistemas.

306
00:11:22,001 --> 00:11:24,061
Es el punto de fallo más habitual en

307
00:11:24,061 --> 00:11:26,381
implementaciones ingenuas, fíjate.

308
00:11:26,481 --> 00:11:28,681
Si la aplicación experimenta un pico de tráfico

309
00:11:28,681 --> 00:11:31,341
por un evento externo, oye, la caché crecerá

310
00:11:31,341 --> 00:11:32,881
a un ritmo exponencial.

311
00:11:31,901 --> 00:11:35,581
Y depender exclusivamente de la memoria local de

312
00:11:35,581 --> 00:11:38,321
un único servidor te garantiza un colapso.

313
00:11:38,221 --> 00:11:39,241
Matemático.

314
00:11:38,981 --> 00:11:41,281
Por eso, gestionar el ciclo de vida de

315
00:11:41,281 --> 00:11:44,681
los datos exige implementar políticas de expulsión agresivas.

316
00:11:45,261 --> 00:11:46,741
O sea, tirar cosas a la basura.

317
00:11:46,741 --> 00:11:47,441
Claro.

318
00:11:47,581 --> 00:11:50,781
El algoritmo LRU, por ejemplo, que descarta los

319
00:11:50,781 --> 00:11:53,661
elementos que llevan más tiempo sin ser consultados,

320
00:11:53,641 --> 00:11:55,281
es súper efectivo en apps de cara al

321
00:11:55,281 --> 00:11:57,781
público, donde el tráfico suele ir por modas

322
00:11:57,781 --> 00:11:59,201
o temas de actualidad.

323
00:11:59,101 --> 00:12:00,281
Ya, lo viejo se borra.

324
00:12:01,081 --> 00:12:03,761
Y supongo que, para evitar la redundancia y

325
00:12:03,761 --> 00:12:07,321
asegurar alta disponibilidad, pues la arquitectura debe escalar

326
00:12:07,321 --> 00:12:08,741
horizontalmente.

327
00:12:08,521 --> 00:12:09,441
Sí o sí.

328
00:12:09,441 --> 00:12:12,701
Desplegar una Caché distribuida apoyándose en sistemas probados

329
00:12:12,701 --> 00:12:14,301
como Memcached o Redis.

330
00:12:14,541 --> 00:12:17,001
O sea, que todo un clúster de servidores

331
00:12:17,001 --> 00:12:20,161
comparta un único cerebro, un estado único.

332
00:12:20,641 --> 00:12:22,701
Si un servidor en Europa calcula y guarda

333
00:12:22,701 --> 00:12:25,401
una respuesta muy compleja, cualquier otro nodo, a

334
00:12:25,401 --> 00:12:28,781
nivel global, en Asia o América, hereda ese

335
00:12:28,781 --> 00:12:30,881
acceso instantáneamente.

336
00:12:30,961 --> 00:12:34,081
Neutralizando la necesidad de duplicar el esfuerzo y

337
00:12:34,081 --> 00:12:35,721
protegiendo la memoria de cada máquina.

338
00:12:36,001 --> 00:12:37,061
Brillante.

339
00:12:36,841 --> 00:12:40,241
Es una infraestructura que resuelve magistralmente la redundancia

340
00:12:40,241 --> 00:12:41,701
en las respuestas finales.

341
00:12:41,781 --> 00:12:42,161
Pero.

342
00:12:42,221 --> 00:12:44,761
Ah, amigo, siempre hay un pero.

343
00:12:44,781 --> 00:12:45,521
Siempre.

344
00:12:45,521 --> 00:12:48,261
Porque todo esto de GPT-Caché es genial si

345
00:12:48,261 --> 00:12:50,661
los usuarios hacen preguntas parecidas.

346
00:12:50,781 --> 00:12:52,941
Pero, ¿qué pasa si cambiamos las reglas?

347
00:12:53,201 --> 00:12:53,801
A ver.

348
00:12:53,861 --> 00:12:56,781
Analicemos el escenario del RAG, el Retrieval Augmented

349
00:12:56,781 --> 00:12:57,361
Generation.

350
00:12:58,201 --> 00:13:01,721
En estos sistemas, inyectamos documentos masivos, a veces

351
00:13:01,721 --> 00:13:04,601
decenas de miles de palabras, en la ventana

352
00:13:04,601 --> 00:13:05,681
de contexto de la IA.

353
00:13:05,821 --> 00:13:07,981
Sí, para fundamentar la respuesta y que no

354
00:13:07,981 --> 00:13:08,681
alucine.

355
00:13:08,681 --> 00:13:10,161
Exacto.

356
00:13:10,161 --> 00:13:12,921
Pues imagínate que un usuario le mete a

357
00:13:12,921 --> 00:13:15,641
la IA un manual técnico de 100 páginas

358
00:13:15,641 --> 00:13:18,581
y le hace una pregunta súper específica sobre

359
00:13:18,581 --> 00:13:19,461
el capítulo 3.

360
00:13:20,081 --> 00:13:20,661
Vale.

361
00:13:20,641 --> 00:13:23,521
Y 10 minutos después, el mismo usuario u

362
00:13:23,521 --> 00:13:26,021
otro, con el mismo manual, le hace una

363
00:13:26,021 --> 00:13:28,801
pregunta completamente diferente sobre el glosario final.

364
00:13:29,581 --> 00:13:30,461
Claro.

365
00:13:30,361 --> 00:13:33,381
La caché semántica de resultados aquí falla estrepitosamente

366
00:13:33,461 --> 00:13:35,441
porque las respuestas que tiene que dar la

367
00:13:35,441 --> 00:13:37,521
IA deben ser distintas.

368
00:13:37,521 --> 00:13:39,621
Sí, sí, irremediablemente.

369
00:13:39,721 --> 00:13:41,901
Porque las salidas esperadas son divergentes.

370
00:13:42,481 --> 00:13:44,881
Entonces la perspectiva cambia por completo.

371
00:13:44,901 --> 00:13:48,141
Ya no buscamos reciclar el plato ya cocinado.

372
00:13:48,241 --> 00:13:50,081
Buscamos otra cosa, que es lo que explica

373
00:13:50,081 --> 00:13:51,441
la documentación de IBM, ¿no?

374
00:13:51,941 --> 00:13:53,101
El prompt caching.

375
00:13:53,681 --> 00:13:56,721
Eso es, el almacenamiento en caché de entradas.

376
00:13:55,861 --> 00:13:58,641
Que yo lo asocio mucho con la mise

377
00:13:58,641 --> 00:14:00,881
en place, en la alta gastronomía.

378
00:14:00,661 --> 00:14:02,281
Me encanta, explícalo.

379
00:14:01,801 --> 00:14:04,281
Pues a ver, si la caché semántica era

380
00:14:04,281 --> 00:14:06,581
una nevela donde guardabas el plato ya terminado

381
00:14:06,581 --> 00:14:08,061
y solo lo calentabas.

382
00:14:08,881 --> 00:14:11,221
El prompt caching es todo el trabajo preparatorio

383
00:14:11,221 --> 00:14:12,301
de la cocina.

384
00:14:12,461 --> 00:14:14,381
El equipo ya ha picado la cebolla, ha

385
00:14:14,381 --> 00:14:17,761
hecho los caldos, tiene las salsas listas… Todo

386
00:14:17,761 --> 00:14:18,421
organizado.

387
00:14:18,561 --> 00:14:19,161
Exacto.

388
00:14:19,161 --> 00:14:21,701
Si entra una comanda de un plato diferente

389
00:14:21,701 --> 00:14:24,341
pero que usa esa base, esos mismos caldos,

390
00:14:24,341 --> 00:14:26,961
te ahorras el 90% del trabajo pesado.

391
00:14:26,481 --> 00:14:28,521
Es que el concepto de la mise en

392
00:14:28,521 --> 00:14:31,241
place captura literalmente la esencia de la fase

393
00:14:31,241 --> 00:14:34,221
de prellenado o el pre-fill en la arquitectura

394
00:14:34,221 --> 00:14:35,361
de los transformers.

395
00:14:35,361 --> 00:14:36,981
A ver, explícanos un poco las tripas de

396
00:14:36,981 --> 00:14:37,681
eso.

397
00:14:37,821 --> 00:14:40,101
Pues para entender el ahorro hay que visualizar

398
00:14:40,101 --> 00:14:42,661
el mecanismo interno del LLM.

399
00:14:43,081 --> 00:14:44,981
Cuando ese manual de 100 páginas entra al

400
00:14:44,981 --> 00:14:47,661
sistema, el modelo no empieza a escribir texto

401
00:14:47,661 --> 00:14:48,701
de inmediato.

402
00:14:48,281 --> 00:14:49,721
No es magia, claro.

403
00:14:49,481 --> 00:14:50,561
Para nada.

404
00:14:50,561 --> 00:14:52,681
Los mecanismos de atención de la red neuronal

405
00:14:52,681 --> 00:14:55,141
tienen que calcular la relación de cada token

406
00:14:55,141 --> 00:14:57,121
con todos y cada uno de los tokens

407
00:14:57,121 --> 00:14:58,381
precedentes.

408
00:14:58,401 --> 00:15:01,081
O sea, entender el contexto de la palabra

409
00:15:01,081 --> 00:15:04,161
tornillo en la página 50 respecto a la

410
00:15:04,161 --> 00:15:04,761
página 2.

411
00:15:05,061 --> 00:15:05,541
Eso es.

412
00:15:05,541 --> 00:15:09,041
Y ese proceso requiere computar unas matrices gigantescas

413
00:15:09,041 --> 00:15:12,501
que se conocen como pares clave-valor, los KV

414
00:15:12,501 --> 00:15:13,001
pairs.

415
00:15:13,261 --> 00:15:15,721
Y supongo que esa computación se adentra en

416
00:15:15,721 --> 00:15:17,981
el territorio de la complejidad cuadrática, ¿no?

417
00:15:17,981 --> 00:15:22,381
Porque si evaluamos 50.000 tokens simultáneamente… Las matemáticas

418
00:15:22,381 --> 00:15:23,121
se disparan.

419
00:15:23,121 --> 00:15:25,781
El número de operaciones de multiplicación de matrices

420
00:15:25,781 --> 00:15:28,601
que la GPU tiene que comerse alcanza cifras

421
00:15:28,601 --> 00:15:29,601
astronómicas.

422
00:15:29,981 --> 00:15:30,621
Madre mía.

423
00:15:30,841 --> 00:15:32,861
Y ojo, que esto se repite en cada

424
00:15:32,861 --> 00:15:35,381
una de las capas ocultas del transformer.

425
00:15:35,381 --> 00:15:39,021
El desgaste de ciclos de procesamiento es absoluto.

426
00:15:38,801 --> 00:15:43,181
Y, claro, como los modelos por defecto no

427
00:15:43,181 --> 00:15:46,121
tienen memoria de estado, si le mandas la

428
00:15:46,121 --> 00:15:49,181
segunda pregunta con el mismo manual adjunto, la

429
00:15:49,181 --> 00:15:50,801
IA desecha todo lo de antes.

430
00:15:51,261 --> 00:15:52,901
Todo a la basura.

431
00:15:52,901 --> 00:15:55,781
Inicia el cómputo masivo de los pares clave-valor

432
00:15:55,781 --> 00:15:57,641
desde la primera letra del manual.

433
00:15:58,401 --> 00:15:59,961
¡Qué ineficiencia!

434
00:15:59,961 --> 00:16:02,581
Entonces el prompt caching interviene ahí.

435
00:16:02,441 --> 00:16:03,501
Exacto.

436
00:16:03,501 --> 00:16:06,201
Interceptando y guardando estas matrices de atención en

437
00:16:06,201 --> 00:16:08,941
la memoria VRAM a altísima velocidad de la

438
00:16:08,941 --> 00:16:09,841
GPU.

439
00:16:10,081 --> 00:16:12,161
Al detectar que un bloque de texto coincide

440
00:16:12,161 --> 00:16:15,081
con uno recién procesado, el sistema carga ese

441
00:16:15,081 --> 00:16:16,341
estado precalculado.

442
00:16:16,761 --> 00:16:19,301
Ah, o sea, recupera el contexto ya en

443
00:16:19,301 --> 00:16:20,821
formato matemático.

444
00:16:20,941 --> 00:16:22,861
Y así solo se esfuerza en calcular los

445
00:16:22,861 --> 00:16:25,361
tokens nuevos, es decir, la preguntita nueva del

446
00:16:25,361 --> 00:16:25,801
usuario.

447
00:16:26,201 --> 00:16:27,161
Eso es.

448
00:16:27,161 --> 00:16:28,521
Pura eficiencia.

449
00:16:28,341 --> 00:16:30,341
El impacto en la latencia tiene que ser

450
00:16:30,341 --> 00:16:31,561
brutal, claro.

451
00:16:31,721 --> 00:16:35,021
pero exija una precisión, digamos, quirúrgica.

452
00:16:35,041 --> 00:16:37,581
El sistema tiene que saber rapidísimo qué parte

453
00:16:37,581 --> 00:16:39,281
recicla y qué parte es nueva.

454
00:16:39,261 --> 00:16:41,261
Sí, y aquí es donde las reglas del

455
00:16:41,261 --> 00:16:43,141
juego se ponen estrictas.

456
00:16:43,161 --> 00:16:45,561
Para discriminar esto, se usa la técnica de

457
00:16:45,561 --> 00:16:48,001
coincidencia de prefijos, el prefix matching.

458
00:16:48,361 --> 00:16:50,941
Que evalúa de izquierda a derecha, entiendo.

459
00:16:51,041 --> 00:16:52,581
Estrictamente secuencial.

460
00:16:52,781 --> 00:16:54,861
Construye como una estructura de árbol.

461
00:16:54,901 --> 00:16:57,122
El motor recorre la instrucción nueva token a

462
00:16:57,122 --> 00:16:57,902
token.

463
00:16:57,902 --> 00:16:59,502
Mientras todo sea idéntico a lo que hay

464
00:16:59,502 --> 00:17:01,562
en caché, recicla los pares KV.

465
00:17:01,562 --> 00:17:02,942
Vale.

466
00:17:02,942 --> 00:17:04,802
Pero la severidad de esto es que, en

467
00:17:04,802 --> 00:17:06,562
el instante en que detecta un solo token

468
00:17:06,562 --> 00:17:09,922
distinto, un carácter, un espacio extra, un salto

469
00:17:09,922 --> 00:17:12,022
de línea cambiado, se rompe la magia.

470
00:17:12,022 --> 00:17:14,382
Se rompe de forma irreversible.

471
00:17:14,382 --> 00:17:16,742
Desde ese punto de divergencia hacia adelante, te

472
00:17:16,742 --> 00:17:20,042
obliga a ejecutar el cómputo completo otra vez.

473
00:17:20,042 --> 00:17:20,062
¡Guau!

474
00:17:20,062 --> 00:17:22,522
O sea que esta rigidez obliga a los

475
00:17:22,522 --> 00:17:25,462
desarrolladores a replantear la ingeniería de los prompts

476
00:17:25,462 --> 00:17:26,842
desde los cimientos.

477
00:17:26,842 --> 00:17:28,222
Totalmente.

478
00:17:28,222 --> 00:17:30,162
Ya no es cómo escribes para que suene

479
00:17:30,162 --> 00:17:33,922
bonito, es que la sintaxis determina la rentabilidad

480
00:17:33,922 --> 00:17:36,322
financiera de tu empresa.

481
00:17:36,322 --> 00:17:37,942
Es que hay una regla de oro aquí,

482
00:17:37,942 --> 00:17:38,342
¿no?

483
00:17:38,342 --> 00:17:41,862
La información debe organizarse en un gradiente estricto,

484
00:17:41,862 --> 00:17:45,702
de lo más estático a lo más dinámico.

485
00:17:45,702 --> 00:17:47,942
Eso es fundamental que la audiencia se lo

486
00:17:47,942 --> 00:17:48,982
grave a fuego.

487
00:17:48,982 --> 00:17:49,882
Sí, sí.

488
00:17:49,882 --> 00:17:51,862
O sea, lo que no cambia, arriba del

489
00:17:51,862 --> 00:17:52,742
todo.

490
00:17:52,742 --> 00:17:55,842
La arquitectura óptima exige que consolides todos los

491
00:17:55,842 --> 00:17:58,442
bloques invariables en la cabecera.

492
00:17:58,442 --> 00:18:01,282
Instrucciones del sistema, en plan, eres un asistente

493
00:18:01,282 --> 00:18:05,102
útil, el contexto kilométrico del manual, los ejemplos

494
00:18:05,102 --> 00:18:06,102
estáticos.

495
00:18:06,102 --> 00:18:07,022
Todo eso primero.

496
00:18:07,022 --> 00:18:08,102
En los primeros estratos.

497
00:18:08,102 --> 00:18:11,762
Y la consulta específica y efímera del usuario,

498
00:18:11,762 --> 00:18:15,282
la pregunta, debe ir estrictamente confinada al final

499
00:18:15,282 --> 00:18:16,042
del documento.

500
00:18:16,042 --> 00:18:18,442
Porque si inviertes el orden, catástrofe.

501
00:18:18,442 --> 00:18:20,402
Si un desarrollador pone la pregunta del usuario

502
00:18:20,402 --> 00:18:22,342
en la primera línea y luego le pega

503
00:18:22,342 --> 00:18:23,422
el manual de 100 páginas.

504
00:18:23,422 --> 00:18:26,142
Pues que el primer token generado por cada

505
00:18:26,142 --> 00:18:28,682
usuario va a ser diferente siempre.

506
00:18:28,682 --> 00:18:30,862
Y el prefix matching falla en el milisegundo

507
00:18:30,862 --> 00:18:31,322
1.

508
00:18:31,322 --> 00:18:34,122
Invalidas la posibilidad de recuperar el bloque gigante

509
00:18:34,122 --> 00:18:34,922
que va detrás.

510
00:18:34,922 --> 00:18:36,162
Exacto.

511
00:18:36,162 --> 00:18:38,342
Un simple error de concatenar strings en el

512
00:18:38,342 --> 00:18:40,522
código y te has cargado la eficiencia de

513
00:18:40,522 --> 00:18:42,082
toda la infraestructura.

514
00:18:42,082 --> 00:18:44,882
Apagar el cálculo estático en cada petición.

515
00:18:44,902 --> 00:18:45,502
¡Qué locura!

516
00:18:45,502 --> 00:18:48,682
Pero, viendo lo elegante que es esta solución,

517
00:18:48,682 --> 00:18:50,062
a mí me surge una duda.

518
00:18:50,062 --> 00:18:52,082
¿Por qué no guardamos en caché el contexto

519
00:18:52,082 --> 00:18:53,282
de absolutamente todo?

520
00:18:53,702 --> 00:18:54,782
A ver, explícate.

521
00:18:54,802 --> 00:18:56,962
Pues si un usuario le dice hola a

522
00:18:56,962 --> 00:18:57,642
un bot.

523
00:18:57,642 --> 00:18:58,902
Tres palabras.

524
00:18:58,902 --> 00:19:01,422
La intuición me dice que guardar esos pares

525
00:19:01,422 --> 00:19:03,502
KB también sería optimizar.

526
00:19:03,502 --> 00:19:04,702
Todo suma, ¿no?

527
00:19:04,642 --> 00:19:08,182
Ya, pero en sistemas distribuidos ninguna abstracción te

528
00:19:08,182 --> 00:19:09,122
sale gratis.

529
00:19:09,142 --> 00:19:11,822
Claro, el sobrecoste de gestionar la propia caché.

530
00:19:12,162 --> 00:19:12,702
Exacto.

531
00:19:12,702 --> 00:19:17,442
Indexar, almacenar en memoria compartida, buscar y transferir

532
00:19:17,442 --> 00:19:19,122
las matrices a la GPU.

533
00:19:19,262 --> 00:19:21,322
Todo eso añade latencia y coste.

534
00:19:21,302 --> 00:19:23,702
O sea, hay un umbral de rentabilidad.

535
00:19:23,522 --> 00:19:26,442
Sí, los proveedores principales suelen establecer la barrera

536
00:19:26,442 --> 00:19:28,802
en unos 1024 tokens de entrada.

537
00:19:28,922 --> 00:19:31,422
Para secuencias más cortas que eso, tardas más

538
00:19:31,422 --> 00:19:32,882
en buscar en la caché que en dejar

539
00:19:32,882 --> 00:19:34,382
que el modelo lo procese en bruto.

540
00:19:34,682 --> 00:19:35,922
Tiene sentido.

541
00:19:35,922 --> 00:19:37,482
Y me imagino que esta mise en place

542
00:19:37,482 --> 00:19:40,042
digital es efímera, no dura para siempre.

543
00:19:40,082 --> 00:19:41,102
Para nada.

544
00:19:41,102 --> 00:19:43,442
Para no saturar el hardware, operan con políticas

545
00:19:43,442 --> 00:19:46,702
de expiración súper agresivas, purgando todo tras 5

546
00:19:46,702 --> 00:19:48,362
o 10 minutos de inactividad.

547
00:19:48,202 --> 00:19:51,662
O sea, optimizan sesiones densas y rápidas, no

548
00:19:51,662 --> 00:19:53,002
un histórico a largo plazo.

549
00:19:53,222 --> 00:19:54,202
Exacto.

550
00:19:53,902 --> 00:19:55,902
Al final, la lógica de la alta cocina

551
00:19:55,902 --> 00:19:56,942
prevalece.

552
00:19:56,942 --> 00:19:59,022
Cuando el servicio acaba, el chef ordena limpiar

553
00:19:59,022 --> 00:20:02,202
la estación, tira los ingredientes preparados y recupera

554
00:20:02,202 --> 00:20:03,762
el control de su encimera.

555
00:20:03,582 --> 00:20:06,102
Es una analogía brillante, sí.

556
00:20:06,102 --> 00:20:09,282
Encapsula perfectamente el ciclo de vida del procesamiento

557
00:20:09,282 --> 00:20:11,122
en redes neuronales.

558
00:20:11,122 --> 00:20:13,862
Y fíjate, contemplar esta evolución hacia la retención

559
00:20:13,862 --> 00:20:17,342
semántica y estructural a mí me empuja hacia

560
00:20:17,342 --> 00:20:18,922
una reflexión mucho más profunda.

561
00:20:19,382 --> 00:20:20,482
A ver, cuéntame.

562
00:20:20,562 --> 00:20:23,322
Pues sobre la naturaleza futura de estos sistemas.

563
00:20:23,322 --> 00:20:26,542
Porque si las arquitecturas siguen perfeccionando esto, guardando

564
00:20:26,542 --> 00:20:29,742
contexto de entrada y semántica de salida, nos

565
00:20:29,742 --> 00:20:32,882
acercamos a un horizonte de hipereficiencia muy bestia.

566
00:20:33,662 --> 00:20:36,762
Y cabe plantearse si los grandes modelos masivos

567
00:20:36,762 --> 00:20:40,662
van a ir reduciendo progresivamente su, digamos, generación

568
00:20:40,662 --> 00:20:42,342
estocástica real.

569
00:20:42,342 --> 00:20:45,342
Se acabarán operando, en la práctica, como gigantescos

570
00:20:45,342 --> 00:20:49,342
repositorios indexados que simplemente actúan como bibliotecarios.

571
00:20:49,742 --> 00:20:52,622
Recuperando pensamientos precalculados del pasado.

572
00:20:52,682 --> 00:20:54,182
A la velocidad de la luz, para el

573
00:20:54,182 --> 00:20:57,102
99% de nuestras interacciones cotidianas.

574
00:20:56,702 --> 00:20:58,082
¡Qué barbaridad!

575
00:20:58,082 --> 00:21:02,442
Resulta fascinante reconsiderar así la generación del lenguaje.

576
00:21:02,442 --> 00:21:04,662
Lo que desde fuera parece, no sé, una

577
00:21:04,662 --> 00:21:07,642
IA, pensando en tiempo real, bajo el capó

578
00:21:07,642 --> 00:21:10,922
se transforma en una labor monumental de recuperación

579
00:21:10,922 --> 00:21:12,302
de estados almacenados.

580
00:21:12,682 --> 00:21:13,522
Exacto.

581
00:21:13,202 --> 00:21:16,822
Una coreografía compleja donde la verdadera magia reside

582
00:21:16,822 --> 00:21:20,042
en evitar pensar la misma idea dos veces.

583
00:21:20,042 --> 00:21:23,182
Es una perspectiva reveladora sobre la eficiencia matemática

584
00:21:23,182 --> 00:21:24,802
de esta revolución.

585
00:21:24,802 --> 00:21:27,622
Antes de despedirnos, hasta el próximo programa, os

586
00:21:27,622 --> 00:21:29,762
informamos de que las voces que oyes han

587
00:21:29,762 --> 00:21:32,322
sido generadas por la IA de Notebook LM

588
00:21:32,322 --> 00:21:35,062
y que dirigiendo el podcast se encuentra Julio

589
00:21:35,062 --> 00:21:38,102
Pablo Vázquez, un humano que te envía saludos.

590
00:21:38,102 --> 00:21:41,222
En caso de error, probablemente sean errores humanos.

591
00:21:41,222 --> 00:21:41,882
¡Nos escuchamos!

592
00:21:53,322 --> 00:21:55,442
Y hasta aquí el episodio de hoy.

593
00:21:55,442 --> 00:21:57,022
Muchas gracias por tu atención.

594
00:22:06,782 --> 00:22:09,042
Esto es BIMPRAXIS.

595
00:22:09,042 --> 00:22:11,142
Nos escuchamos en el próximo episodio.