Cuando explico que en Mercadona Online estamos entrenando nuestros propios LLMs, la pregunta es siempre la misma: «pero por qué, si Claude y GPT son mejores?».
La respuesta cabe en una frase: porque el modelo tiene que ser nuestro.
Este artículo explica qué significa eso, cómo lo estamos haciendo, y por qué creo que es la decisión correcta para cualquier empresa que meta IA dentro de su producto — no al lado.
Por qué frontier es la primera respuesta lógica
Si me hubieras preguntado hace dieciocho meses qué LLM íbamos a meter en nuestros productos, te habría dicho lo mismo que te diría cualquier CTO razonable: el mejor disponible. Claude, GPT, Gemini. La pregunta no era cuál, era cuál de los tres ganará la próxima eval.
Y tiene su lógica. Los modelos frontier resuelven el 99% de los casos de uso de manera espectacular. Tienen el mejor razonamiento, el mejor multilingüe, el mejor tool use. Pagas una API, mandas un prompt, recibes una respuesta. Cero infraestructura, cero entrenamiento, cero deuda técnica.
Es la elección por defecto. Y es exactamente eso lo que la convierte en un problema cuando empiezas a hacer producto en serio.
Porque la pregunta que importa no es «¿qué LLM es el mejor?». Es «¿qué pasa cuando tu producto crece?».
Los cuatro problemas de frontier dentro del producto
Cuando metes un LLM frontier en una funcionalidad concreta de tu producto, hay cuatro cosas que cambian en silencio. Las cuatro son contables con los dedos. Las cuatro son las que te van a obligar, en algún momento, a replantearte la decisión.
Tus datos salen de tu perímetro
Cada vez que llamas a la API de un proveedor frontier, le estás mandando algo: un prompt, un fragmento de tu catálogo, una pregunta de un cliente, un trozo de tu histórico. Da igual lo que diga el contrato sobre retención: ese dato ha cruzado tu frontera.
Para una empresa como Mercadona, el catálogo, los procesos internos y las conversaciones con clientes son parte del activo. No son cosas que mandes a un tercero porque es más cómodo. Y el problema no es el cumplimiento legal — eso se gestiona —. El problema es que tu ventaja competitiva, lo que de verdad sabe tu empresa hacer, se convierte en training data potencial para el modelo que mañana vas a tener que comprar a precio de mercado.
El coste escala con cada cliente, cada feature y cada conversación
Frontier cobra por token. Suena razonable hasta que haces los números a escala.
Si tu producto tiene un asistente que se usa una vez por sesión, multiplicado por millones de sesiones al mes, multiplicado por cada nueva funcionalidad de IA que añades — el coste no crece, explota. Y crece exactamente en el peor momento: cuando tu producto funciona bien y la gente lo usa más.
Pero el problema de fondo no es el coste absoluto. Es que tus costes suben al mismo ritmo que tu facturación. Y eso rompe el apalancamiento operativo.
El apalancamiento operativo es el motivo por el que un negocio digital es atractivo: tu coste de servir al cliente número 10 millones es prácticamente el mismo que el del cliente número uno. Cada usuario nuevo entra casi todo a margen. La curva de ingresos sube, la de costes se aplana, y el beneficio se dispara. Esa es la promesa del software desde hace cuarenta años.
Frontier por token rompe esa promesa de raíz. Cada conversación nueva es un coste nuevo. Cada feature de IA es una factura adicional. Tu margen no se expande con la escala — se queda fijo, en el mejor caso. En el peor, se contrae cuando el proveedor sube tarifas o cuando empiezas a usar modelos más capaces para no quedarte atrás de la competencia.
No es la primera vez que el sector tropieza con esto. Es exactamente lo que pasó con el SaaS y con el cloud público a escala. Empresas como Dropbox descubrieron que pagar a AWS por cada terabyte de cliente se comía sus márgenes brutos, y acabaron repatriando el almacenamiento a infraestructura propia — con ahorros de cientos de millones y márgenes brutos que pasaron de no llegar al 35% a superar el 65%. Basecamp y otras empresas más pequeñas han hecho el mismo viaje en los últimos años: cuando operas a escala, cloud público es dos o tres veces más caro que infra propia bien dimensionada. La conveniencia inicial se convierte en un impuesto permanente sobre tu crecimiento.
Frontier en producción es el siguiente capítulo de esta misma historia. Y los CFOs que aprendieron la lección con AWS la van a aprender otra vez con OpenAI y Anthropic — solo que esta vez el coste no es almacenamiento, es cada palabra que tu producto le dice a un cliente.
Lo que dice tu producto lo decide tu proveedor
Un día Anthropic decide que su próximo modelo se comporta distinto en una tarea concreta. Otro día OpenAI deprecia la versión que tú habías evaluado. Otro día cambian el system prompt por defecto y tu producto empieza a responder con un tono que no es el tuyo.
No estoy hablando de hipotéticos. Esto pasa cada pocos meses. Y cuando tu funcionalidad crítica depende del modelo de un tercero, tú no decides cómo se comporta tu producto. Lo decide la última versión que ese tercero ha desplegado.
Para una herramienta interna eso es asumible. Para un producto que ven millones de clientes, no.
Pagas por capacidades que no necesitas
Los modelos frontier son generalistas. Saben de poesía persa, de derecho mercantil húngaro y de combinatoria avanzada. Y los pagas todos, en cada token, aunque tu producto solo necesite hablar de pedidos, productos y entregas.
La paradoja es que para tu tarea específica — la única que de verdad importa para tu producto —, un modelo open source mucho más pequeño, afinado con tus datos, iguala o supera al frontier. No porque sea mejor en general. Porque está concentrado en lo tuyo.
Estás pagando un Ferrari para ir a comprar el pan a la esquina.
El OSS ya cerró la brecha donde importa
Todo lo anterior sería un debate teórico si el open source no fuera una alternativa creíble. Hace dos años no lo era. Hoy sí, y el cambio se ha dado tan rápido que mucha gente decidiendo arquitectura de IA en empresas todavía no se ha enterado.
Conviene fijar primero qué quiere decir “open source” en este contexto, porque el término se usa con cierta ligereza. Cuando hablo de modelos OSS me refiero a modelos cuyos pesos — los parámetros que el modelo ha aprendido durante el entrenamiento — son públicos, descargables y vienen con licencias que permiten uso comercial: Apache 2.0, MIT o equivalentes. No son APIs a las que llamas. Son modelos que te bajas, que ejecutas en tu propia infraestructura, que puedes inspeccionar, evaluar, modificar y reentrenar. La diferencia con los modelos cerrados — Claude, GPT, Gemini — no es solo de licencia. Es de ubicación: un modelo OSS vive donde tú decides; uno cerrado vive donde decide su proveedor.
En 2024, los modelos abiertos iban dos generaciones por detrás. Llama 2 contra GPT-4 era una pelea perdida. La diferencia de calidad era visible a simple vista, en cualquier tarea, y nadie en su sano juicio metía en producción un modelo abierto si tenía presupuesto para frontier.
En 2026, el panorama es otro. Qwen3 de Alibaba lidera evaluaciones públicas de código y compite de tú a tú en razonamiento, con licencia Apache 2.0. DeepSeek-V3.1 combina razonamiento profundo con una eficiencia en inferencia muy difícil de igualar para los frontier, también con licencia abierta. Mistral Large viene de Francia, con buen rendimiento multilingüe en lenguas europeas, y Llama 4 de Meta tiene el ecosistema de fine-tuning más maduro del mercado.
Cuatro familias serias, con licencias que permiten uso comercial, con pesos descargables, con comunidades activas. Eso no existía hace dieciocho meses.
Pero conviene afinar la palabra “abierto”, porque no todas las licencias son iguales y el matiz importa más de lo que parece. Apache 2.0 (Qwen3) y MIT (DeepSeek) son licencias open source puras: puedes usar el modelo, modificarlo, redistribuirlo, integrarlo en productos comerciales sin restricciones de tamaño, sector o uso. Son el equivalente, para modelos, de lo que Linux representa en software de servidor: libertad real.
La Llama Community License de Meta no es eso. Es lo que en la industria se llama source available: los pesos están disponibles y puedes hacer mucho con ellos, pero la licencia introduce condiciones. La más conocida es que si tu producto supera cierto umbral de usuarios mensuales activos tienes que negociar una licencia comercial separada con Meta. Y mantiene una cláusula de usos prohibidos sobre la que Meta tiene la última palabra. Para una empresa pequeña la diferencia es invisible. Para una empresa que crece — y ese suele ser el plan — no lo es.
Mi recomendación, cuando alguien me pregunta por dónde empezar, es clara: si haces este viaje, hazlo con licencias OSS puras. El motivo principal por el que una empresa va a OSS es evitar depender del roadmap de un tercero. Una licencia “casi abierta” reintroduce exactamente esa dependencia, solo que con menos visibilidad — porque la dependencia no se manifiesta hasta que tu producto crece o hasta que el proveedor decide cambiar los términos. Apache 2.0 o MIT son la garantía de que la decisión sobre qué hacer con tu modelo la sigues tomando tú dentro de cinco años, no Meta o quien sea.
Aclarado esto, el punto importante de fondo es la trampa mental de comparar modelos en abstracto.
Cuando alguien dice “Claude es mejor que Qwen”, normalmente está mirando un benchmark generalista: MMLU, GPQA, evaluaciones de razonamiento puro. Y es verdad — en general, frontier sigue ganando. La pregunta es si “mejor en general” tiene algo que ver con tu producto.
Tu asistente de pedidos no necesita resolver olimpiadas matemáticas. Tu chatbot de atención al cliente no necesita escribir poesía. Tu motor de recomendaciones no necesita debatir filosofía moral. Necesitan entender tu catálogo, tu tono, tus operaciones, tus clientes. Necesitan ser excelentes en una superficie muy concreta.
Y para esa superficie concreta, un modelo open source pequeño afinado con tus datos iguala o supera a un modelo frontier de un orden de magnitud más grande. No porque sea mejor en general — sigue sin serlo. Porque está concentrado en lo tuyo, sin la dispersión de tener que saberlo todo.
Hay una intuición técnica detrás de este resultado que merece la pena explicitar. El espacio de razonamiento que un modelo tiene que cubrir para ser excelente en una tarea concreta es órdenes de magnitud menor que el que necesita un modelo generalista. Un asistente que solo tiene que entender pedidos, productos y entregas no razona sobre química orgánica, ni resuelve acertijos lógicos arbitrarios, ni traduce poesía clásica. Tiene que ser excelente en una superficie acotada. Y cuando acotas la superficie, acotas la dificultad: hacer bien una sola cosa es más fácil que hacer bien muchas.
Es un principio que se aplica a humanos, a software y a modelos. Un equipo pequeño centrado en un problema vence sistemáticamente a un equipo grande que intenta abarcarlo todo. Una herramienta que hace una cosa la hace mejor que una suite que pretende hacer cinco. Y un modelo de menor capacidad bruta, especializado en tu dominio, supera a uno de capacidad bruta superior pero atención dispersa, en tu dominio. Por eso un OSS bien afinado puede competir de tú a tú con un frontier diez veces más grande en lo que de verdad importa para tu producto: porque la pelea no es la que el benchmark cuenta. Es una pelea acotada, y en peleas acotadas, especialización gana.
Es la diferencia entre un médico de cabecera que conoce a tus pacientes desde hace veinte años y el mejor diagnosticador del mundo al que llamas por teléfono. El segundo sabe más medicina. El primero acierta más con tus pacientes.
Tres herramientas para tres problemas distintos: prompts, RAG y LoRA
Una de las confusiones más frecuentes en este terreno es presentar prompts, RAG y fine-tuning como un escalón: que primero pruebas prompts, luego subes a RAG y, si no llega, terminas en fine-tuning. La realidad es otra. Son tres herramientas que resuelven problemas distintos. Elegir la equivocada es una de las maneras más caras de fracasar con IA en producto.
System prompts es siempre la primera capa, porque opera sobre algo que las otras dos no tocan: el comportamiento del modelo en cada llamada. RAG y LoRA, en cambio, no son alternativas escaladas. Son respuestas a preguntas distintas, y pueden coexistir o no según lo que necesite tu funcionalidad.
Capa 1 · System prompts: el comportamiento, en cada llamada
Es la capa más rápida y la más barata. Le dices al modelo, en cada llamada, qué tono usar, qué decir, qué nunca decir, y en qué formato responder. Reglas de comportamiento, guardarrales, estilo.
El cambio es inmediato — editas el prompt, despliegas, listo. Minutos. El coste es marginal: los tokens del prompt en cada llamada. Y el alcance, aunque parezca modesto, no lo es: la mayor parte del tono y de los errores graves de un asistente se arreglan aquí, no en el modelo.
System prompts es la única capa que siempre tiene sentido. Si no resuelves un problema con prompts, lo más probable es que lo tengas mal planteado antes de plantearte ninguna otra cosa.
Capa 2 · RAG: cuándo sí, cuándo no
RAG no es “prompts pero más potente”. Es una herramienta concreta para un problema concreto: que el modelo responda apoyándose en información tuya que el modelo no podía conocer en su entrenamiento.
Tiene sentido cuando:
Tu funcionalidad necesita responder con datos que cambian (catálogo, precios, disponibilidad, estados de pedido, FAQs vivas).
Necesitas trazabilidad: poder mostrar de dónde sale cada afirmación, citar la fuente, auditar.
El cuerpo de conocimiento es demasiado grande para meterlo en el prompt en cada llamada.
Quieres que el conocimiento se actualice sin tocar el modelo — basta con reindexar.
No tiene sentido cuando:
El problema es de tono, estilo o formato. Eso lo arreglan prompts; RAG no añade nada.
Tu dominio es estable y cabe en un prompt. Montar un vector store para guardar tres páginas de documentación es complicar gratis.
La latencia es crítica. RAG añade pasos: embeddings, búsqueda, recuperación, contexto extra. En productos donde la respuesta tiene que ser instantánea, ese coste pesa.
Tu información no se busca bien por similaridad semántica. Si lo que necesitas es una consulta SQL contra una tabla, una API o una búsqueda exacta por ID, RAG no es el camino — es un rodeo caro.
Y un punto que muchos equipos descubren tarde: RAG mal hecho es peor que no tener RAG. Si tu sistema de recuperación devuelve fragmentos irrelevantes — chunks mal troceados, embeddings pobres, mezcla de fuentes que no tocan — no estás dándole al modelo más contexto. Le estás metiendo ruido. Y el modelo no responde “centrándose en lo relevante”: se confunde, mezcla información, alucina con apariencia de rigor citando fuentes que no aplican. Un RAG sin evaluación seria de la calidad de recuperación puede degradar las respuestas respecto a no tener RAG en absoluto. La parte cara de hacer RAG bien no es la generación — es la recuperación.
RAG es muy útil cuando aplica. El error es asumir que aplica siempre.
Capa 3 · LoRA: cuándo sí, cuándo no
LoRA es la única capa que toca el modelo en sí. Reentrenas una fracción de los pesos con datos tuyos. El modelo no consulta tu conocimiento en cada respuesta: ha aprendido patrones que antes no tenía.
Tiene sentido cuando:
Necesitas un comportamiento que no se puede expresar como reglas en un prompt — un tono, una jerga, convenciones implícitas, decisiones de matiz que un humano experto reconoce pero no sabe articular.
Tu volumen de uso es suficiente para amortizar el coste de entrenar y mantener una versión propia.
Quieres reducir el coste por inferencia: un modelo abierto pequeño y bien afinado puede sustituir a uno grande generalista, con una fracción del coste por llamada.
Tienes un dataset de entrenamiento de calidad — no solo cantidad, calidad. Sin esto, no hay LoRA que valga.
No tiene sentido cuando:
El conocimiento que necesitas inyectar cambia frecuentemente. LoRA aprende patrones, no hechos. Si los datos cambian cada semana, estás reentrenando cada semana — y eso no es viable.
Aún no has agotado prompts y, donde aplique, RAG. Casi siempre que un equipo siente “necesidad” de fine-tuning, el problema real está más arriba.
No tienes equipo para mantenerlo: GPUs, evaluaciones, versionado, observabilidad, capacidad de revertir. LoRA no es un proyecto puntual — es una línea de mantenimiento.
El volumen de uso no justifica el coste fijo. Para una funcionalidad de uso puntual, un modelo afinado es matar moscas a cañonazos.
Y luego están las tools: cuando el problema no es saber, sino hacer
Las tres capas anteriores son formas de afinar al modelo a tu contexto. Hay un cuarto recurso que opera sobre algo distinto y es muy fácil de olvidar: las tools (también llamadas function calling o tool use).
Una tool es una función externa que el modelo puede invocar por sí mismo cuando lo necesita: consultar tu API de pedidos, leer un registro en una base de datos, hacer un cálculo, llamar a un servicio interno, ejecutar una acción concreta. El modelo no la ejecuta — pide ejecutarla. Tu sistema la corre, le devuelve el resultado, y el modelo continúa la conversación con esa información en mano.
Tools no compiten con prompts ni con RAG: les añaden una dimensión que ninguna de las tres capas puede dar por sí sola. Donde RAG ofrece conocimiento estático (lo que has indexado de tu corpus), las tools dan información viva y capacidad de actuar: el estado actual de un pedido, el stock real en este momento, la respuesta de un sistema externo, una transacción ejecutada. Para muchas funcionalidades — sobre todo asistentes que tienen que hacer cosas, no solo responder — las tools son lo que convierte una conversación en un producto.
Y un detalle que ahorra muchos disgustos: el lugar correcto para datos estructurados que necesitas exactos — precios, stock, IDs, estados — no es RAG. Es una tool. RAG es para texto donde la similaridad semántica funciona. Tools son para hechos que tienen que ser exactos y vivos. Confundir las dos es la fuente número uno de respuestas seguras de sí mismas y profundamente equivocadas.
El criterio que importa
No subes de prompts a RAG, ni de RAG a LoRA. Eliges la herramienta que encaja con la naturaleza de tu problema:
¿El problema es comportamiento, tono o formato? → prompts.
¿El problema es conocimiento textual puntual y verificable? → RAG.
¿El problema es datos vivos, exactos o capacidad de actuar? → tools.
¿El problema es patrones implícitos, estilo profundo o coste por inferencia a escala? → LoRA.
Las cuatro pueden convivir en la misma funcionalidad, pero no porque sean niveles de una escalera. Porque resuelven cosas distintas.
El umbral económico que casi nadie cuenta
Hasta aquí los argumentos por OSS son cualitativos: soberanía, control, especialización, evitar que tu producto dependa del roadmap de un tercero. Son argumentos válidos. No son los que ganan la conversación con un CFO.
La conversación con un CFO la ganas cuando el cálculo cierra. Y el cálculo, cuando lo haces de verdad, es más matizado de lo que se cuenta en LinkedIn — en las dos direcciones.
El cálculo simple
Frontier es un coste variable. Pagas por token consumido, sin más. Empiezas en cero y subes con el uso. Es ideal para empezar — no necesitas comprometer nada hasta que la funcionalidad demuestra tracción.
OSS propio es un coste fijo. Tienes que tener GPUs (o reservar capacidad gestionada), un vector store si usas RAG, observabilidad, evaluaciones, y un equipo que mantenga todo eso. El primer token que generas te cuesta una fortuna. Los siguientes millones, prácticamente nada.
Donde se cruzan las dos líneas es tu umbral. Por debajo, frontier sale más barato. Por encima, OSS sale más barato — y la brecha se ensancha rápido a medida que el uso crece.
Lo que casi nadie cuenta del lado OSS
La trampa habitual al hacer este cálculo es subestimar el lado fijo. La cuenta ingenua compara €/M tokens de la API frontier contra el coste de una GPU. No es esa la comparación.
Tener un modelo en producción incluye, además del compute:
Equipo: gente que entiende fine-tuning, evaluación, despliegue de modelos, observabilidad. Es perfil escaso, no barato.
Evaluaciones: si no mides la calidad de tu modelo afinado contra una baseline frontier de manera continua, no sabes si has degradado. Eso es infraestructura de evaluación, datasets curados y proceso.
Mantenimiento: los modelos abiertos sacan nuevas versiones. Tu LoRA está atado a una. Migrar tiene coste.
Observabilidad: latencia, fallos, calidad de las respuestas, deriva. Todo eso te lo da gratis un proveedor frontier; en infra propia lo construyes tú.
Si haces el cálculo solo con GPUs y olvidas todo lo demás, tu OSS parece barato y luego no lo es. Y si haces el cálculo solo con GPUs y olvidas lo demás también en el lado frontier, te equivocas en la otra dirección — porque frontier al final también requiere tu propio observabilidad, evaluación y proceso de migración cuando cambian de modelo.
Cuándo OSS no sale a cuenta
Hay casos en los que la respuesta honesta es “frontier es la opción correcta hoy”:
Volumen bajo o impredecible: si tu funcionalidad mueve un puñado de miles de llamadas al mes, no hay aritmética que cierre. Quédate en API.
Funcionalidad experimental: si no sabes aún si la feature va a sobrevivir el próximo trimestre, es absurdo amortizar nada. Frontier es el modo de prototipar.
Equipo insuficiente: si no tienes a nadie que pueda mantener el modelo, el coste real no es la GPU — es el riesgo. Y ese riesgo se cobra solo en el peor momento.
Una sola funcionalidad pequeña: si tu único caso de uso es un asistente puntual de baja intensidad, el coste fijo no se reparte entre nada.
En todos estos casos, frontier no solo es razonable: es lo correcto. Pelear contra eso es ideología, no estrategia.
Cuándo sí, y por qué la brecha se ensancha
OSS empieza a tener sentido cuando se cumplen tres condiciones a la vez: volumen alto y sostenido, varias funcionalidades de IA que comparten infraestructura, y un horizonte previsible en el que ese uso va a crecer, no a desaparecer.
Cuando esas tres condiciones se cumplen, el coste fijo se reparte y el coste variable evitado crece a la vez. La diferencia entre las dos curvas no es lineal — se ensancha. Y a partir de cierto punto, el cálculo deja de ser interesante: frontier en producción simplemente no es competitivo.
Hay además un efecto temporal que muchos análisis ignoran: el umbral baja cada año. Las GPUs son más eficientes, los modelos abiertos son más capaces con menos parámetros, las técnicas de fine-tuning bajan en coste. Lo que hace dieciocho meses requería un cluster, hoy cabe en una máquina. Lo que hoy requiere un equipo dedicado, en dos años cabrá en una herramienta gestionada.
Si tu producto tiene volumen y horizonte, no estás eligiendo entre OSS y frontier en un instante: estás eligiendo en qué dirección quieres que tu coste por conversación evolucione durante los próximos cinco años. Y esa pregunta tiene una respuesta bastante clara.
Hazte el cálculo, no la teología
El error frecuente es tratar esta decisión como ideológica — “yo soy team OSS” o “yo soy team frontier” —. No lo es. Es aritmética con horizonte temporal. Coge tu volumen real, los precios actuales del proveedor que uses, una estimación honesta de tu coste fijo OSS (incluyendo equipo y mantenimiento, no solo compute), y proyéctalo dos o tres años con el crecimiento que esperas. La respuesta sale del cálculo, no de la convicción.
Lo que sí cambia es a quién le toca asumir el coste de equivocarse. Si te quedas en frontier y tu producto escala, lo paga el negocio en márgenes erosionados. Si saltas a OSS y tu producto no escala, lo paga el negocio en infraestructura ociosa. La pregunta es de qué error te puedes recuperar mejor.
El rol que sí tiene Claude (y los demás frontier): research, no producción
Todo lo anterior se puede leer mal: que estoy diciendo que los modelos frontier no sirven. No es eso, en absoluto. Frontier sirve — y mucho. Lo que defiendo es que su lugar no es producción. Su lugar es research y baseline.
Esos son dos roles distintos y los dos son importantes.
Rol 1 · Research: la prueba de viabilidad
Cuando tu equipo de producto pone encima de la mesa una idea de funcionalidad con IA, hay una pregunta que viene antes de cualquier otra: ¿es siquiera resoluble? ¿La mejor IA disponible en el planeta puede hacer lo que estamos imaginando, en las condiciones que necesita un cliente real?
Esa pregunta la contesta frontier en una tarde. Coges Claude o el equivalente, montas un prototipo rápido, le metes ejemplos reales, y observas. Si frontier no llega — si las respuestas son malas, si el razonamiento falla, si los casos límite se rompen — la idea no está lista. No vas a hacerlo mejor con un OSS más pequeño. Has ahorrado seis meses.
Si frontier sí llega, sabes dos cosas a la vez: el problema es resoluble, y has fijado el techo de calidad al que tu solución de producción tiene que aspirar. Eso es lo segundo.
Rol 2 · Baseline: la vara de medir
Aquí es donde frontier se vuelve imprescindible incluso para una empresa que ha decidido no tenerlo en producción. Frontier es el patrón contra el que mides tu propio modelo.
Cada vez que afinas un OSS para tu caso de uso, cada vez que cambias el sistema de RAG, cada vez que iteras sobre un LoRA — necesitas saber si has mejorado o has empeorado. Y “mejor” o “peor” no son adjetivos, son números: tasa de éxito en una eval, calidad subjetiva en muestras anotadas, porcentaje de respuestas correctas en preguntas reales de clientes.
La vara de medir es Claude. Si tu OSS afinado no se acerca a Claude en las tareas que importan a tu producto, no estás listo para producción. Habrás conseguido independencia, sí, pero a costa de degradar la experiencia del usuario. Eso no es una victoria — es haber metido complejidad operativa sin ganar nada.
Si tu OSS sí se acerca o lo supera en tu superficie concreta — y lo hace de manera medible y reproducible — entonces estás listo. Y solo entonces.
El flujo que ata las piezas
El proceso completo que se deduce de estos dos roles es bastante limpio y se puede aplicar a casi cualquier funcionalidad:
1. Idea con Claude: prototipas con frontier para confirmar que el problema es resoluble.
2. Eval contra baseline: defines cómo vas a medir éxito en este caso concreto, fijas la línea base con Claude.
3. RAG sobre OSS, si aplica: montas el sistema de recuperación con tu modelo abierto, evalúas contra la baseline.
4. LoRA, si aplica y se justifica: solo si los dos pasos anteriores no llegan y el caso lo merece económicamente.
5. Producción en OSS: cuando la calidad iguala o supera a la baseline frontier, despliegas.
Lo importante de este flujo no es lo que está en él. Es lo que está fuera: frontier no aparece en el paso 5. Aparece en los pasos 1 y 2, donde aporta lo que de verdad sabe aportar — capacidad bruta para explorar y rigor como vara de medir —, y se queda fuera de la operación diaria del producto.
Es la forma de tener lo mejor de los dos mundos sin pagar el coste de los dos mundos.
Dónde estamos en Mercadona Online (sin vender humo)
He hablado mucho de marco mental, principios y decisiones. Toca aterrizar en dónde estamos nosotros, porque me parece deshonesto publicar todo lo anterior sin contar la verdad de lo lejos — o cerca — que estamos del destino.
La decisión está tomada. Producción en OSS, frontier en research y baseline. Esa es la dirección estratégica de Mercadona Online y se ha discutido y aprobado al nivel donde estas decisiones se toman. No es una idea de un equipo aislado. Es por dónde queremos que vaya nuestra capa de IA en producto.
Lo que ya está pasando es la parte fácil de contar. Algunos de nuestros productos internos — asistentes de coordinadores, herramientas de calidad, sistemas de soporte a operaciones — tienen IA dentro hoy. Y esa IA está apoyada, en este momento, en Claude vía Vertex como solución provisional. Funciona, da valor y nos ha permitido validar que los casos de uso son resolubles. Eso es exactamente el rol 1 del que hablaba antes: research aplicado, prueba de viabilidad en producto real.
Lo que estamos construyendo es la parte que importa de verdad. Tenemos un modelo OSS propio en marcha — actualmente sobre Qwen3 8B, afinado con LoRA y datos nuestros — corriendo en infraestructura propia. Y estamos montando el sistema de evaluaciones que nos va a permitir comparar el comportamiento de nuestro modelo contra la baseline de Claude en cada una de las funcionalidades que importan, antes de cambiar nada en producción.
Hay una decisión consciente en lo que no estamos tomando: no usamos RAG. Enlazo esto directamente con lo que decía en la sección de las herramientas, porque en nuestro caso no se cumplen las condiciones para que aplique. Las funcionalidades que tenemos hoy no manejan grandes volúmenes de información textual que el modelo necesite consultar dinámicamente; lo que necesitan saber cabe en el system prompt, se resuelve por tools contra nuestros sistemas, o se aprende vía LoRA. Y la complejidad de montar bien la recuperación — con todo lo que hablábamos del ruido, la calidad de los embeddings, la evaluación continua de qué se devuelve — no nos compensa hoy. Si en algún momento aparece una funcionalidad que sí lo necesite, lo añadiremos. Pero la regla es exactamente la que recomendaba antes: RAG cuando aplica, no por defecto. Y a nosotros, hoy, no nos aplica.
Lo que aún no tenemos es la parte honesta. No tenemos producción 100% en OSS todavía. Estamos en mitad del viaje, no al final. Las funcionalidades que hoy llegan al cliente y al empleado de tienda van por Claude. La migración a nuestro propio modelo es un trabajo de meses — y por algunas funcionalidades concretas, posiblemente más — porque hay que evaluarlo bien antes de cambiar nada. Si nuestro OSS afinado no se acerca a la baseline frontier en una tarea concreta, no se cambia esa tarea. Se itera hasta que se acerque, o se acepta que esa tarea concreta no es candidata a OSS hoy.
¿Por qué cuento esto antes de tener números reales? Porque la decisión estratégica es lo importante, y los números van detrás. Si esperase a tener todas las métricas para hablar del enfoque, el enfoque ya estaría desfasado cuando lo contara. Prefiero publicar el plan ahora, con la honestidad de que es un plan en ejecución, y volver dentro de unos meses con los datos.
Lo que sí puedo decir hoy con seguridad es que la pregunta “¿esto sale a cuenta?” la hemos hecho. La aritmética cierra para Mercadona — volumen, horizonte y número de funcionalidades de IA suficientes para que el coste fijo se reparta. Y la pregunta “¿el OSS es bueno suficiente?” la estamos contestando funcionalidad a funcionalidad, no en abstracto. Es la única manera honesta de contestarla.
La pregunta que importa
Si tuviera que reducir todo lo anterior a una sola frase, sería esta: el lugar donde decides que viva tu IA es una decisión estructural, no técnica. Decide márgenes. Decide quién determina cómo se comporta tu producto. Decide la velocidad a la que puedes innovar. Decide qué activos quedan dentro de tu empresa y cuáles cruzan la frontera. Tratarla como una decisión de proveedor — “uso este o aquel” — es no ver lo que hay debajo.
La industria del software ya ha vivido este momento dos veces. La primera, con on-premise contra SaaS. La segunda, con servidor propio contra cloud público. En las dos, la conveniencia inicial del proveedor terminó convirtiéndose en un peaje permanente sobre el crecimiento. En las dos, hubo empresas que llegaron tarde a darse cuenta de que estaban subsidiando los márgenes de su proveedor con los suyos. Frontier en producto es el tercer ciclo de la misma película, ahora en directo.
Si tu producto va a tener IA dentro durante la próxima década — y casi todos los productos digitales serios la van a tener — la pregunta importante no es qué LLM usar este trimestre. Es qué relación quieres tener con tu capa de IA dentro de cinco años: una factura mensual creciente con un proveedor que decide cómo se comporta tu producto, o una infraestructura propia, ajustada a tu negocio, sobre la que tomas tus propias decisiones.
Para una empresa con volumen, horizonte y varias funcionalidades de IA que repartan coste fijo, la respuesta — cuando hace el cálculo honesto — sale casi siempre en la misma dirección. La diferencia entre las que actúan ahora y las que actúan dentro de tres años no es la respuesta. Es cuánto habrá pagado de más cada una para llegar al mismo sitio.
¿Dónde está tu umbral?
Gemba se publica todos los lunes a las 8:30. Si te ha resonado, comparte el artículo con un PM o un líder de tecnología que esté tomando esta decisión ahora.
Y, como en todo, entre el blanco y el negro, hay muchos grises. No es necesario usar Opus 4.7 para todo cuando Haiku es suficiente, igual que es un desperdicio coger el Ferrari para ir a por el Humus y el Guacamole al Mercadona del barrio…
Se pueden optimizar las llamadas a los modelos según las necesidades. E, incluso, existen soluciones como OpenRouter que te permiten usar modelos OSS sin pagar por tokens.
Esto va contra la soberanía, por supuesto. Pero pasa los que no somos Mercadona, nos puede servir. No siempre hay que pagar por el frontier full equip.
Por otro lado, no ttermino de ver que haya que hacer baseline contra un modelo frontier. Creo que habría que hacer estudios donde definas lo que es good enough y medir contra eso. Y con cada evolución de tu LoRa, medir si has mejorado. No necesitas estar a la altura del más listo para dar una buena experiencia.
En cualquier caso, esto va avanzando tan rápido que veo arriesgado decantarse por OSS ‘propio’ y ponerse a entrenarlo. Como dices, te estás cerrando a una versión y paaar a la siguiente puede ser más costoso. Habrá que ver qué recorrido de mejora tienen los modelos aún y cuándo empezar a estabilizarse la curva. Igual compensa esperar un poco y, llegado el caso, hacer como los ejemplos de cloud que pusiste y dar el salto más adelante.
Mercadona probablemente pueda permitirse hacerlo así, pero otros más pequeños creo que deberían centrarse en coger velocidad de crucero con modelos fuera y más adelante plantearse entrenar a uno propio.
Muy interesante el artículo, salvando las distancias, nos vemos reflejados en bastantes de las cosas que comentas. Son muchos los comentarios que me surgen, y entiendo que no puedes contestarlos todos, pero quería destacar dos cosas que me han llamado especialmente la atención.
La primera es la elección de Qwen3 8B. Me ha sorprendido que el modelo sea relativamente pequeño. ¿Cómo tomasteis esa decisión frente a variantes más grandes de la misma familia? ¿Fue principalmente por latencia, por coste de inferencia, o visteis que el salto de calidad no justificaba el coste extra de parámetros?.
La segunda es sobre infraestructura, justificar internamente una inversión inicial en hardware serio (varias H100 pueden superar fácilmente los 100k€) no es trivial antes de tener funcionalidades en producción con volumen que lo justifiquen. ¿Empezasteis con hardware más modesto o con capacidad cloud, con la idea de migrar a on-premise potente cuando las funcionalidades demuestren su rendimiento?. Me parece una de las partes difíciles de este viaje, a nosotros por lo menos nos pasa.
Y por último, la estrategia de una especie de "cata a ciegas" de productos que describes, replicar en Qwen lo que ya hacéis con Claude y cambiar solo cuando el resultado es satisfactorio, me parece genial, entiendo que para cada caso de uso hacéis diversas iteraciones y aproximaciones, comparando el resultado de los dos modelos, ¿os habéis encontrado para alguna funcionalidad en un punto de "este no es el camino" y tener de dar marcha atrás o abandonar?, como se determina ese punto de seguir iterando, o abandonar esta vía y replantear.
Muchas gracias por compartir esta información tan interesante.
saludos
diego