En el post anterior vimos cómo los tokens y el contexto afectan costos y calidad. Hoy vamos con la pieza que permite encontrar lo relevante sin depender de coincidencias literales: los embeddings.

¿Qué es un embedding?

Es una representación numérica (un vector) de un texto, imagen o audio, donde la distancia entre vectores refleja su similitud semántica. Si dos frases “significan” cosas parecidas, sus vectores quedan cerca en el espacio.

Intuición rápida: del texto al espacio vectorial

• Entrada: “Soporte técnico por correo” → [0.12, -0.08, 0.44, ...]
• Comparación: calculas similitud (normalmente cosine) contra otros vectores.
• Resultado: obtienes los Top-K más cercanos para responder, clasificar o recomendar.

Regla práctica: usa cosine similarity y asegura normalización consistente entre consulta y documentos.

Usos prácticos que dan valor

• Búsqueda semántica: encuentra documentos aunque no compartan las mismas palabras.
• RAG: recupera fragmentos relevantes para inyectarlos al LLM con citas.
• Deduplicación y near-duplicates: detecta contenidos casi iguales.
• Clasificación y etiquetado: asigna categorías por cercanía a “centroides”.
• Clustering y exploración: agrupa por temas para navegar grandes corpus.
• Recomendaciones: “los usuarios que leyeron esto, también…”.

Decisiones de diseño importantes

• Dimensionalidad: más dimensiones ≠ siempre mejor; equilibra calidad y costo de almacenamiento/búsqueda.
• Idioma y dominio: si tu contenido es bilingüe o técnico, valida el modelo en tu golden set.
• Granularidad: embebe a nivel de párrafo o chunk (300–800 palabras) en lugar de documentos completos.
• Indexación: usa índice aproximado (HNSW/IVF) para escalar recuperaciones rápidas.
• Metadatos: guarda title, url, tags, fecha para filtrar antes de calcular similitud.

Pipeline mínimo (de texto a vector DB)

1. Ingesta: recoge PDFs/HTML/MD desde tu repositorio.
2. Limpieza: quita menús/boilerplate, normaliza espacios y codificación.
3. Chunking: divide en fragmentos con overlap pequeño (p. ej., 50–100 tokens).
4. Embedding: convierte cada fragmento en vector.
5. Upsert: guarda vector + texto + metadatos en la base vectorial.
6. Validación: prueba queries reales y mide recall@k.

Tip Laravel: programa un command para ingesta/embedding nocturno y guarda el estado por lote.

Micro-workflow n8n: “ETL semántico básico”

1. Cron → ejecuta cada noche.
2. HTTP Request → descarga fuentes (S3/Drive/API).
3. Function → limpia HTML y hace chunking.
4. HTTP Request → llama al servicio de embeddings.
5. Database → upsert (vector, texto, metadatos, hash de contenido).
6. IF → si error o costo elevado, notifica por Email/Slack.

¿Cómo sé si funciona? (métricas)

• Recall@K: porcentaje de veces que el fragmento correcto aparece en el Top-K.
• MRR / nDCG: calidad del ranking, no solo presencia.
• Tiempo de respuesta: latencia de recuperación.

Errores comunes

• Embebes documentos enteros y el RAG recupera ruido.
• No almacenas metadatos ni filtros previos a la similitud.
• Dimensiones sobredimensionadas y costos innecesarios.
• Sin golden set: optimizas a ciegas.

Conclusión

Los embeddings son el puente entre tus datos y la inteligencia del modelo. Al dominarlos, tus sistemas encuentran mejor, citan mejor y cuestan menos.

← Anterior: Tokens, contexto y costos: lo que debes saber antes de empezar

Siguiente: Bases de datos vectoriales explicadas fácil (y cuándo no las necesitas) →