Buenas, esto es BIMPRAXIS, el podcast donde el
BIM se encuentra con la inteligencia artificial.
Exploramos la ciencia, la tecnología y el futuro
desde el enfoque de la arquitectura, ingeniería y
construcción.
¡Empezamos!
Hola de nuevo a un episodio más de
BIMPRAXIS.
Hoy llegamos al número 50.
50 ya, felicidades.
Gracias.
Y para celebrar este número tan redondo, vamos
a comenzar una nueva serie dedicada a una
tecnología que está, bueno, en boca de todos.
El RAG, Retrieval Augmented Generation.
Exacto.
Hoy vamos a ver qué es eso de
los RAG.
Porque, a ver, a menudo oímos que los
grandes modelos de lenguaje, los LLMs, a veces
se inventan cosas, ¿no?
O dan información que ya está anticuada.
Totalmente.
¿Y si hubiera una forma de darles, no
sé, como una biblioteca personalizada y que estuviera
siempre al día?
Pues es que has dado justo en el
clavo.
Ese es uno de los mayores desafíos de
los LLMs ahora mismo.
Claro.
Y RAG es precisamente la solución a ese
problema.
Es una arquitectura que permite que un modelo,
antes de responder, pueda consultar fuentes de información
muy específicas y, sobre todo, actualizadas.
Bien, pues vamos a desgranar esto.
La analogía de la biblioteca me parece muy,
muy potente.
Sí, funciona muy bien.
O sea, es como tener un asistente virtual
al que, en lugar de confiar solo en
lo que aprendió durante su entrenamiento hace meses
o años, que se queda viejo enseguida.
le damos acceso a una biblioteca en tiempo
real.
Eso es.
El proceso, a grandes rasgos, es bastante elegante
y se puede dividir como en tres pasos.
A ver.
Primero, la búsqueda.
El sistema recibe la pregunta y, en lugar
de lanzarse a responder, lo que hace es
usar esa pregunta para buscar en una base
de datos de conocimiento que hemos creado nosotros.
Una base de datos con nuestros propios documentos,
¿no?
PDFs, manuales, lo que sea.
Justo, lo que necesitemos.
Una vez que ha buscado, llega el segundo
paso, la recuperación.
De todo lo que encuentra, el sistema elige
sólo los fragmentos de información más relevantes, los
trocitos de texto que de verdad parecen contener
la respuesta.
Ok, busca, recupera lo importante y… El tercer
paso, la generación.
Y aquí es donde está la magia.
El modelo de lenguaje, el LLM, recibe dos
cosas, la pregunta original y, además, esos fragmentos
que hemos recuperado.
Ah, como contexto adicional.
Exacto.
Es como si le dijéramos, oye, responde a
esto, pero por favor, basándote en esta información
que te estoy dando ahora mismo.
Aquí es donde se pone realmente interesante para
mí.
Quiero entender bien ese viaje de los datos.
O sea, ¿cómo se construye esa biblioteca?
Claro.
Porque hablamos de PDFs, documentos de Notion, Excel.
¿Cómo transformamos, por ejemplo, un manual de 500
páginas en algo que una máquina pueda consultar
así de rápido?
Esa es la pregunta del millón, porque ahí
está el núcleo de un buen sistema RAG.
Hay dos fases muy claras.
La primera es la preparación de los datos.
Que se hace solo una vez, imagino.
Eso es, al principio.
Y lo primero dentro de esa preparación es
lo que llamamos chunking o fragmentación.
Trocear los documentos.
Exacto.
No le puedes dar al modelo las 500
páginas de golpe.
Sería un caos.
Así que lo divides en chunks, en fragmentos
más pequeños, más manejables.
¿Y hay un tamaño ideal para esos trozos?
¿Una frase?
¿Un párrafo?
Uf, no hay una fórmula mágica.
Ahí empieza un poco el arte de esto,
¿sabes?
Depende totalmente del caso de uso.
Un chunk muy pequeño puede no tener contexto.
Y uno muy grande puede tener demasiado ruido,
información que no viene al caso.
Justo.
El siguiente paso es clave, porque los modelos,
como bien decías, no entienden texto, entienden números.
Claro.
Así que hay que traducir.
Y eso se llama crear embeddings, o vectorizar.
Cada uno de esos chunks de texto se
convierte en una representación numérica, en un vector.
Como una coordenada en un mapa de significados,
¿no?
Me gusta esa analogía.
Es exactamente eso.
Cada trozo de texto tiene su propia coordenada.
Y estas coordenadas se guardan en una base
de datos especial, una base de datos vectorial.
Vale, que está pensada para buscar por similitud,
no por palabras exactas.
Eso es.
Hay soluciones muy complejas, pero muchas veces basta
con una base de datos postgres de toda
la vida con una extensión como PG Vector.
Entendido.
Entonces, esa es la fase de preparación.
La biblioteca está lista.
Ahora llega una pregunta de un usuario.
¿Qué pasa?
Pues se repite el proceso, pero a la
inversa.
La pregunta del usuario también se convierte en
un vector, en una coordenada en ese mismo
mapa.
Usando el mismo modelo de traducción, supongo.
El mismo, sí.
Y con esa coordenada, el sistema va a
la base de datos vectorial y le dice,
encuéntrame los 5 o 10 fragmentos que estén
más cerca de este punto.
Y esos fragmentos son los que se le
dan al ELM junto a la pregunta original.
Exacto.
Ese es el contexto.
Así es como aumentamos su conocimiento para que
dé una respuesta precisa y, sobre todo, basada
en nuestros datos.
Vale.
El proceso técnico queda claro.
Pero, vamos a la práctica.
¿Qué significa todo esto para una empresa?
Pues significa un cambio radical.
Piensa en un chatbot de servicio al cliente.
¿El que recomendaba productos de la competencia?
Ese mismo.
Con RAH, ese chatbot podría consultar en tiempo
real los manuales de producto y guiar a
una persona paso a paso para solucionar un
problema.
¿Citando la página exacta del manual?
Por ejemplo.
O un asistente para un equipo de médicos
que esté al día con las últimas investigaciones
publicadas la semana pasada, no hace dos años.
Un tutor virtual que pueda citar fuentes académicas
actualizadas para un estudiante.
Las aplicaciones son enormes.
Lo son.
Y las ventajas son muy claras.
Primero, la información está siempre actualizada.
Segundo, las respuestas son mucho más fiables.
Se reducen las alucinaciones a casi cero.
Y tercero, que para mí es crucial, son
respuestas verificables.
Se puede saber de dónde ha salido la
información.
Eso da una confianza brutal.
Y luego está el coste.
Reentrenar un modelo entero, lo que se conoce
como fine tuning, es lentísimo y carísimo.
Mientras que actualizar una base de datos es
mucho más ágil y barato.
Muchísimo más.
Ahora, bueno, tampoco es una solución mágica, tiene
sus desafíos.
Claro, no todo va a ser perfecto.
La implementación puede tener su complejidad técnica.
Y esa base de datos hay que mantenerla,
hay que actualizarla.
Y luego está la latencia.
El tiempo de respuesta, ¿no?
Porque hay más pasos.
Exacto.
Puede tardar un poquito más.
Y el coste por consulta.
Al pasarle más texto al modelo, puede ser
un poco más alto.
Hay que buscar un equilibrio.
Entendido.
O sea, el RAG básico es un punto
de partida genial.
Pero la conversación de verdad está en cómo
optimizarlo, ¿no?
Veo que a menudo se combinan varias estrategias.
Sí, aquí es donde entramos ya en la
parte avanzada.
Por ejemplo, una técnica muy común es el
re-ranking.
Reordenar, supongo.
Sí, es un enfoque de dos pasos.
En lugar de pedirle a la base de
datos los cinco mejores resultados, le pides, no
sé, 50.
Pero, espera, darle 50 fragmentos al LLM no
es contraproducente.
¿Lo puedes aturar?
Claro.
Por eso está el segundo paso.
Se usa un modelo mucho más pequeño y
especializado, un re-ranker, cuya única misión es coger
esos 50 fragmentos y reordenarlos por relevancia real.
Ah, vale.
Y solo después de ese filtro le pasas
al LLM grande los cinco mejores de verdad.
La calidad de la respuesta mejora una barbaridad.
Inteligente.
Primero una búsqueda amplia y luego un filtro
preciso.
Me gusta.
También he leído sobre la fragmentación consciente del
contexto.
Context-aware chunking.
Exacto.
Va de la mano con lo que decíamos
antes.
No vale con cortar un texto cada mil
caracteres y ya.
Hay que respetar la estructura.
Hay que buscar los límites naturales del documento.
El final de un párrafo, un título, el
pie de una tabla… Se trata de preservar
el sentido.
Es que la calidad de lo que metes
en la base de datos tiene un impacto
directo en la calidad de lo que sacas.
Basura entra, basura sale.
De toda la vida.
Así es.
Luego, hay otra estrategia muy potente.
El agentic RAG.
El ra-agéntico.
Esto ya suena a ciencia ficción.
Bueno, un poco.
Es darle al sistema la capacidad de razonar
sobre cómo tiene que buscar.
O sea, que no siga siempre los mismos
pasos.
Eso es.
El agente analiza la pregunta y decide.
Si es una pregunta muy concreta, como cuál
fue el beneficio en 2023, pues hace una
búsqueda muy específica.
Pero si es algo más abierto, como cuáles
son los riesgos estratégicos de la empresa.
Pues a lo mejor decide que es más
útil recuperar y leerse el informe anual completo,
para tener una visión global.
Es más flexible, pero también menos predecible.
Claro, hay que programarlo con mucho cuidado para
que tome buenas decisiones.
Desde luego.
Y ya por último, una que a mí
me parece fascinante, que es el fine tuning
de los embeddings.
O sea, afinar al traductor.
Exacto.
El modelo que convierte texto en vectores suele
ser genérico, pero podemos reentrenarlo con datos de
un dominio muy específico, legal, médico, financiero, para
que entienda la jerga y los matices de
ese campo.
Y lo que se consigue es que un
modelo de embeddings pequeño, pero muy especializado, supera
a modelos gigantescos y genéricos en esas tareas
concretas.
La comprensión del dominio es mucho más profunda.
Es increíble.
Esto me recuerda a un ejemplo que leí.
Entrenar un modelo no para que busque por
similitud de significado, sino por sentimiento.
Sí, es un caso de uso genial.
De forma que una frase como el pedido
llegó roto se considere muy similar a la
web siempre dice que no hay stock.
No porque usen las mismas palabras, sino porque
ambas expresan frustración.
Ese es el poder de la técnica.
Te permite redefinir qué significa similar para tu
problema.
La personalización es total.
Entonces, si lo unimos todo, queda claro que
el RAGE no es solo una mejora técnica,
¿no?
Es un paso hacia una inteligencia artificial, no
sé, más transparente, más fiable.
Totalmente.
Es que pasamos de una IA que es
como un sabelotodo que a veces patina… ¿Y
que no sabes de dónde saca las cosas?
A una IA que se comporta como una
investigadora experta, que consulta, contrasta y cita sus
fuentes.
Y para una empresa o un gobierno, eso
es infinitamente más valioso.
Por eso se está convirtiendo en la arquitectura
por defecto para resolver problemas del mundo real.
Y esto me lleva a una reflexión final,
una pregunta que me queda en el aire.
A ver, dispara.
Todas estas estrategias se centran en encontrar información
que es semánticamente similar a una pregunta.
Pero, ¿qué pasa cuando la respuesta más útil,
la más creativa, no está en un pasaje
que suena parecido, sino en un dato que
a primera vista no parece tener relación?
¿Cómo podrían los futuros sistemas aprender a dar
esos saltos, a conectar piezas de información dispares
dispares para resolver un problema como hace la
intuición de una persona experta.
Llegamos al final por hoy.
El podcast de BIMPRAXIS está dirigido por un
humano, Julio Pablo Vázquez.
Te esperamos en 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.
Música