Ozon: un transformer en sugerencias de búsqueda — fracciones honestas de porcentaje a escala de billones de rublos

• Ozon Tech: генеративный трансформер в поисковых подсказках (архитектура, обучение на событиях, RPS, лимит 300 мс, итерации, риски генерации) — Habr (блог Ozon Tech), n/a
• Как Ozon ускорил расчёт факторов ранжирования динамической компиляцией (трёхуровневый поиск, CPU 15%+ → 5–6%, −10 мс) — Habr (блог Ozon Tech), n/a
• Ozon открыто рассказал об алгоритмах рекомендаций (пресс-брифинг о прозрачности, Алексей Минаев; >1000 признаков, вес персонализации ≈10%) — Телеспутник, 2022-04
• Принцип работы поиска на Ozon (5 шагов ранжирования, до 2000 кандидатов, нейросеть вероятности покупки) — SellerMoon, n/a
• Ozon задумался о создании ИИ-ассистента для помощи в поиске товаров (оценка +3–5% GMV за 1–2 года) — Forbes Russia, n/a
• GMV Ozon по годам (2024 ≈ 2,9 трлн ₽) — Smart-Lab (по отчётности компании), n/a

Contexto

Ozon es uno de los dos mayores marketplaces de Rusia, con GMV de aproximadamente 2.9 billones de rublos en 2024. A esa escala, la barra de búsqueda no es una 'característica del sitio' sino el canal de distribución principal: una gran parte de los pedidos comienza con una consulta, y cada fracción de porcentaje de conversión de búsqueda se mide en miles de millones de rublos de volumen de negocios.

El equipo de Ozon Tech mantiene un blog de ingeniería detallado en Habr y — inusual para este mercado — publica no solo las arquitecturas de su sistema ML sino ganancias métricas reales, incluyendo las modestas. La empresa es inusualmente abierta sobre algoritmos en general: en abril de 2022, en una conferencia de prensa sobre la transparencia del servicio de recomendación, Alexey Minaev, director gerente adjunto de Ozon, explicó públicamente cómo funcionan la búsqueda y las recomendaciones del marketplace — en el contexto de un proyecto de ley de la Duma Estatal sobre regulación de algoritmos de recomendación. Según la descripción oficial de la empresa, la selección y clasificación de ofertas pasan por cinco etapas en fracciones de segundo (Telesputnik).

Para la industria, esta apertura no es cosmética. El mercado de casos de retail AI está inundado de decks de proveedores que promocionan ganancias de 'conversión' de dos dígitos sin metodología; un blog de ingeniería que divulga la arquitectura, restricciones y ganancias exactas de A/B por iteración es casi el único género contra el cual se puede calibrar las propias expectativas.

La búsqueda de Ozon es un complejo sistema de múltiples niveles: el nivel base ejecuta recuperación de texto completo en millones de productos, el nivel intermedio clasifica precisamente miles de candidatos seleccionados, y el nivel superior aplica personalización (Habr, blog de Ozon Tech). Más de mil características participan en la clasificación; según la cuenta pública de la empresa, la personalización pesa aproximadamente 10% (popularidad del artículo 29%, ventas 17%, precio 5%), con los pesos revisados regularmente. Este caso se ensambla de tales fuentes primarias: cubre un transformer generativo en sugerencias de búsqueda — y cómo se ven los números de impacto reales en el recomendador cuando el equipo de ingeniería, no el departamento de marketing, los publica.

Problema

La búsqueda es el punto de entrada de compra en un marketplace. Las sugerencias débiles significan una ruta más larga hacia el producto y páginas de resultados vacías que matan la conversión: un usuario que obtiene 'nada encontrado' dos veces se va a un competidor. La economía de las sugerencias es simple: la mayoría de los compradores escriben consultas en un teléfono, donde cada carácter extra es fricción y cada error tipográfico arriesga una página vacía; una buena sugerencia reduce la escritura a unos pocos caracteres mientras dirige al usuario hacia una consulta cuyos resultados se garantiza que no estarán vacíos.

Las sugerencias clásicas ensambladas a partir de un diccionario de consultas populares manejan especificidades de marketplace pobremente: millones de productos, nombres de marcas y códigos SKU, errores tipográficos, transliteración ('xiaomi' en tres ortografías), y una cola larga de consultas raras donde un diccionario simplemente permanece en silencio. Esta es exactamente la especificidad que Ozon Tech cita como la razón para pasar a un modelo generativo entrenado en datos del dominio del marketplace (Habr).

Las restricciones de ingeniería son estrictas: las sugerencias deben servirse a decenas de miles de solicitudes por segundo dentro de un presupuesto de 300 milisegundos — de lo contrario, el usuario escribirá la consulta más rápido de lo que el sistema puede sugerirla, y todo el valor de la característica colapsa. Esa restricción inmediatamente descarta los grandes modelos de lenguaje con miles de millones de parámetros: con este tráfico, su inferencia o se pierde el presupuesto de latencia o exige una flota de GPU no asequible.

Finalmente, el enfoque generativo añade su propia clase de riesgos que las sugerencias de diccionario nunca tuvieron: el modelo puede producir una frase gramaticalmente rota, un duplicado semántico de una sugerencia vecina, una consulta que lleva a una página de resultados vacía, una frase tóxica de los datos de entrenamiento — o una marca completamente inventada y producto inexistente. Cada uno de estos modos de fallo tuvo que cerrarse con su propio bucle de postprocesamiento.

Solución

Ozon Tech construyó un transformer generativo solo decodificador de varios cientos de millones de parámetros, entrenado no en texto ordinario sino en tokens de acciones de usuario.

El entrenamiento se ejecutó en dos etapas. Primero, preentrenamiento en cadenas de eventos de usuario — consultas, clics, filtros, vistas de productos; una sola secuencia puede abarcar meses de interacciones de un usuario con el marketplace. Luego, ajuste fino en la tarea objetivo: generar una sugerencia a partir del contexto de sesión y el prefijo escrito. Este enfoque permite que el modelo 'conozca' marcas, SKU, errores tipográficos y transliteración a partir del comportamiento real del comprador en lugar de un corpus externo (Habr, blog de Ozon Tech).

La inferencia se ejecuta en un cluster de GPU a través de TensorRT-LLM, sustentando decenas de miles de solicitudes por segundo dentro del presupuesto de 300 ms. Los candidatos se generan con búsqueda de haz — el modelo rastrea varios variantes de continuación simultáneamente y elige el mejor, generando una lista de sugerencias diversa en lugar de una respuesta 'más probable'. Los candidatos se postprocesan luego: deduplicación, filtrado de frases prohibidas, y una verificación de que la sugerencia no lleve a una página de resultados vacía. Este plomería 'aburrida' es lo que cierra los riesgos específicos del enfoque generativo — desde errores gramaticales hasta marcas inventadas: un producto generado pero inexistente se corta en la verificación de resultados no vacíos antes de que llegue al usuario.

El viaje posterior de la consulta también está documentado. La sugerencia elegida entra en la canalización de búsqueda: el sistema recopila candidatos por palabras clave y sinónimos, selecciona hasta 2,000 artículos relevantes, una red neuronal puntúa la probabilidad de compra de cada uno de 0 a 1, luego se aplican impulsos y reducciones — y solo entonces el usuario ve resultados; según escritos de la industria, la canalización completa cabe en fracciones de segundo (SellerMoon). La sugerencia es así el primer filtro de un embudo gigante, y su calidad define la calidad de entrada para cada etapa posterior.

El despliegue procedió en iteraciones con medición A/B en cada una — y la secuencia en sí es instructiva. Iteración uno — generación básica de sugerencias cortas: +10% CTR de sugerencia; el modelo simplemente comenzó a cubrir consultas donde el sugeridor de diccionario permaneció en silencio. Iteración dos — sugerencias de varias palabras con fragmentos más largos: otro +10%; los usuarios comenzaron a ver una consulta completamente formada en lugar de solo 'TV'. Iteración tres — manejo de errores tipográficos: otro +3% CTR, una caída del 3% en páginas de resultados vacías, y +0.3% en la participación de usuarios que finalizan una sesión con un pedido — la primera vez que el efecto alcanzó la métrica empresarial final. El equipo establece la observación clave de estas iteraciones directamente: CTR crece más fácilmente que métricas empresariales — la capacidad de clic de sugerencia puede levantarse rápidamente, mientras que llevar el efecto a través de un pedido es mucho más difícil.

Las sugerencias son solo la parte visible de la pila de búsqueda. En el mismo blog, Ozon Tech describe la maquinaria de clasificación: un sistema de tres niveles (recuperación de texto completo en millones de productos → clasificación precisa de miles de candidatos → personalización) con miles de factores de clasificación profundamente anidados. Cuando la interpretación recursiva de fórmulas de factores comenzó a consumir más del 15% del CPU de todo el servicio, el equipo escribió un compilador que genera bytecode de JVM en tiempo de ejecución: el uso de CPU cayó a 5–6% y el tiempo total de consulta se redujo en 10 milisegundos. Los escritos de la industria completan el cuadro: se seleccionan hasta 2,000 artículos candidatos, una red neuronal puntúa la probabilidad de compra de cada uno de 0 a 1, luego se aplican impulsos y reducciones (SellerMoon). Tenga esto en mente al leer sobre '+10% CTR': detrás de cada porcentaje se encuentra infraestructura donde 10 milisegundos es una ganancia visible.

Resultado

Ganancias publicadas por iteración: CTR de sugerencia de búsqueda +10%, luego otro +10% y +3%; la participación de páginas de resultados vacías se redujo 3%; la participación de usuarios que finalizan una sesión con un pedido creció 0.3%. Cada cifra proviene de un experimento A/B en tráfico en vivo y fue publicada por el equipo mismo en su blog de ingeniería — con la admisión honesta de que la capacidad de clic crece más fácilmente que la conversión de pedidos.

Modesto a primera vista — pero a billones de rublos en GMV, las fracciones de porcentaje son un efecto empresarial material, y esto es lo que parecen números reales de sistemas de recomendación. Un resultado adicional, menos visible, es infraestructural: la compilación dinámica de fórmulas de clasificación redujo el consumo de CPU del servicio de búsqueda aproximadamente tres veces (de 15%+ a 5–6%) y eliminó 10 ms del tiempo de consulta — a decenas de miles de RPS, eso es tanto ahorros de hardware como una contribución directa a la velocidad de resultado.

Marco de credibilidad: todas las cifras son números autoinformados de la empresa sin auditoría independiente. Pero este es un autorreporte de un tipo particular — publicado por ingenieros con la metodología A/B descrita y puntos débiles admitidos (rendimientos decrecientes, la brecha CTR-a-pedido), lo que reduce drásticamente el riesgo de exageración de marketing. Por separado (una previsión, no un resultado): según una estimación citada por Forbes, un asistente de búsqueda AI futuro podría añadir 3–5% GMV para Ozon en uno a dos años. Esta estimación no debe confundirse con el +0.3% medido — son géneros diferentes de números.

En nuestra opinión, el valor principal del caso es de calibración. Establece para el mercado un punto de referencia de reporte honesto: la secuencia +10% → +10% → +3% muestra no solo el efecto sino su decaimiento, y la métrica '+0.3% usuarios con un pedido' muestra lo costoso que es cada fracción de porcentaje en un producto maduro. Cuando un proveedor o integrador promete '+15% conversión de AI en búsqueda', este caso es una regla lista para usar: uno de los equipos ML más fuertes del país, con su propio cluster de GPU y GMV de billones de rublos, documenta un efecto un orden de magnitud más modesto.

La segunda observación es arquitectónica: en nuestra opinión, elegir un modelo de cientos de millones de parámetros sobre un 'LLM de moda multi-miles de millones' es exactamente lo que parece madurez de ingeniería. Ozon eligió la arquitectura mínima que resuelve la tarea dentro de un presupuesto de latencia duro, en lugar de la máxima que la resolvería en una diapositiva.

Lecciones aprendidas

1. Las ganancias reales del recomendador se miden en fracciones y porcentajes individuales: +0.3% usuarios con un pedido en la escala de Ozon es una victoria, mientras que '+14% GMV de personalización' es una bandera roja de fabricación.
2. La latencia conduce la arquitectura: un presupuesto de 300 ms a decenas de miles de RPS dicta tanto el tamaño del modelo (cientos de millones de parámetros, no miles de millones) como la pila de inferencia (TensorRT-LLM).
3. El despliegue iterativo con medición en cada paso (+10% → +10% → +3%) es más honesto que un lanzamiento de un solo ruido: ves tanto el efecto como sus rendimientos decrecientes.
4. CTR crece más fácilmente que métricas empresariales: la capacidad de clic de sugerencia se levanta rápidamente, mientras que llevar el efecto a través de un pedido es un trabajo separado y más difícil (observación propia de Ozon Tech).
5. Las sugerencias generativas traen nuevas clases de riesgo — gramática rota, duplicados, frases tóxicas, marcas inventadas, sugerencias a resultados vacíos — y no deben enviarse sin un bucle de postprocesamiento.
6. La personalización es solo ≈10% del peso de clasificación de Ozon: las señales básicas (popularidad, ventas, precio) todavía deciden más.
7. Publicar números modestos señala madurez de cultura de ingeniería: tales fuentes pueden ser confiables en el resto también.

Preguntas frecuentes