SourceBridge : Outil open-source d'analyse de base de code utilisant des LLM locaux

SourceBridge est un projet open-source qui utilise des LLM locaux pour construire une compréhension structurée des bases de code. Vous le pointez vers un dépôt Git et il indexe la base de code dans un graphe de symboles contenant des fichiers, des fonctions, des classes et des dépendances. L'outil utilise ensuite votre LLM pour construire un arbre de compréhension hiérarchique, partant de segments de code individuels et remontant à travers les fichiers, les packages et le dépôt complet.

Ce qu'il génère

• Notes synthétiques : résumés à plusieurs niveaux ancrés dans le code réel
• Visites de code : parcours ordonnés architecturalement avec références spécifiques aux fichiers/fonctions
• Parcours d'apprentissage : matériel d'intégration pédagogiquement structuré
• Histoires de flux de travail : traces du flux de données à travers le système
• Recherche sémantique sur le graphe du dépôt

Support des modèles locaux

Le support des modèles locaux a été une priorité dès le premier jour. Les backends actuellement pris en charge incluent :

• Ollama — backend local principal, celui contre lequel le développeur teste quotidiennement
• llama.cpp — support direct de llama-server, légèrement plus rapide qu'Ollama lors des tests
• vLLM — pour les serveurs GPU
• LM Studio — y compris le décodage spéculatif
• SGLang — pour les configurations multi-GPU

Tous les backends fonctionnent via l'API compatible OpenAI, donc tout ce qui utilise ce protocole fonctionne. Les fournisseurs cloud (Anthropic, OpenAI, Gemini, OpenRouter) sont également pris en charge lorsque vous souhaitez une qualité supérieure pour des tâches spécifiques.

Performance des modèles

Le développeur l'a principalement exécuté sur Qwen 3.5 35B-A3B (MoE, seulement 3B paramètres actifs) via llama.cpp sur un Mac Studio. Avec la quantification Q4_K_XL, il fonctionne à environ 50 tokens/seconde et produit des notes synthétiques et des visites de code solides. Pour les dépôts plus volumineux, Qwen 3.5 122B-A10B via Ollama a été testé — il montre une meilleure capacité à suivre les instructions mais nécessite environ 76 Go de RAM.

Pour les tâches de compréhension (résumer du code, construire l'arbre de compréhension), les modèles de classe 32B font un travail raisonnable. L'écart de qualité entre les modèles locaux et cloud est perceptible mais n'est pas un obstacle pour la plupart des cas d'utilisation. Les modèles cloud restent clairement supérieurs pour la génération de style rapport où vous avez besoin que le LLM suive des instructions de formatage complexes sans boucler.

Le mode de réflexion dans les modèles Qwen 3.5 est désactivé par défaut — il gaspille des tokens sur des chaînes de raisonnement qui n'améliorent pas la sortie de compréhension. Ceci est configurable via une variable d'environnement si vous souhaitez expérimenter.

Architecture

• Serveur API Go (indexation, authentification, file d'attente des tâches, stockage du graphe)
• Worker Python gRPC (appels LLM, pipeline de compréhension, génération d'artefacts)
• Interface web Next.js (progression en temps réel, visualiseur markdown)
• SurrealDB (données du graphe, artefacts de connaissance, état des tâches)
• Les trois composants sont conteneurisés avec Docker, s'exécutent avec docker compose up

Le worker gère la mise en file d'attente, les nouvelles tentatives, le backoff et l'annulation — donc si votre modèle local est lent ou plante en cours de génération, le système récupère gracieusement au lieu de perdre le travail.

Pour commencer

git clone https://github.com/sourcebridge-ai/sourcebridge.git
cd sourcebridge
# Modifiez config.toml — pointez llm.provider vers votre instance Ollama/llama.cpp
docker compose up

Votre code ne quitte jamais votre machine. L'inférence LLM reste locale. Il y a une télémétrie anonyme facultative (seulement le nombre d'installations, désactivez-la avec DO_NOT_TRACK=1).

Le développeur recherche des retours de personnes exécutant des modèles locaux sur ce qui fonctionne et ce qui ne fonctionne pas, en particulier concernant les modèles qui produisent les meilleures sorties de compréhension, si les modèles MoE valent le compromis en RAM par rapport aux modèles denses, et tout problème avec des backends spécifiques.