Philosophie
Hypothèses de travail
Description des problèmes traités par le projet et des conséquences architecturales qui en découlent.
I. Point de départ
Ce que le projet prend pour problème
Le projet ne part pas de l'hypothèse qu'un modèle de langage comprend au sens humain du terme. Il part d'une difficulté plus restreinte : comment organiser techniquement un système de dialogue qui tienne un historique, traite des documents, réexamine certaines inférences et garde une trace explicite de ses opérations.
Le prompt utilisateur est traité ici comme un texte. Le sens n'est pas supposé résider entièrement dans ce texte, ni entièrement dans le modèle. Il est recherché dans la rencontre entre un texte, un état de système, des matériaux mémoriels ou documentaires et une suite d'opérations de traitement.
La question porte donc moins sur une attribution métaphysique de compréhension que sur les conditions techniques sous lesquelles un événement de compréhension peut parfois avoir lieu dans un dialogue. Cela engage le statut du contexte, de la mémoire, des résumés, des documents injectés, des signaux de jugement et des procédures de révision.
Dans Frida, ces questions sont traitées comme des questions d'architecture : séparation des modules, contrats de persistance, hiérarchie des matériaux textuels, conditions d'injection de la mémoire, temporalité des états et formes d'observabilité.
II. Critique fondamentale
Au-delà de la plausibilité
Le recours à un modèle génératif n'est pas en lui-même contesté. Ce qui pose problème est le fait de laisser la plausibilité locale d'un texte tenir lieu, à elle seule, de mémoire, de validation ou de jugement.
Une réponse peut être fluide et néanmoins mal située, insuffisamment fondée ou en contradiction avec des tours antérieurs. Le projet cherche donc à décrire et à construire des médiations entre génération et réponse finale : mémoire, résumés, arbitrage, validation, régime dialogique et contraintes documentaires.
Le problème n'est pas de produire un style de réponse différent, mais de déterminer à quelles conditions un énoncé peut être retenu, révisé, reformulé ou suspendu.
Texte plausible, position incertaine
Un texte peut être bien formé sans que sa position dans le dialogue soit suffisamment déterminée. La cohérence locale ne suffit pas à produire une continuité exploitable.
L'incertitude doit rester formulée
Lorsqu'un conflit, une lacune ou un mode dégradé apparaît, il doit pouvoir être décrit. Le problème n'est pas l'incertitude elle-même, mais sa dissimulation.
Révision et suspension
Une sortie valable peut consister à réviser une inférence, à demander une précision, à signaler un conflit ou à suspendre la réponse.
III. Mémoire et temps
Mémoire, trace et continuité
Le projet distingue explicitement plusieurs types de matériaux : tours, traces persistées, résumés, snippets récupérés, documents injectés, sorties de validation, journaux opérateur. Ces matériaux n'ont ni le même rôle, ni le même degré de fiabilité, ni la même destination dans le pipeline.
Cette distinction est nécessaire pour éviter qu'une mémoire de dialogue ne soit traitée comme une simple accumulation. Une trace n'est pas un résumé. Un résumé n'est pas une preuve. Un document injecté n'est pas un souvenir récupéré. Un journal d'exécution n'est pas un contenu de dialogue.
Le problème de la continuité consiste alors à maintenir des relations explicites entre ces éléments, à en gérer la temporalité et à rendre possible la révision lorsqu'un tour ultérieur modifie l'état de la question.
Le système n'est pas seulement requis pour accumuler du passé. Il doit aussi pouvoir se situer dans le temps, conserver des différences de régime entre tours, stabiliser certains états, en laisser tomber d'autres et maintenir une identité technique mutable plutôt qu'un simple historique plat.
IV. Herméneutique
L'interprétation comme processus situé
Le terme d'herméneutique est employé ici dans un sens opératoire. Il désigne le fait qu'un énoncé n'est pas traité indépendamment de sa position dans le dialogue, de son contexte d'énonciation et des matériaux mémoriels ou documentaires qui lui sont associés.
Le pipeline est, dans cette perspective, le lieu technique de la rencontre. C'est là que sont distribuées les opérations de mémoire, de résumé, de récupération, de validation, de régime dialogique et d'injection documentaire. Le projet ne cherche pas à attribuer une compréhension substantielle au modèle ; il cherche à coder et à expliciter ces médiations.
Dans FridaDev, cette orientation apparaît sous la forme d'une branche herméneutique explicite dans le pipeline public. Dans Frida_V4, non public à ce jour, des modules distincts travaillent des problèmes voisins, notamment le régime dialogique, l'arbitrage mémoire et le traitement des documents.
Il ne s'agit pas de psychologiser le système. Il s'agit de construire des opérations situées, bornées et révisables, dont les effets puissent être décrits et discutés.
VI. Évaluation
Lecture du dialogue et métriques auxiliaires
Le projet ne réduit pas l'évaluation à des métriques agrégées. Certaines mesures sont utiles : fréquence des reformulations, suspensions, transitions de régime, retours mémoire, conflits détectés, états de validation ou persistance d'un signal sur plusieurs tours.
Cependant, ces mesures ne suffisent pas à elles seules. Le critère principal reste la lecture du dialogue lui-même, c'est-à-dire la justesse avec laquelle un enchaînement textuel est tenu, repris, corrigé ou suspendu. Autrement dit, l'évaluation garde une dimension exégétique.
Le site public n'essaie donc pas de convertir toute validité en courbes. Il décrit des modules, des hypothèses et des documents; il n'efface pas la nécessité d'une lecture située des échanges.
V. Éthique
Conséquences architecturales
Ces hypothèses ont des conséquences directes sur l'architecture. Un système de dialogue ne se réduit pas à un appel modèle. Il suppose des choix de persistance, de journalisation, de hiérarchie des matériaux, de statut des documents et de formes de visibilité pour l'opérateur.
Le projet attache donc de l'importance aux contrats de streaming, aux procédures de sauvegarde canonique, aux surfaces d'inspection et aux modalités de révision. Ces éléments ne sont pas périphériques : ils conditionnent ce que l'on peut réellement soutenir sur le comportement du système.
Le site public doit être cohérent avec cette exigence. Il ne doit pas présenter comme disponible ce qui ne l'est pas, ni attribuer au projet des propriétés qui ne seraient pas soutenues par les dépôts, les documents et l'état effectif du travail.