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,240 --> 00:00:39,840
Hola, humanas y humanos.

8
00:00:39,840 --> 00:00:43,299
Aquí estamos con un nuevo episodio de BIMPRAXIS.

9
00:00:43,299 --> 00:00:45,939
Hoy continuamos con la serie dedicada a los

10
00:00:45,939 --> 00:00:49,840
RAG, Retrieval Augmented Generation, y los vamos a

11
00:00:49,840 --> 00:00:53,960
comparar con los CAG o Caché Augmented Generation.

12
00:00:53,960 --> 00:00:56,320
Veremos las ventajas, los inconvenientes de un método

13
00:00:55,939 --> 00:00:58,740
y otro, y también la solución híbrida.

14
00:00:59,420 --> 00:01:01,299
Pues sí, la misión de hoy es analizar

15
00:01:01,299 --> 00:01:04,319
una disyuntiva que es fundamental en la arquitectura

16
00:01:04,319 --> 00:01:06,040
de la IA ahora mismo.

17
00:01:06,099 --> 00:01:08,680
Por un lado, el método que ya conocemos,

18
00:01:08,680 --> 00:01:11,540
RAG, que funciona como un investigador que consulta

19
00:01:11,540 --> 00:01:13,099
una biblioteca en tiempo real.

20
00:01:13,040 --> 00:01:14,879
Y por otro, el aspirante.

21
00:01:15,099 --> 00:01:17,560
Por otro, el aspirante, CAG, que es más

22
00:01:17,560 --> 00:01:19,379
como un experto que se ha memorizado la

23
00:01:19,379 --> 00:01:21,599
biblioteca entera antes de empezar.

24
00:01:21,819 --> 00:01:24,060
Vamos a analizar la velocidad, la precisión y,

25
00:01:24,060 --> 00:01:26,680
sobre todo, cómo su combinación podría definir el

26
00:01:26,680 --> 00:01:28,799
futuro de los sistemas de conocimiento en IA.

27
00:01:29,000 --> 00:01:31,819
Un investigador frente a un sabio memorista.

28
00:01:31,819 --> 00:01:32,659
Me gusta la metáfora.

29
00:01:33,060 --> 00:01:34,939
Muy bien, pues vamos a desgranar esto a

30
00:01:34,939 --> 00:01:35,640
fondo.

31
00:01:35,560 --> 00:01:36,659
Para poner a todo el mundo en la

32
00:01:36,659 --> 00:01:39,620
misma página, si te parece, recordemos brevemente que

33
00:01:39,620 --> 00:01:40,400
es RAG.

34
00:01:40,959 --> 00:01:43,099
Ha sido la solución, bueno, la solución de

35
00:01:43,099 --> 00:01:44,980
facto durante el último par de años para

36
00:01:44,980 --> 00:01:47,879
conectar los modelos de lenguaje con información externa,

37
00:01:47,879 --> 00:01:48,459
¿cierto?

38
00:01:48,219 --> 00:01:49,519
Exacto.

39
00:01:49,519 --> 00:01:52,400
RAG, o Generación Aumentada por Recuperación, es un

40
00:01:52,400 --> 00:01:54,120
sistema de dos pasos.

41
00:01:54,120 --> 00:01:56,299
Cuando recibe una pregunta, lo primero, el primer

42
00:01:56,299 --> 00:01:57,700
paso, es la recuperación.

43
00:01:58,519 --> 00:01:59,120
La búsqueda.

44
00:01:59,140 --> 00:02:00,299
La búsqueda, sí.

45
00:02:00,299 --> 00:02:02,420
Un componente del sistema busca en una base

46
00:02:02,420 --> 00:02:04,379
de datos externa, que suele ser una base

47
00:02:04,379 --> 00:02:07,120
de datos vectorial, los fragmentos de información más

48
00:02:07,120 --> 00:02:07,719
relevantes.

49
00:02:07,719 --> 00:02:10,460
Y el segundo paso es la generación.

50
00:02:10,240 --> 00:02:10,919
Vale.

51
00:02:10,819 --> 00:02:13,060
Esos fragmentos recuperados se meten en el prompt

52
00:02:13,060 --> 00:02:14,979
junto a la pregunta original y se le

53
00:02:14,979 --> 00:02:16,460
entrega todo al modelo para que elabore la

54
00:02:16,460 --> 00:02:17,259
respuesta.

55
00:02:17,139 --> 00:02:19,780
Es la forma de anclar al modelo a

56
00:02:19,780 --> 00:02:22,580
la realidad, por así decirlo, para evitar que

57
00:02:22,580 --> 00:02:25,120
invente datos, las famosas alucinaciones.

58
00:02:25,699 --> 00:02:26,860
Precisamente.

59
00:02:26,860 --> 00:02:28,919
Y para asegurar que sus respuestas se basan

60
00:02:28,919 --> 00:02:31,259
en información fresca, no solo en los datos

61
00:02:31,259 --> 00:02:33,099
con los que fue entrenado, que pueden tener

62
00:02:33,099 --> 00:02:34,060
meses o años.

63
00:02:34,379 --> 00:02:34,919
Claro.

64
00:02:34,939 --> 00:02:37,219
Es ideal para bases de conocimiento enormes o

65
00:02:37,219 --> 00:02:38,800
que cambian constantemente.

66
00:02:38,800 --> 00:02:42,219
Piensa en noticias, informes de bolsa, historiales médicos.

67
00:02:42,020 --> 00:02:45,599
Suena como la solución perfecta, pero los documentos

68
00:02:45,599 --> 00:02:48,219
que hemos revisado para este análisis señalan varias

69
00:02:48,219 --> 00:02:50,780
fricciones importantes.

70
00:02:50,780 --> 00:02:52,719
Y aquí es donde la cosa se pone

71
00:02:52,719 --> 00:02:53,219
interesante.

72
00:02:53,780 --> 00:02:54,539
Así es.

73
00:02:54,539 --> 00:02:56,659
A pesar de sus ventajas, RAG tiene tres

74
00:02:56,659 --> 00:02:58,340
inconvenientes principales.

75
00:02:58,340 --> 00:03:00,240
El primero, y más evidente para quien lo

76
00:03:00,240 --> 00:03:02,159
usa, es la latencia.

77
00:03:02,000 --> 00:03:03,099
La espera.

78
00:03:03,099 --> 00:03:05,240
A nadie le gusta ver el cursor parpadeando

79
00:03:05,240 --> 00:03:07,120
mientras el chatbot piensa.

80
00:03:06,979 --> 00:03:07,840
Exacto.

81
00:03:07,840 --> 00:03:11,259
Ese proceso de búsqueda, de recuperación, de codificar

82
00:03:11,259 --> 00:03:14,900
la pregunta, buscar, recuperar, todo eso añade un

83
00:03:14,900 --> 00:03:17,060
retardo de varios segundos.

84
00:03:17,060 --> 00:03:19,979
Y en una conversación eso rompe la experiencia.

85
00:03:20,280 --> 00:03:21,620
Totalmente.

86
00:03:21,620 --> 00:03:23,060
¿Y el segundo problema?

87
00:03:23,340 --> 00:03:25,000
La complejidad de la arquitectura.

88
00:03:24,539 --> 00:03:27,159
Y esa complejidad no es solo un dolor

89
00:03:27,159 --> 00:03:28,219
de cabeza técnico.

90
00:03:28,219 --> 00:03:30,439
Me imagino que también tiene un coste económico,

91
00:03:30,439 --> 00:03:30,520
¿no?

92
00:03:30,879 --> 00:03:32,560
Has dado en el clavo.

93
00:03:32,560 --> 00:03:34,780
Cada uno de esos componentes, la base de

94
00:03:34,780 --> 00:03:37,680
datos vectorial, los modelos de embedding, el sistema

95
00:03:37,680 --> 00:03:41,199
de indexación, todo tiene un coste de mantenimiento,

96
00:03:41,199 --> 00:03:42,900
de computación, de operación.

97
00:03:43,259 --> 00:03:45,680
Más piezas móviles, más puntos de fallo.

98
00:03:45,939 --> 00:03:47,719
Y más facturas a final de mes.

99
00:03:47,719 --> 00:03:49,520
Y eso nos lleva a la tercera y

100
00:03:49,520 --> 00:03:53,599
quizá más crítica fricción, los errores de recuperación.

101
00:03:53,500 --> 00:03:54,000
Vale.

102
00:03:54,020 --> 00:03:55,939
El sistema es tan bueno como su eslabón

103
00:03:55,939 --> 00:03:58,539
más débil, y en RAG ese eslabón suele

104
00:03:58,539 --> 00:03:59,960
ser el recuperador.

105
00:03:59,479 --> 00:04:01,560
¿Puedes ponernos un ejemplo?

106
00:04:01,560 --> 00:04:03,439
No es solo que no encuentre nada, ¿verdad?

107
00:04:03,520 --> 00:04:04,240
Claro.

108
00:04:04,240 --> 00:04:05,719
Hay dos tipos de error.

109
00:04:05,719 --> 00:04:08,639
Podríamos tener un error de baja precisión, donde

110
00:04:08,639 --> 00:04:11,280
el sistema te trae muchos documentos, pero la

111
00:04:11,280 --> 00:04:13,659
mayoría son irrelevantes, son ruido.

112
00:04:13,919 --> 00:04:15,900
Y el modelo se vuelve loco con tanta

113
00:04:15,900 --> 00:04:17,100
información basura.

114
00:04:17,100 --> 00:04:17,939
Exacto.

115
00:04:17,939 --> 00:04:19,057
Y la respuesta se degrada.

116
00:04:19,677 --> 00:04:22,717
O peor, un error de baja exhaustividad, donde

117
00:04:22,717 --> 00:04:25,017
no encuentra el fragmento clave, el que tiene

118
00:04:25,017 --> 00:04:26,077
la respuesta.

119
00:04:26,197 --> 00:04:27,717
Y ahí da igual lo bueno que sea

120
00:04:27,717 --> 00:04:29,337
el modelo, si no le das la materia

121
00:04:29,337 --> 00:04:30,697
prima correcta.

122
00:04:30,537 --> 00:04:32,097
Basura entra, basura sale.

123
00:04:32,097 --> 00:04:33,097
El clásico.

124
00:04:33,057 --> 00:04:33,677
El clásico.

125
00:04:34,137 --> 00:04:34,897
De acuerdo.

126
00:04:34,897 --> 00:04:37,877
Entonces tenemos latencia, una complejidad que es costosa

127
00:04:37,437 --> 00:04:40,257
y el riesgo constante de que el recuperador

128
00:04:40,257 --> 00:04:40,677
falle.

129
00:04:41,377 --> 00:04:43,637
Un caldo de cultivo perfecto para que surja

130
00:04:43,637 --> 00:04:45,097
una alternativa.

131
00:04:45,097 --> 00:04:47,057
Y esa es CAG.

132
00:04:47,057 --> 00:04:49,417
Caché Augmented Generation.

133
00:04:49,417 --> 00:04:50,457
¿En qué consiste?

134
00:04:50,537 --> 00:04:53,797
Pues CAG representa un cambio de mentalidad radical,

135
00:04:53,797 --> 00:04:56,037
y es posible gracias a una evolución espectacular

136
00:04:56,037 --> 00:04:58,937
de los modelos recientes, las ventanas de contexto

137
00:04:58,937 --> 00:04:59,937
gigantescas.

138
00:05:00,217 --> 00:05:02,837
Que cada vez son más y más grandes.

139
00:05:02,837 --> 00:05:05,517
Hablamos de modelos que ya procesan cientos de

140
00:05:05,517 --> 00:05:08,417
miles o millones de tokens de una vez.

141
00:05:08,417 --> 00:05:09,677
Libros enteros.

142
00:05:09,197 --> 00:05:11,957
La idea de CAG es simple pero muy

143
00:05:11,957 --> 00:05:12,877
potente.

144
00:05:12,877 --> 00:05:15,237
En lugar de buscar la información fuera, ¿por

145
00:05:15,237 --> 00:05:17,257
qué no la precargamos toda dentro del modelo

146
00:05:17,257 --> 00:05:18,497
desde el principio?

147
00:05:18,697 --> 00:05:20,517
¿Te refieres a meter toda la base de

148
00:05:20,517 --> 00:05:24,197
conocimiento directamente en el prompt, como un anexo

149
00:05:24,197 --> 00:05:25,337
gigantesco?

150
00:05:25,357 --> 00:05:26,637
Esencialmente sí.

151
00:05:26,637 --> 00:05:29,397
El flujo de trabajo es completamente distinto.

152
00:05:29,397 --> 00:05:32,117
Primero cargas todos los documentos en el contexto

153
00:05:32,117 --> 00:05:33,137
del modelo.

154
00:05:33,317 --> 00:05:35,077
Y luego haces un paso clave.

155
00:05:35,077 --> 00:05:38,177
Precomputas la caché de clave-valor, la KV-Caché.

156
00:05:38,857 --> 00:05:41,057
A ver, explícanos eso un poco más.

157
00:05:41,057 --> 00:05:43,737
Es, a grandes rasgos, el estado interno del

158
00:05:43,737 --> 00:05:47,557
modelo, sus cálculos, después de haber asimilado todo

159
00:05:47,557 --> 00:05:48,877
ese conocimiento.

160
00:05:48,977 --> 00:05:51,017
Es como si el modelo se estudiara todo

161
00:05:51,017 --> 00:05:54,237
el temario de una sentada antes del examen.

162
00:05:54,277 --> 00:05:55,837
Y ese estado de ya me lo he

163
00:05:55,837 --> 00:05:57,037
estudiado se guarda.

164
00:05:57,277 --> 00:05:58,517
La analogía es perfecta.

165
00:05:59,197 --> 00:06:02,737
Ese estudio es un coste computacional que asumes

166
00:06:02,737 --> 00:06:04,357
una sola vez, al principio.

167
00:06:05,257 --> 00:06:07,537
Una vez generada la caché, cada nueva pregunta

168
00:06:07,537 --> 00:06:09,697
simplemente se añade al final de ese contexto

169
00:06:09,697 --> 00:06:10,537
ya procesado.

170
00:06:10,797 --> 00:06:12,917
Con lo cual, no hay búsqueda externa.

171
00:06:13,477 --> 00:06:14,197
Ninguna.

172
00:06:14,197 --> 00:06:16,797
Ya sabe todo el contenido y puede generar

173
00:06:16,797 --> 00:06:18,697
la respuesta casi al instante.

174
00:06:17,717 --> 00:06:21,297
Ese coste único suena importante.

175
00:06:21,297 --> 00:06:24,797
¿Hablamos de un proceso que tarda minutos, horas?

176
00:06:24,797 --> 00:06:26,817
Porque podría ser un cuello de botella.

177
00:06:26,757 --> 00:06:28,997
Es una pregunta muy pertinente.

178
00:06:28,997 --> 00:06:30,457
No es trivial.

179
00:06:30,457 --> 00:06:33,377
Generar la caché para, digamos, unas 300 páginas

180
00:06:33,377 --> 00:06:35,877
puede llevar varios minutos en una GPU de

181
00:06:35,877 --> 00:06:36,697
gama alta.

182
00:06:36,697 --> 00:06:37,997
Es una inversión inicial.

183
00:06:38,017 --> 00:06:39,157
Pero se amortiza.

184
00:06:39,217 --> 00:06:40,797
Se amortiza muy rápido.

185
00:06:40,797 --> 00:06:42,357
Si el sistema va a recibir miles de

186
00:06:42,357 --> 00:06:44,557
consultas, el tiempo que te ahorras en cada

187
00:06:44,557 --> 00:06:47,137
una compensa con creces esa inversión.

188
00:06:46,877 --> 00:06:48,157
Entendido.

189
00:06:48,157 --> 00:06:52,037
Entonces, si aceptamos ese coste, SIG parece que

190
00:06:52,037 --> 00:06:55,417
resuelve de un plumazo los tres grandes problemas

191
00:06:55,417 --> 00:06:56,377
de RAG.

192
00:06:56,557 --> 00:06:59,177
Latencia, complejidad y errores.

193
00:06:59,177 --> 00:07:00,537
Simplemente desaparecen.

194
00:07:01,277 --> 00:07:03,857
En su mayor parte sí, desaparecen.

195
00:07:03,857 --> 00:07:06,337
La latencia de recuperación se evapora porque no

196
00:07:06,337 --> 00:07:07,157
hay recuperación.

197
00:07:07,857 --> 00:07:10,157
La arquitectura se simplifica muchísimo.

198
00:07:10,157 --> 00:07:12,017
Adiós a la base de datos vectorial, al

199
00:07:12,017 --> 00:07:15,677
indexador… Y los errores de recuperación son imposibles.

200
00:07:16,377 --> 00:07:19,157
Imposibles, porque el modelo no tiene que elegir

201
00:07:19,157 --> 00:07:20,677
qué fragmentos ver.

202
00:07:20,677 --> 00:07:23,277
Tiene una visión completa, holística, de todo el

203
00:07:23,277 --> 00:07:25,397
conocimiento desde el primer momento.

204
00:07:25,877 --> 00:07:28,377
Vale, pongámoslos frente a frente.

205
00:07:28,617 --> 00:07:30,417
Si SIG es tan bueno.

206
00:07:30,477 --> 00:07:32,637
La pregunta obvia es, ¿por qué no lo

207
00:07:32,637 --> 00:07:33,937
usamos para todo?

208
00:07:34,077 --> 00:07:36,117
¿Qué dicen los datos de rendimiento que hemos

209
00:07:36,117 --> 00:07:37,177
analizado?

210
00:07:37,137 --> 00:07:40,477
Aquí es donde los resultados son realmente impactantes.

211
00:07:41,197 --> 00:07:43,477
En pruebas con basas de conocimiento como Hotpot

212
00:07:43,477 --> 00:07:46,837
QA, las diferencias de velocidad son abismales.

213
00:07:46,837 --> 00:07:50,457
Un sistema CAG responde de media en 0,85

214
00:07:50,457 --> 00:07:50,917
segundos.

215
00:07:51,317 --> 00:07:52,077
¿0,85?

216
00:07:52,977 --> 00:07:53,637
Sí.

217
00:07:53,637 --> 00:07:57,417
Un sistema RAG comparable tarda unos 9,25 segundos.

218
00:07:58,337 --> 00:08:00,657
Eso es más de 10 veces más rápido,

219
00:08:00,657 --> 00:08:04,437
una diferencia brutal para cualquier aplicación interactiva.

220
00:08:04,217 --> 00:08:05,617
Y se pone mejor.

221
00:08:05,617 --> 00:08:07,817
En conjuntos de datos un poco más grandes,

222
00:08:07,817 --> 00:08:08,917
la diferencia se dispara.

223
00:08:09,777 --> 00:08:12,197
Las fuentes hablan de 2,3 segundos para CAG

224
00:08:12,197 --> 00:08:15,797
frente a unos increíbles 94,3 segundos para RAG.

225
00:08:16,197 --> 00:08:18,837
Un momento, es una mejora de hasta 40

226
00:08:18,837 --> 00:08:19,697
veces.

227
00:08:19,797 --> 00:08:20,557
Hasta 40 veces.

228
00:08:21,057 --> 00:08:23,497
Suena casi demasiado bueno para ser verdad.

229
00:08:23,617 --> 00:08:26,017
En estas comparativas estamos seguros de que se

230
00:08:26,017 --> 00:08:29,517
comparan sistemas optimizados en ambos lados.

231
00:08:29,757 --> 00:08:31,417
O sea, no podría ser un escenario ideal

232
00:08:31,417 --> 00:08:33,857
para CAG contra un RAG que no está

233
00:08:33,857 --> 00:08:35,017
del todo afinado.

234
00:08:34,757 --> 00:08:37,675
Es una dosis de escepticismo muy saludable.

235
00:08:37,755 --> 00:08:40,255
Y aunque la optimización siempre es un factor,

236
00:08:40,395 --> 00:08:42,575
la diferencia aquí es arquitectónica.

237
00:08:43,335 --> 00:08:45,875
RAG implica, por narices, una llamada de red

238
00:08:45,875 --> 00:08:48,415
a una base de datos, una búsqueda… Unos

239
00:08:48,415 --> 00:08:49,675
pasos que no te puedes saltar.

240
00:08:49,895 --> 00:08:50,915
Exacto.

241
00:08:50,915 --> 00:08:53,055
CAG elimina todo eso.

242
00:08:53,035 --> 00:08:54,755
Es la diferencia entre buscar un dato en

243
00:08:54,755 --> 00:08:56,855
un libro que tienes en otra habitación o

244
00:08:56,855 --> 00:08:58,595
tenerlo ya abierto sobre la mesa.

245
00:08:59,095 --> 00:09:01,855
Incluso el RAG más optimizado del mundo tendrá

246
00:09:01,855 --> 00:09:03,715
siempre ese cuello de botella.

247
00:09:03,735 --> 00:09:06,015
Vale, aceptamos la ventaja en velocidad.

248
00:09:06,395 --> 00:09:07,915
Pero la velocidad no sirve de nada si

249
00:09:07,915 --> 00:09:09,035
las respuestas son peores.

250
00:09:09,635 --> 00:09:10,715
¿Qué pasa con la precisión?

251
00:09:11,295 --> 00:09:13,235
Uno podría pensar que darle al modelo cientos

252
00:09:13,235 --> 00:09:15,755
de páginas a la vez podría confundirlo.

253
00:09:14,975 --> 00:09:18,715
Pues, contra toda intuición, ocurre lo contrario.

254
00:09:18,955 --> 00:09:20,055
Aquí también hay sorpresas.

255
00:09:20,715 --> 00:09:23,615
Lejos de confundirse, los estudios muestran que CAAG

256
00:09:23,615 --> 00:09:27,615
suele obtener puntuaciones de precisión ligeramente superiores.

257
00:09:27,475 --> 00:09:27,635
Ah.

258
00:09:27,995 --> 00:09:28,895
Sí.

259
00:09:28,895 --> 00:09:31,475
Por ejemplo, una fuente reporta una puntuación BERT

260
00:09:31,475 --> 00:09:37,815
score de 0,7759 para CAG frente a 0,751

261
00:09:37,815 --> 00:09:38,475
para RAG.

262
00:09:38,875 --> 00:09:40,375
¿Y cuál es la teoría detrás de esa

263
00:09:40,375 --> 00:09:40,815
mejora?

264
00:09:41,155 --> 00:09:43,175
La hipótesis es que, al tener la visión

265
00:09:43,175 --> 00:09:45,735
global de todo el contexto, el modelo puede

266
00:09:45,735 --> 00:09:48,195
realizar razonamientos más complejos.

267
00:09:48,215 --> 00:09:50,375
Puede conectar una idea del documento A con

268
00:09:50,375 --> 00:09:52,495
un detalle del documento Z.

269
00:09:52,355 --> 00:09:54,695
Algo que un RAG solo podría hacer si

270
00:09:54,695 --> 00:09:57,875
el recuperador, por casualidad, trae justo esos dos

271
00:09:57,875 --> 00:09:58,635
fragmentos.

272
00:09:58,715 --> 00:10:00,035
Exactamente.

273
00:10:00,035 --> 00:10:02,075
Si falla en recuperar uno, la conexión se

274
00:10:02,075 --> 00:10:02,915
pierde.

275
00:10:03,155 --> 00:10:05,655
CAG, al tener la panorámica completa, no sufre

276
00:10:05,655 --> 00:10:06,915
esa limitación.

277
00:10:07,015 --> 00:10:09,975
Puede encontrar relaciones sutiles entre distintas partes del

278
00:10:09,975 --> 00:10:11,035
conocimiento.

279
00:10:11,135 --> 00:10:11,915
De acuerdo.

280
00:10:11,915 --> 00:10:13,135
Recapitulo.

281
00:10:13,135 --> 00:10:16,635
Es drásticamente más rápido y, sorprendentemente, un poco

282
00:10:16,635 --> 00:10:17,715
más preciso.

283
00:10:18,215 --> 00:10:19,835
Aquí tiene que estar la trampa.

284
00:10:19,835 --> 00:10:21,575
¿Cuál es el talón de Aquiles de CAG?

285
00:10:21,415 --> 00:10:24,455
Tiene dos, y son muy importantes.

286
00:10:24,455 --> 00:10:26,075
Son las razones por las que RAG no

287
00:10:26,075 --> 00:10:27,555
va a desaparecer.

288
00:10:27,555 --> 00:10:31,195
La primera, el conocimiento es estático.

289
00:10:31,195 --> 00:10:32,455
La caché es una foto fija.

290
00:10:32,955 --> 00:10:33,455
Claro.

291
00:10:33,515 --> 00:10:36,235
Si tu base de datos se actualiza constantemente,

292
00:10:36,235 --> 00:10:39,295
precios de acciones, noticias, el inventario de una

293
00:10:39,295 --> 00:10:42,215
tienda, la caché se queda obsoleta al instante.

294
00:10:42,135 --> 00:10:45,075
Y para actualizarla tendrías que regenerar toda la

295
00:10:45,075 --> 00:10:48,095
caché, con el coste que eso implica.

296
00:10:48,095 --> 00:10:50,195
Inviable para datos en tiempo real.

297
00:10:50,075 --> 00:10:51,095
Exacto.

298
00:10:51,095 --> 00:10:53,555
Y la segunda gran limitación es el propio

299
00:10:53,555 --> 00:10:55,875
tamaño de la ventana de contexto.

300
00:10:55,875 --> 00:10:58,735
Aunque son enormes, tienen un límite.

301
00:10:58,735 --> 00:11:01,935
Una ventana de 128.000 tokens puede albergar unas

302
00:11:01,935 --> 00:11:03,015
300 páginas.

303
00:11:03,015 --> 00:11:04,055
Que es mucho.

304
00:11:04,055 --> 00:11:06,595
Es mucho, pero es insuficiente para bases de

305
00:11:06,595 --> 00:11:08,675
datos a escala de una gran empresa, que

306
00:11:08,675 --> 00:11:10,935
pueden tener millones de documentos.

307
00:11:10,755 --> 00:11:12,415
O sea que, por ejemplo, no podrías cargar

308
00:11:12,415 --> 00:11:15,035
todo el boletín oficial del Estado, o toda

309
00:11:15,035 --> 00:11:17,235
la documentación técnica de una multinacional.

310
00:11:17,235 --> 00:11:18,615
Simplemente no cabe.

311
00:11:18,435 --> 00:11:19,595
Correcto.

312
00:11:19,595 --> 00:11:21,655
RAH, en cambio, tiene un tamaño de corpus

313
00:11:21,655 --> 00:11:25,135
teóricamente ilimitado, porque solo carga los pocos fragmentos

314
00:11:25,135 --> 00:11:26,615
que necesita en cada consulta.

315
00:11:27,115 --> 00:11:29,395
Lo que nos lleva a la conclusión lógica.

316
00:11:29,395 --> 00:11:31,895
No se trata de que una tecnología vaya

317
00:11:31,895 --> 00:11:32,955
a reemplazar a la otra.

318
00:11:33,255 --> 00:11:33,975
Para nada.

319
00:11:33,995 --> 00:11:36,815
Sino de que son herramientas diferentes para problemas

320
00:11:36,815 --> 00:11:37,295
diferentes.

321
00:11:37,295 --> 00:11:40,775
O, como sugieren varias de las fuentes, de

322
00:11:40,775 --> 00:11:44,655
que la solución definitiva podría ser usarlas juntas.

323
00:11:44,275 --> 00:11:46,575
Esa es precisamente la dirección que está tomando

324
00:11:46,575 --> 00:11:49,075
la industria, los sistemas híbridos.

325
00:11:49,135 --> 00:11:50,735
Y la estrategia más común es la de

326
00:11:50,735 --> 00:11:53,395
clasificar los datos como calientes y fríos.

327
00:11:53,775 --> 00:11:56,835
¿Puedes explicar qué significa eso en la práctica?

328
00:11:56,835 --> 00:11:58,735
¿Qué es un dato caliente frente a uno

329
00:11:58,735 --> 00:11:59,255
frío?

330
00:11:59,255 --> 00:12:01,275
Piensa en los datos calientes como el núcleo

331
00:12:01,275 --> 00:12:04,155
de conocimiento estable y de acceso muy frecuente.

332
00:12:04,275 --> 00:12:07,035
Para una empresa, pues sus políticas internas, manuales

333
00:12:07,035 --> 00:12:09,455
de producto, las preguntas frecuentes.

334
00:12:09,375 --> 00:12:11,015
Lo que se pregunta siempre.

335
00:12:10,855 --> 00:12:11,695
Eso es.

336
00:12:11,695 --> 00:12:14,755
Esa información se carga en la capa CAG.

337
00:12:14,755 --> 00:12:16,675
Al estar en la caché, las respuestas a

338
00:12:16,675 --> 00:12:18,615
las preguntas más comunes son instantáneas.

339
00:12:19,215 --> 00:12:21,015
Y supongo que RAG se encarga de todo

340
00:12:21,015 --> 00:12:23,095
lo demás, del conocimiento frío.

341
00:12:23,255 --> 00:12:24,115
Exacto.

342
00:12:24,115 --> 00:12:26,195
El conocimiento frío son los datos de nicho,

343
00:12:26,195 --> 00:12:28,095
los que son muy voluminosos o los que

344
00:12:28,095 --> 00:12:29,515
cambian a gran velocidad.

345
00:12:29,915 --> 00:12:32,455
En un sistema híbrido, el flujo sería así.

346
00:12:32,455 --> 00:12:35,095
Llega la pregunta, el sistema intenta responderla con

347
00:12:35,095 --> 00:12:36,275
la capa CAG.

348
00:12:36,035 --> 00:12:37,395
Que es la rápida.

349
00:12:36,915 --> 00:12:38,375
La rapidísima.

350
00:12:38,375 --> 00:12:40,755
Si encuentra la respuesta, perfecto.

351
00:12:40,755 --> 00:12:42,295
Si no, o si la información no es

352
00:12:42,295 --> 00:12:44,975
suficiente, la consulta se escala y se pasa

353
00:12:44,975 --> 00:12:46,615
a la capa RAG para que haga una

354
00:12:46,615 --> 00:12:48,275
búsqueda en tiempo real en la base de

355
00:12:48,275 --> 00:12:49,495
datos completa.

356
00:12:49,575 --> 00:12:52,255
Demos un ejemplo más para solidificar la idea.

357
00:12:52,255 --> 00:12:54,815
Pensemos en un asistente para una tienda online.

358
00:12:54,795 --> 00:12:56,533
Los datos calientes en la caché de CAG

359
00:12:56,533 --> 00:12:59,673
serían las políticas de devolución, las especificaciones de

360
00:12:59,673 --> 00:13:01,193
los productos más vendidos.

361
00:13:01,293 --> 00:13:02,973
Perfectamente ilustrado.

362
00:13:02,973 --> 00:13:05,653
Y si un cliente pregunta, ¿dónde está mi

363
00:13:05,653 --> 00:13:07,253
pedido con número X?

364
00:13:07,253 --> 00:13:09,533
O, ¿tenéis la talla M de esta camiseta

365
00:13:09,533 --> 00:13:11,013
en stock ahora mismo?

366
00:13:11,013 --> 00:13:12,913
Esa es una consulta fría.

367
00:13:12,913 --> 00:13:14,773
Claro, eso cambia a cada minuto.

368
00:13:14,773 --> 00:13:17,573
El sistema activaría la capa RAG para consultar

369
00:13:17,573 --> 00:13:19,313
en tiempo real la base de datos de

370
00:13:19,313 --> 00:13:21,853
pedidos o el sistema de inventario.

371
00:13:21,853 --> 00:13:24,073
Así combinas la velocidad de CAG para el

372
00:13:24,073 --> 00:13:27,253
80% de las consultas comunes con la flexibilidad

373
00:13:27,253 --> 00:13:29,693
de RAG para el 20% restante.

374
00:13:29,733 --> 00:13:32,113
¿Esto implica que el sistema necesita una especie

375
00:13:32,113 --> 00:13:34,653
de director de orquesta que decida qué camino

376
00:13:34,653 --> 00:13:36,173
tomar con cada pregunta?

377
00:13:36,293 --> 00:13:38,253
Correcto, y esa es un área de investigación

378
00:13:38,253 --> 00:13:39,673
muy activa.

379
00:13:39,673 --> 00:13:42,613
Ya existen mecanismos de enrutamiento inteligente.

380
00:13:42,613 --> 00:13:44,713
Uno de los estudios que revisamos menciona un

381
00:13:44,713 --> 00:13:48,693
sistema llamado Self-Route, que entrena al propio modelo

382
00:13:48,693 --> 00:13:51,353
de lenguaje para que sea él quien decida.

383
00:13:51,353 --> 00:13:52,353
El propio modelo.

384
00:13:52,353 --> 00:13:54,593
Sí, le llega una pregunta y el modelo

385
00:13:54,593 --> 00:13:55,813
predice.

386
00:13:55,813 --> 00:13:57,893
¿Puedo responder esto con la información de mi

387
00:13:57,893 --> 00:14:00,593
caché o necesito pedir ayuda externa?

388
00:14:00,593 --> 00:14:03,013
Así que el modelo se convierte en su

389
00:14:03,013 --> 00:14:06,193
propio controlador de tráfico de conocimiento y eso

390
00:14:06,193 --> 00:14:09,133
requiere un entrenamiento muy específico.

391
00:14:09,133 --> 00:14:11,493
Generalmente requiere un fine tuning para esa tarea

392
00:14:11,493 --> 00:14:12,633
de clasificación.

393
00:14:12,633 --> 00:14:15,173
Se le entrena con miles de ejemplos, pero

394
00:14:15,173 --> 00:14:17,253
lo fascinante es que estos sistemas son muy

395
00:14:17,253 --> 00:14:18,393
eficientes.

396
00:14:18,393 --> 00:14:20,893
El estudio de Selfroot demostró que podía alcanzar

397
00:14:20,893 --> 00:14:23,453
la misma calidad de respuesta, pero usando de

398
00:14:23,453 --> 00:14:26,413
media solo el 38% de los tokens.

399
00:14:26,493 --> 00:14:28,853
Es lo mejor de ambos mundos, entonces.

400
00:14:28,853 --> 00:14:30,813
Velocidad y eficiencia.

401
00:14:30,853 --> 00:14:31,333
Exacto.

402
00:14:31,313 --> 00:14:34,793
Notebooks LM, aunque entre bambalinas del podcast siempre

403
00:14:34,793 --> 00:14:37,413
está Julio Pablo Vázquez, que sigue con su

404
00:14:37,413 --> 00:14:41,153
vigilancia tecnológica en alerta constante para pescar los

405
00:14:41,153 --> 00:14:43,553
mejores temas y de más actualidad.

406
00:14:43,553 --> 00:14:45,473
Además, nos dice que os manda saludos y

407
00:14:45,473 --> 00:14:48,073
que está muy contento porque acaba de desarrollar

408
00:14:48,073 --> 00:14:50,653
un sistema propio con Python y Javascript y,

409
00:14:50,653 --> 00:14:53,413
por supuesto, IA, para automatizar el proceso de

410
00:14:53,413 --> 00:14:57,333
edición, descripción, transcripción, publicación y programación de todos

411
00:14:57,333 --> 00:14:58,113
los episodios.

412
00:14:58,753 --> 00:15:00,533
Ya veis, no solo le vamos a las

413
00:15:00,533 --> 00:15:03,433
parrafadas, también aplicamos el conocimiento a la práctica

414
00:15:03,433 --> 00:15:03,833
diaria.

415
00:15:04,513 --> 00:15:06,673
Gracias a este sistema, que hemos bautizado como

416
00:15:06,673 --> 00:15:09,773
Autopod, ahora podemos dedicar más tiempo al factor

417
00:15:09,773 --> 00:15:11,713
humano y minimizar errores.

418
00:15:11,733 --> 00:15:13,513
Quizá un día le dediquemos un episodio a

419
00:15:13,513 --> 00:15:16,213
contaros cómo creamos cada episodio, porque hay mucha

420
00:15:16,213 --> 00:15:18,273
IA y herramientas implicadas.

421
00:15:17,993 --> 00:15:19,153
¿Os parece interesante?

422
00:15:19,153 --> 00:15:21,693
Y para cerrar, una reflexión final que se

423
00:15:21,693 --> 00:15:23,833
deriva de toda esta discusión.

424
00:15:23,933 --> 00:15:27,553
La tensión entre RAG y CAC, impulsada por

425
00:15:27,553 --> 00:15:30,013
la explosión de las ventanas de contexto, nos

426
00:15:30,013 --> 00:15:32,733
obliga a plantearnos una pregunta de diseño fundamental

427
00:15:32,733 --> 00:15:34,133
para el futuro.

428
00:15:34,473 --> 00:15:38,093
CAC favorece un enfoque monolítico, centralizar todo el

429
00:15:38,093 --> 00:15:41,053
conocimiento posible en un único y masivo prompt,

430
00:15:41,013 --> 00:15:43,173
un gran cerebro precargado.

431
00:15:43,233 --> 00:15:45,333
Mientras que RAG es modular.

432
00:15:45,513 --> 00:15:47,813
RAG, por el contrario, aboga por un enfoque

433
00:15:47,813 --> 00:15:51,713
modular, mantener el conocimiento externo, descentralizado, en una

434
00:15:51,713 --> 00:15:54,833
biblioteca que se consulta sólo cuando es necesario.

435
00:15:54,893 --> 00:15:58,973
La pregunta que debemos hacernos es, ¿qué tipo

436
00:15:58,973 --> 00:16:01,973
de arquitectura de IA queremos construir?

437
00:16:02,553 --> 00:16:05,093
¿Sistemas con un único y enorme cerebro que

438
00:16:05,093 --> 00:16:06,273
lo sabe todo de antemano?

439
00:16:06,753 --> 00:16:08,613
¿O sistemas con un cerebro más ágil y

440
00:16:08,613 --> 00:16:11,373
especializado que es experto en consultar una vasta

441
00:16:11,373 --> 00:16:12,873
red de bibliotecas externas?

442
00:16:13,633 --> 00:16:15,753
Las decisiones que los arquitectos de IA tomen

443
00:16:15,753 --> 00:16:19,153
hoy entre estos dos modelos definirán la flexibilidad,

444
00:16:19,153 --> 00:16:21,613
la escalabilidad y, en última instancia, la robustez

445
00:16:21,613 --> 00:16:23,673
de la inteligencia artificial del mañana.

446
00:16:35,093 --> 00:16:37,273
Y hasta aquí el episodio de hoy.

447
00:16:37,273 --> 00:16:38,813
Muchas gracias por tu atención.

448
00:16:48,713 --> 00:16:50,873
Esto es BIMPRAXIS.

449
00:16:50,873 --> 00:16:52,993
Nos escuchamos en el próximo episodio.

450
00:17:13,713 --> 00:17:14,173
¡Gracias!