Discutez avec les dépôts (PR) à l'aide de Llama B

Par Tobi.A

Introduction:

Lorsque vous travaillez avec de grands référentiels, suivre les demandes d'extraction (PR), en particulier celles contenant des milliers de lignes de code, peut être un véritable défi. Qu'il s'agisse de comprendre l'impact de changements spécifiques ou de parcourir des mises à jour massives, les revues de relations publiques peuvent rapidement devenir écrasantes. Pour résoudre ce problème, j'ai décidé de construire un projet qui me permettrait de comprendre rapidement et efficacement les changements au sein de ces grands PR.

En utilisant la génération de récupération augmentée (RAG) combinée aux outils d'observabilité de Langtrace, j'ai développé "Chat with Repo(PRs)" - un outil visant à simplifier le processus d'examen des gros PR. De plus, j'ai documenté et comparé les performances de Llama 3.1B à celles de GPT-4o. Grâce à ce projet, j'ai exploré comment ces modèles gèrent les explications et les résumés de code, et lesquels offrent le meilleur équilibre entre vitesse et précision pour ce cas d'utilisation. 

Tout le code utilisé dans ce blog peut être trouvé ici

Avant d'entrer dans les détails, décrivons les outils clés utilisés dans ce projet :
Services LLM :

• API OpenAI
• API Groq
• Ollama (pour les LLM locaux)

Modèle d'intégration :

• SentenceTransformers (en particulier 'all-mpnet-base-v2')

Base de données vectorielles :

• FAISS (Recherche de similarité Facebook AI)

Observabilité LLM :

• Langtrace pour le traçage et les métriques de bout en bout

Fonctionnement de Chat avec Repo :

Le système Chat with Repo(PRs) implémente une architecture RAG simple pour l'analyse des PR. Cela commence par ingérer des données PR via l'API de GitHub, en fragmentant les fichiers volumineux pour gérer les limites de jetons. Ces morceaux sont vectorisés à l’aide de SentenceTransformers, créant des intégrations denses qui capturent la sémantique du code. Un index FAISS permet une recherche de similarité temporelle sous-linéaire sur ces plongements. Les requêtes subissent le même processus d'intégration, facilitant la correspondance sémantique avec l'index du code. Les morceaux récupérés forment un contexte dynamique pour le LLM choisi (via OpenAI, Groq ou Ollama), qui effectue ensuite une inférence contextualisée. Cette approche exploite à la fois l’efficacité de la recherche vectorielle et la puissance générative des LLM, permettant une compréhension nuancée du code qui s’adapte aux différentes complexités des relations publiques. Enfin, l'intégration Langtrace offre une observabilité granulaire dans les opérations d'intégration et LLM, offrant un aperçu des goulots d'étranglement en matière de performances et des optimisations potentielles dans le pipeline RAG. Plongeons dans ses composants clés.

Processus de regroupement :

Le processus de segmentation de ce système est conçu pour diviser les requêtes d'extraction volumineuses en éléments gérables et riches en contexte. Le cœur de ce processus est implémenté dans la classe IngestionService, notamment dans les méthodes chunk_large_file et create_chunks_from_patch.
Lorsqu'un PR est ingéré, le correctif de chaque fichier est traité individuellement. La méthode chunk_large_file est responsable du fractionnement des fichiers volumineux :

def chunk_large_file(self, file_patch: str, chunk_size: int = config.CHUNK_SIZE) -> List[str]:
    lines = file_patch.split('\n')
    chunks = []
    current_chunk = []
    current_chunk_size = 0

    for line in lines:
        line_size = len(line)
        if current_chunk_size + line_size > chunk_size and current_chunk:
            chunks.append('\n'.join(current_chunk))
            current_chunk = []
            current_chunk_size = 0
        current_chunk.append(line)
        current_chunk_size += line_size

    if current_chunk:
        chunks.append('\n'.join(current_chunk))

    return chunks

Cette méthode divise le fichier en fonction d'une taille de morceau configurée, garantissant que chaque morceau ne dépasse pas cette limite. Il s'agit d'une approche basée sur les lignes qui tente de conserver autant que possible les unités logiques de code ensemble dans la limite de taille.
Une fois le fichier divisé en morceaux, la méthode create_chunks_from_patch traite chaque morceau. Cette méthode enrichit chaque morceau avec des informations contextuelles :

def create_chunks_from_patch(self, repo_info, pr_info, file_info, repo_explanation, pr_explanation):

    code_blocks = self.chunk_large_file(file_info['patch'])
    chunks = []

    for i, block in enumerate(code_blocks):
        chunk_explanation = self.generate_safe_explanation(f"Explain this part of the code and its changes: {block}")

        chunk = {
            "code": block,
            "explanations": {
                "repository": repo_explanation,
                "pull_request": pr_explanation,
                "file": file_explanation,
                "code": chunk_explanation
            },
            "metadata": {
                "repo": repo_info["name"],
                "pr_number": pr_info["number"],
                "file": file_info["filename"],
                "chunk_number": i + 1,
                "total_chunks": len(code_blocks),
                "timestamp": pr_info["updated_at"]
            }
        }
        chunks.append(chunk)

Il génère une explication pour chaque bloc de code à l'aide du service LLM.
Il joint des métadonnées, notamment le nom du référentiel, le numéro PR, le nom du fichier, le numéro de bloc et l'horodatage.
Il inclut un contexte plus large comme des explications sur le référentiel et les demandes d'extraction.
Cette approche garantit que chaque morceau n'est pas simplement une tranche de code, mais une unité riche et contextuelle :

Cela comprend :

• Le code réel change
• Une explication de ces changements
• Contexte au niveau du fichier
• Contexte au niveau des relations publiques
• Contexte au niveau du référentiel

Recherche d'intégration et de similarité :

La classe EmbeddingService gère la création d'intégrations et la recherche de similarité :
1. Création d'intégration :
Pour chaque morceau, nous créons une intégration à l'aide de SentenceTransformer :

text_to_embed = self.get_full_context(chunk)
embedding = self.model.encode([text_to_embed])[0]

L'intégration combine le contenu du code, l'explication du code, l'explication du fichier, l'explication des relations publiques et l'explication du référentiel.
2. Indexation :
Nous utilisons FAISS pour indexer ces intégrations :

self.index.add(np.array([embedding]))

3. Traitement des requêtes :
Lorsqu'une question est posée, nous créons un plongement pour la requête et effectuons une recherche de similarité :

query_vector = self.model.encode([query])

D, I = self.index.search(query_vector, k)

4. Chunk Selection:
The system selects the top k chunks (default 3) with the highest similarity scores.
This captures both code structure and semantic meaning, allowing for relevant chunk retrieval even when queries don't exactly match code syntax. FAISS enables efficient similarity computations, making it quick to find relevant chunks in large repositories.

Langtrace Integration:

To ensure comprehensive observability and performance monitoring, we've integrated Langtrace into our "Chat with Repo(PRs)" application. Langtrace provides real-time tracing, evaluations, and metrics for our LLM interactions, vector database operations, and overall application performance.

Model Performance Evaluation: Llama 3.1 70b Open-Source vs. GPT-4o Closed-Source LLMs in Large-Scale Code Review:

To explore how open-source models compare to their closed-source counterparts in handling large PRs, I conducted a comparative analysis between Llama 3.1b (open-source) and GPT-4o (closed-source). The test case involved a significant update to the Langtrace's repository, with over 2,300 additions, nearly 200 deletions, 250 commits, and changes across 47 files. My goal was to quickly understand these specific changes and assess how each model performs in code review tasks.
Methodology:
I posed a set of technical questions related to the pull request (PR), covering:

• Specific code change explanations
• Broader architectural impacts
• Potential performance issues
• Compatibility concerns

Both models were provided with the same code snippets and contextual information. Their responses were evaluated based on:

• Technical accuracy
• Depth of understanding
• Ability to infer broader system impacts

Key Findings:

Code Understanding:

• Llama 3.1b performed well in understanding individual code changes, especially with workflow updates and React component changes.
• GPT-4o had a slight edge in connecting changes to the overall system architecture, such as identifying the ripple effect of modifying API routes on Prisma schema updates.

Knowledge of Frameworks:

• Both models demonstrated strong understanding of frameworks like React, Next.js, and Prisma.
• Llama 3.1b's versatility is impressive, particularly in web development knowledge, showing that open-source models are closing the gap on specialized domain expertise.

Architectural Insights:

• GPT-4o excelled in predicting the broader implications of local changes, such as how adjustments to token-counting methods could affect the entire application.
• Llama 3.1b, while precise in explaining immediate code impacts, was less adept at extrapolating these changes to system-wide consequences.

Handling Uncertainty:

• Both models appropriately acknowledged uncertainty when presented with incomplete data, which is crucial for reliable code review.
• Llama 3.1b's ability to express uncertainty highlights the progress open-source models have made in mimicking sophisticated reasoning.

Technical Detail vs. Broader Context:

• Llama 3.1b provided highly focused and technically accurate explanations for specific code changes.
• GPT-4o offered broader system context, though sometimes at the expense of missing finer technical details.

Question Comparison:

Below are examples of questions posed to both models, the expected output, and their respective answers:

Conclusion:

While GPT-4o remains stronger in broader architectural insights, Llama 3.1b's rapid progress and versatility in code comprehension make it a powerful option for code review. Open-source models are catching up quickly, and as they continue to improve, they could play a significant role in democratizing AI-assisted software development. The ability to tailor and integrate these models into specific development workflows could soon make them indispensable tools for reviewing, debugging, and managing large codebases.

We'd love to hear your thoughts! Join our community on Discord or reach out at support@langtrace.ai to share your experiences, insights, and suggestions. Together, we can continue advancing observability in LLM development and beyond.

Happy tracing!

有用的资源
Langtrace 入门 https://docs.langtrace.ai/introduction
Langtrace Twitter(X) https://x.com/langtrace_ai
Langtrace Linkedin https://www.linkedin.com/company/langtrace/about/
Langtrace 网站 https://langtrace.ai/
Langtrace Discord https://discord.langtrace.ai/
Langtrace Github https://github.com/Scale3-Labs/langtrace

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!