Ingeniería de contexto para un agente de investigación cuantitativa: niveles de prueba y almacenes de datos

Decidir en qué puede confiar un agente

Imagínese un entorno de investigación gestionado por inteligencia artificial creado para la competencia quant WorldQuant BRAIN. Antes de que existan agentes especializados, verificaciones de ciclo de vida o bucles autónomos, surge un problema de diseño más básico: ¿qué afirmaciones puede el sistema considerar verdaderas? La materia prima llega en cuatro formas que tienen poco en común.

El primero es la documentación oficial de la plataforma y del torneo, que explica cómo funciona el lenguaje de expresiones, qué operadores y conjuntos de datos están disponibles, y qué configuraciones de simulación son permitidas. El segundo es la metodología: los tres libros de Marcos López de Prado ofrecen herramientas para razonar sobre estadísticas de backtesting, riesgo de estrategias, pruebas múltiples, estructura de carteras y falsificación, mientras que *Finding Alphas* de Igor Tulchinsky aborda de manera práctica la construcción de ideas, la rotación, la correlación, el sobreajuste, el sesgo y la durabilidad. El tercero es un conjunto de artículos y notas de investigación profunda sobre anomalías económicas, participantes del mercado y flujo de información, que pueden organizarse en un gráfico que conecte axiomas, teorías, anomalías, mecanismos y formas de implementación. El cuarto elemento es todo lo que genera el proyecto a medida que funciona: respuestas de simulación, curvas diarias de ganancias y pérdidas, correlaciones del portafolio, estadísticas de resiliencia, verificaciones de la plataforma, historiales de experimentos, eventos operativos, compilaciones fallidas y las lecciones extraídas de ellas.

Cada uno de estos elementos constituye contexto, pero tienen un valor de verdad desigual, y ninguno encaja perfectamente en una sola instrucción, un único formato de documento o una sola base de datos. Por lo tanto, la ingeniería de contexto en este escenario comienza en otro lugar que no sea los presupuestos de tokens. Comienza con el diseño de niveles de prueba, además de los sistemas de datos que mantienen cada nivel intacto.

A la izquierda se encuentra el primer diseño ingenuo, en el cual las reglas, los libros, los artículos y los resultados del propio sistema se amontonan en una sola instrucción, y todos tienen el mismo peso. A la derecha, cada afirmación mantiene su propio nivel: las reglas forman las paredes, las creencias proponen pruebas, las observaciones ajustan las creencias, y nada dentro de esas paredes puede modificarlas.

Tres niveles de evidencia

“Prueba” se entiende en un sentido práctico. Para cualquier afirmación, hay que preguntarse qué evidencia es suficiente, quién es responsable de ella y qué se permite para refutarla. Tres niveles abordan esas preguntas.

L1 registra lo que la plataforma declara que es el juego, utilizando material oficial de la plataforma y de los torneos. Cuando el agente necesita saber qué configuraciones existen, qué hace un operador, qué verificaciones debe superar un candidato o cómo calcula el torneo su puntuación, es aquí donde busca la información. Una copia local puede volverse obsoleta, pero ningún experimento inesperado puede alterar una regla.

L2 registra lo que el sistema vio realmente. Aquí se incluyen los resultados de la simulación, junto con las series diarias de ganancias y pérdidas, la cartera actual, las verificaciones de la plataforma, los eventos operativos y el estado más reciente de la tabla de clasificación. Cada medición lleva marcada la hora en que fue observada. Una nueva ejecución no sobrescribe nada; genera una nueva observación, por lo que el historial nunca se actualiza a posteriori.

L3 recoge aquello que el sistema considera útil en el momento actual. Libros, artículos, teorías económicas, especificaciones, lecturas de grafos de conocimiento, lecciones escritas y elementos que pueden refutar las afirmaciones se encuentran en esta capa. Estos elementos guían la siguiente acción y permanecen abiertos a ser modificados.

El orden no es estricto; L1 siempre supera a L2 y L2 siempre supera a L3. Cada nivel responde a un tipo diferente de pregunta. En caso de disputas factuales entre fuentes, prevalece la más contundente y directa, por lo que una regla oficial tiene mayor peso que una paráfrasis incluida en una instrucción al agente, y una respuesta meditada supera a lo que un libro podría hacer esperar. Sin embargo, para decidir qué probar a continuación, las reglas y las mediciones no ofrecen respuesta. Es entonces cuando se necesita a L3 para tomar una decisión fundamentada.

Tres ideas se registran en este gráfico. La desviación posterior a la publicación de resultados no fue eliminada por su factor de falsificación, que en su lugar identificó la estructura que falló, por lo que la idea se reconstruyó basándose en las revisiones de los analistas y se presentaron dos versiones. Una idea basada en un grupo de pares comenzó como una creencia pura sin ninguna evidencia y aun así fue aceptada. Una idea relacionada con un cronómetro de dividendos falló en las diez estructuras propuestas, y la lección aprendida redujo la creencia únicamente a las fechas de pago de dividendos. Los cuadrados verdes superaron las verificaciones de la plataforma, los rojos fallaron, los grises no tienen verificaciones registradas, y los con anillo fueron presentados.

Una única base de datos puede contener tanto una medición (L2) como la lectura que alguien hace de ella (L3), lo que significa que el nivel se asocia a la afirmación, no a su ubicación de almacenamiento. En consecuencia, un registro de contexto útil es más rico que el texto simple. Debe registrar la afirmación en sí, su nivel epistémico, fuente, propietario, alcance, el momento de la observación o revisión, la incertidumbre, un identificador estable y cualquier evidencia que pueda modificarla. Para hechos que cambian con el tiempo, es útil contar con un par de líneas de tiempo: cuándo algo era cierto y cuándo el sistema lo descubrió. Las APIs que responden con retraso y completan posteriormente los datos históricos hacen que esa brecha sea importante.

El contexto es, en realidad, una pequeña plataforma de datos

Cada tienda se diseña según su comportamiento. El registro acumula pruebas en capas y una cadena de linaje las conecta; los eventos antiguos se desvanecen. El gráfico consiste en un par de tablas que se convierten en un multigrafo en la memoria, y los archivos se agrupan según su ciclo de vida. Los IDs estables mantienen unidas todas estas partes. El PnL diario sigue estando en la ubicación que, según las especificaciones del propio proyecto, debería haber abandonado.

Una vez que existen los niveles de prueba, otro punto se vuelve evidente: el contexto no es un único corpus. Se comporta como una plataforma de datos modesta. La parte más grande es el registro de investigación, que en la estación de trabajo inspeccionada es una base de datos SQLite transaccional. Llamarlo tabla de experimentos le resta importancia, ya que funciona como un registro de pruebas que alberga varias familias de registros. Una familia corresponde a la intención de investigación, es decir, mecanismos, hipótesis, predicciones y la evolución de las implementaciones. Otra se refiere a la medición, que almacena las respuestas de la plataforma, estadísticas de la muestra, verificaciones, ganancias y pérdidas diarias y métricas de pruebas de estrés. Una tercera familia está dedicada a la interpretación, con atribuciones, lecciones aprendidas y elementos que permiten refutar las hipótesis. La cuarta familia se ocupa de la gobernanza, haciendo un seguimiento de las decisiones tomadas, las aprobaciones y lo que ocurrió durante la presentación. La última es el análisis materializado: deltas de carteras, pantallas de correlación, cachés de patrones y resúmenes de pruebas de estrés, todos los cuales pueden ser regenerados a partir de entradas canónicas.

Al auditarlo se encontró una discrepancia. Un documento de diseño indica que las ganancias y pérdidas diarias se habían transferido a archivos Parquet, pero la base de datos sigue almacenando cada fila. El documento representa una creencia (Nivel 3), mientras que la base de datos es una observación (Nivel 2), y en caso de conflicto prevalece la observación.

A continuación se encuentra un almacén de eventos operativos, que se mantiene como una base de datos SQLite independiente. Los eventos allí almacenados pueden incluir identificadores de ciclo, lote, candidato, hipótesis, agente y proceso, junto con un payload en JSON versionado. Sería tentador integrarlos en el registro principal, pero las necesidades de conservación son diferentes. La evidencia de investigación es canónica y debe perdurar. La salida de depuración, los eventos de envío, las transiciones en cola y las intervenciones temporales aumentan rápidamente y pueden comprimirse o caducar. Al mantenerlos separados, un aumento repentino en los datos de observabilidad no puede sobrecargar ni bloquear el registro científico.

Luego está el grafo de conocimiento, un grafo de propiedades transaccional con una estructura física deliberadamente sencilla: una tabla de nodos, una tabla de aristas y atributos en JSON para las pruebas específicas de cada tipo, todo cargado en un grafo en memoria para su recorrido. La capa transaccional evita los problemas de corrupción y concurrencia que surgen con un único archivo YAML enorme, mientras que la forma en memoria permite un razonamiento más ágil.

El sistema de archivos también se considera un sistema de datos. Un repositorio alberga documentos de la plataforma inmutables, libros, artículos y informes derivados, y cargar todo eso en la memoria sería un error, ya que sus ciclos de vida son diferentes. Los documentos de la plataforma nunca cambian. Las especificaciones son prioridades de diseño bajo control de versiones. Los informes son derivados que necesitan datos de entrada registrados y una forma de regenerarlos. Los archivos de memoria son punteros cortos y legibles hacia lecciones reutilizables. Los archivos de cola, cachés y registros son estados operativos temporales, mientras que los binarios de modelos, las exportaciones de PnL y las capturas completas son artefactos que es mejor guardar en almacenamiento de objetos en lugar de en Git.

Las historias de fracaso son reveladoras. Un alfa de alto rendimiento estuvo a punto de ser descartado porque el registro contable indicaba que todos los chequeos habían sido exitosos, mientras que un script leía un archivo de ejecución que mostraba un valor de Sharpe de 0. Uno de los primeros ganadores no tenía ningún registro de decisiones hasta que, seis semanas después, una operación de conciliación lo proporcionó. La decisión de apostar en contra de beta existía únicamente dentro de un archivo de memoria en Markdown, por lo que el propio registro contable no habría hecho nada para evitar un nuevo intento.

Lo que surge es un sistema de contexto de múltiples tipos, aunque casi todo sigue funcionando en una sola laptop. SQLite se encarga de las transacciones, el grafo gestiona las relaciones, Parquet es el formato previsto para grandes series temporales, Markdown almacena conocimientos que las personas pueden revisar, y los archivos temporales coordinan los procesos locales.

Aquí aparece un mecanismo real con sus nombres eliminados. La parte izquierda muestra su origen en el grafo de conocimiento, mientras que la derecha muestra cada hipótesis, experimento y candidato que lo puso a prueba. Algunos fallos se repitieron en todas las construcciones, mientras que otros fueron específicos de una implementación concreta. Las dos mitades no comparten nada más que el ID en la unión, y esa única clave es suficiente para unirlas en un paquete de contexto compacto.

Los mecanismos actúan como el vínculo entre las dos bases de datos. En el grafo aparecen como una idea económica junto con sus fuentes, y en el libro mayor como una etiqueta en cada hipótesis y candidato que la aplicó. Los resúmenes empíricos pueden ser reasignados a los nodos del grafo para facilitar la navegación, pero esos son solo reflejos; la base de datos de experimentos sigue siendo donde realmente se encuentran las cifras. Por lo tanto, un buen paquete de contexto se elabora combinando información de distintos sistemas. Incluye un pequeño vecindario del grafo, la procedencia de las fuentes, los resúmenes empíricos actuales, los fallos recientes y las restricciones de la plataforma aplicables. El modelo no necesita el grafo completo ni cada fila de ganancias y pérdidas. Lo que sí es útil es el camino de evidencia más corto hacia la decisión en cuestión.

Cuando el gráfico y el libro mayor comparten un ID de mecanismo, se puede ver juntos todo un ramo: la teoría, los experimentos, cada candidato, y un resumen en el nodo del gráfico que refleja al libro mayor. La idea de autorización de recompra provino directamente de un artículo de 1995, pero nunca se vinculó al ramo de recompras compartidas, por lo que ninguno de sus resultados es accesible desde el gráfico.

Varios contratos de datos merecerían ser más estrictos. Los objetos que cruzan entre almacenes deberían incluir una versión explícita del esquema JSON. Cualquier métrica derivada debería indicar la versión del código, la instantánea de origen y la versión del método que la generó. Cada experimento merece un manifiesto con dirección de contenido para su reproducibilidad, que enumere el commit del código, el resumen del entorno, la configuración de la plataforma, así como los IDs de la hipótesis e implementación. Además, la reconciliación debería probarse como cualquier otra cuestión relacionada con la calidad de los datos, y no considerarse algo inocuo e irrelevante.

En resumen, la postura del diseño es que el gráfico es contexto, el registro también es contexto, y el vínculo entre ellos lo es igualmente. Ese vínculo merece la misma atención en ingeniería que el código del modelo.

Donde esto se encuentra con la ingeniería de harness

Ninguna solicitud se envía completa; cada almacén aporta una pequeña parte a un paquete tipado, y cada especialista recibe únicamente lo que necesita. Los resultados fluyen de vuelta, según su tipo, a los destinos adecuados; las reglas nunca se escriben en ningún lugar, y dos bucles rellenan el siguiente paquete a velocidades diferentes.

Esto marca la línea que separa la ingeniería de contexto de la ingeniería de harness. La gestión de contexto es responsable de los niveles L1 a L3: mantiene las fuentes, mediciones, prioridades, procedencia, marcas de tiempo, alcance e identificadores estables. El nivel L4, el harness agente, decide qué evidencia se recuperará, cuánto se permite pasar por un límite de etapa, qué especialista la recibirá y qué conclusiones son legítimas. Debajo de estos se encuentran el código fuente (L5), la infraestructura local (L6) y la infraestructura distribuida (L7). Estas capas ejecutarán una decisión errónea sin problemas, pero no tienen voz en si una entrada fue una regla, una observación o una creencia.

Una iteración inicial difuminó esa distinción. El archivo principal de instrucciones se convirtió en una wiki de 627 líneas que combinaba reglas de torneo, estado en tiempo real, métodos y las lecciones del día anterior. Después de que se redujo a un pequeño router, el contexto llegaba al agente a través de cuatro rutas. Una capa breve permanece cargada todo el tiempo. Un paquete de inicio transporta lecciones y advertencias actualizadas. Las reglas específicas de cada área se activan solo cuando una tarea afecta esa área, y los roles especializados con sus memorias se recuperan cuando es necesario.

Una solicitud, rastreada paso a paso

Considere la pregunta “¿Qué se debe intentar a continuación?”. El sistema comienza por elaborar un paquete de preflight. Desde L1 obtiene la expresión relevante, así como las restricciones de configuración y puntuación. De L2 provienen el portafolio actual, las mediciones recientes, la cantidad del espacio de búsqueda que ya está cubierto y los resultados aún sin resolver. Desde L3 se toma la rama del grafo más relevante, el origen teórico, los falsificadores definidos, las especificaciones de investigación y las lecciones empíricas.

Luego intervienen los subagentes. Un especialista en hipótesis trabaja a partir de ese paquete para proponer varios enfoques económicos, sin ocultar los razonamientos débiles detrás de las fórmulas. Una vez elegido un enfoque, un especialista en modelado toma la hipótesis registrada y crea implementaciones que difieren realmente entre sí. Un especialista en experimentos recibe el árbol de implementaciones y los límites de la plataforma, y luego registra qué se mide.

Cada etapa tiene su propio destino. El nivel L2 del libro mayor recibe los resultados brutos de la plataforma y las mediciones normalizadas. Los eventos operativos como el inicio de ejecuciones, las llamadas a herramientas, los intentos de reintentar y el tráfico de coordinación pertenecen al almacén de eventos. Cuando un resultado genera una lección o un factor de falsificación específico, se archiva en el nivel L3. Los resúmenes gráficos se obtienen al reconciliarlos con el libro mayor y nunca se editan manualmente, mientras que las grandes series de ganancias y pérdidas, los gráficos y los modelos ajustados se convierten en artefactos a los que apuntan otros registros.

Las dos versiones alfa presentadas partieron de paquetes que ya contenían evidencias. Un grupo había mejorado previamente el portafolio, y la otra idea reutilizó una versión que ya había generado versiones alfa no correlacionadas. Una idea relacionada con un cambio de calificación también recibió un paquete, una celda sin probar en el mapa de oportunidades además de un ganador anterior para imitar, pero todas sus 18 construcciones fracasaron de todos modos.

Etapas de implementación de la infraestructura

Mover todo de una vez sería un error. Cada canal cambia en su propia fase, y una puerta solo se abre cuando un desencadenante medible lo justifica. El lado derecho ilustra la única ruta de escritura en la que se puede confiar (commit, outbox, exporter, projection), en contraste con una escritura dual que genera dos verdades rivales.

La pila local actual puede hacer más de lo que parece. SQLite es una excelente opción por defecto para un investigador individual, ya que ofrece transacciones reales, copias de seguridad sencillas, consultas locales rápidas y casi ningún sobrecosto operativo. Sin embargo, se aprecian ciertas limitaciones: una base de datos de varios gigabytes contiene decenas de millones de filas de series temporales, varios procesos pueden competir por las escrituras locales, los eventos en tiempo de ejecución siguen multiplicándose, los artefactos y las capturas de estado quedan atados a una sola máquina, y reproducir un resultado en otro lugar requiere más estado oculto del que cualquiera desearía. Una evolución en cinco fases tiene sentido.

La Fase 0 consiste en hacer que el diseño se ajuste a la realidad: ya sea completar la migración de PnL incompleta o revertirla conscientemente, y luego automatizar la auditoría que compara la documentación con el almacenamiento en tiempo real. La Fase 1 traslada los archivos voluminosos hacia el exterior, de modo que los datos diarios de PnL, los gráficos, los archivos del modelo, los informes extensos y las instantáneas de la base de datos se almacenan en un sistema de almacenamiento de objetos compatible con S3; el PnL se divide en particiones Parquet comprimidas respaldadas por manifiestos inmutables, checksums y reglas de ciclo de vida. La Fase 2 solo mueve los metadatos cuando la concurrencia obliga a ello. Cuando los trabajadores remotos, varias máquinas o colaboradores deben escribir simultáneamente, el libro mayor y el almacén de eventos se transfieren a PostgreSQL gestionado, ya sea como bases de datos separadas o al menos como esquemas independientes con sus propias políticas de retención. La Fase 3 incorpora MLOps como una proyección y nunca como la fuente de verdad, de modo que herramientas como Weights & Biases o MLflow pueden ser útiles sin reemplazar el libro mayor ni el grafo. La fase 4 separa la orquestación del estado: los trabajadores de investigación se ejecutan en contenedores con manifiestos de tareas inmutables, mientras que un motor de colas o de flujos de trabajo asigna tareas idempotentes con mecanismos de arrendamiento, reintentos y tiempos de espera. La fase 5 ofrece análisis más avanzados solo cuando la carga de trabajo lo justifica. Un formato de tabla tipo lakehouse, una base de datos de grafos dedicada o una plataforma de streaming podrían resultar útiles con el tiempo, pero solo una vez que ciertas consultas comiencen a causar problemas, como búsquedas en miles de millones de observaciones, numerosas traversales de grafos simultáneas, evolución de esquemas en grandes colecciones Parquet o consumidores de eventos de baja latencia.

No se puede atribuir una mejora exacta en el rendimiento a esta arquitectura, ya que su efecto nunca se aisló. Su verdadera contribución es permitir que el sistema se contradiga honestamente. Un artículo lo sugiere, una simulación está en desacuerdo, un falsificador reduce la credibilidad, pero la regla del torneo sigue siendo la misma.

Leer más

• Las cinco capas de un harness de agente, con código que falla sin ellas — Un recorrido práctico por los cinco lugares donde un harness de agente aplica reglas en el código, desde los límites de ejecución hasta las tuberías de contexto, y lo que la investigación puede y no puede demostrar.
• Agentes que se mejoran a sí mismos mediante habilidades: reutilización, selección, reparación y verificación — Un diseño en cuatro partes para agentes que mejoran sus propias habilidades: guardar código funcional, perfeccionar las descripciones, proponer correcciones revisadas y verificar la salida antes de la transferencia.