Il s'agit du deuxième article d'une série dans laquelle je construis un outil RAG CLI open source. Dans l’article précédent, nous avons défini l’objectif de l’outil et analysé les étapes pour y parvenir.

Dans cet article, nous allons concevoir l'interface CLI et commencer à écrire du code.

Attendez, est-ce que j’ai vraiment besoin de lire l’article précédent pour pouvoir enchaîner avec celui-ci ?

Idéalement oui, mais voici le résumé que nous avons réalisé dans l’article précédent :

Nous construisons un outil CLI qui stocke les documentations de différents frameworks/bibliothèques et permet d'effectuer une recherche sémantique et d'en extraire les parties pertinentes.

Exigences:

• Git : sera utilisé pour cloner le dépôt des documentations
• Ollama : sera utilisé pour générer des intégrations

Hypothèses/limites :

• Nous supposons que les documentations sont disponibles sous forme de fichiers markdown sur un dépôt Git

Base de données : nous choisissons d'utiliser SQLite pour le moment et d'ajouter la prise en charge d'autres bases de données à l'avenir.

Conception de l'interface CLI

Remue-méninges

Appelons notre outilchiffon, les premières commandes qui me viennent à l'esprit sont :

• configuration du chiffon: configurez les exigences de l'outil (git, ollama, le modèle d'intégration, ...).
• chiffon ajouter: ajouter de la documentation à l'outil.
• chiffon obtenir: récupérer les parties pertinentes des documentations.

si je comprends bien, leinstallationLa commande doit être exécutée juste après l’installation de l’outil. Que se passe-t-il si l'utilisateur ne l'exécute pas et commence par faire unchiffon ajouterouchiffon obtenirdirectement?

Bonne prise, ma première idée serait d'afficher un message d'erreur demandant à l'utilisateur d'exécuter leinstallationcommande en premier. Mais maintenant que j'y pense, si nous pouvons détecter quand certaines exigences manquent, alors nous pouvons les installer automatiquement, en informer l'utilisateur via un message (peut-être sur stderr pour éviter de polluer la sortie), puis continuer avec le demandé. commande.

Avantages : Les commandes fonctionnent immédiatement, elles ajoutent automatiquement les exigences manquantes en cas de besoin. Pas besoin d'uninstallationcommande. Inconvénients : Toutes les commandes doivent vérifier les exigences au démarrage, ce qui peut ralentir l'outil.

Je pense que la résilience que nous gagnons en gérant automatiquement les exigences vaut la peine de performance. Une commande plus lente vaut mieux qu’une commande qui ne fonctionne pas.

Je suis d'accord avec toi sur la suppression duinstallationcommande et vérifier les exigences au début de chaque commande. Mais je demanderais les autorisati...
[Courte citation de 8% de l'article original]