Un notebook IA pour power users : un kernel, deux paires de mains

Un faux choix est incrusté dans la plupart des outils d'analyse IA. Les produits de chat traitent chaque utilisateur en utilisateur métier : questions en entrée, réponses en sortie - et pour toucher les vraies données, on vous invite à exporter un CSV et à partir. Les produits de notebook font l'erreur inverse : tout le monde est présumé ingénieur, et ceux qui voulaient juste une réponse rebondissent sur la cellule vide. Les deux designs partagent une hypothèse qui mérite d'être rejetée - que le travail de l'IA et le travail de l'expert se passent à des endroits différents.

Vos meilleurs analystes sont des power users. Ils lisent une décomposition de Brinson plus vite que n'importe quel résumé, ils ont des opinions sur les clés de jointure, et ils n'accepteront pas - et ne devraient pas accepter - un chiffre dans lequel ils ne peuvent pas mettre les mains. La question qu'une plateforme sérieuse doit résoudre n'est pas « comment faire pour qu'ils n'en aient plus besoin ? » C'est : où se branchent-ils ?

Un établi, deux paires de mains

Dans DataQube, la réponse est : au même endroit que l'agent. Un fil n'est pas une fenêtre de chat avec une API derrière - c'est un établi avec un kernel vivant, et la conversation est la manière de travailler à cet établi. Le composeur qui accepte les questions ordinaires accepte aussi /py et /sh. Demandez en français, et l'agent interroge, met en forme et calcule ; passez en code, et vous êtes dans la même session - le même kernel, les variables de l'agent intactes, ses dataframes vivants en mémoire.

Voici à quoi cela ressemble - les étapes d'outils de l'agent et une cellule de notebook, dans un même flux :

Rejouer l'exécution

D'après de réelles conversations clients — toutes les données sont fictives.

Reprendre exactement où l'agent s'est arrêté

Le passage de main est le sujet. L'agent a tiré les positions du trimestre, joint l'indice avec le bon décalage et calculé l'attribution - les quatre-vingts pour cent ennuyeux et propices aux erreurs. Une quant qui veut creuser n'exporte rien, ne recharge rien, ne reconstruit rien. Elle ouvre une cellule et continue :

1# /py — att is the agent's attribution frame, still live2top = drilldown(att[att.sector == "Industrials"], level="issuer")3top[["issuer", "selection_bp", "active_weight_bp"]].head(2)4 5#            issuer              selection_bp   active_weight_bp6# Kessler Industrietechnik AG          -41               1307# Nordbahn Systems SE                  -30               110

att est le dataframe de l'agent. Le drill-down prolonge son travail - ici jusqu'au niveau émetteur, jusqu'aux deux noms derrière la perte de sélection du secteur. De là, la quant peut couper les données autrement, introduire un facteur que l'agent n'a pas considéré, ou prototyper l'étape suivante de l'analyse entièrement en code - et l'agent reprend le fil en conversation, car tout est une seule session. C'est du co-travail au sens le plus simple : deux formes d'expertise qui opèrent les mêmes outils sur le même établi, chacune faisant ce qu'elle fait de mieux.

Les deux travaux, un registre

Tout ce qui se passe à l'établi atterrit dans le même registre append-only : les requêtes de l'agent avec leurs références d'audit, les cellules de l'analyste avec les leurs, entrelacées dans l'ordre réel et attribuées à qui a agi. Rien n'est jamais muté en silence - éditez une cellule et vous créez une révision ; les résultats en aval sont marqués périmés jusqu'à réexécution ; l'ancienne version demeure. Quand un chiffre de ce fil atteint un comité, « d'où cela vient-il » a une réponse mécanique qui inclut les contributions humaines : remontez le journal, et le drill-down par émetteur de la quant est juste à côté du calcul d'attribution de l'agent, chacun avec sa propre trace.

Cet entrelacement est ce qui rend le co-travail gouvernable plutôt que chaotique. Le code de l'expert n'est ni un canal parallèle ni un brouillon privé - il est au registre, avec le même rang que le travail de l'agent, visible des mêmes relecteurs sous les mêmes garanties d'audit.

Quand le kernel n'est plus là

Une session vivante a un kernel : des variables en mémoire, des dataframes où fouiller. Les sessions se terminent ; les registres, non. Rouvrez un fil de mars et DataQube est honnête sur la différence - les cellules montrent exactement ce qui a tourné et ce que cela a produit, comme des enregistrements, et rien ne prétend que le kernel de mars est encore chaud. Aucune réexécution silencieuse sur les données d'aujourd'hui avec les horodatages de mars. Quand vous voulez le travail à nouveau vivant, c'est explicite : réexécutez-le dans une session neuve, avec de nouveaux résultats ajoutés comme nouveaux événements - ou extrayez le workflow s'il doit continuer à tourner seul.

Le pari

Ne construisez pas un produit de chat pour le plus grand nombre en exilant les experts vers un autre outil. Construisez un établi : l'agent fait le gros du travail, vos meilleurs éléments travaillent les mêmes données avec du vrai code, et tout ce que les deux ont fait reste sur un seul registre. Le module fils-et-notebooks de la page produit montre où cela vit dans la plateforme - et si vous avez une quant qui ne croit pas que le kernel est vraiment partagé, amenez-la à une démo et laissez-la taper.