MAISON CODE .
/ AI · LLM · RAG · Vectors

Optimización de LLM: RAG, búsqueda vectorial y Edge

Ejecutar un modelo de parámetros de 70 mil millones en una tienda es un suicidio. Cómo diseñar funciones de IA que sean rápidas, económicas y realmente útiles.

AB
Alex B.

En 2024, todos los directores ejecutivos de comercio electrónico preguntaron: “¿Cómo agregamos IA?” En 2025, todos los CTO responderán: “Lo ideal sería, sin ir a la quiebra”. Los modelos de lenguaje grande (LLM) son pesados, lentos y alucinan. Los clientes no quieren charlar con un robot que piensa que una tostadora es un microondas. Quieren Búsqueda semántica e Hiperpersonalización. Esto requiere una arquitectura específica: RAG (Generación aumentada de recuperación) en el borde.

Por qué Maison Code analiza esto

En Maison Code Paris, actuamos como la conciencia arquitectónica de nuestros clientes. A menudo heredamos pilas “modernas” que se construyeron sin una comprensión fundamental de la escala. Vemos API simples que tardan 4 segundos en responder debido a problemas de consultas N+1 y “microservicios” que cuestan €5000 al mes en tarifas de nube inactiva.

Discutimos este tema porque representa un punto crítico en la madurez de la ingeniería. Implementar esto correctamente diferencia un MVP frágil de una plataforma resistente de nivel empresarial que puede manejar el tráfico del Black Friday sin sudar.

El problema: latencia y costo

Ejemplo: un usuario pregunta: “¿Tiene algún vestido de verano que sea bueno para una boda en Italia?”

  • Enfoque ingenuo: envíe el catálogo de productos completo (CSV) a la ventana contextual GPT-4.

    • Costo: €2.00 por consulta (tokens de entrada).
    • Latencia: 15 segundos.
    • Resultado: El usuario se va antes de que se cargue la respuesta.

  • Enfoque de ingeniería: búsqueda vectorial + RAG.

    • Costo: €0.002 por consulta.
    • Latencia: 400ms.
    • Resultado: Conversión.

La arquitectura: el oleoducto RAG

No le pedimos al LLM que “conozca” nuestros productos. Le pedimos que “resuma” nuestros resultados de búsqueda.

diagrama de secuencia
    Usuario participante
    Borde del participante como función de borde (Vercel)
    Vector participante como Vector DB (Piña)
    participante LLM como GPT-4o-mini

    Usuario->>Edge: "Vestido rojo para boda en Italia"
    
    Nota sobre Edge: 1. Generar incrustaciones
    Edge->>LLM: Solicitud de incrustación (incrustación de texto-3-pequeño)
    LLM-->>Borde: [0,12, 0,98, -0,4...]
    
    Nota sobre Edge: 2. Búsqueda semántica
    Borde->>Vector: Consultar vectores más cercanos (Top 5)
    Vector-->>Edge: Devuelve 5 JSON de producto
    
    Nota sobre el borde: 3. Síntesis
    Edge->>LLM: "Aquí hay 5 vestidos. Recomiende uno para Italia".
    LLM-->>Edge: "El vestido de seda Amalfi es perfecto porque..."
    
    Edge-->>Usuario: Respuesta JSON (Producto + Texto)

No puedes buscar texto. Debes buscar “Significado”. Convertimos cada descripción de producto en Incrustación de vectores (una matriz de 1536 números de punto flotante). “Vestido rojo” y “Vestido carmesí” tienen texto diferente pero vectores similares (distancia <0,2).

El script de ingesta (Node.js)

Ejecutamos esto en un trabajo cron todas las noches.

importar {OpenAI} desde "openai";
importar {Piña} desde "@pinecone-database/pinecone";

const openai = nuevo OpenAI();
const piña = nueva piña();

función asíncrona vectorizarProducto(producto) {
  // 1. Crea una "cadena semántica"
  // Combinamos Título, Descripción y Reseñas
  contenido constante = `
    Título: ${producto.título}
    Descripción: ${producto.descripción}
    Tejido: ${product.tags.join(', ')}
    Ambiente: ${product.metafields.custom.vibe}
  `.recortar();

  // 2. Generar incrustación
  const incrustación = espera openai.embeddings.create({
    modelo: "incrustación de texto-3-pequeño",
    entrada: contenido,
  });

  // 3. Insertar en Vector DB
  aguarde piña.index("maison-products").upsert([{
    identificación: producto.id,
    valores: embedding.data[0].embedding,
    metadatos: {
      título: producto.título,
      precio: producto.precio,
      mango: producto.mango,
      imagen: producto.imagen
    }
  }]);
}

Paso 2: La consulta perimetral

La velocidad es crítica. Usamos Vercel Edge Functions o Cloudflare Workers. NO utilizamos un backend de Python. Es demasiado lento para arrancar en frío. Usamos TypeScript estrictamente tipado en Edge.

La consulta ocurre en dos etapas:

  1. Recuperación: busque los productos relevantes.
    • “Boda en Italia” -> Mapa semántico -> Lino, Transpirable, Floral, Elegante.
    • Vector DB devuelve: Vestido Amalfi, Falda Toscana, Sandalias Roma.
  2. Generación: Explica POR QUÉ.
    • Mensaje: “Eres estilista de moda. Explica por qué estos 3 artículos se ajustan a la solicitud del usuario. Sé breve.”

Técnicas de optimización

Procesar tokens cuesta dinero. Así es como reducimos los costos en un 90%.

1. Filtrado estricto (búsqueda híbrida)

Si un usuario filtra por “Tamaño: S”, no busque en todo el espacio vectorial. Aplique un filtro de metadatos a Pinecone FIRST. vector_search(query_vector, filtro={ tamaño: "S", in_stock: verdadero }) Esto reduce el espacio de búsqueda y mejora la precisión.

2. Almacenamiento en caché de respuestas

El 80% de los usuarios hacen las mismas preguntas. “¿Cuál es su política de devolución?” “¿Hacen envíos a Canadá?” Almacenamos en caché la Respuesta LLM en Redis, codificada por una versión hash del Vector de consulta. Si una nueva pregunta es semánticamente similar (distancia <0,1) a una pregunta almacenada en caché, devuelve la respuesta almacenada en caché. Latencia de 0 ms.

3. Modelos pequeños (SLM)

¿Necesitas GPT-4 para esto? No. GPT-4o-mini o Claude Haiku es 20 veces más barato y más rápido. Para las recomendaciones de comercio electrónico, la “inteligencia” es menos importante que el “contexto”. Si proporciona los productos correctos en la ventana contextual, incluso un modelo pequeño dará una excelente respuesta.

UI: La “UI generativa”

No se limite a transmitir texto. Transmitir Componentes. Cuando el LLM sugiera un vestido, muestre el componente <ProductCard /> directamente en el chat. Usamos el Vercel AI SDK para transmitir los estados de la interfaz de usuario.

// La interfaz de chat
importar {useChat} desde 'ai/react';

función de exportación ShopAssistant() {
  const {mensajes, entrada, handleInputChange, handleSubmit} = useChat();

  regresar (
    <div className="ventana de chat">
      {mensajes.map(m => (
        <clave div={m.id} nombre de clase={m.role}>
          {m.content}
          {/* Si la herramienta llama a los productos devueltos, renderícelos */}
          {m.toolInvocaciones?.map(herramienta => (
             <ProductoCarrusel productos={tool.result} />
          ))}
        </div>
      ))}
    </div>
  );
}

12. Almacenamiento en caché semántico (Redis/Momento)

Si 100 personas preguntan “¿La camisa es de algodón?”, no pague a OpenAI 100 veces. Págales una vez.

  1. Consulta de usuario -> Vectorizar -> [0.1, 0.2, ...].
  2. Verifique Redis: OBTENER vectores: más cercano ([0.1, 0.2]).
  3. Si la distancia es < 0,05, devuelve la respuesta en caché. Esto reduce los costos de LLM en un 60 % en implementaciones de alto tráfico. También reduce la latencia de 2 segundos a 50 ms.

13. Almacenamiento en caché rápido (antrópico)

Nuevo en 2025: Almacenamiento en caché rápido. Si envía un mensaje del sistema de 50 páginas (“Usted es un agente de ventas… aquí está nuestro catálogo…”), pagará por esos tokens cada vez. Con Context Caching, paga una vez para “cargar” el contexto a la API. Las llamadas posteriores hacen referencia a cache_id. Esto reduce los costos de los tokens de entrada en un 90 % y duplica la velocidad (el precarga es instantáneo).

14. Cuantización (GGUF / AWQ)

Los modelos suelen ser FP16 (coma flotante de 16 bits). Son enormes (14 GB para parámetros de 7 B). Cuantización los reduce a INT4 (enteros de 4 bits). El tamaño baja a 4GB. La pérdida de precisión es insignificante (< 1%). La velocidad aumenta 3x. Ejecutamos modelos cuantificados de 4 bits en hardware de consumo (MacBook Pros) para desarrollo local e inferencia de borde.

15. Decodificación especulativa

Los LLM generan un token a la vez. Esto es serial y lento. Decodificación especulativa utiliza un pequeño “modelo borrador” (rápido) para adivinar las siguientes 5 palabras. El Big Model (lento) simplemente los verifica en paralelo. Si el borrador es correcto (generalmente es por gramática simple), obtienes 5 fichas por el costo de 1 pase hacia adelante. Esto duplica la velocidad de generación sin cambiar los pesos del modelo.

16. Conclusión

La IA no es mágica. Es ingeniería. Requiere canalizaciones de datos, bases de datos vectoriales y almacenamiento en caché perimetral. Si simplemente “envuelve ChatGPT”, gastará dinero en efectivo. Si construyes un oleoducto RAG, construyes un foso competitivo.

Contrata a nuestros Arquitectos.