SynaLinks est une équipe de recherche appliquée autant qu’une équipe d’ingénierie. Nous écrivons les frameworks avec lesquels se construisent les systèmes d’IA, et nous testons nos propres idées comme nous vous demandons de tester les vôtres : par des expériences contrôlées, reproductibles, publiées avec leur code.
Est-ce qu’un système d’IA tient dans la durée ? Comment l’améliorer quand on ne possède pas le modèle ? Comment prouver qu’une réponse est juste, et pas seulement plausible ? Ces questions se décident en production, chez nos clients, et la littérature commerciale n’y répond pas : elle vend.
Alors nous les traitons comme des questions de recherche. Nous formulons une hypothèse, nous construisons l’expérience qui peut la réfuter, nous mesurons, et nous publions le résultat. C’est plus lent qu’un billet d’opinion, et c’est la seule chose qui nous autorise à vous dire, ensuite, ce qui marchera chez vous.
Chacun de ces axes vit dans nos dépôts open source, où le code est lisible par n’importe qui. Ce n’est pas une feuille de route d’intentions : c’est ce sur quoi nous travaillons.
Améliorer un système d’IA sans réentraîner un seul poids : ses instructions et ses exemples sont optimisés contre une récompense mesurable, comme on entraîne un modèle. C’est ce qui rend possible l’amélioration continue quand vous ne possédez pas le modèle.
Comment savoir qu’un système répond juste, et qu’il ne s’est pas dégradé depuis hier. Jeux de données synthétiques, juges automatiques, métriques d’agents et tests de non-régression lors des changements de modèle.
Contraindre un modèle de langage par la structure et la logique : des sorties valides par construction, un raisonnement inspectable, et des conclusions qui remontent à leurs prémisses plutôt qu’à une intuition statistique.
Transformer des documents en graphes exploitables, puis interroger ces graphes : recherche locale pour les questions précises, recherche globale pour les questions qui portent sur un corpus entier.
Un agent qui écrit et exécute du code est utile, et dangereux. Nous travaillons sur son confinement : isolation du système de fichiers, restriction des appels système, contrôle des accès réseau, capacités accordées explicitement.
Des pipelines où le modèle produit ses propres exemples, où la couche symbolique vérifie et écarte ce qui ne tient pas, et où seul ce qui passe sert à la suite. L’objectif : progresser sur un domaine sans mobiliser vos experts à chaque itération.
La plupart des « benchmarks » publiés comparent en réalité deux systèmes qui diffèrent par dix choses à la fois. Voici les règles que nous nous imposons pour que nos chiffres veuillent dire quelque chose.
Nous partons d’une question à laquelle on peut répondre par un chiffre, décidée avant de lancer quoi que ce soit. Une démonstration montre ce qui marche ; une expérience dit dans quelle mesure.
Même tâche, mêmes découpes d’entraînement, de validation et de test, mêmes modèles, même juge. Tout est tenu constant sauf la chose que nous mesurons, sinon la comparaison mesure autre chose que ce qu’elle annonce.
Chaque expérience tient dans un script exécutable, tourne autant que possible sur des modèles locaux, et conserve ses journaux d’exécution complets. Vous pouvez la relancer chez vous.
Y compris quand le résultat ne nous arrange pas. Une méthode qui n’apporte rien sur une tâche donnée est une information utile, et la taire rendrait tout le reste invérifiable.
Nous menons des travaux de recherche appliquée avec des équipes industrielles et des laboratoires : un verrou technique identifié, un protocole d’évaluation construit ensemble, et un résultat que vous gardez. Le code produit reste le vôtre, et ce que nous publions est convenu avec vous à l’avance.
Si vous avez une question que personne autour de vous ne sait trancher, elle nous intéresse : écrivez-nous, même si elle est encore mal formulée.
Nos travaux servent d’abord nos clients. Le point de départ reste le même : un audit de préparation à l'IA, à périmètre et prix fixes.
