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,280 --> 00:00:38,320
Muy buenas.

8
00:00:38,320 --> 00:00:40,460
Episodio 51.

9
00:00:40,460 --> 00:00:42,840
Continuamos con la serie dedicada a los RAG,

10
00:00:42,840 --> 00:00:45,579
Retrieval Augmented Generation.

11
00:00:45,579 --> 00:00:48,079
Hoy hablaremos de cómo mejorar la calidad de

12
00:00:48,079 --> 00:00:49,619
la recuperación.

13
00:00:49,619 --> 00:00:53,039
Bienvenidos al podcast de BIMPRAXIS.

14
00:00:53,039 --> 00:00:54,759
La idea central de estos sistemas, ya lo

15
00:00:54,759 --> 00:00:57,560
sabemos, es conectar un modelo de lenguaje a

16
00:00:57,560 --> 00:00:59,820
una base de conocimiento para que dé respuestas

17
00:00:59,820 --> 00:01:01,619
más precisas.

18
00:01:01,619 --> 00:01:05,519
Pero, ¿qué pasa cuando esa conexión falla?

19
00:01:05,519 --> 00:01:08,180
Pues ese es precisamente el punto crítico.

20
00:01:08,180 --> 00:01:10,500
Es que la calidad de todo el sistema

21
00:01:10,500 --> 00:01:12,599
depende casi por completo de la calidad de

22
00:01:12,599 --> 00:01:14,120
la recuperación.

23
00:01:14,120 --> 00:01:16,180
De encontrar los documentos correctos.

24
00:01:16,180 --> 00:01:16,840
Exacto.

25
00:01:16,840 --> 00:01:19,379
De encontrar los documentos correctos para darle contexto

26
00:01:19,379 --> 00:01:20,799
al modelo.

27
00:01:20,799 --> 00:01:24,180
Si los documentos que recuperas son, pues, irrelevantes

28
00:01:24,180 --> 00:01:26,719
o incorrectos, da igual lo bueno que sea

29
00:01:26,719 --> 00:01:28,299
tu modelo o el prompt final.

30
00:01:28,299 --> 00:01:29,739
La respuesta va a ser mala.

31
00:01:29,739 --> 00:01:32,439
Va a ser mediocre o directamente errónea.

32
00:01:32,379 --> 00:01:34,120
Y el material que analizamos hoy, que viene

33
00:01:34,120 --> 00:01:37,000
de un proyecto real documentado por Johannes Jolkonen

34
00:01:36,920 --> 00:01:40,579
en su canal Functio AI, aborda justo esto.

35
00:01:40,579 --> 00:01:42,819
Se enfrentaron a un sistema que, bueno, apenas

36
00:01:42,579 --> 00:01:44,280
acertaba la mitad de las veces.

37
00:01:44,280 --> 00:01:45,420
Que ya es decir.

38
00:01:45,420 --> 00:01:47,359
Y lo transformaron en uno con una precisión

39
00:01:47,359 --> 00:01:49,400
de más del 95%.

40
00:01:49,400 --> 00:01:52,060
Así que hoy vamos a desgranar cómo lograron

41
00:01:52,060 --> 00:01:53,640
esa mejora tan espectacular.

42
00:01:53,640 --> 00:01:55,599
Es un caso de manual, de verdad.

43
00:01:55,599 --> 00:01:58,439
Sobre cómo un diagnóstico inteligente del problema te

44
00:01:58,019 --> 00:02:00,640
puede llevar a una solución mucho más eficaz

45
00:02:00,640 --> 00:02:03,640
que, bueno, que simplemente aplicar la tecnología más

46
00:02:03,640 --> 00:02:04,739
popular del momento.

47
00:02:04,760 --> 00:02:06,120
Pues vamos a ello.

48
00:02:06,120 --> 00:02:08,080
Para entender la genialidad de la solución, creo

49
00:02:08,080 --> 00:02:10,520
que lo mejor es empezar por el principio.

50
00:02:10,520 --> 00:02:12,620
¿Cuál era el sistema que tenían montado y

51
00:02:12,620 --> 00:02:13,979
por qué fallaba de esa forma?

52
00:02:14,039 --> 00:02:16,039
A ver, el punto de partida era un

53
00:02:16,039 --> 00:02:17,460
proyecto bastante común.

54
00:02:17,460 --> 00:02:19,500
Un chatbot interno para una empresa del sector

55
00:02:19,500 --> 00:02:20,639
del bienestar.

56
00:02:20,639 --> 00:02:21,919
Spine Wellness.

57
00:02:21,919 --> 00:02:24,419
El objetivo era que los empleados de atención

58
00:02:24,419 --> 00:02:28,699
al cliente pudieran consultar rápido información sobre servicios,

59
00:02:28,699 --> 00:02:31,020
ubicaciones, especialistas.

60
00:02:31,020 --> 00:02:34,020
Cientos de empleados necesitaban respuestas al instante.

61
00:02:35,060 --> 00:02:37,340
Una herramienta de productividad, vaya.

62
00:02:37,340 --> 00:02:39,500
Y por lo que dicen, la arquitectura que

63
00:02:39,500 --> 00:02:42,000
montaron era la estándar para un sistema a

64
00:02:42,000 --> 00:02:42,639
RAG.

65
00:02:42,560 --> 00:02:43,960
Totalmente estándar.

66
00:02:43,960 --> 00:02:45,780
Siguieron el libro de jugadas al pie de

67
00:02:45,780 --> 00:02:46,740
la letra.

68
00:02:46,740 --> 00:02:50,580
Primero, recopilaron datos de sus sistemas, descripciones de

69
00:02:50,580 --> 00:02:53,599
spas, gimnasios, perfiles de masajistas.

70
00:02:53,599 --> 00:02:57,580
Luego, limpiaron y trocearon esa información en chunks.

71
00:02:57,879 --> 00:03:02,379
Tercero, crearon los embeddings, estas representaciones numéricas que

72
00:03:02,379 --> 00:03:03,639
capturan el significado.

73
00:03:04,300 --> 00:03:06,500
Y finalmente, lo cargaron todo en una base

74
00:03:06,500 --> 00:03:09,639
de datos vectorial, en su caso, Azure AI

75
00:03:09,639 --> 00:03:12,280
Search, para las búsquedas semánticas.

76
00:03:12,159 --> 00:03:14,699
Y para simplificar, unieron todos los campos de

77
00:03:14,699 --> 00:03:17,960
texto, como la descripción, la ciudad, las especialidades,

78
00:03:18,780 --> 00:03:21,879
todo en un único campo gigante llamado content.

79
00:03:21,840 --> 00:03:23,659
Sí, sobre el que se hacía la búsqueda.

80
00:03:23,939 --> 00:03:28,419
Suena lógico, pero claro, los problemas aparecieron enseguida.

81
00:03:28,419 --> 00:03:31,000
Cuando un usuario preguntaba algo tan simple como

82
00:03:31,000 --> 00:03:34,199
masaje sueco en Helsinki, la tasa de acierto

83
00:03:34,199 --> 00:03:36,199
era de un 50-60%.

84
00:03:36,199 --> 00:03:39,960
Para una herramienta profesional, eso es un fracaso.

85
00:03:39,919 --> 00:03:41,020
Es inaceptable.

86
00:03:41,020 --> 00:03:42,580
Y aquí es donde la historia se pone

87
00:03:42,580 --> 00:03:45,139
de verdad interesante, porque su primer instinto fue

88
00:03:45,139 --> 00:03:47,840
intentar mejorar la búsqueda probando los dos enfoques

89
00:03:47,840 --> 00:03:49,159
más populares.

90
00:03:49,139 --> 00:03:49,919
Y ambos fallaron.

91
00:03:50,139 --> 00:03:53,500
Y ambos fallaron, pero por razones completamente opuestas.

92
00:03:53,020 --> 00:03:55,800
Empecemos por el primero, la búsqueda vectorial.

93
00:03:55,780 --> 00:03:57,467
Es como la técnica estrella en el mundo

94
00:03:57,467 --> 00:03:59,887
RAG, la que usa los embeddings para encontrar

95
00:03:59,887 --> 00:04:01,407
cosas por similitud.

96
00:04:01,387 --> 00:04:02,407
¿Por qué no les funcionó?

97
00:04:02,467 --> 00:04:05,267
La fuente lo describe como un fracaso total

98
00:04:04,827 --> 00:04:07,547
para este caso de uso concreto.

99
00:04:07,647 --> 00:04:08,887
Y la razón es...

100
00:04:08,887 --> 00:04:10,987
es útil pero fundamental.

101
00:04:11,307 --> 00:04:13,787
La búsqueda vectorial es brillante para la similitud

102
00:04:13,787 --> 00:04:17,667
semántica, para lo que podríamos llamar coincidencia difusa.

103
00:04:18,087 --> 00:04:18,667
Vale.

104
00:04:17,927 --> 00:04:21,767
Si buscas coche deportivo rojo, te puede devolver

105
00:04:21,767 --> 00:04:25,447
documentos que hablen de un automóvil rápido escarlata,

106
00:04:25,447 --> 00:04:27,887
porque entiende que son conceptos relacionados.

107
00:04:27,887 --> 00:04:31,967
O sea que el sistema era demasiado creativo,

108
00:04:31,967 --> 00:04:32,687
por así decirlo.

109
00:04:33,387 --> 00:04:36,867
Entendía que Helsinki y Estocolmo eran parecidas por

110
00:04:36,867 --> 00:04:39,887
ser capitales nórdicas, pero para el usuario que

111
00:04:39,887 --> 00:04:43,067
busca algo en una ciudad concreta, esa inteligencia

112
00:04:43,067 --> 00:04:44,187
es un error.

113
00:04:44,187 --> 00:04:45,527
Exactamente.

114
00:04:45,527 --> 00:04:48,547
Devolvía otros tipos de masajes porque eran semánticamente

115
00:04:48,547 --> 00:04:52,127
parecidos, o servicios en otras ciudades porque eran

116
00:04:52,127 --> 00:04:54,347
semánticamente parecidas a Helsinki.

117
00:04:54,347 --> 00:04:56,167
El problema es que el usuario no quería

118
00:04:56,167 --> 00:05:00,047
algo parecido, quería exactamente un masaje sueco en

119
00:05:00,047 --> 00:05:00,827
Helsinki.

120
00:05:00,827 --> 00:05:05,727
Necesitaban una coincidencia exacta, no una aproximación.

121
00:05:05,727 --> 00:05:06,907
Justo.

122
00:05:06,907 --> 00:05:08,807
Vale, entiendo el problema.

123
00:05:08,807 --> 00:05:12,627
La búsqueda semántica era demasiado imprecisa, Así que,

124
00:05:12,627 --> 00:05:15,667
lógicamente, probaron el otro extremo, la búsqueda de

125
00:05:15,667 --> 00:05:17,827
texto completo de toda la vida con el

126
00:05:17,827 --> 00:05:21,187
algoritmo BM25, que se basa en palabras clave

127
00:05:21,187 --> 00:05:21,847
exactas.

128
00:05:22,347 --> 00:05:23,247
Eso es.

129
00:05:23,547 --> 00:05:26,287
La fuente dice que fue un poco mejor,

130
00:05:26,287 --> 00:05:27,587
pero no mucho.

131
00:05:27,587 --> 00:05:28,867
¿Qué falló esta vez?

132
00:05:29,007 --> 00:05:31,687
Aquí el problema era casi el contrario.

133
00:05:31,687 --> 00:05:33,707
El sistema era demasiado literal y se dejaba

134
00:05:33,707 --> 00:05:36,227
engañar por la frecuencia de las palabras.

135
00:05:36,227 --> 00:05:38,247
El ejemplo que usan es brillante.

136
00:05:38,207 --> 00:05:38,967
A ver.

137
00:05:39,167 --> 00:05:41,247
Imagina que tienes dos ubicaciones.

138
00:05:41,427 --> 00:05:43,907
La ubicación A, que es irrelevante, no ofrece

139
00:05:43,907 --> 00:05:44,727
masaje sueco.

140
00:05:45,227 --> 00:05:47,427
Pero en su descripción la palabra masaje aparece

141
00:05:47,427 --> 00:05:50,107
seis veces porque ofrecen muchos otros tipos.

142
00:05:49,927 --> 00:05:52,207
Tailandés, de tejido profundo.

143
00:05:52,247 --> 00:05:52,707
Eso es.

144
00:05:53,187 --> 00:05:54,507
Y para colmo, en el menú de su

145
00:05:54,507 --> 00:05:57,527
cafetería sirven albóndigas suecas.

146
00:05:57,307 --> 00:05:58,307
No puede ser.

147
00:05:58,407 --> 00:05:59,767
Ya veo por dónde vas.

148
00:05:58,987 --> 00:06:02,627
Pues esa ubicación, que no sirve para nada,

149
00:06:02,627 --> 00:06:06,087
acumula siete coincidencias con las palabras masaje y

150
00:06:06,087 --> 00:06:06,487
sueco.

151
00:06:07,127 --> 00:06:09,927
Ahora, compárala con la ubicación B, que es

152
00:06:09,927 --> 00:06:11,227
el resultado perfecto.

153
00:06:11,227 --> 00:06:14,507
Un centro en Helsinki que solo ofrece masaje

154
00:06:14,507 --> 00:06:15,367
sueco.

155
00:06:15,327 --> 00:06:16,007
Claro.

156
00:06:16,107 --> 00:06:19,867
Su documento solo tiene tres coincidencias, masaje, sueco

157
00:06:19,867 --> 00:06:21,247
y Helsinki.

158
00:06:21,787 --> 00:06:25,427
El algoritmo BM25, como prima la frecuencia, colocaría

159
00:06:25,427 --> 00:06:28,367
el resultado incorrecto por encima del correcto.

160
00:06:28,047 --> 00:06:30,327
Es un fallo de diseño del método para

161
00:06:30,327 --> 00:06:32,207
este tipo de consulta.

162
00:06:32,207 --> 00:06:34,627
El sistema no entiende el contexto, solo cuenta

163
00:06:34,627 --> 00:06:35,467
palabras.

164
00:06:34,987 --> 00:06:37,427
Y por si fuera poco, había un segundo

165
00:06:37,427 --> 00:06:39,907
problema, muy grave porque el proyecto era en

166
00:06:39,907 --> 00:06:42,607
finés, pero que afecta a muchísimos idiomas, español

167
00:06:42,607 --> 00:06:43,147
incluido.

168
00:06:43,147 --> 00:06:45,427
Las declinaciones y conjugaciones.

169
00:06:45,847 --> 00:06:46,707
Ah, claro.

170
00:06:46,787 --> 00:06:49,367
Si el usuario busca en Helsinki, con una

171
00:06:49,367 --> 00:06:52,247
terminación gramatical, pero en el documento la palabra

172
00:06:52,247 --> 00:06:56,027
Helsinki aparece de otra forma, BM25 simplemente no

173
00:06:56,027 --> 00:06:57,327
lo encuentra.

174
00:06:57,327 --> 00:06:58,647
No es tan listo.

175
00:06:58,447 --> 00:06:59,007
Vale.

176
00:06:59,007 --> 00:07:01,327
El panorama es desolador.

177
00:07:01,327 --> 00:07:04,187
Ni la búsqueda semántica inteligente ni la búsqueda

178
00:07:04,187 --> 00:07:06,787
literal por palabras clave funcionaban.

179
00:07:06,787 --> 00:07:08,707
Estaban en un callejón sin salida.

180
00:07:08,647 --> 00:07:09,787
Exacto.

181
00:07:09,787 --> 00:07:11,367
Se dieron cuenta de que el problema no

182
00:07:11,367 --> 00:07:14,267
era qué algoritmo de búsqueda usar, sino la

183
00:07:14,267 --> 00:07:15,527
naturaleza de sus datos.

184
00:07:16,267 --> 00:07:19,887
Y la solución que encontraron fue sorprendentemente simple

185
00:07:19,887 --> 00:07:21,107
y elegante.

186
00:07:21,307 --> 00:07:23,847
Implicó dos cambios, uno en cómo preparaban los

187
00:07:23,847 --> 00:07:26,067
datos en el back-end y otro en cómo

188
00:07:26,067 --> 00:07:28,747
interpretaban la pregunta del usuario en el front-end.

189
00:07:29,067 --> 00:07:30,707
Empecemos por el back-end.

190
00:07:30,707 --> 00:07:32,207
¿Cuál fue ese cambio en la indexación?

191
00:07:32,867 --> 00:07:35,887
El cambio fue conceptualmente muy potente.

192
00:07:35,987 --> 00:07:37,907
En lugar de tener toda la información en

193
00:07:37,907 --> 00:07:41,987
un campo de texto desestructurado, decidieron añadir metadatos

194
00:07:41,987 --> 00:07:43,207
estructurados.

195
00:07:43,487 --> 00:07:43,967
¿Cómo?

196
00:07:43,707 --> 00:07:46,547
Pues en concreto, añadieron un nuevo campo llamado

197
00:07:46,547 --> 00:07:47,947
servicios.

198
00:07:47,947 --> 00:07:50,087
En la práctica, esto significa que la frase

199
00:07:50,087 --> 00:07:52,667
masaje sueco, que antes estaba perdida en un

200
00:07:52,667 --> 00:07:55,514
párrafo, ahora se convertía en una etiqueta dentro

201
00:07:55,514 --> 00:07:56,414
de una lista.

202
00:07:56,414 --> 00:08:00,274
Algo como servicios, masaje sueco, reflexología.

203
00:08:00,254 --> 00:08:04,054
Un momento, eso suena genial, pero ¿de dónde

204
00:08:04,054 --> 00:08:06,334
sacaron esos datos estructurados?

205
00:08:06,334 --> 00:08:08,274
Si el problema era que todo estaba en

206
00:08:08,274 --> 00:08:10,694
texto, parece un círculo vicioso.

207
00:08:10,694 --> 00:08:12,514
No me digas que tuvieron que etiquetar miles

208
00:08:12,514 --> 00:08:13,994
de documentos a mano.

209
00:08:13,814 --> 00:08:16,014
Ahí está la genialidad de la solución.

210
00:08:16,014 --> 00:08:19,054
Utilizaron un modelo de lenguaje, un LLM, durante

211
00:08:19,054 --> 00:08:21,254
el propio proceso de indexación.

212
00:08:21,254 --> 00:08:21,854
¿Cómo?

213
00:08:22,014 --> 00:08:24,534
Para cada documento que entraba al sistema, pasaban

214
00:08:24,534 --> 00:08:27,214
el texto descriptivo por un LLM, con una

215
00:08:27,214 --> 00:08:28,334
instrucción muy directa.

216
00:08:28,974 --> 00:08:31,474
Extrae de este texto una lista estructurada de

217
00:08:31,474 --> 00:08:33,894
los servicios que se ofrecen y devuélvemela en

218
00:08:33,894 --> 00:08:35,114
formato JSON.

219
00:08:35,014 --> 00:08:37,434
O sea, que usaron la generación de un

220
00:08:37,434 --> 00:08:40,634
LLM para mejorar la recuperación.

221
00:08:40,634 --> 00:08:42,554
Invirtieron el acrónimo RAG.

222
00:08:42,354 --> 00:08:43,754
Justo eso.

223
00:08:43,754 --> 00:08:46,074
Es una idea que la fuente llama Generation

224
00:08:46,074 --> 00:08:48,134
Augmented Retrieval.

225
00:08:48,134 --> 00:08:50,294
En lugar de usar el LLM solo al

226
00:08:50,294 --> 00:08:53,394
final para responder, lo usaron al principio, para

227
00:08:53,394 --> 00:08:56,434
enriquecer y estructurar su base de conocimiento.

228
00:08:56,434 --> 00:08:58,954
Es como tener un ejército de documentalistas súper

229
00:08:58,954 --> 00:09:00,714
rápidos etiquetando tu archivo.

230
00:09:01,154 --> 00:09:02,214
Fascinante.

231
00:09:02,554 --> 00:09:05,014
Y, por cierto, como consecuencia de esto, eliminaron

232
00:09:05,014 --> 00:09:07,994
por completo los embeddings y la búsqueda vectorial.

233
00:09:08,214 --> 00:09:10,334
Concluyeron que para este problema no solo no

234
00:09:10,334 --> 00:09:12,114
ayudaban, sino que metían ruido.

235
00:09:12,594 --> 00:09:14,174
Pasaron de buscar en un pajar a tener

236
00:09:14,174 --> 00:09:16,314
un archivador perfectamente etiquetado.

237
00:09:16,374 --> 00:09:17,394
Ese fue el cambio en el Maken.

238
00:09:18,074 --> 00:09:19,774
¿Y la segunda pieza del puzzle, la del

239
00:09:19,774 --> 00:09:20,514
frontend?

240
00:09:20,814 --> 00:09:23,214
La segunda pieza fue cambiar cómo trataban la

241
00:09:23,214 --> 00:09:24,074
pregunta del usuario.

242
00:09:25,034 --> 00:09:28,394
Antes, la frase masaje sueco en Helsinki se

243
00:09:28,394 --> 00:09:30,414
lanzaba directamente contra el motor de búsqueda.

244
00:09:30,854 --> 00:09:31,714
Ahora no.

245
00:09:31,974 --> 00:09:34,014
Ahora esa frase se pasa primero por otro

246
00:09:34,014 --> 00:09:34,774
LLM.

247
00:09:35,234 --> 00:09:36,534
¿Con qué objetivo?

248
00:09:36,534 --> 00:09:38,454
¿Para que la reescriba o la mejore?

249
00:09:38,554 --> 00:09:40,714
Ah, para algo mucho más preciso.

250
00:09:40,854 --> 00:09:43,354
La única misión de este segundo LLM es

251
00:09:43,354 --> 00:09:45,174
actuar como un traductor.

252
00:09:45,534 --> 00:09:47,694
Convierte la pregunta en lenguaje natural del usuario

253
00:09:47,694 --> 00:09:50,614
en una consulta estructurada, formal, que la base

254
00:09:50,614 --> 00:09:52,814
de datos pueda entender sin ninguna ambigüedad.

255
00:09:53,514 --> 00:09:55,034
Ah, ya veo.

256
00:09:55,054 --> 00:09:57,874
Coge masaje sueco en Helsinki y lo transforma

257
00:09:57,874 --> 00:09:59,814
en una consulta de filtro estricta, como por

258
00:09:59,814 --> 00:10:03,314
ejemplo, ciudad igual a Helsinki, y servicios contiene

259
00:10:03,314 --> 00:10:04,634
masaje sueco.

260
00:10:04,834 --> 00:10:06,014
Brillante.

261
00:10:06,014 --> 00:10:09,634
Es decir, eliminaron por completo la ambigüedad.

262
00:10:09,634 --> 00:10:11,734
Ya no se busca algo que se parezca

263
00:10:11,734 --> 00:10:13,734
a esto, sino que se le ordena a

264
00:10:13,734 --> 00:10:16,574
la base de datos devuélveme solo los documentos

265
00:10:16,574 --> 00:10:19,414
que cumplan estas dos condiciones exactas.

266
00:10:19,234 --> 00:10:21,314
Es un cambio de paradigma total.

267
00:10:21,314 --> 00:10:23,314
Y el impacto fue, como era de esperar,

268
00:10:23,314 --> 00:10:25,154
inmediato, masivo.

269
00:10:25,354 --> 00:10:27,234
En la siguiente ronda de pruebas, la tasa

270
00:10:27,234 --> 00:10:29,454
de acierto se disparó a casi el 100%.

271
00:10:30,034 --> 00:10:31,094
Increíble.

272
00:10:31,094 --> 00:10:32,434
El feedback fue unánime.

273
00:10:32,434 --> 00:10:35,134
Los problemas de relevancia habían desaparecido.

274
00:10:35,214 --> 00:10:37,234
Los únicos fallos que quedaban eran casos muy

275
00:10:37,234 --> 00:10:39,594
puntuales, casi siempre por errores en los datos

276
00:10:39,594 --> 00:10:41,694
de origen, no en el sistema.

277
00:10:42,014 --> 00:10:42,814
Problema resuelto.

278
00:10:43,834 --> 00:10:46,274
Un resultado espectacular, desde luego.

279
00:10:46,514 --> 00:10:49,734
Pero esto suena demasiado bueno para ser verdad.

280
00:10:49,894 --> 00:10:51,874
Seguro que este enfoque tiene sus inconvenientes.

281
00:10:51,414 --> 00:10:54,654
¿Qué contrapartidas tuvieron que asumir?

282
00:10:54,674 --> 00:10:56,494
La fuente es muy transparente en eso e

283
00:10:56,494 --> 00:10:58,514
identificados trade-offs claros.

284
00:10:58,534 --> 00:11:00,554
El primero, como te puedes imaginar, es el

285
00:11:00,554 --> 00:11:00,854
coste.

286
00:11:01,354 --> 00:11:01,914
Claro.

287
00:11:01,974 --> 00:11:04,374
Usar un LLM para procesar y estructurar cada

288
00:11:04,374 --> 00:11:07,134
documento durante la indexación es más caro que

289
00:11:07,134 --> 00:11:08,514
simplemente generar un embedding.

290
00:11:09,194 --> 00:11:11,254
Cada documento que añades implica una llamada a

291
00:11:11,254 --> 00:11:13,254
una API y eso cuesta dinero.

292
00:11:13,394 --> 00:11:15,634
Un coste inicial y luego recurrente cada vez

293
00:11:15,634 --> 00:11:16,694
que se actualizan los datos.

294
00:11:17,354 --> 00:11:19,274
¿Cómo justificaron esa inversión?

295
00:11:19,014 --> 00:11:20,654
Lo pusieron en perspectiva.

296
00:11:20,754 --> 00:11:23,574
estaban construyendo una herramienta para ahorrar miles de

297
00:11:23,574 --> 00:11:25,634
horas a cientos de empleados.

298
00:11:26,214 --> 00:11:28,014
El coste adicional de las llamadas a la

299
00:11:28,014 --> 00:11:31,314
API era ínfimo en comparación con el valor

300
00:11:31,314 --> 00:11:33,654
de negocio que aportaba tener una herramienta que

301
00:11:33,654 --> 00:11:34,514
funcionaba de verdad.

302
00:11:34,894 --> 00:11:36,814
El retorno de la inversión era obvio.

303
00:11:36,834 --> 00:11:37,794
No fue ni un debate.

304
00:11:37,814 --> 00:11:38,974
Tiene todo el sentido, sí.

305
00:11:39,794 --> 00:11:41,054
¿Y la segunda contrapartida?

306
00:11:41,274 --> 00:11:42,794
La segunda es la latencia.

307
00:11:43,594 --> 00:11:45,354
La latencia en la respuesta al usuario.

308
00:11:46,214 --> 00:11:48,474
Al añadir ese paso intermedio, en el que

309
00:11:48,342 --> 00:11:52,002
un LLM traduce la pregunta, introduces un pequeño

310
00:11:52,002 --> 00:11:52,522
retraso.

311
00:11:52,322 --> 00:11:54,762
Y en una herramienta de uso intensivo, cada

312
00:11:54,762 --> 00:11:56,322
milisegundo cuenta.

313
00:11:56,582 --> 00:11:58,002
¿Cómo lo solucionaron?

314
00:11:58,082 --> 00:11:58,822
Con pragmatismo.

315
00:11:59,642 --> 00:12:01,182
Se dieron cuenta de que la tarea de

316
00:12:01,182 --> 00:12:04,722
traducir la consulta es muy simple y definida.

317
00:12:04,762 --> 00:12:07,382
Las entradas son cortas y las salidas también.

318
00:12:07,502 --> 00:12:09,582
No necesitas un modelo gigante y lento para

319
00:12:09,582 --> 00:12:10,302
eso.

320
00:12:10,422 --> 00:12:12,822
Optaron por un modelo mucho más pequeño, rápido

321
00:12:12,822 --> 00:12:15,282
y barato, optimizado para esa tarea.

322
00:12:15,842 --> 00:12:19,202
El retraso añadido fue mínimo, apenas perceptible, y

323
00:12:19,202 --> 00:12:21,542
el beneficio en la precisión lo compensaba con

324
00:12:21,542 --> 00:12:21,942
creces.

325
00:12:23,362 --> 00:12:27,122
Entonces, si destilamos la experiencia de este proyecto,

326
00:12:27,122 --> 00:12:29,102
¿qué significa todo esto para alguien que esté

327
00:12:29,102 --> 00:12:31,282
construyendo un sistema similar?

328
00:12:31,282 --> 00:12:32,702
¿Cuál es la gran lección?

329
00:12:32,742 --> 00:12:35,042
La lección más importante, que la propia fuente

330
00:12:35,042 --> 00:12:37,382
subraya, es que a veces las soluciones más

331
00:12:37,382 --> 00:12:39,182
directas e intuitivas son las mejores.

332
00:12:39,942 --> 00:12:42,242
El equipo podría haberse perdido en técnicas mucho

333
00:12:42,242 --> 00:12:44,702
más complejas, de moda, pero en lugar de

334
00:12:44,702 --> 00:12:46,102
eso dieron un paso atrás.

335
00:12:46,802 --> 00:12:49,402
¿Se centraron en diagnosticar el problema real en

336
00:12:49,402 --> 00:12:51,762
lugar de aplicar la última tecnología sin más?

337
00:12:52,122 --> 00:12:52,542
Eso es.

338
00:12:52,542 --> 00:12:55,542
Y esto plantea una pregunta fundamental.

339
00:12:55,542 --> 00:12:57,642
¿Cuál es la naturaleza de mi problema de

340
00:12:57,642 --> 00:12:58,062
búsqueda?

341
00:12:58,782 --> 00:13:02,502
¿Se necesita encontrar cosas relacionadas o se necesita

342
00:13:02,502 --> 00:13:04,882
encontrar exactamente esto?

343
00:13:05,402 --> 00:13:06,822
Este equipo se dio cuenta de que su

344
00:13:06,822 --> 00:13:09,842
problema no era de similitud semántica, sino de

345
00:13:09,842 --> 00:13:12,002
búsqueda por facetas, de filtrado.

346
00:13:12,542 --> 00:13:15,362
Y una vez tienes ese diagnóstico, la solución

347
00:13:15,362 --> 00:13:16,362
se vuelve evidente.

348
00:13:16,562 --> 00:13:17,602
Exacto.

349
00:13:16,622 --> 00:13:20,742
Y refuerza esa idea tan potente que mencionabas,

350
00:13:20,742 --> 00:13:23,082
la de usar la generación para aumentar la

351
00:13:23,082 --> 00:13:23,602
recuperación.

352
00:13:24,002 --> 00:13:26,122
Sí, para mí ese es el otro gran

353
00:13:26,122 --> 00:13:26,802
aprendizaje.

354
00:13:27,282 --> 00:13:29,542
Nos obliga a pensar en los LLMs no

355
00:13:29,542 --> 00:13:31,602
sólo como el motor que genera la respuesta

356
00:13:31,602 --> 00:13:35,182
final, sino como una herramienta súper versátil en

357
00:13:35,182 --> 00:13:36,522
todo el proceso.

358
00:13:36,742 --> 00:13:39,642
Son como una navaja suiza para manipular datos.

359
00:13:39,762 --> 00:13:42,582
Pueden extraer, estructurar, limpiar.

360
00:13:42,662 --> 00:13:45,282
Podemos usarlos para construir una base de conocimiento

361
00:13:45,282 --> 00:13:47,322
mucho más sólida y fiable.

362
00:13:47,402 --> 00:13:49,482
El cimiento de todo el sistema RAG.

363
00:13:49,722 --> 00:13:50,642
Justo.

364
00:13:50,322 --> 00:13:53,282
Sin duda, un caso de estudio fantástico.

365
00:13:53,242 --> 00:13:55,142
Un recordatorio de que la buena ingeniería y

366
00:13:55,142 --> 00:13:57,862
un diagnóstico preciso a menudo superan a la

367
00:13:57,862 --> 00:14:00,542
aplicación ciega de la tecnología más novedosa.

368
00:14:00,662 --> 00:14:02,002
Totalmente.

369
00:14:02,002 --> 00:14:03,701
Y creo que nos deja con una reflexión

370
00:14:03,701 --> 00:14:05,201
final muy valiosa.

371
00:14:05,362 --> 00:14:07,922
En un mundo obsesionado con la búsqueda semántica

372
00:14:07,922 --> 00:14:10,302
y los vectores, este caso nos obliga a

373
00:14:10,302 --> 00:14:12,982
preguntarnos si a veces no estamos intentando clavar

374
00:14:12,982 --> 00:14:14,682
un tornillo con un martillo.

375
00:14:14,522 --> 00:14:15,342
¡Qué buena imagen!

376
00:14:15,382 --> 00:14:18,862
Un enfoque estructurado, basado en filtros, que viene

377
00:14:18,862 --> 00:14:20,802
de los principios de las bases de datos

378
00:14:20,802 --> 00:14:23,062
de toda la vida, puede ser, para ciertos

379
00:14:23,062 --> 00:14:25,262
problemas, inmensamente superior.

380
00:14:25,262 --> 00:14:27,462
La clave está en no dar por sentado

381
00:14:27,462 --> 00:14:30,142
el método, sino en cuestionar si nuestro problema

382
00:14:30,142 --> 00:14:33,282
es encontrar cosas parecidas o, como en este

383
00:14:33,282 --> 00:14:36,502
caso, encontrar exactamente esto.

384
00:14:36,362 --> 00:14:37,962
Y así hemos llegado al final de nuestro

385
00:14:37,962 --> 00:14:39,422
episodio de hoy.

386
00:14:39,422 --> 00:14:41,602
Os recordamos que detrás de las voces sintéticas

387
00:14:41,602 --> 00:14:43,982
que escuchas en estos episodios y que están

388
00:14:43,982 --> 00:14:46,842
generadas con Notebook LM, hay un humano que

389
00:14:46,842 --> 00:14:49,242
no es otro que Julio Pablo Vázquez, el

390
00:14:49,242 --> 00:14:50,842
que dirige el podcast.

391
00:14:50,842 --> 00:14:54,022
En caso de error, sin duda será humano.

392
00:14:54,022 --> 00:14:55,922
Hasta el próximo episodio.

393
00:15:07,562 --> 00:15:09,722
Y hasta aquí el episodio de hoy.

394
00:15:09,722 --> 00:15:11,322
Muchas gracias por tu atención.

395
00:15:21,062 --> 00:15:23,322
Esto es BIMPRAXIS.

396
00:15:23,322 --> 00:15:25,422
Nos escuchamos en el próximo episodio.

397
00:15:46,701 --> 00:15:46,762
¡Suscríbete al canal!