Buenas, esto es BIMPRAXIS, el podcast donde el
Download transcript (.srt)
0:10
0:15
0:20
0:23
0:26
0:28
0:37
0:38
0:40
0:42
0:45
0:48
0:49
0:53
0:54
0:57
0:59
1:01
1:05
1:08
1:10
1:12
1:14
1:16
1:16
1:19
1:20
1:24
1:26
1:28
1:29
1:32
1:34
1:36
1:40
1:42
1:44
1:45
1:47
1:49
1:52
1:53
1:55
1:58
2:00
2:03
2:04
2:06
2:08
2:10
2:12
2:14
2:16
2:17
2:19
2:20
2:21
2:24
2:28
2:31
2:35
2:37
2:39
2:42
2:42
2:43
2:45
2:46
2:50
2:53
2:57
3:02
3:04
3:06
3:09
3:12
3:14
3:18
3:21
3:23
3:28
3:31
3:34
3:36
3:39
3:41
3:42
3:45
3:47
3:49
3:50
3:53
3:55
3:57
3:59
4:01
4:02
4:04
4:07
4:08
4:11
4:13
4:18
4:17
4:21
4:25
4:27
4:31
4:33
4:36
4:39
4:43
4:44
4:45
4:48
4:52
4:54
4:56
5:00
5:00
5:05
5:06
5:08
5:12
5:15
5:17
5:21
5:22
5:23
5:26
5:27
5:29
5:31
5:33
5:36
5:38
5:39
5:41
5:43
5:45
5:47
5:49
5:52
5:53
5:54
5:57
5:58
5:58
6:02
6:06
6:07
6:09
6:11
6:14
6:15
6:16
6:19
6:21
6:25
6:28
6:30
6:32
6:34
6:34
6:37
6:39
6:42
6:43
6:45
6:46
6:49
6:52
6:56
6:57
6:58
6:59
7:01
7:04
7:06
7:08
7:09
7:11
7:14
7:16
7:19
7:21
7:23
7:26
7:29
7:30
7:32
7:35
7:37
7:41
7:43
7:43
7:46
7:47
7:50
7:52
7:55
7:56
8:00
8:04
8:06
8:08
8:10
8:12
8:13
8:16
8:19
8:21
8:22
8:24
8:27
8:28
8:31
8:33
8:35
8:37
8:40
8:42
8:43
8:46
8:48
8:50
8:53
8:56
8:58
9:01
9:02
9:05
9:08
9:10
9:12
9:14
9:16
9:18
9:19
9:20
9:23
9:25
9:28
9:30
9:31
9:34
9:35
9:36
9:38
9:40
9:43
9:45
9:47
9:50
9:53
9:55
9:57
9:59
10:03
10:04
10:06
10:09
10:11
10:13
10:16
10:19
10:21
10:23
10:25
10:27
10:30
10:31
10:32
10:35
10:37
10:39
10:42
10:43
10:46
10:49
10:51
10:54
10:56
10:58
11:00
11:01
11:01
11:04
11:07
11:09
11:11
11:13
11:15
11:17
11:19
11:20
11:23
11:26
11:28
11:31
11:33
11:34
11:36
11:37
11:39
11:41
11:43
11:46
11:48
11:52
11:52
11:54
11:56
11:58
11:59
12:01
12:04
12:07
12:09
12:10
12:12
12:15
12:19
12:21
12:23
12:27
12:29
12:31
12:32
12:35
12:37
12:39
12:42
12:44
12:46
12:49
12:52
12:52
12:55
12:57
12:58
13:02
13:05
13:06
13:09
13:12
13:15
13:16
13:16
13:20
13:23
13:24
13:26
13:27
13:29
13:31
13:35
13:36
13:39
13:42
13:45
13:47
13:49
13:50
13:53
13:55
13:57
14:00
14:02
14:03
14:05
14:07
14:10
14:12
14:14
14:15
14:18
14:20
14:23
14:25
14:27
14:30
14:33
14:36
14:37
14:39
14:41
14:43
14:46
14:49
14:50
14:54
15:07
15:09
15:21
15:23
15:46
BIM se encuentra con la inteligencia artificial.
Exploramos la ciencia, la tecnología y el futuro
desde el enfoque de la arquitectura, ingeniería y
construcción.
¡Empezamos!
Muy buenas.
Episodio 51.
Continuamos con la serie dedicada a los RAG,
Retrieval Augmented Generation.
Hoy hablaremos de cómo mejorar la calidad de
la recuperación.
Bienvenidos al podcast de BIMPRAXIS.
La idea central de estos sistemas, ya lo
sabemos, es conectar un modelo de lenguaje a
una base de conocimiento para que dé respuestas
más precisas.
Pero, ¿qué pasa cuando esa conexión falla?
Pues ese es precisamente el punto crítico.
Es que la calidad de todo el sistema
depende casi por completo de la calidad de
la recuperación.
De encontrar los documentos correctos.
Exacto.
De encontrar los documentos correctos para darle contexto
al modelo.
Si los documentos que recuperas son, pues, irrelevantes
o incorrectos, da igual lo bueno que sea
tu modelo o el prompt final.
La respuesta va a ser mala.
Va a ser mediocre o directamente errónea.
Y el material que analizamos hoy, que viene
de un proyecto real documentado por Johannes Jolkonen
en su canal Functio AI, aborda justo esto.
Se enfrentaron a un sistema que, bueno, apenas
acertaba la mitad de las veces.
Que ya es decir.
Y lo transformaron en uno con una precisión
de más del 95%.
Así que hoy vamos a desgranar cómo lograron
esa mejora tan espectacular.
Es un caso de manual, de verdad.
Sobre cómo un diagnóstico inteligente del problema te
puede llevar a una solución mucho más eficaz
que, bueno, que simplemente aplicar la tecnología más
popular del momento.
Pues vamos a ello.
Para entender la genialidad de la solución, creo
que lo mejor es empezar por el principio.
¿Cuál era el sistema que tenían montado y
por qué fallaba de esa forma?
A ver, el punto de partida era un
proyecto bastante común.
Un chatbot interno para una empresa del sector
del bienestar.
Spine Wellness.
El objetivo era que los empleados de atención
al cliente pudieran consultar rápido información sobre servicios,
ubicaciones, especialistas.
Cientos de empleados necesitaban respuestas al instante.
Una herramienta de productividad, vaya.
Y por lo que dicen, la arquitectura que
montaron era la estándar para un sistema a
RAG.
Totalmente estándar.
Siguieron el libro de jugadas al pie de
la letra.
Primero, recopilaron datos de sus sistemas, descripciones de
spas, gimnasios, perfiles de masajistas.
Luego, limpiaron y trocearon esa información en chunks.
Tercero, crearon los embeddings, estas representaciones numéricas que
capturan el significado.
Y finalmente, lo cargaron todo en una base
de datos vectorial, en su caso, Azure AI
Search, para las búsquedas semánticas.
Y para simplificar, unieron todos los campos de
texto, como la descripción, la ciudad, las especialidades,
todo en un único campo gigante llamado content.
Sí, sobre el que se hacía la búsqueda.
Suena lógico, pero claro, los problemas aparecieron enseguida.
Cuando un usuario preguntaba algo tan simple como
masaje sueco en Helsinki, la tasa de acierto
era de un 50-60%.
Para una herramienta profesional, eso es un fracaso.
Es inaceptable.
Y aquí es donde la historia se pone
de verdad interesante, porque su primer instinto fue
intentar mejorar la búsqueda probando los dos enfoques
más populares.
Y ambos fallaron.
Y ambos fallaron, pero por razones completamente opuestas.
Empecemos por el primero, la búsqueda vectorial.
Es como la técnica estrella en el mundo
RAG, la que usa los embeddings para encontrar
cosas por similitud.
¿Por qué no les funcionó?
La fuente lo describe como un fracaso total
para este caso de uso concreto.
Y la razón es...
es útil pero fundamental.
La búsqueda vectorial es brillante para la similitud
semántica, para lo que podríamos llamar coincidencia difusa.
Vale.
Si buscas coche deportivo rojo, te puede devolver
documentos que hablen de un automóvil rápido escarlata,
porque entiende que son conceptos relacionados.
O sea que el sistema era demasiado creativo,
por así decirlo.
Entendía que Helsinki y Estocolmo eran parecidas por
ser capitales nórdicas, pero para el usuario que
busca algo en una ciudad concreta, esa inteligencia
es un error.
Exactamente.
Devolvía otros tipos de masajes porque eran semánticamente
parecidos, o servicios en otras ciudades porque eran
semánticamente parecidas a Helsinki.
El problema es que el usuario no quería
algo parecido, quería exactamente un masaje sueco en
Helsinki.
Necesitaban una coincidencia exacta, no una aproximación.
Justo.
Vale, entiendo el problema.
La búsqueda semántica era demasiado imprecisa, Así que,
lógicamente, probaron el otro extremo, la búsqueda de
texto completo de toda la vida con el
algoritmo BM25, que se basa en palabras clave
exactas.
Eso es.
La fuente dice que fue un poco mejor,
pero no mucho.
¿Qué falló esta vez?
Aquí el problema era casi el contrario.
El sistema era demasiado literal y se dejaba
engañar por la frecuencia de las palabras.
El ejemplo que usan es brillante.
A ver.
Imagina que tienes dos ubicaciones.
La ubicación A, que es irrelevante, no ofrece
masaje sueco.
Pero en su descripción la palabra masaje aparece
seis veces porque ofrecen muchos otros tipos.
Tailandés, de tejido profundo.
Eso es.
Y para colmo, en el menú de su
cafetería sirven albóndigas suecas.
No puede ser.
Ya veo por dónde vas.
Pues esa ubicación, que no sirve para nada,
acumula siete coincidencias con las palabras masaje y
sueco.
Ahora, compárala con la ubicación B, que es
el resultado perfecto.
Un centro en Helsinki que solo ofrece masaje
sueco.
Claro.
Su documento solo tiene tres coincidencias, masaje, sueco
y Helsinki.
El algoritmo BM25, como prima la frecuencia, colocaría
el resultado incorrecto por encima del correcto.
Es un fallo de diseño del método para
este tipo de consulta.
El sistema no entiende el contexto, solo cuenta
palabras.
Y por si fuera poco, había un segundo
problema, muy grave porque el proyecto era en
finés, pero que afecta a muchísimos idiomas, español
incluido.
Las declinaciones y conjugaciones.
Ah, claro.
Si el usuario busca en Helsinki, con una
terminación gramatical, pero en el documento la palabra
Helsinki aparece de otra forma, BM25 simplemente no
lo encuentra.
No es tan listo.
Vale.
El panorama es desolador.
Ni la búsqueda semántica inteligente ni la búsqueda
literal por palabras clave funcionaban.
Estaban en un callejón sin salida.
Exacto.
Se dieron cuenta de que el problema no
era qué algoritmo de búsqueda usar, sino la
naturaleza de sus datos.
Y la solución que encontraron fue sorprendentemente simple
y elegante.
Implicó dos cambios, uno en cómo preparaban los
datos en el back-end y otro en cómo
interpretaban la pregunta del usuario en el front-end.
Empecemos por el back-end.
¿Cuál fue ese cambio en la indexación?
El cambio fue conceptualmente muy potente.
En lugar de tener toda la información en
un campo de texto desestructurado, decidieron añadir metadatos
estructurados.
¿Cómo?
Pues en concreto, añadieron un nuevo campo llamado
servicios.
En la práctica, esto significa que la frase
masaje sueco, que antes estaba perdida en un
párrafo, ahora se convertía en una etiqueta dentro
de una lista.
Algo como servicios, masaje sueco, reflexología.
Un momento, eso suena genial, pero ¿de dónde
sacaron esos datos estructurados?
Si el problema era que todo estaba en
texto, parece un círculo vicioso.
No me digas que tuvieron que etiquetar miles
de documentos a mano.
Ahí está la genialidad de la solución.
Utilizaron un modelo de lenguaje, un LLM, durante
el propio proceso de indexación.
¿Cómo?
Para cada documento que entraba al sistema, pasaban
el texto descriptivo por un LLM, con una
instrucción muy directa.
Extrae de este texto una lista estructurada de
los servicios que se ofrecen y devuélvemela en
formato JSON.
O sea, que usaron la generación de un
LLM para mejorar la recuperación.
Invirtieron el acrónimo RAG.
Justo eso.
Es una idea que la fuente llama Generation
Augmented Retrieval.
En lugar de usar el LLM solo al
final para responder, lo usaron al principio, para
enriquecer y estructurar su base de conocimiento.
Es como tener un ejército de documentalistas súper
rápidos etiquetando tu archivo.
Fascinante.
Y, por cierto, como consecuencia de esto, eliminaron
por completo los embeddings y la búsqueda vectorial.
Concluyeron que para este problema no solo no
ayudaban, sino que metían ruido.
Pasaron de buscar en un pajar a tener
un archivador perfectamente etiquetado.
Ese fue el cambio en el Maken.
¿Y la segunda pieza del puzzle, la del
frontend?
La segunda pieza fue cambiar cómo trataban la
pregunta del usuario.
Antes, la frase masaje sueco en Helsinki se
lanzaba directamente contra el motor de búsqueda.
Ahora no.
Ahora esa frase se pasa primero por otro
LLM.
¿Con qué objetivo?
¿Para que la reescriba o la mejore?
Ah, para algo mucho más preciso.
La única misión de este segundo LLM es
actuar como un traductor.
Convierte la pregunta en lenguaje natural del usuario
en una consulta estructurada, formal, que la base
de datos pueda entender sin ninguna ambigüedad.
Ah, ya veo.
Coge masaje sueco en Helsinki y lo transforma
en una consulta de filtro estricta, como por
ejemplo, ciudad igual a Helsinki, y servicios contiene
masaje sueco.
Brillante.
Es decir, eliminaron por completo la ambigüedad.
Ya no se busca algo que se parezca
a esto, sino que se le ordena a
la base de datos devuélveme solo los documentos
que cumplan estas dos condiciones exactas.
Es un cambio de paradigma total.
Y el impacto fue, como era de esperar,
inmediato, masivo.
En la siguiente ronda de pruebas, la tasa
de acierto se disparó a casi el 100%.
Increíble.
El feedback fue unánime.
Los problemas de relevancia habían desaparecido.
Los únicos fallos que quedaban eran casos muy
puntuales, casi siempre por errores en los datos
de origen, no en el sistema.
Problema resuelto.
Un resultado espectacular, desde luego.
Pero esto suena demasiado bueno para ser verdad.
Seguro que este enfoque tiene sus inconvenientes.
¿Qué contrapartidas tuvieron que asumir?
La fuente es muy transparente en eso e
identificados trade-offs claros.
El primero, como te puedes imaginar, es el
coste.
Claro.
Usar un LLM para procesar y estructurar cada
documento durante la indexación es más caro que
simplemente generar un embedding.
Cada documento que añades implica una llamada a
una API y eso cuesta dinero.
Un coste inicial y luego recurrente cada vez
que se actualizan los datos.
¿Cómo justificaron esa inversión?
Lo pusieron en perspectiva.
estaban construyendo una herramienta para ahorrar miles de
horas a cientos de empleados.
El coste adicional de las llamadas a la
API era ínfimo en comparación con el valor
de negocio que aportaba tener una herramienta que
funcionaba de verdad.
El retorno de la inversión era obvio.
No fue ni un debate.
Tiene todo el sentido, sí.
¿Y la segunda contrapartida?
La segunda es la latencia.
La latencia en la respuesta al usuario.
Al añadir ese paso intermedio, en el que
un LLM traduce la pregunta, introduces un pequeño
retraso.
Y en una herramienta de uso intensivo, cada
milisegundo cuenta.
¿Cómo lo solucionaron?
Con pragmatismo.
Se dieron cuenta de que la tarea de
traducir la consulta es muy simple y definida.
Las entradas son cortas y las salidas también.
No necesitas un modelo gigante y lento para
eso.
Optaron por un modelo mucho más pequeño, rápido
y barato, optimizado para esa tarea.
El retraso añadido fue mínimo, apenas perceptible, y
el beneficio en la precisión lo compensaba con
creces.
Entonces, si destilamos la experiencia de este proyecto,
¿qué significa todo esto para alguien que esté
construyendo un sistema similar?
¿Cuál es la gran lección?
La lección más importante, que la propia fuente
subraya, es que a veces las soluciones más
directas e intuitivas son las mejores.
El equipo podría haberse perdido en técnicas mucho
más complejas, de moda, pero en lugar de
eso dieron un paso atrás.
¿Se centraron en diagnosticar el problema real en
lugar de aplicar la última tecnología sin más?
Eso es.
Y esto plantea una pregunta fundamental.
¿Cuál es la naturaleza de mi problema de
búsqueda?
¿Se necesita encontrar cosas relacionadas o se necesita
encontrar exactamente esto?
Este equipo se dio cuenta de que su
problema no era de similitud semántica, sino de
búsqueda por facetas, de filtrado.
Y una vez tienes ese diagnóstico, la solución
se vuelve evidente.
Exacto.
Y refuerza esa idea tan potente que mencionabas,
la de usar la generación para aumentar la
recuperación.
Sí, para mí ese es el otro gran
aprendizaje.
Nos obliga a pensar en los LLMs no
sólo como el motor que genera la respuesta
final, sino como una herramienta súper versátil en
todo el proceso.
Son como una navaja suiza para manipular datos.
Pueden extraer, estructurar, limpiar.
Podemos usarlos para construir una base de conocimiento
mucho más sólida y fiable.
El cimiento de todo el sistema RAG.
Justo.
Sin duda, un caso de estudio fantástico.
Un recordatorio de que la buena ingeniería y
un diagnóstico preciso a menudo superan a la
aplicación ciega de la tecnología más novedosa.
Totalmente.
Y creo que nos deja con una reflexión
final muy valiosa.
En un mundo obsesionado con la búsqueda semántica
y los vectores, este caso nos obliga a
preguntarnos si a veces no estamos intentando clavar
un tornillo con un martillo.
¡Qué buena imagen!
Un enfoque estructurado, basado en filtros, que viene
de los principios de las bases de datos
de toda la vida, puede ser, para ciertos
problemas, inmensamente superior.
La clave está en no dar por sentado
el método, sino en cuestionar si nuestro problema
es encontrar cosas parecidas o, como en este
caso, encontrar exactamente esto.
Y así hemos llegado al final de nuestro
episodio de hoy.
Os recordamos que detrás de las voces sintéticas
que escuchas en estos episodios y que están
generadas con Notebook LM, hay un humano que
no es otro que Julio Pablo Vázquez, el
que dirige el podcast.
En caso de error, sin duda será humano.
Hasta el próximo episodio.
Y hasta aquí el episodio de hoy.
Muchas gracias por tu atención.
Esto es BIMPRAXIS.
Nos escuchamos en el próximo episodio.
¡Suscríbete al canal!