Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Evaluation: Add latency summary data

Đang mở
  • Có gì không ổn?
#1,253 0 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

@Ayush8923 đang làm issue này rồi.

Từ ngày 14/10/2026.

  • #1252 của @Ayush8923 — đang mở

Đánh giá

Issue này chưa được đánh giá.

Mô tả

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.
Ngôn ngữ chính
Python
Star
18
Fork
11
Merge trung bình
4 ngày 20 giờ
Pull request đã merge (30 ngày)
9

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của ProjectTech4DevAI/kaapi-backend

Tất cả issue của ProjectTech4DevAI/kaapi-backend

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.