LiiaLabs · Recherche et architecture

VLLM et VPLLM : une architecture normalisée en couches.

Une proposition pour séparer le modèle de langage, le comportement du système et l’identité privée des agents.

Le modèle est une partie de l’architecture.

Un modèle de langage offre une capacité de génération. En faire une expérience cohérente exige aussi de définir comportement, connaissances, identité et limites. Réunir toutes ces décisions dans un seul prompt rend difficile la distinction entre les règles communes au système et les choix propres à chaque application.

La proposition du laboratoire organise ces responsabilités en couches : le LLM comme base d’inférence, le VLLM comme profil système et le VPLLM comme identité privée. Un canal d’accès présente l’expérience sans devenir une nouvelle identité cognitive.

Vidéo illustrative sur les modèles de langage en couches.

Du modèle à l’expérience

  1. LLM

    Capacité de langage

    Le modèle de base génère les réponses. Il peut être utilisé auprès d’un fournisseur ou sur une infrastructure propre, selon les exigences de l’application.

  2. VLLM

    Comportement partagé

    Virtual Large Language Model : une couche logique qui réunit choix du modèle, paramètres, capacités et consignes communes dans un contrat système.

  3. VPLLM

    Identité et connaissances privées

    Virtual Private Large Language Model : une configuration rattachée à un périmètre, avec une finalité, une identité, un cadre de réponse et des connaissances autorisées.

  4. 04

    Canal d’accès

    Un site, une application ou une intégration présente l’agent. Changer de canal ne doit pas, à lui seul, créer un autre agent ni étendre ses autorisations.

Ce qui doit être normalisé

01

Un contrat commun pour le moteur

Le VLLM décrit la manière dont la capacité de langage est proposée : modèle de référence, paramètres admis et capacités disponibles. Changer de fournisseur exige de valider ce contrat plutôt que de supposer l’équivalence de modèles différents.

02

Une configuration privée aux limites claires

Le VPLLM spécialise le comportement commun par sa finalité, son ton, ses langues et ses sources de connaissances. Son cadre de réponse explicite la référence attendue ; le degré de fidélité souhaité doit être défini et évalué.

03

Une priorité explicite des règles

Une consigne privée peut compléter la politique système, mais ne doit pas supprimer les restrictions centrales. Les contenus récupérés, les documents et les messages des utilisateurs ne sont pas habilités à modifier ces règles.

04

Des autorisations hors du prompt

L’application doit vérifier l’accès aux documents, outils et conversations à chaque opération. Le mot « privé » ne garantit pas l’isolation : identité, autorisation et séparation des données doivent être mises en œuvre.

Versionner la configuration effective.

La normalisation doit permettre d’identifier la combinaison de modèle, de profil VLLM, de configuration VPLLM et de sources de contexte utilisée lors d’une exécution. Une modification ultérieure ne doit pas effacer la référence employée pour évaluer un résultat antérieur.

Avant de promouvoir une nouvelle version du moteur ou du cadre de réponse, il convient d’évaluer des cas représentatifs, de consigner les différences et de prévoir un retour arrière. L’organisation en couches facilite l’évolution, sans remplacer les tests de compatibilité.

Un moteur partagé, deux identités.

Dans un centre de recherche fictif, un même profil VLLM peut prendre en charge différents agents. Les capacités communes sont partagées, mais le contexte autorisé et la finalité de chacun restent distincts.

Guide des visiteurs

Un VPLLM consulte les consignes publiques, horaires et informations de visite. Sa finalité est d’aider les personnes qui arrivent sur place.

Assistant de recherche

Un autre VPLLM travaille avec les documents autorisés d’une équipe. Le partage du moteur ne donne pas au premier agent accès à cette collection.

Normaliser les responsabilités, préserver les différences.

Dans cette proposition, créer un VLLM ou VPLLM ne signifie ni entraîner un nouveau modèle ni réserver une machine dédiée. Ce sont des abstractions de configuration et d’exploitation. Leur valeur dépend de contrats clairs, d’un contexte délimité, de contrôles vérifiables et d’une évaluation continue des réponses.