Un notebook de IA para power users: un kernel, dos pares de manos
La mayoría de las herramientas de análisis con IA trata a todos como usuarios de negocio - respuestas dentro, preguntas fuera, expertos desterrados a otra herramienta. DataQube es un banco de trabajo compartido: el agente y sus quants co-trabajan en el mismo kernel, sobre los mismos dataframes, hacia el mismo registro.
Hay una elección falsa incrustada en la mayoría de las herramientas de análisis con IA. Los productos de chat tratan a cada usuario como usuario de negocio: preguntas dentro, respuestas fuera - y si quiere tocar los datos de verdad, se le invita a exportar un CSV y marcharse. Los productos de notebook cometen el error contrario: presumen que todos son ingenieros, y quien solo quería una respuesta rebota contra la celda vacía. Ambos diseños comparten una suposición que vale la pena rechazar: que el trabajo de la IA y el trabajo del experto ocurren en lugares distintos.
Sus mejores analistas son power users. Leen una descomposición de Brinson más rápido que cualquier resumen de ella, tienen opiniones sobre las claves de join, y no aceptarán - ni deberían - un número en el que no puedan meter las manos. La pregunta que una plataforma seria tiene que responder no es "¿cómo hacemos que no lo necesiten?" Es: ¿dónde se enchufan?
Un banco de trabajo, dos pares de manos
En DataQube, la respuesta es: en el mismo sitio donde trabaja el agente. Un hilo no es una ventana de chat con una API detrás - es un banco de trabajo con un kernel vivo, y la conversación es cómo se trabaja en ese banco. El compositor que acepta preguntas normales también acepta /py y /sh. Pregunte en lenguaje natural, y el agente consulta, da forma y calcula; pase a código, y está en la misma sesión - el mismo kernel, las variables del agente intactas, sus dataframes vivos en memoria.
Así se ve - los pasos de herramientas del agente y una celda de notebook, en un mismo flujo:
A partir de conversaciones reales con clientes — todos los datos son ficticios.
Continuar exactamente donde el agente lo dejó
El traspaso es el punto. El agente ha extraído las posiciones del trimestre, unido el índice con el desfase correcto y ejecutado la atribución - el ochenta por ciento aburrido y propenso a errores. Una quant que quiera profundizar no exporta nada, no recarga nada, no reconstruye nada. Abre una celda y continúa:
# /py — att is the agent's attribution frame, still livetop = drilldown(att[att.sector == "Industrials"], level="issuer")top[["issuer", "selection_bp", "active_weight_bp"]].head(2) # issuer selection_bp active_weight_bp# Kessler Industrietechnik AG -41 130# Nordbahn Systems SE -30 110att es el dataframe del agente. El drill-down extiende su trabajo - aquí hasta nivel de emisor, hasta los dos nombres detrás de la pérdida de selección del sector. Desde ahí, la quant puede cortar los datos de otra manera, incorporar un factor que el agente no consideró, o prototipar el siguiente paso del análisis enteramente en código - y el agente lo retoma en la conversación, porque todo es una sola sesión. Esto es co-trabajo en el sentido más llano: dos tipos de pericia operando las mismas herramientas en el mismo banco, cada una haciendo lo que mejor sabe.
Git versiona archivos; un análisis no es un archivo. Es una secuencia de decisiones entrelazada con acceso a datos - y la pregunta interesante rara vez es "qué cambió" sino "de qué dependía este número". El log de eventos responde ambas, y los no ingenieros nunca tienen que aprender qué es un rebase.
Los dos trabajos, un registro
Todo lo que pasa en el banco aterriza en el mismo registro solo-anexado: las consultas del agente con sus referencias de auditoría, las celdas de la analista con las suyas, entrelazadas en el orden en que realmente ocurrió y atribuidas a quien lo hizo. Nada se muta jamás en silencio - edite una celda y crea una revisión; los resultados posteriores quedan marcados obsoletos hasta reejecutarse; la versión antigua permanece. Cuando un número de este hilo llega a un comité, "¿de dónde salió esto?" tiene una respuesta mecánica que incluye las contribuciones humanas: recorra el log, y el drill-down por emisor de la quant está justo al lado de la ejecución de atribución del agente, cada uno con su propio rastro.
Ese entrelazado es lo que hace el co-trabajo gobernable en lugar de caótico. El código del experto no es un canal lateral ni un borrador privado - está en el registro, con el mismo rango que el trabajo del agente, visible para los mismos revisores bajo las mismas garantías de auditoría.
Cuando el kernel ya no está
Una sesión viva tiene un kernel: variables en memoria, dataframes en los que hurgar. Las sesiones terminan; los registros no. Reabra un hilo de marzo y DataQube es honesto sobre la diferencia - las celdas muestran exactamente qué corrió y qué produjo, como registros, y nada finge que el kernel de marzo sigue caliente. No hay reejecución silenciosa contra los datos de hoy con los sellos de tiempo de marzo. Cuando quiera el trabajo vivo otra vez, eso es explícito: reejecútelo en una sesión nueva, con resultados nuevos anexados como eventos nuevos - o extraiga el flujo de trabajo si debe seguir corriendo solo.
La apuesta
No construya un producto de chat para la mayoría y destierre a los expertos a otra herramienta. Construya un banco de trabajo: el agente hace el trabajo pesado, su gente más aguda trabaja los mismos datos con código real, y todo lo que hicieron ambos queda en un registro. El módulo de hilos y notebooks de la página de producto muestra dónde vive esto en la plataforma - y si tiene una quant que no se cree que el kernel de verdad se comparte, tráigala a una demo y déjela teclear.