ModelFit: 코드베이스별 맞춤 프로브로 LLM 정확도를 우선 평가하는 도구

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

TL;DR

ModelFit은 특정 코드베이스에서 자동으로 생성한 프로브와 명시적 루브릭을 이용해 후보 LLM의 정답률을 우선으로 비교하는 오픈소스 도구이다. 프로브는 대상 리포지토리의 실제 코드·패턴에서 유도되며 채점자는 모델명을 보지 못한 상태로 응답을 검증하기 때문에 평균 벤치마크와는 다른 실무 중심 비교가 가능하다.

실행 파이프라인은 각 프로브를 후보 모델에 전송해 시도와 응답을 기록하고, 판정자에게 과제와 루브릭과 응답을 전달해 JSON 형식의 엄격한 평결을 수집한 뒤 리포트에서 합격률·품질·비용을 종합해 순위를 매긴다. 비용은 공급자 토큰 사용량이 제공되는 경우 추적되며 누락 시 NA로 표기되고, 샘플 수를 늘리면 런 간 분산을 줄일 수 있다.

블라인드 채점은 모델 식별 편향을 낮추지만 스타일 편향과 프롬프트 인젝션 위험은 남아 있고, 판정자가 코드를 실제로 실행하지 않으면 컴파일 의존성으로 인한 실패 모드를 놓칠 수 있다. 따라서 민감한 데이터는 .env 등으로 관리하고 가격·샘플링 설정을 검증해야 하며 결과 해석 시 통계적 신뢰도와 실행 커버리지를 함께 고려해야 한다.

섹션별 상세

실무의 문제는 공개 벤치마크가 평균적 코드 패턴을 반영하므로 특정 리포지토리의 실제 요구를 충족하는 모델을 가려내기 어렵다는 점이다. ModelFit은 타깃 리포지토리를 인스펙션해 6~10개의 프로브(PROMPT + RUBRIC)를 생성하고 각 프로브를 후보 모델에 보내 응답을 수집하는 방식으로 동작한다. 생성된 프로브는 해당 코드베이스에서 약한 모델이 실수하기 쉬운 결정적 차이를 질문으로 삼아 실무적 분별력을 높인다. 이 접근은 평균 성능이 아닌 특정 워크플로우 적합성을 직접 평가하려는 목적에 맞춰 설계되어 모델 선택의 실효성을 높인다.

ModelFit가 후보 모델을 순회하며 프로브를 실행하고 블라인드 채점으로 순위를 매기는 데모 GIF 화면이다. — ScreenshotGIF는 프로브 실행과 판정 파이프라인의 동작 흐름을 시각적으로 보여주며 각 단계에서 시도와 판정이 기록되는 과정을 나타낸다. 이 이미지는 파이프라인의 입력(프로브)→응답 수집→판정자 전달→리포트 생성이라는 처리 흐름을 직관적으로 이해하는 데 유용하다.

실행 파이프라인은 순차적 스크립트로 구성되어 run.sh가 각 프로브를 후보 모델에 제출하고 모든 시도와 응답을 runs/<run-id>/attempts.csv에 기록하며 빈 응답이나 잘린 응답은 토큰 한도 내에서 재시도한다. judge.sh는 과제와 루브릭과 응답만을 판정자에게 전달해 엄격한 JSON 형식의 평결을 수집하고 runs/<run-id>/verdicts.csv에 보관하며 report.sh는 합격률, 품질, 비용을 종합해 커버리지 인식 리더보드를 만든다. 공급자별 토큰 사용량이 제공되는 경우 후보 비용, 판정 비용, 재시도 비용을 집계하고 누락 항목은 NA로 표기한다. 이 파이프라인은 판정의 불투명성을 줄이고 시도별 기록으로 감사 및 재현을 가능하게 한다.

bash

for p in probes/*.md; do
  n=$(basename "$p" .md)
  ./bin/modelfit run "$n" all --samples 1
  ./bin/modelfit judge "$n" all
done
./bin/modelfit report

probes 디렉토리의 각 프로브를 순회하며 run 명령으로 후보 모델에 프롬프트를 보내고 judge 명령으로 블라인드 루브릭 채점을 실행한 뒤 최종적으로 report를 생성하는 배치 실행 예시이다.

bash

./bin/modelfit run example-chunk fake-model-key --samples 1
./bin/modelfit judge example-chunk fake-model-key
./bin/modelfit report

단일 프로브에 대해 후보 모델과 판정자를 스모크 테스트하는 순서로, 샘플 수를 지정해 반복 변동성을 확인할 수 있는 기본 사용 예시이다.

블라인드 루브릭 채점은 채점자가 모델명을 보지 못하게 하여 모델 식별 편향을 줄이지만 스타일 편향과 프롬프트 인젝션 위험은 그대로 남는다. README는 블라인드 채점이 완전한 객관성을 보장하지 못한다는 한계를 명시하고 판정자가 코드 실행 결과를 보지 못하면 컴파일 의존성 같은 결정적 실패 모드를 포착하지 못할 수 있으므로 실행형 게이트를 추가할 것을 권고한다. 샘플 수가 1인 단일 실행은 통계적 신뢰도가 낮으므로 --samples N 옵션으로 반복 실행을 늘려 런 간 분산을 관리해야 한다. 이러한 설계 선택은 정확도 우선의 평가를 가능하게 하지만 결과 해석에서 통계적 신뢰성과 실행 커버리지를 반드시 함께 고려해야 함을 의미한다.

보안과 운영 측면은 민감 정보를 깃에서 배제하는 방식으로 처리되며 config/models.json에는 키를 담지 않고 .env 또는 쉘 환경 변수로 키를 관리하도록 설계되어 있다. 레포는 bin/scan-secrets.sh로 커밋 대상 파일에서 흔한 비밀 패턴을 점검하고 runs/, results.csv, .env 같은 민감 파일은 기본적으로 .gitignore에 등록되어 있어 우발적 유출 위험을 낮춘다. 다만 로컬 도구로서 100% 유출 방지가 불가능하므로 프로브 생성 전 민감 데이터 포함 여부를 검토하도록 권고한다. 가격 정보는 config의 예시 값일 뿐이므로 실제 비용 비교를 신뢰하려면 공급자 요금을 검증해야 한다.

실무 Takeaway

실제 코드베이스에서 생성한 프로브를 쓰면 평균 벤치마크가 놓치는 리포지토리 특화 오류 모드를 직접 측정해 모델 선택의 실효성을 높일 수 있다.
블라인드 루브릭 채점은 모델 식별 편향을 줄여 정확도를 우선 비교하게 하지만 스타일 편향과 프롬프트 인젝션 위험이 남아 있으며 코드 실행이 필요한 경우 실행형 게이트를 추가해야 한다.
리포트는 합격률·품질·비용을 함께 제시하므로 공급자 토큰 사용량이 제공될 때만 비용 비교가 정확하며 샘플 수를 늘려 통계적 신뢰도를 확보해야 한다.