> ## Documentation Index > Fetch the complete documentation index at: https://docs.myrmagent.ai/llms.txt > Use this file to discover all available pages before exploring further. # 평가 연구소 > 내장된 GUI 대시보드에서 프로필 전체에 걸쳐 상담원 품질을 평가하고, 회귀를 추적하고, 성과를 비교하세요. # 평가연구소 Myrm의 **Eval Lab**은 에이전트에 대한 테스트 사례를 실행하고, 다양한 에이전트 프로필의 성능을 비교하고, 시간 경과에 따른 품질을 추적할 수 있는 내장 평가 대시보드입니다. 이 모든 작업이 WebUI에서 이루어집니다. ## 주요 기능 * **단일 프로필 평가** — 현재 에이전트 구성에 대해 테스트 모음을 실행하고 통과/실패 결과를 실시간으로 확인하세요. * **교차 프로필 매트릭스 평가** — 모델이나 프롬프트를 전환하기 전에 여러 에이전트 프로필에 걸쳐 동일한 테스트 사례를 실행하여 회귀를 감지합니다. * **환경 재현성** — 모든 평가 실행은 고정된 `EvalManifest` 스냅샷(모델, 도구, 프로필, 벤치마크 모드)을 캡처하므로 결과는 항상 재현 가능합니다. * **벤치마크 모드** — 핵심 도구만 사용하여 공정한 기준 점수를 생성하기 위해 사용자 사용자 정의(기술, MCPs, 메모리, 웹 검색)를 제거하는 원클릭 토글입니다. * **과거 추세 추적** — 대화형 차트를 통해 시간 경과에 따른 합격률 추세를 확인하세요. 기록 테이블에는 프로필, 모델, 합격률, 평균 시간 및 실행당 토큰 사용량이 표시됩니다. * **클릭하여 세부정보 보고서** — 사례별 결과, 환경 스냅샷 및 차이점 보기가 포함된 전체 보고서를 로드하려면 기록 실행을 클릭하세요. ## 시작하기 1. 사이드바에서 **Eval Lab**으로 이동합니다(또는 `/eval-lab`으로 이동). 2. **구성** 탭에서 데이터세트를 선택하고 선택적으로 **벤치마크 모드**를 활성화합니다. 3. **실행**을 클릭하여 평가를 시작합니다. 진행 상황은 실시간으로 업데이트됩니다. 4. **보고서** 탭에서 요약 카드, 사례별 테이블, 환경 스냅샷 등 결과를 봅니다. 5. **기록** 탭으로 전환하여 여러 실행을 비교합니다. ## WorkBuddy Bench 벤치마크 Eval Lab에는 **WorkBuddy Bench**(Tencent의 멀티 도메인 코딩 에이전트 벤치마크)용 내장 어댑터가 포함되어 있으며, 공식 4개 트랙을 논문 정렬 점수 방식으로 지원합니다. | 트랙 | 작업 수 | 대략 크기 | 점수 모드 | | ---------------- | ---- | -------- | ------------------ | | WBBench Code | 80 | \~196 MB | composite | | WBBench Web | 70 | \~22 MB | composite | | WBBench Office | 50 | \~10 MB | composite | | WBBench Security | 60 | \~479 MB | native (작업 내장 채점기) | ### 하위 집합 다운로드 1. **Eval Lab**을 열고 **WorkBuddy Bench** 탭으로 전환합니다. 2. 각 트랙은 작업 수, 대략 크기, 로컬 상태(`미다운로드` / `다운로드됨`)를 표시합니다. 3. **다운로드**를 클릭하면 Hugging Face에서 아카이브를 백그라운드로 가져옵니다. 진행률은 SSE를 통해 스트리밍되고, 다운로드 중에는 버튼이 비활성화됩니다. 4. 아카이브는 공식 SHA-256 체크섬으로 검증되고 원자적으로 설치됩니다 — 손상되거나 부분적인 아카이브는 절대 사용되지 않습니다. 5. 언제든지 **새로고침**으로 로컬 디스크 상태를 다시 읽습니다. 방금 완료된 다운로드는 즉시 버튼을 `다운로드됨`으로 전환합니다. ### 벤치마크 실행 1. 다운로드된 트랙에서 **실행**을 클릭하여 해당 하위 집합의 모든 작업을 평가합니다. 2. 평가 중에 **중지** 컨트롤이 제공됩니다 — 실행 중과 다운로드 중 모두 중단할 수 있습니다. 3. 완료되면 재현 가능한 보고서를 생성합니다(매니페스트에 모델, 도구, 프로필, 점수 모드 기록). :::tip Security 작업은 자체 내장 `tests/scoring.py`로 채점됩니다(LLM 판정 없음). Code/Web/Office는 합성 검증기(CompositeVerifier)를 사용합니다 — WBBench 논문의 수용 계층과 일치합니다. ::: ## 국제 권위 벤치마크(BrowseComp) WorkBuddy Bench 외에도 Eval Lab은 **BrowseComp**를 통합합니다 — OpenAI 공식 벤치마크로, 다중 홉 증거 검색과 웹 브라우징이 필요한 1,266개의 실제 연구 질문으로 구성됩니다. 여기서 나온 점수는 최고 AI 연구소가 인용하는 작업 형식과 동일하므로 릴리스나 제안에서 인용할 수 있는 권위 있는 성적입니다. * **샘플 먼저 실행** — 대형 벤치마크는 작은 샘플을 자동 제안합니다(예: 1,266문제 중 20문제). 전체 실행 전에 토큰 비용의 일부로 전체 파이프라인을 검증할 수 있습니다. 샘플을 비우면 전체 세트를 실행합니다. 보고서는 실제로 샘플링한 실행만 `sampled` 배지로 정직하게 표시합니다. * **공정한 기준선** — 벤치마크 모드는 스킬/MCP/메모리를 제거하여 점수가 '모델 + 핵심 도구'만 반영하게 합니다. * **사전 점검** — 실행 전에 벤치마크가 필요로 하는 검색/임베딩 서비스가 구성되고 도달 가능한지 확인하여 토큰을 낭비하지 않습니다. ## 결정적 채점: 계층형 수용(CompositeVerifier) 모든 작업의 채점은 작업 자체 테스트 스위트가 주도합니다 — 통과/실패 경로에 블랙박스 LLM 판정이 없습니다. 합성 검증기는 다운로드된 트랙 내부에 포함된 `tests/` 코드를 깨끗한 시드 워크스페이스에서 실행하고 결과를 실제 턴별 점수로 변환합니다. * **작업 자체 테스트 실행** — `test_suite` 어설션이 에이전트의 워크스페이스 산출물에 대해 작업에 번들된 테스트를 실행합니다. 결과는 JUnit XML 또는 일반 reward 스크립트 종료 코드에서 파싱됩니다. * **턴별 `pass_rate`** — 다중 턴 대화는 각 턴을 개별적으로 채점합니다. 1턴에 통과했지만 나중에 퇴화하는 작업은 조기에 발견되어 토큰을 낭비하지 않습니다(구성 가능한 `on_turn_fail` 전략). * **숨겨진 LLM 판정 없음** — 파싱은 완전히 결정적입니다. 통과/실패는 모델이 출력을 읽는 것이 아니라 테스트 러너에서 나옵니다. 점수는 재현 가능하고 judge-prompt 드리프트에 면역입니다. * **이진 판정이 아닌 부분 점수** — `skipped` 테스트는 분모에서 제외되어 수집 불가능한 flaky 테스트가 실제 통과를 깎지 못하게 합니다. reward 스크립트 출력은 점진 점수로 매핑됩니다. * **테스트 수준 가시성** — 각 트랙 카드는 실행 통과율과 **테스트 통과율**(턴 전체 `avg_pass_rate` 평균)을 모두 표시하고, 모든 보고서는 집계된 테스트 수준 평균을 포함합니다. | 수용 계층 | 검증 내용 | | -------------------------- | ---------------------------- | | Tool 호출 어설션 | 에이전트가 필요한 도구를 호출했는지 | | State 어설션 | 파일시스템/상태가 기대와 일치하는지 | | Sandbox 어설션 (`test_suite`) | 작업 자체 테스트가 실제 워크스페이스에서 통과했는지 | | Semantic 판정(선택) | 작업에 네이티브 테스트가 없는 경우에만 LLM 검사 | `test_suite` 타임아웃은 기본 600초이며 케이스별로 구성 가능하므로, 오래 걸리는 작업 테스트(예: 컴파일 + 실행)가 조기 종료되지 않고 완료됩니다. ### 판정 모델 구성 Semantic(LLM-as-a-judge) 어설션은 특정 벤더 판정 모델을 하드코딩하지 않습니다. 판정 모델은 사용자 구성에서 해석됩니다 — 실행 시 명시적 재정의, 어설션 수준 필드, 기본 모델 구성 순으로 — 이미 사용 중인 어떤 모델 공급자로도 채점할 수 있습니다. 모든 보고서는 실제 채점한 판정 모델(`judge_model`)을 기록하며, 작업 네이티브 벤치마크는 LLM 판정이 없다는 의미로 `none`을 정직하게 표시합니다. ### 채점 진단: 실패가 조용히 지나가지 않습니다 채점 실행이 테스트 출력을 만들기 전에 실패할 수 있습니다 — 채점 명령이 샌드박스 보안 정책에 차단되거나, 타임아웃되거나, 크래시할 수 있습니다. 이러한 실패는 이제 정확히 귀인되어 실제 증거와 함께 표면화됩니다: * **실패 귀인** — 실행 수준 실패(보안 차단, 타임아웃, 크래시)가 실제 원인으로 보고되며, 더 이상 "reward 파일을 읽을 수 없음"으로 잘못 보고되지 않습니다. 채점이 왜 실패했는지 즉시 알 수 있습니다: 정책 차단, 타임아웃, 또는 명령 자체 오류. * **stdout 끝부분 표시** — 모든 "명령 실패", "reward 파일을 읽을 수 없음", "JUnit 파일을 읽을 수 없음" 메시지에 채점 명령의 실제 stdout 최대 800자를 첨부하여, 추측 대신 실제로 무슨 일이 있었는지 확인할 수 있습니다. * **카운트 기반 reward 폴백** — 전체 `score.json`/`reward.json` 스키마 대신 `tests_passed`/`tests_total` 카운터(또는 `tests[]` 배열)만 담은 reward 페이로드를 올바르게 파싱하여 채점하며, 읽을 수 없음으로 거부하지 않습니다. 이는 공식 WBBench 러너의 카운팅 의미를 미러링하면서 가벼운 채점 스크립트와도 호환됩니다. ## 교차 프로파일 매트릭스 평가 서로 다른 에이전트 구성이 동일한 작업을 처리하는 방식을 비교하려면 다음을 수행하세요. 1. **구성** 탭의 칩 기반 다중 선택기에서 **2개 이상의 프로필**을 선택합니다. 2. 2개 이상의 프로필을 선택하면 **매트릭스 모드** 배지가 자동으로 나타납니다. 3. **실행 매트릭스**를 클릭하여 시작합니다. 대시보드는 실시간 진행 상황을 보여주는 **매트릭스** 탭으로 전환됩니다. * 현재 평가 중인 프로필 * 프로필 진행 상황(예: 2/3) * 케이스 완료 진행률 표시줄 4. 완료되면 **매트릭스** 탭이 표시됩니다. * **요약 카드** — 총 사례, 안정 비율, 회귀 횟수, 총 시간 * **프로필별 표** — 각 프로필의 합격률, 토큰, 비용, 시간 * **사례 × 프로필 그리드** — 각 프로필의 각 사례 상태를 표시하는 색상으로 구분된 매트릭스(녹색 = 안정, 황색 = 회귀, 빨간색 = 모두 실패) 5. 사건은 다음과 같이 분류됩니다. * **안정적** — 선택한 모든 프로필을 전달합니다(모델을 전환해도 안전함) * **회귀** — 일부는 통과했지만 일부는 실패함(위험한 영역) * **모두 실패함** — 모든 프로필에서 실패함(관계없이 조사 필요) :::tip 평가가 실패하면(예: API 키 만료, 모델을 사용할 수 없음) 토스트 알림에 오류가 즉시 표시됩니다. 자동 실패는 없습니다. ::: ## 메모리 A/B: 숫자로 메모리의 가치를 증명 메모리를 켜면 에이전트가 실제로 나아질까요? **메모리 A/B**는 마케팅 문구 대신 나란히 놓인 실험으로 이 질문에 답합니다. ### 작동 방식 1. **Eval Lab** → **WorkBuddy Bench**를 열고 다운로드된 트랙을 선택합니다. 2. 트랙 카드의 **Memory A/B** 버튼을 클릭합니다 — 확인 대화상자에 실행될 내용이 정확히 표시됩니다. 3. 대화상자는 **먼저 embedding 모델을 검사합니다**: 메모리 검색은 embedding에 의존하므로, embedding이 없거나 연결할 수 없으면 실행 낭비를 막기 위해 미리 알려줍니다. 4. Myrm은 **동일한 작업**을 두 번 실행합니다 — 한 번은 `enable_memory=True`, 한 번은 `enable_memory=False` — 나머지 설정은 완전히 동일합니다. 5. 진행률은 SSE로 실시간 스트리밍됩니다. 헤더의 **Stop** 버튼으로 실행을 중단하고 중간 상태를 정리합니다. :::note 대화상자는 WBBench 작업이 단일 턴이라 메모리 효과가 긴 다중 턴 세션에서 더 분명하다는 점을 솔직하게 알려줍니다. 과장된 홍보보다 올바른 해석을 드리고자 합니다. ::: ### 보고서 매트릭스 보고서는 두 팔을 나란히 보여줍니다: * **통과율** — 메모리 켬 vs 끔의 작업 완료율 * **토큰 및 비용** — 기억하는 데 드는 대가 * **`memory_tool_calls`** — 메모리 도구가 실제로 호출된 횟수. 메모리가 도움이 되었다면 실제로 사용되었음을 확인할 수 있습니다 — '켜져 있지만 사용되지 않은 메모리'의 거짓 양성은 없습니다. ### 기록 재열람 모든 메모리 A/B 실행은 **Run History** 테이블에 기록됩니다(타임스탬프, 데이터셋, 두 팔의 통과율 및 `memory_tool_calls`). **View**를 클릭하면 과거 보고서를 다시 열 수 있습니다 — 제품이 진화하면서 메모리 가치가 어떻게 변하는지 추적할 수 있습니다. ### 격리 및 안전 메모리 A/B 실행은 **임시 격리 메모리 저장소**를 사용하며 실행 후 폐기됩니다 — 실제 메모리 데이터는 절대 건드리거나 오염되지 않습니다. ### 테스트 커버리지 전체 연결 Chrome E2E 커버리지(실제 브라우저 + 실제 백엔드): 카드 진입 + 확인 대화상자, 시드된 이중 팔 보고서 + 기록 렌더링, 실제 실행 시작 + 중단 — E2E 테스트 3개 + 프론트엔드 단위 테스트 12개. ## 평가 워크스페이스 수명주기: 격리 샌드박스, 실행 후 즉시 폐기 모든 평가 케이스는 **물리적으로 격리된 워크스페이스**(`.myrm/eval_workspaces/{case_id}`)에서 실행됩니다 — 동시 케이스가 같은 파일에서 경합하지 않고, 에이전트는 자신의 샌드박스만 읽고 쓸 수 있습니다. 수명주기는 완전 자동입니다. * **실행 후 즉시 폐기** — 성공·실패·중단·크래시 모두 동일한 정리 경로(`create_session` 및 `execute` 전용 실행 포함)로 이어져, 장기 운영 서버에도 디스크가 쌓이지 않습니다. * **크래시 자가 치유** — 죽은 프로세스가 남긴 워크스페이스는 다음 서버 시작 시 자동으로 정리되며 수동 청소가 필요 없습니다. * **정리 체인 장애 방지** — 각 정리 단계(메모리 볼륨 해제, 디렉터리 삭제, 프로필별 워크스페이스 정리)는 독립적으로 보호되어, 한 단계가 실패해도 나머지 정리가 누수되지 않습니다. 이 격리는 메모리 A/B에도 동일하게 적용됩니다. 두 팔은 일회용 임시 메모리 볼륨을 사용하며 실행 후 해제 및 삭제됩니다. ## 평가 무결성: 오염 방지, 예산 통제, 궤적 공개 벤치마크 점수는 '실행을 속일 수 없고 보고서를 감사할 수 있을 때'만 신뢰할 가치가 있습니다. Eval Lab은 이 두 가지를 구조적으로 보장합니다. ### 오염 방지 실행 (HF 유출 방지) 벤치마크 실행 중 에이전트는 정답이 보관된 저장소 — 특히 **Hugging Face**(WBBench 트랙과 수많은 정답 데이터가 호스팅된 곳) 접근이 차단됩니다. 심층 방어: * **웹 페치** — 벤치마크의 차단 목록에 있는 hostname에 도달하는 즉시 `benchmark_blocked` 도구 오류가 발생합니다. * **웹 검색** — 차단된 호스트의 결과는 랭킹/포맷 전에 조용히 제거되고, 차단된 쿼리 용어는 즉시 실패합니다. * **Shell / 코드 실행** — 네트워크 정책은 기본적으로 외부 접근이 차단되거나(Hugging Face가 없는 엄격한 허용 목록) 정답을 외부로 빼낼 사이드 채널이 없습니다. * 보고서는 오염 방지 활성 여부(`decontam_active`)를 기록하고 Report 탭에 배지로 표시합니다 — '깨끗한 점수'는 가정이 아니라 증명 가능합니다. ### 선언된 실행 예산 모든 타사 벤치마크는 자체 **도구 호출 및 반복 예산**(`max_tool_calls` / `max_iterations`)을 선언합니다: * 막힌 에이전트가 무한정 토큰을 태울 수 없습니다 — 도구 호출 미들웨어와 엔진의 재귀 예산이 상한을 강제합니다. * 상한에 도달하면 실행이 중단되고 per-case 보고서에 어떤 상한이 중단시켰는지 정확히 기록됩니다(`limit_reached`, 예: `max_tool_calls` 또는 `max_iterations`). 잘린 케이스는 정상 완료와 절대 혼동되지 않습니다. * 매니페스트는 선언된 예산을 기록하고 Report 탭에 **예산 · N회 호출 / M회 반복**으로 표시됩니다. ### 궤적 공개 모든 보고서는 점수 뒤의 실행 증거를 노출합니다: * **도구 호출 세부사항** — 에이전트가 실제로 도구를 몇 번 호출했는지(`N×` 배지 + 툴팁). * **차단 횟수** — 오염 방지 가드가 몇 번의 시도를 가로챘는지(`Blocked N` 배지). * **도달한 상한** — 어떤 예산이 실행을 중단시켰는지(`Limit` 배지, 툴팁에 구체적 유형 표시). * **판정 투명성** — 의미론적(LLM-as-a-judge) 어서션은 설정 가능한 `judge_prompt`를 허용하고 보고서에 기록됩니다. 모든 실행에 `agent_model` / `judge_model`이 공개됩니다(작업 네이티브 채점은 정직하게 `none`으로 표시). 정확히 일치하는 답변은 판정자를 완전히 우회하므로 사소한 적중이 판정 토큰을 소모하지 않습니다. 이러한 메커니즘은 점수를 **모든 도구 호출까지 감사 가능**하게 만듭니다 — 숫자가 무엇인지뿐 아니라 어떤 보호, 어떤 예산, 어떤 궤적에서 생성되었는지 설명할 수 있습니다. ## 환경 스냅샷 모든 평가 실행은 다음을 사용하여 `EvalManifest`을 기록합니다. | Field | Purpose | | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `model_provider` / `model_id` | Which LLM was used | | `agent_model` / `judge_model` | Which agent model was scored and which model judged it — `none` for task-native benchmarks (no LLM judge). Every report and history row records both, so score drift after switching models is traceable | | `profile_id` | Which agent profile was active | | `benchmark_mode` | Whether user customizations were stripped | | `harness_version` | Framework version for reproducibility | | `tool_policy` | Which tools were available | | `prompt_fingerprint` | SHA-256 of the system prompt | | `task_set_hash` | Hash of the test dataset | 이 스냅샷은 보고서 탭의 **환경** 및 기록 테이블에 **프로필** 및 **모델** 열로 표시됩니다. ## 벤치마크 모드 깨끗한 기준을 얻으려면 구성 탭에서 **벤치마크 모드**를 전환하세요. * 시스템 프롬프트 → 비어 있음 * 도구 → 코어 전용(MCP 없음, 기술 없음, 하위 에이전트 없음) * 메모리, 웹 검색, 재계획, 압축 → 비활성화 이를 통해 사용자 정의 없이 원시 모델 기능을 측정할 수 있으므로 설정 전반에 걸쳐 점수를 비교할 수 있습니다. ## 테스트 케이스 작성 테스트 사례는 각 줄이 JSON 개체인 JSONL 파일입니다. ```json theme={null} {"message": "What is 2+2?", "expected": "4"} ``` 의미론적 주장(LLM-as-Judge)의 경우: ```json theme={null} { "message": "Write a haiku about coding", "assertions": [ {"type": "semantic", "criteria": "Output is a valid haiku with 5-7-5 syllable structure"} ] } ``` 구성 가능한 실패 전략을 갖춘 다중 회전 케이스 체인 회전: ```json theme={null} { "turns": [ {"message": "Create a file called test.txt", "assertions": [{"type": "tool", "tool_name": "write_file"}]}, {"message": "Read the file back", "expected_contains": "test.txt"} ], "on_turn_fail": "stop" } ``` ## 스킬 게시 품질 가드 기술이 Myrm의 Skill Evolution 파이프라인을 통해 발전하면 프로덕션에 도달하기 전에 **5개 방어 계층**을 통과합니다. 1. **EvolutionScreener** — 5단계 스크리닝(잠김 → 강제 재시도 → 쿨다운 → 거부 내역 → LLM 확인)을 통해 잘못된 진화 시도가 리소스를 소비하기 전에 차단합니다. 2. **EvalCase 회귀 게이트** — 후보 변형에 대해 바인딩된 EvalCases를 실행합니다. 실패한 사례에 비례하여 점수 페널티를 적용합니다. 100% 사례에 실패하는 하드 필터 변형입니다. 3. **개선 관문** — 원래의 기술을 기본 경쟁자로 주입합니다. 원본보다 실제로 더 높은 점수를 받은 변종만이 살아남습니다. 4. **SandboxValidator** — 격리된 샌드박스에서 후보를 실행하여 실제로 작동하는지 확인합니다. 5. **ConfidenceApprovalFlow** — 다중 신호 위험 제어(차이율, 유효 비율, 신뢰 임계값). 위험 신호는 GUI에서 인간 Diff 검토로 다운그레이드됩니다. 승인 후 **Shadow AB 테스트**는 전체 출시 전에 실제 트래픽과 비교하여 새 버전을 검증합니다. 문제가 발생하면 **원클릭 롤백**을 통해 이전 버전을 즉시 복원할 수 있습니다. ## 역사 및 저하 * 이전 보고서(매니페스트 추적 전에 생성됨)는 프로필 및 모델 열에 `-`을 표시하며 데이터 손실은 없습니다. * 히스토리 테이블은 좁은 화면에서 가로 스크롤을 지원합니다. * 실패한 보고서 로드는 자동으로 실패하는 대신 토스트 알림을 표시합니다.