Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Evaluation: Add latency summary data

未關閉
  • 哪裡不對？
#1,253 0 則留言 0 個 reaction 已指派 1 人 在 GitHub 檢視

維護者通常 1 天內回覆

@Ayush8923 已經在處理了。

開始於 2026年10月14日。

  • #1252 來自 @Ayush8923 —— 未關閉

評估

這個 Issue 還沒有評估資料。

描述

Is your feature request related to a problem?
Evaluation runs provide cost information for OpenAI calls but lack latency data. This prevents us from identifying which configurations or prompts are slower, impacting our ability to optimize evaluations effectively.

Describe the solution you'd like
Add a latency summary to each evaluation run next to the cost, including:

  • Average time of OpenAI calls in milliseconds, plus the number of calls for each step:
    • response: generating the answer
    • embedding: similarity scoring (v1 runs)
    • judge: LLM-as-judge scoring (v2 runs)
  • One overall average across all successful calls.
  • Display this data on existing run endpoints for frontend integration.
  • Ensure runs complete even if latency calculation fails.
Original issue

Is your feature request related to a problem? Please describe.
Evaluation runs show how much the OpenAI calls cost, but not how long they took. When we compare configs or prompts, we can't tell whether one setup is slower than another, or which step of the evaluation is slow: generating answers, embeddings, or judging. Response time is one of the main reasons fast evaluations exist, but we don't report it anywhere.

Describe the solution you'd like
Add a latency summary to each evaluation run, next to the existing cost:

  • The average time of an OpenAI call in milliseconds, plus the number of calls, for each step:
    • response: generating the answer for each question
    • embedding: similarity scoring (v1 runs)
    • judge: LLM-as-judge scoring (v2 runs)
  • One overall average across all calls in the run.
  • Only successful calls count. Failed calls and questions blocked by a guardrail are left out.
  • Shown on the existing run endpoints, so the frontend can display it on the run card next to cost.
  • If working out latency fails, the run should still complete.

Describe alternatives you've considered

  • Storing latency inside the cost field. Rejected: a problem with one could wipe out the other. Keeping them separate keeps them independent.
  • Using the total batch duration for batch runs. Rejected: batch time is mostly OpenAI queue time, not call time, so it would be misleading. Batch runs will show no latency.
  • Adding p95 / max / per-question latency now. Deferred: we'll start with averages. The call counts and per-question timings are stored so these can be added later.
主要語言
Python
星號
18
分支
11
平均合併
4 天 3 小時
30 天內合併 PR
13

環境準備

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

ProjectTech4DevAI/kaapi-backend 的其他 Issue

查看 ProjectTech4DevAI/kaapi-backend 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。