IA en production
Développement IA : votre premier workflow en production en 21 jours
Nous mettons l'IA à l'intérieur des systèmes qui font déjà tourner votre activité. Un runtime d'agent en Go, des outils typés vers votre ERP, votre CRM, votre file de tickets et votre mainframe, une validation sur tout ce qui écrit, et une suite d'évaluations en CI qui casse le build quand les réponses se dégradent. N'importe quelle pile, n'importe quel secteur, d'un seul workflow à une plateforme que vos ingénieurs font tourner eux-mêmes.
21 jours jusqu'au premier workflow en production
La ligne barrée est la partie que la plupart des pilotes sautent, et sans elle personne ne peut dire si le modèle s'est dégradé la semaine dernière.
Prototype
Un notebook qui marche sur des données de démo et une API fermée.
- spec.docxWord
- proof-of-conceptPython · notebook
- vendor APIclosed
- evalnone
Production
Un service avec des outils à appeler, des tests qui peuvent échouer, et des traces consultables.
- agent runtimeGo
- tool layerTypeScript
- eval harnessCI gate
- tracesOpenTelemetry
21 jours jusqu'au premier workflow en production
Comment le travail se déroule
- 01jours 1–2
Choisir un workflow
Un processus avec du volume et une bonne réponse. Nous mesurons ce qu'il vous coûte aujourd'hui en minutes et en erreurs, parce que c'est ce chiffre qui servira à juger le résultat.
- 02jours 2–6
Constituer le jeu d'évaluation d'abord
Quelques centaines de cas réels tirés de votre historique, chacun avec la réponse qu'ont donnée vos équipes. C'est la partie ingrate du projet, et la raison pour laquelle tout ce qui suit se démontre au lieu de se discuter.
- 03jours 5–16
Construire le runtime et les outils
Runtime d'agent en Go, adaptateurs typés vers vos systèmes, une validation sur tout ce qui écrit. Les évaluations tournent à chaque commit dès le premier jour.
- 04jours 14–21
Mettre en production et passer la main
Les traces, un runbook, et une journée avec vos ingénieurs pour qu'ils changent prompts et outils sans nous appeler. La passation est comprise dans le prix.
Ce que fait la plateforme, ce que fait un humain
| Ce que fait la plateforme, ce que fait un humain | Qui fait quoi | Notes |
|---|---|---|
| Lire le code et trouver les points d'intégration | Plateforme | Quelques heures sur un dépôt qu'une personne mettrait une semaine à lire. |
| Choisir le workflow qui passe en premier | Ingénieur | Du volume, une réponse vérifiable, et quelqu'un chez vous qui porte le résultat. |
| Écrire les adaptateurs vers vos API | Les deux | La plateforme rédige d'après le contrat d'API. Un humain corrige ce sur quoi le contrat mentait. |
| Constituer le jeu d'évaluation depuis votre historique | Les deux | Extraire les cas est automatique. Décider quelles réponses passées étaient justes ne l'est pas. |
| Rejouer les régressions à chaque commit | Plateforme | Une baisse casse le build, comme le ferait un test unitaire cassé. |
| Décider ce que l'agent a le droit d'écrire | Ingénieur | Votre risque, votre décision, écrite avant que quoi que ce soit tourne. |
Qui travaille sur votre projet
Des dizaines de migrations derrière nous et plus de dix ans passés dans les systèmes des autres. Les ingénieurs qui ont mis des services Go et TypeScript en production à côté de COBOL, RPG, VB6, Delphi et PHP sont ceux qui construisent la couche agent. C'est pour cela que notre IA finit à l'intérieur des systèmes qui portent votre argent, au lieu de rester à côté.
Donnez-nous un accès en lecture et la plateforme sort en quelques jours la carte des modules et la liste du code mort de votre propre système. Vous gardez ce document que vous nous embauchiez ou non, et c'est le moyen le plus rapide de voir comment nous travaillons.
Questions que nous posent les ingénieurs
- Est-ce un wrapper autour d'une API de chat ?
- Il y a un modèle dedans, comme il y a une base de données dans votre facturation. Le travail, c'est la couche d'outils, les points de validation et les évaluations qui vous disent quand une mise à jour du modèle a dégradé les choses. Appeler une API est la partie bon marché ; savoir quand la réponse est fausse est ce que vous payez.
- Que se passe-t-il quand le modèle change sous nos pieds ?
- La suite d'évaluations tourne contre le modèle candidat avant tout basculement. Si le score baisse, vous restez sur l'ancien jusqu'à ce que les prompts et les outils rattrapent.
- Où tourne notre code pendant que vous travaillez dessus ?
- Là où vous l'exigez, y compris entièrement dans votre réseau ou votre compte cloud. Nous avons travaillé sous VPN client, sur des machines de build coupées du réseau et sur du matériel qui n'a jamais quitté le bâtiment ; le détail passe dans le contrat.
- À qui appartient ce que vous construisez ?
- À vous. Des dépôts Go et TypeScript ordinaires, des bibliothèques ordinaires, aucun appel qui revient chez nous à l'exécution. Notre plateforme est notre façon de travailler, ce n'est pas quelque chose que vous finissez par louer.
- Notre équipe pourra-t-elle le maintenir après ?
- C'est à cela que sert la passation, et c'est pourquoi la couche d'outils est typée et les prompts vivent dans le gestionnaire de versions plutôt que dans la console d'un éditeur. Vos ingénieurs changent une définition d'outil, relancent les évaluations et livrent, sans nous dans la pièce.
Envoyez-nous le workflow
Nommez le processus que vous automatiseriez en premier et ce qu'il vous coûte quand il déraille. En retour : comment nous le construirions, en combien de temps et à quel prix, sous deux jours ouvrés.
Quatre écrans : le système, ce qui fait mal, où vous voulez arriver, comment vous joindre. Aucun rendez-vous n'est pris si vous n'en demandez pas.