LLM 평가의 회귀 탐지 공백을 변이 테스트로 측정

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

LLM 평가 스위트가 원래 시스템에서 통과하더라도 프롬프트나 검색 문맥이 약해진 회귀를 잡는다는 보장은 없으며, muteval은 시스템에 의도적인 변이를 주입하고 기존 평가를 다시 실행해 이 공백을 측정합니다. 18개 변이 연산자로 프롬프트·RAG 문맥·도구 출력·모델을 바꾼 뒤 killed와 survived를 구분하고, 변이 점수와 95% 신뢰구간, 심각도 순위, 생존 변이를 잡을 평가 제안을 제공합니다. 기준선 실패나 과도한 변이체 오류에는 점수를 내지 않는 fail-closed 정책을 적용하며, 캐시·병렬 처리·호출 예산·CI 게이트로 운영 비용을 통제합니다. promptfoo, deepeval, RAGAS와 기존 Python 함수·endpoint를 연결할 수 있지만, 실제 시스템 도입은 플러그 앤 플레이가 아닌 통합 작업이며 점수의 한계도 함께 검토해야 합니다.

섹션별 상세

LLM 평가 스위트가 원래 시스템에서 모두 통과해도 내부 규칙이 약해진 회귀를 잡는다는 보장은 없습니다. muteval은 프롬프트와 검색 문맥, 도구 출력, 모델을 의도적으로 약화한 변이체로 바꾸고 기존 평가를 다시 실행합니다. 평가가 변이를 탐지하면 killed, 출력이 바뀌었는데도 평가가 통과하면 survived로 기록해 조치가 필요한 커버리지 공백을 드러냅니다.

muteval은 기준선이 먼저 통과한 경우에만 변이 점수를 계산해 의미 없는 수치를 차단합니다. 이후 18개 연산자로 입력 시스템을 변형하고 각 변이체에 대해 기존 평가를 실행한 뒤 탐지된 변이체 수를 평가된 변이체 수와 비교합니다. 결과에는 변이 점수, 95% 신뢰구간, 심각도 순위, 근접 실패 여유, 생존 변이를 잡을 수 있는 평가 제안이 포함됩니다.

프롬프트 변이는 부정문 뒤집기, 지시문 삭제, 문장 제거, few-shot 예시 제거, 강조 제거처럼 모델의 행동 규칙을 약화하는 방식으로 작동합니다. RAG와 에이전트 시스템에서는 문서 삭제·교체·손상, 문맥 초기화, 도구 출력 삭제·교체를 적용하고 모델에는 downgrade_model을 적용합니다. System(prompt, context, tools, model) 구조를 넘기면 시스템의 각 구성 요소를 따로 변이할 수 있어 단순 출력 비교보다 회귀 원인을 좁힐 수 있습니다.

기존 파이프라인을 다시 작성하지 않고 Python 함수나 배포된 endpoint를 테스트 대상에 연결할 수 있습니다. promptfoo 설정은 model provider와 기존 테스트·assertion을 읽어 그대로 재사용하며, deepeval과 RAGAS 지표도 어댑터로 muteval 평가 형식에 연결합니다. OpenAI-compatible endpoint, Ollama, Groq, Gemini 호환 서버, GitHub Models와 같은 제공자를 base-url로 지정할 수 있어 모델 호출 계층과 평가 계층을 분리할 수 있습니다.

반복 실행 비용과 CI 운영 부담을 줄이기 위한 기능도 평가 흐름에 결합되어 있습니다. SQLite 캐시는 동일한 모델·평가자 호출 결과를 저장하고 concurrency는 변이체를 병렬 평가하며 max-calls는 예산을 넘기기 전에 종료하도록 구성됩니다. fail-under 75와 fail-on-severity high를 CI에 연결하면 평가 커버리지가 기준 아래로 떨어지거나 심각한 미탐지 변이가 남을 때 빌드를 실패시킬 수 있습니다.

muteval은 점수가 높아 보여도 평가 자체가 불안정하면 신뢰하지 않도록 fail-closed 정책을 사용합니다. 기준선이 실패하거나 오류가 나면 점수를 산출하지 않고, 변이체 오류가 허용 한도를 넘으면 축소된 분모로 점수를 만들지 않으며, 비결정적 결과에는 반복 실행 다수결과 Wilson 신뢰구간을 적용합니다. 동일한 출력 변화가 실제로 관찰 가능한 회귀인지 구분하기 위해 출력 차이도 확인하고, 문서의 한계와 도입 체크리스트를 통해 실제 시스템 연결이 약 1시간의 통합 작업을 요구한다고 밝힙니다.

muteval의 probe 명령은 변이 커버리지와 별도로 평가 스위트의 품질을 점검합니다. 동일 입력에서 LLM Judge가 판정을 뒤집는지, 좋은 출력과 나쁜 출력을 구별하는지, 통계적 충분성과 평가 중복성이 어떤지 확인하며 라벨이 있으면 Cohen's κ로 사람과의 일치도도 계산합니다. 여러 품질 신호를 하나의 종합 점수로 압축하지 않고 report card로 제공하는 방식은 평가 커버리지와 평가 타당성을 구분하려는 설계입니다.

통제된 CI 실험에서는 평가가 전혀 없을 때 0%, 완전한 커버리지일 때 100%가 되도록 변이 점수가 네 도메인에서 단조롭게 상승했습니다. 대상 도메인은 support bot, code review, RAG, HR policy였으며, 이는 변이 점수가 평가 추가에 따라 어떻게 변하는지 확인한 결과입니다. 다만 실제 시스템에 적용할 때는 LLM 기반 의미 변이, 에이전트 trace 변이, A/B 스위트 비교가 아직 현재 범위가 아니므로 점수 자체를 절대적인 품질 지표로 해석해서는 안 됩니다.

이미지 분석

Screenshot
화면은 mutation score 23%와 5/22 killed, 95% CI 10–43%를 함께 보여주며 평가 스위트가 주입된 회귀 대부분을 놓친 상황을 나타냅니다. weaken_modals와 flip_negation 변이가 HIGH로 표시되고, 환불 규칙용 llm_judge 추가 같은 후속 조치가 연결되어 있어 muteval이 단순 점수보다 미탐지 원인과 보완 평가를 함께 제시하는 흐름을 시각화합니다.
터미널 화면에 muteval의 변이 점수, 탐지된 변이체 수, 생존 변이의 심각도와 이를 잡을 평가 제안이 표시되어 있습니다.

용어 해설

변이 테스트(Mutation Testing): — 변이 테스트는 정상 시스템에 의도적인 결함을 주입한 변이체를 만든 뒤 기존 테스트가 이를 잡아내는지 확인하는 방법입니다. muteval은 프롬프트, 검색 문맥, 도구 출력, 모델을 변형하고 평가 결과의 탐지 여부로 평가 스위트의 회귀 감지 범위를 측정합니다.
변이 점수(Mutation Score): — 변이 점수는 주입된 회귀 가운데 평가 스위트가 탐지한 비율입니다. muteval은 제거·변경된 변이체 수를 평가된 전체 변이체 수로 나누고, 95% 신뢰구간과 함께 표시해 평가 범위의 불확실성까지 드러냅니다.
Wilson 신뢰구간(Wilson Confidence Interval): — Wilson 신뢰구간은 이항 비율인 변이 점수가 표본 수에 따라 얼마나 불확실한지 나타내는 통계적 범위입니다. muteval은 변이체 수와 탐지 결과를 바탕으로 점수와 함께 95% 신뢰구간을 계산해 작은 실험에서 과도한 확신을 피하도록 합니다.
LLM 평가자(LLM Judge): — LLM Judge는 다른 언어 모델이 출력의 충실성이나 특정 규칙 준수 여부를 판정하도록 하는 평가 방식입니다. muteval은 OpenAI-compatible endpoint를 통해 grounded 같은 평가를 실행하며, 동일 입력의 판정 변동성과 좋은 출력·나쁜 출력 구분 능력도 별도로 점검합니다.
신뢰구간(Confidence Interval): — 신뢰구간은 관측된 평가 점수가 표본 변동으로 인해 가질 수 있는 범위를 나타냅니다. muteval은 변이체 평가에서 95% 신뢰구간을 제공하고, 반복 실행이 필요한 비결정적 환경에서는 다수결 판정과 함께 점수의 안정성을 확인합니다.

코드 예제

bash

muteval init --template rag # scaffold a config (or --template basic)
muteval check --config muteval_config.py # validate wiring + baseline first
muteval run --config muteval_config.py

RAG용 설정을 만들고 파이프라인 연결과 기준선 평가를 검증한 뒤 변이 테스트를 실행합니다.

bash

muteval run --prompt-file system.txt --cases cases.jsonl --model gpt-4o-mini \
--judge "the answer is grounded in the provided context" --fail-under 75

프롬프트와 테스트 케이스를 지정하고 LLM Judge 조건과 최소 통과 점수를 함께 설정해 실행합니다.

python

from muteval import MutEvalConfig, checks
config = MutEvalConfig(
    prompt=SYSTEM_PROMPT,
    cases=[{"input": "...", "order_id": "A123"}],
    run=my_run_fn,
    evals=[
        checks.contains_case("order_id"),
        checks.grounded("context"),
    ],
)

테스트 대상 호출 함수와 기존 평가 검사를 MutEvalConfig에 등록해 프롬프트·케이스·평가 흐름을 구성합니다.

bash

muteval run --config muteval_config.py --concurrency 8 --cache .muteval-cache.sqlite
muteval run --config muteval_config.py --max-calls 500

캐시로 반복 호출을 줄이고 변이체를 병렬 처리하며 모델과 평가자 호출 상한을 설정합니다.

python

from deepeval.metrics import FaithfulnessMetric
from muteval.adapters.deepeval import metrics_to_evals
evals = metrics_to_evals([FaithfulnessMetric()], input_key="question", retrieval_context_key="context")

deepeval의 FaithfulnessMetric을 muteval 평가 형식으로 변환해 기존 지표를 재사용합니다.

근거 모음

근거

muteval은 시스템을 의도적으로 약화한 변이체에 기존 평가를 다시 실행해 평가 스위트가 회귀를 탐지하는지 측정한다. — README의 muteval 정의와 How it works 절에서 시스템 변이, 평가 재실행, killed/survived 판정 흐름을 설명한다. 출처
기준선이 실패하거나 변이체 오류가 허용 범위를 넘으면 muteval은 점수를 산출하지 않는다. — Trustworthy by design 절의 Red or errored baseline, partial_errors, fail-closed 정책 설명. 출처
muteval은 프롬프트·검색 문맥·모델·도구를 대상으로 18개 변이 연산자를 제공한다. — What it can mutate (18 operators) 절의 연산자 목록. 출처
변이 점수는 탐지된 변이체 비율과 95% 신뢰구간, 심각도 순위를 함께 제공한다. — README 예시의 Mutation score 표기와 Score 단계의 결과 항목. 출처
promptfoo, deepeval, RAGAS의 기존 평가와 OpenAI-compatible endpoint를 muteval 흐름에 연결할 수 있다. — Optional extras, promptfoo ingestion, adapters, provider 설정과 Bring your existing metrics 절. 출처
통제된 CI 실험에서 네 도메인의 평가 커버리지 증가에 따라 변이 점수가 0%에서 100%까지 단조롭게 상승했다. — Trustworthy by design 절의 controlled, CI-enforced experiment와 support bot, code review, RAG, HR policy 언급. 출처

기술

muteval
Python
promptfoo
deepeval
RAGAS
OpenAI-compatible endpoint
Ollama
GitHub Actions
SQLite

활용 사례

지원 봇의 환불 규칙이나 문맥 근거 검사를 약화한 변이체를 만들어 기존 평가가 규칙 위반을 잡는지 확인할 수 있습니다. 프롬프트 문장 삭제와 부정문 반전을 통해 출력이 바뀌었지만 평가가 통과하는 생존 변이를 찾습니다. 발견된 변이에 맞춰 contains_case나 grounded 같은 평가를 추가해 커버리지 공백을 줄일 수 있습니다.
RAG 시스템에서 검색 문서 삭제와 교체, 문맥 초기화, 문서 손상을 적용해 검색 결과 의존성을 점검할 수 있습니다. 변이된 문맥을 모델에 전달한 뒤 충실성이나 근거성 평가가 이를 탐지하는지 확인합니다. 문서 수준의 변이 결과는 검색 계층과 생성 계층 중 어느 부분에 평가가 부족한지 파악하는 데 활용됩니다.
에이전트 시스템에서 도구 출력을 삭제하거나 바꾸어 도구 결과에 대한 의존성을 점검할 수 있습니다. System 구조에 tools를 포함하면 도구 출력 변이를 기존 평가와 함께 실행할 수 있습니다. CI에서 high 심각도 생존 변이를 차단하면 핵심 도구 오류를 놓치는 변경을 배포 전에 걸러낼 수 있습니다.