De 3 jours de lecture de rapports à une requête de 10 minutes

Trois professionnels de l’investissement. 450 entreprises sur leur liste de suivi. Avant chaque comité d’investissement trimestriel, quelqu’un passait deux à trois jours à lire des PDF pour préparer une note qualitative. C’est ce que nous avons construit pour régler ce problème, et ce qu’il a fallu pour bien le faire.

TLDR

Emerald Wealth Partners est un family office privé. Son portefeuille réel est volontairement petit, environ 20 à 25 positions. Mais la liste de suivi qui le soutient est délibérément large : 450 sociétés cotées suivies comme candidats futurs, références concurrentielles et contexte sectoriel. Trois professionnels de l’investissement (un directeur et deux associés) font toute la recherche.

FactSet couvre les données financières. Tout le reste, ce que la direction a dit sur le pouvoir de fixation des prix, la discipline de capital, la position concurrentielle ou l’investissement en IA, venait encore de la lecture manuelle des rapports.

Le problème, c’était le temps. Avant chaque comité d’investissement trimestriel, quelqu’un passait deux à trois jours à lire des PDF pour préparer un résumé qualitatif. Pour une nouvelle position, la recherche approfondie signifiait qu’un associé travaillait sur les quatre derniers rapports annuels d’une entreprise plus les transcriptions récentes des conférences téléphoniques sur les résultats (environ 1 200 pages) pendant plusieurs jours.

Nous avons construit un outil de recherche IA privé sur l’intégralité de leur corpus de recherche : 2 200 rapports annuels et transcriptions de conférences téléphoniques sur les résultats pour 400 entreprises. Les 50 noms restants de la liste de suivi ont été exclus parce qu’ils n’avaient pas quatre ans d’historique de dépôts à la SEC au moment de la constitution du corpus. Le corpus couvre les quatre dépôts annuels les plus récents par entreprise (10-K et 20-F), plus les transcriptions issues des annexes 8-K lorsqu’elles ont été déposées à la SEC.

Posez une question en langage simple. Obtenez une réponse courte et citée. Voyez le passage exact d’où elle vient. Cliquez pour accéder au dépôt SEC ou à la transcription d’origine. Tout tourne sur leur infrastructure. Leurs requêtes ne quittent jamais leur environnement.

10 min

Préparation de la recherche pour le comité d'investissement

Avant : 2 à 3 jours de lecture manuelle par cycle de réunions.

3×

Nouvelles positions évaluées par trimestre

L'équipe évalue désormais 12 à 15 nouveaux noms par trimestre, contre 4 à 5.

0%

Erreurs de citation depuis la mise en service

Chaque réponse renvoie au passage exact du rapport ou de la transcription d'origine.

50+

Requêtes par semaine à 60 jours

Les comparaisons inter-entreprises et l'analyse historique du ton sont les types les plus courants.

Le moment qui a justifié le projet

Les comités d’investissement trimestriels chez Emerald s’articulent autour d’une note qualitative : comment le ton de la direction a évolué dans l’ensemble du portefeuille, ce qui a changé dans le langage des facteurs de risque, si ce que les entreprises ont dit qu’elles feraient dans le dernier rapport annuel se retrouve dans les conférences téléphoniques récentes. Préparer cette note prenait deux à trois jours chaque trimestre.

Avant une réunion en particulier, le directeur voulait une réponse simple. Quinze entreprises de la distribution et de la consommation avaient-elles été cohérentes dans leur façon de parler des droits de douane et de la hausse des coûts ces deux dernières années, ou le langage avait-il discrètement changé ? Répondre à cela signifiait lire environ 60 dépôts trimestriels de ces 15 entreprises, puis recouper le tout avec ce qui avait été dit lors de chaque conférence téléphonique.

L’associé y a passé trois jours. Le comité avait lieu le deuxième jour. Le directeur est entré avec des notes partielles.

Ensuite, elle a dit ce qu’elle disait depuis un an : « Il doit y avoir une meilleure façon de faire. » Cette fois, elle nous a demandé d’évaluer le projet.

Ce qu’ils avaient déjà essayé

L’un des associés avait construit un prototype elle-même : l’API d’OpenAI, quelques PDF téléchargés par session et une interface de chat simple. Cela fonctionnait pour les questions sur une seule entreprise et un seul dépôt. Cela ne pouvait pas garder plus d’un ou deux documents en contexte, ce qui excluait toute question inter-entreprises ou inter-années. Et parfois, les réponses citaient des passages qui, une fois vérifiés dans le dépôt d’origine, ne disaient pas exactement ce que le modèle prétendait.

Elle appelait cela l’hallucination plausible. La mauvaise réponse semble exactement juste. C’est pire que pas de réponse, parce que vous ne savez pas qu’il faut vérifier.

Deux notes d’investissement sont parties en résumant le langage de la direction d’une entreprise sur le pouvoir de fixation des prix en utilisant des citations partiellement fabriquées par le modèle. Les passages cités existaient. Les phrases précises citées, non. Ce n’était pas grave, car les deux notes étaient destinées à une discussion interne.

Quand ils sont venus nous voir, l’exigence était simple : soit la réponse est accompagnée d’une source sur laquelle on peut cliquer et vérifier, soit il n’y a pas de réponse.

FactSet, Bloomberg AI et les outils de recherche IA généralistes ne suffisaient pas

Leur abonnement FactSet gère les données quantitatives avec précision. Quand ils ont besoin de revenus, de marges, de ratios d’endettement ou d’estimations de consensus, FactSet est le bon outil. Ce que le poste de travail standard de FactSet ne fait pas, c’est répondre à « comment cette direction a-t-elle décrit son approche de l’allocation du capital dans les cinq derniers rapports annuels, et ce langage a-t-il changé ? ». Cette question exige de la lecture. FactSet a ajouté des fonctions d’IA ces dernières années, mais elles fonctionnent sur l’univers de données propre à FactSet, pas sur un corpus privé et curaté limité aux 400 entreprises qu’ils suivent réellement.

Les outils de recherche IA généralistes (Perplexity, fonctions d’IA intégrées à diverses plateformes de recherche) citent des articles de presse et des commentaires d’analystes. Pour la recherche fondamentale basée sur des sources primaires, une paraphrase dans un article de presse n’est pas une citation. Vous voulez la phrase du 10-K, pas le résumé que quelqu’un en a fait.

Le prototype de l’associée avait les bons instincts : privé, local, travaillant directement sur les sources primaires. Mais il ne fonctionnait qu’une session à la fois. Il ne pouvait pas contenir une bibliothèque permanente de 2 200 documents. Il ne pouvait pas répondre aux questions inter-entreprises parce qu’il ne pouvait garder qu’un ou deux documents en vue à la fois. Et il inventait des choses assez souvent pour être inutilisable.

Ce qu’il leur fallait, c’était quelque chose qui garde tout le corpus en mémoire en permanence, qui cherche par le sens et par les mots exacts simultanément, et qui refuse de répondre quand les preuves ne sont pas assez solides pour étayer une réponse confiante. Ce dernier comportement (dire « aucune donnée » au lieu de deviner) s’est révélé le plus difficile à construire correctement.

Il y avait aussi une question de données qu’ils ont soulevée tôt et que nous avons prise au sérieux. Ce que Emerald recherche est le signal le plus sensible possible pour un bureau d’investissement. Faire transiter cela par les systèmes d’un fournisseur tiers créait un risque qu’ils n’étaient pas prêts à accepter. L’outil tourne sur leur infrastructure avec leurs clés API. Une requête sur ce que Nvidia a dit de sa capacité de production lors de ses trois dernières conférences téléphoniques ne touche jamais un serveur qu’ils ne possèdent pas.

La construction en sept semaines

Sept semaines entre le coup d’envoi et un outil que l’équipe pouvait mettre devant une vraie note de comité. Chaque semaine a apporté quelque chose de précis, et en sauter une aurait laissé un outil auquel personne ne pouvait réellement faire confiance.

1. 01

   Découverte + cadrage du corpus

   Défini quelles 400 entreprises comptaient vraiment pour la liste de suivi, pour que l'outil réponde aux questions sur le bon univers dès le premier jour

2. 02

   Pipeline d'ingestion : rapports + transcriptions

   2 200 rapports annuels et transcriptions de conférences téléphoniques réunis dans un corpus interrogeable, mis à jour chaque semaine sans intervention d'ingénierie

3. 03

   Recherche plus intelligente + appariement des entreprises

   Le moteur qui garantit qu'une question sur une entreprise ne renvoie pas de réponses sur une autre

4. 04

   Suite d'évaluation (de 13 à 83 cas sourcés)

   Un test permanent pour vérifier que l'outil donne des réponses correctes, pas seulement des réponses plausibles, avant que l'équipe d'investissement ne le voie

5. 05

   Réglage de la récupération + trois versions du même bug

   A comblé l'écart entre « renvoie une réponse » et « renvoie la bonne réponse à chaque fois », y compris des bugs qui auraient attribué des citations à la mauvaise entreprise

6. 06

   Couche de fidélité + visionneuse de sources

   Chaque réponse renvoie à la phrase exacte dont elle provient, pour que rien n'entre dans une note de comité sans pouvoir être vérifié en un clic

7. 07

   Portes CI + livraison

   A verrouillé le niveau de précision en permanence, formé l'équipe et livré un outil qui se tient à jour tout seul

Construit avec : OpenAI pour le moteur de recherche, Supabase pour stocker et interroger le corpus, le flux de données publiques de SEC EDGAR pour récupérer les dépôts, et un pipeline sur mesure pour garder le tout organisé et interrogeable. L’interface de requête est une application web interne légère. Les coûts d’infrastructure et d’API tournent autour de 150 à 250 dollars par mois au volume de requêtes actuel de l’équipe.

Comment faire entrer 2 200 documents dans un corpus interrogeable

Les deux premières semaines étaient de la pure configuration. Rien d’autre ne pouvait être construit tant que les 2 200 documents n’étaient pas récupérés, découpés en morceaux interrogeables et stockés.

Le pipeline récupère chaque dépôt directement sur SEC EDGAR, enlève la mise en forme et divise le document en deux couches. Les petits passages, environ 220 mots chacun, sont ce que la recherche scanne réellement pour trouver la bonne réponse. Les fenêtres plus grandes, environ 650 mots chacune, sont ce que l’outil lit pour rédiger la réponse. Un extrait de 220 mots a rarement assez de contexte autour de lui pour avoir un sens seul. L’outil a besoin du passage plus complet pour expliquer ce qu’il a trouvé.

Les transcriptions des conférences téléphoniques ont exigé une approche différente. Beaucoup d’entreprises déposent leurs transcriptions à la SEC peu après la conférence, en annexe d’un rapport de routine. Le pipeline les récupère comme les autres dépôts, mais il les traite différemment une fois qu’il les a : il garde chaque question d’analyste appariée à sa réponse, au lieu de découper la conversation.

Le corpus inclut aussi des entreprises étrangères de la liste de suivi, comme ASML, TSMC et SAP, qui déposent des types de rapports différents de ceux des entreprises américaines. Le pipeline gère les deux. Certains de ces dépôts étrangers se révèlent être des pages de couverture vierges sans contenu réel. Ils sont consignés et ignorés automatiquement, sans interrompre le reste.

Fin de la semaine 2 : 400 entreprises, 2 200 rapports annuels et transcriptions, environ 160 000 passages interrogeables.

Le pipeline tourne aussi tout seul par la suite, chaque semaine. Quand de nouveaux dépôts arrivent sur le site de la SEC, il les récupère et les ajoute à ce qui existe déjà, sans rien dupliquer ni reconstruire de zéro. Chaque exécution hebdomadaire produit un rapport montrant ce qui a été mis à jour et ce qui a été ignoré, le cas échéant. Aucun ingénieur n’a besoin de le surveiller.

La première version, et pourquoi elle échouait en silence

La première version de la recherche était basique. Une question arrivait, l’outil trouvait les 12 passages qui lui ressemblaient le plus, et c’était la réponse. Aucune vérification de l’entreprise dont parlait réellement la question. Aucune correspondance de mots clés en plus de la recherche par le sens. Aucun moyen de dire « je ne sais pas » quand le corpus n’avait rien de pertinent.

Elle fonctionnait sur les questions directes. « Comment Nvidia a-t-elle évoqué le risque lié à la chaîne d’approvisionnement de l’IA ? » renvoyait des passages de Nvidia. Tout le reste échouait.

Une question sur la pression sur les coûts des intrants pouvait renvoyer trois passages du même dépôt sur un sujet totalement différent, simplement parce que la formulation ressemblait un peu. Une question large comme « quelles entreprises ont mentionné la discipline tarifaire lors de récentes conférences téléphoniques ? » renvoyait la même entreprise six fois, parce que rien ne poussait l’outil à puiser dans plusieurs entreprises. Une question sur une entreprise qui n’était même pas dans le corpus obtenait encore une réponse qui semblait confiante.

Nous l’avons mesuré. Environ deux fois sur trois, le bon passage n’était même pas le premier résultat. Chaque correction suivante visait l’un de ces échecs précis.

Le bug du ticker : trois apparitions

L’échec le plus instructif est apparu trois fois, sous des déguisements différents.

La première version appariait les noms d’entreprises en vérifiant si une partie du nom apparaissait dans la question. Les tickers à une seule lettre ont immédiatement tout cassé. Le ticker d’AT&T est « T ». Le mot « discussed » contient la lettre T. Toute question sur la stratégie IA était routée vers AT&T, et aussi vers Disney, puisque le ticker de Disney, DIS, se trouve dans le mot « discussed ». La correction : ne faire correspondre que des mots entiers, jamais des lettres cachées dans d’autres mots.

Puis le même problème est revenu sous une nouvelle forme, cette fois avec des mots ordinaires intégrés dans les noms légaux d’entreprises. « Companies » fait partie de « Lowe’s Companies, Inc. ». Une question comme « quelles entreprises ont mentionné la discipline tarifaire ? » filtrait les résultats jusqu’à Lowe’s. « Electric » fait partie du nom de General Electric. « Technology » apparaît dans le nom légal complet de plusieurs entreprises du corpus. La correction : tout mot qui apparaît dans le nom de plus d’une entreprise est retiré de la liste d’appariement, ne laissant que les mots qui identifient réellement une seule entreprise.

Troisièmement, les abréviations. Quelqu’un qui tapait « IA » dans une question ne correspondait pas aux dépôts qui écrivaient « intelligence artificielle » en toutes lettres. Un analyste cherchant l’investissement en IA manquait la moitié des résultats sans le savoir. La correction : l’outil développe désormais les abréviations courantes avant de chercher.

Aucun de ces problèmes n’est apparu en lisant simplement le code. Les trois ont été détectés parce que la suite de tests posait une question simple après chaque recherche : quelles entreprises sont réellement remontées, et est-ce la bonne liste ?

Le fantôme de la recherche à 40 secondes

Pendant environ une semaine, les recherches prenaient 40 secondes. Nous avions construit l’index de recherche, confirmé qu’il fonctionnait, et nous regardions chaque question ramper.

La cause était un seul réglage enfoui dans la configuration de recherche de la base de données. Il plafonnait silencieusement chaque recherche à 40 résultats, quel que soit le nombre demandé. Les questions larges qui avaient besoin de 80 résultats pour tirer des réponses de plusieurs entreprises n’en obtenaient que 40, sans aucun avertissement que quelque chose avait été coupé. Les résultats semblaient juste maigres, et le classement paraissait faux. En plus, la recherche faisait du travail supplémentaire inutile en arrière-plan pour chaque grande question, ce qui la ralentissait.

Changer un réglage a tout réglé. Mais trouver ce réglage n’a été possible que parce que la suite de tests posait déjà la bonne question : pourquoi une recherche large continue-t-elle de renvoyer des résultats de la même entreprise ?

Mesure avant de régler

Avant de toucher aux réglages de recherche, nous avons construit une suite de tests étiquetée. Treize cas écrits à la main au départ : des questions qui doivent renvoyer des entreprises précises, des questions qui doivent faire remonter des sujets précis, et des questions qui doivent ne rien renvoyer : des entreprises absentes du corpus, des thèmes absents de tous les dépôts.

À partir de là, la suite a grandi en tirant de vrais sujets du corpus réel et en générant des questions de test autour de six catégories : une seule entreprise, comparaisons côte à côte, tendances historiques, correspondance d’alias, recherches filtrées, et questions délibérément sans réponse, conçues pour vérifier que l’outil dit « aucune donnée » au lieu de deviner. Chaque question de test générée est exécutée contre l’outil en conditions réelles avant d’être ajoutée à la suite. Si l’outil ne peut pas réellement y répondre avec le corpus actuel, la question n’est pas retenue. Rien dans le fichier de tests n’attend une réponse que le corpus ne peut pas donner.

La suite est passée à 83 cas sourcés. La construire a trouvé plus de problèmes que la revue de code.

Une leçon récurrente : les questions de test doivent grandir avec le corpus. « Quelles entreprises ont mentionné l’investissement en IA ? » a été écrit quand seulement une poignée d’entreprises étaient indexées. Face aux 400 entreprises complètes, une bonne réponse fait remonter 20 entreprises distinctes ou plus. Le test d’origine, écrit pour attendre une liste courte et fixe, était faux, pas l’outil. Tout test de ce type vérifie désormais un nombre minimum d’entreprises au lieu d’une liste exacte, pour qu’il reste pertinent à mesure que le corpus grandit.

29 tentatives de réglage, une vraie amélioration

Une fois la suite de tests assez fiable, nous avons essayé de régler la recherche : quel poids donner à la correspondance par le sens par rapport aux mots clés, combien de résultats récupérer pour une question large, et à quel point être strict avant que l’outil fasse assez confiance à une correspondance pour répondre. 29 combinaisons différentes, testées un changement à la fois contre le même ensemble de cas.

Les réglages de départ étaient déjà proches du bon. La seule vraie amélioration : récupérer moins de résultats pour les questions larges (40 au lieu de 80) faisait remonter le bon passage plus haut, plus régulièrement, sans baisse de précision. Un bassin plus petit signifiait que les passages qui répondaient réellement à la question n’étaient pas noyés sous des correspondances plus faibles.

La partie contre-intuitive : combiner la meilleure configuration de chaque catégorie séparément empirait les choses au lieu de les améliorer. Le meilleur équilibre mots clés/sens cassait seul une question de comparaison. La meilleure taille de bassin ne touchait pas cette même question seule. Ensemble, les deux faisaient des dégâts. Chaque changement conservé a été retesté contre la suite complète avant d’être mis en production.

S’assurer que les réponses ne dépassent pas les preuves

Vérifier que chaque citation pointe réellement vers un passage récupéré a été la première protection. Nécessaire, mais pas suffisante à elle seule. Une réponse peut citer de vrais passages et affirmer quand même quelque chose que ces passages ne disent pas.

C’est pourquoi un second modèle d’IA vérifie le travail du premier. Après chaque réponse, il relit la réponse contre ses passages cités et signale toute phrase qui va au-delà de ce que les preuves affirment réellement. La première exécution de ce contrôle a détecté deux problèmes que le contrôle des citations avait manqués.

Une réponse sur Apple, Cisco et IBM contenait une phrase qui semblait raisonnable mais ne figurait dans aucun passage cité. C’était une petite inférence du modèle, pas quelque chose qu’un dépôt disait. Une réponse comparative a récupéré des passages de Tesla et de Rivian mais a généré une réponse qui ne parlait que de Rivian, laissant tomber silencieusement la moitié de la comparaison.

Deux corrections : l’outil dit désormais au modèle exactement quelles citations sont valides, pour qu’il cesse d’inventer des numéros de citation qui ne pointent vers rien de réel. Et quand rien de ce que le modèle écrit ne passe le contrôle de précision, la réponse de repli affiche maintenant 5 passages bruts au lieu de 3, pour que les deux côtés d’une comparaison apparaissent même dans le repli.

Ces deux corrections ont fait passer le taux de réussite du contrôle de précision de 8 sur 10 à un 10 sur 10 net.

Trois choses qui ont cassé

L’évaluation mesurait la mauvaise chose

Trois semaines plus tard, nous avons exécuté la suite et obtenu un taux de réussite qui semblait sain. Puis nous avons regardé ce que « réussite » signifiait réellement pour une catégorie de cas.

Plusieurs questions avaient des attentes de listes d’entreprises fixes écrites quand le corpus contenait une poignée d’entreprises. Face à 400 entreprises, une bonne réponse à « quelles directions ont mentionné la pression sur la chaîne d’approvisionnement lors de récentes conférences téléphoniques ? » fait remonter 30 ou 40 entreprises distinctes. Le test à trois entreprises que nous avions écrit était faux, pas l’outil. Nous marquions des réponses correctes comme des échecs et obtenions un taux de réussite qui semblait sain pour la mauvaise raison.

Corriger ces tests a pris une demi-journée. La même chose est arrivée deux semaines plus tard, une fois de nouvelles entreprises étrangères ajoutées. Les questions de test exigent un entretien continu. Les écrire une fois et les oublier ne fonctionne pas.

La détection des entreprises a cassé après une mise à jour du corpus

Le lendemain de l’ajout de 28 nouvelles entreprises au corpus, l’outil a commencé à en manquer certaines dans ses résultats. Pas souvent. Mais assez souvent pour compter.

Deux des nouvelles entreprises avaient des mots de nom qui auraient dû être exclus de l’appariement, la même règle du « apparaît dans le nom de plus d’une entreprise » du bug du ticker. Mais cette liste d’exclusion avait été construite à la main au départ et n’avait jamais été revérifiée à mesure que de nouvelles entreprises étaient ajoutées. Elle était devenue obsolète.

La correction : à chaque ajout d’une nouvelle entreprise, le système vérifie automatiquement son nom contre la liste d’appariement existante, signale tout conflit avant que l’entreprise ne soit mise en service, et écrit un résumé clair de ce avec quoi elle correspondra. Quelqu’un peut vérifier ce résumé sans lire de code. Ce contrôle s’exécute désormais à chaque mise à jour, pas seulement la première fois.

La limite du « aucune donnée » a bougé pendant le développement

L’outil a une règle intégrée pour les questions auxquelles il ne peut pas réellement répondre. Si les preuves trouvées sont trop minces pour étayer une vraie réponse, il dit « aucune donnée trouvée » au lieu de deviner. C’était une exigence centrale depuis le premier jour. L’équipe avait déjà été brûlée une fois par des réponses qui semblaient confiantes et étaient fausses.

Mais pendant que le corpus était encore en construction, certaines entreprises n’avaient que deux ou trois dépôts indexés. Les questions sur ces entreprises franchissaient parfois la barre du « assez de preuves » sur un point technique, et produisaient des réponses techniquement sourcées mais trop minces pour être utiles. Un associé ne pouvait pas dire si une réponse faible signifiait un vrai problème de l’outil, ou simplement que les dépôts de cette entreprise n’étaient pas encore entièrement chargés.

Nous avons ajouté un indicateur de couverture : quand l’entreprise interrogée a moins de cinq documents indexés, la réponse inclut une note indiquant que la couverture est limitée. « Le système ne peut pas répondre à cela » et « le corpus n’en a pas encore assez » sont des situations différentes avec des réponses différentes : la seconde a une voie de résolution.

Les résultats à 60 jours

L’équipe d’Emerald a commencé à utiliser l’outil dès la première semaine après la mise en service. Le retour qualitatif a été constant : l’outil a supprimé le goulot d’étranglement, pas la réflexion. Trouver ce que Nvidia a dit sur l’investissement en capacité lors de ses quatre dernières conférences téléphoniques prend 10 minutes et renvoie les passages exacts avec les liens sources. Ce que cela signifie pour la thèse d’investissement reste le travail de l’associé, et cela prend toujours le temps nécessaire.

10 min

Préparation du comité d'investissement

Une note de recherche qui prenait 2 à 3 jours est désormais préparée le matin de la réunion.

12–15

Nouvelles positions évaluées par trimestre

Contre 4 à 5 avant. La même équipe de trois personnes.

50+

Requêtes par semaine

Surtout des comparaisons inter-entreprises et de l'analyse historique du ton : les questions que la lecture manuelle ne pouvait pas du tout traiter.

0

Erreurs de citation depuis la mise en service

Chaque [1] a été vérifié contre la source d'origine. Le contrôle de fidélité s'exécute sur chaque réponse.

Le plus grand changement n’était pas la vitesse des requêtes individuelles. C’était les questions que l’équipe prend la peine de poser. Quelque chose comme « comment cette direction a-t-elle décrit sa philosophie d’allocation du capital ces cinq dernières années, et le langage est-il devenu plus ou moins précis ? » représentait autrefois une semaine de travail, alors personne ne la posait. Maintenant, cela prend 15 minutes, alors ils la posent.

Ici, le sur mesure avait du sens ; une plateforme, non

Pour les équipes avec de petits ensembles de documents et des besoins de recherche occasionnels, un outil IA généraliste (ou même un espace NotebookLM bien tenu) est probablement suffisant. Ce projet avait du sens pour Emerald pour trois raisons précises.

D’abord, le corpus est trop grand et change trop souvent pour tout outil qui ne fonctionne qu’une session à la fois. 2 200 documents à la livraison, et en croissance chaque semaine à mesure que de nouveaux rapports annuels et transcriptions sont déposés. Téléverser les documents à nouveau à chaque session ne peut pas suivre ce rythme.

Deuxièmement, l’intégrité des citations n’est pas négociable. Les décisions d’investissement (même internes) dépendent de la capacité à vérifier la source de chaque affirmation. Le contrôle de fidélité et les liens profonds vers les dépôts d’origine ne sont pas des options. Ce sont le produit.

Troisièmement, la sensibilité des données. L’activité de recherche d’un bureau d’investissement (ce qu’il étudie, quelles entreprises il sonde, quelles questions il pose sur la crédibilité de la direction ou la discipline de capital) est un signal propriétaire. Faire traiter cela par une plateforme IA tierce crée une exposition qu’ils n’étaient pas prêts à accepter. Chaque requête reste dans leur environnement.

Ce que nous ferions différemment

Nous démarrerions la suite de tests en semaine 1, pas en semaine 4. Le bug du ticker aurait été attrapé dès la première semaine au lieu de trois semaines plus tard. Le ralentissement à 40 secondes aurait été évident dès le premier jour, puisque « pourquoi une question large continue-t-elle de renvoyer des résultats de la même entreprise ? » est exactement le genre de question qu’une suite de tests est faite pour poser, pas quelque chose dans lequel on tombe par accident plus tard. Nous avons construit la suite de tests comme un outil de développement et n’avons découvert sa vraie valeur que grâce à ce qu’elle a attrapé en chemin. Nous aurions dû savoir à quoi elle servait avant d’en avoir besoin.

Nous serions aussi plus agressifs sur la composition du corpus en semaine 1. Emerald avait une idée claire des entreprises qui comptaient, mais aucune définition écrite de l’univers de couverture réel de l’outil. Certaines entreprises étaient sur la liste de suivi pour des raisons claires. D’autres y étaient pour des raisons historiques que personne ne pouvait reconstituer. Relancer une entreprise dans le pipeline ne fait que la mettre à jour au lieu de créer un doublon, donc plus la liste d’entreprises est verrouillée tôt, plus l’appariement des noms reste stable et plus les questions de test restent valides.

Troisièmement, nous mettrions une version en lecture seule devant un associé en semaine 4 au lieu de la semaine 7. Nos propres tests attrapent les bugs de logique. Les vraies questions de recherche attrapent tout le reste : des noms d’entreprises que nous n’avions pas prévus, des transcriptions de conférences téléphoniques mal découpées, des questions formulées comme les associés parlent réellement au lieu de comme nous l’imaginions. Une personne passant une semaine sur de vraies questions nous a appris plus que 20 autres questions que nous avions écrites nous-mêmes.

Commencez la suite d’évaluation dès le premier jour, figez le corpus avant de régler quoi que ce soit, et mettez un vrai utilisateur devant une version fonctionnelle le plus tôt possible. La construction devient plus facile quand vous savez ce que vous mesurez réellement. Tout le reste est de la devinette éclairée.