--- type: BCV asset_id: BCV-ContextEngineering-MemoriaVirtual-v02 version: v02 status: Operativo owner: Victor Heredia sherpa_owner: Jay fecha_creacion: 2026-05-20 fecha_ultima_actualizacion: 2026-06-08 intellbank: IB-EL-EmpowerLabs subbank: BC-EL-BrainCodes bc_type: BCV source_name: Context Engineering y Memoria Virtual source_type: CORPUS_SINTÉTICO materials_used: - tipo: blog_post referencia: "Harrison Chase (LangChain) — 'The Rise of Context Engineering' (2025-06-23). blog.langchain.com" - tipo: podcast referencia: "Harrison Chase — Sequoia Capital 'Context Engineering Our Way to Long-Horizon Agents' (2026-01)" - tipo: paper_academico referencia: "Packer et al. — 'MemGPT: Towards LLMs as Operating Systems' (arXiv:2310.08560, 2023-10)" - tipo: paper_academico referencia: "Liu et al. — 'Lost in the Middle: How Language Models Use Long Contexts' (arXiv:2307.03172, 2023, TACL 2024)" - tipo: paper_academico referencia: "Asai et al. — 'Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection' (arXiv:2310.11511, 2023)" - tipo: paper_academico referencia: "Wang et al. — 'Recursively Summarizing Enables Long-Term Dialogue Memory in LLMs' (arXiv:2308.15022, ICLR 2025)" - tipo: tweet_referencia referencia: "Andrej Karpathy — tweet sobre context engineering vs. prompt engineering (2025-06-25, x.com/karpathy/status/1937902205765607626)" - tipo: experimento_benchmark referencia: "Greg Kamradt — 'Needle in a Haystack' test (github.com/gkamradt, 2023-11)" - tipo: paper_academico referencia: "Li et al. — 'LaRA: RAG vs Long-Context LLMs – No Silver Bullet' (ICML 2025, proceedings.mlr.press/v267/li25dv.html)" - tipo: protocolo_tecnico referencia: "Anthropic — Model Context Protocol (MCP), noviembre 2024" distillation_date: 2026-06-08 distiller_version: TP-XX-BCDistillerEngine-Portable-v02 distilled_by: Jay (investigación primaria directa + agente de investigación paralelo) confidence: lenses: muy_alta models: muy_alta principles: muy_alta rules: alta algorithms: alta skills: alta tacit_patterns: alta readiness_score: ⭐⭐⭐⭐ coverage_note: | Corpus sintético que integra la investigación académica y de practitioners sobre context engineering a junio 2026. Cobertura alta en frameworks de Harrison Chase (LangChain), MemGPT/Letta, y los papers fundacionales (Lost in the Middle, Self-RAG, Recursive Summarization). Consenso verificado en el debate RAG vs. Long Context (ICML 2025 LaRA paper). Menor cobertura en implementaciones propietarias no publicadas de OpenAI y Google. usage_modes: [VALIDACIÓN, AUDITORÍA, CREACIÓN, DISEÑO_DE_SISTEMAS] upgrade_from: BCV-ContextEngineering-MemoriaVirtual-v01 upgrade_notes: | v02 reescritura completa desde anatomía v00 ad-hoc a anatomía BCV v02. Fuentes actualizadas y verificadas con investigación primaria directa (junio 2026). Corrección crítica: Harrison Chase no acuñó "context engineering" — Tobi Lütke y Andrej Karpathy la popularizaron simultáneamente en junio 2025. Self-RAG ≠ Agentic RAG: se distinguen claramente en este v02. Content Architecture añadida per spec BCV (Layer 0). --- ## Asset Header - **Asset ID:** BCV-ContextEngineering-MemoriaVirtual-v02 - **Tipo:** BCV — Brain Code de Contenido/Corpus Sintético - **Fuente:** Corpus de Context Engineering (Chase/LangChain + MemGPT + papers fundacionales) - **Readiness:** ⭐⭐⭐⭐ - **Upgrade desde:** BCV-ContextEngineering-MemoriaVirtual-v01 - **Última actualización:** 2026-06-08 --- > **INSTRUCCIÓN DE USO** > Este BCV activa el sistema de ideas del corpus de Context Engineering sobre cualquier input de diseño de sistemas de IA. > No es la voz de Harrison Chase — es el marco de ideas del campo. > Secuencia: Layer 0 (entender el campo) → A (percibir el problema) → B (evaluar) → C (decidir arquitectura) → D (ejecutar) > Layer CAL activo en Board Mode para separar claims verificados de claims populares no verificados. --- ## LAYER M — METADATA *Ver frontmatter superior.* --- ## LAYER 0 — IDENTIDAD DEL CONTENIDO ### 0.1 Frase Identitaria Context Engineering es el diseño de sistemas dinámicos que ensamblan la información correcta, en el formato correcto, en el momento correcto — de modo que un LLM pueda *plausiblemente* completar la tarea. No es la redacción de un prompt; es la arquitectura de la memoria virtual de la inteligencia. ### 0.2 La Pregunta Central ¿Cómo diseñas el sistema de memoria y recuperación que rodea un LLM para que tenga exactamente lo que necesita cuando lo necesita — sin desperdiciar tokens en ruido, sin perder información crítica en el medio del contexto, y sin colapsar cuando la tarea se extiende más allá de la ventana? ### 0.3 Salience Architecture — Qué Activa Este Marco **Señal 1: La tarea es más larga que la ventana de contexto** - *Disparador:* El LLM necesita operar sobre un corpus que excede su límite de tokens, o necesita mantener coherencia a lo largo de múltiples sesiones. - *Respuesta del marco:* Activar gestión de memoria jerárquica (MemGPT). Decidir qué va en Core Memory, qué en Recall Memory, qué en Archival Memory. **Señal 2: El agente está alucinando o dando respuestas inconsistentes** - *Disparador:* Fallos de calidad que no son del modelo base sino del contexto que recibe. - *Respuesta del marco:* Diagnóstico de falla de contexto: ¿el problema es relevancia (ruido), posición (lost in the middle), o frescura (datos obsoletos)? **Señal 3: El costo de inferencia escala con el volumen, no con la calidad** - *Disparador:* Sistemas donde se inyecta todo el corpus disponible sin filtrado ("dump and pray"). - *Respuesta del marco:* Context pruning. Ranker models. Recursive summarization. El objetivo es maximizar señal-ruido, no maximizar tokens. ### 0.4 Content Architecture — Mapa de Fuentes y Estructura del Corpus El campo de Context Engineering es un corpus sintético construido desde tres corrientes convergentes: **Corriente 1: Practitioners / Engineering Discourse (2025)** - Harrison Chase (LangChain): definición operativa, 5 patrones de context engineering, distinction vs. prompt engineering. - Andrej Karpathy: popularización del término "context engineering" y el marco LLM-as-CPU/context-as-RAM. - Tobi Lütke (Shopify): primer uso documentado del término en comunicaciones internas (abril 2025). **Corriente 2: Research académico fundacional (2023)** - MemGPT (Packer et al.): la formalización del LLM como OS, la arquitectura de memoria jerárquica (main context = RAM, external storage = disk). - Lost in the Middle (Liu et al.): prueba empírica de que la posición de la información dentro del contexto determina su recuperabilidad. - Self-RAG (Asai et al.): el modelo que decide cuándo recuperar, cuándo ignorar lo recuperado, y cuándo reformular. - Recursive Summarization (Wang et al.): el mecanismo para mantener memoria de largo plazo sin expandir la ventana. **Corriente 3: Debate de infraestructura (2024-2026)** - RAG vs. Long Context: el debate que Gemini 1.5 (1M tokens, 2024) detonó, resuelto por LaRA/ICML 2025 como "no hay bala de plata — depende del caso de uso". - Anthropic MCP: el protocolo estándar de integración de contexto (nov 2024), adoptado por OpenAI (marzo 2025). - Agentic RAG: el patrón arquitectural donde el agente controla el loop de recuperación como una tool, no como un paso pre-fijo. ### 0.5 Aportación Única en Contexto **Lo que este corpus aporta que no estaba antes:** - Renombra el problema: "prompt engineering" describía la redacción de texto estático. "Context engineering" nombra correctamente el problema actual: diseñar sistemas *dinámicos* de ensamblaje de información. - Formaliza la jerarquía de memoria: la distinción Core / Recall / Archival (MemGPT) da un modelo mental concreto para diseñar agentes de larga duración. - Da base empírica a la intuición del posicionamiento: "Lost in the Middle" convierte en dato la sospecha de que poner información crítica en el centro del contexto es un error de diseño. - Distingue Self-RAG de RAG estándar: la diferencia entre recuperar siempre vs. recuperar condicionalmente es una decisión de arquitectura con impacto masivo en calidad y costo. **Lo que NO aporta este corpus:** - No resuelve el problema de recuperación semántica perfecta — eso depende de la calidad de los embeddings. - No define cuándo usar long context vs. RAG en contextos específicos de negocio — LaRA/ICML 2025 confirma que no hay respuesta universal. - No provee benchmarks en dominios especializados (médico, legal, código) — los papers son generales. ### 0.6 Conexiones Críticas - **PRERREQUISITOS:** [LLM Architecture / Transformer attention mechanism] → El fenómeno "Lost in the Middle" es consecuencia directa de cómo funciona la atención en transformers. Sin entender el mecanismo, las heurísticas de posicionamiento parecen superstición. - **PRERREQUISITOS:** [Vector databases / Embedding models] → El "Archival Memory" de MemGPT y el RAG estándar dependen de la calidad de los embeddings. Context Engineering no resuelve mala indexación. - **CONTRASTES:** [Fine-tuning] → Fine-tuning embebe conocimiento en los pesos del modelo; context engineering lo inyecta dinámicamente en cada llamada. Son estrategias complementarias, no sustitutas. Fine-tuning para comportamiento estable; context engineering para conocimiento actualizable. - **COMPLEMENTOS:** [Anthropic MCP] → MCP estandariza cómo los sistemas de context engineering se conectan a fuentes de datos externas. Es la infraestructura de integración que permite que los patrones de context engineering escalen. - **CONTINUADORES:** [Agentic RAG / LangGraph / LlamaIndex AgentQueryEngine] → El patrón Agentic RAG implementa los principios de MemGPT y Self-RAG en frameworks de producción. ### 0.7 Mapa de Frontera | Área del BCV | Frontera / Limitación | Lo que hay más allá | Modo de uso combinado | |:---|:---|:---|:---| | Context Engineering (input side) | No aborda la *calidad del razonamiento* del LLM una vez que tiene el contexto correcto | Chain-of-thought, scratchpad reasoning, structured outputs | Combinar con frameworks de razonamiento para cubrir ambos lados del problema | | Jerarquía de memoria MemGPT | Asume que la categorización Core/Recall/Archival es estática — pero las fronteras cambian con el contexto de la tarea | Adaptive memory classification | Cuando la tarea cambia radicalmente, revisar si la clasificación de memoria sigue siendo válida | | RAG vs. Long Context | Sin respuesta universal — depende de 4 variables (capacidades del modelo, longitud de contexto, tipo de tarea, características de recuperación) | LaRA/ICML 2025 framework de routing | Usar LaRA como decision tree antes de arquitectar el sistema | | Self-RAG (trained behavior) | Requiere fine-tuning del modelo — no es un patrón que se aplica a cualquier LLM | Agentic RAG (arquitectural) | Cuando no hay acceso al modelo para fine-tuning, usar Agentic RAG como alternativa arquitectural | > Mapa actualizado al: 2026-06-08. Próxima revisión: +12 meses (2027-06). --- ## CAPA A — PERCEPCIÓN: CÓMO VE ESTE MARCO ### A1 Cognitive Lenses Los lentes definen cómo el marco de Context Engineering diagnostica cualquier problema de sistema de IA. --- **LENTE 1: El Contexto como Sistema, no como Texto** Context Engineering no pregunta "¿cómo redacto mejor el prompt?" — pregunta "¿qué sistema dinámico necesito para que el LLM reciba exactamente lo correcto en cada llamada?". - Ante un sistema de IA que falla: ¿El problema está en el modelo o en lo que le estamos pasando? - El diagnóstico de Chase: cuando un agente falla, en la mayoría de los casos es porque "the underlying model was not passed the appropriate context to make a good output" — no porque el modelo sea incapaz. - La distinción clave: prompt engineering = redacción estática; context engineering = arquitectura dinámica. *Cita directa verificada:* "Context engineering is building dynamic systems to provide the right information and tools in the right format such that the LLM can plausibly accomplish the task." [Harrison Chase, LangChain blog, 2025-06-23] *Señal de uso:* Cuando el debate está centrado en "cómo redactar mejor el prompt", redirigir hacia "qué sistema dinámico ensambla el prompt en tiempo de ejecución". --- **LENTE 2: El LLM como OS — Jerarquía de Memoria** El LLM no es una caja negra que recibe texto — es una CPU que opera sobre una memoria jerárquica. La ventana de contexto es la RAM: rápida, cara, limitada. La base de datos vectorial es el disco duro: lenta pero vastamente más grande. - La ventana de contexto = RAM activa. Lo que entra aquí determina todo. - El almacenamiento externo = disco. Debe recuperarse deliberadamente. - El agente = el OS que administra el paginado entre RAM y disco. *Fuente académica:* MemGPT (Packer et al., arXiv:2310.08560, 2023): "virtual context management, drawing inspiration from hierarchical memory systems in traditional operating systems which provide the illusion of an extended virtual memory via paging between physical memory and disk." *Señal de uso:* Ante el diseño de cualquier sistema de IA de larga duración, preguntar: "¿Cuál es la jerarquía de memoria? ¿Qué vive en RAM y qué en disco?" --- **LENTE 3: Señal sobre Volumen — Relevancia como Restricción** Inyectar más tokens no produce mejores respuestas. Frecuentemente produce peores. El objetivo del context engineering no es maximizar información — es maximizar señal-ruido. - El anti-patrón dominante: "Dump and Pray" — volcar todo el PDF/documento/histórico y esperar que el modelo lo procese. - La realidad empírica: los modelos pierden atención en el centro de ventanas largas (Liu et al., 2023). Un millón de tokens con 90% de ruido produce peores resultados que 10,000 tokens perfectamente relevantes. - La heurística operativa: cada token que entra al contexto debe "ganarse su lugar" — si no aumenta la probabilidad de completar la tarea correctamente, es ruido. *Cita verificada (Karpathy, 2025-06-25):* "+1 for 'context engineering' over 'prompt engineering'. Doing this right involves task descriptions and explanations, few shot examples, RAG, related data, tools, state and history, compacting." *Señal de uso:* Cuando alguien propone "agregar más información al contexto", preguntar primero: "¿Aumenta la relevancia o solo el volumen?" --- **LENTE 4: Posición como Variable de Diseño** La posición de la información dentro del contexto no es neutral — es una variable de diseño que determina si el modelo la usará. - El hallazgo de "Lost in the Middle" (Liu et al.): la recuperabilidad de información es máxima al inicio y al final del contexto, y se degrada significativamente en el centro — incluso para modelos diseñados explícitamente para contextos largos. - La implicación: las instrucciones críticas y los datos más relevantes deben posicionarse al inicio o al final del prompt. El centro es tierra de nadie. - El "Needle in a Haystack" test (Kamradt, nov 2023) empiriza esto: insertar una frase clave en el centro de 200K tokens produce una caída significativa en la tasa de recuperación. *Evidencia:* "Performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts." [Liu et al., arXiv:2307.03172] *Señal de uso:* Ante el diseño de un prompt con múltiples bloques de información, preguntar: "¿Qué es lo más crítico? ¿Está al inicio o al final?" --- **LENTE 5: Recuperación Condicional vs. Recuperación Automática** El RAG estándar recupera siempre, antes de cada generación, sin importar si la recuperación agrega valor. Self-RAG y Agentic RAG rompen ese supuesto: el sistema decide *cuándo* recuperar, *qué* recuperar, y *si* lo recuperado es útil. - RAG estándar: Recupera → Genera. Simple. Predecible. Ineficiente cuando el modelo ya tiene la respuesta. - Self-RAG: El modelo emite "reflection tokens" para decidir si necesita recuperar, si lo recuperado es relevante, y si su propia generación es buena. Requiere fine-tuning. - Agentic RAG: El agente usa recuperación como una *tool* que llama cuando la necesita. No requiere fine-tuning — requiere arquitectura de agente. *Señal de uso:* Ante un sistema RAG que tiene alta latencia o costos inflados, preguntar: "¿Cuántas de estas recuperaciones eran necesarias? ¿El modelo ya sabía la respuesta?" --- ### A2 Mental Models Los modelos organizan cómo el marco entiende categorías completas de decisiones de arquitectura. --- **MODELO 1: Taxonomía de Memoria MemGPT / Letta** ``` CORE MEMORY (siempre en contexto — "RAM fija") → Instrucciones permanentes del agente (persona, misión, restricciones) → Perfil inmutable del usuario → Estado activo de la tarea actual → Acceso: siempre visible; editable por el agente → Capacidad: limitada por diseño (pocos KB de texto) RECALL MEMORY (historial de conversación buscable — "Disco caché") → Conversaciones pasadas completas → Searchable by semantic query → Acceso: via tool call: search_recall_memory() → Capacidad: miles de conversaciones ARCHIVAL MEMORY (almacenamiento de largo plazo — "Disco frío") → Documentos, datos externos, conocimiento histórico → Vector store (embeddings) → Acceso: via tool call: archival_memory_search() → Capacidad: prácticamente ilimitada SELF-EDITING MECHANISM: → El agente puede llamar write_to_core_memory(), update_user_profile() → No espera que un orquestador externo actualice su memoria → El agente administra su propio contexto ``` *Pregunta de activación:* "¿Este dato debe estar en la RAM del agente (siempre disponible) o debe ser buscado solo cuando sea necesario?" --- **MODELO 2: Los 5 Patrones de Context Engineering (Chase/LangChain)** ``` Patrón 1: INSTRUCCIONES DE TAREA (Prompt Engineering) → Qué debe hacer el agente, cómo debe comportarse → Static or dynamic: puede personalizarse en runtime → Posición recomendada: inicio del prompt Patrón 2: MEMORIA DE CORTO PLAZO (Conversation Memory) → Historial de la conversación actual → Problema: crece linealmente; consume tokens → Solución: Recursive Summarization (comprimir sin perder esencia) Patrón 3: MEMORIA DE LARGO PLAZO (Cross-Session Memory) → Preferencias del usuario, hechos aprendidos, decisiones pasadas → Implementación: retrieval de core memory o archival memory → Activación: al inicio de cada sesión Patrón 4: RECUPERACIÓN (RAG / Retrieval) → Información externa que el modelo no tiene en sus pesos → Variantes: RAG estándar, Self-RAG, Agentic RAG → Filtros críticos: relevancia, frescura, formato Patrón 5: OUTPUT DE TOOLS (Tool Call Results) → Resultados de APIs, bases de datos, code execution → Problema común: resultados muy largos consumen tokens innecesarios → Solución: formatear y comprimir antes de inyectar ``` *Pregunta de activación:* "¿Qué patrones de los 5 necesita este sistema? ¿Cuál es el orden de prioridad por impacto?" --- **MODELO 3: RAG vs. Long Context — El Árbol de Decisión (LaRA/ICML 2025)** ``` ¿El corpus cambia frecuentemente? → Sí: RAG (más eficiente para contenido dinámico) → No: continúa... ¿El corpus cabe cómodamente en la ventana? → Sí: Long Context (mejor calidad en razonamiento whole-corpus) → No: RAG (única opción práctica) ¿El costo de inferencia es una restricción fuerte? → Sí: RAG (80-90% más barato en llamadas repetidas) → No: continúa... ¿La tarea requiere razonamiento cross-document / multi-hop? → Sí: Long Context (mejor en síntesis de múltiples fuentes) → No: RAG suficiente Resultado: No hay bala de plata. El routing óptimo depende de la intersección de estas 4 variables por caso de uso. ``` *Fuente:* "The optimal choice between RAG and LC depends on a complex interplay of model capabilities, context length, task type, and retrieval characteristics." [LaRA, Li et al., ICML 2025] --- **MODELO 4: Ciclo de Vida del Token — El Proceso de Context Engineering** ``` 1. INGESTA → Capturar el input del usuario y el estado del sistema → Identificar qué tipo de tarea es (retrieval? reasoning? generation?) 2. RECUPERACIÓN SEMÁNTICA → Buscar en archival memory los datos relevantes → Criterios: relevancia semántica + frescura + autoridad de fuente 3. PODA (Pruning) → Eliminar duplicados → Comprimir fragmentos largos → Remover contexto que no aumenta la probabilidad de éxito 4. RANKING → Ordenar de lo más crítico a lo menos crítico → Posicionar lo más crítico al inicio o al final (anti-lost-in-middle) 5. ENSAMBLAJE E INYECCIÓN → Construir el prompt final con el orden correcto → Verificar que no excede el límite de la ventana 6. EVALUACIÓN POST-GENERACIÓN → ¿La respuesta es factualmente correcta? (Self-RAG: critique step) → ¿El agente necesita actualizar su memoria con lo aprendido? 7. ACTUALIZACIÓN DE MEMORIA → Resumir la interacción (recursive summarization) → Actualizar core memory si hay nuevos hechos permanentes → Archivar en recall memory para referencia futura ``` --- **MODELO 5: Recursive Summarization — Memoria sin Tokens Infinitos** ``` Problema: Una conversación de 100 turnos = 50,000 tokens. La ventana no aguanta. La solución naive (truncar) pierde contexto crítico. Solución (Wang et al., 2023, ICLR 2025): Nivel 1: Resumir cada bloque de N turnos → "En los últimos 10 turnos: el usuario definió el alcance del proyecto X, aprobó el plan Y, rechazó la opción Z por motivo W." Nivel 2: Resumir resúmenes cuando acumulan → "En la sesión 1-5: establecimos los objetivos. En la sesión 6-10: iteramos sobre el diseño." Nivel 3: El meta-resumen → "Historial del proyecto: [resumen compacto de todo]" Resultado: El agente mantiene coherencia a lo largo de meses sin que el contexto explote. La esencia persiste; los detalles se comprimen. ``` --- ### A3 Anchor Cases Casos concretos que los practitioners de context engineering citan como fuente de sus frameworks. --- **CASO 1: AlexNet en GPU — La Plataforma Latente del Context Engineering** Cuando MemGPT (2023) propuso el LLM-as-OS, el framework era análogo a la GPU que NVIDIA diseñó para gaming pero que resultó ser perfecta para deep learning. Las GPUs tenían las propiedades físicas correctas antes de que alguien lo demandara. El contexto window como RAM/disco tiene la misma estructura: una analogía que ya existía en la arquitectura de OS pero que nadie había aplicado formalmente a LLMs hasta MemGPT. *Lo que revela:* El mejor framework no siempre es uno nuevo — es la traducción correcta de un framework maduro (OS memory management) a un dominio nuevo (LLM context management). --- **CASO 2: "Dump and Pray" — El Anti-Patrón Fundacional** El anti-patrón más común en sistemas de IA de producción: volcar el PDF completo, el historial completo, el manual de 500 páginas, y esperar que el modelo lo entienda. Funciona para demostraciones. Falla en producción cuando: (a) el modelo ignora información crítica que está en el centro, (b) el costo de tokens escala sin control, (c) la latencia hace el sistema inutilizable. *Lo que revela:* La intuición de "más contexto = mejor respuesta" es técnicamente incorrecta. El valor del contexto es una función cóncava: sube con relevancia, baja con ruido. --- **CASO 3: Gemini 1.5 (1M tokens) y el "RAG is dead" falso** En 2024, Gemini 1.5 Pro lanzó con una ventana de 1M tokens. La narrativa inmediata fue "RAG está muerto — carga todo en el contexto." El LaRA paper (ICML 2025), con 2,326 casos de prueba en 11 LLMs, demostró que esta narrativa era prematura. Los long-context LLMs outperforman a RAG cuando hay recursos de compute ilimitados, pero RAG es órdenes de magnitud más eficiente en costo para corpora dinámicos y frecuentemente actualizados. *Lo que revela:* Las narrativas de "X está muerto" en tecnología frecuentemente son incorrectas. El verdadero análisis requiere especificar el caso de uso antes de pronunciar un ganador. --- **CASO 4: El Needle in a Haystack Test (Kamradt, nov 2023)** Greg Kamradt insertó una frase trivial ("The best thing to do in San Francisco is eat a sandwich and sit in Dolores Park") en distintas posiciones dentro de documentos de hasta 200K tokens, y midió si el modelo la recuperaba. Resultado: recuperación casi perfecta cuando la frase estaba al inicio o al final; degradación significativa en el centro — incluso para modelos "long-context" de GPT-4 Turbo y Claude 2.1. *Lo que revela:* El benchmark convencionalizó una intuición: los modelos no leen el contexto uniformemente. La arquitectura de atención produce sesgos de posición que deben ser diseñados explícitamente. No es un defecto a esperar que se corrija — es una restricción a diseñar alrededor. --- **CASO 5: MemGPT / Letta — El Agente que Administra su Propia Memoria** El paper de UC Berkeley propone un mecanismo donde el LLM puede llamar funciones de memoria (write_to_core_memory, archival_memory_search) como si fueran tool calls. El agente no espera que un orquestador externo le diga qué recordar — él mismo decide. "He aprendido que al usuario no le gusta Z — actualizando memoria principal." *Lo que revela:* La diferencia entre un agente frágil (que pierde el hilo al cambiar de sesión) y un agente de largo plazo (que acumula conocimiento sobre el usuario y la tarea) es la auto-administración de la memoria. No es una feature de los pesos del modelo — es una feature de la arquitectura del sistema. --- **CASO 6: Anthropic MCP — La Infraestructura que Estandariza el Campo** En noviembre 2024, Anthropic publicó el Model Context Protocol: un estándar abierto para que aplicaciones provean contexto a LLMs a través de una arquitectura cliente-servidor. OpenAI adoptó MCP en marzo 2025. A junio 2026, MCP es el estándar de facto para integración de contexto en sistemas de producción — equivalente a lo que HTTP es para la web. *Lo que revela:* Los frameworks de context engineering necesitan infraestructura de integración para escalar. MCP es la capa que permite que los patrones (RAG, memory management, tool calling) se conecten a fuentes de datos reales sin código custom por cada integración. --- ## CAPA B — EVALUACIÓN: CÓMO JUZGA ESTE MARCO ### B1 Basic Principles Axiomas del campo de Context Engineering que no se violan. --- **P1. La relevancia es finita, aunque el contexto sea infinito.** Agregar tokens de baja relevancia no mejora — degrada. El modelo distribuye atención sobre todo el contexto; el ruido roba atención a la señal. > *Anti-patrón: "Dump and Pray" — volcar todo y esperar que el modelo lo entienda.* **P2. La posición del contexto no es neutral — es una variable de diseño.** La información crítica va al inicio o al final. El centro del contexto es la zona de menor recuperabilidad empírica. > *Evidencia: Liu et al. (2023) — "Lost in the Middle". Verificado en múltiples modelos.* **P3. La memoria debe ser autocrítica — el agente administra su propio contexto.** Un agente que no puede actualizar su propia memoria está condenado a repetir errores y olvidar aprendizajes. La auto-edición de memoria es una propiedad de diseño, no de los pesos del modelo. > *Evidencia: MemGPT — mecanismo de self-editing memory via tool calls.* **P4. El prompt engineering es un subconjunto del context engineering.** La calidad de la redacción del prompt importa — pero solo después de que el sistema dinámico que ensambla el prompt está correctamente diseñado. > *Cita Chase: "I would also argue that prompt engineering is a subset of context engineering."* **P5. No hay bala de plata en RAG vs. Long Context.** La elección correcta depende de 4 variables simultáneas: capacidades del modelo, longitud de contexto, tipo de tarea, características de recuperación. Cualquier respuesta universal es incorrecta. > *Evidencia: LaRA, ICML 2025 — 2,326 casos de prueba, sin ganador universal.* --- ### B2 Thinking Rules Reglas de decisión con contexto ecológico. --- **R1. Si el contexto supera 100K tokens y el modelo comienza a degradarse →** Activar un "Ranker" (co-modelo pequeño o scoring function) para reordenar fragmentos por relevancia antes de entregarlos al modelo principal. - **Cuándo SÍ aplica:** Cuando hay un corpus fijo de alta densidad (ej.: base de conocimiento legal, manual técnico). - **Cuándo NO aplica:** Cuando el corpus es de baja densidad informacional (texto redundante). En ese caso, primero hacer pruning. **R2. Si el agente olvida instrucciones críticas mid-sesión →** Mover las instrucciones de sistema al *final* del prompt (efecto de recencia) O a Core Memory (siempre disponible). NO confiar en que el modelo las "recuerde" del inicio si hay mucho contenido intermedio. - **Cuándo SÍ aplica:** Instrucciones de comportamiento críticas (seguridad, tono, restricciones). - **Cuándo NO aplica:** Ejemplos few-shot que deben estar juntos y en contexto — no se benefician de estar al final. **R3. Si la base de conocimiento crece exponencialmente →** Implementar Recursive Summarization: resumir bloques, luego resumir resúmenes. Mantiene la esencia sin el peso de tokens históricos. - **Cuándo SÍ aplica:** Conversaciones de larga duración (días, semanas), proyectos multi-sesión. - **Cuándo NO aplica:** Cuando el historial completo es necesario para la tarea actual (ej.: debugging de una sesión específica de código). **R4. Si el sistema RAG produce respuestas inconsistentes →** Diagnóstico en tres pasos: (1) ¿El retrieval está devolviendo los documentos correctos? (2) ¿Los documentos están en el formato correcto para el modelo? (3) ¿El modelo está usando lo recuperado o lo está ignorando? Cada pregunta requiere una intervención diferente. - **Cuándo SÍ aplica:** Fallos de calidad en sistemas RAG de producción. - **Cuándo NO aplica:** Cuando el modelo simplemente no tiene la información en el corpus — eso no es un fallo de context engineering, es un fallo de coverage. **R5. Si hay debate sobre RAG vs. Long Context →** Aplicar el árbol de decisión LaRA: frecuencia de actualización del corpus, tamaño vs. ventana disponible, restricción de costo, tipo de razonamiento requerido. Sin estas 4 variables, el debate es abstracto. - **Cuándo SÍ aplica:** Decisiones de arquitectura para nuevos sistemas. - **Cuándo NO aplica:** Cuando ya hay un sistema en producción con RAG maduro — el costo de migración a long context puede no justificar el beneficio marginal. --- ### B3 Evaluación de Calidad de un Sistema de Context Engineering *(Framework de diagnóstico — equivalente a Moral Foundations para este corpus)* | Dimensión | Sistema Débil | Sistema Fuerte | |---|---|---| | **Relevancia** | Inyecta todo el corpus disponible sin filtrado | Filtra, rankea, y selecciona el subconjunto óptimo | | **Posicionamiento** | Información crítica enterrada en el centro | Instrucciones críticas al inicio; datos relevantes al final | | **Persistencia** | Pierde contexto entre sesiones | Memoria jerárquica (core/recall/archival) con auto-actualización | | **Recuperación** | RAG siempre activo sin evaluación de necesidad | Recuperación condicional (Self-RAG / Agentic RAG) | | **Escalabilidad** | Costo crece linealmente con historial | Recursive summarization comprime sin perder esencia | | **Diagnóstico** | No distingue fallos de modelo vs. fallos de contexto | Identifica si el fallo es de relevancia, posición, frescura, o formato | --- ## CAPA C — DECISIÓN: CÓMO DECIDE ESTE MARCO ### C1 Cognitive Algorithms --- **ALGORITMO 1: Diseño de Memoria para un Agente de Larga Duración** ``` 1. ¿Qué debe SIEMPRE estar disponible sin costo de retrieval? → Core Memory: instrucciones del agente, perfil del usuario, estado de tarea activa → Límite: pocos KB, actualizable por el agente 2. ¿Qué información histórica es searchable pero no siempre necesaria? → Recall Memory: historial de conversación completo → Implementación: base de datos con búsqueda semántica 3. ¿Qué conocimiento externo necesita el agente "cuando sea relevante"? → Archival Memory: documentos, datos, knowledge base → Implementación: vector store con embeddings 4. ¿Cuándo actualiza el agente su memoria? → Al detectar información nueva que cambia Core Memory → Al finalizar cada sesión: comprimir con Recursive Summarization → Al recuperar Archival Memory: verificar que sigue siendo relevante Output: Arquitectura de memoria con las 3 capas, mecanismo de actualización, y protocolo de paginación entre capas ``` --- **ALGORITMO 2: Diagnóstico de Fallo de Contexto** ``` Un agente produce una respuesta incorrecta o de baja calidad. Diagnóstico: Pregunta 1: ¿El modelo base puede responder esto correctamente si se le da el contexto perfecto directamente? → No: el problema está en el modelo o la tarea excede sus capacidades → Sí: el problema está en el contexto. Continúa... Pregunta 2: ¿El retrieval devolvió los documentos correctos? → No: problema de indexación o query formulation → Sí: continúa... Pregunta 3: ¿La información crítica está al inicio o al final del contexto? → No: problema de posicionamiento (anti-lost-in-middle) → Sí: continúa... Pregunta 4: ¿El contexto tiene más de 50% de tokens de baja relevancia? → Sí: problema de pruning — activar ranker o context compression → No: continúa... Pregunta 5: ¿El formato del contexto recuperado es procesable por el modelo? → No: problema de formatting — limpiar y estructurar antes de inyectar → Sí: el problema es más profundo — revisar instrucciones del sistema Output: Diagnóstico en uno de 6 categorías + intervención específica ``` --- **ALGORITMO 3: Decisión RAG vs. Long Context** ``` Input: nuevo sistema de IA, corpus de conocimiento definido Variable 1: ¿El corpus se actualiza más de una vez por semana? → Sí: favorecer RAG (corpus dinámico = retrieval dinámico) Variable 2: ¿El corpus cabe dentro del 70% de la ventana disponible? (70% para dejar espacio a conversación, instrucciones, output) → Sí: Long Context puede ser opción viable Variable 3: ¿El costo de inferencia es una restricción dura? → Sí: RAG (80-90% más barato en corpus estático) Variable 4: ¿La tarea requiere síntesis de múltiples documentos o razonamiento que cruza todo el corpus? → Sí: Long Context outperforma RAG en este escenario específico Scoring: Si 3+ variables favorecen RAG → RAG Si Variable 4 fuerte + Variables 1 y 3 débiles → Long Context Si equilibrado → Hybrid (RAG para retrieval + Long Context para synthesis) Output: Arquitectura de retrieval recomendada con justificación por variable ``` --- **ALGORITMO 4: Context Pruning — Maximizar Señal-Ruido** ``` Input: conjunto de documentos/fragmentos recuperados por RAG Paso 1: DEDUPLICACIÓN → Eliminar fragmentos que contienen la misma información → Conservar el más reciente o el de mayor autoridad Paso 2: COMPRESSION → Para fragmentos > 500 tokens: resumir preservando claims específicos → Para tablas y listas: conservar estructura, comprimir texto explicativo Paso 3: RELEVANCE SCORING → Score cada fragmento: ¿cuánto aumenta la probabilidad de respuesta correcta? → Umbral mínimo: si el score es bajo, excluir aunque el retrieval lo devolvió Paso 4: POSITION ASSIGNMENT → Score alto → inicio o final del contexto → Score medio → zona entre instrucciones y output examples → Score bajo → excluir o comprimir a una sola oración Paso 5: FORMAT CHECK → ¿El formato es parseable por el modelo? (JSON, markdown, texto plano) → Si no: re-formatear antes de inyectar Output: Contexto final optimizado, con justificación de cada inclusión/exclusión ``` --- ### C2 Prototypical Situations + Red Flags --- **PROTOTIPO 1: Agente que "olvida" al cambiar de sesión** - *Causa:* No hay persistent memory. El agente solo tiene el historial de la sesión actual. - *Solución:* Implementar Core Memory + Recall Memory con recuperación al inicio de cada sesión. El agente carga su "memoria de trabajo" antes de cualquier input del usuario. **PROTOTIPO 2: Respuestas inconsistentes en RAG con corpus grande** - *Causa:* El retrieval devuelve fragmentos que se contradicen entre sí, y el modelo no tiene instrucción de cómo resolver contradicciones. - *Solución:* (1) Mejorar el chunking para que los fragmentos tengan contexto suficiente. (2) Agregar instrucción de resolución de contradicciones en Core Memory. (3) Considerar Agentic RAG para que el agente pueda reformular la query si los resultados son insatisfactorios. **PROTOTIPO 3: Alto costo de inferencia con contexto largo** - *Causa:* El sistema inyecta el historial completo en cada llamada. 10,000 tokens/call × 1,000 calls/día = $$$ - *Solución:* Recursive Summarization + Prompt Caching (Anthropic: reduce costo ~90% en contexto repetido). El historial se comprime; el sistema operativo se cachea. **PROTOTIPO 4: El "Lost in the Middle" en respuestas largas** - *Causa:* Instrucciones críticas al inicio del sistema prompt + datos recuperados en el medio + ejemplo de output al final. Las instrucciones del inicio "se olvidan" cuando hay mucho texto en el medio. - *Solución:* Mover las instrucciones de comportamiento críticas también al *final* del prompt (recency effect). O implementar Core Memory siempre-en-contexto para instrucciones críticas. **RED FLAG 1: "Agreguemos más contexto para mejorar las respuestas"** - *Diagnóstico:* Asunción incorrecta de que volumen = calidad. Antes de agregar, preguntar: ¿este contexto adicional aumenta la relevancia o solo el ruido? **RED FLAG 2: "El modelo es demasiado tonto para este corpus"** - *Diagnóstico:* En la mayoría de los casos, el problema es el contexto que recibe el modelo, no las capacidades del modelo. Hacer el test: ¿responde correctamente si le das el contexto perfecto directamente? Si sí, el problema es context engineering, no el modelo. **RED FLAG 3: "Necesitamos fine-tuning para que el modelo recuerde X"** - *Diagnóstico:* Fine-tuning embebe conocimiento estático en los pesos. Para conocimiento que cambia o crece, context engineering (Core Memory / RAG) es más apropiado y mucho más barato. --- ### C3 Tacit Patterns Lo que los expertos en context engineering hacen automáticamente. --- **PATRÓN TÁCITO 1: Chunk design antes de retrieval design** Antes de preguntar "¿cómo recupero mejor?", los expertos preguntan "¿cómo divido el corpus en chunks que tienen contexto suficiente pero no demasiado ruido?". Un chunk de 200 tokens que pierde el sujeto de la oración es peor que un chunk de 500 tokens con contexto completo. **PATRÓN TÁCITO 2: El test "¿puede el modelo resolverlo sin contexto adicional?"** Antes de agregar retrieval, los expertos verifican si el modelo base ya tiene la respuesta en sus pesos. Si la tiene, el RAG agrega latencia y costo sin beneficio. Este test rápido previene sobreingeniería. **PATRÓN TÁCITO 3: Formato-antes-de-inyectar** Los expertos limpian y reformatean el output del retrieval antes de inyectarlo al contexto. El raw JSON de una API, el HTML de un sitio, el PDF parseado con caracteres especiales — todos deben convertirse a texto limpio y estructurado antes de entrar al prompt. **PATRÓN TÁCITO 4: Monitoreo de token usage por componente** Los expertos rastrean cuántos tokens consume cada componente del contexto: instrucciones del sistema, historial, recuperado, examples. Cuando el total se acerca al límite, saben exactamente qué comprimir primero sin perder capacidad. **PATRÓN TÁCITO 5: Retrieval evaluation separado del model evaluation** El pipeline de evaluación tiene dos métricas separadas: (1) ¿El retrieval devuelve los documentos correctos? (2) ¿El modelo usa correctamente lo que recibe? Mezclar las métricas hace imposible identificar dónde está el problema. --- ## CAPA D — ACCIÓN: HABILIDADES DESTILADAS ### D1 Distilled Skills --- **SKILL 1: Arquitectura de Memoria para Agentes de Larga Duración** Diseñar los tres niveles de memoria (Core / Recall / Archival), los mecanismos de transición entre niveles, y los triggers de auto-actualización. La habilidad es tratar la memoria del agente como se trata la arquitectura de datos de un sistema de software: con esquema, con CRUD, con índices. *Cómo activarla:* "Si este agente va a operar durante 6 meses con el mismo usuario, ¿qué necesita recordar siempre, qué necesita poder buscar, y qué puede olvidar con seguridad?" --- **SKILL 2: Context Pruning y Señal-Ruido Optimization** La capacidad de analizar un conjunto de fragmentos recuperados y seleccionar el subconjunto óptimo — no el más grande, el más relevante. Requiere: relevance scoring, format evaluation, position assignment, y duplication detection. *Cómo activarla:* "Si solo puedo usar 2,000 de estos 10,000 tokens recuperados, ¿cuáles son los que más aumentan la probabilidad de respuesta correcta?" --- **SKILL 3: Diseño de Esquemas de Metadatos para RAG** Crear las etiquetas de metadata que permiten retrieval por intención, fecha, tipo de fuente, y autoridad — no solo por similitud semántica del texto. Un chunk sin metadata solo puede buscarse por contenido; un chunk con metadata puede filtrarse por contexto. *Cómo activarla:* "¿Qué dimensiones de filtrado van a ser necesarias para recuperar exactamente el fragmento correcto en el momento correcto?" --- **SKILL 4: Diagnóstico de Fallos de Agente** La habilidad de distinguir si un agente falla por capacidades del modelo, por contexto incorrecto, por retrieval deficiente, o por arquitectura de memoria inadecuada — y aplicar la intervención correcta sin sobreingeniería. *Cómo activarla:* Aplicar el Algoritmo 2 (Diagnóstico de Fallo de Contexto) sistemáticamente antes de proponer cualquier solución. --- ## LAYER L — LÉXICO DEL CAMPO ### L1 Términos Nucleares | Término | Definición | Fuente | |---|---|---| | **Context Engineering** | Diseño de sistemas dinámicos que proveen la información correcta, en el formato correcto, para que un LLM pueda plausiblemente completar la tarea. | Chase/LangChain, jun 2025 | | **Core Memory** | La capa siempre-en-contexto de la memoria del agente: instrucciones permanentes, perfil del usuario, estado activo. Analógico a RAM fija. | MemGPT/Letta | | **Recall Memory** | Historial de conversación buscable. No siempre en contexto — requiere query explícita. Analógico a disco caché. | MemGPT/Letta | | **Archival Memory** | Base de conocimiento externo de largo plazo. Vector store con búsqueda semántica. Analógico a disco frío. | MemGPT/Letta | | **Lost in the Middle** | El fenómeno por el que la información colocada en el centro de un contexto largo es significativamente menos recuperable que la del inicio o final. | Liu et al., 2023 | | **Needle in a Haystack** | Test benchmark que mide la capacidad de recuperar información específica ubicada en distintas posiciones dentro de un contexto largo. | Kamradt, nov 2023 | | **Self-RAG** | Sistema donde el modelo mismo decide cuándo recuperar, evalúa la relevancia de lo recuperado, y critica su propia generación usando "reflection tokens". Requiere fine-tuning. | Asai et al., oct 2023 | | **Agentic RAG** | Arquitectura donde el agente usa retrieval como una tool que llama condicionalmente — sin fine-tuning, como patrón de sistema. | Patrón 2024-2025 | | **Recursive Summarization** | Técnica de compresión de historial: resumir bloques de conversación, luego resumir esos resúmenes, manteniendo la esencia sin tokens ilimitados. | Wang et al., ago 2023 | | **Dump and Pray** | Anti-patrón: inyectar todo el corpus disponible sin filtrado, esperando que el modelo lo procese correctamente. | Nombre coloquial del campo | | **Prompt Caching** | Mecanismo (Anthropic) que reduce el costo de re-procesar el mismo contexto repetido en múltiples llamadas. ~90% de ahorro en contexto estático. | Anthropic | | **MCP (Model Context Protocol)** | Estándar abierto (Anthropic, nov 2024) para conectar LLMs a fuentes de datos externas via arquitectura cliente-servidor. Adoptado por OpenAI en marzo 2025. | Anthropic | --- ### L2 Anti-Léxico | Término rechazado | Por qué / Reformulación | |---|---| | **"Solo es prompt engineering"** | Minusvalora la arquitectura dinámica. Prompt engineering es el subconjunto de redactar texto; context engineering es diseñar el sistema que ensambla ese texto. | | **"Más contexto = mejor respuesta"** | Incorrecta en la mayoría de los casos. El valor del contexto es una función de relevancia, no de volumen. | | **"RAG está muerto por los LLMs largos"** | Refutado por LaRA/ICML 2025. No hay ganador universal — depende del caso de uso. | | **"El modelo es demasiado tonto"** | En la mayoría de los fallos de agente, el problema es el contexto, no el modelo. El diagnóstico correcto precede al juicio. | | **"Fine-tuning para que el modelo recuerde"** | Fine-tuning embebe conocimiento en los pesos — es estático y caro. Para conocimiento dinámico, context engineering es la herramienta correcta. | --- ## CAPA V — VOZ Y EXPRESIÓN DEL MARCO ### V1 Tonal Signature | Dimensión | Descripción | Ejemplo | |---|---|---| | **Origen** | Ingenieril / académico / pragmático. No inspiracional — resolutivo. | "Build dynamic systems." No: "Unlock the power of AI." | | **Certeza** | Alta en lo que está verificado empíricamente; explícitamente incierto en lo que no. | "Lost in the Middle es empírico. El número de tokens óptimo por caso es experimental." | | **Escala** | Arquitectural. Del chunk al sistema, del sistema al producto. | "No pregunto cómo mejorar el prompt. Pregunto cómo diseñar el sistema que lo ensambla." | | **Diagnóstico** | Sistemático. Antes de solucionar, identificar la capa del problema. | "¿Es fallo del modelo o fallo del contexto? No son lo mismo." | --- ### V2 Linguistic Patterns **PATRÓN 1: Distinción antes de recomendación** El marco siempre distingue categorías antes de recomendar. Nunca dice "usa RAG" sin preguntar primero "¿qué tipo de corpus, con qué frecuencia de actualización, con qué restricción de costo?". **PATRÓN 2: El benchmark como punto de referencia** Cita papers y experimentos reales en lugar de intuiciones. "Lost in the Middle (Liu et al.) muestra que..." es el estilo del marco — no "en mi experiencia". **PATRÓN 3: La pregunta de test antes del diagnóstico** "¿Puede el modelo responder correctamente si le das el contexto perfecto directamente?" Esta pregunta diagnóstica precede a cualquier recomendación de arquitectura. --- ### V3 Anti-patrones de Expresión - **Nunca usar "simplemente" o "solo tienes que"** — el context engineering tiene complejidad real que no debe minimizarse. - **Nunca recomendar sin especificar las condiciones de aplicación** — toda recomendación de RAG vs. Long Context requiere las 4 variables del árbol de decisión. - **Nunca confundir Self-RAG con Agentic RAG** — son mecanismos distintos con requisitos distintos (fine-tuning vs. arquitectura). --- ### V4 Activation Protocol ``` ACTIVADO: BCV-ContextEngineering · Modo Diseño de Sistema Cuando uses este BCV para diseñar o evaluar un sistema de IA: 1. LAYER 0: ¿Cuál es la pregunta central de la tarea? → "¿Cómo diseño la memoria/retrieval para que el LLM tenga lo correcto?" 2. CAPA A: Diagnostica el problema con los 5 lentes. - ¿Es un problema de sistema o de texto? - ¿Cuál es la jerarquía de memoria correcta? - ¿Hay ruido excesivo? ¿Hay problema de posición? - ¿El retrieval es estático o condicional? 3. CAPA B: Aplica los 5 principios. - ¿Se está violando el principio de señal-ruido? - ¿Hay información crítica en el centro del contexto? 4. CAPA C: Selecciona el algoritmo apropiado. - Diseño de memoria nueva → Algoritmo 1 - Diagnóstico de fallo → Algoritmo 2 - RAG vs. Long Context → Algoritmo 3 - Optimización de contexto existente → Algoritmo 4 OUTPUT: Recomendación de arquitectura + justificación empírica + CAL check para claims no verificados ``` --- ## LAYER CAL — CONSTITUTIONAL AI OVERRIDES **CAL-1: "Context Engineering" no fue acuñado por Harrison Chase** Chase formalizó el framework en un blog post (23 junio 2025), pero el término fue usado antes por Tobi Lütke (Shopify, abril 2025 en comunicación interna) y popularizado simultáneamente por Andrej Karpathy (tweet 25 junio 2025). Chase es el mejor referente para la definición operativa, no para la autoría del término. **CAL-2: Self-RAG ≠ Agentic RAG** Son mecanismos distintos: - Self-RAG (Asai et al., oct 2023): requiere fine-tuning del modelo para emitir "reflection tokens". No se aplica a cualquier LLM. - Agentic RAG: patrón arquitectural (2024-2025), no requiere fine-tuning. El agente usa retrieval como una tool. Confundirlos produce recomendaciones de implementación incorrectas. **CAL-3: "Lost in the Middle" se ha mitigado parcialmente en modelos de 2025-2026** El paper original (2023) documentó el fenómeno en GPT-3.5, Claude, y modelos de la época. Los modelos frontier de 2025-2026 (Gemini 1.5 Pro, Claude 3.5/3.7, GPT-4o) han reducido parcialmente el efecto mediante mejoras en el mecanismo de atención. El fenómeno no ha desaparecido — pero su severidad varía por modelo. Verificar con benchmarks actualizados antes de citar como verdad absoluta. **CAL-4: El "LLM-as-OS" es una analogía — no una descripción técnica exacta** La analogía RAM/disco es pedagógicamente útil pero imprecisa técnicamente. El contexto window no es RAM física — es una abstracción de atención. Los mecanismos de retrieval no son paginación de OS. Usar la analogía para comunicación; no para diseño técnico detallado. **CAL-5: LaRA/ICML 2025 usa 11 LLMs — no todos los modelos frontier actuales** El paper es el estudio más riguroso disponible a junio 2026, pero no incluye todos los modelos más recientes. Sus conclusiones son robustas para el debate general RAG vs. Long Context, pero los resultados específicos de performance pueden variar con modelos más nuevos. --- ## CHANGELOG | Fecha | Cambio | Por | |---|---|---| | 2026-06-08 | Upgrade a v02. Reescritura completa desde anatomía v00 ad-hoc a anatomía BCV v02 completa. Investigación primaria directa: Harrison Chase/LangChain blog (jun 2025), MemGPT paper (oct 2023), Lost in the Middle paper (jul 2023), Self-RAG paper (oct 2023), Recursive Summarization paper (ago 2023), Karpathy tweet (jun 2025), LaRA/ICML 2025, Anthropic MCP. Layer 0 completo (BCV spec: Content Architecture en 0.4). A1: 5 lenses. A2: 5 modelos. A3: 6 anchor cases. B1: 5 principios. B2: 5 rules con contexto ecológico. B3: tabla de evaluación de calidad. C1: 4 algoritmos. C2: 4 prototipos + 3 red flags. C3: 5 patrones tácitos. D1: 4 skills. L1: 12 términos. L2: 5 anti-léxico. V1-V4 completo. CAL: 5 flags. | Jay | | 2026-05-20 | Creación v01 (Draft). Formato v00 ad-hoc. Fuentes: Harrison Chase, MemGPT, debate RAG vs. Long Context. Anatomía parcial (A1-D1 incompleta, sin Layer 0 canónico, sin CAL). | Jay |