Deep Agent Builder 회귀 평가와 개선
회귀 평가는 에이전트 설정을 바꾼 뒤 기존 평가 결과와 현재 결과를 같은 기준으로 비교하는 작업입니다. Dataset, Case, Evaluator, 실행 대상 에이전트와 모델을 고정하지 않으면 점수 차이를 설정 변경의 영향으로 해석할 수 없습니다. 이 페이지는 실행 전 기준을 고정하고, 실행 후 결과 차이를 분류해 다음 변경을 결정하는 절차를 설명합니다.
비교 대상을 고정하기
먼저 비교 목적에 맞는 Dataset과 Case를 선택합니다. Case의 question은 확인하려는 실제 입력을 대표해야 하며, reference_answer는 비교 기준으로 사용합니다. 질문과 기준 답변에는 고객 정보, 비밀값, 운영 로그를 넣지 않습니다. CSV를 가져왔다면 question과 answer header, 최대 5 MiB 파일 크기, 최대 1,000행, 문자 길이 제한을 확인합니다.
비교 전에는 다음 항목을 기록합니다.
- Dataset의 식별자, Case 수, Case 순서와 각 question 및 reference_answer
- 평가 대상 agent의 식별자와 변경 전후 설정
- Evaluator의 식별자, 범위, 유형과 점수 범위
- 실행에 사용할 model 또는 사용자의 기본 model 여부
- 실행 시각과 비교할 이전 run의 식별자
Dataset을 수정한 뒤에는 기존 결과를 새 기준으로 취급하지 않습니다. Case의 질문이나 기준 답변을 바꾸면 같은 Dataset 이름을 유지하더라도 이전 run과 현재 run의 비교 조건이 달라집니다. 변경 시점을 별도로 기록하고, 필요하면 새 Dataset을 만들어 기준을 분리합니다.
기준 run과 비교 run을 만들기
기준 run과 비교 run은 같은 Dataset, 같은 Evaluator, 같은 agent를 사용하고, 의도한 변경은 기록된 범위 안에서 하나씩 적용합니다. 실행을 시작할 때 Dataset이 삭제되지 않았고 실행을 시작할 사용자에게 권한이 있는지 확인합니다. workspace Dataset을 조회할 수 있다는 사실만으로 다른 사용자가 실행할 수 있는 것은 아닙니다. 실행은 Dataset 생성자 기준으로 제한됩니다.
- 기준 run의 상태가 terminal인지 확인하고, pending 또는 running 상태라면 완료되거나 취소된 뒤 결과를 기준으로 삼습니다.
- 기준 run의 Dataset, Evaluator, agent, model과 실행 시각을 기록합니다.
- 비교하려는 agent 설정만 변경하고, 변경하지 않은 Dataset과 Evaluator는 그대로 둡니다.
- 비교 run을 생성한 뒤 pending에서 running으로 전환되는지 확인합니다.
- 두 run의 terminal 상태와 completed case 수를 확인합니다.
- 각 run의 결과 목록과 전체 결과 export를 조회합니다.
사용자별 pending 또는 running run의 기본 동시 실행 한도는 2입니다. 한도를 넘으면 429 RATE_LIMITED가 반환됩니다. 비교 run이 만들어지지 않았다면 반복해서 재시도하지 말고 기존 실행 수와 설정값 EVALUATION_MAX_CONCURRENT_RUNS를 먼저 확인합니다.
결과 차이를 분류하기
결과를 비교할 때는 전체 score만 먼저 보지 말고 Case별 결과를 같은 case_id로 맞춥니다. 다음 값을 함께 기록합니다.
| 비교 항목 | 확인할 내용 |
|---|---|
| 판정 | score, judge_reasoning, error, metrics_status |
| 품질 | question, reference_answer, agent_answer |
| 실행 | run status, 처리된 Case 수, latency_seconds, time_to_first_token_ms |
| 비용 | token_input, token_output, estimated_cost |
| 추적 | trace_id와 실행·저장 시각 |
score가 달라진 Case는 agent 설정 변경으로 인한 차이인지, 모델 또는 외부 의존성의 차이인지, 실행 오류인지 구분합니다. agent_answer가 바뀌지 않았는데 score만 달라졌다면 Evaluator, model, judge reasoning을 먼저 확인합니다. error가 있거나 metrics_status가 partial 또는 failed라면 점수 차이를 품질 회귀로 확정하지 않습니다.
결과 조회의 pass 필드는 실제 응답 계약에 포함되지 않습니다. 결과 필터의 pass는 score가 1 이상인 항목, fail은 score가 0인 항목으로 처리되며 Evaluator별 threshold를 사용하지 않습니다. 따라서 Dashboard의 pass_rate와 결과 목록의 필터 수를 비교할 때는 필터 규칙과 Dashboard의 집계 규칙이 같은지 확인합니다.
개선 여부를 판단하기
개선으로 판단하려면 같은 Case 집합에서 점수 변화뿐 아니라 실패 Case의 답변, judge_reasoning, 오류, 지연 시간과 비용을 함께 검토합니다. 일부 Case만 처리된 run은 전체 Dataset의 품질을 대표하지 않습니다. timeout, error, cancelled 상태의 run은 성공한 결과만으로 비교 결론을 내리지 않습니다.
Dashboard는 호출자가 소유한 agent 범위로 집계합니다. Dashboard와 개별 run의 수치가 다르면 먼저 agent 소유 범위, user 또는 workspace scope, date_range, terminal run 포함 여부를 맞춥니다. Dashboard의 avg_score는 score가 있는 실행을 대상으로 계산하고, pass_rate는 Evaluator의 score_max를 기준으로 판정합니다. TTFT가 없으면 latency_seconds를 밀리초로 환산해 평균에 사용하며, 비용 값이 하나도 없으면 total_cost는 null입니다.
다음 조건을 모두 확인한 뒤에만 변경을 유지합니다.
- 기준 run과 비교 run의 Dataset, Case, Evaluator, agent 범위가 의도대로 동일합니다.
- 비교 run이 terminal 상태이고 처리된 Case 수와 실패 Case를 확인했습니다.
- score 차이를 Case별 agent_answer와 judge_reasoning으로 설명할 수 있습니다.
- 오류나 부분 결과를 품질 개선으로 잘못 세지 않았습니다.
- latency, TTFT, token, estimated_cost가 허용 범위를 벗어나지 않았습니다.
- Dashboard 수치와 개별 결과의 집계 범위를 맞춰 확인했습니다.
실행 오류와 취소를 다루기
비교 run이 pending에 오래 머물거나 결과가 비어 있으면 worker queue와 run 상태를 확인합니다. 결과 export는 pending 또는 running 상태에서 409 CONFLICT가 되며, 결과가 0건이면 400 VALIDATION_ERROR입니다. Redis 연결 실패가 있어도 run 생성 응답은 pending으로 남을 수 있으므로, 201 응답만으로 평가가 실행됐다고 판단하지 않습니다.
취소는 run 생성자만 할 수 있고 pending 또는 running 상태에서만 가능합니다. DB에 cancelled 상태를 기록했더라도 Redis 취소 신호가 전달되지 않으면 남은 Case가 계속 처리될 수 있습니다. 취소 뒤에는 상태, completed case 수와 결과 목록을 다시 조회합니다.
결과가 일부만 저장된 경우에는 먼저 실행 오류와 metrics_status를 기록하고, 같은 조건으로 재실행할지 Case 단위로 보완할지 판단합니다. 원인을 확인하지 않은 채 Evaluator threshold를 낮추거나 실패 Case를 Dataset에서 제거하지 않습니다.