¡Hola! Soy Oscar 👋, y por aquí estoy de nuevo!!!
Esta semana estuve reunido con el CEO de un grupo empresarial Colombiano con negocios en más de 5 o 6 industrias diferentes.
Su inquietud era: ¿por qué si los negocios parecen ser exitosos, el grupo no está capturando el potencial de valor esperado?
Y es que cada unidad está llena de tecnología, plataformas, aplicaciones… y al final el valor individual no fluye de manera conectada para el grupo como un todo.
No se piensa como ecosistema…no se piensa en un cerebro organizacional común.
Si lo piensas, hoy, vivimos en un mundo en donde la tecnología dejó de ser el gran problema. Tenemos acceso a ella, cada vez a menor costo, pero a su vez tenemos mayor información disponible en el entorno, algo a lo que yo llamo: densidad contextual.
Con la “democratización” de la inteligencia artificial generativa, creímos que por fin habíamos resuelto el reto de la gestión del conocimiento organizacional, pero oh sorpresa!!!
NO, no lo hemos resuelto, lo agrandamos.
Los modelos son cada vez más capaces, pero una organización no obtiene mejores resultados simplemente conectándose a una inteligencia artificial más avanzada.
Obtiene mejores resultados cuando esa inteligencia puede acceder a la evidencia correcta, distinguir lo vigente de lo obsoleto y comprender cómo se relacionan los fragmentos de conocimiento que la empresa ya posee.
Hay una clase de error que se ha vuelto habitual en los equipos que trabajan con inteligencia artificial. No es el error absurdo ni la alucinación evidente.
Es algo más incómodo: una respuesta coherente, técnicamente competente y perfectamente inútil.
Piensa en estas situaciones:
Un asistente modifica un servicio y entrega código limpio, pero ignora una convención de arquitectura acordada meses atrás.
Un agente comercial explica por qué se perdió una cuenta importante, aunque no tuvo acceso a la llamada en la que el cliente formuló su objeción principal.
Un copiloto de soporte responde de acuerdo con una política que dejó de estar vigente la semana anterior.
La respuesta parece inteligente porque está bien construida. El problema es que razona sobre una representación incompleta de la realidad.
Cada vez que observo uno de estos casos, me resulta más difícil aceptar el diagnóstico habitual: “el modelo todavía no es suficientemente bueno”.
A veces es cierto.
Hay tareas en las que la capacidad de razonamiento, planificación o interpretación del modelo sigue siendo el límite principal (aunque cada vez menos para un gran porcentaje de las tareas de un humano).
Pero, en buena parte del trabajo empresarial, la explicación más sencilla es otra: el sistema no tuvo acceso al conocimiento necesario, no supo encontrarlo o no consiguió distinguir qué parte de ese conocimiento debía creer.
La diferencia no es menor.
Si el problema es el modelo, la solución consiste en sustituirlo. Si el problema es el contexto, hay que rediseñar la manera en que la organización produce, conserva, recupera y valida conocimiento.
Lo segundo es bastante más difícil.
Y también es donde empieza a concentrarse la ventaja actual de las organizaciones.
AI-Digest
Una tesis que necesita ser formulada con cuidado
La frase “El contexto, no el modelo” funciona bien como provocación. Como afirmación académica, necesita matices.
Los modelos continúan siendo heterogéneos.
Se diferencian en razonamiento, programación, comprensión multimodal, capacidad para seguir instrucciones, latencia, coste y confiabilidad. Una tarea matemática compleja, una migración de software o una investigación científica pueden estar limitadas principalmente por la capacidad del modelo.
Pero el rendimiento de un sistema de IA empresarial no depende únicamente de esa capacidad. Podríamos representarlo mediante una función conceptual:
[Q = f(M, C, H, V, T)]
Donde:
M representa la capacidad del modelo.
C, la calidad del contexto.
H, la capacidad de encontrar y recuperar evidencia.
V, los mecanismos de verificación y gobierno.
T, las herramientas disponibles para actuar.
No es una ecuación empírica, sino una forma de pensar el sistema. Su utilidad reside en recordarnos que el modelo es solo una variable.
Además, estas variables no se comportan necesariamente de manera aditiva. Un modelo excelente no puede utilizar un documento que nunca recibió.
En el gráfico, las barras muestran las cinco variables tal cual. A simple vista el sistema se ve decente: M dispara al 95%, T llega al 80%, hay dos barras que superan la línea del promedio. La historia que cuenta un promedio es “vas bien, 52%”.
La línea punteada del promedio es la trampa que quiero exponer.
Es la lectura aditiva, lo que reporta un dashboard ingenuo, y engaña, porque asume que una variable alta compensa a una baja. En un sistema cognitivo eso no ocurre: los 95 puntos de M no pueden hacer nada con un contexto del 10%.
El bloque rojo es el desenlace. Como las variables se multiplican, el rendimiento real (~40%, media geométrica) no gravita hacia el promedio sino hacia el eslabón más débil. C actúa como techo: no importa cuánto subas M, H, V o T, el sistema queda anclado cerca de su punto más flojo. Ese es el argumento de los rendimientos decrecientes hecho imagen —mejorar el modelo aquí es empujar la barra que ya está llena.
En muchos casos, la relación se parece más a una multiplicación que a una suma: cuando una de las variables se aproxima a cero, mejorar las demás produce rendimientos decrecientes.
Esta es la versión defendible de la tesis:
Para una clase creciente de tareas empresariales, la utilidad marginal de mejorar el modelo es menor que la utilidad marginal de mejorar la selección, actualización, procedencia y gobernanza del contexto.
El desplazamiento es importante porque cambia el objeto que debemos diseñar. Ya no basta con construir una interfaz sobre un modelo. Hay que construir un sistema cognitivo alrededor de él.
El contexto no es el contenido de una ventana
En el lenguaje cotidiano de la inteligencia artificial, solemos utilizar equivocadamente “contexto” como sinónimo de los tokens incluidos en un prompt o el espacio que tenemos para interactuar con la IA.
Es una definición demasiado estrecha.
El contexto de un sistema empresarial incluye al menos:
Las instrucciones y restricciones de la tarea.
Los documentos recuperados.
La identidad y los permisos del usuario.
El estado actual de sistemas operativos.
Las decisiones históricas relevantes.
La procedencia y vigencia de cada afirmación.
Los resultados producidos por herramientas.
La memoria de interacciones anteriores.
Las relaciones entre personas, clientes, procesos y sistemas.
Los criterios utilizados para resolver contradicciones.
Desde esta perspectiva, la ventana de contexto es únicamente el espacio temporal en el que el modelo puede leer una representación parcial de ese mundo.
No es el mundo.
Podemos ampliar la ventana sin mejorar la representación. Podemos introducir cien documentos y seguir omitiendo el único que contiene la decisión relevante. Podemos incorporar todas las conversaciones de un canal y no señalar que una de ellas fue reemplazada por una política posterior.
Una ventana extensa permite transportar más información. No determina qué información merece ser transportada.
Esa distinción —entre capacidad de transporte y calidad epistemológica— es uno de los puntos que más se pierden en la conversación actual.
Una ventana de un millón de tokens no contiene un millón de tokens de comprensión
El crecimiento de las ventanas de contexto suele presentarse como una posible disolución del problema: cuando los modelos puedan recibir todos los documentos, ya no necesitaremos seleccionar.
La evidencia disponible recomienda más prudencia.
El estudio Lost in the Middle mostró que el rendimiento de diversos modelos podía variar según la posición de la información relevante.
En tareas de respuesta sobre múltiples documentos y recuperación de pares clave-valor, los modelos tendían a utilizar mejor la evidencia situada al principio o al final y peor la ubicada en zonas intermedias.
RULER amplió esta evaluación con tareas que no se limitaban a encontrar una única “aguja”, sino que incluían múltiples elementos, seguimiento de relaciones y agregación. Aunque varios modelos obtenían resultados casi perfectos en pruebas simples, su rendimiento disminuía al aumentar la longitud y la complejidad; solo una parte mantenía resultados satisfactorios en las longitudes declaradas.
Esto permite distinguir dos conceptos:
Ventana nominal: el número máximo de tokens que el modelo acepta.
Ventana efectiva: la cantidad y complejidad de información que puede utilizar de forma confiable para una tarea concreta.
Una biblioteca puede contener un millón de páginas. Eso no significa que un lector pueda encontrar, contrastar e integrar cualquier combinación de hechos presentes en ellas.
El contexto largo sigue siendo valioso. Puede evitar errores de recuperación y preservar relaciones que se pierden al fragmentar documentos. De hecho, una comparación presentada en EMNLP 2024 encontró que, con suficientes recursos, los modelos de contexto largo superaban en rendimiento promedio a RAG en buena parte de los escenarios evaluados, mientras que RAG conservaba una ventaja importante en coste.
El enfoque híbrido propuesto por los autores buscaba enrutar cada consulta hacia la estrategia más adecuada.
La conclusión académicamente responsable no es que RAG sea superior al contexto largo ni que el contexto largo vuelva obsoleto a RAG.
Es que la elección depende de:
La naturaleza de la tarea.
La distribución de la evidencia.
La longitud del corpus.
La frecuencia de actualización.
El coste tolerable.
La necesidad de trazabilidad.
Los riesgos de privacidad.
La capacidad efectiva del modelo.
La arquitectura más razonable será con frecuencia híbrida.
El contexto tiene calidad, no solo cantidad
Cuando hablamos de “dar más contexto”, tendemos a imaginar una variable cuantitativa. Pero el contexto posee al menos seis dimensiones cualitativas.
1. Relevancia
¿La información ayuda realmente a responder la pregunta?
Recuperar contenido relacionado no garantiza recuperar la evidencia necesaria.
2. Completitud
¿Están presentes todas las piezas críticas?
Un resumen de una cancelación puede ser correcto en sus afirmaciones individuales y equivocado en su explicación causal si omite la conversación decisiva.
3. Actualidad
¿La información seguía vigente en el momento de la consulta?
La similitud semántica no distingue necesariamente entre una política anterior y su reemplazo.
4. Autoridad
¿Qué fuente prevalece cuando existen contradicciones?
Un comentario en un chat y una política aprobada pueden describir el mismo tema sin tener el mismo estatus.
5. Procedencia
¿Podemos rastrear de dónde procede cada afirmación?
La trazabilidad es necesaria tanto para verificar respuestas como para diagnosticar errores.
6. Accesibilidad legítima
¿El usuario y el agente están autorizados para acceder a esa información?
La investigación sobre privacidad en sistemas RAG muestra que conectar información privada a un proceso de recuperación introduce una superficie de riesgo propia. El problema no consiste solo en proteger el modelo, sino también el corpus, el índice y las reglas mediante las cuales se recuperan datos.
Podemos resumirlo de esta manera:
Más contexto aumenta la superficie de información. Mejor contexto aumenta la probabilidad de que el sistema actúe correctamente.
No son equivalentes.
Las organizaciones siempre han pensado de forma distribuida
La idea de que una empresa necesita una “memoria compartida” puede parecer una consecuencia reciente de los agentes de IA. En realidad, conecta con varias décadas de investigación sobre cómo las organizaciones conocen y recuerdan.
En 1991, James Walsh y Gerardo Rivera Ungson propusieron que la memoria organizacional no debía entenderse como un archivo central ni como la suma de los recuerdos individuales. El conocimiento del pasado se conserva en múltiples estructuras: personas, cultura, procedimientos, roles, configuraciones físicas y archivos externos. La recuperación de ese conocimiento depende de cómo la organización conecta esas estructuras con las decisiones presentes.
Esta observación sigue siendo sorprendentemente actual.
Una decisión de producto puede estar parcialmente contenida en una presentación, en la memoria de una product manager, en una excepción introducida en el código y en la forma en que el equipo de soporte clasifica determinados tickets. Ninguna de esas piezas aisladas explica la decisión completa.
La organización “recuerda” a través de su combinación.
La teoría de la cognición distribuida lleva el argumento un paso más lejos.
En lugar de situar el pensamiento exclusivamente dentro de la mente individual, estudia sistemas compuestos por personas, herramientas, representaciones y entornos que coordinan información para realizar una tarea. Hollan, Hutchins y Kirsh plantearon que, para comprender determinados procesos cognitivos, la unidad de análisis debe extenderse más allá del individuo y abarcar las relaciones funcionales entre personas y recursos externos.
Una cabina de navegación, un hospital o un equipo de ingeniería no “piensan” porque una sola persona posea toda la información. Piensan porque distribuyen observaciones, responsabilidades y representaciones de manera coordinada.
Esto permite reinterpretar el problema de la IA empresarial.
El agente no es una inteligencia aislada que llega a una organización y comienza a comprenderla.
Se incorpora a un sistema cognitivo preexistente. Su rendimiento dependerá de si puede leer las representaciones utilizadas por ese sistema, reconocer quién o qué tiene autoridad y devolver sus aprendizajes de una forma que otros puedan reutilizar.
La pregunta correcta no es únicamente “¿qué sabe el modelo?”, sino:
¿En qué sistema de memoria, coordinación y autoridad estamos insertando al modelo?
De la memoria organizacional a la memoria transaccional
Existe otro concepto especialmente útil: la memoria transaccional.
Una memoria transaccional no implica que todos sepan todo. Implica que las personas saben, de manera aproximada, quién sabe qué. El equipo distribuye su memoria: una persona conoce la infraestructura, otra comprende al cliente y otra conserva el contexto regulatorio.
Argote y Ren describen estos sistemas como mecanismos colectivos para codificar, almacenar y recuperar conocimiento.
Su funcionamiento depende de tres propiedades: especialización, credibilidad y coordinación. Los miembros deben desarrollar conocimientos complementarios, confiar razonablemente en la experiencia ajena y ser capaces de dirigirse a la fuente correcta cuando aparece un problema.
Un buen sistema empresarial de IA necesita una versión técnica de esas mismas propiedades.
Especialización: debe saber qué sistema es competente para cada tipo de pregunta.
Credibilidad: debe conocer la autoridad, procedencia y nivel de confianza de cada fuente.
Coordinación: debe ser capaz de combinar fuentes y herramientas sin perder el estado de la tarea.
Esta analogía revela por qué “conectar todos los documentos” no es suficiente.
Un sistema con acceso universal, pero sin una noción de autoridad, es como un empleado que puede preguntar a todo el mundo y no sabe a quién creer.
El verdadero contexto no es un inventario de información. Es un mapa de responsabilidades epistemológicas.
Quién define los ingresos recurrentes. Qué repositorio contiene el contrato vigente. Qué política prevalece si dos documentos discrepan. Quién puede aprobar una excepción. Qué sistema registra el estado real de una cuenta.
Las organizaciones humanas resuelven muchas de estas preguntas mediante relaciones sociales y experiencia acumulada. Los agentes necesitan que esas relaciones sean parcialmente explícitas.
📌 Si llegaste hasta aquí, es porque te interesa ir más allá de la teoría, así que te invito a Xtrategas, mi comunidad para profesionales que lideran en producto, operaciones, tech, innovación y transformación digital.
¿Te unes?
El problema de la memoria paramétrica
Los modelos de lenguaje contienen conocimiento en sus parámetros. Ese conocimiento, adquirido durante el entrenamiento, resulta extraordinariamente útil para el razonamiento general, la escritura, la programación y la comprensión del lenguaje.
Pero tiene tres limitaciones para el trabajo empresarial.
La primera es la especificidad. El modelo no ha sido entrenado necesariamente con los procesos internos, clientes, decisiones o datos recientes de una empresa.
La segunda es la actualización. Cambiar el conocimiento contenido en los parámetros requiere entrenamiento, ajuste o algún mecanismo externo.
La tercera es la procedencia. Incluso cuando el modelo conoce un hecho, puede resultar difícil identificar la fuente concreta de la que procede.
El trabajo que introdujo formalmente la generación aumentada mediante recuperación —Retrieval-Augmented Generation o RAG— planteó precisamente una combinación entre memoria paramétrica y memoria no paramétrica. El modelo aporta capacidades lingüísticas y de razonamiento; un índice externo permite recuperar información específica y actualizable.
La idea es poderosa porque separa dos funciones que solemos confundir:
Saber razonar.
Tener acceso a la evidencia sobre la que razonar.
Sin embargo, RAG no convierte automáticamente una colección de documentos en conocimiento confiable.
Simplemente añade una etapa de recuperación.
Y cada etapa adicional introduce nuevas formas de equivocarse.
Recuperar información no es comprender una organización
Un sistema RAG convencional suele seguir una secuencia sencilla:
Divide documentos en fragmentos.
Representa esos fragmentos mediante vectores.
Compara la consulta con el índice.
Recupera los fragmentos más próximos.
Los incorpora al prompt del modelo.
Genera una respuesta.
Esta arquitectura funciona razonablemente bien cuando la respuesta está contenida en pasajes localizables y semánticamente parecidos a la pregunta.
Pero el conocimiento empresarial rara vez es tan limpio.
Una consulta puede requerir unir un ticket, una llamada, una definición de métrica y una decisión de arquitectura.
El fragmento más parecido semánticamente no siempre es el más importante. Los nombres propios, identificadores técnicos y fechas pueden funcionar mejor con búsqueda lexical que con embeddings. Y algunas preguntas exigen comprender la estructura global de un corpus, no recuperar un párrafo aislado.
GraphRAG fue propuesto para abordar parte de este último problema.
En lugar de limitarse a buscar fragmentos similares, construye relaciones entre entidades y genera resúmenes de comunidades. En evaluaciones sobre preguntas globales aplicadas a corpus cercanos al millón de tokens, sus autores encontraron mejoras en amplitud y diversidad frente a una implementación convencional de RAG.
Esto no significa que todas las empresas necesiten grafos de conocimiento. Significa que la forma del contexto debe corresponderse con la forma de la pregunta.
Una consulta puntual como “¿cuál es el límite de reembolso?” puede resolverse mediante recuperación documental.
Una pregunta relacional como “¿qué cuentas están expuestas al mismo problema que provocó esta cancelación?” requiere conectar clientes, eventos y causas.
Una pregunta global como “¿qué temas están apareciendo en las entrevistas de usuarios?” exige agregar evidencia distribuida.
Una pregunta normativa como “¿podemos realizar esta acción?” necesita resolver no solo relevancia, sino autoridad y vigencia.
No existe un único sistema de contexto óptimo porque no existe una única clase de conocimiento.
El cuello de botella no es simplemente técnico
La mayor parte de las propuestas de ingeniería de contexto se concentra en embeddings, bases vectoriales, rerankers, grafos, memoria y herramientas.
Son componentes importantes. Pero una empresa puede implementar todos ellos y seguir teniendo un problema fundamental: no sabe qué considera verdadero.
La infraestructura de contexto expone problemas organizacionales que antes podían permanecer ocultos.
Si existen cuatro definiciones de “cliente activo”, el agente no crea la contradicción. La revela.
Si una decisión esencial solo vive en la memoria de una persona, el fallo no pertenece al sistema de recuperación. Pertenece al proceso mediante el cual la organización conserva decisiones.
Si nadie es responsable de retirar una política obsoleta, añadir más documentos al índice empeora la situación.
Si los equipos no confían entre sí, una memoria central no genera automáticamente credibilidad.
Por eso, construir contexto es también construir gobierno.
Requiere asignar responsables, establecer jerarquías entre fuentes, introducir fechas de vigencia, conservar decisiones y diseñar procesos para corregir conocimiento incorrecto.
En otras palabras: la ingeniería de contexto no reemplaza a la gestión del conocimiento. La obliga a volverse operacional.
Contexto como infraestructura epistemológica
La palabra “infraestructura” puede resultar engañosa si hace pensar únicamente en servidores y bases de datos.
Lo que una organización necesita es una infraestructura epistemológica: un sistema que determine cómo se produce, valida, distribuye y corrige aquello que la empresa considera conocimiento.
Una arquitectura madura debería cubrir cinco capas.
Capa 1: fuentes
Identifica dónde vive cada tipo de información y cuál es la fuente autorizada.
No es necesario que todo esté centralizado. Es necesario saber dónde reside la autoridad.
Capa 2: representación
Convierte documentos, conversaciones, eventos, tablas y decisiones en formatos que puedan localizarse y relacionarse.
La representación debe conservar metadatos como autor, fecha, entidad, versión y nivel de aprobación.
Capa 3: selección
Decide qué información presentar para una tarea.
Puede utilizar búsqueda textual, semántica, filtros, grafos, reglas del dominio, reranking o una combinación.
Capa 4: interpretación y acción
El modelo sintetiza la evidencia, formula hipótesis, solicita información adicional o utiliza herramientas.
Aquí es donde la capacidad del modelo vuelve a ser decisiva.
Capa 5: verificación y aprendizaje
El sistema comprueba resultados, registra errores y convierte determinados hallazgos en conocimiento reutilizable.
Sin esta última capa, cada interacción empieza desde una forma ligeramente distinta de amnesia.
Si aún no te has suscrito a Xtrategia, te invito a hacerlo dando click aquí:
La memoria de un agente no debe confundirse con la verdad
A medida que los agentes operan durante más tiempo, aparece una tentación comprensible: conservar todo lo que aprendan.
Pero una memoria indiscriminada puede degradar el sistema.
No toda observación merece persistir. No toda inferencia es un hecho. No toda preferencia individual debe convertirse en política organizacional.
Conviene separar al menos cuatro categorías:
La memoria institucional necesita controles adicionales:
Fuente.
Responsable.
Fecha de creación.
Fecha de vigencia.
Nivel de confianza.
Evidencia de respaldo.
Estado de aprobación.
Condiciones de revisión.
Esto puede parecer burocrático hasta que un agente reutiliza una conclusión incorrecta cientos de veces.
La memoria amplifica tanto el aprendizaje como el error.
El peligro de una fuente única de verdad
La expresión “single source of truth” tiene atractivo porque promete orden. También puede ocultar una premisa peligrosa: que la realidad organizacional siempre admite una versión única y estable.
En numerosos dominios existen desacuerdos legítimos.
Finanzas puede definir un cliente activo de una manera y producto de otra porque responden a preguntas diferentes. Investigación cualitativa puede interpretar una pérdida de cliente de forma distinta al equipo comercial. Una política puede tener excepciones regionales.
El objetivo de una buena infraestructura no debería ser borrar toda pluralidad, sino hacerla explícita.
El sistema debe poder representar:
Que dos métricas comparten un nombre, pero no una definición.
Que una política posee excepciones.
Que una conclusión está disputada.
Que una fuente es oficial para una tarea y orientativa para otra.
Que cierta información era correcta hasta una fecha determinada.
Una memoria corporativa útil no es aquella que nunca contiene contradicciones. Es aquella que puede mostrar de dónde proceden, cuándo aparecieron y qué autoridad tiene cada parte.
Cuándo el modelo sigue siendo el cuello de botella
Sería un error utilizar la tesis del contexto para minimizar los avances en capacidad.
El modelo sigue siendo determinante cuando la tarea exige:
Razonamiento novedoso con varios pasos.
Planificación bajo incertidumbre.
Comprensión de instrucciones ambiguas.
Integración de modalidades diferentes.
Generación o revisión de código complejo.
Detección de contradicciones sutiles.
Reconocimiento de que la evidencia es insuficiente.
Además, un sistema puede recuperar la evidencia correcta y aun así interpretarla mal. Puede confundir correlación con causalidad, sobrevalorar una fuente o responder con una certeza que los datos no permiten.
Por eso la evaluación debe separar dos fallos:
Fallo de acceso: la evidencia necesaria no llegó al modelo.
Fallo de razonamiento: la evidencia llegó, pero fue utilizada incorrectamente.
Si una empresa no diferencia ambos casos, puede terminar cambiando de modelo para corregir un problema de documentación o reconstruyendo su sistema de recuperación para corregir una limitación cognitiva.
La tesis no es “los modelos ya son suficientemente inteligentes para todo”.
Es algo más preciso:
Un modelo solo puede demostrar la inteligencia que su contexto le permite ejercer.
Cómo auditar el problema en una organización
Antes de invertir en una nueva arquitectura, conviene realizar una evaluación sencilla.
Selecciona entre veinte y cincuenta tareas reales. Para cada una, registra:
La respuesta o acción esperada.
La evidencia mínima necesaria.
Las fuentes autorizadas.
La fecha o versión relevante.
Lo que el sistema consiguió recuperar.
Lo que el modelo utilizó realmente.
La respuesta final.
El tipo de error producido.
Esta evaluación permite construir una matriz de diagnóstico:
Este ejercicio suele ser más informativo que comparar modelos sobre prompts abstractos.
También cambia la conversación interna. En lugar de preguntar “¿qué modelo obtuvo mejor puntuación?”, el equipo comienza a preguntar:
¿Qué evidencia faltó?
¿Por qué no se recuperó?
¿Quién era responsable de mantenerla?
¿Cómo debería haberse presentado?
¿Qué mecanismo habría detectado la contradicción?
¿Podemos rastrear la decisión final?
Estas son preguntas de infraestructura, pero también de organización.
La ventaja no será poseer el modelo
Los modelos avanzados pueden seguir diferenciándose durante mucho tiempo. No es prudente afirmar que ya son un commodity perfecto.
Pero el acceso a capacidad de generación y razonamiento tenderá a difundirse más rápido que el conocimiento específico de una organización.
Un competidor puede contratar al mismo proveedor o utilizar un modelo comparable.
Pero le resultará mucho más difícil replicar:
La historia de decisiones de un producto.
La comprensión acumulada de sus clientes.
Las relaciones entre sistemas y procesos.
Los criterios empleados para resolver excepciones.
Los aprendizajes derivados de incidentes.
La confianza desarrollada entre especialistas.
Los mecanismos que convierten experiencia en conocimiento reutilizable.
La investigación sobre memoria transaccional ayuda a explicar por qué.
Estos sistemas son difíciles de imitar porque se desarrollan con el tiempo, dependen de interacciones sociales y están vinculados al contexto concreto en el que opera una organización.
La ventaja no reside en acumular más documentos que los demás.
Reside en ser capaz de transformar experiencia dispersa en contexto operativo sin eliminar su procedencia, sus límites ni su temporalidad.
La empresa como sistema cognitivo
Durante los primeros años de la inteligencia artificial generativa, tratamos al modelo como si fuera el producto.
Le escribíamos una instrucción, observábamos la respuesta y atribuíamos el resultado a su inteligencia.
Los agentes empresariales obligan a abandonar esa simplicidad.
Cuando un sistema trabaja sobre clientes, código, operaciones o decisiones, su unidad real ya no es el modelo. Es el conjunto formado por el modelo, las personas, las fuentes, las herramientas, los permisos, las memorias y los mecanismos de verificación.
Es, en términos de cognición distribuida, un sistema cognitivo completo.
Esto explica por qué dos empresas que utilizan el mismo modelo pueden obtener resultados tan diferentes. Una le entrega un universo fragmentado, sin jerarquía, lleno de documentos viejos y decisiones invisibles. La otra le ofrece una representación curada de su realidad: fuentes autorizadas, relaciones, historia, límites y mecanismos para saber cuándo no existe una respuesta suficiente.
La diferencia no está en la inteligencia abstracta que han comprado.
Está en la organización que esa inteligencia puede ver.
Durante mucho tiempo pensamos que el desafío consistía en construir máquinas que supieran más.
El desafío empresarial que aparece ahora es más humilde y más difícil: construir organizaciones capaces de mostrar lo que saben, recordar por qué lo saben y corregirse cuando dejan de saberlo.
El modelo aporta capacidad.
El contexto le da una realidad sobre la cual ejercerla.
Y ninguna inteligencia, por avanzada que sea, puede razonar correctamente sobre aquello que permanece fuera de su alcance.
¿en tu experiencia, el principal límite de la IA en las empresas sigue siendo el modelo o la calidad del contexto que recibe?
Cuéntame en los comentarios qué está fallando en tu organización: recuperación de información, documentación, memoria, permisos, herramientas o razonamiento. Me interesa especialmente conocer casos reales porque ahí es donde la conversación se vuelve verdaderamente útil.
Gracias por leerme.
Si esta newsletter te resultó útil, compártela con un líder de tu red que siga usando IA sin muchos resultados. Nos ayuda a crecer y a ellos les puede cambiar la perspectiva.
Nos leemos la próxima semana.
Oscar Durán - @duranoscarf en instagram y Linkedin
Comparte Xtrategia Newsletter con alguien que creas le puede agregar valor.
Fuentes citadas
Walsh, James P. y Gerardo Rivera Ungson. “Organizational Memory”. Academy of Management Review, 1991-01.
Hollan, James, Edwin Hutchins y David Kirsh. “Distributed Cognition: Toward a New Foundation for Human-Computer Interaction Research”. ACM Transactions on Computer-Human Interaction, 2000-06.
Argote, Linda y Yuqing Ren. “Transactive Memory Systems: A Microfoundation of Dynamic Capabilities”. Journal of Management Studies, 2012-12.
Lewis, Patrick et al. “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”. 2020-05-22.
Liu, Nelson F. et al. “Lost in the Middle: How Language Models Use Long Contexts”. 2023-07-06; versión publicada en TACL en 2024.
Hsieh, Cheng-Ping et al. “RULER: What’s the Real Context Size of Your Long-Context Language Models?”. 2024-04-09.
Edge, Darren et al. “From Local to Global: A Graph RAG Approach to Query-Focused Summarization”. Microsoft Research, 2024-04.
Li, Zhuowan et al. “Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach”. EMNLP Industry Track, 2024-11.
Zeng, Shenglai et al. “The Good and the Bad: Exploring Privacy Issues in Retrieval-Augmented Generation”. Findings of ACL, 2024.
Oscar, esto describe perfectamente lo que pasa en muchas pymes que se lanzan a implementar IA esperando que el modelo resuelva solo, y terminan con respuestas correctas pero inútiles porque el contexto de la empresa nunca estuvo bien organizado. En mi experiencia con negocios pequeños el límite casi nunca es el modelo, es que la información vive dispersa en la cabeza del dueño y en tres chats de WhatsApp. Muy útil el marco de las cinco capas. Gracias por el análisis. Te invito a conocer El café del emprendedor, la suscripción es gratis.
Gran artículo Oscar. Cómo mencioné en otro post, ya no son solo los datos sino el conocimiento que se desprende de estos.