Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Support additional evaluation frameworks

オープン
  • 何か問題がありますか？
#283 コメント 1 件 リアクション 1 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
12/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
python
領域
machine-learning

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.
主要言語
Python
スター
337
フォーク
52
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ServiceNow/Fast-LLM のほかの issue

ServiceNow/Fast-LLM の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。