Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Support additional evaluation frameworks

Ouverte
  • Quelque chose ne va pas ?
#283 1 commentaire 1 réaction 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
12/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
À l'abandon
Stack technique
python
Domaine
machine-learning

Piste de recherche

The payload names no files or tests. The only concrete reference is the lm_eval_harness model wrapper in PR #282, so start there to see how the model is passed in memory. Done would mean agreeing on a unified interface design with maintainers and then integrating at least one additional evaluation framework, which is design work rather than a first-timer task.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

enhancement need update

🎯 Goal (What & Why)

The goal is to support the most important evaluation suites for our experiments. Ideally, we would define a unified API—an improved version of the lm_eval_harness model wrapper from #282—and let contributors extend the integration as needed.

The main challenge is that, in order to enable evaluation during training across different frameworks, we need to pass the model in memory to the target evaluation framework, rather than saving and reloading it from disk. This approach avoids changes in memory allocation and allows training to seamlessly resume after an evaluation step. We have already implemented such a wrapper for lm_eval_harness in #282.

Next steps:

  • Identify several key evaluation frameworks important to us.
  • Evaluate whether we can design a unified interface to integrate them as described above.
  • If a common interface isn't feasible, we may need to integrate each framework individually.

🚀 Execution Plan

(This section may start as an incomplete draft but must be defined before implementation begins.)

Step 1: What is the smallest working version?

(Describe the simplest way to implement this feature with minimal effort.)

Step 2: What additional optimizations are possible (but optional)?

(List potential refinements that can be added in later PRs if needed.)

📌 Acceptance Criteria (Must-Haves for Completion)

  • The feature must be functional and tested.
  • The implementation must be documented in practical terms.
  • The PR must include a performance/impact summary.
  • No refactors unless directly necessary for feature completion.

🛠️ Project Management

  • Assign the project to the Fast-LLM project.
  • Set the Estimate field (in days) in the GitHub project.
  • Use the Size field to categorize the PR size (Small/Medium/Large).
  • Assign an owner when opening the issue.
Langage dominant
Python
Étoiles
337
Forks
52
Aucune PR mergée en 30 j

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de ServiceNow/Fast-LLM

Toutes les issues de ServiceNow/Fast-LLM

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.