Si venís construyendo algo con RAG —esa arquitectura de «buscá los documentos relevantes y pasáselos al modelo»— seguro te pasó: en el demo anda hermoso, y en producción, con documentos reales, empieza a fallar de formas raras. Vengo metido en esto hace rato (entre otras cosas, armando búsqueda semántica para un proyecto propio), y quiero ordenar algo que conviene tener clarísimo: los embeddings no son magia, y fallan de maneras predecibles.
Qué hace realmente un embedding
La promesa de la búsqueda vectorial es tentadora: convertís cada texto en un vector y encontrás lo «parecido» por cercanía. Y para sinónimos, parafraseos o errores de tipeo, funciona genial. El tema es entender qué mide en realidad: cercanía de tema, no la relación pregunta-respuesta. Como leí en un análisis de Angela Shi que me pareció clarísimo, «un embedding ve texto y lo rankea por similitud de términos; no representa la relación pregunta-a-respuesta para nada». Esa diferencia, que parece chiquita, es la que explica casi todos los fracasos.
Los modos de falla que vas a encontrar sí o sí
No son bugs ni mala suerte: son límites de fondo. Estos son los que más duelen en una base de documentos real de una empresa:
- Vocabulario que el modelo nunca vio: códigos internos de producto, citas regulatorias, jerga de tu industria. Como nunca los vio, «pool» lo entiende como pileta y no como un instrumento financiero.
- Negaciones: preguntá «¿qué NO es una ciudad?» y el embedding te rankea ciudades primero. Mide cercanía de tema; el «no» directamente no lo procesa.
- Valores y magnitudes exactas: buscás «valor mayor a 1M» y matchea el token «1M» en vez de «3B», que es la respuesta numéricamente correcta.
- Identificadores y siglas: números de contrato, nombres internos, siglas de la empresa. Ranking de azar, porque el modelo no tiene de dónde agarrarse.
- Se diluye la señal: si embebés una página entera, la respuesta queda promediada con 16 oraciones de ruido alrededor y se hunde por debajo de candidatos puestos al azar.
Lo peligroso de todo esto es que falla en silencio: no te tira un error, te devuelve una respuesta que suena bien pero está mal. Y eso, en un sistema que la gente usa para decidir, es lo peor que te puede pasar.
La salida no es «mejor modelo»
Acá está el error más común: cuando RAG falla, lo primero que se te ocurre es cambiar a un modelo de embeddings más nuevo. Pero ninguno de estos problemas se arregla cambiando el modelo, porque son límites de fondo. La solución es de arquitectura, y está antes del embedding:
- Búsqueda híbrida (léxica + semántica): el keyword match resuelve rápido y sin sorpresas los identificadores exactos; el embedding aporta los sinónimos del dominio.
- Cortá más fino: embeber a nivel de línea o sección, no de página entera, para no diluir la señal.
- Parseá la consulta: sacá las negaciones, los operadores numéricos y las exclusiones, y convertilas en filtros que se aplican después de buscar, no metidos adentro del vector.
- Diccionarios de keywords armados por gente que conoce el dominio, que vas descubriendo con la ayuda del propio embedding.
Entender los límites es parte del oficio
Lo que más me convence de este enfoque es que no es anti-IA: es IA bien puesta. Usar los embeddings para lo que son buenos y no pedirles lo que no pueden dar. Esa madurez —saber dónde brilla la herramienta y dónde te traiciona— es, para mí, la diferencia entre un prototipo que impresiona y un sistema que aguanta producción.
Y es justamente este tipo de criterio el que tratamos de bajar a tierra en el AI-First Builders Lab del MUG: no quedarse en el «mirá qué lindo el demo», sino aprender a construir cosas con IA que funcionen de verdad cuando los datos son reales y desprolijos. Que, al final, es donde se juega todo.
