7 min de lectura
La mayoría de los stacks de IA empresariales son máquinas sobreingenierizadas: miles de tokens en el prompt del sistema, pipelines RAG de múltiples etapas, reglas de negocio hardcodeadas y revisiones manuales de código como cuello de botella. Esto funcionaba cuando los modelos tenían una precisión del 85 por ciento. Con cada nueva generación de modelos, el equilibrio se desplaza, y la complejidad se convierte en un freno. Cuatro puntos concretos de auditoría muestran dónde los equipos de TI deben simplificar ahora.
Lo más importante en breve
- La «Bitter Lesson» (Lección Amarga) de Rich Sutton (2019) también aplica a los stacks de IA: el andamiaje diseñado por humanos pierde frente a la inteligencia del modelo, tan pronto como la escalabilidad entra en juego (Sutton, University of Alberta).
- Las ventanas de contexto han crecido de 4.000 tokens (GPT-3, 2020) a más de 1 millón de tokens (2025/26), un factor de 250 en cinco años. Esto cambia radicalmente las arquitecturas de recuperación.
- Los prompts de sistema procedimentales con más de 3.000 tokens pueden acortarse entre un 30 y un 50 por ciento en modelos más potentes, sin pérdida de calidad (Anthropic Prompt Engineering Guide, 2025).
- Google Big Sleep (Project Zero + DeepMind) encontró en octubre de 2024 una verdadera vulnerabilidad Zero-Day en SQLite, el primer caso documentado públicamente de un agente de IA que descubrió una brecha de seguridad desconocida en software utilizado en producción.
- Los modelos de frontera cuestan entre 5 y 10 veces más por token en comparación con las generaciones anteriores. Los prompts eficientes no son solo una cuestión de calidad, sino también de costos.
Por qué la escalabilidad fuerza la simplificación
En marzo de 2019, Rich Sutton, profesor de la Universidad de Alberta y cofundador de la investigación moderna de aprendizaje por refuerzo, publicó un ensayo titulado «The Bitter Lesson». Su tesis: a lo largo de más de 70 años de historia de la IA, los métodos que se basan en el poder bruto de cálculo han ganado consistentemente contra los métodos que incorporan el conocimiento humano del dominio. No porque el conocimiento humano sea inútil, sino porque no se mantiene al ritmo de la escalabilidad.
Seis años después, se observa el mismo patrón al trabajar con modelos de lenguaje grandes. Los equipos construyen sistemas alrededor de los modelos: cadenas de indicaciones de varios niveles, árboles de decisión codificados en el sistema, tuberías de recuperación curadas manualmente. Esto tenía sentido cuando GPT-3 operaba con 4,000 tokens de contexto y alucinaba en cada tercera consulta. Pero los modelos se han mejorado más rápido que los sistemas que los rodean.
Las leyes de escalabilidad de Kaplan et al. (2020, arXiv:2001.08361) y los resultados de Chinchilla de Hoffmann et al. (2022, arXiv:2203.15556) han demostrado: el rendimiento del modelo aumenta de manera predecible con el cálculo, los datos y el número de parámetros. Lo que esto significa para la práctica: cada nueva generación de modelos hace que una parte de la complejidad diseñada por humanos sea redundante. No todo. Pero lo suficiente como para cuestionar regularmente las arquitecturas existentes.
Audit 1: Prompt-Scaffolding entschlacken
La primera pregunta para cualquier pila de KI productiva: ¿Cuánto del sistema de indicaciones describe el resultado deseado y cuánto describe el camino hacia él? En la mayoría de los sistemas de producción, la proporción es de 20 a 80. Veinte por ciento objetivo, ochenta por ciento procedimiento.
Un ejemplo típico del soporte al cliente: Un sistema de indicaciones de 3.000 tokens que prescribe la clasificación de intenciones en 14 categorías, define pasos de recuperación, fuerza verificaciones de alucinaciones y establece formatos de respuesta. Esta especificación procedimental era necesaria porque los modelos anteriores omitían pasos sin instrucciones explícitas. Con modelos más potentes, se convierte en una restricción: el modelo sigue el camino prescrito, aunque conoce uno mejor.
El guía de ingeniería de indicaciones de Anthropics lo formula claramente: solo agregar complejidad si demuestra mejores resultados. La documentación de Codex de OpenAI va en la misma dirección: describir el objetivo, no el camino.
| Aspekt | Prozeduraler Prompt (Status quo) | Outcome-Prompt (Zielzustand) |
|---|---|---|
| Intent | «Klassifiziere in 14 Kategorien, dann route zum Handler» | «Löse das Anliegen des Kunden» |
| Retrieval | «Top 5 KB-Artikel via Hybrid Search, alpha=0.7» | «Nutze unsere Knowledge Base und Policies» |
| Validation | «Prüfe auf halluzinierte URLs, dann Faktencheck» | «Antwort muss unserer Rückgabe-Policy entsprechen» |
| Token-Bedarf | ~3.000 Token | ~800 Token |
La recomendación: revisar cada indicación línea por línea. Para cada instrucción, preguntar: ¿Esto está aquí porque el modelo lo necesita o porque pensé que lo necesitaba? Quien quiera preparar su Developer-Experience-Stack para la próxima generación de modelos, comienza aquí.
Audit 2: Simplificar la arquitectura de recuperación
RAG no está muerto. Pero la pregunta de quién controla la lógica de recuperación cambia. Con una ventana de contexto de 4.000 tokens, el chunking preciso, el reordenamiento y la filtración eran esenciales para sobrevivir. Con un millón de tokens, el cálculo es diferente.
Si un modelo puede procesar 500 páginas de texto al mismo tiempo, la pregunta «¿Cuáles 5 fragmentos son relevantes?» pierde importancia. En su lugar, la pregunta «¿Qué repositorio o colección de documentos recibe el modelo?» se convierte en la decisión arquitectónica decisiva. La inteligencia de recuperación se desplaza del código de la pipeline al modelo.
El desarrollo de las ventanas de contexto lo ilustra: GPT-3 comenzó en 2020 con 4.096 tokens. GPT-4 llegó en 2023 con 128.000 tokens. Gemini de Google alcanzó un millón de tokens en 2024. A principios de 2026, varios modelos trabajan con ventanas de contexto más allá del millón. Esto no es un crecimiento lineal; es un factor de 250 en cinco años. Cada decuplicación de la ventana de contexto hace que una parte de la pipeline de recuperación sea redundante, ya que el modelo puede procesar más datos brutos directamente.
Esto no significa que las bases de datos vectoriales desaparezcan. Para corpora más allá de la ventana de contexto, la recuperación sigue siendo necesaria. Pero la lógica se simplifica: en lugar de pipelines de reordenamiento multietapa con umbrales ajustados manualmente, cada vez es más suficiente presentar al modelo un repositorio bien organizado y buscable y dejar la selección al modelo. El esfuerzo se desplaza de la pipeline a la estructura del documento.
Para los equipos de Platform-Engineering, que equipan plataformas internas de desarrolladores con asistentes de IA, esto tiene una consecuencia práctica: inviertan en la calidad y estructura de su documentación en lugar de en la complejidad de su pipeline de recuperación. Un wiki Confluence bien organizado o un repositorio Git bien estructurado aporta más que un modelo de reordenamiento sofisticado.
Audit 3: Hardcoded Domain Knowledge vs. Modell-Inferenz
¿Cuántas reglas de negocio tienen codificadas en los prompts del sistema? Cuéntelas. Luego pregúntense por cada una: ¿Puede el modelo deducir esta regla del contexto si tiene acceso a los documentos relevantes?
Un ejemplo: Un sistema de informes que define el estilo de casa para informes de clientes como una instrucción de 15 líneas en el prompt. Estilo, estructura, reglas de formulación, formato. Un modelo potente deduce todo esto a partir de un solo informe de ejemplo con mayor precisión que a partir de una descripción abstracta de la regla. Este es exactamente el mecanismo que describe Sutton: Las leyes de escalabilidad no hacen que el conocimiento codificado por humanos sea inútil, pero cada vez más redundante, porque el modelo puede deducirlo por sí mismo.
«Quien en 2024 necesitó un prompt de sistema de 3.000 tokens, en 2026 obtendrá mejores resultados con 800 tokens – siempre y cuando describa el objetivo en lugar del camino y dé acceso al modelo en lugar de reglas.»
– cloudmagazin Redaktionsbewertung
Lo que debe seguir codificado: Reglas de cumplimiento que no deben violarse (políticas de devolución, disposiciones regulatorias). Límites de seguridad en los que una violación es inaceptable. Todo lo demás merece una prueba: prompt con regla vs. prompt sin regla. Si los resultados son igual de buenos, la regla puede eliminarse.
Audit 4: Un Eval-Gate en lugar de muchos checkpoints
Los pasos de evaluación intermedia en las pipelines de IA fueron una reacción a modelos poco fiables: verificar después de cada paso si el resultado intermedio es correcto antes de iniciar el siguiente. ¿Intención clasificada? Check. ¿Recuperación relevante? Check. ¿Respuesta libre de alucinaciones? Check.
En modelos que funcionan correctamente en el 99 por ciento de los casos, la relación costo-beneficio cambia. Cada verificación intermedia cuesta latencia, tokens y complejidad. Si el resultado final es correcto en la gran mayoría de los casos, un único Eval-Gate integral al final es más eficiente que cinco verificaciones parciales en el camino.
Para el desarrollo de software, esto es especialmente relevante. Googles Big Sleep (una colaboración entre Project Zero y DeepMind) descubrió en octubre de 2024 una vulnerabilidad de desbordamiento de búfer de pila (Stack-Buffer-Underflow) previamente desconocida en SQLite, el primer caso documentado públicamente de un agente de IA que encontró una verdadera vulnerabilidad Zero-Day en software de código abierto ampliamente utilizado. Si los modelos de IA pueden encontrar vulnerabilidades que Security-Researcher experimentados han pasado por alto, entonces también pueden encargarse de revisiones de código y pruebas de regresión.
La recomendación práctica: un script de Eval al final de la pipeline que verifique de manera integral los requisitos funcionales, no funcionales y los casos límite. Si todas las pruebas se superan, el resultado se aprueba. Si no, vuelve al modelo. Sin pasos intermedios manuales, sin revisión humana como cuello de botella.
Costes y enrutamiento multi-modelo
Los modelos de frontera son caros. La plataforma NVIDIA GB200 (arquitectura Blackwell, presentada en la GTC en marzo de 2024) y sus sucesores GB300 (Blackwell Ultra, GTC marzo 2025) elevan los costes de entrenamiento a cientos de millones de euros por modelo. Esto se refleja en los costes de inferencia: los modelos de frontera cuestan entre 5 y 10 veces más por token en comparación con la generación anterior. Quien envíe todo su tráfico a través de un modelo de frontera quema presupuesto. Quien delegue todo al modelo más económico pierde calidad en tareas complejas.
La solución es el enrutamiento multi-modelo: delegar tareas simples (clasificación, extracción, formateo) a modelos económicos y redirigir tareas complejas (razonamiento, generación de código, auditorías de seguridad) a modelos de frontera. La capacidad de enrutar problemas correctamente se convertirá en 2026 en una de las competencias más importantes en arquitecturas API-First.
La simplificación de los prompts no es solo una cuestión de calidad, sino también de costes. Un prompt de sistema de 3.000 tokens que se reduce a 800 tokens ahorra, con mil llamadas a la API al día, 2,2 millones de tokens. A precios de frontera de 15 euros por millón de tokens de entrada, eso supone 33 euros al día, casi 1.000 euros al mes. Simplificación y eficiencia de costes van de la mano.
Conclusión
La lección amarga no solo es válida para los investigadores de inteligencia artificial. Afecta a cualquier equipo que despliegue modelos de IA en producción. Cuatro auditorías -estructuración de indicaciones (prompt-scaffolding), arquitectura de recuperación, conocimiento especializado codificado directamente y tuberías de evaluación (evaluación-pipelines)- muestran claramente dónde la complejidad se convierte en un freno. Los modelos mejoran más rápido de lo que la mayoría de los sistemas a su alrededor logran adaptarse. Quien simplifique ahora, estará preparado cuando llegue la próxima generación. Quien siga aferrado a su indicación de 5.000 tokens desarrollada durante años, descubrirá que una sola línea produce mejores resultados.
Preguntas frecuentes
¿Qué dice exactamente la «Bitter Lesson» de Rich Sutton?
Rich Sutton argumentó en 2019 que, a lo largo de más de 70 años de historia de la IA, los métodos que se basan en la escalabilidad del poder de cálculo han ganado consistentemente contra los métodos que incorporan el conocimiento del dominio humano. Para los stacks de IA, esto significa: en lugar de agregar cada vez más reglas y andamios, se debe dar más libertad al modelo y medir los resultados.
¿Debo eliminar todo mi sistema de indicaciones?
No. Las reglas de cumplimiento, los límites de seguridad y la lógica comercial no negociable permanecen en la indicación. Lo que puede eliminarse: las secuencias procedimentales que le indican al modelo el camino a seguir en lugar de definir el objetivo. La prueba es sencilla: comparar la indicación con y sin la regla. ¿No hay diferencia en la calidad? Eliminar la regla.
¿Es innecesario RAG con grandes ventanas de contexto?
No necesariamente. Para corpora que exceden la ventana de contexto, sigue siendo necesario el recuperación. Pero la lógica de recuperación se simplifica: en lugar de pipelines de reordenación multietapa, cada vez es suficiente darle al modelo un repositorio bien estructurado y dejar que el modelo se encargue de la selección. La inversión se desplaza de la complejidad de la pipeline a la calidad de los documentos.
¿Cómo encontró Google Big Sleep la vulnerabilidad de SQLite?
Big Sleep es una colaboración entre Google Project Zero y Google DeepMind. En octubre de 2024, el agente de IA identificó un desbordamiento de búfer de pila en SQLite – una vulnerabilidad que existía en una rama de desarrollo y fue encontrada antes de un lanzamiento oficial. Fue el primer caso públicamente documentado en el que un agente de IA descubrió una vulnerabilidad de seguridad desconocida en un software ampliamente utilizado.
¿Cómo inicio un auditoría de indicaciones para mi stack de IA existente?
Tres pasos: Primero, revisar cada indicación del sistema línea por línea y marcar cada instrucción como «Objetivo» o «Proceso». Segundo, eliminar todas las instrucciones de proceso individualmente y medir la calidad del resultado con un conjunto de evaluación. Tercero, solo volver a agregar las instrucciones cuya eliminación produce resultados mediblemente peores. La mayoría de los equipos descubren que el 30 al 50 por ciento de las instrucciones de proceso ya no tienen un impacto medible.
Selección editorial
Fuente de la imagen: KI-generiert via Cloudflare FLUX.2 / cloudmagazin Redaktion