TL;DR en langage simple
- Kremis est décrit sur GitHub comme « a minimal graph engine for grounded AI — records, associates, and retrieves, but never invents ». Le projet est écrit en Rust. Source : https://github.com/M2Dr3g0n/kremis
- But pratique : cloner le dépôt, compiler localement avec cargo (outil Rust), exécuter un petit « harness » de validation et vérifier que deux exécutions produisent exactement la même sortie.
- Ce guide montre les étapes concrètes pour obtenir un démonstrateur local et pour ajouter des vérifications simples de reproductibilité.
Exemple concret (scénario court)
- Équipe : 2 développeurs.
- Objectif : prouver qu'une requête sur le moteur produit les mêmes résultats deux fois.
- Étapes : cloner le dépôt, compiler (cargo build --release), lancer le binaire avec une entrée contrôlée (fichier JSON), sauvegarder la sortie, relancer et comparer bit-à-bit.
Plain-language note avant les détails avancés
- Ce guide est divisé en étapes claires : préparation, build, test de reproductibilité et recommandations pour CI (intégration continue).
- Les détails « avancés » sont les commandes de compilation, la mise en place du harness et les recommandations CI. Ils sont expliqués de manière simple avant les blocs techniques.
Ce que vous allez construire et pourquoi c'est utile
Vous allez construire un démonstrateur local minimal basé sur le dépôt suivant : https://github.com/M2Dr3g0n/kremis. Le démonstrateur fera trois choses simples :
- Ingest (charger) une entrée contrôlée.
- Exécuter une requête via le binaire compilé.
- Comparer deux exécutions pour confirmer la reproductibilité des résultats.
Pourquoi c'est utile
- Audit et traçabilité : un moteur de graphe minimal est plus simple à auditer. Vous pouvez suivre comment les associations sont créées et retournées.
- Reproductibilité : vérifier que deux runs donnent le même résultat réduit les risques liés à des éléments non déterministes.
- Outils standards : le dépôt indique que le projet est écrit en Rust. Vous utiliserez donc la chaîne d'outils Rust standard (rustup, cargo). Source : https://github.com/M2Dr3g0n/kremis
Remarque méthodologique
- Toute étape opérative non décrite explicitement dans le dépôt est traitée ici comme une hypothèse et listée dans la section finale « Hypotheses / inconnues ».
Avant de commencer (temps, cout, prerequis)
Source principale : https://github.com/M2Dr3g0n/kremis
Prérequis logiciels et accès
- Git disponible pour cloner : git clone https://github.com/M2Dr3g0n/kremis
- Chaîne d'outils Rust (rustup / cargo) installée
- Accès réseau pour récupérer le dépôt
Checklist initiale
- [ ] Accès réseau et possibilité de cloner le dépôt
- [ ] rustup / cargo installés et testés
- [ ] Répertoire de travail prêt pour builds locaux
Estimation de temps (à valider)
- Clone + build initial : 60–120 minutes (hypothèse, voir section finale).
- Écriture du harness et tests automatisés : 30–180 minutes.
Installation et implementation pas a pas
Plain-language : vous allez cloner le dépôt, compiler le code et créer un petit script qui envoie une entrée connue au binaire. Ensuite vous sauvegarderez la sortie et la comparerez entre deux runs.
- Cloner et inspecter
git clone https://github.com/M2Dr3g0n/kremis
cd kremis
ls -la
- But : récupérer les sources et vérifier l'arborescence.
- Compiler le projet (chaîne Rust standard)
# compilation release (pratique habituelle pour un démonstrateur)
cargo build --release
# optionnel : exécuter les tests unitaires si présents
cargo test --lib -- --nocapture
- Explication : cargo est l'outil officiel de gestion et de compilation pour Rust. --release génère un binaire optimisé.
- Si la compilation échoue, voir la section « Problemes frequents et correctifs rapides ».
- Préparer un harness minimal (concept et exemple)
Plain-language : le « harness » est un petit script qui fournit une entrée contrôlée au binaire et enregistre la sortie dans un fichier. Vous lancez ce script deux fois et vous comparez les fichiers.
Exemple simple (bash)
# hypothetically run the compiled binary with a controlled input file
./target/release/kremis --input test/input.json > out1.json
# run again
./target/release/kremis --input test/input.json > out2.json
# compare
cmp --silent out1.json out2.json && echo "IDENTICAL" || echo "DIFFER"
- Adaptez les arguments du binaire selon ce que contient le dépôt. Consultez le README du dépôt si des options spécifiques existent.
- L'idée : normaliser l'entrée et capturer la sortie brute pour comparaison byte-à-byte.
- Intégrer des vérifications simples dans CI
- Ajouter un job CI qui clone, build, lance le harness et vérifie l'identité des sorties.
- Gardez le job rapide (< 10 minutes) pour itérations fréquentes.
- Référez-vous au dépôt : https://github.com/M2Dr3g0n/kremis
Problemes frequents et correctifs rapides
Source : https://github.com/M2Dr3g0n/kremis
Build failures
- Symptôme : compilation échoue.
- Correctif : mettre à jour la toolchain Rust (rustup update), exécuter cargo clean puis cargo build. Vérifier Cargo.toml et la version d'édition définie.
Sorties non déterministes
- Symptôme : deux runs du harness produisent des différences.
- Correctifs recommandés :
- Canonicaliser les entrées (normalisation Unicode).
- Supprimer ou fixer les timestamps volatiles.
- Fixer les seeds des générateurs aléatoires en mode test.
Performance et latence
- Mesurez la latence médiane et les percentiles (p95) sur un test local.
- Faites un court warmup avant la mesure.
Restauration et sauvegarde
- Mettre en place snapshots réguliers et tester la restauration en environnement de dev avant mise en production.
Pour toute erreur, consultez d'abord le README et les fichiers du dépôt : https://github.com/M2Dr3g0n/kremis
Premier cas d'usage pour une petite equipe
Source : https://github.com/M2Dr3g0n/kremis
Public cible
- Fondateurs solo et équipes de 1–3 personnes souhaitant une preuve de concept locale.
Procédure courte (preuve en séance de travail)
- Cloner et compiler le dépôt.
- Écrire un petit script d'ingestion qui envoie une entrée connue au binaire.
- Exécuter 2 runs et comparer les fichiers de sortie bit-à-bit.
Exemple minimal (une ligne)
git clone https://github.com/M2Dr3g0n/kremis && cd kremis && cargo build --release
Déploiement minimal recommandé
- Containeriser le démonstrateur (Docker) et déployer sur une VM de test restreinte.
- Objectif : vérifier l'intégration réseau et collecter des métriques simples.
Notes techniques (optionnel)
- Citation exacte trouvée sur le dépôt : "a minimal graph engine for grounded AI — records, associates, and retrieves, but never invents". Le projet est écrit en Rust. Source : https://github.com/M2Dr3g0n/kremis
- Utilisez le README du dépôt comme référence primaire pour toute API ou option de build présente dans le code.
Que faire ensuite (checklist production)
Source principale et référence : https://github.com/M2Dr3g0n/kremis
Hypotheses / inconnues
Les points suivants sont des hypothèses pratiques, à valider contre les fichiers du dépôt (README, Cargo.toml, CI) :
- Clone + build + smoke test : 60–120 minutes.
- Écriture du harness et tests automatisés : 30–180 minutes.
- Containerisation + job CI : 60–240 minutes.
- VM de test (coût estimé) : £4–£40 / mois.
- Canary initial recommandé : 10% du trafic pendant 48 heures.
- Objectifs de latence de départ : médiane < 100 ms, 95e percentile < 300 ms sous 100 RPS (requêtes par seconde).
- Snapshot quotidien (24 h) avec rétention 7 jours, restauration testée toutes les 30 jours.
- Nombre d'ingestions pour profilage : 1 000 en lot.
- Exemple de limite de tokens si utilisé avec agents externes : 2 048 tokens.
Exemple hypothétique de docker-compose (à valider avant usage)
version: '3.8'
services:
kremis-demo:
build: .
ports:
- "8080:8080"
restart: on-failure
Tableau comparatif (hypothèse pour choisir un environnement)
| Environnement | Temps d'intégration (h) | Coût (£/mois) | Note | |---|---:|---:|---| | Local dev | 1–2 | 0 | itération rapide | | VM petite | 3–8 | 4–40 | tests réseau réels | | CI + canary | 6–24 | 10–80 | feedback automatique |
Risques / mitigations
- Risque : ingestion non déterministe. Mitigation : canonicalisation des entrées, suppression des timestamps volatiles et utilisation d'un seed fixe en mode test. Bloquer progression si 2 runs ne sont pas identiques.
- Risque : performances insuffisantes en production. Mitigation : déployer en canary (10% du trafic), mesurer la médiane et le 95e percentile, augmenter les ressources si nécessaire.
- Risque : perte de données. Mitigation : snapshots 24 h, rétention 7 jours, tester restauration au moins une fois tous les 30 jours.
- Risque : instructions de build manquantes dans le dépôt. Mitigation : lire le README et tout fichier CI avant d'automatiser, documenter toute étape ajoutée.
Prochaines etapes
- [ ] Vérifier le README et les fichiers du dépôt : https://github.com/M2Dr3g0n/kremis
- [ ] Cloner et exécuter un build local (cargo build --release)
- [ ] Implémenter le harness d'ingestion+query et produire 2 runs identiques
- [ ] Containeriser le démonstrateur et ajouter un job CI court (< 10 min) pour exécuter le test
- [ ] Déployer en canary restreint (10%) et monitorer les métriques définies (taux d'erreur, latence médiane, 95e percentile)
Checklist rapide à coller localement
- [ ] Cloner https://github.com/M2Dr3g0n/kremis
- [ ] Construire et exécuter smoke tests (cargo build --release)
- [ ] Implémenter test de reproductibilité ingest+query (2 runs identiques)
- [ ] Ajouter job CI pour construire et exécuter le test
- [ ] Déployer canary restreint et monitorer
Méthodologie recommandée : priorisez la preuve locale (smoke) puis l'automatisation CI avant toute montée en charge.