El año pasado, casi todos los operadores de almacén con los que hablé me hicieron la misma pregunta: queremos convertir nuestros SOP, manuales de equipos y órdenes de trabajo históricas en una base de conocimiento interna con un bot de preguntas y respuestas — ¿vamos con RAG o afinamos un modelo de lenguaje grande? Parece una decisión tecnológica, pero por debajo hay tres libros contables: qué tan rápido cambia tu conocimiento, cuánto cuesta una respuesta equivocada y qué enfoque puede sostener de verdad tu equipo.
Mirando primero el panorama: según mi revisión de informes públicos del sector y casos de estudio de proveedores, entre los proyectos empresariales de preguntas y respuestas sobre bases de conocimiento que realmente salieron en producción entre 2024 y 2026, RAG (generación aumentada por recuperación) se ha convertido en la arquitectura dominante de facto. La técnica fue introducida por Meta en 2020 (Lewis et al.), y la idea central es simple: en lugar de meter el conocimiento a presión en los parámetros del modelo, el modelo primero recupera documentos relevantes y luego genera respuestas basadas en lo que recuperó. El fine-tuning toma el otro camino: seguir entrenando el modelo con tus propios datos de preguntas y respuestas para que el conocimiento quede «prensado» en los parámetros. Ambos caminos funcionan, pero sus estructuras de costos, perfiles de riesgo y límites son totalmente distintos — y el precio de equivocarse solo aparece unos seis meses después del lanzamiento.
Cómo se ve realmente RAG en un almacén: la trazabilidad es su sangre
A principios de 2025, un almacén 3PL en el Inland Empire de California me mostró su proyecto. La instalación tiene unos 120,000 pies cuadrados, atiende a más de 40 marcas de comercio electrónico y había acumulado decenas de miles de órdenes de trabajo históricas y registros de excepciones en su WMS, además de varios cientos de páginas de SOP. Su enfoque fue RAG de manual: fragmentar los documentos, vectorizarlos y, al consultar, recuperar los 5–8 pasajes más relevantes para que el LLM componga una respuesta a partir de esos pasajes — con cada respuesta llevando sus fuentes, hasta la sección del SOP o el número específico de orden de trabajo.
Ese diseño de «fuentes citadas» es el punto central. Un almacén es un entorno fuertemente impulsado por el cumplimiento y la auditoría: cuando un inspector de calidad pregunta «¿cuál es la proporción de muestreo para este lote de entrada?», no quiere una respuesta bonita — quiere una respuesta que pueda quedar en el registro y rastrearse si algo sale mal. Las respuestas de RAG traen procedencia por construcción; cuando una es incorrecta, puedes señalar qué documento se quedó obsoleto y corregir el documento, no el modelo. Seis meses después del lanzamiento, el ciclo de incorporación de nuevos empleados de este 3PL se había reducido de unas tres semanas a unos diez días. Una advertencia: esa es su métrica interna de negocio, y el proceso de capacitación en sí se optimizó en paralelo, así que no todo el mérito es de RAG — pero la dirección es clara: el conocimiento se volvió encontrable y verificable.
RAG tiene otra ventaja que importa enormemente en entornos de almacén: las actualizaciones de conocimiento significan «cambiar documentos», no «reentrenar». Cuando se revisa un SOP, re-fragmentas y re-indexas; tiene efecto en minutos. Para almacenes cuyo conocimiento cambia constantemente, eso es casi decisivo.

El caso de fracaso del fine-tuning: memorizó la especificación y perdió la fuente
El fine-tuning también tiene sus adoptantes — y sus casos reales de fracaso. A mediados de 2025, un centro de distribución en el este de China quiso «enseñar» a un modelo sus manuales de mantenimiento de equipos y reunió varios miles de pares de preguntas y respuestas para afinarlo. Durante las pruebas, alguien preguntó la carga nominal de un apilador de estanterías concreto, y el modelo respondió con total confianza — y el número estaba mal. La capacidad real era de 1.5 toneladas; dijo 2 toneladas. La investigación posterior encontró que una revisión obsoleta del manual se había colado en los datos de entrenamiento, y el modelo había «memorizado» el error sin saber que lo era.
Ese es el defecto estructural del fine-tuning para bases de conocimiento: una vez que el conocimiento se comprime en parámetros, no es rastreable ni corregible localmente. Cuando encuentras un error, no puedes simplemente editar un documento como te permite RAG — tienes que re-preparar datos, reentrenar y re-validar todo. Peor aún, un modelo afinado expresa sus errores exactamente con la misma confianza que sus respuestas correctas. En un almacén, donde una respuesta equivocada puede herir personas, dañar mercancía o romper el cumplimiento, esa confianza inexplicable es la propiedad más peligrosa de todas.
Para ser justos, el fine-tuning tiene un lugar legítimo — solo que no está en memorizar datos. Sobresale en cambiar el comportamiento del modelo: fijar formatos de salida, unificar el tono de voz, aprender un patrón de razonamiento específico. Si tu necesidad es «haz que el modelo hable como el manual de servicio de nuestra empresa», el fine-tuning encaja bien. Si tu necesidad es «haz que el modelo recuerde tres mil páginas de manuales», estás usando la herramienta equivocada.
RAG vs Fine-tuning: una matriz de decisión
Reuniendo todo, aquí hay una matriz de decisión que uso. Mapea tu propia situación sobre estas cuatro dimensiones y la respuesta suele surgir sola:
| Dimensión | Inclínate por RAG | Inclínate por fine-tuning |
|---|---|---|
| Frecuencia de actualización del conocimiento | Alta — cambios semanales o incluso diarios (SOP, reglas de promo) | Baja — conocimiento estable por años (principios de equipos, regulaciones) |
| Necesidades de precisión y trazabilidad | Alta — respuestas erróneas son costosas, fuentes deben citarse (calidad, seguridad) | Media a baja — el estilo importa más que la precisión factual |
| Volumen de datos | Muchos documentos pero pocos pares de preguntas y respuestas (RAG come documentos directamente) | Decenas de miles de pares de preguntas y respuestas de alta calidad disponibles para entrenar |
| Costo y equipo | Arranque ligero, pagas por recuperación, el mantenimiento es solo cambiar documentos | Costo GPU del entrenamiento inicial más reentrenamientos repetidos, más gastos de gestión de versiones |
La dimensión del costo merece su propio cálculo. Usando precios públicos de la nube como referencia, un fine-tuning completo de un modelo abierto de clase 7B suele costar entre cientos y unos pocos miles de dólares en alquiler de GPU (consulta el sitio oficial de cada proveedor para los precios actuales) — pero eso es solo para una corrida de entrenamiento. El costo real viene después: cada ciclo de actualización del conocimiento exige en teoría reentrenar, re-probar y re-desplegar una nueva versión del modelo, lo que se convierte en un gasto anual recurrente. La curva de costos de RAG es invertida: construir el pipeline de recuperación requiere esfuerzo de ingeniería inicial, pero el mantenimiento diario es solo «cambiar documentos», con un costo marginal muy bajo. Una curva está cargada al inicio, la otra al final — la comparación que importa es el total a tres años, no la factura del primer mes.
La tesis contraintuitiva: para almacenes que cambian rápido, el fine-tuning es un activo que se deprecia
Aquí va un juicio contraintuitivo que vale la pena decir claramente: para almacenes cuyo conocimiento se actualiza con frecuencia, el fine-tuning no es una «inversión única» — es un activo que se deprecia. Cada revisión de SOP y cada cambio de equipo vuelve obsoleta parte de la «memoria» del modelo afinado anterior, y no puedes decir cuál parte. Así que te ves forzado a un ciclo de reentrenar–reprobar–redesplegar, gastando cada vez más mientras el modelo persigue por siempre un objetivo en movimiento. RAG se comporta al revés en exactamente este escenario: cuanto más nuevo, más fragmentado y más disperso sea el conocimiento, mayor será la ventaja de la arquitectura de recuperación.
Mi lectura de la tendencia, entonces: en los próximos dos o tres años, la forma por defecto de las bases de conocimiento de almacén será híbrida — RAG para el qué (hechos, trazabilidad, actualizaciones en tiempo real) y fine-tuning ligero para el cómo (formato, tono, fraseología del sector). Los dos enfoques nunca fueron uno u otro; son una división del trabajo.
Una pregunta merece observación más larga, eso sí: elijas el camino que elijas, la calidad de la base de conocimiento en sí es el techo. SOP vagos, registros de órdenes de trabajo con campos faltantes, manuales de equipos con revisiones enredadas — ningún pipeline de RAG ni ninguna corrida de fine-tuning puede arreglar problemas de «gobernanza del conocimiento». Detrás del debate de arquitectura, la verdadera línea divisoria puede ser esta: ¿tu almacén tiene de verdad conocimiento que valga la pena que una IA aprenda? Esa es una pregunta que cada empresa que construye una base de conocimiento tendrá que responderse a sí misma.
Por Dr. Chen, investigador de cadena de suministro
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.






