comment-le-faire-avec-deepinfra-pour-gerer-des-formats-onthologies-dont-saferener

DeepInfra

DeepInfra expose des endpoints OpenAI-compatibles, ce qui permet d’utiliser des SDK ou appels API similaires aux appels OpenAI.

Exemple simplifié côté Node.js :


const response = await fetch("https://api.deepinfra.com/v1/openai/chat/completions", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.DEEPINFRA_API_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "qwen-or-mistral-model-name",
    messages: [
      {
        role: "system",
        content: `
Tu es un assistant de structuration sémantique.
Tu dois produire uniquement un JSON-LD valide.
Tu dois utiliser les vocabulaires fournis : ETIM, Haystack, SAREF4ENER, Energy Core.
Tu ne dois pas inventer de propriété non autorisée.
Si une information est incertaine, ajoute requiresHumanValidation = true.
`
      },
      {
        role: "user",
        content: `
Document extrait :
${extractedText}

Contexte dictionnaire :
${ragContext}

Produit attendu :
JSON-LD pour un équipement énergie exploitable par un EMS Overlay.
`
      }
    ],
    response_format: {
      type: "json_object"
    }
  })
});

const result = await response.json();

Pour Mistral, le JSON mode est officiellement documenté ; la documentation recommande aussi d’indiquer explicitement dans le prompt que la réponse doit être en JSON.

Pour Qwen, la documentation Alibaba Cloud indique aussi un usage de response_format avec json_object et demande que le prompt contienne explicitement le mot JSON.

7. Pipeline technique recommandé

Étape 1 — Préparer les dictionnaires

Vous créez des tables ou collections :

etim_classes
etim_features
haystack_tags
saref4ener_terms
energy_core_concepts
jsonld_contexts
shacl_shapes

Le LLM ne doit pas “inventer” l’ontologie. Il doit sélectionner dans des dictionnaires contrôlés.

Étape 2 — RAG avant appel LLM

Avant d’appeler Qwen ou Mistral, vous récupérez uniquement le contexte utile :

Document : fiche batterie
↓
RAG recherche :
- classes ETIM proches
- tags Haystack proches
- concepts SAREF4ENER pertinents
- concepts Energy Core pertinents
↓
Prompt compact

Cela évite d’envoyer tout ETIM ou tout SAREF au LLM.

Étape 3 — Générer un JSON-LD candidat

Le LLM produit un objet :


status = draft
confidence = 0.78
requiresHumanValidation = true

Il faut éviter de publier directement.

Étape 4 — Validation déterministe

Après la réponse LLM :

1. Vérifier JSON valide
2. Vérifier JSON Schema / Zod
3. Vérifier contexte JSON-LD
4. Faire expansion JSON-LD
5. Appliquer SHACL
6. Extraire relations critiques
7. Stocker dans PostgreSQL

Étape 5 — Stockage

Table principale :


CREATE TABLE semantic_objects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  source_system TEXT NOT NULL,
  source_ref TEXT NOT NULL,
  object_type TEXT NOT NULL,
  ontology_profile TEXT NOT NULL,
  jsonld JSONB NOT NULL,
  llm_model TEXT,
  llm_confidence NUMERIC,
  validation_status TEXT DEFAULT 'draft',
  created_at TIMESTAMPTZ DEFAULT now(),
  updated_at TIMESTAMPTZ DEFAULT now()
);

Table de relations extraites :


CREATE TABLE semantic_relations (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  subject_id TEXT NOT NULL,
  predicate TEXT NOT NULL,
  object_id TEXT NOT NULL,
  source_object_id UUID REFERENCES semantic_objects(id),
  confidence NUMERIC,
  status TEXT DEFAULT 'candidate'
);

C’est cette table semantic_relations qui remplace partiellement le graphe RDF pour un MVP.

8. Ce que l’EMS consomme

L’EMS ne doit pas appeler le LLM à chaque décision.

Mauvais design :

EMS temps réel → appel LLM → décision de pilotage

Trop lent, trop incertain, trop difficile à auditer.

Bon design :

LLM → prépare les descriptions sémantiques
Validation → publication
EMS → consomme les objets validés

Exemple d’objet publié vers l’EMS :

{
  "equipmentId": "zendure-4000-pro-001",
  "type": "StorageAsset",
  "controllable": true,
  "canCharge": true,
  "canDischarge": true,
  "minSoc": 20,
  "backupReserve": 30,
  "availableControlPoints": [
    "chargeLimit",
    "dischargeLimit",
    "operatingMode"
  ],
  "semanticSource": "saref4ener-jsonld",
  "validationStatus": "validated"
}

9. Cas d’usage où Qwen / Mistral apportent beaucoup

Cas	Apport du LLM
Lire une fiche PDF	Extraction intelligente
Trouver la bonne classe ETIM	Matching sémantique
Mapper vers Haystack	Tags proposés automatiquement
Ajouter SAREF4ENER	Flexibilité, profils, événements
Créer un JSON-LD	Génération structurée
Corriger une incohérence	Réparation assistée
Expliquer à l’expert	Justification lisible
Générer des tests SHACL	Proposition de contraintes
Requête en langage naturel	Traduction vers SQL/JSON ou SPARQL

10. Ce qu’il faut éviter

Erreur	Risque
LLM seul comme base de données	Pas de persistance fiable
LLM seul comme validateur	Erreurs silencieuses
Tags libres inventés	Pollution de l’ontologie
Publication automatique vers EMS	Mauvaise décision énergétique
Prompt trop large avec tout ETIM	Coût, lenteur, confusion
Pas de versioning	Audit impossible
Pas de validation humaine	Risque métier

11. Architecture cible pour votre projet

Odoo
= source de vérité métier

PostgreSQL / Supabase
= stockage JSON-LD, mappings, embeddings, cache relationnel

DeepInfra / Qwen ou Mistral
= génération et mapping sémantique

Semantic API
= orchestration, validation, versioning

SHACL / JSON Schema
= garde-fous

EMS Overlay
= décision énergétique sur objets validés

Visuellement :

PDF / CCTP / DPGF / datasheet
        ↓
OCR / parsing
        ↓
RAG dictionnaires
        ↓
LLM DeepInfra
        ↓
JSON-LD candidat
        ↓
Validation JSON Schema + SHACL
        ↓
PostgreSQL jsonb + semantic_relations
        ↓
Human Review
        ↓
Published semantic profile
        ↓
EMS Overlay

12. Conclusion

Oui, vous pouvez utiliser un LLM open source sur DeepInfra pour “gérer” les JSON-LD, mais uniquement comme moteur de génération, mapping, enrichissement et réparation.

La meilleure formulation serait :

Le LLM ne remplace pas GraphDB comme base graphe.
Il remplace une partie de l’effort humain de modélisation sémantique.

L’architecture que je recommande :

Pas de GraphDB au début.
PostgreSQL jsonb + pgvector + semantic_relations.
LLM DeepInfra pour générer les JSON-LD.
SHACL / JSON Schema pour valider.
Odoo comme vérité métier.
EMS uniquement alimenté par les objets validés.

C’est plus léger, plus rapide à développer, moins coûteux, et parfaitement compatible avec une montée en puissance future vers GraphDB ou Apache Jena si vous avez ensuite besoin de SPARQL lourd et d’inférence RDF.