Jesús Martínez
EN
← Trabajo · Caso de estudio

Respuestas en menos de un minuto, no en minutos.

Cortado, una plataforma de alquiler de propiedades, responde los mensajes de sus huéspedes con agentes de IA. La recuperación detrás de ellos había crecido hasta volverse lo que su CTO llamó un monstruo sobrediseñado, y los huéspedes esperaban minutos por una respuesta. La reconstruí desde los principios.

Cliente
Cortado
Rol
Ingeniero de LLM
Período
Ago 2024 a nov 2025
Construido con
Python, Pinecone, agentes LLM, MCP, microservicios basados en eventos

El contexto

Un huésped pregunta. El agente sale a buscar.

Responderle bien a un huésped es un problema de recuperación antes que de lenguaje: el agente necesita los datos correctos de la propiedad específica que tiene enfrente. Esos datos vivían en varias fuentes separadas. Y en alquileres, un huésped que espera demasiado simplemente le pregunta a otro.

El problema

Cada salto de más es tiempo mirando un “escribiendo…”.

El sistema que juntaba esos datos había crecido más allá de lo que el trabajo pedía, y las respuestas tardaban minutos. La ingesta tenía el mismo problema desde el otro lado: un solo pipeline monolítico, donde cada etapa avanzaba al ritmo del conjunto.

El enfoque

No hay que afinarlo. Hay que reconstruirlo.

Optimizar un sistema sobrediseñado suele conservar justo lo que lo vuelve lento. Así que partimos de lo que el agente de verdad necesita al responder, y nos quedamos solo con eso: un solo lugar donde buscar y una ingesta que corre en piezas pequeñas.

01

Cambio

Alguien edita un anuncio en algún sistema de origen, y esa edición se vuelve un evento.

02

Ingesta

Servicios pequeños basados en eventos la recogen y procesan solo lo que cambió, en vez de pasar todo por un monolito.

03

Índice

Los datos de las propiedades, vengan de donde vengan, terminan en un solo índice vectorial en Pinecone.

04

Respuesta

El agente recupera de ese único índice y le responde al huésped en menos de un minuto.

Decisiones y trade-offs

Tres decisiones que lo hicieron funcionar.

01

Reconstruir, no afinar.

En un sistema sobrediseñado, las partes que más tiempo cuestan suelen ser las más difíciles de quitar sin admitir que nunca hicieron falta. Partir de los principios obligó a tomar esa decisión a conciencia, en vez de heredarla.

Elegí reconstruir desde los principios en vez de optimizar el sistema viejo
02

Un solo lugar donde buscar.

Los datos de las propiedades estaban repartidos en varias fuentes, y una respuesta dependía de a cuál llegara la consulta. Consolidarlos en un solo índice vectorial les dio a los agentes un único lugar de dónde recuperar, y la precisión mejoró con eso.

Elegí un solo índice vectorial en vez de consultar varias fuentes
03

Eventos, no un monolito.

La ingesta pasó a servicios distribuidos basados en eventos. Una etapa lenta dejó de marcar el ritmo de las demás, la latencia de procesamiento bajó y un anuncio editado llegaba al índice sin reprocesar todo lo demás.

Elegí una ingesta basada en eventos en vez de un pipeline monolítico

El giro

Quitar cosas lo mejoró.

Se supone que quitarle etapas a un pipeline de recuperación cambia calidad por velocidad. Aquí mejoraron las dos. Cada etapa se había agregado para resolver un problema propio, y cada una se interponía entre la pregunta de un huésped y los datos de la propiedad. El camino más liviano le ganó al anterior en ambas cosas.

Más rápidomenos etapas que esperar
Más precisomenos lugares donde perder el dato correcto

El resultado

Dónde terminó.

< 1 minde tiempo de respuesta del agente, antes eran minutos por respuesta
1índice vectorial para datos de propiedades que antes estaban dispersos

También mejoraron la precisión de la recuperación y la satisfacción de los huéspedes. El diseño nuevo era más simple que el anterior, y más fácil de arreglar cuando algo fallaba.

En sus palabras

«Jesús fue clave para ayudarnos a renovar el sistema RAG detrás del software de mensajería con IA para huéspedes de Cortado. Con su ayuda, reconstruimos nuestro sistema de recuperación desde los principios y convertimos un monstruo sobrediseñado en una máquina de recuperación ágil y eficaz. Mi equipo recomendaría a Jesús a cualquiera que quiera dominar el machine learning moderno en la era de la inteligencia artificial».

Harry DubkeCTO, Cortado

Para el lector técnico

Notas de ingeniería

Decidir qué borrar

Un sistema sobrediseñado casi nunca se construye por descuido. Lo construye gente que va respondiendo a restricciones reales, una a la vez. Recortarlo significó descubrir cuáles de esas restricciones seguían siendo reales y cuáles se seguían esquivando mucho después de que dejaron de importar. Equivocarse en eso es quitar algo que sostenía el sistema.

Un solo almacén obliga a una sola verdad

Cuando varias fuentes se vuelven un solo índice, cada punto en que antes no coincidían tiene que resolverse. Antes se resolvía por accidente, según la fuente a la que llegara la consulta. Después tuvo que ser una decisión tomada a propósito.

Migrar con el producto en vivo

El paso del monolito a los eventos se hizo mientras los huéspedes seguían recibiendo respuestas. El camino viejo siguió atendiendo mientras el nuevo tomaba el relevo etapa por etapa, y los estados intermedios son justo los que nadie diseña.

  • Python
  • Pinecone
  • agentes LLM
  • MCP
  • microservicios basados en eventos