레이블링 엔진

레이블링 엔진은 모델로 데이터셋에 레이블을 달고, 사람을 이용해 모델이 얼마나 자주 틀리는지 측정합니다. 완성된 레이블이 충족해야 할 조건은 계약으로 선언합니다. 예를 들면 "수락된 기계 레이블 중 틀린 것은 최대 5%, 신뢰도 90%"와 같은 조건입니다. 엔진은 그 주장을 검정하는 데 필요한 레이블을 사람에게 요청하고, 검정이 뒷받침하는 기계 레이블을 수락하며, 나머지 항목은 사람에게 보냅니다. 결과물은 데이터셋과, 무엇을 몇 개의 사람 레이블로 검정했는지 기록한 인증서입니다.

엔진은 Potato 2.11부터 쓸 수 있습니다. 주석 서버, potato label 명령줄, REST API, MCP 서버, Python SDK가 모두 작업 디렉터리의 같은 engine.sqlite 파일을 통해 엔진을 구동합니다.

엔진이 맞는 연구

엔진은 사람이 모든 항목에 레이블을 달 수 없고 모델이 대부분을 달 수 있을 때 효과가 있습니다. 어차피 사람이 모든 항목에 레이블을 달 계획이라면 엔진은 보탤 것이 없으며, 일반적인 할당 전략이 더 낫습니다. 다음 세 가지 상황에 맞습니다.

• 사람이 레이블을 달 수 있는 것보다 항목이 많고, 대부분 맞히는 모델이 있습니다.
• 논문, 데이터셋 공개, 또는 다른 사람이 쓸 학습 세트를 위해 모델이 레이블을 만들었다는 사실만이 아니라 레이블이 얼마나 좋은지도 보고해야 합니다.
• LLM 판정자로 모델이나 에이전트를 평가하고 있으며, 판정자가 사람을 대신할 수 있는지 알아야 합니다.

모델 예측에서 최종 레이블까지

엔진은 기계 예측, 사람에게 보낸 요청, 계약 결과를 한 저장소에 보관하며, 모든 항목은 같은 여섯 단계를 거칩니다.

1. 소스는 모델입니다. 소스는 LLM, 비전-언어 모델, 의사결정 모델(Laya, Jev, OpenJev), 객체 탐지기, LLM 판정자, 해당 연구의 레이블로 학습한 모델, 다른 소스로 구성한 배심(jury), 또는 이미 가지고 있는 레이블일 수 있습니다. 각 소스는 예측마다 신뢰도를 기록합니다.
2. 캐스케이드는 소스의 순서를 정합니다. 항목은 첫 번째 소스로 가고, 계약이 그 답을 수락하지 않으면 다음 소스가 시도합니다. 마지막 소스 다음에는 항목이 사람에게 갑니다.
3. 요청은 엔진이 사람에게 맡기는 일입니다. 각 요청에는 요청한 이유(예: 보정, 인증, 검증, 감사), 그 항목이 표본으로 뽑힐 확률, 사람이 기계의 답을 볼 수 있었는지가 기록됩니다. 보정 요청은 무작위로 뽑히며 항상 블라인드입니다.
4. 계약은 무작위 표본의 사람 레이블에 대해 기계 레이블을 검정합니다. 그 표본의 절반(dev 분할)으로 수락 규칙을 고르고, 나머지 절반(cert 분할)으로 그 규칙을 검정합니다. 계약의 상태는 met, insufficient(레이블이 더 필요하며, 몇 개가 필요한지 추정치를 함께 제공), infeasible, violated, stale 중 하나입니다.
5. 해소는 모든 항목에 최종 레이블을 정합니다. 레이블은 충족된 계약에 따라 수락된 기계 레이블, 사람의 레이블, 또는 대기 중 상태입니다.
6. 인증서에는 각 계약의 결과, 모델 및 프롬프트 버전을 포함한 캐스케이드, 용도별로 쓰인 사람 레이블 수, 모델 비용, 호출 로그의 다이제스트가 기록됩니다.

보장을 떠받치는 규칙

충족된 계약은 사람이 레이블을 단 무작위 표본에 관한 통계적 진술이며, 그 진술은 표본을 뽑고 쓰는 방식 덕분에 성립합니다. 엔진은 다섯 가지 규칙을 강제합니다.

• 블라인드 요청에는 기계의 답이 보이지 않습니다. 사람이 보정, 인증 또는 감사 요청을 맡고 있는 동안 서버는 그 항목에 대한 기계의 답을 모두 보류합니다. 사전 주석, 인라인 판정자, AI 어시스턴트(403으로 응답), AI 도움 버튼이 모두 꺼집니다. 기계의 답을 본 뒤에 단 레이블은 그 답을 독립적으로 확인한 것이 아닙니다.
• 선택과 검정에는 서로 다른 레이블을 씁니다. 임계값은 dev 레이블로 고르고 cert 레이블로 검정합니다. cert 레이블에 대한 새 검정은 매번 더 엄격한 수준에서 실행되므로, 검정을 통과할 때까지 인증을 반복해도 신뢰도가 부풀려지지 않습니다.
• 인증은 사람만 합니다. 기계 주석자는 최종 레이블 추론에는 참여할 수 있지만, 계약이 검정 기준으로 삼는 레이블에는 절대 참여하지 않습니다.
• 변경이 생기면 인증서는 stale 상태가 됩니다. 소스, 프롬프트, 임계값 또는 스키마를 바꾸면 영향을 받는 모든 계약이 stale로 표시되고, 수락되었던 레이블은 계약이 다시 검정될 때까지 pending_recert로 옮겨집니다. 사람 레이블은 유지됩니다.
• 기계 예측은 주석자 자리를 채우지 않습니다. 엔진의 예측은 항목별 주석자 상한에 포함되지 않습니다.

엔진은 사람 레이블이 옳은지 확인하지 않습니다. 모든 계약은 표본에 레이블을 단 사람들을 기준으로 기계를 측정하므로, 신뢰할 수 없는 사람들을 기준으로 검정한 계약은 신뢰할 수 없는 사람들과의 일치를 인증합니다. 사람도 함께 확인하려면 품질 관리, 중복 레이블링(humans.overlap), no_worse_than_human 계약을 사용하세요.

첫 연구

Potato에는 examples/labeling-engine/ 아래에 텍스트, 이미지, 에이전트 트레이스용 예제 연구가 하나씩, 모두 세 개 들어 있습니다. 표에는 각 예제가 쓰는 소스와 계약이 나와 있습니다.

텍스트 예제는 명령 네 개로 실행됩니다. 첫 번째 명령은 캐스케이드로 모든 항목에 레이블을 달고 첫 블라인드 표본을 뽑으며, 두 번째 명령은 그 표본을 사람에게 제공합니다. 마지막 두 명령은 사람이 표본에 레이블을 단 뒤 계약을 검정하고 인증서를 출력합니다.

potato label run examples/labeling-engine/text-certified-sentiment/config.yaml
potato start examples/labeling-engine/text-certified-sentiment/config.yaml -p 8000
potato label certify examples/labeling-engine/text-certified-sentiment/config.yaml
potato label certificate examples/labeling-engine/text-certified-sentiment/config.yaml --format md

자신의 연구에 엔진을 추가하려면, 이미 data_files와 sentiment라는 이름의 주석 스키마가 있는 설정에 다음 키를 추가하세요. 이 계약은 수락된 기계 레이블 중 틀린 것이 최대 10%, 신뢰도 90%일 것을 요구하며, budgets.human_labels는 엔진이 열 수 있는 사람 요청의 수를 제한합니다.

assignment_strategy: engine
 
labeling_engine:
  enabled: true
  sources:
    - id: gemma
      kind: llm
      endpoint_type: vllm
      model: google/gemma-4-12B-it-qat-w4a16-ct
      base_url: http://localhost:8001/v1
      confidence: {method: logprob}
  contracts:
    - id: accuracy
      kind: selective_risk
      schema: sentiment
      error: 0.1
      confidence: 0.9
  budgets:
    human_labels: 400

이 소스는 토큰 로그 확률로 신뢰도를 산출합니다(method: logprob). 이 방식은 항목당 호출이 한 번이며, 신뢰도 방식 중 대개 보정이 가장 잘 되어 있습니다. 설정에 모든 키가 나와 있고, 계약에서 각 계약이 무엇을 검정하는지 설명합니다.

주석 페이지의 요청

assignment_strategy: engine을 쓰면 주석자에게는 엔진의 요청이 우선순위가 높은 것부터 제공됩니다. 순서는 판정, 인증, 보정, 분포 계약을 위한 추가 평가자, 어떤 기계도 레이블을 달지 못한 항목, 검증, 감사입니다. 보정 요청은 고정된 무작위 순서로 제공되며, dev 요청과 cert 요청이 섞여 나옵니다. 한 사람은 한 항목에 열린 요청을 스키마당 하나씩 한꺼번에 받으며, 같은 항목의 같은 스키마에 대한 요청을 두 개 받는 일은 없습니다.

항목 위의 짧은 메모가 어떤 종류의 요청인지 알려 주고, 질문이 여러 개인 페이지에서는 해당 질문을 짚어 줍니다.

• 블라인드. 메모에는 "Label this one yourself. Suggestions are off for this item."이라고 표시됩니다. 그 사람이 저장한 뒤에도, 다시 불러오거나 뒤로 가도 항목은 블라인드로 남습니다.
• 검증. 기계의 답이 채워져 있고, 메모는 맞으면 그대로 두고 틀리면 바꾸라고 안내합니다. 페이지는 미리 채운 답을 기록하므로 사람들이 그 답을 얼마나 자주 받아들이는지 측정할 수 있습니다. 사람이 무언가를 하기 전에는 아무것도 저장되지 않으므로, 페이지를 열어 두기만 해서 답한 것으로 처리되지는 않습니다. 페이지가 답을 미리 채울 수 없는 스키마(시간 세그먼트, 3D 객체, 에이전트 트레이스)는 대신 블라인드로 제공됩니다.
• 해소. 수락할 수 있는 기계 레이블이 없었으므로 사람의 답이 레이블이 됩니다.

누군가 맡은 채 runtime.hold_minutes(기본 60분) 동안 답하지 않은 요청은 풀로 돌아가고 그 사람의 페이지에서 사라집니다. 엔진이 그 사람에게 제공하지 않은 항목에 저장된 레이블은 다른 사람의 요청을 닫지 않으며, 엔진은 이를 자연 발생 레이블(organic label)로 보관합니다. 새 인증으로 기계 레이블이 수락되면, 엔진은 이제 그 인증이 다루는 항목에 열려 있던 검증 및 해소 요청을 취소합니다. 이미 사람이 맡고 있는 요청은 그대로 남고, 그 사람의 답이 기계 레이블을 대체합니다.

진행 카운터는 코퍼스가 아니라 그 사람이 아직 맡을 수 있는 요청을 셉니다. 아직 할 일이 없으면 주석자에게 짧은 대기 페이지가 표시되고, 플래너가 새 요청을 열면 제공됩니다. 모든 항목에 레이블이 있거나, 사람 레이블 예산을 다 썼거나, 그 사람의 상한에 도달해서 더 이상 올 요청이 없으면, 평소처럼 사후 연구 페이지와 함께 그 사람의 몫이 끝나고 크라우드 플랫폼에서는 완료 코드가 표시됩니다. 플래너의 첫 실행 전에 끝나는 사람은 없습니다.

포켓 모드도 엔진 요청을 한 번에 한 배치씩 제공하며, "All caught up"을 표시하기 전에 요청을 더 받아 옵니다. 포켓 모드는 기계의 답을 절대 보여 주지 않으므로, 데스크톱 페이지가 그 사람에게 이미 답을 보여 준 경우가 아니라면 그곳에서 제공된 검증 요청은 블라인드로 기록됩니다. 해소 및 판정 카드에는 데스크톱 페이지와 같은 메모가 표시됩니다.

관리자 페이지

엔진이 켜져 있으면 관리자 대시보드에 /admin/labeling-engine의 Labeling engine 링크가 생깁니다. 이 페이지의 모든 차트에는 표 보기도 있습니다. 페이지에는 다음이 표시됩니다.

• 각 계약의 상태, 커버리지, 검정 회차, 추가로 필요한 레이블 수와, 계약이 내세우는 전체 진술(충족되지 않은 계약은 보장이 아니라 목표를 진술합니다)
• 각 ppi 계약의 구간과, 그 옆에 사람만으로 얻은 구간
• 마지막 실행이 실패했거나 모든 답이 오류였던 소스에 대한 경고
• 마지막 캐스케이드 단계의 오류 대 커버리지 곡선과, 보장된 상한 및 목표
• 단계별 신뢰도 다이어그램. 진술된 신뢰도를 사람 레이블 기준 정답 비율과 대비해 그리며, ECE와 Brier 점수를 표시하고, 레이블이 적은 구간은 더 옅게 그립니다
• 수락된 레이블에 대한 감사를 목표 대비 오류로 나타낸 결과와, 판단하기에 감사가 너무 적은지 여부
• 용도와 상태별 사람 요청
• 토큰, 지연 시간, 비용을 포함한 모델 호출 로그(최신순)
• 플래너 실행, 즉시 인증, 인증서 열기 버튼

관리자 세션 없이 열면 페이지는 대시보드의 키 입력 양식으로 이동합니다. 엔진이 꺼져 있으면 그 사실과 함께 엔진을 켜는 키를 알려 줍니다.

더 읽어보기

• 레이블링 엔진 계약: 여섯 가지 계약 종류와 각각이 검정하는 것
• 레이블링 엔진 설정: 모든 labeling_engine 키
• 명령줄, REST API, MCP 도구, SDK
• icl_labeling, judge_calibration, pre_annotation에서 레이블링 엔진으로 이전하기
• 전문가 한 명이 LLM과 함께 작업하는 솔로 모드
• LLM 사전 주석과 LLM 판정자 일치도

구현에 관한 자세한 내용은 소스 문서를 참고하세요.